要件定義後の設計・開発工程でも発注者の主体的関与は不可欠【第5回】

開発工程に入っても開発ベンダーへの“任せきり”は厳禁

　設計が完了すると、いよいよ開発工程、すなわちプログラミング作業に進みます。開発ベンダーのエンジニアが、基本設計や詳細設計で定義された要求を具現化していきます。ここでは、作成したプログラムの最小単位であるモジュールなどが設計通りに動作するかどうかを確認する「単体テスト」も並行して実施します。これらは基本的に開発ベンダーが実施する作業です。

成果物や進捗や定期的に確認し修正が必要な箇所を早期に見つける

　設計工程や開発工程では、開発ベンダーは、要件定義書に基づき設計書やテスト計画書などの多くの成果物（ドキュメント）を作成します。発注者には、提出された成果物を詳細にレビューする責任があります。レビューの主な目的は、要件定義で合意した内容との相違がないか、そしてプロジェクトの実現が技術的・ビジネス的に可能であるかの確認です。

　発注者にすれば成果物が「どのような体裁で、どのような内容でまとめられるのか」に関心があるでしょう。初めて開発ベンダーに発注した際などは、レビューの進め方やアウトプットに戸惑うことも少なくありません。そうした場合は、不明点や事前に調整したい事項を率直に開発ベンダーに伝えることが、後の手戻りを防ぐ上で極めて重要です。

　開発ベンダーは一般に、これまでの開発経験から標準的な成果物フォーマットを持っています。プロジェクトを円滑に進めるためには、このフォーマットのすり合わせが不可欠です。

　その際も、単に形式を合わせるだけでなく、成果物の一つひとつが「どのような工程で、なぜ必要なのか」という背景についても十分に議論を交わし、共通のイメージを持つことが極めて重要です。これにより、成果物が単なる形式的な書類に留まらず、プロジェクトの品質と方向性を保証するための意味のあるドキュメントとして機能するようになります。

　設計・開発工程は、開発ベンダーへの“丸投げ”では決して成功しません。プロジェクトの進捗と成果物の質を向上させる鍵は、発注者の積極的なコミュニケーションと当事者意識にあります。

　特に、プロジェクトに遅延が見え始めた際、まずその原因が発注者によるレビューの遅れや必要な情報の提供の遅れなどによっていないかを確認することが重要です。もし発注者側に原因があれば、開発ベンダーへの協力を惜しまず迅速な対応を心掛けることで、遅れを最小限に抑えることにつながります。素早い対応こそが、遅延の予防において決定的な役割を果たします。

　一方、質の高い成果物を実現するためには、発注者と開発ベンダーが共に責任を持つという意識が不可欠です。開発途中の成果物であっても定期的に確認することで、軌道修正が必要な部分を早期に発見し、手戻りを未然に防げます。

　プロジェクトの根幹である要件定義を終えた後も、設計・開発工程における発注者の積極的な関わりや協力は、プロジェクト成功の“生命線”です。発注者が主体的に関与し「自分たちもプロジェクトチームの一員である」との意識を持ち続けることこそが、プロジェクトの成功を確実にするのです。