システム開発においてユーザが満足できないものになる要因3選
システム開発に携わった方で、システムのリリース後にユーザから「このシステム使えない」と言われた経験はないでしょうか?
なぜそのような状況になるのか、そうならないために何を気を付ければ良いかを私がこれまでに携わったプロジェクトの経験を元にお伝えします。
要因は色々あると思いますが、その中でも下記の3点が大きな要因だと考えています。
<要因3選>
- ユーザがシステムのコンセプト/仕様を理解していない
- 要件定義が漏れていて一部を運用できない
- クリティカルなバグがあり運用できない
[要因1] ユーザがシステムのコンセプト/仕様を理解していない
システムの良し悪しではなく、そもそもユーザが仕様を理解しておらず使い方が分からないために、「使えないシステム」となるケースです。
ユーザの立場からすれば、これまでとは運用が変わり、新システムに慣れる/覚えるまではストレスとなるため、仕様を理解せずに運用すると、このように感じることになります。
なぜ仕様を理解せずに運用しているのかを考えてみます。
①ユーザ側のシステム担当者が全ユーザにコンセプト/仕様を共有していない
システム開発は、ユーザ側のシステム担当者と開発側の担当者で要件を詰めて仕様を決定するが、ユーザ側のシステム担当者が全ユーザに全ての機能を共有できていない、または正確に共有していないために発生する。
対策:時間をかけてレクチャし、全体の説明と役割ごとの説明の場を設ける
②ユーザ側のシステム担当者がシステムを全て正確に理解していない
仕様は開発側の担当者がユーザ側のシステム担当者と確定した要件を元に、検討しレビューを行った後に確定しているので、仕様は理解されているはずだが発生する。
対策:ユーザ側のシステム担当者がマニュアルを作成するなどして、仕様を確認した上で全ユーザに対して説明する
[要因2] 要件定義が漏れていて一部を運用できない
ユーザが運用して初めて要件の抜け漏れに気付き、「〇〇〇はどうやって対応するのですか?」と開発者に問い合わせをするケースです。
要件定義は確定しているはずだが、なぜリリース後にそれが発生するのかを考えてみます。
①業務で起こりえる全てのケースが想定されていない
他にも「要件定義時から業務フローが変わっている」「仕様の確認が十分に行われていない」も同じようにあります。
要件定義後に各機能の仕様を開発担当者がユーザ担当者にレビューし、仕様書の確認を依頼するが、それが十分に確認されずに確定となっている。
②要件があいまい
「以前使っていたシステムと同じ機能で」等のあいまいな要件で定義されているため、本来必要な機能が漏れている。
③ユーザによる受入テストが行われていない又はテストケースが漏れている
基本、システムテスト完了後にユーザによる受入テストを実施するが、それが十分に行われていないために、リリースされるまで発覚しない。
対策:ユーザ側が「要件を満たしていれば良い」とし、テストを開発者任せにすることがあるので、テストの目的を共有して進めることが重要
[要因3] クリティカルなバグがあり運用できない
バグで処理が実行できず、手作業で対応しないとならない運用が発生してしまうケースです。
なぜこのようなバグが発生してしまうかを考えてみます。
①テストが不十分
リリースされるまでには基本、開発担当者によるシステムテストとユーザによる受入テストが行われ、どちらかのテストでデバッグできる。
しかし、テストが十分に行われていない場合、リリース後に不具合が発覚する。
対策:ユーザ側と開発側の担当者がそれぞれ責任もってテストを行う(お互いに他人任せにしない)
②機能追加の実装でデグレート
システムテスト時にバグはなかったが、それ以降の機能追加の対応でデグレートしている。
対策:システム改修時は開発者が影響範囲の調査を行い、関係者にレビューして漏れがないかの確認することで防げる
まとめ
ユーザは役割や携わる業務により想定していた業務が遂行できないと「使えないシステム」という判断をします。
開発/テストフェーズにおいて、ユーザ側と開発側の担当者がお互いに他人任せにするのではなく、仕様決め/テストを協力し合って行うことができれば、より満足度の高いシステムに仕上がると思います。
ファブリカコミュニケーションズで働いてみませんか?
あったらいいな、をカタチに。人々を幸せにする革新的なサービスを、私たちと一緒に創っていくメンバーを募集しています。
ファブリカコミュニケーションズの社員は「全員がクリエイター」。アイデアの発信に社歴や部署の垣根はありません。
“自分から発信できる人に、どんどんチャンスが与えられる“そんな環境で活躍してみませんか?ご興味のある方は、以下の採用ページをご覧ください。