”もう失敗しない”
プロジェクトマネジメント講座
失敗プロジェクトからの脱出
第3回：要求仕様の負の連鎖を断ち切る
アクセンチュア株式会社
通信・ハイテク産業本部
パートナー
冨永 孝
要求仕様から始まる負の連鎖
図1 曖昧な要求仕様がもたらす負の連鎖
曖昧で不安定な要求仕様はプロジェクトの成否に影響を及ぼすだけではなく、依頼者と開発ベンダー、エンドユーザーに深刻な負の連鎖をもたらす。
非常にシンプルに見えるユーザーの要望であっても、明確で正確な仕様に落とし込めない限り、開発見積を精緻に行うことは出来ない。正確な見積がないまま、期日を優先して見切発車で設計、コーディングへと進めてしまうと、後続フェーズで仕様変更が頻発し、場合によってはアーキテクチャ変更などもあり得、プロジェクトが混乱するリスクが非常に高まる。さらに、この仕様変更のために、スコープの再定義が必要になり、一部の仕様については見送られるか、スコープも期日も変更せずに暗黙の内に品質を犠牲にしてプロジェクトが進行することとなる。また、当然、追加費用が発生するので、依頼者と開発ベンダー間でどちらがそれを負担するか泥仕合になるケースもあるであろう。
このような混乱を乗り越え、何とか本番稼動にまで漕ぎ着けたとしても、期日の遅れや、業務に必要な機能がない、使い勝手が悪い、トラブルが頻発するなど、ユーザーから不満が爆発し、その結果、システム改善要望が現場から頻発することになり、その対応にシステム部門も手一杯となってしまう。さらに、改修が必要となった場合に、開発時に追加請求できなかった開発ベンダーからその負担分を取り返すために高く保守費用を請求されることもあり得るので、保守費増大の一因となる。何れにせよシステム部門や開発ベンダーへの不信感がユーザー側に募り、次のシステム開発時においても十分な協力を得ることが出来なくなり、その結果、前回同様に要求開発プロセスが改善することなく同じ負の連鎖が続くことになる。
負の連鎖を断ち切るためにシステム部門ができること
この負の連鎖を断ち切るためには、後続フェーズにおける仕様変更を管理可能なレベルにまで抑えることはもちろん重要であるが、システム開発の根幹である要求開発プロセスにメスを入れていくことが結局は早道であり、要求管理と要求開発を両輪とした改善サイクルを回していくことがプロジェクトマネージャーの急務と言えるだろう。
まず、要求開発であるが、依頼者が高品質な要求仕様を開発ベンダーに渡せなくなっている現状がある。
（出典）ユーザ企業I T動向調査 調査概要報告書 JUAS 平成15年12月
図2 要求仕様書作成の開発ベンダーへの依存
図2は、JUASの「ユーザ企業IT動向調査 調査概要報告書」（平成15年12月）から引用したものであるが、要求仕様の作成を開発ベンダーに依存している様子が伺える。これはシステム部門の機能の外部委託化とも解釈できるが、実態は要求仕様を纏めるだけの人員とスキルが欠如していることの現れであろう。
要求開発スキルを持った人員を維持し続けることが、全てのケースにおいて妥当であるとは言えないが、要求仕様に対するガバナンスは依頼者が握っていなくてはいけない。
まずは、依頼者と開発ベンダーで 役割を明確に規定することが重要である。図３で一般的な開発フェーズを示しているが、要求開発の実作業を誰が行うかは別として、以下の点については最低限依頼者の役割であると認識すべきであろう。
- 要求開発のインプットとなる要求（業務ニーズ）の特定、文書化、優先順位の付与
- 全ての要求が仕様化されており、抽出された仕様が実装された場合に抽出元の要求が満たされていることの確認
- 要求仕様をベースライン化しステークホルダー間で共有され合意されていることの確認
図3 開発プロセスにおける依頼者側の役割
（クリックして拡大）
また、要求仕様がベースライン化されると、要求管理が必要となるが、以下の点も依頼者の作業である。
- 要求仕様に対する変更の適用可否の判断
- 変更が各種文書へ反映されたことの監査
さらに、承認された変更を含む仕様が検証可能でありテストフェーズのインプットとなり、検証されたことの確認も依頼者の重要な作業と認識すべきであろう。
学習曲線による落ち込みを乗り越える
要求開発および要求管理がプロセスとして定着していない組織に対してプロセス改善を進めることは、依頼者にとっても非常に困難で、煩雑なことである。今まで、開発ベンダーのプログラマーに口頭で伝えれば良かったものが変更管理委員会などの場で一つ一つ審査するように変わるのであるから止むを得ない。しかし、この一時的な生産性の低下、現場の抵抗を前に改善を諦めてはいけない。要求開発と管理を両輪としてプロセス改善を進めて行けば必ず果実を得ることが出来るであろう。