経営部門代表：そんな大所帯でやるんですか？ スケジュール調整も大変だし、最終要件定義レビューも通常のプロジェクト会議メンバーだけでやればいいんじゃないですか？
千石君：はい。確かにその方がスケジュール調整は容易ですが、プロジェクトを効率的に進めるために、合同レビューにしたいのです。また、過去のシステムトラブルの記録の中に、以下のような事例が何件もあったんです。
- 過去におけるシステムトラブル（の氷山の一角）
- 要件定義文書の記載内容を設計者が誤解。誰も確認しないまま設計を継続
⇒テスト段階になって不具合が多数見つかり、修正が大変だった - システム運用時のオペレーションを要件としてほとんど考慮していなかった
⇒操作性が悪く誤操作が頻発。システムが時々停止した
こういったことが起きないように、このプロジェクトでは、合同レビューを対面で進めます。業務要件実装上の理解を深めていただくとともに、システム要件を再確認します。ご協力ください。
経営部門代表：わかりました。やりましょう。
千石君：みなさん、よろしくお願いします。
全員：お願いします。
＊＊＊＊＊
かくして千石君は、（巣鴨課長を介して）プロジェクト会議で合意されたシステム開発の修正案を経営会議に付議しました。一部役員から厳しい意見が出たものの、投資効果測定の仕組み導入の提案が高く評価され、めでたく了承されました。
また、要件定義文書の合同レビューも、表現上の分かりにくさをいくつか指摘されたものの大きな問題はなく、無事終了しました。こうして千石君は、巣鴨課長に要件定義文書の最終承認を依頼しました。
＊＊＊＊＊
巣鴨課長：千石君、この要件定義文書で問題ないと思うよ。先に進めたまえ。今回の要件定義では、多くのステークホルダーからの要求を調整してよくまとめたね、ご苦労さん。
千石君：すべては課長のご支援があったからです。ありがとうございました。
巣鴨課長：いやいや、君の実力だよ。私は千石君の緻密な行動力と調整能力を評価している。ただ、これからもプロジェクトは続くので、気を抜かないように頑張ってくれ。
ところで、今回の要件定義フェーズを振り返って、新たな気付きや反省点などがあれば、今後のために記録しておくといい。自分のためだけではなく、後進にも役立てられるからね。
千石君：はい。実は、このプロジェクト開始時にわが社の「システム開発標準」や、IPA/SECが提供している「ユーザのための要件定義ガイド」を読んで勉強し、当初はそれらで説明されていた要件定義文書をパクろうとしていたんですが…。
巣鴨課長：誰がステマしろと言った。
千石君：失礼しました。しかし、要件定義を進めるうちに、初めのうちは漠然としていた要求が徐々に明確になっていったり、部門間で議論を進めるうちに要求の内容が進化していったりして、作成中の要件定義文書の修正に追われるようになりました。
そこで気付いたのは、要件定義文書にはその目的に応じて大きく2種類があるということです。
巣鴨課長：というのは？
千石君：つまり、要件定義プロセスで作成する文書には、以下の2種類があり、目的に応じて適切なドキュメントを使用することが重要であるということです。
- 各ステークホルダーからの要求についての関係者の理解を助け、要求間の調整や要件化などを効率よく行うためのもの
- 定義した要件を漏れなく正確に表し、設計者が正しく理解するためのもの
