「カネ」にまつわるリスクファクター：超現場主義！ 失敗しないITプロジェクトマネジメント（4）

[玉木栄三郎, 須永啓太 ，＠IT]

第2回「ユーザー企業側プロジェクトマネージャの勘違い」、第3回「アーキテクチャ選定のコツは『少し先を見ること』」ではそれぞれ「ヒト」「モノ」というカテゴリでプロジェクトに発生するリスクファクターとその対処法について紹介してきた。発注者側が、プロジェクトが失敗に終わったと判断する状況はいくつもあるが、その中で最も端的に数値で提示される場面は「カネ」である。プロジェクト運営が予算どおり進まず、機能追加や、開発期間の延長を経験した人も多いと思う。今回は「カネ」にまつわるリスクファクターとマネジメント方法について、いつものように具体的事例を挙げながら紹介する。

ITプロジェクトの現場でよくある風景

発注者側PM　「どうして提案していただいたときと金額がこんなに違うわけ？ あらかじめRFP（Request for Proposal）に載せていたでしょう」

開発者側PM　「はい。あらかじめ機能として認識していましたが、要件定義の段階で、弊社より提案させていただいた機能よりも複雑な機能であると判明しました」

発注者側PM　「そんなのお宅の会社が想定してないのが悪いんじゃない。もう予算ないし、困りますね」

開発者側PM　「しかし、われわれとしても、追加で開発者をアサインしないと、想定されている納期に間に合いません。ご対応をお願いできないでしょうか？」

発注者側PM　「納期と予算は変えられないよ。そっちで調整してよ」

開発者側PMの心の叫び　（この機能以外にも、ほとんどが要件定義の段階でRFPと乖離（かいり）してるんだよなー。発注はあらかじめ要件定義と開発以降で分けるようにリスク管理しておいたし。ここはプロジェクト撤退も視野に入れながら交渉しないと……）

　発注側のプロジェクトマネージャにとってすでにRFPは一般的なものだろう。書店には専門の書籍や雑誌が並び、Webでも情報が手に入る。しかし、それらの情報の中には、RFPの本来の意味や機能をきちんと紹介していないものも多い。例えば、A4サイズの紙一1枚に、プロジェクトの「概要」「開発予算」「スケジュール」「プレゼンの候補日程」が書かれたRFPを見たことがないだろうか？

RFPを書く目的

　今回の事件は、精度が低いRFPに対して、開発会社が俗にいう「ザックリ」とした見積もりを提示し、それを発注者側プロジェクトマネージャが発注予算として確保してしまったために起こった、所謂（いわゆる）よくあるケースである。このようなリスクを避けるには、開発者側が、詳細な見積もりを作成できるレベルの精度のRFPを用意するか、開発者側との要件定義を、プロジェクトにおける真のRFP作成ととらえ、フェイズを分けて発注予算を2つに分けるかである。

　RFPは、発注者側と開発側でより多くの「合意」を得るための手段である。ハードウェアやソフトウェア、保守など、発注者側が想定していることを伝え、プロジェクト開始時からできるだけ発注者側と開発者側のズレを少なくし、後戻りの利かないような開発フェイズでのプロジェクトの混乱を避けるために作られるものである。ペラ1枚で書かれたRFPで得られる「合意」では、プロジェクトのリスクを減らすことはほとんど期待できない。

開発者側とRFPを書くこと

　RFPを構成するために必要な要素項目は、書籍や雑誌などで語り尽くされた感があるので詳しくは触れないが、一応、必要最低限の項目を列記しておく。

1. システムの概要と目的
2. システム機能一覧
3. ソフトウェア必要条件
4. ハードウェア必要条件
5. 保守に関するサービスレベル
6. 想定予算
7. 想定納期
8. 契約条件

　ハードウェア要件やソフトウェアの機能要件など、前回の連載で触れたような「モノ」にまつわる要件は、その要件が本当に正しいのか発注者側でまとめる自信がない、もしくはまとめる時間が割けないというのも発注者側にとっては本音かもしれない。

　このような発注者側のプロジェクトマネージャには、ぜひとも開発者側と共同でRFPを書く要件定義の前段階、つまり要件整理のフェイズを持っていただきたいと考える。

　当然、開発者側がRFPの作成にかかわることにより、プロジェクトに起こり得る発注者側と開発者側の認識のズレは非常に少なくなるとともに、成果物として作成されたRFPを使用して、他社の開発会社の見積もりを取ることにより、発注しようとしている開発会社の見積もりが妥当であるかどうかを判断することにも活用できるのである。

RFPは銀の弾丸か？

　ではRFPがプロジェクト成功のための銀の弾丸なのだろうか？ RFPはプロジェクトの初期要件において、発注側と開発側のズレを回避するのに有効な手段なのだが、今日のプロジェクトの要件は、必ずしも初期の段階とは一致しない。このことは読者の皆さんもご存じのとおりである。

　プロジェクトの要件は、常にプロジェクト外の情勢に左右され、要件の追加や変更は当たり前のことである。機能変更もしくは追加が行われそうなものをRFP作成の段階であらかじめ認識する、そのリスクをプロジェクトマネージャ自身があらかじめ認識し、リスクマネジメントをする必要があるのである。

---

　RFPはプロジェクトの初期段階における発注者側、開発者側のシステム合意をするうえで、非常に有効な手段である。しかし、RFPを使用して、ただシステムを具体化するだけでなく、作成の中で要件に変更が伴う可能性が高いもの、要件に変更が発生した場合、大きくスケジュールや予算に影響を与える機能を抽出する必要がある。

　発注者側プロジェクトマネージャは、RFPとそれらのリスクとなり得る事象を分析して、リスクを吸収し得るだけの妥当な予算とスケジュールを作成することが必要である。

　いままで、「ヒト」「モノ」「カネ」という切り口で、それぞれのリスクファクターとリスクマネジメントの方法について述べてきた。次回は連載の最後として、失敗をしないプロジェクトマネジメント手法を総括し、発注者側のプロジェクトマネージャの皆さまがプロジェクト管理を行ううえで、少しでも役に立つ手法を紹介していきたいと考えている。最後までお付き合いいただきたい。