記事一覧に戻る
RFPの終わりとスコープの始まり — カネを巡る現代の戦い方

RFPの終わりとスコープの始まり — カネを巡る現代の戦い方

ZenChAIne·
projectmanagementbusinessrfpproduct

はじめに

「ヒト」が動き、「モノ(技術)」が決まった。最後に向き合わなければならないのが「カネ」——予算とスコープの冷徹な現実です。

20年前、プロジェクトが炎上する最大の導火線は「曖昧なRFP(提案依頼書)」でした。ユーザー企業が数枚の紙で「こんな感じのシステムを作って」と依頼し、ベンダーは行間を勝手な想像で埋めて見積もりを出す。この瞬間から、ボタンの掛け違いは始まっていました。

驚くべきことに、20年経った今もこの構図の根本は変わっていません。しかし、現場の戦い方には大きな進化があります。

本記事は、Zenn連載「超現場主義!失敗しないITプロジェクトマネジメント Remake」第4回・第5回のエッセンスを、現代の実践フレームワークとして再構成したものです。

20年変わらない「一括見積もり」の呪縛

企業が数億、数十億という投資を決める際、「やってみないとわかりません」は通用しません。結果として現代になっても、不確実な未来に対して「精緻な見積もり」という嘘をつき続けなければならない構造的な矛盾を抱えています。

特に大型プロジェクトでは、いまだに「詳細なRFPをベースに提案書と見積もりを出せ」という要求が、企業のガバナンスや予算策定プロセスの都合上、厳然たる現実として残り続けています。

RFPは、今もなお強力な「儀式」として機能しているのです。

契約と実態の乖離を埋める3つの戦術

20年前は「RFP通りに作ること」が正解でした。今は「RFPに書いてあったことが、開発中に古くなる」ことが前提です。

現代のPMの戦いとは、「一括請負・固定予算」という古い殻の中で、いかに「適応型開発」を両立させるかという高度な曲芸です。

1. フェーズ分け契約(リスクの切り出し)

「要件定義・設計」と「開発・実装」を一括で契約するのは自殺行為です。不確実性が高い前半を準委任で切り出し、解像度が上がった状態で後半の契約を結ぶ。このステップだけで、見積もり精度とリスクのコントロール力は劇的に向上します。

2. バッファの戦略的活用(余白の合意)

見積もりにバッファを乗せることは「悪」ではありません。変化が前提の現代において、バッファは「品質を守り、変化に対応するための必須コスト」です。これを正直にクライアントに説明し合意を取り付ける交渉力こそ、PMの腕の見せ所です。

3. 検収の細分化(キャッシュフロー防衛)

ウォーターフォールの一括検収は、納期遅延がベンダーの死(入金遅れ・資金繰り悪化)に直結します。可能な限り動く成果物をこまめに確認・検収してもらうサイクルを作る。これにより、RFPの内容が陳腐化しても短いサイクルで見直しができ、最後の大爆発を防げます。

特に発注側が「PoCフェーズで成果が出なければ本開発に進まない」という段階的な投資判断(ゲート)を設けることが重要です。一度走り出したら止まれない「特攻」ではなく、フェーズごとに「続けるか、止めるか」を冷静に判断できる勇気。これが現代のリスクマネジメントの要です。

LLM製RFPという新たな罠

LLMの登場で、RFPに対するプロトタイピングのスピードは劇的に上がりました。数週間かかっていた要件の具体化が、数時間で終わる場面も珍しくありません。

しかし、「LLM製RFP」の新たな罠が生まれています。

クライアント側もAIを使ってRFPを書くようになった結果、一見すると非常に洗練された精度の高そうなRFPが出てくるようになりました。しかし精査すると、論理が破綻していたり、予算に対して非現実的なSLAやセキュリティ要件がしれっと盛り込まれていたりします。

「見た目が完璧」な分、20年前の「ペラペラのRFP」よりもある意味タチが悪い。鵜呑みにして見積もると予算が全く合わない金額を提案することになり、無理に予算に合わせるとプロジェクトは確実に死に至ります。

これからのPMに求められるのは「AIが書いたもっともらしいRFPの嘘を見抜き、固定予算の枠内でAIを駆使して早く価値を証明し、投資の優先順位を組み替える」という防衛的かつ実質的なスコープマネジメント能力です。

犠牲ではなく投資 — MVPの正しい理解

20年前、プロジェクトが危機に陥った時、PMに求められたのは「何を諦めるか」を冷徹に選ぶことでした。機能を削るのか、納期を延ばすのか、追加予算を毟り取るのか。それは「犠牲(Sacrifice)」と呼ぶべき、痛みを伴うネガティブな決断でした。

あれから20年。不確実性が常態化した現代において、このニュアンスは変わりました。何かを「犠牲」にすることは日常的な「選択」に昇華されたのです。

全部入りは何も目指していないのと同じ

「この機能を削ります」ではなく「この体験を最高にするために、今はここに全力を注ぎます」。この言い換えは単なる言葉のあやではなく、プロダクトマネジメントの本質的な進化です。

MVPは「手抜き」ではない

MVPとは単なる「未完成品」ではありません。私たちが信じる仮説を証明するために研ぎ澄まされた、鋭利な刃であるべきです。不必要な機能を削ぎ落とす決断は、ユーザーに「何を見てほしいのか」を明確にするための、最もクリエイティブな作業です。

決断の責任

AIは「平均的な正解」は教えてくれますが、際どい決断の責任は取ってくれません。膨大なデータの中から、最後は自分の直感と意志を信じて「こっちだ」と指を差す。その覚悟が、チームを動かします。

まとめ

20年前、RFPは「一通の手紙」でした。投函したら、返事を待つだけ。

現代、RFPは「対話のきっかけ」に過ぎません。

「どのボタンを置くか」ではなく「ユーザーの課題をどう解決するか」を共通のゴールにする。詳細な要件定義書を積み上げるよりも、GitHubのIssueやNotionで毎日「今、何に価値があるか」を対話し続ける。

カネを巡る戦いは、もはや契約書の上ではなく、チームの信頼関係の上で行われています。

20年前の現場で血を流しながら見つけ出した教訓を、現代の文脈に翻訳するとこうなります。

  • 致命傷を避け(Resilience) — フェーズ分けとバッファで身を守る
  • 早く失敗して学び(Fail Fast) — 検収細分化で短いサイクルを回す
  • 本当に大切な価値に賭ける(Focus) — MVPで仮説を研ぎ澄ます

これが、挑戦前提の時代のプロジェクトマネジメントです。

失敗前提から挑戦前提へ — ITプロジェクトマネジメント 20年の進化ウォーターフォールからアジャイルへ。20年で変わったこと、変わらないこと。zench-aine.io
AI時代、全員がPMになる — エンジニアの新しい生存戦略AIがコードを書く時代、エンジニアに求められるのは技術力ではなくPM的視点。zench-aine.io