第25章 現場に入り、次期体制と予算をつくる
ここまでの章では、顧客を理解し、価値仮説を小さく試し、提案を実行計画へ変える方法を扱いました。しかし、部門横断の新規事業やサービス改善では、資料を渡すだけでは前へ進みません。顧客ヒアリングへ同席し、設計をレビューし、顧客に届く言葉へ翻訳し、動くものを一緒に作りながら、次期の体制と予算を承認可能な形にする必要があります。
この仕事の成果は、本人が活躍し続けることではありません。顧客、現場、意思決定者の間に学習の循環を作り、次の期間を組織自身で進められる状態へ移すことです。
25.1 五つの依頼を一つの仕事として設計する
五つの依頼は、別々の作業ではなく一つの因果でつながります。
| 依頼 | その場で行うこと | 残す成果物 | 次につながる判断 |
|---|---|---|---|
| 顧客ヒアリングへの同席・設計レビュー | 仮説を確認し、行動事実を聞き、矛盾と未確認事項を拾う | 発言記録、解釈、示唆、未検証仮説 | 何を作り、何を作らないか |
| 顧客に届く言葉・ストーリーへの翻訳 | 社内用語を顧客の状況、妨げ、変化、証拠へ変える | 価値提案、説明シナリオ、反論一覧 | 誰へ何をどう見せるか |
| 動くモック・MVP | 最重要仮説が観察できる最小の体験を作る | モック、実験計画、観察記録 | 継続、変更、中止 |
| メンバーとの直接の関係構築 | 一緒に作業し、困りごと、能力、意思決定経路を理解する | 関係者地図、協働約束、課題・決定ログ | 誰が担い、どこを支援するか |
| 下半期の体制案と予算取り | 成果、仕事量、役割、能力差、費用を選択肢にする | 体制三案、費用モデル、採用・調達計画、承認依頼 | いつ、誰が、いくらを承認するか |
ヒアリング件数や画面数だけを進捗にしません。各活動が、次の意思決定に必要な証拠を増やしたかで確認します。
25.2 最初の二週間で現場の地図を作る
着任直後から解決策を提示する前に、依頼者、意思決定者、実行者、顧客接点、予算管理者を確認します。肩書だけでなく、実際に情報が集まる人、拒否権を持つ人、作業が集中している人を見ます。
最初の二週間で、少なくとも次を一枚にします。
- 下半期に決めるべきことと承認日
- 現在の顧客仮説、事業仮説、技術仮説
- 進行中の案件、会議、成果物、既決事項
- 意思決定者、予算所有者、実行責任者、専門確認者
- 顧客へ接触できる経路と同意・情報管理の条件
- チームの能力、予定稼働、兼務、ボトルネック
- 予算編成、採用、外注、契約に必要なリードタイム
聞き取りだけで作らず、既存資料、会議観察、実際の作業を突き合わせます。認識が食い違う箇所は、誰かの誤りと決めず、確認すべき論点として残します。
25.3 顧客ヒアリングでは三つの役割を合意する
同席前に、主質問者、深掘り・時間管理、記録者を決めます。同席者が途中で競うように質問すると、話の流れが切れ、顧客の回答も誰に合わせるかで変わります。
事前の 15 分で次を確認します。
- この面談の後に変え得る意思決定
- 現在の仮説と、反対なら計画が変わる点
- 必ず聞く最近の具体的な経験
- 見せるものと、反応を誘導しない見せ方
- 主質問者、追質問者、記録者、終了時刻
- 録音、機密、個人情報、利用目的の説明
面談中は、「欲しいですか」より、直近にいつ、何をし、どこで止まり、誰に頼り、何を失ったかを聞きます。解決案を見せた後は、好意的な感想ではなく、理解できない箇所、使わない理由、現在の代替、導入権限を確認します。
終了直後の 15 分で、記録を次の四列へ分けます。
| 発言・観察 | 解釈 | 仮説への影響 | 次に確かめること |
|---|---|---|---|
| 顧客が実際に述べた言葉や操作 | チームの読み | 支持、反証、変化なし | 次の質問、ログ、実験 |
設計レビューでは、質問の美しさではなく、意思決定との対応、対象者の偏り、誘導、倫理、記録方法、終了条件を確認します。詳細は第10章と付録 D を使います。
25.4 顧客の言葉を価値のストーリーへ翻訳する
翻訳とは、顧客の発言を広告らしい言葉に言い換えることではありません。顧客が経験する順番を保ちながら、社内の機能、技術、計画を意味のある変化へ結び直すことです。
次の順で一つのストーリーを作ります。
対象と場面:
誰が、どの状況で困るのか。
現在のやり方:
今は何でしのぎ、どんな負担や危険があるか。
転換点:
なぜ今のままではいけないのか。
提供する仕組み:
何をすることで、行動がどう変わるか。
得られる変化:
時間、品質、安心、売上など何が観測可能になるか。
証拠と限界:
何を確認済みで、何がまだ仮説か。
次の一歩:
相手に何を試し、判断してほしいか。
同じ事実でも、利用者には仕事の変化、現場責任者には運用と危険、経営には投資理由と撤退条件を示します。ただし、相手に合わせて確認状態や不確実性を変えてはいけません。第20章の価値提案と第22章の意思決定順を組み合わせます。
レビューでは、顧客が実際に使った言葉との対応、機能から始まっていないか、効果を言い過ぎていないか、反対理由へ答えているかを確認します。
25.5 動くモックを学習装置として作る
最初に、モックを見た後に何を決めるかを一文にします。画面一覧や技術選定から始めません。
実装の忠実度は仮説に合わせます。
| 確かめたいこと | 最小の作り方 | 観察すること |
|---|---|---|
| 言葉や順序を理解できるか | 紙、スライド、クリックモック | 読み違い、迷い、質問 |
| 一連の操作を完了できるか | 画面設計ツールの Figma、ウェブページを記述する HTML、既存の UI（利用者との操作接点）部品 | 自力完了、戻り、所要時間 |
| AI 出力が業務で役立つか | 人が確認する裏側手動の MVP | 採用、修正、棄却と理由 |
| 連携や性能が成立するか | 薄い技術 PoC | 成功率、待ち時間、例外 |
| 運用と採算が続くか | 少数顧客への限定提供 | 支援工数、障害、継続、費用 |
作業は、当日動く縦の一経路を先に作ります。サンプルデータ、失敗時表示、リセット方法、説明文を含め、デモ担当者しか操作できない状態を避けます。AI で生成したコードや画面も、機密、権利、安全、障害や利用環境にかかわらず使えるアクセシビリティ、誤操作を人が確認します。
毎回のレビューは「見た目の好み」「仮説を測れるか」「本番化に必要な品質」を分けます。モック段階で本番品質を要求せず、本番化するならモックの近道や手動部分を明示して作り直します。
25.6 関係構築は一緒に仕事を終えることで行う
関係構築を、会食や定例 1on1 の回数に置き換えません。信頼は、約束した小さな仕事を一緒に終え、判断理由を開示し、現場の貢献を成果へ反映することで育ちます。
メンバーごとに、次を確認します。
- 担っている仕事と、公式の役割との差
- 成功と評価の基準
- 顧客について知っていること
- 止まっている判断と依存先
- 得意なこと、学びたいこと、避けたい負荷
- 自分に期待する支援と、越えてほしくない境界
助言だけで終わらず、ヒアリング準備、モック作成、レビュー、予算計算のいずれかを共同作業にします。成果物には共同作成者と判断者を記録し、外部支援者が手柄を回収しません。
一方、個人的な信頼で正式な承認や異議申立てを代替しません。1on1 で得た機微情報を本人の同意なく共有せず、課題を共有するときは個人評価ではなく仕事の構造へ戻します。
25.7 下半期の成果から必要な能力を逆算する
体制図を先に描くと、知っている職種を並べるだけになります。まず、下半期末までに得たい顧客・事業成果と、期間内に通過する判断点を置きます。そのうえで必要な仕事量と能力を見積もります。
成果:
対象顧客で価値仮説を検証し、限定提供の継続可否を決める。
判断点:
顧客課題の優先、MVP開始、限定提供、拡大・変更・中止。
必要な仕事:
顧客調査、サービス設計、実装、データ分析、営業連携、運用、法務・安全確認。
必要な能力:
各仕事を完了・確認できる知識、経験、権限、稼働。
供給方法:
既存メンバー、育成、異動、採用、業務委託、共通部門。
人数ではなく、役割ごとの仕事量、必要時期、予定稼働、兼務、余力を見ます。1 人月を一律に 160 時間として埋めず、会議、レビュー、休暇、問い合わせ、学習、管理を含む実績から利用可能時間を置きます。特定の一人だけが持つ顧客関係、技術、承認権は、人数が足りていても単一障害点です。
25.8 体制は三案を同じ条件で比べる
「理想体制」だけでは、予算制約の下で承認者が選べません。最低限、次の三案を同じ成果期間と費用範囲で示します。
| 案 | 狙い | 主な構成 | 代償 |
|---|---|---|---|
| 最小案 | 最重要仮説だけを検証 | 既存メンバー中心、範囲を限定 | 学習範囲が狭く、属人化が残る |
| 推奨案 | 検証と限定提供を両立 | 不足能力を採用・外注で補う | 採用・立上げ費用が必要 |
| 加速案 | 複数仮説と提供能力を並行構築 | 専任増員、外部専門家、基盤投資 | 固定費と調整負荷が高い |
各案に、実現できる成果、対象外、役割、人数・稼働、開始可能日、依存関係、費用、主な危険、停止条件を付けます。人数を増やせば比例して速くなるとは仮定せず、採用期間、オンボーディング、レビュー能力、連携コストを入れます。
25.9 予算要求を費目表ではなく投資判断にする
予算は「必要そうな金額」の合計ではなく、何を学び、どの成果を得るための支出かを説明します。
費用は少なくとも次に分けます。
- 人件費: 既存人員の増分、採用、業務委託、管理・レビュー時間
- 制作・技術費: 開発、デザイン、クラウド、AI、データ、ツール
- 顧客検証費: 募集、謝礼、訪問、調査運営、サポート
- 品質・統制費: セキュリティ、法務、アクセシビリティ、監視、保険
- 立上げ・移行費: 採用、教育、データ移行、契約終了、引継ぎ
- 予備費: 金額だけでなく、使える条件と承認者を定義
金額には、単価、数量、期間、開始月、税込・税別、既存予算との重複、資産計上の扱いを記録し、財務担当者と確認します。売上や削減額だけでなく、顧客損害の回避、学習価値、将来の選択肢も分けて示します。効果の二重計上を避け、既存人員を無料と扱いません。
要求は段階化します。例えば、最初の承認では顧客調査とモックまで、次のゲートでは限定 MVP、結果が基準を満たした場合だけ採用と本格開発へ進みます。各ゲートに成果、証拠、支出上限、判断日、追加・変更・中止条件を置きます。投資計算の詳細は第18章を使います。
25.10 予算承認の逆算カレンダーを作る
「下半期開始までに予算が必要」だけでは遅れます。執行開始日から逆算し、次を置きます。
- 取締役会・経営会議などの最終承認日
- 事業責任者と予算所有者の合意日
- 財務、人事、調達、法務、情報セキュリティの確認期限
- 見積取得、採用承認、契約審査の開始日
- 体制三案と費用モデルの初回レビュー日
- 顧客証拠と MVP 結果を反映できる最終日
予算所有者とは早期に、承認基準、予算科目、上限、予備費、採用枠、資料様式を確認します。完成した提案を最後に持ち込むのではなく、荒い三案の段階で不足情報と反対理由を聞きます。
25.11 90日で依頼を体制案へ変える
期間は案件に合わせて調整します。標準的には次の順で進めます。
| 期間 | 主な活動 | 判断・成果物 |
|---|---|---|
| 1〜2週 | 関係者面談、既存資料・会議観察、顧客接点と予算日程の確認 | 現場地図、意思決定一覧、初期仮説 |
| 3〜4週 | ヒアリング設計・同席、価値の言葉とストーリー作成 | 顧客証拠、価値提案、最重要仮説 |
| 5〜8週 | 動くモック、顧客観察、技術・運用確認 | MVP判断、必要能力、仕事量の初版 |
| 9〜10週 | 体制三案、費用、採用・外注のリードタイム作成 | 最小・推奨・加速案、予算モデル |
| 11〜12週 | 反対意見、財務・人事・現場レビュー、意思決定会議 | 承認、条件付き承認、変更または中止 |
毎週、顧客から学んだこと、変わった仮説、動く成果物、体制・予算への影響、次に必要な決定を一枚で共有します。活動報告だけにしません。
25.12 支援の終了条件を決める
直接手を動かすほど、外部支援者がボトルネックになる危険があります。開始時に、誰へ何を移すかを決めます。
- 顧客ヒアリングを設計・実施・記録できる
- 顧客の証拠から価値提案を更新できる
- 最重要仮説に合うモックや実験を選べる
- 設計レビューの観点と決定記録を運用できる
- 体制の能力差と費用を更新できる
- 予算ゲートで追加、変更、中止を提案できる
共同実施、相手主導での実施、自走とレビューの三段階で移します。テンプレートだけを渡さず、実案件で一度使い、判断理由と例外まで共有します。
考えてみる問い
今回の五つの依頼について、90日後に誰が何を決められる状態にしたいかを書いてください。次に、最初の二週間で会う人、同席する顧客面談、作る一つの動く経路、比較する体制三案、最初の予算承認日を置いてください。
現場に入る仕事では、ヒアリング、言葉、モック、関係、体制、予算を別々に完成させません。顧客の証拠を価値仮説へ変え、動くものから必要能力を学び、その能力を体制と段階予算へ変えます。付録 H の実践シートを使うと、この流れを一つの案件として管理できます。
第8部では、この過程で得た成功と失敗を、次の案件で使える知見として残します。