戦略フェーズで完結する提案書は、もう半分しか機能しなくなってきました。生成 AI や kintone のようなツールが安価に手に入る時代、クライアントが本当に困っているのは「何をやるか」ではなく「どう動かし続けるか」という段階に移っています。にもかかわらず、提案書の構造は 10 年前のまま——AsIs / ToBe / ロードマップ / 体制図——という現場をよく見かけます。
本記事では、コンサルが実装に降りる時代において、提案書がどう変わるべきかを 4 つの観点から整理します。私たちが過去 3 年で関わった案件のうち、提案段階で運用設計まで踏み込めたものとそうでないものを比較しながら、構造の違いを言語化してみます。
提案書の役割は「やること」から「動かし続けるための設計図」へ
提案書の作法は、戦略レイヤーから実装・運用レイヤーへと降りていく流れの中で、構造そのものを変える必要があると考えています。具体的には、(1) ToBe と同じ粒度で「運用 Day1」を描く、(2) 体制図に実装責任者を置く、(3) フェーズ移行の判定基準を提案段階で握る、(4) ツール選定の前提を提案書本体に書き込む、の 4 点が出発点になります。
これらは小手先のフォーマット変更ではなく、提案する側が実装にコミットする覚悟を提案書の構造に織り込む作業です。戦略だけ作って引き渡す提案書は、クライアント側の実装力に賭ける構造になっており、現場でうまく回らないケースが増えてきました。「戦略の精度は高いが、運用が始まると 3 ヶ月で形骸化する」という現象は、提案段階の設計に原因があると整理できそうです。
提案書は「やること」のリストではなく、「動かし続けるための設計図」へと役割を変えつつあります。
なぜ戦略提案書は半分しか機能しなくなったのか
背景には、コンサルティングの希少資源がシフトしているという構造変化があります。10 年前であれば、AsIs / ToBe を整理し、業界ベストプラクティスを参照しながらロードマップを引く——この作業自体に高い価値がありました。
ところが現在は、生成 AI による分析支援、kintone や各種 SaaS による業務可視化が安価に手に入る状況です。「現状分析」「ベンチマーク」「ロードマップ作成」のような戦略アウトプットは、相対的な希少性が下がってきました。一方で、実装と運用の難易度は逆に上がっています。ツール選択肢が増えたことで、組み合わせ設計の難しさが指数関数的に増し、運用責任の所在も曖昧になりやすい。
私たちが過去 3 年で見てきた案件のうち、戦略フェーズだけで完結した提案書を採用した組織の多くが、実装着手後 6 ヶ月以内に再度コンサルを呼び戻している傾向があります。理由は揃って同じで、「戦略の絵は描けたが、それを動かす役割設計が抜けていた」というものです。
従来型の提案書フォーマット（AsIs / ToBe / ロードマップ / 体制図）がカバーしきれない領域は、明確に 3 つあります。運用 Day1 の動線、実装責任の所在、フェーズ移行の判定基準。この 3 つを提案書本体に書き込めるかどうかが、戦略と実装をつなぐ橋になります。
提案書に組み込むべき 4 つの新しい構成要素
新方針の提案書に必須となる 4 要素を整理してみます。
要素 | 従来版との違い | 省略した場合のリスク |
|---|---|---|
運用 Day1 シナリオ | ToBe 像で止めず、初日の画面・データ・例外対応まで描写 | 実装後に「誰が何をするか」が決まらず、運用開始が遅延 |
実装責任者を明記した体制図 | PM・コンサル・クライアントの 3 層から、実装責任者を 4 層目として追加 | フェーズ移行時に責任の押し付け合いが発生 |
フェーズ移行の判定基準 | 戦略フェーズ完了の条件を、定量・定性の両軸で提案段階に明記 | 戦略フェーズが延々と長引き、実装着手が 2〜3 ヶ月遅延 |
ツール選定の前提条件 | 「適切なツールを選定」と書かず、候補と判断軸を提案書本体に記載 | 実装フェーズで選定し直しになり、戦略設計の前提が崩れる |
それぞれの要素は、提案段階で書き込むことに意味があります。実装フェーズに入ってから決めればいい、という発想がそもそもの落とし穴です。なぜなら、これら 4 要素は実装フェーズの予算規模・期間・体制を逆算する根拠になるため、提案段階で握れない場合、見積もり自体が机上の空論になってしまうからです。
特に「ツール選定の前提条件」は重要で、「kintone か Salesforce か Notion か」の判断軸を提案書本体に書き込むことで、クライアント側の意思決定速度が変わります。判断軸が共有されていれば、実装フェーズでの再議論コストが大幅に下がります。生成 AI 活用の文脈でも同様の論点があり、詳しくは 生成 AI の業務実装で、最初に必ず躓く 3 つの設計判断 を参照してみてください。
ToBe と同じ粒度で「運用 Day1」を描く
提案書の中で最も抜けやすいのが、運用が始まった初日の描写です。ToBe 像は精緻に描かれているのに、Day1 の動線は「運用開始」とだけ書かれている提案書をよく見かけます。
具体的に書き込むべきは、誰がどの画面を開いて、どんなデータを入力し、例外時に誰にエスカレーションするか、という動線です。たとえば「営業担当が朝 9 時に kintone の案件一覧アプリを開き、前日に入力した商談記録を確認する。承認待ち案件が 3 件以上ある場合、マネージャー画面に通知が飛ぶ」というレベルの記述です。
この粒度で書こうとすると、必然的に業務プロセス・データ構造・組織体制の 3 つが整合しているかを提案段階で検証することになります。検証の過程で穴が見つかれば、提案書を提出する前に修正できる。提出後に発覚するのとは、コストが桁違いに違います。
運用 Day1 を描けない提案書は、ToBe の絵を机上の空論に留めている。
実装に降りるコンサルティングでは、Day1 の描写こそが提案の価値を象徴する箇所だと考えています。kintone のような業務プラットフォームを扱う場合は特に、Day1 の粒度を上げることでカスタマイズ範囲も自然と確定していきます。関連して kintone カスタマイズで失敗する組織の共通点 でも、運用設計の重要性に触れています。
体制図に「実装責任者」を置けるか
従来の体制図は、プロジェクトマネージャー・コンサルタント・クライアント側担当の 3 層構造が主流でした。しかし実装に降りる時代には、実装責任者を明示する必要があります。
コンサル側が実装責任を取るのか、SIer に渡すのか、クライアント内製化するのか——この判断を提案書段階で握れない場合、フェーズ移行時に必ず詰まります。「戦略フェーズが終わったので、あとは実装ベンダーを決めてください」と引き渡す瞬間に、3 ヶ月の空白が発生する構造です。
パターンとしては、大きく 3 つに分かれます。
- コンサル側が実装責任者を兼ねる：戦略から実装まで一気通貫で受ける。提案書には実装フェーズの体制と工数を明記する
- SIer をパートナーとして提案書段階から組み込む：提案書共同作成も視野に入れる。役割分担表を提案書に含める
- クライアント内製化を支援する：内製チームの育成計画と、伴走期間を提案書に含める
どのパターンを選ぶかは案件の性質によりますが、提案書段階でどれかに決めておくことが重要です。決めずに「実装フェーズで検討」と書いた提案書は、戦略フェーズの後半で必ず再議論になり、納期を圧迫します。
ある製造業の販売管理改革で、提案書を組み替えた実例
ある大手製造業の販売管理改革プロジェクトで、提案書の構造を変えた事例を紹介します。当初クライアントから提示された RFP は、戦略立案フェーズ（3 ヶ月）のみを切り出した形式で、その後の実装は別ベンダーに任せる前提でした。
私たちは提案書の中で、戦略立案と同じセクション数を割いて「運用 Day1 シナリオ」と「フェーズ移行の判定基準」を記述し、戦略フェーズ終了時点で何が決まっていれば実装に進めるかを明示しました。具体的には、業務プロセス図に加えて、kintone 上のアプリ構成案、運用責任部署、月次の運用負荷試算（約 40 時間 / 月）まで提案書本体に含めています。
結果として、提案コンペで競合 3 社を上回り、戦略フェーズと実装フェーズの両方を一気通貫で受注できました。さらに重要だったのは、戦略フェーズ終了後の実装着手までの空白期間が、通常 2〜3 ヶ月発生するところを 2 週間に短縮できた点です。提案段階で実装責任者と移行基準を握っていたことが、クライアント社内の意思決定スピードを大きく上げた要因でした。
この案件で得た学びは単純で、提案書のページ数や見た目の華やかさではなく、実装に降りる覚悟がどこまで構造に織り込まれているかが、クライアントの意思決定を動かすということです。
提案書の構造から見直したい、というご相談
戦略と実装をつなぐ提案書の構造から見直したい、という課題をお持ちでしたら、私たちが伴走するご相談を承っています。提案書のレビュー、構造の組み替え、運用 Day1 シナリオの言語化支援など、テーマの粒度に合わせて入り方を設計します。
実装に降りるコンサルティングは、戦略立案だけを切り出す従来型より、提案段階での作り込みが重くなります。その分、フェーズ移行のロスや実装後の手戻りを大幅に減らせる構造になっています。営業組織の改革文脈でこの考え方を適用したい場合は、サービスページからお問い合わせください。
関連記事：
