システム化範囲がぶれていれば失敗する：プロジェクトはなぜ失敗するのか（1）
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。
プロジェクトの失敗例で多いのは
プロジェクトの失敗で、一番多いのはシステム化範囲（スコープ）がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである。
このようなプロジェクトは昔から後を絶たないのであるが、その対策が十分に取れているとは思えない。今回は、このシステム化範囲がぶれる問題を考えていきたい。
プロジェクトはなぜ失敗するのか 各回のインデックス
第1回 システム化範囲がぶれていれば失敗する
なぜ、システム化範囲はぶれるのか
システム化範囲がぶれる理由はいろいろあるが、その代表的なものを挙げてみる。
（1）「ｘｘシステム一式」という契約書は意味があるのか
そもそもシステム化範囲は明確になっているのであろうか。最近私が関与した会社で、ベンダから送られてきた契約書を見せてもらったが、そこに記載された委託内容は「生産管理システム一式」という文言が1行書かれているだけであった（図1。この契約書は、一体どういう意味を持っているのであろう。確かに金額や一般的な責任は確定できている。しかし、その金額で作成する機能の一覧や帳票などの一覧もないのである。
ここまでひどいケースでなくても、機能の詳細は「提案書に記載のとおりとする」という類（たぐい）の契約書は多い。
ここで、提案書というのはどの提案書のことを指すのか。もしかしたら、何回か提案書を出し直している可能性も高い。その場合は、一番機能範囲の広い提案書を顧客は想定するのに対し、ベンダ側は最後に提出した機能を絞った提案書を想定するのかもしれない。
（2）なぜ要件定義前に見積もれるのか
要件定義からシステムテストまで一括で請け負う契約書もまだまだ多い。しかし、要件が固まっていないのに、なぜ、見積もりができるのであろう。要件が未定ということは、機能数、帳票数、画面数、どれを取っても変動する可能性が高いはずである。
もし、要件定義で想定していたファンクションポイントが倍になれば、要件定義以降のすべての工程が倍になってくる。こんなリスクの大きい契約をなぜ結ぶのであろうか。
要件定義は、本来は発注側の責任で行うべきものである。どういうシステムにしたいかをベンダに任せきりにすることは本来おかしいのである。たとえ、ベンダに依頼したとしても、最後の意思決定は発注側が行うべきである。
経済産業省の「『情報システム信頼性向上のための取引慣行・契約に関する研究会』最終報告書〜情報システム・モデル取引・契約書〜の公表について」でも、要件定義フェイズは委任契約にして、最終的にはユーザー責任で行うべきだと述べている。これは、本質的に正論である。本来、要件定義をベンダ任せにするというのはおかしな話であり、手伝ってもらうにしても最後は自社の責任で意思決定をしなければならないのが要件定義である。
（3）要件の確定は誰が責任を持つのか
もう1つ大きな問題は、要件を確定する責任者が明確になっていない点である。担当者と一生懸命要件を確定して、開発を行いテスト段階に入ったところで、経営者がその内容を見て、「こんなシステムを頼んだ覚えはない」などといい出すこともある。
多くの場合、ここで担当者と取り決めたことを説明しても無駄である。「契約の責任者は私だ」と経営者に主張されると、なかなか対抗することが難しくなる。しょうがなく、経営者の要望を追加で聞くことになり、大幅なコスト増加が発生することになる。
このようにシステム化範囲が明確に押さえられていないと、顧客からのむちゃな要望に対しても、的確に反論できなくなる。後になって、「営業のXXさんは、これもできるといっていた」などの営業トークを持ち出されて、要件を追加されたらプロジェクトマネージャはたまったものではない。
システム化範囲を明確にする方策
システム化範囲が膨らんでいくことを防ぐ方法はいくつかあるが、まずは契約で押さえられるところは押さえておくことが重要である。
（1）要件定義が完了していない場合の契約
要件定義が確定していない段階では、そもそも一括の請負契約は結ぶべきではない。こんなむちゃなことをやっていたら、赤字プロジェクトがなくなるはずがないのである。要件定義までは委任契約にしておき、この契約が完了してから、その後のフェイズを請負契約にすることが望ましい。
しかし、現実は一括の契約をしなければならない場合も多い。この場合の対応は2つである。1つは、リスク分を上乗せした金額で契約することである。PMBOKによれば、このような見積もりは「超概算見積もり」と呼ばれ、その精度は−50％〜＋100％と書かれている。従って、見積もった金額は、最大100％のブレが生じることになる。契約としては、この上限の100％アップで契約をしておけばよいことになる。
しかし、すぐに反論がくるのは、そんなに金額で見積もりをしたら、仕事が取れないではないかということであろう。正しくは、こんなリスクが高い仕事はそもそも取らなくてよいのである。ただし、現実には営業サイドの理由により、多少無理をしても受注を取ることは多い。
この場合には、請け負った作業を要件定義フェイズとその後のフェイズに分けて、要件定義終了時に再度見積価格を見直す権利を契約で留保しておくことが必要である。
（2）契約書に記載するシステム化範囲
システム化範囲は契約書に記載すべきであるが、その記載もかなりいいかげんなものが多い。「○○システム一式」などという契約書は論外であるが、ここまでひどくなくても、簡単な機能一覧を添付することで済ましている契約書も多い。これでは、システム化範囲でもめたときに自己を守ることはできない。要件定義が完了しているのであれば、契約書にシステム化範囲は要件定義書に基づいて作業を行うことを明記しておくことが重要である。このとき、要件定義書の版や作成日付を明確にしておかなければならない。
それでは、要件定義書がまだ完成していない段階での契約はどうしたらよいのであろうか。この場合には、営業段階で提出した提案書や見積書を根拠にすることになる。この場合も作成日付などを明確にしておく必要がある。もう1つ大事なことは、これらの提案書や見積書が根拠になるのは、要件定義フェイズまでであることを明確にしておくことである。提案書にはそれほど詳細な内容を記述していない場合が多いので、いつまでもこの提案書を引きずっているとろくなことはない。要件定義書が完成したら、その後の開発範囲は要件定義書のみに基づくことも契約に明記しておくことが重要である。
（3）要件の確定責任者の明記
要件を決定する人が誰であるかを契約書に明記しておくことも非常に重要である。このときに注意が必要なのは、この決定の期限を明記しておくことである。このように責任を明確にしておくと、その責任者はその決定に関して慎重になる可能性が高い。その結果、要件の確定が遅れれば、全体の進ちょくが遅れてしまうことになる。これを防ぐために、要件の決定期限を明確にしておけばよい。例えば、要件を提示してから10日経過しても要件の確定について回答がなければ、要件は自動的に確定するという条項も契約書に入れておくのである。
このように、契約書をしっかり作成しておくことで、システム化範囲の確定に絡むいくつかの問題は回避できる。従って、契約書の作成を営業に任せきりにするのではなく、プロジェクトマネージャも積極的に関与していくべきである。
著者プロフィール
落合和雄
1953年生まれ。1977年東京大学卒業後、新日鉄情報通信システム（現新日鉄ソリューションズ）などを経て、現在経営コンサルタント、システムコンサルタント、税理士として活動中。経営計画立案、企業再建などの経営指導、プロジェクトマネジメント、システム監査などのIT関係を中心に、コンサルティング・講演・執筆など、幅広い活動を展開している。主な著書に、『ITエンジニアのための【法律】がわかる本』（翔泳社）、『実践ナビゲーション経営』（同友館）、『情報処理教科書システム監査技術者』（翔泳社）などがある。そのほか、PMI公式認定のネットラーニングのeラーニング講座「ITプロジェクト・マネジメント」「PMBOK第3版要説」の執筆・監修も手掛けている。
Copyright © ITmedia, Inc. All Rights Reserved.