”もう失敗しない”
プロジェクトマネジメント講座
失敗プロジェクトからの脱出
第4回：要求リスク最小化に向けて
アクセンチュア株式会社
通信・ハイテク産業本部
パートナー
冨永 孝
曖昧な要求仕様がもたらす負の連鎖とそれを断ち切るためにシステム部門にできることを前回述べた。今回は開発ベンダーの立場に立った時に注意すべき点と、改善に向けたロードマップを示す。
業務ニーズを理解する
前回、システム開発のインプットとなる業務ニーズや要求を特定することは依頼者の役割であると述べたが、依頼者が常に適切に要求を特定できるわけではない。特に、要求として依頼者がソフトウェアの機能を指定してきた場合には注意が必要である。なぜなら、その機能が必要となった業務背景やニーズを明確にせずに設計作業を進めていくと、業務ニーズを満たすためにソフトウェアの機能が実装されることを忘れてしまい、価値のない仕様や枝葉の仕様について無用な追加・変更の依頼が出されるリスクが高まるからである。
図1 要求と仕様と機能の関係
図１で示すように、全ての仕様が投資対効果を測定できるような粒度の要求から抽出され、その紐付け関係を明確にすることは良いプラクティスである。つまり、その仕様が実現することで抽出元の要求が満たされる関係となっているのか、投資対効果の向上に寄与しているのか、という視点で議論できるので、無価値な仕様や変更依頼の検討に貴重な時間が浪費されることを防ぐことができるであろう。
非機能要求を明文化する
要求の仕様化作業において、ソフトウェア機能の要求仕様が分析の中心になる。しかし、非機能要求を仕様化することもまた同様に重要なことである。非機能要求とは次のようなものがある。
- 性能要求（レスポンスタイム、スループットなど）
- 品質特性（可用性、保守性、ユーザビリティなど）
- プロジェクト制約（法規制による制約、市場による制約、システム起因の制約など）
システムのライフサイクルを考えた場合、初期構築に要する期間は、その後の運用保守フェーズの期間と比較すると非常に短いものである。つまり、プロジェクトの成功を論じる時に、初期構築を無事に行えることだけでは全く不十分で、保守運用フェーズにおけるシステムの評価こそが成否を決めていると言える。この保守運用フェーズにおける評価を大きく左右するのが非機能要求に関する仕様なのである。
「非機能要求なら“無停止であること”、“保守性が高いこと”といったようにキチンと明文化しているよ」と思われる方も多いかもしれない。しかし、「仕様は検証可能であるべき」という前提を思い出して欲しい。「無停止であること」という要求は検証可能なシステムの仕様にまで展開できていると言えるであろうか。開発ベンダーは当然何らかの前提条件付の「無停止」と認識しているかもしれないし、依頼者は別の理解かもしれない。これでは検証可能であるとは言えない。
非機能要求もスコーピング対象
非機能要求も機能と同様に当然スコーピングの対象となる。
スコーピングの検討ではシステム機能の仕様が議論の中心となるのは止むを得ないが、非機能要求も同様に議論すべきである。なぜならば、前述したように運用保守フェーズで重要であるという理由の他に、非機能要求が変更されると、アーキテクチャなどに大幅な変更が発生し、プロジェクト規模に著しく影響する可能性があるからである。
機能要求のみでスコーピングを議論するのは危険なことである。
要求開発/要求管理ベストプラクティスへのステップアップ
仕様を業務ニーズである要求から展開すること、非機能要求も機能要求と同等に検証可能なレベルに仕様化しスコーピングの対象とすべきことを述べた。
では、これらの要求開発プロセスを改善しようと思った時、何から着手するのが良いのであろうか。要件開発プロセス、要件管理プロセスはそれぞれCMMIレベル3、レベル2のPA（プロセスエリア）の一つであるが、残念ながら大きな示唆を与えてはくれない。まずは現場の抵抗や負荷が小さく、効果が実感できることから始めると良いであろう。図２にプロセスとスキルという二つの軸で改善を進めるロードマップを示した。
図2 ベストプラクティスへのロードマップ
特に、要求仕様を作成するスキルが十分でない組織に対して、要求管理プロセスのみを導入しようとすると頻繁な変更依頼が発生し、管理工数ばかりが発生してしまう。要求仕様開発スキルの学習曲線を考慮しないと、プロジェクト全体の生産性が著しく低下することになるので、あくまでプロセスとスキルが両輪となっていることを忘れてはいけない。
◆◆◆
４回に渡り、システム開発プロジェクトにおける最大のリスクであり失敗要因となる曖昧な要求仕様の問題点とその対応を述べてきた。要求仕様の重要性を再認識していただきプロジェクト管理の現場で役立てていただければ幸いである。