システム開発の虎ノ巻

プロマネ初級者必見!システム開発の鉄板ノウハウをいつでも使える形に!徐々に充実させていきます!

<要件定義のポイント>スコープで要件の肥大化を防止する

f:id:tsunetsune7:20200112173316j:plain


ユーザーからのヒアリングで業務要件の洗い出しが終わったら次の工程へ、とはいきません。まずは、業務要件を整理・分析することが必要です。

ヒアリングで入手した情報の中には、システムによって実施する方が効率が良い部分もあれば、人間にしか出来なかったり、既に他のシステムで行われていたりする業務もあったりします。何でもかんでもシステムに突っ込んで実現する方がユーザーは幸せになれるかと言えば決してそんなことはなく、あまり使われない機能についても予算を確保しなければならなくなったり、運用保守フェーズに移ってからもシステム化したがために融通が利かない仕組みになったり、障害が多く出てしまったり、デメリットが発生する場合もあります。開発者側としても、単純に作業量の増加につながるだけでなく、開発スケジュールに無理が生じてテストが十分に行えないなど、プロジェクト運営に支障をきたします。最悪の場合、プロジェクトが失敗に終わる可能性もゼロではありません。

このような状況に陥らせないためにもスコープの設定が重要になります。ヒアリングを通じて、システムとして実現したい業務要件については把握できました。そこから本当にシステムで実現すべき範囲を線引きして切り分けを行うことで、システム化する対象を絞り込みます。そうして絞られたのがスコープとなります。

尚、設定したスコープは、「機能要件」と「非機能要件」に分けることができます。「機能要件」は分かりやすく、画面に必要な項目や検索条件、項目制御内容などのことで、「非機能要件」は機能要件を実現するために必要なコンピューターの性能や環境面のことを言います。例えば、同時接続人数は100人~200人程度だからCPU、メモリはこれくらい必要でクラスタ構成が必要だとか、受注実績データが過去3年分は必要だからディスク容量はこれくらい必要だとか、インタネットに公開するから認証方式は何々が必要でセキュリティ面はこのように確保するとか、ネットワーク回線の太さは100MBbpsで十分だとかいったことです。非機能要件の存在を見過ごしてしまうと、テスト工程になってからパフォーマンス問題が顕在化してしまい、設計のやり直しなどの手戻りが発生することにもなりかねません。そのため、機能要件とそれを実現するための非機能要件はセットで考えるようにしましょう。

ポイント

  • 要件をすべて取り込むのは無理、QCD(品質・コスト・納期)を考えてスコープを設定しよう。
  • 機能要件と非機能要件は常にセットで考えるべし。