top of page

機能を盛り込みすぎた結果使いこなせないシステムが出来上がった失敗例

更新日:2022年5月27日

開発慣れしていないと、使うかわからないけどあれば便利という機能を盛り込みがちになります。

開発予算と納期が長引いても良いのであれば良いのですがそのような開発はありません。



【失敗例】システム導入に際して機能を盛り込みすぎた


これまで経理部が社員の出張管理をエクセルにより管理していたのですが、ベテランの退職や、時間効率の悪さからシステムにより一括管理することになりました。


これまで社員は既定のエクセルフォーマットに出張記録を付けて経理部に送り、経理部がそれを取りまとめていたのですがこの作業をシステムで自動化することが目的の開発でした。


まず社員側が作成する必要項目を洗い出しました。また、要望として挙がっていたことを機能として盛り込み入力側の要件を取りまとめました。


次に経理部でやっている作業を洗い出し要件にまとめるようにしました。その際、こんな機能があれば便利というものをヒアリングして経理側の要件をとりまとめました。


要件定義が出そろってきたので開発会社と打ち合わせを行い設計書の作成、画面遷移図の作成などの作業に入り、インフラの設計、セキュリティなどについては開発会社さんからご提案をいただき社内確認後、採用となった提案を盛り込みました。


構築にとりかかりCSVのアップ/ダウンロード機能など追加要件は多少の追加見積もりで対応できました。


出来上がったシステムは従来のエクセルと変わらない情報量に加えて要望が上がっていた機能が盛り込まれいたため開発会社からのレクチャーを受ければすぐに使いこなせると思っていました。


ところがシステムが稼働を開始し、運用方法について入力側の人材にレクチャーを行ったところ、クレームとは言いませんが不評の嵐になってしまいました。


一番の問題はこれまでエクセルで10分程度だった入力作業が平均して30分以上になってしまったことです。

理由は見た目が変わってしまったこと、操作範囲が多すぎて、何をすればよいのかがわかりにくくなってしまったことでした。


携帯端末、PCなど環境に依存しないことを機能として盛り込んだのですが各端末による使用方法を学ばなければならず、覚える時間が無駄だといった意見が出てしまったのです。


管理側の経理部でもシステムで出来ることが多すぎること、希望した機能は実現されているのですが実行するための手順が複雑すぎて、実際に何をすれば今まで通りのことが出来るのかが見えづらくなってしまい以前よりも処理に時間がかかる事態になってしまいました。


作業効率をアップさせるためのシステム導入だったのですが1か月経っても効率がアップしないため経営陣の判断により、システムの稼働を一時停止し元のエクセル入力に戻すことになりました。


【失敗の理由】

業務システムの開発に関する失敗例としてよく聞かれるのが、


システム化した結果、以前よりも業務効率が落ちた


ケースです。

ほんとうに多いです。今回はその中でも最悪のケースを失敗例として挙げました。


なぜこんなことが起こってしまったのか少しまとめてみました。


・社員の技量に合わせていないシステム化

・担当者を付ける

・機能を盛り込みすぎた


社員の技量に合わせていないシステム化

それまでエクセルで処理しているわけですから入力画面など社員が操作する箇所はエクセルと同じ見え方、導線の引き方をしなければなりません。


表示画面をエクセルと全く同じにする必要はありませんが、エクセルで入力していた時に限りなく似せる努力をすべきでした。


とくにIT慣れしている人材が少ない業種については見え方が異なってしまうだけで違和感を感じたり、やる気が失せてしまうことを理解しなければなりません。


それまでの当たり前が当たり前ではなくなってしまうと、勉強しなければならないといった感情がわいてきます。


ただでさえ忙しいのに社内作業で勉強する時間というのは、いらない作業に分類されます。


風通しが良い会社であればクレームに発展します。


大切なことなのでもう一度繰り返しますが、使う人にストレスを感じないような画面設計にすることはとても重要です。


担当者を付ける

業務システムなどは利用マニュアルが作成されます。


