ホーム >  特別連載企画：”もう失敗しない”プロジェクトマネジメント講座 >  2005年10月号 >  第２回：手戻りを防ぐスコーピング

”もう失敗しない”
プロジェクトマネジメント講座

失敗プロジェクトからの脱出

第２回：手戻りを防ぐスコーピング

成功プロジェクトとは

システム開発における「成功」とは、ユーザーが求める機能を満足できる品質（Quality）で、同意された予算（Cost）で、決められた期日（Delivery）までに提供することであると、一般には言われている。

しかし、日経コンピュータ誌の「プロジェクト実態調査」（2003 年11 月17 日号）によれば、システム開発プロジェクトでQCDの全てを予定通り満たしたのは26.7%に過ぎないということである。

ITがビジネスのエネイブラーとなった今日、システムが経営、更には社会に及ぼす影響を考えると大変な損失であると言える。

開発の現場では

昨今のシステム開発プロジェクトにおいては、厳しく選別されるIT予算、経営を取り巻く外部環境の急速な変化に伴う納期短縮化など、予算および期間の点で、プロジェクト開始時点から非常に厳しい制約を受けている。

また、これらの厳しい制約を乗り越えて無事にデリバリーした後においても、業務ニーズを満たせていない、性能が十分ではないなどの品質に起因する欠陥により、現場から頻発される改善要望に対して応えていく必要がある。しかも、戦略的IT投資の掛け声の下、絞られた保守予算で、なおかつ、経営層からの厳しい投資対効果に対する要望にも応えていかなくてはならない。

このようにトレードオフの関係にあるQCDのバランスを取ることは難しく、日々奮闘されているマネージャーが非常に多いのではないだろうか。

「スコーピング」再考

CMMIのようなプロセス改善に取り込むことも重要であるが、まずはシステム開発の根本に立ち返り、プロジェクトの「スコーピング」をきちんと行うことを再認識してはどうだろうか。「スコーピング」とは、プロジェクトが対象とする範囲を規定することであるが、プロジェクトの予算や期間に見合った規模にスコープを限ることは、一見、基本的で当たり前の作業のように思えて実際には色々な困難がある。

プロジェクト開始時にスコープについて依頼者と開発ベンダー間で同意したつもりになっていても、設計作業やコーディング作業をしながら仕様の確認をユーザーに対して行っていくと隠れた要望がどんどん出てきて、気付いたら予算も期間も変わらないのに規模だけが２倍になっていた、などという経験を持っている方も多いと思う。なぜこのようにスコーピングしたつもりがプロジェクトの後続フェーズで規模が爆発してしまうかというと、要求の特定とその仕様化が不十分であることが原因であることが多いようだ。

経済産業省が組込みソフトウェアについて調査した資料によると、開発案件の86 ％程度で手戻りが発生し、その理由を３つ挙げる質問に対して、「要求仕様の不備」を第１の理由と回答したケースが30 ％程度で最も多く、「仕様書の不備」も合わせ要求仕様に関する不備を理由として挙げているのは約50％となる。これは件数ベースの割合であるので、要求仕様不備起因の手戻りで浪費される工数が全体開発工数に占める割合は更に大きいと思われる。

要求仕様に対する心理

要求仕様の抽出が十分終わっていない、重要なユーザーグループに対するインタビューが完了していない、ユーザーに言われた機能要求の背景にある業務的なニーズの調査が完了していない、など要求仕様開発が完了していない状態であっても、設計、開発へと突入してしまう場合が、多々あるであろう。特にスケジュールがタイトである場合には開発ベンダー側に相当な心理的な圧力がかかり、要求仕様がいい加減であっても、実装作業へと進みたい衝動に駆られる。プロジェクトマネージャーもプログラマーの「早くコーディングを始めないと到底期日までに間に合いません」という声に押されて実装作業に突入してしまいがちである。実装作業が進捗するとプロジェクトが進んだような気にはなるが、実際には設計やコーディング段階でユーザーに仕様を確認してみると、ユーザーが「常識」と考えている暗黙の仕様や、大前提が発見され、とんでもないスコープリークが起きることになるのである。

曖昧な要求のメリット？

スコーピングの重要性は理解できるが、要求は曖昧なままの方がやり易いと思われている依頼者も多いかもしれない。

• エンドユーザーから新たな要求や変更要望が挙がるのは確実だ。
• 開発ベンダーから仕様変更として追加請求される恐れがあるので「行間」の解釈の余地を残しておこう。

依頼者側に、要求の仕様化という観点でスキル構築が行われていない上、上記のような事情があると、ますます要求仕様がないがしろとなってしまう。しかし、実際には「行間の解釈」を巡り不毛な駆け引きが行われ、ステークホルダー間の信頼関係が崩壊する、プロジェクトメンバーのモチベーションが低下するなど、コスト面以外についてもプロジェクトリスクの大きさは計り知れない。

◆◆◆

今回は、プロジェクト成功の鍵となるスコーピングと、スコーピングで失敗する大きな要因である曖昧な要求仕様について述べた。次回は、曖昧な要求仕様がもたらす負の連鎖と、この連鎖を断ち切るために、依頼者と開発ベンダーができることをそれぞれの立場から見ていく。