コラムカテゴリー：プロジェクトマネジメント
2018年の日経コンピュータの「ITプロジェクト実態調査 2018」によると、システム開発プロジェクトの成功率は52.8%です。
システム開発のコストを考えると、決して楽観できる割合ではありません。
同調査では成功の定義を、スケジュール・コスト・満足度の3条件を満たすプロジェクトとしていて、各条件の失敗の理由も調査しています。
以下は、各条件で最も多い失敗理由です。
・計画よりも遅延した理由：システムの仕様変更が相次いだため
・コストが超過した理由：追加の開発作業が発生したため
・当初の計画通りにシステムが利用されていない理由：要件定義が不十分だったため
要件定義が不十分だと、システムの仕様変更や追加の開発作業が発生する可能性を高めるため、システム開発プロジェクトを成功に導くためには、要件定義を十分に行う必要があります。
では、どうすれば要件定義を十分に行い、スケジュール遅延、コスト超過、品質不良といったリスクを下げることができるでしょうか。
要件定義で混入した欠陥を検出する手段は、要件定義書のレビュー又は要件定義に対応したテスト(受入テスト又はシステムテスト)です。
受入テストやシステムテストで重大な欠陥を検出したのでは、スケジュールは遅延しコストも超過するでしょう。
最悪、受入テストで要件の認識齟齬が明らかになった場合、それまでのコストが全て無駄になる可能性もあります。
そのため、要件定義書のレビューによって重大な欠陥を検出することが重要です。
弊社コラム「レビューの目的は承認ではない！」でレビューポイントを記載しています。
考え方は変わらず、「レビューの目的の定義」と「レビューシナリオやチェックシートを作成する」ことが重要です。
上記の考え方に沿った要件定義書のレビューポイントの例は以下になります。
・レビューの目的：発注者が提示した要件の抜け漏れを検出し是正する
・レビューシナリオ：要件定義書に記載されている機能に漏れがないか業務フローと比較する
上記2つにチェックリスト(テストの期待値と正誤欄)を加えれば、受入テスト仕様書を作成するのと、ほぼ同義です。
つまり、要件定義書のレビュー効果を高めるには、受入テストで実施予定のテスト仕様書を作成することが非常に有効な手段と考えます。
受入テストの実施までにテスト仕様書は必要なため、要件定義で作成しても、プロジェクト全体の工数に変動はありません。
工数に変動なくレビューが具体的になり、重大な欠陥を早期に検出できる可能性が高まるため、是非実践していただきたいのですが、スケジュールに考慮すべきポイントがあります。
それは、要件定義終了後のベンダー開発期間に並行して受入テスト仕様書を作成していた期間です。
従来通り、要件定義終了後に受入テスト仕様書を作成すると、その期間分がスケジュールに追加されます。
そのため、ベンダーの要件定義書作成中など、従来の要件定義期間内で受入テスト仕様書を作成するようにプロジェクトを計画することで、スケジュールも変わらなくなります。
要件定義をベンダー任せにすると、プロジェクトが失敗するリスクが高まります。
本コラムを参考に効果的な要件定義書のレビューを実践し、プロジェクトを成功に導いてください。
＜日経コンピュータ ITプロジェクト実態調査 2018＞
https://xtech.nikkei.com/atcl/nxt/column/18/00177/
2021年11月08日 (月)
青山システムコンサルティング株式会社