開発に携わっている部署は開発会社と知識の共有を行っていますから問題ありませんが、ボリュームの大きなシステムに切り替わったりすると、やれることが多くなる半面、覚えることが多くなりすぎて使いこなすのが大変になります。


そのための利用マニュアルですが経験上、使い手がマニュアルを読む率はそれほど高くありません。


感覚的には3割いないのではないかと思っています。


理由は先に挙げた、本来すべきではない作業、という意識が働いているからです。

システムの管理を行っている部署が社員に対して全体説明会などを催すのは一般的ですが、これもうまく機能した例を私は知りません。


最悪なのは、使う社員からの問い合わせに対してマニュアルを確認してください、という対応です。


質問する側からすれば、調べてる時間がもったいないから訊いてるんだ、というスタンスです。それに対して、マニュアルを見てください、という回答は少々乱暴ではあります。


社内体制が「自分で調べて解決する」ことに慣れている会社であればそれでも良いのかもしれません。

ただそのような会社はすでにシステム化が完了していることが多いのが現実です。


自主性を重んじることを社風にしている会社が増えましたが、こういうツールの使いこなしについては人的サポートが必須だと考えます。


この問題をクリアするために必要なのはシステムを熟知している担当者を付けることです。


開発に携わっている方の1人が担当者として新しいツールについて問い合わせ窓口となることです。


利用が浸透してくるまで時間はかかりますが、サポートに費やす時間は右肩下がりになりますからタスクが重くなることはありません。


そしてもう1つ重要なことは、開発中に経験したことをまとめておくことです。


新しいものを作っているわけですから、最初からシステムを完全に理解するのは不可能です。

アジャイル開発では機能ごとに開発を進めますから、テスト環境下で稼働しているシステムを自分でテストしている時に感じた違和感や注意点などをすべて書き出してエクセルなどにまとめておきます。


管理部署全体で行えば各人によって様々な使い方となるので経験、感じたことをまとめておくことは大変に効果的です。


これを質問想定集としてまとめておくと効果的なマニュアルになります。


システムが稼働した際に利用者からあがってきた質問の5割近くが開発担当者が感じた疑問と同じだったという発注者もいたほどです。


マニュアルは読まないと書きましたが、無いほうが良いという意味ではありません。

効果的に作られているマニュアルは質問率を下げることに役立ちます。


機能を盛り込みすぎた

これもシステム開発においてよくある失敗です。


要件の洗い出し作業を行っているとどうしても欲張りになります。


「この機能を付けたのであれば、あの機能も追加しとこう」

「せっかくだからこの機会にあの機能を盛り込んでおこう」

「もしかしたら使うかもしれないから要件に入れておこう」


こうした理由による機能追加が重なるとゴテゴテのシステムになってしまいます。

工期は長くなりますし開発費も必然的に高騰します。


機能の盛り込みすぎは利便性を損なうことにつながりますから避けるべきです。

こうした失敗をしないための心得があります。


・既存のタスクから必要であると思われる追加機能のみを書き出す

・せっかく、もしかしたらなど、使うか分からないけどあれば便利、という機能は要件から外す


どちらも同じ意味のように見えますが、前者は過去の業務経験からくる考え方であり、後者は未来の想定からくる考え方です。


盛り込む機能は、実装される追加機能が過去の経験に基づいているものだけで構成することです。あやふやな理由で要件を洗い出さないことが失敗を避けることにつながります。


ちなみに弊社では

既存システムの改修を多数手がけてきた経験から機能要件の取り決めにかける時間は多めにとるようにしています。


特にフロント側の処理に時間をかけるようにしています。


要件の洗い出しではエンジニアだけではなく営業部も参加して「利用者」目線での構成を組み上げるようにしています。


特に機能の盛り込みすぎ問題、導線の複雑化、見た目の変化などは利用者ストレスに直結しますから気を付けます。


必要となれば文字だけではなく図と文字、時にはかんたんなモックを作るなどして文字と図だけでは見えてこない面を深堀します。


業務システムに関しては機能選定をあいまいにしていると失敗に直結するので特に気を付けます。






bottom of page