はじめに

RSL Consulting は、AI（本書では主に文章、表、コードなどを生成する生成 AI）を前提に、相談を受け、調べ、考え、提案し、経験を知見に変えるための実践書です。

本書は、コンサルティングの用語やフレームワークを暗記するための本ではありません。目的は、何を決めるために、どの情報を集め、どの道具を使い、どこからは人が判断するのかを見えるようにすることです。

AI は本書の独立した章ではありません。仮説を広げる、調査を助ける、インタビュー記録を整理する、提案書を磨く、過去の案件を探す。そうした各工程の中で、AI をどう使い、どこを人が確認するかを扱います。

学習目標

本書を使うことで、次の状態を目指します。

• 相談内容を、意思決定に使える問いへ変えられる。
• 何を決めるために、どの情報やデータが必要か説明できる。
• 3C（顧客・競合・自社を見る枠組み）、SWOT（強み・弱み・機会・脅威を見る枠組み）、財務、インタビュー、実験などを、目的に応じて使い分けられる。
• AI の出力をそのまま信じず、出典、推論、情報管理を確認できる。
• 案件の成功や失敗を、次の案件で使える知見として残せる。

対象読者

本書は、次のような人を想定しています。

• AI を使って調査や提案の仕事を速くしたい人
• 新規事業、サービス改善、業務改善に関わる人
• コンサルティングの基本的な考え方を、自分の実務に接続したい人
• フレームワークを知っているだけでなく、いつ使い、いつ使わないかを判断したい人
• 案件で得た成功や失敗を、個人の経験で終わらせず、再利用できる知見にしたい人
• 外部から AI 新規事業や既存プロダクトの機能追加に入り、受注、検証、本番化、引継ぎまで担う人

すでにコンサルティングを専門にしている人にも、AI 時代の作業設計や知見化の観点で使える部分があります。一方で、本書は専門的な法務、会計、統計、業界固有知識を代替するものではありません。必要な場面では、専門家や一次情報に戻ります。

読み方

最初から順番に読んでもかまいません。ただし、案件で使うなら、困っている場所から読んでください。

コンサルティングの経験がまだ少ない人は、最初から全部を完璧に理解しようとしなくてかまいません。まず「相談を受けたら、何を決める話なのかをはっきりさせる」「判断に使う証拠を集める」「案を作り、捨てる理由も示す」「実行後に学びを残す」という流れをつかんでください。3C（顧客・競合・自社）、SWOT（強み・弱み・機会・脅威）、TAM（定義した市場の総需要機会）、LTV（顧客関係から得られる将来価値）などの略語は、暗記する対象ではなく、その場で何を見落とさないための道具として扱います。

各章では、原則として次の観点を扱います。

• 何を決めるための考え方か
• どの場面で使うか
• 使わなくてよい場面はどこか
• AI をどう使えるか
• 人が確認し、判断すべきことは何か
• 実務で失敗しやすい点は何か

最短で始めるなら、第2章、第7章、第10章、第20章、第26章を読み、顧客共創から次期体制・予算までを担う場合は第25章を加えてください。AI 機能を本番へ出す責任を持つ場合は、第29章と第30章を必ず読みます。必要に応じて付録 C、D、E、F、H、I、J、K を使います。最初からすべてのテンプレートを埋める必要はありません。

外部から AI 案件へ入る人の最短ルート

本書を順番に読み終えるまで案件を止める必要はありません。今いる局面に合わせて、次の順で参照します。

急ぐ場合も、受注前の境界、本番前の評価、終了前の引継ぎは省略しません。省略する作業があるなら、誰がどの危険を引き受けるかを記録します。

未経験から順に力を付けたい場合は、次の順で読むと、各章の役割がつながりやすくなります。

1. 第1部で、相談を意思決定の問いへ変える
2. 第2部で、考え方と論証の土台を作る
3. 第3部で、調査、データ、インタビューを扱う
4. 第4部で、顧客、競合、市場を見て、どこで戦うかを考える
5. 第5部で、利益、現金、投資、成長の経済性を確認する
6. 第6部と第7部で、解決策、提案、実行計画へ落とす
7. 第8部で、案件から学びを残す
8. 第9部で、外部支援として契約、AI評価、本番化、引継ぎを一続きに実践する

各章を読んだら、「この章は何を決めるための章か」「その判断に必要な証拠は何か」「人が責任を持って決める部分はどこか」を一つずつ言葉にしてください。章末の問いは、正解を当てる問題ではなく、自分の案件へ置き換えるための練習です。

章末の問いに取り組むときは、長いレポートを作る必要はありません。その章で判断に効いた観点を、自分の案件に当てはめて短く書きます。書く形は章ごとに変わります。比較が必要な章もあれば、問いを一文にするだけで十分な章もあります。書けない箇所がある場合は、理解不足ではなく、まだ前提や証拠が足りない合図として扱ってください。

本書の更新方針

RSL Consulting は、完成品として固定する本ではありません。Repeat Space Library の第一弾として、実際の案件、成功体験、失敗体験、調査メモ、提案の改善から更新していきます。

更新するときは、単なる成功談を増やすのではなく、次の形で残します。

• そのとき何を決めようとしていたか
• どの前提で判断したか
• 何がうまくいき、何がうまくいかなかったか
• 次に同じ状況ならどうするか
• どの条件では使ってはいけないか

経験は、そのままでは知見になりません。背景、制約、判断、結果、適用条件を残して初めて、次の案件で使えるようになります。本書は、そのための土台です。

第1部 コンサルティングの仕事

コンサルティングの道具を学ぶ前に、何のために使うのかを定めます。この部では、曖昧な相談を意思決定の問いへ変え、限られた時間の中でプロジェクトを設計するところまでを扱います。

第1章 コンサルティングは何を変える仕事なのか

「市場を調べてください」と依頼され、競合一覧と市場規模をまとめた資料を納品したとします。調査内容は正確で、図表もきれいです。それでも、依頼した会社が何も決められなければ、その仕事は成功したと言えるでしょうか。

コンサルティングでは、調査、分析、会議、資料作成など、目に見える作業が数多く発生します。しかし、それらは目的ではありません。本章では、コンサルティングを「クライアントがよりよい意思決定を行い、必要な変化を実行できる状態をつくる仕事」と捉えます。

ここでいう変化には、状況への理解が変わること、選択肢と優先順位が定まること、組織の行動が変わること、その後は自分たちで判断できるようになることが含まれます。

この定義を採用すると、成果物の完成度だけでなく、「誰が何を決めるのか」「その判断に何が必要か」「決定後に実行できるか」を問えるようになります。同時に、コンサルタントが決定を引き取るのではなく、クライアントが負う責任を支える仕事だという境界も見えてきます。

現実の案件が、常にこの定義どおりに行われているわけではありません。資料作成の代行や、すでに決まった方針の正当化が「コンサルティング」と呼ばれる場合もあります。本書は業界に存在する仕事をすべて同じ価値で記述するのではなく、クライアントの判断力と実行力を高める仕事を目指す、規範的な立場を採ります。

1.1 成果物の先にある意思決定

コンサルティングの仕事を外から見ると、成果物が目につきます。

• 市場調査レポート
• 顧客インタビューの分析
• 事業計画や財務モデル
• 業務プロセスの設計
• 経営会議向けの提案資料

これらは必要です。しかし、成果物そのものをゴールにすると、依頼の言葉をそのまま作業へ置き換えてしまいます。

たとえば、「若年層向けの新サービスについて市場調査をしてほしい」という依頼を考えます。この時点では、何を決めたいのかが分かりません。

• 市場へ参入するか決めたいのか
• どの顧客層から始めるか決めたいのか
• 投資額を決めたいのか
• すでに決めた参入方針を、経営会議で承認してもらいたいのか

決めたいことが違えば、必要な調査も変わります。参入判断なら、市場の成長性、競争、顧客課題、自社の優位性、投資回収の可能性が必要です。最初の顧客層を選ぶなら、課題の強さ、接触可能性、支払い意思、既存の代替手段などを比較する必要があります。

したがって、最初に確認すべきなのは「何を調べるか」ではなく、次の 4 点です。

1. 誰が意思決定するのか
2. 何を決めるのか
3. いつまでに決めるのか
4. 決めるために、現在何が足りないのか

不足を埋める方法は、調査だけではありません。安価に試せるなら、小規模な実験や顧客との対話から学ぶ方が速い場合があります。取り消しやすい決定なら、すべてを調べてから動くより、範囲を限定して動き、結果を見て見直す方法もあります。

成果物や検証方法は、決定に必要な不足へ合わせて選びます。使われない分析を増やしても、価値は増えません。実験を選ぶ場合も、金銭費用だけでなく、顧客への不利益、信頼、法令、安全性を確認します。小さく始めても、影響まで簡単に取り消せるとは限りません。AI に調査や整理を任せる場合も同じです。出力を増やす前に、何の不足を埋めるのかを定めます。

1.2 助言だけでは終わらない

意思決定を支えることは重要ですが、コンサルティングを「正しい答えを教える仕事」と捉えるのも不十分です。

外部のコンサルタントが論理的に優れた案を示しても、その会社が実行できるとは限りません。実行には、予算、権限、人員、技術、既存業務との調整が必要です。関係者が問題の捉え方に合意していなければ、提案は会議で止まります。提案が既存の評価制度や組織構造と衝突すれば、承認されても動きません。

このため、コンサルティングの成果は 4 段階で考えられます。

案件によって、コンサルタントが担う範囲は異なります。調査だけを受け持つ場合もあれば、実行や定着まで支援する場合もあります。重要なのは、契約範囲を超えて何でも引き受けることではありません。どの段階までを成果とし、どこから先をクライアントが担うのかを、開始時に明確にすることです。

事業成果とコンサルタントの寄与も分けます。売上、利益、解約率などの最終的な成果は、市況、競合、クライアントの実行を含む多くの要因に左右されます。コンサルタントが直接管理できるのは、必要な分析の品質、選択肢の明確さ、合意した支援の実施などです。最終成果を共有目標に置きつつ、自分が管理できない結果まで保証したように見せてはいけません。

国際標準化機構（ISO）が定めた管理コンサルティングサービスの国際的な指針である ISO 20700 も、サービス提供の有効性だけでなく、クライアントのニーズの理解、透明性、成果を重視しています。これは、よい分析手法だけでプロジェクトの品質が決まるわけではないことを示しています。

1.3 外部の人間を入れる 4 つの理由

クライアントは、自社のことをコンサルタントより長く見ています。それでも外部の人間へ相談するのは、社内に能力がないからとは限りません。主な理由は 4 つに分けられます。

専門知識と経験

新しい市場、制度、技術、経営課題など、社内で経験していない問題に取り組む場合です。コンサルタントは、他社や他業界で得た知識をそのまま持ち込むのではなく、クライアントの条件に合わせて翻訳します。

一時的な処理能力

社内に能力はあっても、重要な期限までに調査や分析を行う人手が足りない場合です。このとき求められるのは、単純な作業代行だけではありません。短い時間で論点を絞り、意思決定に間に合う精度を見極める必要があります。

外部からの視点

組織の中では、前提が共有されすぎて疑われなくなることがあります。部門間の利害や過去の経緯により、問題を率直に扱いにくい場合もあります。外部の人間は、暗黙の前提を問い直し、比較対象を持ち込みます。ただし、外部だから自動的に客観的になるわけではありません。コンサルタント自身にも、経験や契約関係から生じる偏りがあります。

意思決定プロセスの設計

必要な情報が揃っていても、誰が、どの基準で、いつ決めるかが曖昧な場合です。コンサルタントは、論点を整理し、選択肢を比較し、関係者が決められる場を設計します。この役割は、特定の案を押し通すこととは異なります。

4 つの理由は重なることがあります。依頼を受けるときは、クライアントがどの役割を期待しているのかを確認します。期待がずれたまま進めると、コンサルタントは深い分析を提供したつもりでも、クライアントは「一緒に合意形成してほしかった」と感じるかもしれません。

外部へ頼むこと自体が正解とは限りません。内製する、必要な人材を採用する、特定の作業だけを外注する、今回は何もしないという選択肢もあります。報酬だけでなく、社員が説明、会議、データ提供に使う時間や、知識が社内に残らない危険も費用です。外部支援によって得られる速度、専門性、判断の改善が、これらの費用を上回るかを確認します。

1.4 分析が正しくても失敗する理由

次の例を考えます。

ある教育サービス会社は、解約率の上昇を問題と考えました。分析の結果、利用開始から 30 日以内に学習を始められなかった顧客ほど、解約率が高いという関連が見つかりました。この時点では、学習開始の遅れが解約を引き起こしたとは断定できません。そこでコンサルタントは、因果関係を確かめるため、利用開始時の定着を助けるオンボーディング施策の小規模な検証を提案しました。

分析と提案には筋が通っています。しかし、次の事情が見落とされていました。

• 顧客への連絡は営業部門の承認が必要だった
• 開発チームは半年先まで別案件で埋まっていた
• サポート部門の評価指標に、初期利用率が含まれていなかった
• 解約率の定義が部門ごとに異なっていた

この状態では、提案に可能性があっても実行できません。必要だったのは、解約との関連を調べることだけではなく、検証と実行の条件を確認することです。たとえば開発を待たず、対象を限定し、担当者が手動で初期案内を行えば、低い費用で効果と運用負荷を確かめられます。

コンサルティングの失敗を避けるには、少なくとも次の問いが必要です。

• この結論を誰が受け入れる必要があるか
• 決定に反対する合理的な理由は何か
• 実行に必要な権限、予算、人員、データはあるか
• どの既存業務や評価制度と衝突するか
• 何をもって実行できたと判断するか

「正しい答え」と「組織が実行できる答え」は同じではありません。実行しやすさだけを優先して問題を小さくするのも危険ですが、実行条件を無視した提案は、資料の中でしか成立しません。

1.5 コンサルタントは決定者ではない

コンサルタントは、選択肢を示し、根拠を整理し、推奨案を述べられます。しかし、通常はクライアントに代わって経営上の責任を負う立場ではありません。

ここには重要な境界があります。

• コンサルタントは、都合の悪い事実も伝える
• 推奨案と、その前提やリスクを明示する
• 分からないことを、分かったように埋めない
• クライアントの望む結論へ根拠を合わせない
• 最終的な決定権と責任の所在を曖昧にしない

一方で、「決めるのはクライアントだから」と言って、選択肢を並べるだけでも不十分です。専門家として推奨できる案があるなら、条件と確信度を添えて述べます。中立性とは、判断を避けることではなく、根拠と利害を透明にすることです。AI の出力を使った場合も、根拠を原資料まで確認し、検証していない仮説と確認済みの事実を分けます。

各国の管理コンサルタント団体から成る国際組織 ICMCI（International Council of Management Consulting Institutes）の能力フレームワークは、分析技法だけでなく、価値観、倫理、行動、クライアントとの関係、継続的な専門能力開発を含めています。コンサルティングの品質が、頭のよさや資料作成能力だけでは決まらない理由がここにあります。

1.6 AI が変える作業と変えない責任

AI は、論点候補の展開、資料探索、要約、分類、集計、質問案や構成案の作成を速くします。大量の情報を集め、整った資料にする作業だけでは、価値の差がつきにくくなっています。

Stanford HAI（スタンフォード・エイチエーアイ）は、米国のスタンフォード大学にある Stanford Institute for Human-Centered Artificial Intelligence の略称です。日本語では「人間中心の AI を研究する組織」という意味で、技術だけでなく、経済、政策、社会への影響も複数分野の研究者が調べています。

この組織が毎年公表する AI Index は、AI の研究開発、性能、企業利用、投資、政策などの変化を、多数の統計から整理した年次報告書です。その 2026 年版は、2025 年に調査対象組織の 88 パーセントが、少なくとも 1 つの業務機能で AI を利用していると報告しています。ただし、これは自己申告調査に基づく方向的な数値であり、すべての企業が AI を深く使い、同じ成果を得ているという意味ではありません。この数値は 2026 年 7 月 15 日に確認した、AI の普及を示す時点情報です。

作業が速くなっても、問いを選ぶこと、根拠を検証すること、利害を扱うこと、推奨することへの責任は残ります。AI は関係者や選択肢の候補を挙げられますが、誰の不利益をどこまで受け入れるかを決め、対話の結果を引き受ける主体にはなりません。

たとえば、AI に「この会社が新市場へ参入すべきか分析してください」と依頼すると、もっともらしい SWOT 分析や市場参入案を作るでしょう。しかし、前提となる顧客データや自社の実行能力を与えていなければ、それは検証前の仮説です。

AI を使うときは、次の流れを守ります。

1. 意思決定と、AI に任せる作業を分ける
2. 必要な前提と資料を与える
3. 出力を仮説、事実、推測に分ける
4. 重要な事実を一次情報で確認する
5. 反証と代替案を求める
6. 人間が推奨案と責任の所在を明確にする

AI は、コンサルタントから考える責任を取り除く道具ではありません。調査や資料作成に使っていた時間を減らし、問い、検証、対話、判断へ時間を移すための道具です。

1.7 よい意思決定を結果だけで測らない

よい結果が出たからといって、判断の仕方までよかったとは限りません。根拠のない賭けが偶然当たることもあります。反対に、十分な検討をしても、予測できなかった出来事によって結果が悪くなることがあります。

本書では、意思決定の質を、結果が判明する前にも確認できる次の条件で捉えます。

• 目的と制約が明確である
• 現状維持を含む複数の選択肢を比較している
• 重要な根拠と反証を確認している
• 前提、不確実性、利害を明示している
• 決定者と責任の所在が明確である
• 結果を測り、見直す条件を決めている

さらに、影響を受ける人を確認し、目的そのものが法令や倫理上の制約に反していないかを問います。

すべての決定に同じ時間をかける必要はありません。重要度、可逆性、緊急性に応じて検討の深さを変えます。この基準は、正解を保証するものではありません。結果から学び、次の判断を改善できるプロセスをつくるためのものです。

1.8 プロジェクト開始時に合意すること

コンサルティングの価値を意思決定と変化に置くなら、開始時の合意も変わります。「何を納品するか」だけでなく、次を確認します。

ただし、この表を初回会議で一度に埋める必要はありません。まず目的、決定者、範囲、開始条件を合意し、分からない項目は仮説として置いて、調査と対話に応じて具体化します。

必要な開始条件が揃わない場合は、受注しない、開始を待つ、範囲を縮めるという判断も必要です。始めてから重要な前提が崩れた場合も、惰性で続けず、停止または再設計します。外部支援を終える条件には、クライアント側へ責任者と運用が移り、自分たちで次の判断を行えることも含めます。

この合意は、開始時に一度作って固定するものではありません。調査によって前提が崩れれば、問いや範囲を見直します。ただし、変更を曖昧に行うと、期待と費用がずれます。何が分かり、何を変え、どの影響があるのかを共有します。意思決定者だけでなく、支援の責任を持つスポンサー、日々の実務責任者、レビューを行う会議体も決めます。

考えてみる問い

最近受けた「調べてほしい」「作ってほしい」という依頼を 1 つ選んでください。誰が、何を、いつ決めるための依頼だったか。調査ではなく、小さな実験で埋められる不足はなかったかを考えてみましょう。

コンサルティングは、正解を知っている人が、知らない人へ答えを渡す仕事ではありません。クライアントが置かれた条件の中で、重要な問いを定め、根拠を集め、選択肢を比較し、決定と実行を支える仕事です。

この捉え方が定まると、次に問うべきことが見えます。依頼として語られた「調べてほしいこと」を、どのように「決めるべきこと」へ変えるのか。次章では、その入口となる問題設定を扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。理解、決定、実行、定着という段階と、「よい意思決定」の条件は、以下の資料を踏まえた本書独自の整理です。

• ISO 20700:2017 ― Guidelines for management consultancy services
• ICMCI ― CMC Competence Framework, Version 4.0
• Stanford Institute for Human-Centered AI ― The 2026 AI Index Report, Chapter 4: Economy

第2章 相談を意思決定の問いへ変える

「解約率が上がっています。オンボーディングを改善したいので、競合を調べてください」

この依頼は具体的に聞こえます。問題は解約率、解決策はオンボーディング改善、作業は競合調査と、すでに揃っているように見えるからです。しかし、ここで調査を始めると、クライアントが最初に口にした因果関係と解決策を、そのまま正しいものとして扱うことになります。

解約率の上昇は、問題そのものではなく症状かもしれません。オンボーディングに原因があるとは限りません。価格改定、顧客構成の変化、サービス品質、競合の参入、計測方法の変更も候補です。そもそも、いま決めるべきことがオンボーディング施策なのかも分かりません。

コンサルタントは、依頼を受け取ってすぐ作業へ移るのではなく、その依頼を「誰が、何を、いつ、どの基準で決めるのか」という問いへ変換します。本章では、この変換を問題設定と呼びます。

問題設定は、最初に一度決めて固定する準備作業ではありません。調査や対話によって見直される仮説です。よい問題設定とは、問題を美しい一文にすることではなく、次に何を確かめ、何を決めればよいかを明らかにすることです。

2.1 依頼の言葉は出発点にすぎない

クライアントが最初に話す内容には、複数のものが混ざっています。

• 起きていること
• 困っていること
• 原因についての見立て
• すでに考えている解決策
• 社内で説明しやすい言い方
• コンサルタントへ頼みたい作業

先ほどの依頼を分けると、次のようになります。

依頼の言葉を疑うことは、クライアントを否定することではありません。発言には、その人が持つ経験と組織内の事情が含まれています。それを重要な初期仮説として尊重しながら、事実と解釈を分けます。

すぐに言い換えを提示するより、まず具体化します。

• 「解約率」はどのように定義していますか
• どの期間と比較して上がりましたか
• どの顧客群で変化していますか
• オンボーディングが原因だと考えた根拠は何ですか
• 競合調査の結果を受けて、誰が何を決めますか
• 何もしなかった場合、いつ、どのような影響が出ますか

ここでの目的は、質問を多くすることではありません。依頼の中に隠れている前提を、検証できる形にすることです。

2.2 症状、原因、課題、解決策の混同

問題に関する用語は、会社や本によって意味が揺れます。本書では、議論を追いやすくするため、次のように区別します。

この区別は、唯一の正しい用語体系ではありません。実務では、クライアントが使う言葉を無理に置き換える必要もありません。重要なのは、同じ言葉で別のものを指していないかを確かめることです。

症状も、価値判断から独立した事実ではありません。数値の変化は観測できても、それを「問題の兆候」とみなすには期待値が必要です。誰がどの期待を重視しているのか、その期待が顧客、従業員、経営者の間で衝突していないかを確認します。

混同すると、調査の順序が逆になります。解決策から始めると、その解決策を支持する情報ばかり集めやすくなります。症状を原因と呼ぶと、「解約率が高いのは顧客が解約するからだ」という循環した説明になります。課題を「オンボーディングを作ること」と置くと、作るかどうかを検討する余地がなくなります。

問題設定では、少なくとも次の鎖を仮置きします。

観測された症状
  ↓ 何が生んでいるか
原因仮説
  ↓ 何を変えられるか
課題
  ↓ どの方法を選ぶか
解決策仮説
  ↓ 誰が何を決めるか
意思決定の問い

矢印は事実ではありません。それぞれが検証対象です。一本の鎖に早く絞らず、重要な代替仮説を残します。

原因候補は、根拠の強さ、症状への影響の大きさ、介入可能性を分けて評価します。影響が大きくても変えられない要因があり、変えやすくても影響が小さい要因があります。「原因らしい」と「いま働きかける価値がある」は別の判断です。

2.3 問題の見方が解決策を狭める

同じ状況でも、問題の切り取り方によって、調べるものと選択肢が変わります。

たとえば「会議が多く、開発が遅い」という相談を考えます。

会議の効率として捉える

会議時間、参加者、議題、進行方法を調べます。解決策は、会議の削減、時間制限、議事進行の改善などになります。

意思決定権限として捉える

誰が承認するのか、どの判断が上位者へ集中しているのかを調べます。解決策は、権限委譲、判断基準の明文化、承認段階の変更などになります。

仕事の依存関係として捉える

複数チームの作業がどこで待ち合っているかを調べます。解決策は、チーム境界、担当範囲、システム構造の変更かもしれません。

優先順位として捉える

同時に進める案件数や、割り込みの発生源を調べます。解決策は、仕掛かりの制限、経営判断の集約、案件の中止かもしれません。

どれか一つが最初から正しいわけではありません。複数の見方を置くと、最初の解決策へ固定されるのを防げます。一方で、可能性を無限に広げると何も調べられません。次の観点で、最初に確かめる見方を絞ります。

• 観測された複数の症状を説明できるか
• 反証できる形になっているか
• 行動につながるか
• 重要な関係者を見落としていないか
• 期限内に確かめられるか

戦略的な問題のフレーミングと定式化を研究した Ananth、Park、Turner は、症状へ注意を向ける段階と、その症状を説明する原因を組み立てる段階を区別しています。戦略的で複雑な問題では、目立つ一つの症状だけを見るより、関連する症状を広く確認してから原因を考えることが、狭すぎる局所的な解決を避ける助けになります。緊急対応や境界の明確な技術問題では、必要な速度に合わせて探索範囲を狭めます。

問題定義を研究した Gerald F. Smith は、問題解決には問題の定義や表現が先行する一方、その定義自体が十分に扱われてこなかったと指摘しています。問題をどう表現するかは、分析モデルを作る前の単なる言葉選びではなく、その後の探索を方向づける判断です。

2.4 誰の問題かで境界が変わる

「売上が落ちた」という症状でも、関係者によって問題の意味は異なります。

• 経営者は、利益と成長への影響を見る
• 営業責任者は、商談数と成約率を見る
• プロダクト責任者は、顧客が価値を得られているかを見る
• 顧客は、支払った費用に見合う結果が得られるかを見る
• サポート担当者は、問い合わせ増加と対応負荷を見る

一つの視点だけで境界を決めると、別の場所へ負担を移す解決策を選びかねません。サポート時間を短縮して費用を下げても、顧客の自己解決が難しくなり、解約が増えれば全体では悪化します。

問題設定では、次を確認します。

• 誰が困っているのか
• 誰が決めるのか
• 誰が実行するのか
• 誰が利益を得るのか
• 誰が費用や危険を負うのか
• 誰の声が、現在の会話に入っていないのか

すべての関係者を同じ重さで扱うという意味ではありません。関係者の期待が対立するとき、問題設定によって対立を消したように見せてはいけません。両立しない目的と、各案で誰が負う不利益を記録し、決定者が選択の理由を説明できるようにします。

複雑な問題では、唯一の定義へ急いで合意すること自体が危険です。経済協力開発機構（OECD）と国際応用システム分析研究所（IIASA）のシステム思考に関する報告も、複雑な政策課題では相互関係、フィードバック、複数の価値を扱う必要があり、単一の問題定義や評価尺度への固定を避けるよう提案しています。企業の案件すべてが同じ複雑さを持つわけではありませんが、部門をまたぐ問題では参考になります。

2.5 意思決定の問いに必要な 7 要素

問題を広く理解するだけでは、プロジェクトを進められません。何を決めるかまで具体化します。本書では、意思決定の問いを次の 7 要素で記述します。

冒頭の依頼は、まず次のように構造化できます。

決定者: 事業責任者
選択: どの顧客群へ、どの初期支援を試すか
期限: 8 月末
目的: 新規顧客の 90 日以内解約を減らす
判断基準: 期待効果、顧客への危険、支援工数、実行可能性、学習価値（次の判断で不確実性を減らせる情報が得られるか）
制約: 追加開発なし。既存人員で 4 週間運用できる
不足: 解約が増えた顧客群、初期行動との関係、手動支援の効果と負荷

この 7 要素は、決める前の問いを構造化します。施策を試す段階では、別に停止条件を加えます。この例なら、顧客苦情または 1 人あたりの支援工数が合意した上限を超えたら停止します。

これを一文にすると、次のようになります。

事業責任者が 8 月末までに、新規顧客の 90 日以内解約を減らすため、どの顧客群へどの初期支援を試すかを決める。期待効果、顧客への危険、支援工数、実行可能性、学習価値で比較する。追加開発は行わず、既存人員で 4 週間運用できることを条件とし、解約が増えた顧客群、初期行動との関係、手動支援の効果と負荷を確かめる。

この一文が最終回答なのではありません。次の調査を設計するための暫定的な問いです。調べた結果、問題が初期利用ではなく価格改定後の顧客構成にあると分かれば、問いを変えます。

この問いは、コンサルタントだけで確定しません。決定者、プロジェクトのスポンサー、実務責任者と確認し、異論と未合意点も残します。未合意点には、解消する責任者と期限を付けます。全員が同じ文言を暗記する必要はありませんが、調査結果を受けて誰が何を変えるのかは共有します。

政策判断向けの OECD のチェックリストも、問題の性質と規模、発生理由を明確にし、介入の便益と費用、代替手段を比べることを求めています。対象は規制ですが、「対策を選ぶ前に問題と代替案を明らかにする」という順序は、事業上の問題設定にも応用できます。

2.6 スコープは「扱わないこと」まで決める

問題の境界を広げれば、多くの要因を含められます。しかし、すべてを扱うプロジェクトは終わりません。

スコープでは、対象だけでなく、扱わないものと理由を記録します。

除外は「重要ではない」という宣言ではありません。期限内の決定に対して、いまは優先しないという選択です。除外した要因が重要だと分かったときに戻せるよう、理由と見直し条件を残します。

スコープを変えるときは、変更した問い、変更理由、期限と費用への影響、承認者を短いログに残します。変更そのものより、誰にも共有されないまま期待だけが変わることを避けます。

また、スコープは分析対象だけではありません。誰に話を聞けるか、どのデータを使えるか、どの会議で決めるかも境界です。意思決定者へアクセスできないなら、問いをどれだけ整えても、提案は決定につながりません。

2.7 AI には答えより別の見方を求める

問題設定で AI を使う価値は、最初から正しい問題を当ててもらうことではありません。人間が置いた見方を広げ、暗黙の前提と反証候補を見つけることにあります。

たとえば、次の材料を渡します。

観測された症状:
新規顧客の 90 日以内解約率が、直近 3 か月で上昇した。

現在の見立て:
オンボーディングに問題がある。

決めたいこと:
来月、解約を減らすために何を試すか。

制約:
追加開発はできない。4 週間、既存人員で試せること。

依頼:
1. この問題の別の捉え方を 5 つ挙げる
2. 各案について、成立を支持する事実と反証する事実を示す
3. 最初の 1 週間で確認できることを示す
4. 現在の問いに埋め込まれた前提を指摘する

AI の候補は、事実ではありません。実在しない顧客事情や、与えていない因果関係を補うことがあります。候補を採用する前に、社内データ、顧客との対話、業務の観察、一次資料で確かめます。

もう一つの危険は、詳細な依頼文が AI の探索を固定することです。「オンボーディングが原因です」と断定してから改善案を求めれば、その前提に沿った案が増えます。現在の見立てを仮説と明記し、「この見立てが誤っているとしたら何が起きているか」を尋ねます。

AI は問題設定の速度を上げますが、問題の境界によって誰が得をし、誰が見落とされるかを判断する責任は人間に残ります。

2.8 問題設定を更新する合図

問題設定に時間をかけすぎると、調査も行動も始まりません。反対に、早く固定しすぎると、後から得た事実を現在の枠へ押し込みます。

決定の重要度と失敗費用に応じて、問題設定の深さを変えます。小さく取り消しやすい判断なら、最低限、次の 4 点があれば動き始められます。

1. 誰が、何を、いつ決めるか
2. 最初に何を確かめるか
3. どの条件で止め、問いを見直すか
4. 顧客、法令、安全への重大な危険がないか

大きな投資、組織変更、顧客へ不可逆な影響を与える判断では、関係者、原因仮説、判断基準、スコープをより丁寧に確認します。

通常の問題設定は、次の条件が揃えば調査を始められます。

• 暫定的な決定者と決定期限が分かる
• 原則として、現状維持を含む代替案を確認している
• 主要な症状と原因仮説を区別している
• 最初に確認する事実が決まっている
• 対象と、いま扱わない範囲が分かる
• 新しい事実によって問いを見直せる

法令対応、事故対応、緊急障害など、選択の余地や時間が小さい場合は、数を満たすために案を増やしません。その場合も、実行方法、危険の抑え方、停止や復旧の条件は比較できます。

調査中に次の合図が現れたら、問題設定へ戻ります。

• 症状の定義や数値が部門によって異なる
• 主要な原因仮説を反証する事実が見つかった
• 決定者が想定と違った
• 選択肢が最初から一つに固定されていた
• 対策による負担が別の関係者へ移ると分かった
• 期限や制約が変わった
• 集めた情報が、決定に使われない状態が続いた

問題設定の変更は失敗ではありません。新しい事実を受けても問いを変えないことの方が問題です。ただし、変更するたびに、調査範囲、期限、費用、関係者への影響を共有し、変更ログに残します。

2.9 依頼を問いへ変える 4 手順

ここまでの内容を、実務で最初に行う順序へまとめます。

1. 依頼を分ける 観測された症状、原因仮説、解決策仮説、作業依頼を分けます。
2. 別の見方を置く 別の見方を置き、最初に確かめるものを選びます。
3. 意思決定の問いを書く 決定者、選択、期限、目的、判断基準、制約、不足を記述します。
4. 合意して、更新条件を決める 決定者と実務責任者へ確認し、最初に確かめること、停止条件、問いを見直す合図を残します。

この 4 手順は、前の節を省略するための新しいフレームワークではありません。案件の大きさに合わせて、どこを詳しく確認するか判断するための入口です。

考えてみる問い

最近受けた依頼を、症状、原因仮説、解決策仮説、作業依頼に分けてください。そのうえで、決定者、選択、期限、目的、判断基準、制約、不足の 7 要素を使い、意思決定の問いへ書き換えてみましょう。

問題設定は、最初から正しい問題を言い当てる技術ではありません。依頼に含まれる前提を見えるようにし、複数の見方を比べ、次に確かめることを決める技術です。

問いが定まれば、次は限られた時間の中で何を行うかを設計できます。第3章では、仮説、作業、成果物を結び、プロジェクトを進める道筋を扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の用語区分と「意思決定の問い」の 7 要素は、以下の資料を踏まえた本書独自の整理です。

• Gerald F. Smith ― Defining Managerial Problems: A Framework for Prescriptive Theorizing
• OECD ― Reference Checklist for Regulatory Decision-making
• OECD / IIASA ― Systemic Thinking for Policy Making
• Ananth, Park and Turner ― Looking at the Trees to See the Forest: Construal Level Shift in Strategic Problem Framing and Formulation

第3章 プロジェクトを設計する

第2章では、「競合を調べてください」という依頼を、「事業責任者が 8 月末までに、どの顧客群へどの初期支援を試すか」という意思決定の問いへ変えました。次に必要なのは、その問いに答えるためのプロジェクトです。

ここで、すぐにインタビュー、データ分析、競合調査と作業を書き出すと、仕事は始めやすくなります。しかし、作業が終わっても判断材料が揃わないことがあります。競合を 10 社調べ、顧客へ 20 件インタビューし、立派な報告書を作っても、どの施策を試すか決められなければ、プロジェクトの目的は達成されていません。

プロジェクト設計は、作業を漏れなく並べることではありません。決定に必要な証拠から逆算して、確かめる問い、作業、成果物、会議、担当、期限を結ぶことです。本章でいう証拠とは、判断を支持または反証するために使うデータ、観察、証言、文書などを指します。本章では、この逆算の方法を扱います。

図 3-1 は、左から右へ「何を決めるか」「何で比べるか」「どの証拠が必要か」「どの作業で得るか」を見ます。下段の成果物や会議は、作業の終点ではなく、決定と実行へ証拠を渡すために置きます。

3.1 成果物から始めると仕事が目的になる

提案書、調査報告書、分析表は、プロジェクトの成果物です。成果物は必要ですが、それ自体がクライアントに起こしたい変化ではありません。

本書では、次の 4 つを区別します。

この順序には因果関係の仮説があります。

作業 → 成果物 → 意思決定 → 実行 → 期待する結果

矢印は自動ではつながりません。分析表を作っても、決定者が会議に参加しなければ決定されません。決定しても、実行担当者や予算がなければ結果は変わりません。解約率が下がっても、価格改定や顧客構成の変化が原因なら、施策の効果とは限りません。

したがって、プロジェクトの約束を「報告書を納品する」とだけ置くのは不十分です。契約上の納品物とは別に、その成果物を誰がどの決定に使うか、何を満たせば受け入れるか、決定後に誰が実行し、何を追跡するかまで確認します。

受入条件はページ数や体裁だけでなく、利用可能性で書きます。たとえば、「対象顧客を同じ定義で比較できる」「各選択肢について判断基準ごとの証拠と不明点が示されている」とします。プロジェクト開始時に成果物の利用者と合意し、意思決定やスコープが変わったときに見直します。

一方で、コンサルタントが事業成果を単独で保証することもできません。成果は、市場環境やクライアントの実行に左右されます。コンサルタントが責任を持つ範囲と、クライアントと共同で追う結果を分けます。

3.2 決定から証拠へ逆算する

第2章で作った意思決定の問いには、決定者、選択、期限、目的、判断基準、制約、不足が含まれていました。プロジェクト設計では、このうち判断基準と不足から、必要な証拠を考えます。

今回の選択肢を、次の 3 つと仮定します。

• 顧客全体へ手動の初期支援を行う
• 解約危険の高い顧客だけへ手動支援を行う
• 手動支援を行わず、別の原因を調べる

判断基準は、期待効果、顧客への危険、支援工数、実行可能性、学習価値です。すると、「競合は何をしているか」より先に、次の証拠が必要だと分かります。

ここでいう証拠は、必ずしも厳密な因果推論を可能にするデータだけではありません。決定の大きさと失敗費用に応じて、必要な確かさを変えます。取り消しやすい 4 週間の試行なら、完全な予測を待つより、危険を限定して学ぶ方がよい場合があります。全顧客へ不可逆な変更を加えるなら、より強い証拠と承認が必要です。

証拠を比べるときは、少なくとも次を確認します。

• 関連性: 今回の顧客、選択肢、判断基準に直接関係するか
• 信頼性: 定義、収集方法、欠損、発言者の立場を確認できるか
• 識別力（見分ける力）: 仮説以外の説明をどこまで除き、複数の説明を見分けられるか
• 適時性: 現在の状況を表し、決定期限に間に合うか

強い証拠を一律に順位づけるのではありません。顧客の経験を知る証言と、行動の広がりを知るログでは、答えられる問いが違います。複数の証拠が矛盾するときは、多数決にせず、対象、定義、時点、収集方法の違いを調べます。

逆算するときは、次の順に問いかけます。

1. 期限に、誰が何を選ぶのか
2. 選択肢を何で比較するのか
3. その比較に必要な証拠は何か
4. 現在ある証拠と、足りない証拠は何か
5. 足りない証拠を、期限内にどの方法で得るか
6. 証拠が得られない場合、何を小さくするか、延期するか、見送るか

この順序なら、調査手法は目的に従います。インタビューをすることが先に決まるのではなく、顧客が初期価値を得られない理由を確かめるために、行動データだけでは分からない経験を聞きます。

3.3 仮説と証拠を一枚で結ぶ

必要な証拠を作業へ落とす前に、仮説、反証条件、証拠、判断への影響を結びます。本書では、これを「仮説・証拠表」と呼びます。

反証条件を書くのは、仮説を否定するためではありません。何が分かれば方針を変えるのかを、結果を見る前に決めるためです。反証条件がなければ、どの結果も「一部は仮説を支持している」と解釈できます。

ただし、一つの観測だけで仮説を確定しないようにします。初期設定の未完了と解約に関連があっても、顧客の規模や利用目的が両方へ影響しているかもしれません。表には、代替説明と証拠の限界も残します。

また、4 週間の試行で直接確かめられるのは、支援の実施率、初期設定の完了、顧客の反応、支援工数といった近い結果です。90 日以内解約への効果は、試行期間後も追跡しなければ分かりません。「運用できた」「先行指標が動いた」「長期成果が変わった」を分け、前の 2 つだけで施策の最終効果を断定しません。

仮説・証拠表は、立派な分析を増やすための道具ではありません。「この分析結果で、どの判断が変わるのか」と問うための道具です。結果がどちらでも判断が変わらない項目は、優先順位を下げられます。

3.4 ワークストリームは問いで分ける

ワークストリームとは、一定の成果へ向けた関連作業のまとまりです。部門名や手法だけで分けると、分析、インタビュー、競合調査がそれぞれ進み、最後まで接続されないことがあります。

この案件なら、次のように「答える問い」で分けます。

次に、依存関係を確認します。顧客群を定義できなければ、試行対象を選べません。支援手順が決まらなければ、工数を測れません。一方、顧客への聞き取りとデータ定義の確認は、早い段階から並行できます。

作業を細かく分解する前に、次の 3 種類を見分けます。

• 先に終える必要があるもの: 後の作業の前提になる
• 並行できるもの: 同じ前提を待たずに進められる
• 結果次第で行わないもの: 初期の証拠によって必要性が決まる

すべての作業を初日に確定すると、初期仮説が崩れても計画だけが残ります。後半の詳細は、前半で得る証拠に合わせて段階的に具体化します。

3.5 マイルストーンは判断の場として置く

「データ分析完了」「インタビュー完了」は進捗を示しますが、プロジェクトの方向を変える条件が分かりません。マイルストーンには、日付だけでなく、その時点で確認または決定することを置きます。

会議は情報共有のためだけに置きません。事前に、決めること、必要な資料、決定者、未決の場合の扱いを明らかにします。共有だけで済む内容は文書で伝え、対話が必要な論点へ会議時間を使います。終了後は、決定、根拠、保留事項、次に動く責任者と期限を短く残します。

また、決定者が最終会議で初めて分析を見る設計は危険です。途中のマイルストーンで、判断基準、証拠の強さ、未解決の対立を確認します。ただし、頻繁な確認が現場の作業を止める場合は、変更の権限と報告の閾値（しきいち。対応を切り替える境界）を決め、会議を減らします。

3.6 責任は成果物ではなく判断まで割り当てる

担当表で「分析資料: A さん」「インタビュー: B さん」と決めても、定義の不一致や方針変更を誰が解決するかは残ります。少なくとも、次の役割を区別します。

• 決定者: 選択肢から方針を選び、理由を引き受ける
• スポンサー: プロジェクトの必要性を支え、組織上の障害を取り除く
• プロジェクト責任者: 問い、証拠、作業、期限のつながりを保ち、複数のワークストリームから得た証拠の矛盾を整理する
• 作業責任者: ワークストリームの中間成果と品質に責任を持つ
• 実行責任者: 決定後の施策を運用する
• 助言・影響を受ける人: 専門知や当事者の視点を提供する

小さな案件では、一人が複数の役割を持ちます。それでも、どの立場で判断しているかを明らかにします。反対に、大きな案件で全員をあらゆる判断へ参加させると、責任が曖昧になります。

責任分担表を作ることが目的ではありません。重要な論点ごとに、「誰が案を作り、誰の意見を聞き、誰が最終的に決めるか」を確認します。データ定義、スコープ変更、試行開始、停止といった判断には、決定者を一人または明確な意思決定機関として置きます。

3.7 計画は不確実性に合わせて変える

国際標準化機構（ISO）の規格 ISO 21502 は、プロジェクトマネジメントの指針を、予測型、反復型、適応型、ハイブリッドなどの進め方に適用できるものとしています。以下の使い分けは、ISO が特定の方法を推奨しているという意味ではなく、本書の実務上の整理です。案件全体へ一つの型を当てはめるより、不確実性の種類に合わせます。

法令上の期限、取締役会の日程、契約上の納品日は、早く固定する必要があります。一方、顧客がなぜ離脱するか、どの支援が有効かは、調べる前に詳細を固定できません。この案件では、決定日と安全条件は固定し、調査内容と試行案は証拠に応じて更新します。

更新に備えて、前提を短く記録します。

データだけでなく、人へのアクセスも開始時に確かめます。決定者、顧客、現場担当者へ必要な時期に接触できないなら、代わりに誰へ確認するか、どの証拠で補うか、誰へ障害を報告するかを決めます。代替手段では判断に必要な質を満たせない場合、アクセスが得られるまでスコープを縮めるか、案件を止めます。

計画変更では、変更理由、問いと成果物への影響、期限・費用・危険への影響、承認者を残します。変更を避けることより、根拠のない変更と、古い前提の放置を避けます。

英国財務省の評価指針 Magenta Book は、施策の投入、活動、結果へ至る因果の連鎖と、その前提を Theory of Change（変化の理論）として明示し、関係者と検討しながら更新することを勧めています。政策評価向けの指針ですが、「なぜその作業が結果につながると思うのか」を可視化し、実施前から評価を設計する考え方は、コンサルティングのプロジェクトにも応用できます。

ただし、図を精緻にするほど未来が正確になるわけではありません。因果の鎖は、確定した設計図ではなく、証拠によって更新する仮説です。

3.8 AI は計画の穴を探す相手になる

AI は、作業候補の展開、依存関係の指摘、見落とした関係者や失敗条件の列挙に使えます。特に、意思決定の問いと仮説・証拠表を渡すと、一般的な「市場調査をする」といった案より、目的に沿った批判を得やすくなります。

意思決定の問い:
事業責任者が 8 月末までに、どの顧客群へどの初期支援を試すか決める。

判断基準:
期待効果、顧客への危険、支援工数、実行可能性、学習価値。

現在の仮説・証拠表:
[表を貼る]

依頼:
1. 各作業がどの証拠と意思決定に寄与するか対応づける
2. 前提となる作業と並行できる作業を分ける
3. 結果次第で不要になる作業を示す
4. 証拠が弱いまま決定する危険を挙げる
5. 4 週間では過剰な作業を指摘する

事実を補わず、不明点は不明と記すこと。

出力は、そのまま工程表にしません。AI は、社内政治、担当者の力量、データの実情、暗黙の承認手順を知りません。もっともらしい担当者名や所要日数を作ることもあります。作業責任者と決定者が、現場で実行できるかを確認します。

機密情報や個人情報を外部サービスへ入力できない場合は、承認された環境を使うか、情報を抽象化します。抽象化によって重要な条件が失われるなら、AI を使わず、関係者との設計を優先します。

AI に任せられないのは、誰に責任を持たせるか、どの危険を受け入れるか、証拠が弱い状態で決めるかという判断です。AI は計画の候補と批判を増やせますが、権限と説明責任は割り当てられません。

3.9 一枚のプロジェクト設計書

小さな案件で、厚い計画書を作る必要はありません。少なくとも次を一枚に置けば、意思決定と作業のつながりを確認できます。

1. 意思決定: 誰が、現状維持を含むどの選択肢から何を、いつ、何の基準で決めるか
2. 仮説と証拠: 何を支持・反証する、どの証拠が必要か
3. ワークストリーム: どの問いへ、誰が答えるか
4. マイルストーン: いつ、誰が、何を確認・決定するか
5. 成果物: 各成果物がどの決定に使われるか
6. 前提と危険: 何が崩れたら、誰がどう変えるか
7. 実行への接続: 決定後、誰が実行し、何を追跡するか
8. 扱わないこと: 今回行わない調査・施策と、見直す条件

この一枚は、プロジェクトの要約です。仮説・証拠表、詳細工程、前提ログは、複雑さに応じて別紙にします。一枚を埋めることが目的ではありません。項目同士をたどり、孤立した作業や、証拠のない判断や、決定者のいない会議を見つけます。

小さく取り消しやすい判断では、数十分で暫定版を作り、動きながら更新できます。その際も、調査に使える期間、人員、費用の上限を先に置きます。上限までに証拠が揃わなければ、危険を限定して小さく試す、計測を整える、決定を延期する、見送る、のいずれかを決定者が選びます。計測を整える場合も、将来のどの判断が改善し、その価値が整備費用を上回るかを確認します。調査を続ける場合は、追加調査でどの判断が変わりうるかを説明します。

大規模投資、法的責任、安全、人員削減を伴う案件では、専門家による確認、より強い証拠、正式な承認と監査可能な記録が必要です。法令へ適合するだけでなく、影響を受ける人への公平性と、決定理由を説明できるかも確認します。設計の項目は同じでも、求める深さは同じではありません。

考えてみる問い

最近行ったプロジェクトを一つ選び、成果物から意思決定まで逆向きにたどってください。その成果物がなければ、誰のどの判断ができなくなるでしょうか。答えられない成果物や作業があれば、なぜ必要だったのかを見直してみましょう。

プロジェクト設計の質は、作業数の多さでは決まりません。意思決定、証拠、作業、責任、期限がつながり、新しい事実によって更新できるかで決まります。

設計ができたら、次は何を先に確かめるかを決めます。第4章では、仮説を使って調査範囲を絞り、結果によって次の行動を変えられる状態を作ります。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の「仮説・証拠表」と「一枚のプロジェクト設計書」は、以下の資料を踏まえた本書独自の整理です。

• ISO ― ISO 21502:2020 Project, programme and portfolio management — Guidance on project management
• HM Treasury ― The Magenta Book: Central Government guidance on evaluation
• HM Treasury ― Test and Learn

第2部 仮説と論理

調査を始める前に、何が分かれば判断が変わるのかを考えます。この部では、仮説によって調査を絞り、論点の関係を組み立て、事実と根拠から結論を導く方法を扱います。

仮説も論理も、最初の考えを正しく見せるための道具ではありません。反対の証拠や別の説明を受け入れ、考えを更新できる状態を作るための道具です。

第4章 仮説は調査を減らすためにある

第3章では、新規顧客の 90 日以内解約を題材に、意思決定から必要な証拠へ逆算しました。その中で、「初期設定を完了しない顧客ほど解約しやすい」「手動支援で初期設定の完了が増える」といった仮説を置きました。

仮説を持たずに調査すると、入手できる情報を広く集めることになります。顧客属性、利用ログ、競合事例、解約理由、価格、サポート履歴のどれも関係しそうです。調べるほど新しい論点が見つかり、終わる条件がなくなります。

反対に、仮説を早く一つに絞ると、その仮説に合う情報だけを集める危険があります。仮説は調査を速くする一方で、視野を狭めます。

本章では、仮説を意思決定の問いに対する、証拠によって更新できる暫定的な答えと定義します。仮説の目的は、正解を先に言い当てることではありません。次に何を確かめるか、結果によって何を変えるかを決め、不要な調査を減らすことです。

実務では、仮説を作る、競合する仮説から優先するものを選ぶ、見分ける証拠を集める、評価と資源配分を更新する、必要な確かさで調査を終える、という順に進めます。新しい証拠によって問いが変われば、前の段階へ戻ります。

4.1 仮説と推測を分けるもの

「オンボーディングが悪いと思う」は推測です。出発点としては使えますが、このままでは、何を観測すれば見直すのかが分かりません。

検証に使える仮説には、少なくとも次の要素があります。

仮説を長い一文にする必要はありません。重要なのは、言葉の格好ではなく、観測と判断につながることです。

「顧客は使いにくいと感じている」のように、対象者の心の中だけで終わる表現は確かめにくいものです。何を行おうとしたか、どこで止まったか、どのように語ったかへ落とします。ただし、行動だけで感情や理由を断定しません。ログで行動を確かめ、インタビューで経験を聞き、両者の違いも証拠として扱います。

また、仮説は事実の言い換えではありません。「解約した顧客は契約を終了した」では新しい予測を生みません。複数の観測を説明し、まだ見ていない結果を予測できる形にします。

仮説の種類によって証拠は変わる

「仮説」という一語には、異なる問いが含まれます。本書では、次のように区別します。

前の種類が支持されても、後の種類が自動的に支持されるわけではありません。初期設定未完了と解約に関連があっても、手動支援で解約が減るとは限りません。関連を生む別の要因、支援による顧客体験への悪影響、運用上の制約を別に確かめます。

案件によっては、介入や比較可能な状況を作れず、観察データしか得られません。その場合は、原因を特定したと断定せず、残る代替説明と不確実性を示したうえで、取り消しやすさに応じて判断します。

4.2 一つの「原因」を急いで選ばない

目立つ仮説を一つだけ置くと、調査は速く見えます。しかし、その仮説が誤っていたとき、次にどこを見るか分かりません。重要な意思決定では、競合する仮説を並べます。

解約率上昇について、次の候補を置けます。

表の H は hypothesis（仮説）を見分けるための記号で、重要度の順位ではありません。

候補を増やす目的は、可能性を網羅することではありません。同じ証拠を見たときに、どの説明がより妥当になるかを比較することです。

クライアントがすでに持つ仮説も、否定してから作り直す必要はありません。重要な初期情報として候補に置き、どの予測が成り立つか、何が観測されたら見直すかを一緒に決めます。発言者の役職ではなく、競合する説明と証拠によって評価します。

たとえば「未完了群の解約率が高い」という結果は H1 と整合します。しかし、H2 も、適合しない顧客が初期設定を完了せず解約すると予測できます。この観測だけでは両者を見分けられません。獲得経路や利用目的を分けた比較、初期設定を支援した後の変化など、競合仮説を見分ける証拠が必要です。

一方、緊急障害への対応のように、原因候補を広く並べる時間がない場面もあります。その場合は、被害を止める暫定対応と、原因を確かめる作業を分けます。速度を優先して仮説を絞ったこと、そのために残る危険を記録します。

4.3 仮説の優先順位は情報量だけで決めない

すべての仮説を同じ深さで調べると、仮説を置いた意味がなくなります。最初に確かめる仮説は、次の観点で選びます。

• 判断への影響: 結果によって選択が変わるか
• 不確実性: 現在の証拠では、どちらとも言えないか
• 見分ける力: 一度の確認で、競合する説明を分けられるか
• 確認費用: 時間、人員、費用、顧客負担はどの程度か
• 失敗時の危険: 誤ったまま進めたとき、取り返せるか

確率が高そうな仮説から調べるとは限りません。成立しても判断が変わらない仮説は、優先度が低くなります。可能性は低くても、顧客の安全や法令違反に関わる仮説は先に確認します。

今回なら、最初に計測定義を確認する費用は小さく、H5 が成立すれば他の分析の前提が変わります。次に、既存データで顧客群と初期行動の関係を確認します。その結果を受けて、顧客への聞き取りや小規模試行を設計します。

計測定義を確認する
  ├─ 変化あり → 数値を再計算し、問題設定へ戻る
  └─ 変化なし → 顧客群と初期行動を比較する
                   ├─ 特定群に集中 → H1 と H2 を見分ける
                   └─ 集中しない → H3、H4 などへ重点を移す

この順序は固定の正解ではありません。利用できるデータ、決定期限、危険によって変わります。重要なのは、各調査の前に「結果が A なら何をし、B なら何をしないか」を決めることです。

4.4 支持する証拠より見分ける証拠を探す

仮説を立てると、人は仮説に合う証拠を探し、曖昧な証拠を都合よく解釈しやすくなります。ここでは、人がどのように仮説を確かめようとするかを研究した心理学者たちの知見を使います。

米国の心理学者 Raymond S. Nickerson（レイモンド・S・ニッカーソン）は、既存の信念、期待、手元の仮説に偏る形で証拠を探したり解釈したりする現象を、過去の研究を検討した論文で「確証バイアス」として広く整理しました。本章では、人は必ず偏ると言うためではなく、調査設計に反対証拠と代替仮説の確認を組み込む根拠として参照します。

実務上の原則は、支持例を避けることではありません。その証拠が競合する仮説でも同じように起きるかを比べ、仮説を見分ける力を確かめることです。

英国の認知心理学者 Peter C. Wason（ピーター・C・ウェイソン）が 1960 年に報告した規則発見課題では、参加者が自分の仮説と整合する例を試し続け、別の規則を十分に排除できない傾向が示されました。この研究は、推論や仮説検証を実験で調べる研究の初期の代表例です。ただし、「仮説に合う例を試すことは常に誤り」と単純化してはいけません。

当時シカゴ大学の意思決定研究センターに所属していた Joshua Klayman（ジョシュア・クレイマン）と Young-Won Ha（ハ・ヨンウォン）は、Wason 以後の議論を再検討しました。二人は、仮説が正しいなら当てはまりそうな事例を調べる「正の検査方略」が、条件によっては効率的な方法になりうると論じました。問題は、支持例を調べたこと自体ではなく、その結果が競合する仮説でも同じように起きるかを考えないことです。

たとえば、「解約した顧客に、初期設定で困りましたか」と聞き、多くの人が「はい」と答えても、H1 の強い証拠とは限りません。継続した顧客も同じ程度困っていたかもしれないからです。次のように質問を変えます。

• 解約顧客と継続顧客の両方で、同じ経験を確認する
• 初期設定以外の候補も、同じ条件で確認する
• 回答者へ原因を選ばせる前に、実際の行動経過を聞く
• 仮説を知らない分析者にも、記録の一部を分類してもらう
• 仮説と合わない事例を、除外せず詳しく調べる

反証候補を決めても、一件の例外で直ちに仮説を捨てるとは限りません。計測誤り、対象範囲、同時に置いた前提も確認します。科学的方法を論じた Karl Popper の反証可能性は、仮説が観測と衝突しうることを重視しますが、実務上の一回の観測は複数の前提に依存します。本書は科学哲学を事業判断の機械的な規則として使うのではなく、反対の観測を受け入れられる仮説を書くための示唆として用います。

そのため本書では、「反証する」だけでなく「どの観測なら、どの前提を、どの程度見直すか」と記録します。仮説を守るために毎回条件を後付けするのも、一件の異常値で全体を捨てるのも避けます。

4.5 仮説は支持、保留、棄却の三択ではない

現実の証拠は、きれいに一致または不一致へ分かれません。調査のたびに、仮説と行動を次のように更新します。

更新の理由を短いログに残します。

仮説: 初期設定の未完了が解約を増やしている
更新前: 重点 高
新しい証拠: 未完了群で解約率が高いが、獲得経路を分けると差が小さい
代替説明: 特定の広告経路から、適合しない顧客が増えた
更新後: H1 は中、H2 は高
次の確認: 獲得経路別の利用目的と解約理由を確認する
判断への影響: 全顧客への支援試行は保留する
資源の変更: 支援手順の詳細設計を止め、分析責任者が獲得経路の分析へ 2 日を移す

評価では、事前に置いた予測との一致、競合する仮説との差、説明のために後から追加した前提の少なさを確認します。追加前提の少なさは、必要な複雑さまで排除するという意味ではありません。各前提を独立して確かめられるか、予測を具体的にするかを見ます。結果を見るたびに条件を足す仮説は、多くを説明しているように見えても、次の予測には使いにくくなります。

数値で確率を付ける方法もありますが、根拠のない精密さを生むなら「高・中・低」で十分です。尺度より、何を受けて評価を変えたかが重要です。

また、仮説の持ち主と評価者が同じだと、愛着が生まれます。重要な案件では、仮説を考えた人とは別の人が、反対証拠と代替説明をレビューします。評価を人事評価と結びつけると、仮説を捨てにくくなるため、「早く誤りを見つけたこと」を失敗として扱わない運営も必要です。

各仮説には、証拠を集めて更新案を作る責任者を置きます。これは仮説の成立を証明する責任ではありません。重点や調査範囲の変更は、意思決定者またはプロジェクト責任者と、決めたマイルストーンで確認します。評価が割れた場合は、異論、判断を保留する点、次に必要な証拠を残します。変更が期限、費用、成果物へ影響する場合は、仮説ログだけでなくプロジェクトの変更記録にも残します。

4.6 AI には仮説の数より差を作らせる

AI は、原因候補を大量に出せます。しかし、「考えられる原因を 30 個」と頼むだけでは、言い換えが増え、優先順位を付ける負担が人間へ戻ります。

AI へは、競合仮説の違いと、見分ける観測を求めます。

意思決定:
8 月末までに、どの顧客群へどの初期支援を試すか決める。

観測:
新規顧客の 90 日以内解約率が直近 3 か月で上昇した。

現在の仮説:
H1 初期価値の不足
H2 顧客構成の変化
H3 価格と期待のずれ
H4 サービス品質
H5 計測の変化

依頼:
1. 各仮説が正しい場合に特徴的な予測を示す
2. 一度の確認で複数の仮説を見分けやすい証拠を挙げる
3. 各証拠について、結果 A と結果 B で次の行動がどう変わるか示す
4. 現在の候補では説明できない観測を指摘する
5. 与えられていない事実を補わず、不明と記す

出力では、仮説同士が本当に異なるかを確認します。「顧客が価値を感じない」と「価値が伝わっていない」は、予測する観測が同じなら、現段階では分ける意味が小さいかもしれません。反対に、一つの広い仮説が条件によって違う予測を生むなら分けます。

AI に反対役をさせる場合も注意が必要です。AI は、もっともらしい反論を作れますが、それが実際の証拠とは限りません。AI が挙げた事例、数値、制度、顧客の声は、原資料や現場で確認します。

入力した仮説の枠内でしか答えない危険もあります。最後に「この仮説群すべてが誤っているとしたら、どの観測を説明できないか」と尋ねます。それでも、現場を知る人、影響を受ける人、異なる専門家の視点を置き換えるものではありません。

4.7 調査を終える条件を先に置く

仮説検証は、真実を完全に確定するまで続ける仕事ではありません。意思決定に必要な確かさへ達したら止めます。

調査前に、次の終了条件を決めます。

1. どの仮説を、どの選択肢の判断に使うか
2. 何が観測されたら、重点を上げ、下げ、捨てるか
3. どの競合仮説を見分ける必要があるか
4. 調査に使える時間、人員、費用の上限は何か
5. 証拠が不足したまま期限を迎えたら、誰が何を決めるか
6. 顧客、安全、法令への危険から、先に否定すべきことは何か

小さく取り消しやすい判断では、すべてを文書化する必要はありません。最低限、「現在の暫定回答」「反対なら何が観測されるか」「結果ごとに次の行動をどう変えるか」の 3 点を決めて始めます。影響が大きく不可逆な判断ほど、競合仮説、証拠の質、承認と記録を詳しくします。

調査を止められる典型的な状態は、次のとおりです。

• 追加情報を得ても、選ぶ案が変わりそうにない
• 重要な競合仮説を、必要な程度まで見分けられた
• 取り消し可能な試行へ進めるだけの安全、法令、必要な同意の条件が揃った
• 調査費用が、判断改善によって得られる価値を上回る
• 期限または資源の上限に達し、不確実性を明示して決める必要がある

調査の終了と施策の継続は、別の判断です。仮説が弱まったときは、調査だけでなく、その仮説に基づく開発、営業、運用を止める条件も確認します。施策を続けるなら、別の根拠と責任者を明らかにします。

「仮説が証明されたから終わる」とは限りません。事業上の仮説は、条件が変われば成り立たなくなります。今回は採用した仮説も、どの条件で、どの証拠まで確認したかを残します。

考えてみる問い

最近行った調査を一つ選び、その調査結果が A でも B でも同じ判断をしていなかったか確認してください。同じなら、その調査は何のために必要だったのでしょうか。次に調べるなら、どの競合仮説を見分ける証拠を選ぶでしょうか。

よい仮説は、正しそうに聞こえる仮説ではありません。観測によって評価が変わり、次の行動を変えられる仮説です。仮説を作り、優先し、競合する説明を見分け、評価と資源を更新し、必要な確かさで止めることで、調査範囲を狭めます。

複数の仮説を扱うには、論点を分け、その関係を混同しない技術が必要です。第5章では、分解の目的と、ロジックツリーや因果関係の違いを扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の仮説の 6 要素、優先順位、更新区分、終了条件は、以下の資料を踏まえた本書独自の整理です。

• P. C. Wason ― On the Failure to Eliminate Hypotheses in a Conceptual Task ― 英国の認知心理学者 Wason による規則発見課題と、別の仮説を十分に排除できない傾向を確認
• Joshua Klayman and Young-Won Ha ― Confirmation, Disconfirmation, and Information in Hypothesis Testing ― シカゴ大学意思決定研究センターの二人による、正の検査方略が有効になる条件と誤りを生む条件の整理を確認
• Raymond S. Nickerson ― Confirmation Bias: A Ubiquitous Phenomenon in Many Guises ― 米国の心理学者 Nickerson による、確証バイアス研究の広範なレビューを確認
• Stanford Encyclopedia of Philosophy ― Scientific Method

第5章 論点を分け、関係を組み立てる

第4章では、解約率上昇について複数の仮説を置き、見分ける証拠を考えました。しかし、仮説が増えると、どれが同じ種類の問いで、どれが別の階層にあり、どれが互いに影響するのか分かりにくくなります。

そこで、複雑な問いを小さな論点へ分けます。コンサルティングでは、MECE（重複なく、全体として重要な漏れがない分け方）や、論点を枝分かれさせるロジックツリーという言葉で説明されることが多い仕事です。

分解には危険もあります。売上を単価と数量へ分けること、顧客を契約規模で分類すること、解約の原因を並べることは、いずれも木の形で描けます。しかし、三つの関係は同じではありません。計算上の関係を因果関係と読み違えたり、重なりのある原因を無理に箱へ入れたりすると、整った図が誤った判断を導きます。

本章では、分解を意思決定の問いを、答えられる下位の問いへ変換し、その関係を明示することと定義します。目的は、きれいな木を作ることではありません。何を調べ、どこまで分かれば、上位の問いに答えられるかを明らかにすることです。

実務では、親の問いを定め、関係の種類を選び、重複と重要な漏れを点検し、判断を変える枝を優先し、証拠を得られる単位で止めます。木で扱えない相互依存があれば、因果図やループへ移ります。

5.1 分ける前に、上位の問いを固定する

「解約率を分解してください」という依頼だけでは、分け方を決められません。何を判断したいかによって、適切な軸が変わります。

同じ「解約」というテーマでも、判断が違えば構造も変わります。最初に、親となる問いを一文で書きます。

事業責任者は 8 月末までに、
どの顧客群へ、どの初期支援を試すべきか。

次に、その問いへ答えるために必要な下位の問いを置きます。

どの顧客群へ、どの初期支援を試すべきか
├─ どの顧客群で解約が増えているか
├─ その顧客群では、何が解約を生んでいるか
├─ どの支援なら原因へ働きかけられるか
└─ どの支援なら安全かつ既存人員で実行できるか

各枝へ答えても親の問いに答えられないなら、分解がずれています。反対に、親の問いへ答えるために使わない枝は、興味深くても今回の優先度を下げます。

5.2 木の形より関係の種類を選ぶ

論点を分ける方法は一つではありません。少なくとも、次の 4 種類を区別します。

分類

対象を、同じ軸で集まりへ分けます。

新規顧客
├─ 小規模顧客
├─ 中規模顧客
└─ 大規模顧客

分類は、「どこで起きているか」「誰を対象にするか」を比べるときに向きます。分類軸は、契約金額、従業員数、利用者数などから、判断に合うものを選びます。「大企業」「高単価」「戦略顧客」のように異なる軸を兄弟へ置くと、同じ顧客が複数へ入り、比較の分母が崩れます。

計算

上位の数値を、数式で構成する要素へ分けます。

売上
= 顧客数 × 顧客あたり平均売上

顧客数
= 前期顧客数 + 新規顧客数 - 解約顧客数

計算分解は、数字の変化がどの項から生じたかを確認するときに向きます。式が成り立つよう、単位、期間、平均の定義を揃えます。

ただし、式の要素は原因とは限りません。「売上が下がったのは顧客数が減ったから」は計算上の説明です。なぜ顧客数が減ったかを知るには、別の原因仮説が必要です。

過程

時間または仕事の順序で分けます。

広告を見る
─[次の工程]→ 資料を請求する
─[次の工程]→ 商談する
─[次の工程]→ 契約する
─[次の工程]→ 初期設定を完了する
─[次の工程]→ 継続利用する

過程分解は、どこで停滞や離脱が起きるか、誰が引き継ぐかを調べるときに向きます。現実の顧客は前後したり、工程を飛ばしたり、戻ったりします。図を標準的な流れとして使い、例外経路も確認します。

因果

ある要因の変化が、別の要因の変化を生むという仮説を結びます。

適合しない顧客の獲得増
          ↓
初期設定の未完了増
          ↓
価値を体験できない顧客の増加
          ↓
90 日以内解約の増加

矢印は、時間順や相関だけを意味しません。「前の要因へ介入したら、ほかの条件のもとで後の結果が変わる」という因果仮説です。Judea Pearl は、観測した条件付き確率と、外部から介入したときの結果を表すために異なる記法を導入し、統計的関連と因果的介入を区別しました。

因果図は、矢印を描くことで因果を証明するものではありません。時間順序、共通原因などの交絡候補、途中で働く媒介要因、測定の誤り、分析対象を選ぶ過程による偏りを確認します。必要な証拠を得られない矢印には、不確実性を残します。

因果関係は、分類のように重なりなく並ぶ必要はありません。複数の原因が同時に働き、同じ原因が複数の結果を生み、結果が原因へ戻ることもあります。木よりネットワークや因果ループ図が適する場合があります。

5.3 MECE は問いに対する点検基準

MECE は、Mutually Exclusive（互いに重ならない）、Collectively Exhaustive（合わせて全体を覆う）の略です。本書では、ある親集合に対して、子集合が互いに重ならず、定めた範囲を合わせて覆う状態とします。

MECE は、世界を唯一正しく分類する原理ではありません。親となる集合、分類軸、目的を決めたときに初めて判定できます。

分類を始める前に、母集団、基準時点、分類不能と欠損の扱いを決めます。「新規顧客全体」が、全契約データを指すのか、行動ログを取得できた顧客だけを指すのかで、網羅性の意味は変わります。分類不能を消さず、件数と理由を残します。

たとえば、顧客を「新規顧客」「既存顧客」に分けるとします。契約から何日までを新規と呼ぶか決めなければ、境界は曖昧です。「新規」「解約危険が高い」「大企業」なら、契約時期、危険度、規模という異なる軸が混ざり、重複します。

重複が問題になるのは、同じものを二重に数えたり、責任を二重に割り当てたりするときです。一方、原因仮説には重なりがあります。価格への不満と初期価値の不足が一緒に解約へ影響するかもしれません。ここで無理に排他的な箱を作るより、相互作用を残す方が正確です。

したがって、本書では MECE を分類に対して直接使います。イシューツリーでは、質問を集合のように扱って「MECE である」と断定せず、重複調査がないか、親の判断を変える重要論点が漏れていないかを点検します。原因候補では、重なりを消さず、主要な代替説明を残します。

「漏れなく」にも限界があります。考えうる原因をすべて列挙することはできません。実務で必要なのは、現在の意思決定を重大に変える候補を見落としていないことです。次の問いで点検します。

• 親の問いに対して、同じ種類・同じ抽象度で分けているか
• 重複によって二重計上や責任の曖昧さが起きないか
• 見落とすと判断を変える重要な項目がないか
• 「その他」が大きすぎて、主要な現象を隠していないか
• 分ける費用が、判断の改善に見合うか

「その他」は、判断に影響しないほど小さく、内容が安定している間は残せます。割合や重要な事例が増え、既存分類の結論を変えうるようになったら、中身を調べて分類軸を見直します。固定の数値基準ではなく、判断への影響で閾値を決めます。

分類、集計、責任分担では MECE を厳しく求める価値があります。探索初期の原因候補、顧客の語り、複雑なシステムでは、重なりや未知を残します。MECE にすることより、どこが重なり、どこが未確認かを明示する方が役立つ場合があります。

5.4 イシューツリーは質問を分ける

本書では、意思決定の問いを、答えられる下位の問いへ分けたものをイシューツリーと呼びます。名前や図形より、親子関係を文章で読めることが重要です。

よい親子関係は、次のように確認できます。

親の問いへ答えるには、子の問いへの答えを、依存関係と判断基準を踏まえて統合すれば十分か。

先ほどの例には、まだ飛躍があります。「どの顧客群で解約が増えたか」「原因は何か」「どの支援が可能か」が分かっても、支援案を比較する基準がありません。そこで、判断基準を含めて直します。

どの顧客群へ、どの初期支援を試すべきか
├─ 対象: 解約増加が集中し、支援で変えられる顧客群はどこか
├─ 効果: どの支援が原因仮説へ働きかけ、先行指標を変えうるか
├─ 危険: 顧客への不利益と停止条件は何か
├─ 実行: 既存人員と 4 週間で運用できるか
└─ 学習: 次の判断に使える証拠を得られるか

枝は、答えの候補ではなく質問です。「オンボーディング改善」「価格変更」「広告停止」と並べると、最初の施策案に分析が固定されます。選択肢を広げる段階では使えますが、原因を調べる問いと混ぜません。

イシューツリーを細かくしすぎると、末端の作業が増えます。各枝に対して、次を確認します。

• 答えが変わると、親の答えも変わるか
• 期限内に証拠を得られるか
• すでに十分な証拠がないか
• ほかの枝と同じ調査で答えられないか
• 重大な危険を先に確かめる必要がないか

答えが親の判断を変えない枝は削ります。重要でも期限内に答えられない枝は、不確実性として残し、判断を小さくするか延期します。

今回の 4 週間の案件では、まず低費用で H5「計測の変化」を確認します。定義に問題がなければ、既存データで対象顧客の枝を調べます。顧客への重大な危険を確認する枝は可能性が低くても先行します。

今回扱わないこととして、長期的なプロダクト改修の実行可能性は、追加開発なしという制約から除外します。枝の除外は意思決定者と合意し、理由と戻す条件を残します。短期支援で先行指標が動かない、重大な顧客事例が見つかる、追加開発の制約が変わる場合は、改修の枝を戻します。判断への影響、不確実性、確認費用、重大な危険を比べ、対象、危険、短期の効果と実行可能性へ時間を使います。

枝を作業へ移すときは、各枝の責任者に加え、共通データの定義と証拠の再利用を管理し、枝間の矛盾を統合するプロジェクト責任者を置きます。顧客分析と原因分析が同じログを使うなら、別々に抽出せず、定義、抽出日、加工、欠損、抽出履歴を一つの記録で共有します。

5.5 ロジックツリーと因果図を混同しない

「ロジックツリー」は、実務で広い意味に使われます。分類、計算、質問、原因候補のどれも、ロジックツリーと呼ばれることがあります。本書では曖昧さを避けるため、分類木、計算木、イシューツリー、因果図と呼び分けます。ここでは種類を再説明するのではなく、一つの図から別の図へ移るときに生じる推論の飛躍を確認します。

一つの案件では、複数の図をつなぎます。計算木で「解約顧客数の増加が売上減少へ大きく寄与した」と確認し、分類木で「特定の獲得経路に集中している」と見つけ、因果図で「適合しない顧客の獲得が初期未完了と解約を生んだ」という仮説を置き、イシューツリーで必要な調査を決めます。

ただし、4 種類すべてを成果物として作る必要はありません。現在の判断で関係を誤りそうな箇所にだけ使います。数値の寄与が不明なら計算木、対象が不明なら分類木、調査範囲が曖昧ならイシューツリー、介入の波及を考えるなら因果図を選びます。別の関係へ飛躍する必要が生じたときだけ、図を追加します。

図を移るたびに、推論の種類が変わります。計算上の寄与から原因へ移る場所、観測上の関連から介入案へ移る場所に、仮説と必要な証拠を記します。

5.6 木で表せない関係を残す

木は、一つの親から複数の子へ分かれる階層を見やすくします。しかし、組織や市場には、相互依存とフィードバックがあります。

たとえば、解約率が上がると、顧客対応者は解約防止へ時間を使います。新規顧客への支援が減り、初期設定の未完了が増え、さらに解約が増えるかもしれません。

解約増加
   ↓
解約防止対応の増加
   ↓
新規顧客への支援減少
   ↓
初期設定未完了の増加
   ↓
解約増加

これは、始点と終点が同じ強化ループです。各矢印は同時に起きるとは限らず、数日から数か月の遅れを含む仮説です。原因を一方向の木にすると、「担当者の支援不足」という一箇所だけを責める可能性があります。実際には、負荷が次の負荷を生む構造かもしれません。

経済協力開発機構（OECD）と国際応用システム分析研究所（IIASA）のシステム思考に関する報告は、複雑な政策課題で、要素だけでなく相互関係とフィードバックループを確認する必要性を示しています。企業のすべての案件に大規模なシステム分析が必要なわけではありませんが、部門をまたぐ問題、遅れて効果が出る施策、同じ問題が繰り返す状況では有用です。

木で始めても、次の合図があればネットワークやループへ移ります。

• 一つの要因が複数の枝へ現れる
• 原因と結果が時間の経過で入れ替わる
• 一部を改善すると別の場所が悪化する
• 部門ごとの最適化が全体を悪化させる
• 施策の効果が遅れて現れ、追加施策と干渉する

複雑な図を作ることが目的ではありません。意思決定に重要な関係だけを残し、矢印ごとに根拠と不確実性を示します。

5.7 AI が作る整った構造を疑う

AI は、箇条書きを分類し、ツリー形式へ整えるのが得意です。しかし、見た目の対称性と論理的な妥当性は別です。異なる軸を同じ階層へ並べ、存在しない因果関係を補い、「その他」を加えて MECE だと主張することがあります。

AI へは、ツリーを作らせるだけでなく、関係を明記させます。

親の問い:
どの顧客群へ、どの初期支援を試すべきか。

判断基準:
期待効果、顧客への危険、支援工数、実行可能性、学習価値。

依頼:
1. 親の問いを、答えられる下位の問いへ分ける
2. 各分解が、分類、計算、過程、因果、質問のどれかを明記する
3. 同じ階層で軸や抽象度が異なる箇所を指摘する
4. 重複、見落とし、「その他」が大きくなる箇所を示す
5. 子の問いへ答えても親へ答えられない飛躍を示す
6. 因果の矢印には、代替説明と必要な証拠を付ける

与えられていない事実を補わず、仮説は仮説と記すこと。

出力を確認するときは、各親子関係を文章で読み上げます。「なぜこの 3 項目なのか」「どの集合を覆っているのか」「この矢印は観測、計算、因果のどれか」と問い直します。

AI へ MECE と指示しても、完全性は保証されません。AI は、学習した典型的な分類を再現できますが、クライアント固有の例外や、まだ言語化されていない現場の関係を知りません。現場担当者、データ、一次資料で確認します。

機密情報を抽象化して入力した場合、重要な依存関係も消えることがあります。抽象化した条件と、AI が確認できなかった範囲を記録します。

5.8 分解を止める条件

ツリーは、細かくしようと思えば際限なく分けられます。分解は、末端の問いに対して、期限内に証拠を集め、上位の判断を変えられるところで止めます。

実務では、次の順で使います。

1. 親となる意思決定の問いを書く
2. 分類、計算、過程、因果、質問から関係を選ぶ
3. 同じ階層の軸、重複、重大な漏れを確認する
4. 各枝が親の判断を変えるか確認する
5. 優先する枝へ仮説と証拠を割り当てる
6. フィードバックや相互依存があれば、木以外の図へ移す
7. 証拠を得られる単位で分解を止める

小さな判断では、紙に図を描かなくてもかまいません。時間を決めて、「親の問い」「必要な下位の問い」「その関係」の 3 点を言葉で確認すれば始められます。大きな投資や部門横断の問題では、定義、責任、依存関係、因果仮説を図と文書で共有します。

考えてみる問い

最近見たロジックツリーを一つ選び、各枝が分類、計算、過程、因果、質問のどれを表しているか書いてください。一つの階層に複数の関係が混ざっていたら、どの判断を誤らせる可能性があるでしょうか。

よい分解は、枝の数や左右の対称性では決まりません。親の問いと子の問いがつながり、関係の種類が明確で、重要な重複と漏れを扱い、必要な証拠へ到達できることが条件です。

論点を分けたら、それぞれの答えを根拠から組み立てる必要があります。第6章では、事実、根拠、主張を区別し、結論の論理を作ります。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の分解の 4 種類、図の対応表、分解を止める条件は、以下の資料を踏まえた本書独自の整理です。

• Barbara Minto ― The Minto Pyramid Principle
• Judea Pearl ― A Causal Calculus for Statistical Research
• OECD / IIASA ― Systemic Thinking for Policy Making

第6章 結論を根拠から組み立てる

第5章では、意思決定の問いを下位の問いへ分けました。調査を進めると、顧客群別の解約率、インタビューの発言、支援工数、競合事例など、多くの材料が集まります。しかし、材料を順番に並べても、提案にはなりません。

たとえば、次の説明を考えます。

初期設定を完了していない顧客の解約率は高く、インタビューでも設定の難しさが指摘されました。競合 3 社は導入支援を提供しています。したがって、当社も全新規顧客へ導入面談を提供すべきです。

一見、結論と根拠が揃っています。しかし、初期設定未完了と解約の関連だけでは、面談によって解約が減るとは言えません。インタビュー対象が偏っているかもしれません。競合が実施していることは、自社でも有効だという証拠ではありません。全顧客へ広げる前に、対象、効果、工数、危険を確かめる必要があります。

本章では、論証を事実や観測から、どの推論を通じて、どの強さの主張を導くかを明示することと定義します。結論を先に書くことと、結論を先に決めて証拠を選ぶことは違います。読者へは結論から伝えながら、作り手は反対証拠と代替説明を含めて結論を組み立てます。

実務では、事実・証拠・推論・主張を分け、証拠に合わせて主張の強さを調整し、推論を確かめ、反例と代替説明を入れ、判断基準によって推奨へ統合します。

小さく取り消しやすい判断なら、まず次の 4 点を一枚に置きます。

主張: 何を、どの条件で勧めるか
主要な証拠: 何を観測したか
推論: なぜその観測から主張へ進めるか
次の行動: 誰が何を行い、何を見て止めるか

影響が大きくなるほど、競合する説明、代替案、例外条件、価値判断、専門家の確認、正式な承認を加えます。

6.1 事実、証拠、主張、推論を分ける

「データが示している」と書くだけでは、論理の接続が見えません。本書では、次の 4 つを区別します。

事実と証拠は同じではありません。事実は、ある主張との関係で証拠になります。競合 3 社が導入支援を提供していることは、「導入支援が業界で実行可能」という主張の参考にはなります。しかし、「自社の解約を減らす」という主張への直接的な証拠にはなりません。

推論は、文章で省略されやすい部分です。

事実:
未完了群の 90 日以内解約率は 20%、完了群は 5% だった。

推論:
期間、顧客属性、獲得経路などの主要な差を確認したうえで差が残るなら、
初期設定未完了は解約危険を識別する材料になる。

主張:
初期設定未完了を、支援試行の対象条件の一つとして使う価値がある。

ここでは、原因だとも、支援すれば解約が減るとも主張していません。証拠が支えられる範囲へ主張を合わせています。

英国出身の哲学者 Stephen E. Toulmin（スティーヴン・E・トゥールミン）は、日常や専門分野で行われる実際の議論が、どのように正当化されるかを研究しました。著書『The Uses of Argument』では、data（根拠となる情報）、claim（主張）、warrant（情報から主張へ進む正当化）などを区別しています。本書の 4 要素は、この考え方を事業上の意思決定へ使いやすく整理したものです。Toulmin の枠組みを完全に再現することより、普段省略される「なぜその証拠からその主張へ進めるのか」を表に出すことを重視します。

重要な論証では、4 要素に加えて、推論そのものの裏付けと例外条件を確認します。たとえば、「初期設定未完了は解約危険を識別する」という推論の裏付けには、顧客群を分けても差が再現することが必要です。裏付けは権威的な一般論を置くだけでは足りず、今回の対象と条件へ適用できる資料や分析で確かめます。例外条件には、ログ欠損、特殊な利用目的、別経路で価値を得る顧客などがあります。

6.2 主張の強さを証拠に合わせる

同じ観測から、異なる強さの主張を作れます。

「可能性がある」「示唆される」と弱めれば、どんな飛躍も許されるわけではありません。どの証拠から、何がどの程度不確かなのかを書きます。

主張には、対象、条件、期間、確かさを付けます。

直近 6 か月の新規顧客では、顧客規模と獲得経路を分けても、初期設定未完了群の 90 日以内解約率が高かった。未観測の要因は残るため原因とは断定しないが、未完了を支援対象の識別条件として試す根拠になる。

限定は、主張を弱く見せるためではありません。どの範囲で判断に使えるかを明らかにします。限定を外して強く言うと、短期的には説得的でも、反例が一つ見つかっただけで提案全体の信頼を失います。

6.3 推論の種類によって確かさが変わる

実務では、演繹（えんえき）、帰納（きのう）、アブダクション（観測を最もよく説明する仮説を選ぶ推論）を組み合わせます。

演繹（えんえき）

前提が正しく、推論形式が妥当なら、結論が必ず成り立つ推論です。

前提 1: 支援対象は、初期設定が未完了の顧客に限る。
前提 2: A 社は初期設定を完了している。
結論: A 社は支援対象ではない。

演繹は確実に見えますが、前提の定義や事実が誤っていれば、実務上の結論も誤ります。「完了」の定義、データ更新時点、例外条件を確認します。

帰納（きのう）

観測した複数の事例から、より広い傾向を推測します。

観測:
調査した未完了顧客では、完了顧客より解約率が高かった。

結論:
同じ条件の新規顧客でも、未完了群は解約危険が高いと予想する。

帰納の結論は、観測範囲を超えるため確実ではありません。標本の選び方、件数、ばらつき、期間、母集団との違いを確認します。件数が多くても、同じ偏った顧客だけを観測していれば一般化できません。

アブダクション（最良の説明への推論）

観測を説明する候補から、現時点で最もよい説明を選ぶ推論です。「最良の説明への推論」と呼ばれることがあります。

観測:
特定の広告経路で、初期設定未完了と解約が同時に増えた。

説明候補:
その経路から、サービスと適合しない顧客が増えた。

説明として自然でも、真実だとは限りません。ほかの候補を十分に考えたか、事前の予測と合うか、後付けの前提が多くないか、新しい観測を予測できるかを確認します。

Stanford Encyclopedia of Philosophy（スタンフォード哲学百科事典）は、スタンフォード大学の研究組織が公開するオンライン哲学事典です。各項目はその分野の専門家が執筆・更新し、編集委員による査読を経て公開されます。一般向け辞書や大学の公式見解ではなく、専門分野の論点と研究状況を確認するための参考資料です。そのアブダクションに関する項目では、最良の説明への推論が日常と科学で広く使われる一方、どの説明を候補とし、何を「最良」とするか、その正当性には議論があると整理しています。

3 種類は競合する手法ではありません。アブダクションで原因仮説を作り、演繹でその仮説から観測されるはずの結果を導き、調査や試行の複数の観測から帰納的に適用範囲を評価します。

6.4 ピラミッドは説明の順序を作る

分析は、事実を見つけ、仮説を変え、追加調査を行うという往復で進みます。その順番をそのまま報告すると、聞き手は最後まで結論を待たなければなりません。

ピラミッドストラクチャーは、最上位に一つの結論を置き、その下へ結論を直接支える同じ種類の理由をまとめ、さらに下へ事実や証拠を置く構造です。読み手は、最初に答えを知り、その後で「なぜそう言えるのか」を上から下へ確認できます。

この構成法をビジネス文書の作成手順として体系化したのが、Barbara Minto（バーバラ・ミント）の Pyramid Principle（ピラミッド原則）です。Minto は経営コンサルティングの現場でこの方法を開発しました。単に結論を先に書く方法ではありません。同じ問いへ答える理由を一つのまとまりにし、そのまとまりを要約する上位メッセージを置くことで、書く前に論理の重複、抜け、階層の混同を見つける方法です。本書では、提案の説明順を整えるために使いますが、構造が整っていても根拠が正しいとは限らないため、論証の確認とは分けます。

推奨:
解約危険が高い未完了顧客に限り、4 週間の手動支援を試す

├─ 必要性:
│  未完了は、解約危険を識別する材料になる
│  └─ 顧客群を分けても、未完了群で解約率が高い
│
├─ 期待効果:
│  手動支援は初期設定完了を増やす可能性がある
│  └─ 小規模試行で完了率の差を確認する
│
└─ 実行可能性:
   対象を限定すれば、既存人員で安全に運用できる
   └─ 想定件数、工数上限、停止条件を満たす

上位の主張を、下位の主張が同じ種類の理由として支えているか確認します。「必要性」「競合事例」「実施スケジュール」のように、根拠、参考情報、実行手順が同じ階層へ混ざると、推奨の論理が見えません。

また、下位の理由がすべて正しくても、上位の結論が自動的に導かれるとは限りません。上の例では、必要性、期待効果、実行可能性に加え、顧客への危険、代替案、学習価値との比較が必要です。ピラミッドの整った形を、論証の妥当性と混同しません。

結論から伝えるのは、異論を隠すためではありません。聞き手が「何について判断を求められているか」を理解し、下位の根拠を評価できるようにするためです。

6.5 一つの証拠へ働かせすぎない

説得力のある一つの数値や発言に、複数の役割を持たせると危険です。

「未完了群の解約率が高い」という観測は、対象を絞る参考になります。しかし、次の主張を単独では支えません。

• 未完了が解約の原因である
• 手動面談が最善の解決策である
• 面談を全顧客へ提供すべきである
• 面談の費用を回収できる
• 顧客が面談を望んでいる

主張ごとに、必要な証拠を分けます。

証拠の量より、主張への関連性、信頼性、競合する説明を見分ける力を見ます。同じデータを複数の主張へ使うこと自体は問題ではありません。ただし、各主張に対して何を証明せずに残すかを明記します。

インタビューの印象的な一言も同様です。発言は、その人の経験を理解する重要な証拠ですが、顧客全体の頻度を示すものではありません。定量データと定性データを、互いの代用品ではなく、異なる問いへ答える証拠として組み合わせます。

同じ主張について証拠が矛盾したときは、平均して一つの結論へ急ぎません。対象、期間、用語の定義、収集・測定方法、欠損、証拠の質を並べます。たとえば、ログでは離脱が多いのにインタビューでは困難が語られないなら、対象者が継続顧客へ偏っていないか、ログの「未完了」が実際の利用を表しているかを確認します。矛盾を解けなければ、両方を示し、推奨を小さくするか追加確認へ回します。

6.6 反例と代替説明を論証に入れる

反対証拠を最後の「リスク」へ追いやると、中心の主張が実際より確実に見えます。重要な反例と代替説明は、主張を作る段階で扱います。

たとえば、初期設定を完了していないのに継続している顧客がいるとします。その顧客を外れ値として除く前に、利用目的、別の価値体験、支援経路を調べます。仮説の適用条件を見つけられるかもしれません。

代替説明は、現在の説明と同じ観測を説明できる別の仮説です。

観測:
未完了群で解約率が高い

説明 A:
初期設定を完了できないため、価値を得られず解約する

説明 B:
サービスに適合しない顧客は、初期設定を完了せず解約する

説明 C:
担当者の支援が少ない顧客は、未完了にも解約にもなりやすい

説明 A だけを前提に支援を増やすと、B では不適合顧客の解約を先送りし、C では担当者の配分問題を見落とします。A、B、C を見分ける証拠を確認し、期限内に見分けられなければ、不確実性を残して試行を小さくします。

反対意見への対応は、すべてを論破することではありません。

• 主張の対象や条件を限定する
• 追加証拠で反対意見を弱める
• 不確実性を認め、停止条件を付ける
• 代替案の方がよければ推奨を変える
• 今回は判断できないと結論づける

提案の信頼性は、反論がないことではなく、重要な反論を受けても、何を決められ、何をまだ決められないかが分かることから生まれます。

6.7 推奨は事実だけでは決まらない

「解約率が高い」という事実から、「面談を実施すべき」という推奨は直接導けません。推奨には、目的、価値判断、制約、代替案が含まれます。

事実:
未完了群の解約率が高い。

目的:
価値を得られる顧客の早期解約を減らす。

判断基準:
期待効果、顧客への危険、支援工数、実行可能性、学習価値。

代替案:
全顧客へ支援 / 危険の高い顧客だけ支援 / 支援せず原因調査 / 現状維持。

推奨:
危険の高い未完了顧客へ限定し、停止条件付きで 4 週間試す。

判断基準の重みは、データだけから決まりません。解約低下を優先するか、顧客の自律性や現場負荷をどこまで重視するかは、説明責任を伴う判断です。コンサルタントは、基準と各案のトレードオフを示し、決定者が選んだ理由を残せるようにします。

コンサルタントが作るのは、証拠と価値判断を明示した推奨です。その推奨を採用するかは決定者が選びます。採用した決定、変更した条件、採用しなかった理由を、コンサルタントの推奨と分けて記録します。

推奨には、少なくとも次を含めます。

1. 誰が、何を決めるのか
2. どの案を、どの条件で勧めるのか
3. 主要な根拠と、その推論は何か
4. ほかの案よりよい理由は何か
5. 何がまだ分からないか
6. どの条件で開始、停止、見直すか
7. 誰が実行し、何を測るか

今回の試行例では、顧客対応者 2 人、合計週 8 時間、対象 20 社を上限とします。苦情、同意撤回、通常業務の待ち時間、1 社あたり工数、より価値の高い通常業務への影響が合意した上限を超えたら停止します。4 週間後に、実施率、初期設定完了率、顧客反応、工数を比較し、対象拡大、支援内容の修正、中止を選びます。90 日解約への効果は、その時点では確定せず追跡します。拡大する場合も対象数と期間に次の上限を設け、長期成果または危険が基準を外れたら再び止めます。

「データドリブン」という言葉で、価値判断を隠してはいけません。データは選択の結果を予測する助けになりますが、どの結果を望ましいとするかまでは決めません。

6.8 AI には文章より推論をレビューさせる

AI は、文章を滑らかにし、ピラミッド形式へ並べ替えられます。しかし、存在しない接続を自然な文章で補い、関連を因果へ強め、限定を削ることがあります。

まず、文章ではなく論証の部品を渡します。

意思決定:
どの顧客群へ、どの初期支援を試すか。

主張:
解約危険が高い未完了顧客へ、4 週間の手動支援を試す。

事実・観測:
[定義、母集団、期間、数値、調査方法、出典を付ける]

判断基準と制約:
[期待効果、危険、工数、実行可能性、学習価値]

依頼:
1. 各事実が、どの主張をどの程度支えるか対応づける
2. 事実から主張へ進む暗黙の推論を文章にする
3. 関連から因果、観測から一般化、事実から価値判断への飛躍を指摘する
4. 競合する説明と、主張に合わない反例を挙げる
5. 証拠より強い表現と、曖昧な限定語を指摘する
6. 推奨を変えうる不足情報を示す

与えられていない事実を補わず、推測は推測と記すこと。

AI の指摘も、論理的に正しいとは限りません。反例として作った事例が実在するか、提示した推論規則が今回の事業に当てはまるかを確認します。AI が「証拠不足」と言っても、決定期限と取り消しやすさによっては、小さく進む判断が合理的です。

複数の資料を要約させるときは、要約文だけで論証を作りません。元資料の定義、対象、期間、限界へ戻ります。AI が異なる資料の主張を一つに統合すると、各資料が実際には述べていない結論が生まれることがあります。

機密情報を入力できない場合は、承認された環境を使うか、論証の構造だけを抽象化します。抽象化によって失われた条件は、人間が元資料と照合します。

論証は最終報告の直前に初めて見せません。分析開始時に事実の定義、中間時点で主要な推論と反対証拠、決定前に判断基準と推奨を、データ責任者、実行責任者、意思決定者と段階的に確認します。決定者が参加できない場合は、代理で確認できる範囲と権限、本人が最終確認する期限を決めます。未合意点、各立場の理由、誰がいつ決めるかを残します。

推奨を更新したときは、何の事実・証拠・推論・価値判断が変わり、以前の推奨をどのように修正したかを記録します。結論だけを上書きせず、変更理由を決定者が追えるようにします。

6.9 論証を完成させる 7 つの確認

提案前に、上位の推奨から下位の証拠へたどり、次を確認します。

1. 主張: 誰に、何を、どの条件で受け入れてほしいか
2. 証拠: 各主張を直接評価する事実・観測があるか
3. 推論: なぜその証拠から主張へ進めるかを説明できるか
4. 強さ: 関連、原因、効果、推奨を混同していないか
5. 代替: 競合する説明と現状維持を含む別案を比べたか
6. 限界: 反例、不確実性、適用条件を示したか
7. 行動: 決定、実行、測定、停止へつながっているか

チェックに使う時間にも上限を置きます。小さな試行では短いレビューで 4 点を確認し、顧客、安全、法令、人員、大規模投資へ影響する判断では、代替案、反対証拠、専門家の確認、正式な承認へ時間を配ります。すべてを同じ深さで埋めることは目的ではありません。

考えてみる問い

最近作った提案から、「したがって」を一つ選んでください。その直前の事実だけで、直後の主張へ本当に進めるでしょうか。間にある暗黙の推論、別の説明、価値判断を書き出してみましょう。

よい論証は、反論できない文章ではありません。どの事実を、どの推論で、どの強さの主張へつないだかが見え、新しい証拠によって結論を変えられる構造です。

ここまでで、問いを立て、仮説を置き、論点を分け、結論を組み立てる基礎が揃いました。第3部では、その論証に使う情報をどう見極め、調べ、データとインタビューから証拠を作るかを扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の 4 要素、主張の強さ、推奨の 7 要素、論証確認の 7 項目は、以下の資料を踏まえた本書独自の整理です。

• Stephen E. Toulmin ― The Uses of Argument ― 哲学者 Toulmin による、根拠、主張、その間を正当化する理由などから実際の議論を捉える考え方を参照
• Stanford Encyclopedia of Philosophy ― Abduction ― 専門家が執筆し編集委員が査読するオンライン哲学事典から、アブダクションの定義、利用、正当化をめぐる論点を確認
• Barbara Minto ― The Minto Pyramid Principle ― 経営コンサルティングのために開発された、結論とそれを支える考えを階層化する文書構成法を参照

第3部 調査とデータ

問いと仮説を作っても、判断に使える証拠がなければ結論は出せません。この部では、何を調べるかを決め、外部資料、数値、インタビューから証拠を作る方法を扱います。

情報量を増やすことは目的ではありません。定義、対象、期間、収集方法、出典を確かめ、どの情報がどの主張をどの程度支えるかを見極めます。AI は探索と整理を速めますが、原資料への遡及（そきゅう。情報を元の資料までさかのぼること）と判断の責任は人間に残ります。

第7章 意思決定に必要な情報を見極める

第6章では、推奨を事実、証拠、推論、主張へ分けました。論証の空欄が見えると、追加で知りたいことが増えます。市場規模、競合の機能、顧客の不満、解約率、支援工数、将来の売上予測。どれも役立ちそうに見えます。

しかし、「役立ちそうな情報」を集め始めると、調査は終わりません。検索すれば関連資料が増え、インタビューすれば新しい疑問が生まれます。詳しくなることと、決められることは別です。

今回の意思決定は、「8 月末までに、どの顧客群へどの初期支援を試すか」です。この判断に全国の SaaS（インターネット経由で継続利用するソフトウェアサービス）市場規模が必要でしょうか。競合 30 社の全機能を比較する必要があるでしょうか。情報が正確でも、結果によって選択が変わらないなら、今の判断に対する価値は小さくなります。

本章では、必要な情報を選択肢の評価または重要な不確実性を変え、期限内の意思決定に使えるものと定義します。調査の出発点を「何を知りたいか」から「何が分かれば選択が変わるか」へ移します。

作業は、次の順で進めます。

決定を定める
  ↓
結果によって変える行動を決める
  ↓
必要な情報と情報源を選ぶ
  ↓
必要十分な品質で収集する
  ↓
終了条件で止め、来歴を残す

小さく取り消し可能な判断なら、最初から詳細な表は要りません。まず、次の 3 問だけを書きます。

1. 今、何を決めるのか
2. 結果が逆なら、何を変えるのか
3. いつまでに、何を一つ確認するのか

今回の例なら、次のように記入できます。

8 月末までに、初期設定未完了の顧客へ手動支援を試すか決める。未完了と 90 日以内解約に差がなければ、対象条件を見直す。8 月 10 日までに、直近 6 か月の群別解約率を確認する。

失敗したときの影響が大きいほど、後で扱う品質、責任、来歴の項目を追加します。

7.1 知りたいことを決定に必要な問いへ変える

クライアントやプロジェクトメンバーからは、次のような情報要求が出ます。

• 競合のオンボーディングを調べたい
• 顧客の声をもっと聞きたい
• 業界の成功事例を知りたい
• 解約率を詳しく分析したい
• AI 活用の最新動向を押さえたい

このままでは、対象と終わりが決まりません。情報要求を、決定との関係が分かる形へ変えます。

「もっと詳しく」は情報要求ではありません。比較する選択肢、評価基準、必要な精度、期限を付けます。

たとえば、「解約率を詳しく」ではなく、次のように書きます。

支援対象を選ぶため、直近 6 か月の新規顧客について、契約プラン、獲得経路、初期設定完了の有無ごとに、90 日以内解約率と母数を比較する。8 月 10 日までに、対象群を変えるほどの差があるか確認する。

この一文なら、必要なデータと終了条件を考えられます。

判断とデータの対応をまだ自分で組み立てにくい場合は、付録 B「意思決定と必要データの対応表」を参照します。付録の表をそのまま埋めるのではなく、今回の選択肢、期限、失敗費用に合わせて必要な行だけを使います。

7.2 情報要求をデータ要求へ落とす

情報は、判断に意味を持つ形へ解釈された内容です。データは、その情報を作るために記録・収集する値、文書、発言、観察などです。本書では、両者を次のように区別します。

意思決定
  ↓ 何を比較するか
情報要求
  ↓ 何を観測・計算するか
データ要求
  ↓ どこから得るか
情報源と収集方法

解約率の情報要求なら、データ要求は次のようになります。

情報要求とデータ要求を分けると、入手できるデータに問いを合わせる危険を減らせます。手元にページ閲覧数があるからといって、それが初期価値を表すとは限りません。先に必要な情報を定め、既存データでどこまで近づけるかを確認します。

反対に、理想的なデータを求めすぎても進みません。必要な精度と失敗費用に応じて、代理指標、定性情報、小規模な追加収集を使います。代理指標を使う場合は、何を代わりに表すと仮定したか、どの条件でずれるかを残します。

7.3 情報要求表で調査を計画する

調査項目を一覧にするだけでなく、意思決定との関係を置きます。この表は、調査前に何を確認するかを決める計画です。第7.10節で扱う来歴の記録は、実際に使った証拠を後からたどるための記録です。

まず、判断側を設計します。

次に、同じ ID で収集側を設計します。

このように調査前に目的、証拠、停止条件をそろえる必要があるときは、付録 C「調査計画テンプレート」を下書きに使えます。書式を完成させることより、調査を止める条件と、結果によって変える行動が見えていることを優先します。

表の中心は、「結果 A / B で変えること」です。ここを書けない情報は、現時点の意思決定には不要か、問いがまだ曖昧です。

情報要求が複数ある場合は、すべてを同時に調べません。まず安全、法令、顧客との約束に関わる条件を確認します。そのうえで、選択を変える可能性、決定期限、取得費用を比べ、優先順位を付けます。

すべての情報を同じ精度で求めません。大規模な投資判断の需要予測と、20 社への取り消し可能な試行の工数見積もりでは、必要な確かさが違います。品質欄には、「正確な数字」のような抽象語ではなく、必要十分な精度として、許容する欠損、期間、比較可能性、確認方法を書きます。

また、担当者は情報を都合よく作る人ではありません。情報源を確認し、品質と限界を記録し、期限までに得られない場合の代替案を提案する人です。社内データでは、データ所有者、利用を承認する人、取得・分析する人、意思決定者が異なることがあります。担当欄だけで曖昧になる場合は、提供と利用を誰が承認するかも書き分けます。

7.4 一次情報と二次情報は役割が違う

一次情報は、対象となる事象や主体から直接得た元の記録です。社内の契約・行動ログ、顧客へのインタビュー記録、企業の決算資料、政府統計の元表、法令本文、原著論文などが該当します。二次情報は、一次情報や複数資料を整理、解釈、比較したものです。報道、業界レポート、解説記事、レビュー論文などがあります。ただし、この区別は分野や主張によって変わります。企業の公式資料は「企業がそう公表した」ことの一次情報ですが、施策が一般に有効だという独立した証拠ではありません。

一次情報が常に正しく、二次情報が常に劣るわけではありません。

一次・二次は、情報の生成過程を示す区別であり、品質順位ではありません。直接聞いた顧客の発言でも、質問が誘導的なら弱い証拠です。質の高い系統的レビューは、一つの原著研究より全体像をよく示す場合があります。一方、顧客が何を経験したかを探索する問いに、効果研究の方法をそのまま当てはめることはできません。普遍的な情報源の順位を作るのではなく、問いに方法が合うかを見ます。

探索では二次情報から全体像と用語をつかみ、重要な主張は一次情報へ遡ります。二次情報しかない場合は、その情報が何を根拠にしたか、誰がどの目的で作ったか、どこまで確認できないかを記します。

7.5 情報源の質は主張との関係で見る

有名な組織の資料だから、今回の主張を強く支えるとは限りません。情報源は、少なくとも次の観点で評価します。

評価は、出典へ点数を付けて終わるものではありません。何を言えるかを調整するために使います。

たとえば、競合企業の導入事例には、顧客名と成果が掲載されていても、失敗事例、選定方法、比較対象がありません。この資料から「その会社が事例として公開した」ことは言えますが、「導入企業の多くで同じ成果が出る」とは言えません。

複数サイトが同じ市場規模を掲載していても、元をたどると一つの調査会社かもしれません。転載数を証拠の独立性と誤解しません。元資料が入手できなければ、定義と方法を確認できない数字として扱います。

情報源同士の数字が違うときは、単純に平均しません。対象、定義、分母、期間、作成目的を照合し、今回の問いへ合う数字を選びます。一つに決められない場合は、幅または複数の見積もりとして示し、どの前提ならどの値になるかを残します。

米国国立標準技術研究所（NIST）の情報品質に関する指針も、意思決定や政策の基礎に第三者情報を使う場合、その品質が分かり、適用される品質基準と整合することを求めています。対象は米国政府機関の情報公開ですが、第三者資料を権威だけで採用しない点は企業調査にも応用できます。

7.6 情報の価値は選択が改善する幅で考える

情報には、取得費用だけでなく待つ費用があります。調査中に機会を失い、問題が拡大することもあります。

意思決定論では、追加情報を得ることで期待される選択結果の改善を、情報の価値として考えます。以下は、正式な期待情報価値を計算する方法ではなく、調査の優先順位を決めるための定性的なふるい分けです。厳密に比較する場合は、結果の確率、効果の大きさ、対象期間を置きます。

• 結果によって選ぶ案が変わる可能性はあるか
• 案を変えることで、どの損失を避け、どの利益を得られるか
• 情報は期限までに得られるか
• 取得、分析、待機、顧客負担の費用はいくらか
• 誤った情報によって、判断を悪化させる危険はないか

例として、未完了顧客へ支援するかを考えます。

追加調査なし:
全顧客へ支援する。想定工数は週 40 時間。

追加調査あり:
2 日の分析で解約リスクが高い顧客群を識別できれば、対象を 20% に絞れる可能性がある。
分析費用は 16 時間。4 週間の試行では、支援工数を最大 128 時間減らせる可能性がある。

この例で 128 時間をそのまま期待効果とはみなしません。分析によって対象を識別できる確率と、絞っても効果を失わない確率があるからです。それらを確かに見積もれなくても、追加情報が変えうる資源配分、対象期間、取得費用を同じ土俵へ置くことで、調査の優先度を説明できます。

反対に、市場規模を 1,000 億円か 1,200 億円かまで精緻化しても、どちらでも同じ 20 社試行を選ぶなら、今の判断に対する追加価値は小さいものです。将来の投資判断には必要でも、今回の調査からは外せます。

情報の価値は、金額だけではありません。顧客への重大な危険、法令違反、公平性、評判の毀損を避ける情報は、発生確率が低くても先に確認します。

7.7 既存データを使うか、新しく集めるか

既存データは速く使えますが、今回の問いのために作られていません。新規収集は問いへ合わせられますが、時間、費用、対象者の負担が増えます。

次の順で検討します。

1. 既存データで直接答えられるか
2. 定義変更、欠損、偏りを補正・説明すれば使えるか
3. 複数の既存情報を組み合わせれば答えられるか
4. 代理指標で、判断に必要な程度まで近づけるか
5. 小規模な追加収集が必要か
6. 期限内に得られないなら、判断を小さくするか延期するか

「データがある」と「使ってよい」は別です。利用目的、同意、契約、個人情報、機密性、アクセス権、保存期間を確認します。技術的に結合できても、当初の目的を超えた利用が許されない場合があります。

追加収集では、必要な項目だけを集めます。「将来使うかもしれない」という理由で個人情報や機密情報を増やすと、対象者の負担と管理責任が増えます。収集しないことも、情報設計の判断です。

調べるか、小さく試すか

低費用で取り消し可能であり、安全、法令、顧客との約束を守れるなら、小規模な試行が最も直接的な情報源になることがあります。反対に、失敗を回復しにくい判断は、実行前の確認を厚くします。

「十分に調べてから試す」か「何も調べずに試す」かの二択ではありません。重大な制約を先に確認し、残る不確実性を小さな試行で学ぶように組み合わせます。

7.8 調査を終える条件

調査を終えるのは、新しい情報が見つからなくなったときではありません。決定に必要な不確実性が許容範囲まで下がり、追加情報の価値が費用を上回らなくなったときです。

開始前に、次を決めます。

1. どの決定または主張へ使う情報か
2. 結果 A / B で何を変えるか
3. 必要な品質・精度はどの程度か
4. どの情報源を最低限確認するか
5. 時間、人員、費用、対象者負担の上限は何か
6. 期限までに得られない場合、誰がどう決めるか
7. 何が判明したら、問いそのものへ戻るか

次の状態なら、止める判断ができます。

• 主要な選択肢を同じ基準で比較できる
• 新しい情報を加えても選択肢の順位が安定し、重要な基準が許容範囲に入った
• 結果が変わっても選択が変わらない追加調査だけが残った
• 重要な反対証拠と代替説明を必要な範囲で確認した
• 小さく取り消し可能な試行へ進む安全条件が揃った
• 追加調査の費用や待つ損失が、期待される判断改善を上回る
• 調査上限または決定期限に達し、残る不確実性を明示した

すでに費やした時間は、追加調査の理由にしません。「ここまで調べたから」ではなく、これから使う 1 日が判断をどの程度改善するかで決めます。

期限までに得られなかった情報は、確認済み、代理指標、仮定、未確認を区別し、意思決定者へ一覧で示します。そのまま進む場合は、判断を小さくする、条件付きで承認する、後で再確認するなど、残る不確実性に対応した条件を付けます。

同じ結論を支持する資料が増える「飽和」だけでは不十分です。検索方法が同じなら、同種の情報ばかり見ている可能性があります。反対の結果、別の方法、異なる立場の情報源も確認します。

調査を止める権限を明確にします。担当者は情報の限界と残る不確実性を報告し、プロジェクト責任者と意思決定者が、追加調査、試行、延期、見送りを選びます。

今回使わなかった情報要求を、すべて「いつか調べる一覧」へ移してはいけません。将来のどの決定へ使うか、担当者と再検討時期が決まるものだけを別に残し、それ以外は閉じます。

7.9 AI は探索の入口として使う

AI は、検索語の展開、資料候補の発見、長い文書の該当箇所探索、比較表の下書きに使えます。特に、情報要求表を渡すと、一般的な業界解説ではなく、判断に必要な情報源を探しやすくなります。

意思決定:
どの顧客群へ、どの初期支援を 4 週間試すか。

情報要求:
同じ顧客規模と運用制約で、手動の初期支援を実行できる根拠。

必要な品質:
対象顧客、支援内容、運用主体、工数または件数、実施期間が確認できること。

依頼:
1. 一次情報を優先して資料候補を挙げる
2. 各資料が情報要求のどの項目へ答えるか示す
3. 元資料の URL（ウェブ上の所在を示す文字列）、発行主体、発行日、該当箇所を示す
4. 確認できない項目を「不明」と記す
5. 同じ元情報を参照する資料をまとめる
6. 反対事例または限界を示す資料も探す

AI が示した URL、文書名、数値、引用、発行日は、原資料で確認します。存在しない資料や、実在する資料にない内容を生成することがあります。リンクが実在しても、該当箇所が主張を支えるとは限りません。

要約では、定義、分母、期間、方法、限定が落ちやすくなります。重要な数値は原表へ戻り、必要なら再計算します。引用は前後の文脈を確認します。

AI の回答だけを情報源として参考資料へ載せません。AI は探索と整理の手段であり、主張の出典は検証可能な原資料です。どの AI とやり取りしたかより、最終的にどの資料のどの箇所を確認したかを記録します。

機密情報や個人情報を入力する場合は、承認された環境、利用規約、保存と学習への利用、アクセス権を確認します。許可できない場合は、情報要求だけを抽象化して渡すか、AI を使いません。

7.10 情報の来歴を残す

ここでは、調査前の要求ではなく、実際に判断や主張へ使った証拠の来歴を記録します。調査結果だけを残すと、後から定義や更新日を確認できません。最低限、次を記録します。

来歴は、参考文献の体裁だけではありません。数値と結論を再現し、後から更新し、誤りが見つかったときに影響範囲を追うための情報です。

スクリーンショットだけでは、URL、更新、表の全体、代替テキストを失うことがあります。原 URL と取得日を残し、公開内容が変わる可能性が高い場合は、契約と著作権の範囲で保存方法を決めます。

AI で要約・抽出した場合も、使用箇所と人間の確認を記録します。AI 出力を途中で修正しても、最終的な主張がどの原資料に基づくかをたどれる状態にします。

考えてみる問い

最近集めた情報を一つ選び、「その結果が逆だったら、自分の選択は変わったか」と問い直してください。変わらないなら、その情報は現在の意思決定に必要だったでしょうか。将来の別の判断に必要なら、今回の調査と分けて記録しましょう。

必要な情報を見極めるとは、情報を減らすこと自体ではありません。意思決定、情報要求、データ要求、情報源、品質、終了条件をつなぎ、判断に働く情報へ限られた資源を配ることです。

何を調べるかが定まったら、次は外部資料を実際に探索します。第8章では、検索前の調査表、公的統計、企業資料、論文、報道の使い分けと、出典を遡るデスクリサーチを扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の情報要求表、情報源の評価観点、調査終了条件、来歴の記録項目は、以下の資料を踏まえた本書独自の整理です。

• HM Treasury ― The Magenta Book: Central Government guidance on evaluation
• NIST ― Information Quality Standards
• Cochrane Handbook ― Searching for and selecting studies
• Cochrane Handbook ― Considering bias and conflicts of interest

第8章 デスクリサーチを設計する

第7章では、調査の出発点を「何を知りたいか」から「何が分かれば選択が変わるか」へ移しました。情報要求が決まったら、外部にある資料を探します。公的統計、企業の開示資料、学術論文、業界団体の報告書、報道、ウェブサイト。机上で既存資料を集め、分析する仕事を、本章ではデスクリサーチと呼びます。

検索窓へ言葉を入れることは、デスクリサーチの一部にすぎません。検索結果の上位から数字を拾うだけでは、定義の違う市場規模を混ぜ、企業が選んだ成功事例を一般化し、同じ情報の転載を複数の証拠として数えてしまいます。資料を多く集めても、比較できる証拠は増えません。

デスクリサーチは、検索する仕事ではありません。問いに合う資料を見つけ、生成過程を確かめ、比較可能な証拠へ変える仕事です。

第7章が「意思決定にどの情報が必要か」を設計したのに対し、本章は「外部にある資料をどう探し、証拠へ変えるか」を扱います。作業は次の順で進みます。

調査表を作る
  ↓
候補と検索語を広げる
  ↓
問いに合う資料を選ぶ
  ↓
引用の上流と方法を確認する
  ↓
同じ項目で比較する
  ↓
履歴と限界を残し、意思決定へ戻す

本章の方法は、期限内の事業判断を支える実務的な調査です。学術研究を網羅的に探索・統合する系統的レビューそのものではありません。検索履歴を残すことで透明性と更新可能性は高まりますが、すべての資料を見つけたことや、選択の偏りがないことまでは保証しません。

今回も、「8 月末までに、どの顧客群へどの初期支援を試すか」という意思決定を扱います。そのうち、外部資料で確かめたいのは次の問いです。

同じ顧客規模と運用制約で、手動の初期支援を実施している事例があり、自社の 4 週間の試行設計へ転用できるか。

この一文から、探索、選別、読解、比較、記録を設計します。

小さく取り消し可能な判断では、最初からすべての表を作る必要はありません。まず、次の 5 項目だけを書きます。

1. 今回の問い
2. 結果が反対なら変える行動
3. 問いに直接答え、生成方法を確認できる資料 1 件
4. 反対結果または限界を示す資料 1 件
5. 今回は確認できなかったこと

失敗費用、説明責任、更新の必要が大きいほど、後続の項目を追加します。

8.1 検索前に調査表を作る

検索を始める前に、問いを探索可能な単位へ分けます。検索語を先に考えると、見つかりやすい情報だけで答えを作りがちです。

この表は、資料名の一覧ではありません。どの主張を作るために、資料から何を抜き出すかを定める表です。

表と一緒に、調査の範囲も決めます。

調査の深さは、判断の大きさに合わせます。

30 分と半日は、今回のような小規模試行を考えるときの開始例です。時間は機械的な組織標準ではなく、調査を無制限にしないために案件ごとに決めます。法令、安全、大規模投資のように失敗を回復しにくい判断では、必要な専門確認とレビューを別途設計します。

「オンボーディング 成功事例」と検索しても、成功と呼ぶ条件が決まっていなければ、閲覧数の多い記事が集まるだけです。反対に、顧客規模、支援期間、担当者、測定指標が必要だと分かっていれば、資料を開いた時点で採用・保留・除外を判断できます。

探索語は概念を分けて組み立てる

検索語は、一つの長い文章ではなく、概念群へ分けます。

対象:
SMB（Small and Medium-sized Business、中小企業）, small business, small and medium-sized business

介入:
customer onboarding, implementation support, customer success

方法・結果:
manual, high-touch, assisted, completion, retention, churn

資料形式:
case study, report, guide, study, filetype:pdf

同義語、上位語、下位語、旧称、略語、英語表現を広げます。ただし、すべてを一度に入れると結果を狭めすぎます。対象と介入から始め、結果や資料形式を組み替えます。見つかった資料の用語を次の検索へ使い、検索履歴へ追加します。

8.2 探索と検証を分ける

探索段階の目的は、候補と用語を広げることです。検証段階の目的は、主張を支えられるかを狭く確かめることです。この 2 つを同時に行うと、最初に見つけた結論へ合う資料ばかり集めやすくなります。

探索で読んだ資料を、そのまま根拠に昇格させません。元資料を開き、該当箇所、定義、対象、期間、方法を確認して初めて、検証済みの資料にします。

検索順位は証拠の順位ではありません。検索サービスは、関連性、人気、更新、利用者の状況などによって結果を並べます。上位にあることは、今回の問いに適した方法で作られたことを意味しません。

候補が多いときは、まず主張への直接性、作成方法の確認可能性、決定期限への適合で絞ります。その後、同じ元情報の重複を除き、独立した資料と反対結果を探します。有料資料は、要約だけで必要項目を確認できないなら、購入承認を得る、代替資料を探す、未確認として残す、のいずれかを選びます。

8.3 資料の種類で読み方を変える

外部資料には、それぞれ作られた目的があります。同じ確認項目を機械的に当てるのではなく、生成過程に合わせて読みます。

以下では、この表の確認点を資料ごとに詳しく見ます。

公的統計は定義と作成方法から読む

公的統計は、市場、人口、雇用、事業所などの基準を置くときに役立ちます。ただし、公的機関が公開した数字同士でも、対象と定義が同じとは限りません。

最低限、次を確認します。

• 調査の目的と作成主体
• 母集団、標本、回答率、除外対象
• 用語、分類、単位、価格基準
• 調査時点、対象期間、公開日
• 推計、季節調整、改定の方法
• 表ごとの注記と系列の切断

たとえば「中小企業」は、法令上の定義、統計上の従業者規模、サービス提供者の顧客分類で異なります。表の数値だけを転記せず、その数字に含まれる企業を言葉で説明できる状態にします。

業界資料は作成目的と調査対象から読む

業界団体や調査会社の資料は、特定分野の用語、論点、企業動向を速く把握するのに役立ちます。一方、会員企業だけを対象にした調査、回答者を公表しない調査、定義や質問票を確認できない市場予測もあります。

次を区別します。

• 実測値か、推計値か、将来予測か
• 調査対象をどう集めたか
• 無回答と欠損をどう扱ったか
• 市場の境界と重複をどう定義したか
• 資料の販売や業界振興と、結論に利害があるか

方法が公開されていない数字は、存在しないものとして捨てる必要はありません。ただし、正確な市場規模ではなく、追加確認が必要な参考値として扱います。

企業資料は開示と宣伝を分けて読む

企業資料には、法令や取引所規則に基づく開示、製品仕様、利用規約、ヘルプ、ニュースリリース、導入事例、経営者の発言などがあります。同じ公式サイトでも、資料の目的と確認可能性は違います。

数字は本文だけでなく、注記、会計方針、対象期間、比較対象を読みます。企業名や製品名が同じでも、組織再編や指標定義の変更で、前年と単純比較できない場合があります。

論文は結論より方法から読む

学術論文は、効果、関連、仕組みを検討するときに役立ちます。抄録だけでは、対象、介入、比較、除外、分析上の判断を十分に確認できません。

次の順で読みます。

1. 研究の問いと研究デザイン
2. 対象者の選び方と比較条件
3. 測定した結果と観察期間
4. 欠損、脱落、分析方法
5. 効果の大きさと不確実性
6. 著者が示す限界と利益相反
7. 自社の条件へ適用できる範囲

査読済みであることは、今回の問いへ直接答える保証ではありません。一つの研究だけで一般化せず、同じ問いを扱う研究全体、異なる結果、公開されにくい結果がないかを確認します。

報道は出来事と原資料への入口として読む

報道は、新しい出来事、関係者の反応、未整理の論点を知るために有効です。記事が引用する調査、判決、行政文書、企業発表へ遡れる場合は、原資料も確認します。

速報では、初期情報が後から訂正されることがあります。発生日時と記事の公開・更新日時を分け、匿名情報源、推測、記者が確認した事実、当事者の主張を混ぜません。複数の記事が通信社や同じ発表を参照している場合、独立した確認が複数あるとは数えません。

8.4 出典を上流へ遡る

デスクリサーチで最も起こりやすい誤りの一つは、引用の連鎖を元の調査と取り違えることです。

本章でいう原資料とは、ある記述や数字が依拠した、引用連鎖の上流にある資料です。第7章の一次情報と常に同じではありません。報道記事が引用した企業発表は、その記事の出典としては原資料ですが、企業施策の効果に対する独立した一次証拠とは限りません。

まとめ記事
  ↓ 引用
報道記事
  ↓ 引用
企業のニュースリリース
  ↓ 要約
調査報告書
  ↓ 集計
質問票・元データ

可能な範囲で上流へ遡り、どの段階で定義、限定、分母が落ちたかを確認します。すべての元データを入手できるとは限りません。到達できた最上流の資料と、確認できなかった部分を記録します。

たとえば、記事に「利用企業の 80% が生産性向上」とあっても、元資料では「オンライン調査へ回答した導入担当者 50 人のうち 40 人が、自己評価で向上したと回答」かもしれません。80% という計算が正しくても、誰の、何の測定かが違えば、意思決定での意味は変わります。

出典の遡及では、次を確認します。

• リンク先が実際の根拠か、別の要約か
• 引用された文や数字が原資料に存在するか
• 文脈と限定が維持されているか
• 最新版への差し替えや訂正がないか
• 同じ原資料を複数証拠として数えていないか

元資料へ到達できない場合は、二次資料であることを明示し、強い主張を避けます。「複数メディアが報じた」ことと、「複数の独立した調査が同じ結果を示した」ことを分けます。

8.5 比較表は空欄を消さない

資料を集めたら、同じ項目へ揃えて比較します。情報がない欄を推測で埋めると、比較表は整って見えても、証拠の強さを失います。

「不明」「記載なし」は、調査の失敗ではありません。比較できない理由を可視化する結果です。重要な空欄なら追加探索や問い合わせを行い、期限までに埋まらなければ、主張を限定するか、その事例を判断根拠から外します。

数値を揃える場合も、見かけだけの統一を避けます。通貨換算、物価調整、年率換算、割合の再計算をしたら、元の値、式、換算日、使用した係数を残します。異なる定義を同じ列へ置く場合は、注記で差を示します。

再計算しても、元資料以上に精密な証拠にはなりません。丸められた値、標本調査の推計、欠損を含むデータから小数点以下の桁を増やしても、不確実性は小さくなりません。

8.6 調査履歴を残す

最終的に採用した資料だけでは、何を探し、何を除外したかが分かりません。調査を再現し、更新し、都合のよい資料だけを選んでいないか確認するため、探索履歴を残します。

除外理由は、資料が「悪い」からではなく、今回の問いに合わない理由を書きます。対象違い、期間違い、方法不明、重複、原資料へ到達不能など、後から同じ判断を再現できる粒度にします。

履歴には、検索で見えない範囲も限界として残します。成功した事例だけが公開される公開バイアス、特定言語だけを見る言語バイアス、無料で入手できる資料へ偏る可用性バイアスがあります。履歴は偏りを消すものではなく、どこに偏りが残りうるかを説明するためにも使います。

探索履歴と第7章の来歴記録は役割が違います。探索履歴は調査過程全体を示し、来歴記録は最終的な主張がどの原資料のどの箇所に基づくかを示します。両者を調査 ID でつなぎます。

8.7 AI で探索を広げ、原資料で閉じる

AI は、検索語の展開、資料候補の分類、長い資料の該当箇所探索、比較表の下書きに使えます。特に、言い換えや隣接概念を広げる段階では、人間が思いつかなかった探索経路を示せます。

調査の問い:
従業員 100 人未満の顧客へ、手動の初期支援を実施した事例を探す。

必要項目:
顧客規模、支援内容、期間、担当者、工数、結果指標、比較対象、限界。

依頼:
1. 日本語と英語の検索語を概念群ごとに提案する
2. 公的資料、企業資料、論文、報道に分けて資料候補を示す
3. 各候補の発行主体、文書名、公開日、URL を示す
4. 元資料か、別資料の要約かを区別する
5. 必要項目を確認できない場合は「不明」とする
6. 成功事例だけでなく、失敗、限界、反対結果も探す

AI が作った比較表は完成品ではありません。各セルについて、次を確認します。

1. 資料が実在するか
2. URL が文書名と一致するか
3. 該当箇所にその内容があるか
4. 数字、単位、期間、対象が一致するか
5. AI が複数資料を一つの事実へ混ぜていないか
6. 要約で限定や否定が落ちていないか

AI の回答に出典が付いていても、検証は省けません。実在する文書名と架空の URL を組み合わせたり、本文にない数値をもっともらしく補ったりすることがあります。確認できないセルは空欄へ戻します。

長い PDF（表示・印刷の体裁を保つ文書形式）の該当箇所を探す場合も、AI の抜粋だけで引用しません。ページ番号、表番号、前後の文脈、注記を原資料で読みます。画像化された表や複雑な脚注は、文字抽出で列がずれることがあるため、表示も確認します。

8.8 調査結果を意思決定へ戻す

デスクリサーチの成果物は、資料一覧ではありません。実務では、確認可能性のための証拠表と、意思決定者が読む短い要約を分けます。

証拠表には、調査 ID、主張、原資料、該当箇所、方法、証拠の評価、限界を記録します。意思決定要約には、選択肢ごとに分かったこと、分からないこと、転用条件、次の行動を載せます。要約から証拠表へ戻れるように、同じ調査 ID でつなぎます。

「評価」は、資料が今回の主張をどの程度直接支えるかです。「限界」は、対象、方法、欠損など、主張を適用できる範囲を狭める条件です。

今回の問いなら、次のように戻します。

外部事例が見つかったことは、「自社でも成功する」という結論ではありません。何が同じで、何が違い、どの条件なら転用できるかを示します。外部資料で埋められない不確実性は、社内データ、インタビュー、小規模試行へ引き渡します。

同条件の事例が見つからないことも、そのような事例が存在しない証拠にはなりません。検索語、公開範囲、言語、アクセス可能性の限界を確かめます。そのうえで、隣接する顧客群や支援方法を探すか、重大な制約だけを確認して自社で小さく試します。

考えてみる問い

最近使ったウェブ上の数字を一つ選び、引用の上流へ遡ってください。最初のページと原資料で、対象、分母、期間、表現は同じでしょうか。違いがあるなら、その数字で支えられる主張を書き直してみましょう。

デスクリサーチの質は、検索結果の件数では測れません。問いに合う資料を選び、定義と方法を確かめ、出典の連鎖を遡り、比較できない空欄を残すことで、外部情報は意思決定に使える証拠になります。

外部資料から得た数字を自社の判断へ使うには、数値の構造をさらに理解する必要があります。第9章では、絶対数、比率、変化率、分布、施策を分けるための顧客群であるセグメント、同じ時期や出来事を起点にした集団であるコホートを使い、数字を選択肢の比較へ変える方法を扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の調査表、探索と検証の区別、比較表、調査履歴は、以下の資料を踏まえた本書独自の整理です。

• UK Statistics Authority ― Code of Practice for Statistics: Quality ― 統計の適切なデータと方法、品質保証、説明の原則を確認
• U.S. Securities and Exchange Commission ― How to Read a 10-K ― 企業の法定開示で確認する構成と注記を確認
• Cochrane Handbook ― Searching for and selecting studies ― 研究探索、情報源、検索記録、選択バイアスを確認
• Cochrane Handbook ― Collecting data ― 比較可能な項目の抽出、複数確認、欠損情報の扱いを確認

第9章 数字を意思決定に変える

第8章では、外部資料を探索し、比較可能な証拠へ変えました。外部資料にも社内データにも、数字が含まれます。顧客数、初期設定完了率、解約率、売上、支援工数。数字は曖昧な議論を具体化しますが、数字があるだけで判断が客観的になるわけではありません。

たとえば、初期設定完了率が 60% から 75% へ上がったとします。「15% 改善した」と報告してよいでしょうか。実際には 15 パーセントポイントの増加であり、元の 60% に対しては 25% の相対的な増加です。対象が 10 社なら、完了企業は 6 社から 7 社または 8 社へ変わった程度かもしれません。対象期間や顧客構成が違えば、支援の効果ではない可能性もあります。

数字を意思決定に使うには、指標の値だけを見ても足りません。定義、分母、比較基準、分布、時間、データ品質を一緒に読みます。

今回の意思決定は、引き続き「どの顧客群へ、どの初期支援を試すか」です。分析の目的は、きれいなダッシュボードを作ることではありません。支援対象を選び、必要な人員を見積もり、試行の継続・変更・中止を判断することです。

本章の顧客数、割合、工数は、考え方を説明するための仮想データです。実在案件の結果ではありません。

決定と比較を定める
  ↓
指標の仕様を固定する
  ↓
絶対数・比率・分布を見る
  ↓
セグメントと時間で分ける
  ↓
不確実性とデータ品質を確認する
  ↓
選択肢と次の行動へ戻す

小さな試行なら、最初からすべての分析を行う必要はありません。最低限、次の 5 点を確認します。

1. 分子、分母、対象期間
2. 平均だけではなく分布と件数
3. 行動を変える主要な顧客群
4. 成果指標と、工数・安全などのガードレール
5. 結果によって選ぶ次の行動

9.1 指標より先に決定を置く

「どの KPI（重要業績評価指標）を見ればよいですか」という質問から分析を始めると、一般に重要とされる数字を並べるだけになりがちです。先に、誰が、いつ、どの選択肢を比較するかを書きます。

指標は、選択肢を評価するための観測方法です。同じ「初期設定完了率」でも、支援対象を選ぶ分析と、支援の効果を評価する分析では、必要な比較が違います。

支援対象を選ぶなら、過去の顧客について未完了と解約の関係を調べます。支援の効果を評価するなら、支援を受けた顧客と受けなかった顧客を、比較可能な条件で見る必要があります。目的を混ぜると、関連がある顧客群を見つけただけで、支援に効果があると結論してしまいます。

分析前に、行動を変える閾値も仮置きします。たとえば、「14 日以内完了率が非支援群より 10 パーセントポイント以上高く、1 社あたり支援時間の 90% が 60 分以内なら継続する」のように、成果と運用条件を対にします。結果を見た後で閾値を変える場合は、変更理由を記録し、新しい仮説として次のデータで確かめます。

結果が確定する時期も分けます。

9.2 指標を一文で定義する

指標名だけでは、同じ数字を再現できません。次の要素を一文にします。

誰について
何を数え
何で割り
いつからいつまでを対象にし
どの時点で判定し
何を除外するか

初期設定完了率なら、次のように定義できます。

2026 年 1 月から 6 月に有料契約を開始した顧客企業のうち、契約開始から 14 日以内に必須 5 項目をすべて完了した企業数を、同期間の有料契約開始企業数で割る。試用のみ、社内テスト、契約取消は除外する。

指標仕様を表にすると、定義変更を追いやすくなります。

指標定義が途中で変わった場合、変更前後を同じ系列として単純比較できません。旧定義で再計算する、新定義へ遡及する、系列を分ける、のいずれかを選びます。再計算できないなら、グラフに切断を示します。

定義を変えたら、変更理由、承認者、適用日、影響するレポートを記録し、利用者へ通知します。指標名が同じまま意味だけが変わる状態を避けます。

9.3 絶対数と比率を一緒に見る

比率だけでは規模が分かりません。絶対数だけでは、対象全体に占める大きさが分かりません。原則として、分子、分母、比率を一緒に示します。

本章では、次のように用語を使います。

• 比: 2 つの数量を割って比べた値。分子が分母の一部とは限らない
• 割合: 分子が分母に含まれる値。0〜1 またはパーセントで表す
• 率: 一定時間または人時間などの曝露量あたりの発生を表す値

「完了率」「解約率」はビジネスで定着した名称なので本書でも使いますが、ここで計算している多くは対象企業に占める割合です。名称だけでなく、分子、分母、期間、単位を指標仕様へ書きます。

小規模顧客の完了率は低く、未完了は 48 社です。中規模顧客の未完了は 4 社です。率の差は支援対象の候補を示し、絶対数は必要な支援量を示します。

分母が小さい比率は、少数の変化で大きく動きます。2 社中 1 社なら 50% ですが、1 社の結果で 0% または 100% になります。「50%」だけを大きな標本の 50% と同じ確かさで扱いません。

パーセントとパーセントポイントを分ける

60% から 75% への変化は、次の 2 通りに表せます。

差 = 75% - 60% = 15 パーセントポイント

相対変化 = (75% - 60%) ÷ 60% = 25%

どちらも計算できますが、意味が違います。「15% 上昇」のように曖昧に書かず、パーセントポイント差か相対変化かを示します。相対変化は大きく見えやすいため、変化前後の値も併記します。

9.4 変化は比較基準で意味が変わる

数字の増減を述べるには、何と比べたかが必要です。

初期設定完了率が前月より上がっても、獲得経路が変わり、もともと完了しやすい顧客が増えただけかもしれません。比較基準とともに、同じ時期に変わった条件を書きます。

基準値が極端に小さい場合、相対変化は大きくなります。1 社から 2 社への増加は 100% 増ですが、増えたのは 1 社です。変化率、差、絶対数を組み合わせます。

9.5 平均値だけでは分布が見えない

本節でいう算術平均は、全体の合計を件数で割った値です。全体の資源量を見るには有用ですが、典型的な顧客やばらつきを必ずしも表しません。

5 社の支援時間が次の値だったとします。

30 分、35 分、40 分、45 分、250 分

平均は 80 分です。中央値は 40 分です。どちらかが正しく、どちらかが誤りなのではありません。

• 平均: 5 社全体の必要時間を見積もるときに役立つ
• 中央値: 順番の中央にある、典型的な位置を見るときに役立つ
• 最大値: 極端な負荷と停止条件を考えるときに役立つ
• 分位点: たとえば 90% の顧客が収まる範囲を見るときに役立つ

この例で「通常は 40 分程度」と言うだけでは、250 分かかった顧客を運用計画から消してしまいます。反対に、平均 80 分だけを使うと、大半の顧客に必要な時間を過大に見積もります。人員計画には合計と平均、運用設計には中央値と上位側の分布、例外対応には最大値と事例の中身が必要です。

ヒストグラム、箱ひげ図、点図などで分布を確認します。件数が少ない場合は、複雑な図より全データを点で示す方が分かりやすいことがあります。外れ値を見つけても、すぐ削除しません。入力誤り、単位違い、重複、実在する例外のどれかを確認し、除外するなら規則と影響を残します。

9.6 セグメントは平均の違いを見つける道具

全体平均の背後で、顧客群ごとに異なる動きが起きます。プラン、企業規模、獲得経路、業種、利用目的、地域などで分けると、支援対象の候補を絞れます。

ただし、切り口を増やすほど、偶然に大きな差が見つかります。データを見た後で都合のよい群だけを選ぶと、その差を再現できない可能性が高まります。

セグメント分析では、次を決めます。

1. その切り口が、どの行動を変えるか
2. 分類は互いに重複するか
3. 各群の分母は十分か
4. 他の条件が群ごとに偏っていないか
5. 分析前に想定した群か、分析後に見つけた群か

表中のパーセントは、小数第 1 位を四捨五入した整数です。判断に必要な精度に応じて桁を決め、分子と分母は丸めません。

この表から、小規模で広告経由の顧客が候補に見えます。しかし、広告経由では契約時期やプランも違うかもしれません。セグメント差は原因の確定ではなく、追加確認や試行対象を選ぶ手がかりです。

全体値だけでは、顧客構成の変化を施策の変化と取り違えることがあります。たとえば、小規模と中規模の両方で完了率が上がっていても、完了しにくい小規模顧客の比率が大きく増えれば、全体の完了率は下がる場合があります。反対の向きも起こります。これは集計による逆転として知られる現象です。全体と、意思決定に重要なセグメントの両方を見て、構成比も併記します。

個人や企業を細かく分けると、少数でも特定できる危険が高まります。分析に必要な粒度、アクセス権、表示する最小件数を決めます。差別や不公平な扱いにつながりうる分類では、法務・倫理・事業上の妥当性を確認します。

9.7 コホートで同じ時間軸にそろえる

コホートは、同じ時期または同じ出来事を起点にした集団です。SaaS では、契約月、初回利用週、支援開始月などで顧客をまとめます。

全顧客の解約率を月ごとに見ると、古い顧客と新しい顧客が混ざります。新規契約が急増した月は、まだ解約する機会の少ない顧客が増えるため、全体率がよく見えることがあります。

契約月コホートなら、それぞれを「契約から 30 日」「60 日」「90 日」の同じ経過時間で比較できます。次の仮想表は、2026 年 8 月 10 日時点で、各月の全顧客が所定の日数を経過した列だけを確定しています。

5 月・6 月コホートの未確定欄を 0% として扱いません。まだ観察期間が終わっていない状態は、統計では右側打ち切りと呼ばれます。観察期間が揃うまで待つか、各コホートで確定した範囲だけを比較します。

確定済みの顧客だけを抜き出す方法にも注意が必要です。早く契約した顧客だけが残り、製品、獲得経路、市場の条件が新しい顧客と違う可能性があります。どのコホートがどこまで観察済みかを表に残します。

コホートを作るときは、起点、対象への加入条件、経過時間、途中での対象変更を固定します。支援開始月コホートと契約月コホートは答える問いが違うため、同じ表へ混ぜません。

9.8 欠損とデータ品質を分析結果に含める

欠損は、単なる空欄ではありません。なぜ欠けたかによって、結論への影響が変わります。

• 設定イベントの送信障害で、特定期間だけ欠けた
• 解約顧客だけアンケートに答えにくい
• 古いプランでは獲得経路を記録していない
• 担当者が忙しい案件ほど工数入力が抜けた

欠損のある行を削除すると、残った顧客だけの結果になります。欠損率を全体と主要セグメントで示し、欠損を含めた場合と除いた場合で判断が変わるかを確かめます。

分析前に、判断を誤らないための基本的な確認を行います。

データを修正したら、元の値を失わない形で、修正規則、件数、実施者、実施日を残します。手作業で表計算シートのセルを上書きするだけでは、再現とレビューが難しくなります。

点の値と不確実性を分ける

観測した 60% を、将来も変わらない真の値とみなしません。同じ条件で別の顧客を観測すれば、割合は動きます。特に件数が少ないほど、ありうる範囲は広くなります。

推定値を示すときは、分子と分母に加え、可能なら信頼区間などの区間も示します。区間は「真の値が必ずこの中にある確率」を直接表すものではなく、使った方法と前提のもとで推定の不確実性を表す道具です。分析方法に応じた解釈を確認します。

少数の試行で区間が判断閾値の両側へ広がるなら、「差がない」と結論せず、現時点では方向や大きさを絞れないと報告します。追加データを待つか、失敗費用が小さければ条件付きで試行を続けます。

9.9 差があっても原因とは限らない

支援を受けた顧客の継続率が高くても、支援が継続を生んだとは限りません。担当者が成功しそうな顧客を選んだ、熱心な顧客ほど支援を希望した、同じ時期に製品が改善された、といった別の説明があります。

数字から言える範囲を分けます。

因果効果を知りたい場合は、比較群の作り方、対象者の割り当て、同時期の変化、観察期間を設計します。厳密な因果推論が期限内にできない場合も、関連を因果と呼ばず、仮説として小規模な試行へつなぎます。

統計的に差が検出されたことと、事業上重要な差であることも別です。顧客が非常に多ければ、ごく小さな差でも統計的に検出されることがあります。反対に、少数の試行では、重要な差があっても不確実性が大きくなります。差の大きさ、可能な範囲、意思決定の閾値を一緒に見ます。

9.10 AI に集計させても再計算する

AI は、列の意味の整理、集計式やコードの下書き、グラフ候補、異常値候補、別の切り口の提案に使えます。しかし、元データを見せただけで、業務上の定義やデータ生成過程まで理解するわけではありません。

依頼には、意思決定と指標仕様を含めます。

意思決定:
初期設定未完了の顧客へ、4 週間の手動支援を試すか決める。

分析単位:
顧客企業。利用者単位にはしない。

指標:
契約開始から 14 日以内に必須 5 項目を完了した企業数 ÷
対象期間の有料契約開始企業数。

確認:
1. 分子、分母、除外件数を先に示す
2. 全体と、企業規模・獲得経路別を示す
3. 各群の件数を必ず併記する
4. 平均だけでなく中央値、範囲、分布を確認する
5. 欠損、重複、定義変更の候補を一覧にする
6. 関連と因果を分け、別の説明を挙げる
7. 実行した計算式またはコードを示す

AI の出力は、次の順で検証します。

1. 元データの行数、期間、一意な顧客数と一致するか
2. 分子、分母、除外条件が指標仕様と一致するか
3. 小さな標本を手計算し、集計式と照合する
4. 合計と内訳が一致するか
5. 欠損が自動的に 0 へ置換されていないか
6. コードを保存し、同じ入力から同じ結果を再現できるか
7. 別の実装または既知の集計値で主要結果を再確認する

AI が示した「異常値」は、統計的に珍しい値の候補です。業務上の誤りとは限りません。原記録と担当者へ戻り、修正、除外、別群として扱う、残す、のいずれかを決めます。

重要な推奨を支える集計は、AI を使ったかどうかにかかわらず、必要に応じて別の担当者が確認します。指標仕様、コード、分子・分母、除外、元記録の標本をたどり、同じ入力から主要結果を再現します。レビュー担当が同じ出力だけを見るのではなく、計算過程へ戻れるようにします。

個人情報や機密情報を入力する前に、利用が承認された環境かを確認します。顧客名を削除しても、少数の属性の組み合わせから再識別できる場合があります。必要な列と粒度に絞り、アクセスと出力の共有範囲を管理します。

9.11 分析結果を選択肢へ戻す

最終成果物は、グラフの枚数ではなく、数字が選択へどう関係するかで構成します。

数字が判断閾値をまたがない場合、追加の小数点やグラフを増やしても選択は変わりません。反対に、結論が分母、除外、外れ値の扱いで変わるなら、単一の数字にまとめず、条件ごとの結果を示します。

最終判断では、各結果を事前条件へ戻します。完了率と支援時間が継続条件を満たせば継続候補、成果は満たすが工数上限を超えれば対象または手順を変更、成果条件を満たさなければ中止または別仮説へ移ります。重大な苦情、権限逸脱、安全上の問題のようなガードレール違反は、成果指標がよくても停止を優先します。

分析は、次のいずれかで止めます。

• 主要指標とガードレールが、事前に置いた行動条件のどちら側か判断できる
• 合理的な欠損・除外・外れ値の扱いを変えても、選択が変わらない
• 残る不確実性は、既存データの追加分析ではなく試行やインタビューで確認すべきである
• 期限または分析上限に達し、条件ごとの結論と未確認事項を示した

考えてみる問い

最近見た「平均」または「○% 増」という数字を一つ選び、分子、分母、件数、比較期間、分布を確認してください。その情報を加えると、同じ判断をするでしょうか。

数字を意思決定に変えるとは、値を複雑に加工することではありません。何を決めるかに合わせて指標を定義し、絶対数と比率、中心と分布、全体とセグメント、暦時間と経過時間を読み分け、データの限界を選択へ織り込むことです。

数字は、何が起きているか、どこで差があるかを示します。しかし、記録されていない経験や、なぜその行動を取ったかまでは十分に語りません。第10章では、インタビューを使い、数字だけでは見えない理由と未知の論点を探ります。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の指標仕様、比較表、分析確認手順は、以下の資料を踏まえた本書独自の整理です。

• NIST/SEMATECH e-Handbook of Statistical Methods ― Measures of Location ― 算術平均、中央値など中心を表す指標の性質を確認
• NIST/SEMATECH e-Handbook of Statistical Methods ― Measures of Scale ― 範囲、分散、標準偏差など、ばらつきの指標を確認
• CDC ― Principles of Epidemiology: Lesson 3, Measures of Risk ― 比、割合、率とリスク指標の定義を確認
• UK Statistics Authority ― Code of Practice for Statistics: Quality ― 適切なデータと方法、品質保証、説明の原則を確認

第10章 インタビューで未知を見つける

第9章では、小規模で広告経由の顧客に初期設定未完了が多いという差を見つけました。しかし、数字だけでは理由が分かりません。設定手順が難しいのか、始める時間がないのか、期待した機能がなかったのか、契約した人と使う人が違うのか。理由を決めつけて施策を作ると、間違った問題を解くことになります。

インタビューは、相手の経験、行動の経過、判断、制約、言葉を知る方法です。まだ想定していない論点を見つけ、既存の仮説を具体化できます。一方で、何人かが語った内容から、顧客全体の割合や施策の因果効果を推定する方法ではありません。

インタビューの価値は、賛否を数えることではなく、具体的な経験から仮説と選択肢を更新することにあります。

今回の意思決定は、「初期設定未完了の顧客へ、どの手動支援を試すか」です。インタビューでは、未完了になるまでの出来事、顧客が試した対処、社内の役割、支援を受ける制約を確認します。

本章でいう調査は、事業上の意思決定を支える顧客調査です。学術研究、法令上の調査、倫理審査が必要な研究の手続を代替するものではありません。また、参加者 ID、人数、発言、観察は、方法を説明するための仮想例です。実在案件の記録ではありません。

意思決定と未知を定める
  ↓
異なる経験を持つ対象者を選ぶ
  ↓
同意と安全な記録方法を決める
  ↓
具体的な過去の行動を聞く
  ↓
発言・解釈・示唆を分けて分析する
  ↓
仮説、追加調査、試行設計へ戻す

小さく取り消し可能な判断なら、20 分程度の設計から始められます。

1. 今回の意思決定と、まだ分からないことを 1 つ書く
2. 反対の経験を持つ対象者を含める
3. 目的、記録、利用範囲を説明し、同意を確認する
4. 直近の出来事、止まった点、試した対処、変えにくい制約を聞く
5. 発言と質問者の解釈を別の欄へ記録する
6. 仮説の更新と次の行動を 1 つ決める

録音しない場合は、相手の許可を得て要点を記録し、面談直後に発言、行動、解釈、未確認を分けて補います。重要な引用を正確に再現できない場合は、かぎ括弧付きの直接引用として使いません。

目的、対象者、説明文、質問、記録方法を一度に確認したい場合は、付録 D「インタビューガイドテンプレート」を使えます。毎回同じ質問票を作るためではなく、今回の意思決定に対して、聞くべき経験と聞いてはいけない誘導が分かれているかを見るために使います。

10.1 インタビューで分かることを限定する

インタビューを始める前に、問いがこの方法に向いているかを確認します。

「この支援を使いたいですか」と聞けば、好意的な回答を得られるかもしれません。しかし、回答には礼儀、期待、質問者との関係、想像上の条件が混ざります。将来の意思より、直近の具体的な出来事と、すでに取った行動を聞きます。

インタビューだけで結論を出す必要もありません。ログで起きたことを見つけ、インタビューで理由の候補を探し、小さな試行で支援の実行可能性と結果を確かめます。方法ごとの役割を組み合わせます。

10.2 研究課題を一文にする

「顧客の課題を知る」のような広い目的では、何を聞き、いつ終えるかが決まりません。意思決定、未知、必要な経験をつなぎます。

小規模・広告経由の顧客へ試す初期支援を選ぶため、契約から 14 日以内に設定を完了できなかった過程と、顧客自身では変えにくかった障害を明らかにする。

この研究課題から、次の学習目標を置きます。

1. 契約前に何を期待していたか
2. 最初に誰が、いつ、何をしようとしたか
3. どの時点で止まり、何を試したか
4. 社内外の誰が判断や作業に関わったか
5. どの障害が支援で変えられ、どれは変えられないか
6. 支援を受ける時間、権限、情報上の制約は何か

学習目標は、質問文そのものではありません。「期待を教えてください」と抽象的に尋ねるのではなく、契約を検討した時点の出来事をたどります。

既存仮説も記録します。

この表は仮説を証明するためではありません。質問者が自分の思い込みを認識し、反対の経験を探すために使います。

10.3 平均的な人ではなく、必要な経験を選ぶ

インタビューの対象者は、顧客全体を統計的に代表する標本とは限りません。意思決定に関わる異なる経験を意図的に選びます。

今回なら、次のような対比が必要です。

都合のよい参加者だけを集めません。営業担当が関係のよい顧客だけを選ぶと、強い不満、解約、利用しなかった経験が欠けます。募集経路、参加・不参加条件、断った人数を記録します。

募集前に、次を表へ置きます。

募集担当、インタビュー担当、営業・サポート担当の役割を分けます。参加の可否や発言内容を、契約更新や担当者評価へ不必要に共有しません。

最初から「10 人聞けば十分」とは決められません。対象の多様性、問いの狭さ、1 回の情報量、意思決定のリスクで必要数は変わります。最初の数件を行い、重要な対比が欠けていないか、新しい論点が増えているかを確認して追加します。

新しいテーマが出なくなることを飽和と呼ぶことがありますが、同じ種類の人に同じ聞き方をしただけでも、見かけ上の飽和は起きます。「もう新しい話がない」ではなく、どの対象群と問いの範囲で、新しい意思決定上の論点が増えなくなったかを記します。

10.4 参加者への説明と同意を設計する

インタビューは、話を聞ければよい作業ではありません。参加者が目的、記録、利用、断る権利を理解したうえで参加できるようにします。

開始前に、少なくとも次を説明します。

• 誰が、何の目的で行うか
• 所要時間と、行うこと
• 参加は任意で、途中でも断れること
• 録音、録画、文字起こしの有無
• 誰が記録へアクセスするか
• どの成果物へ、どの粒度で使うか
• 保存期間と削除方法
• AI や外部サービスを使うか
• 撤回を申し出られる範囲、期限、連絡先

「匿名化します」という一言だけでは不十分です。企業名を消しても、業種、役職、地域、出来事の組み合わせから本人や会社を推測できる場合があります。報告で引用する範囲と、再識別の危険を説明します。

本章では、氏名を参加者 ID に置き換え、別に対応表を保持する処理を仮名化と呼びます。対応表を使って本人へ戻れるため、個人情報として管理します。合理的な手段で本人を再識別できない状態にする匿名化とは分けます。具体的な法的定義と必要な処理は法域によって異なるため、適用される法令、契約、組織の専門手続を確認します。

撤回できる範囲は、実際の運用に合わせます。仮名化された個別記録と参加者を対応できる段階では除外できても、再識別できない形へ匿名化・集計した後は、特定の参加者分だけを取り除けない場合があります。「いつでもすべて削除できる」と一律に約束せず、どの時点まで何を撤回できるかを事前に伝えます。

参加者が取引先や従業員の場合、形式上は任意でも断りにくいことがあります。営業評価、人事評価、契約条件に影響しないことを伝え、担当者から離れた募集・実施方法を検討します。謝礼を出す場合も、参加を断れないほど過大にしません。

医療、未成年者、研究倫理審査が必要な調査など、特別な法令・倫理要件がある領域では、一般的な事業インタビューの手順だけで進めません。組織の法務、倫理、専門手続を確認します。

顧客は、インタビューをサポート、営業交渉、要望受付と受け取ることがあります。冒頭で、今回その場で解決・約束できることと、できないことを説明します。緊急の障害や契約上の問題が出た場合は、同意を得て担当窓口へ引き渡します。共有した範囲、担当者、対応期限を記録し、参加者へ連絡方法を伝えます。発言した要望が必ず実装されるとは約束しません。

10.5 質問票を会話の経路として作る

質問票は、同じ文を順番どおり読み上げる台本ではありません。必要な領域を漏らさず、相手の経験に沿って深掘りするための経路です。

今回の 45 分の構成例です。

本番前に、同僚または対象に近い協力者と試行します。予定時間に収まるか、専門用語が伝わるか、答えにくい順序になっていないか、誘導や二重質問がないかを確認します。試行で質問を変えた場合も、版と変更理由を残します。

実施前には、質問者自身の立場も記録します。所属、製品への関与、期待する仮説、参加者との関係、答えを期待している方向です。実施後には、どの発言へ強く反応したか、聞かなかった反対例はないかを振り返ります。質問者は透明な観測装置ではなく、会話と解釈へ影響する当事者です。

質問は、広い出来事から具体的な場面へ進めます。

最初に設定しようとした日のことを、覚えている範囲で教えてください。

その直前に何がありましたか。
誰が一緒にいましたか。
最初に何を開きましたか。
そこで何をしようとしましたか。
次に何をしましたか。
そのとき、どのような情報があれば進められましたか。

「なぜ完了しなかったのですか」と一度だけ聞くと、後から整えた理由が返りやすくなります。時系列、画面、会話、判断、試した対処をたどり、理由を出来事の中で具体化します。

10.6 誘導せず、具体性を上げる

誘導質問は、期待する答えや評価を質問の中へ含めます。

深掘りは、問い詰めることではありません。曖昧な言葉を、観察可能な出来事へ近づけます。

• 「大変だった」とは、何にどのくらい時間がかかったか
• 「みんな」とは、誰を指すか
• 「いつも」とは、直近ではいつ起きたか
• 「使えなかった」とは、どこまで進み、何が起きたか
• 「必要」とは、なければ何ができないか

沈黙をすぐ別の質問で埋めません。相手が思い出し、言葉を選ぶ時間を待ちます。質問者が理解した内容を短く言い返し、「こういう理解で合っていますか」と確認します。ただし、質問者の解釈を相手の言葉として記録しません。

10.7 役割を分けて記録する

可能なら、進行役と記録役を分けます。進行役が話を聞きながら詳細な記録まで行うと、相手の表情、沈黙、矛盾、次の深掘りを逃しやすくなります。

クライアントや営業担当が観察する場合は、参加者へ同席者と目的を説明し、同意を得ます。観察者は途中で評価、反論、販売説明をせず、裏側のチャットで進行役へ誘導を送り続けません。質問候補は記録し、進行役が会話の流れと参加者の安全を見て判断します。録音・記録へのアクセスも、説明した範囲に限定します。

記録には、少なくとも次を区別します。

発言と観察も、事実全体ではありません。参加者が覚えて語ったこと、インタビュー場面で観察したことです。ログや実際の画面と食い違う場合、どちらかを直ちに誤りと決めず、認識と記録の差を調べます。

インタビュー直後に 15 分程度で、事実、驚き、反対証拠、次回深掘りする点を短く記録します。複数件を終えてから記憶でまとめると、最近の強い発言だけが残りやすくなります。質問を追加・修正した場合は、版、変更日、理由、どの参加者から適用したかを残し、全員へ同じ質問をしたように扱いません。

10.8 発言、解釈、示唆を分けて分析する

印象に残る一言を、そのまま顧客課題や提案に変えません。発言から示唆までの推論をたどれる形にします。

まず、証拠側を記録します。

同じ ID で、判断側を記録します。

分析は、次の順で進めます。

1. 各記録を読み、出来事、行動、障害、対処、結果へ印を付ける
2. 似た内容をまとめる前に、反対の経験と例外を残す
3. 対象者ごとの時系列を比較する
4. 既存仮説を支持、反証、修正、新規に分ける
5. 各解釈の根拠となる参加者 ID へ戻れるようにする
6. 意思決定を変える示唆だけを要約する

複数人で分析する場合は、簡単なコードブックを作ります。

コードは客観的な正解ではなく、記録を同じ観点で比較するための分析規則です。新しい事例で定義を変えたら、以前の記録にも戻り、必要な範囲で付け直します。

発言回数だけで重要度を決めません。1 人しか語っていなくても、重大な安全問題や、試行を実行不能にする制約なら先に扱います。反対に、多くの人が好意的でも、具体的な行動や結果に結びつかない賛同は弱い証拠です。

引用は説明を具体化しますが、参加者全体を代表する証明ではありません。刺激的な一文だけを選ばず、文脈、対象者属性、反対例、何人に見られた論点かを必要な範囲で示します。公開・共有時は同意と再識別リスクを再確認します。

重要な推奨を支える解釈は、必要に応じて別の担当者が原記録、コード定義、反対例、参加者 ID をたどります。解釈が一致すること自体を目的にせず、どの証拠と前提から違いが生じたかを話し合い、採用した説明と残る異論を記録します。

10.9 AI は整理を助けても、意味を確定しない

AI は、質問案の批評、文字起こし、記録の整形、初期コードの候補、発言箇所の探索、反対例の検索に使えます。大量の記録を同じ観点で見直す補助になります。

質問票のレビューでは、答えを作らせるより、誘導と前提を指摘させます。

研究課題:
初期設定未完了までの過程と、顧客自身では変えにくかった障害を知る。

依頼:
1. 質問に含まれる誘導、評価、仮定を指摘する
2. 一度に複数のことを聞く質問を分ける
3. 将来の意向を、直近の具体的行動を聞く形へ直す
4. 仮説に反する経験を聞く質問を提案する
5. センシティブで答えにくい質問を示す

文字起こしは、固有名詞、専門用語、数字、否定、話者を誤ることがあります。「できた」と「できなかった」の誤認は解釈を逆にします。重要な引用と判断根拠は録音へ戻り、前後の文脈を確認します。自動要約だけを分析対象にせず、原記録へ戻れる状態を保ちます。

AI が複数の発言を、存在しない「典型的な顧客の声」へ統合することがあります。テーマ名は候補として受け取り、どの参加者のどの箇所が支えるか、反対例があるかを人が確認します。出力に参加者 ID と該当箇所を付けさせ、確認できない要約は採用しません。

個人情報、顧客の機密、健康・労務・財務などのセンシティブな内容を外部 AI へ入力する前に、利用目的、契約、保存場所、学習利用、アクセス権、越境移転、削除方法を確認します。承認された環境がなければ、AI を使わないか、個人を特定できない最小限の抜粋で代替します。

個人データの保護は、名前を置換するだけでは終わりません。分析に不要な属性を収集しない、早い段階で識別情報を分離して仮名化する、対応表へのアクセスを限定する、報告時に属性を集約する、必要なら再識別できない形へ匿名化する、といった工程全体で扱います。

参考資料の ICO は英国の監督機関です。本章では、目的に必要なデータだけを扱う考え方を参照しています。日本を含む実案件では、対象者、保管場所、委託先に適用される法令と契約を別途確認します。

10.10 インタビューを終え、意思決定へ戻す

「何人聞いたら終わりか」だけで終了を決めません。次を確認します。

• 意思決定に必要な主要な経験の対比を含んでいる
• 既存仮説を支持する例と反対例を確認した
• 新しいインタビューで、行動を変える論点が増えなくなった
• 重要な不一致と未確認事項を説明できる
• 次はログ、追加対象者、小規模試行のどれで確かめるか決まった
• 時間、参加者負担、予算の上限に達した

興味深くても今回の選択を変えない論点は、将来のどの意思決定へ使うか、担当と再検討時期が決まる場合だけ別の調査候補へ移します。それ以外は今回の範囲外として閉じます。

今回の結果は、次のように意思決定へ戻せます。

インタビュー結果から「顧客はこう思っている」と一般化しません。「今回の対象者では、どの状況で何が起き、どの仮説が生まれたか」を示します。試行する支援、対象条件、停止条件、次に測る数字へ変換して初めて、意思決定へ役立ちます。

考えてみる問い

最近聞いた顧客の要望を一つ選び、その人が要望を持つ前に何をし、どこで止まり、何を試したかを書き出してください。要望の言葉と、観察できる障害は同じでしょうか。

インタビューは、顧客の内面を直接読む方法ではありません。語られた経験を文脈の中で聞き、質問者の解釈を分離し、反対例と未確認事項を残すことで、数字だけでは見えなかった仮説を作る方法です。

調査とデータの部では、必要情報、外部資料、数字、インタビューを扱いました。次の第4部では、これらの証拠を使って顧客、課題、市場、競合、自社を理解し、事業上の選択肢を組み立てます。第11章では、顧客、利用者、購入者、意思決定者を分け、顧客課題の仮説を作ります。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の研究課題、対象者の対比、質問、分析表、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• GOV.UK Service Manual ― Using in-depth interviews ― インタビューが向く目的、質問、実施方法を確認
• GOV.UK Service Manual ― Find user research participants ― 対象条件、募集、同意、謝礼の考慮点を確認
• GOV.UK Service Manual ― Analyse a research session ― セッション直後の記録とチーム分析を確認
• Information Commissioner's Office ― Data protection principles ― データ最小化を含む個人データ取扱いの原則を確認

第4部 事業と市場を理解する

調査で集めた事実を並べても、どの事業機会を選ぶかは決まりません。この部では、顧客、競合、自社、市場、産業構造を、意思決定に必要な関係として読み解きます。

3C、TAM・SAM・SOM、PEST、5 フォース、バリューチェーン、SWOT などの略語やフレームワークが出てきますが、先に暗記する必要はありません。各章では、その道具が何を見落としやすく、どの選択を助け、どの場面では使わなくてよいかを扱います。AI は候補の展開と比較を助けますが、分類の境界、重要度、事業として引き受ける選択は人間が決めます。

第11章 顧客と課題を捉える

第10章では、初期設定未完了までの出来事をインタビューでたどりました。その結果、画面が分かりにくいという説明だけでは足りないことが分かりました。契約した人と設定する人が別である、管理者権限を誰に頼むか分からない、月末は面談時間を取れない。表面上は同じ「未完了」でも、止まる状況は異なります。

ここで「顧客の課題は設定画面の分かりにくさだ」とまとめると、証拠より早く一つの解決策へ寄ってしまいます。また、「中小企業の担当者」という人物像だけでは、誰が購入し、誰が使い、誰が許可し、どの場面で困るのかが分かりません。

ここで扱う顧客課題は、属性や要望の一覧ではありません。ある主体が特定の状況で進めたいことと、それを妨げる制約の仮説として捉えます。

今回の意思決定は、「どの顧客群へ、どの初期支援を試すか」です。第7章から第10章で得た仮想データと仮想インタビューを使い、誰のどの状況を対象にするかを決めます。本章の企業数、発言、役割は、方法を説明するための仮想例です。

関係する主体を分ける
  ↓
状況・行動・結果をたどる
  ↓
進めたいことと障害を仮説にする
  ↓
行動を変えられる単位で顧客群を分ける
  ↓
証拠、反対例、未確認を結ぶ
  ↓
対象、価値、次の検証を決める

小さな判断では、次の 6 点から課題仮説を始めます。

1. 誰が経験しているか
2. どの状況で起きるか
3. 何を進めようとしているか
4. 今はどう対処しているか
5. 進めないと何を失うか
6. 次に何を確かめるか

役割表、JTBD（顧客がある状況で達成したい進歩を見る考え方）、セグメント（似た課題や購買条件を持つ顧客群）、ペルソナ（調査に基づいて表現した代表的な利用者像）は、この 6 点を詳しくし、異なる選択肢を作る必要があるときに使います。すべての成果物を毎回作る必要はありません。

11.1 「顧客」を一人にまとめない

B2B（Business to Business、企業間取引）のサービスでは、お金を払う組織と、毎日使う人が違います。同じ組織の中でも、導入を提案する人、予算を承認する人、契約する人、設定する人、利用する人、管理する人が分かれます。

一人が複数の役割を担う場合もあります。小規模企業では経営者が購入、承認、利用を兼ねるかもしれません。役割表は組織図を作るためではなく、誰の行動を変えなければ導入が進まないかを見つけるために使います。

今回のインタビューで「管理者権限がない」と分かったなら、設定担当者だけへ説明を増やしても解決しません。権限を持つ承認者を特定し、依頼を届け、承認してもらう流れが必要です。

関心に加えて、権限と負担を置きます。

便益を得る人と負担を負う人が違えば、同じ価値提案では動きません。設定担当者には作業短縮、IT 管理者には必要情報と安全性、購入者には費用と契約条件が必要です。

役割は時間とともに入れ替わります。

問題を認識する
  → 候補を比較する
  → 予算・安全性を承認する
  → 契約する
  → 初期設定する
  → 利用・管理する
  → 更新・拡大・解約を決める

各段階で、誰が情報を集め、誰が拒否でき、誰が次へ引き渡すかを確認します。購入時の意思決定者と、更新時の意思決定者が同じとは限りません。

主体ごとに、次を確認します。

• 何を達成しようとしているか
• どの時点で関わるか
• 何を決め、何を決められないか
• 成功と失敗を何で判断するか
• 誰から情報、予算、権限を得るか
• 誰が便益を受け、誰が負担を負うか

利用者の便利さだけを改善しても、購入者が費用を承認しなければ導入されません。購入者に価値があっても、現場の負担が大きければ使われません。顧客理解は、一つの人物像ではなく、複数の主体の関係を理解することから始まります。

11.2 課題と解決策を分ける

顧客は「面談してほしい」「AI で自動化してほしい」「CSV（表形式のデータ交換ファイル）出力がほしい」と要望を語ります。要望は重要な証拠ですが、そのまま課題の定義ではありません。

要望:
管理者と一緒に設定する面談がほしい

状況:
設定担当者と権限を持つ人が別部署にいる

進めたいこと:
必要な権限を得て、期限までに初期設定を完了したい

障害:
誰に何を依頼すればよいか分からず、依頼後の進捗も見えない

解決策候補:
事前確認、依頼テンプレート、権限者の招待、合同面談、代行

要望を一段上の状況と結果へ戻すと、複数の解決策を比較できます。合同面談が有効な場合もあれば、時間を合わせられない顧客には逆効果です。

課題は、単なる不満でもありません。作業が少し面倒でも、顧客が対処でき、結果に影響しないなら、優先度は低いかもしれません。反対に、本人が強く不満を語らなくても、権限や制度の制約で重要な仕事を完了できないなら、事業上の課題になり得ます。

本書では、課題仮説を次の要素で書きます。

11.3 Jobs to Be Done を進歩の仮説として使う

Jobs to Be Done（JTBD）は、顧客が製品そのものを欲しいのではなく、ある状況で望む進歩を得るために製品や方法を選ぶ、と見る考え方です。JTBD には複数の実務的な流派があり、Job の定義や調査手順が完全に統一されているわけではありません。本書では、顧客を固定的な属性だけで捉えず、状況、進めたい結果、動機、制約、代替手段を結ぶ課題仮説を作る視点として使います。

今回なら、次のように書けます。

新しいサービスの運用を任されたとき、他部署の管理者へ必要事項を正しく依頼し、導入期限に間に合わせたい。そうすれば、権限待ちで計画が止まり、自分の責任として扱われることを避けられる。

この文は、確認済みの事実ではなく課題仮説です。「自分の責任として扱われることを避けたい」という動機が、全員にあるとは限りません。参加者の発言、実際の行動、反対例で確かめます。

JTBD を定型文へ埋めるだけでは、顧客理解になりません。

• 状況が広すぎる: 「仕事をするとき」
• 結果が解決策になっている: 「AI を使いたい」
• 動機を創作している: 「革新的な人と思われたい」
• 対象を平均化している: 「すべての中小企業」
• 制約と代替がない: 「効率化したい」

重要なのは文型ではなく、顧客が何を選び、何をやめ、どの状況で別の方法へ切り替えるかです。製品を導入しない、表計算で続ける、人へ依頼する、仕事自体を諦めることも代替です。

JTBD は、顧客の行動を説明する唯一の理論でも、結果を予測する法則でも、因果を自動的に証明する方法でもありません。状況と進歩を中心に仮説を作る実務上の視点として使い、ログ、インタビュー、試行で検証します。ここでいう進歩は顧客が望む変化であり、それ自体が安全、公平、他の主体にとって望ましいとは限りません。別の主体への負担とガードレールも評価します。

本章の用語は、次の関係にあります。

11.4 言葉より行動を上位に置くのではなく、差を見る

顧客が「面談なら使う」と答えても、実際には予約しないことがあります。言葉と行動が違うとき、「顧客は嘘をついた」と片づけてはいけません。

インタビュー時と実際の場面では、条件が違います。

• 面談の時間帯が合わなかった
• 上司や管理者の許可が必要になった
• 予約時に新しい情報の入力を求められた
• 問題の優先度が下がった
• 質問者に配慮して好意的に答えた
• 支援を受けることに心理的・組織的な負担があった

発言は、認識、期待、意味づけを知る証拠です。行動は、実際の制約下で何を選んだかを知る証拠です。どちらかを常に上位に置くのではなく、差が生じた条件を調べます。

行動も、内面の選好を直接見せるわけではありません。利用可能な選択肢、情報、予算、権限、制度、時間に制約された結果です。また、ログに記録されない行動もあります。言葉と行動の両方を条件付きの証拠として扱います。

表明された要望と観測された行動が一致しても、因果は確定しません。発言、行動、状況、結果をつなぎ、別の説明を残します。

11.5 現在の代替手段は課題の重要度を示す

顧客がすでに時間、費用、関係調整を使って対処しているなら、その行動は課題の重要度を考える手がかりになります。

今回の顧客は、管理者を探すために社内チャットで複数人へ連絡し、3 日待っていました。別の顧客は、外部の設定代行へ費用を払っていました。このような対処には、単なる「困っています」という発言とは異なる情報があります。

現在の代替を、次の観点で見ます。

切替の強さを見るには、現在の費用だけでなく、次を確認します。

• 何が起きたら今の方法を見直すか
• 誰が切替を提案し、誰が予算を持つか
• データ移行、学習、契約、社内承認に何が必要か
• 過去に別の方法を検討・購入・解約したことがあるか
• 新しい方法を試すために、すでに時間や費用を払ったか

代替手段がないことは、必ずしも巨大な未充足需要を意味しません。課題が重要でない、予算がない、解決できると思っていない、規制で動けない場合もあります。無行動の理由を確認します。

顧客が大きな費用を払っていても、自社がその価値を受け取れるとは限りません。既存の代替には、信頼、契約、社内政治、慣習など、機能以外の価値があります。置き換える対象を正確に捉えます。

11.6 セグメントは行動を変えるために作る

セグメンテーションは、顧客を似た群へ分けることです。年齢、企業規模、業種のような属性は使いやすい一方、属性だけでは同じ施策が効く理由を説明できないことがあります。

今回の目的は、初期支援の対象と方法を変えることです。そのため、次の切り口が候補になります。

よいセグメントは、少なくとも次を満たします。

1. 誰がどの群に入るか、一貫して判定できる
2. 群によって課題、選択、反応が意味のある形で違う
3. 必要な時点で識別し、到達できる
4. 群ごとに実際の施策や資源配分を変えられる
5. 十分な人数または事業価値がある
6. 差別、不公平、プライバシー上の危険を確認している

分けるほど理解が深まるわけではありません。群が小さすぎる、識別に高い費用がかかる、施策を変えられないなら、分ける実務価値は低くなります。

今回の仮説では、「小規模企業」をさらに、設定担当者が管理権限を持つ群と、他者承認が必要な群へ分けます。企業規模は募集の入口に使えても、支援方法を直接決めるのは権限関係かもしれません。

判定を運用できる仕様へ落とします。

識別できることと、原因であることは別です。他者承認が必要な群で未完了が多くても、企業規模、導入目的、契約時期などが同時に違う可能性があります。セグメントは試行対象と施策候補を決める仮説であり、その群で施策効果が大きいかは比較可能な試行で確かめます。

直接センシティブな属性を使わなくても、地域、役職、企業規模などが保護される属性や不利益の代理になる場合があります。分類によって誰が支援から外れ、どの負担が増えるかを確認し、必要以上の属性を集めません。

セグメントは固定的な人間分類ではありません。同じ企業でも、導入段階、担当変更、組織改編で状況が変わります。何の意思決定のための分類か、有効な時点はいつかを明記します。

11.7 ペルソナは証拠を圧縮する道具

ペルソナは、調査で見つかった行動、目標、制約のまとまりを、設計や意思決定で参照しやすくしたモデルです。名前、年齢、趣味、顔写真を付ければペルソナになるわけではありません。

今回なら、次のような短い記述にできます。

他部署承認待ちの設定担当者

契約後に初期設定を任されたが、管理権限は情報システム部門にある。導入期限はあるものの、依頼先と必要情報が分からない。同期面談は月末に取りにくい。現在は社内チャットで知人を探し、返答を待っている。

この記述の各要素は、参加者 ID、行動ログ、契約情報などへ戻れる必要があります。証拠がないのに「新しい技術が好き」「効率を重視」「SNS（交流・情報共有のためのオンラインサービス）で情報収集」のような設定を足しません。

ペルソナは実在の一人でも、平均的な人でもありません。複数の証拠を目的に応じて圧縮した仮説です。内部に重要な違いがあるなら、一つへ統合しません。ペルソナに合わない顧客を例外として捨てず、対象外とする理由や別の群を検討します。

顧客を理解するために、必ずペルソナが必要なわけでもありません。役割表、状況別セグメント、課題仮説の方が行動を決めやすいなら、それらだけで十分です。

11.8 課題仮説を証拠と反証へつなぐ

課題仮説は、確からしさの異なる内容を一文に混ぜず、構成要素ごとに証拠を置きます。

まず、仮説と証拠を置きます。

同じ ID で、限界と次の確認を置きます。

表の目的は、すべての欄を強い証拠で埋めることではありません。どこまで分かり、どこから推測かを見せ、次の確認を選ぶことです。

課題の重要度は、発言の強さだけでなく、次を組み合わせて判断します。

• 起きる頻度と対象数
• 顧客が失う時間、費用、機会、信頼
• 現在の対処へ払っている負担
• 事業成果との関係
• 自社が変えられる範囲
• 解決に伴う副作用と不公平
• 証拠の確かさ

頻度が高くても損失が小さい課題、損失は大きいが自社では変えられない課題があります。「重要」と「自社が解くべき」を分けます。

顧客にとって重要な課題でも、それだけで事業機会になるわけではありません。対象へ到達できるか、購入者が予算を持つか、提供費用に見合うか、自社の能力と方針に合うかを別に評価します。本章は顧客側の課題仮説を作り、競合・自社との適合は第12章以降、経済性は第5部へ引き渡します。

11.9 AI に顧客像を作らせず、証拠を整理させる

AI に業種と製品名だけを渡して「ペルソナを作って」と頼むと、もっともらしい名前、性格、悩み、行動を生成できます。しかし、それらは顧客調査の結果ではありません。一般的なパターンや文章上の補完を、実在顧客の事実として扱ってはいけません。

AI には、証拠の範囲を固定して依頼します。

意思決定:
どの顧客群へ、どの初期支援を試すか。

入力:
参加者 ID 付きの確認済み発言、行動ログの集計、契約条件。

依頼:
1. 主体、状況、進めたいこと、現在の行動、障害、代替へ整理する
2. 各記述に根拠となる参加者 ID またはデータ ID を付ける
3. 根拠がない内容を補わず「未確認」とする
4. 仮説を支持する証拠と反対例を並べる
5. 同じ属性でも行動が違う例を探す
6. セグメント候補ごとに、変えられる施策を示す
7. センシティブな属性による分類を警告する

AI が作ったテーマやセグメントは候補です。元の記録へ戻り、同じ証拠を重複して数えていないか、例外を落としていないか、複数人の発言を架空の一人へ統合していないかを確認します。

顧客名を消しても、企業規模、業種、役職、出来事の組み合わせから再識別できる場合があります。第10章と同じく、必要なデータへ限定し、承認された環境、アクセス、保存、出力共有を管理します。

11.10 対象、価値、検証を一文へ戻す

顧客理解の成果物は、人物紹介ではありません。誰のどの状況を優先し、何を変え、何をまだ確かめるかを意思決定者が選べる形にします。

今回なら、次のようにまとめます。

他部署の管理者承認が必要で、導入期限のある設定担当者を、最初の試行対象とする。IT 管理者へ必要情報と依頼方法を事前に届け、事業責任者の承認のもと、同期面談と非同期の依頼支援を選べるようにする。20 社で、14 日以内完了、支援工数、重大な苦情を比較する。企業規模だけでは対象を決めず、管理権限と期限を募集時に確認する。

この一文には、対象、状況、価値、支援の境界、検証が含まれます。ただし、まだ仮説です。試行結果が反対なら、対象条件、課題解釈、支援方法のどこを変えるかを記録します。

無料の試行へ参加したことは、継続利用や支払意思の証拠と同じではありません。この試行は、支援が設定完了と運用負荷をどう変えるかを主に学びます。購入、継続、価格を判断するには、実際の選択、更新、支払いを別の段階で確認します。

顧客課題を定めると、競合と自社を見る基準も変わります。同業他社の機能数ではなく、顧客が同じ進歩を得るために使う代替手段、自社がその状況へ到達できる能力、提供に必要な費用を比較できます。

考えてみる問い

最近聞いた顧客要望を一つ選び、主体、状況、進めたいこと、現在の代替、障害へ分けてください。その要望以外に、比較すべき解決策は何でしょうか。

顧客と課題を捉えるとは、もっともらしい人物像を詳しく描くことではありません。役割と状況を分け、要望を進めたいことへ戻し、言葉と行動の差、現在の代替、反対例を証拠として、誰の何を変えるかを選ぶことです。

第12章では、この顧客理解を 3C の「顧客」に置き、競合や自社能力との関係を見ます。3C の欄を埋めるのではなく、顧客が選ぶ代替に対して、自社がどの価値を実現できるかを判断します。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の役割表、課題仮説表、セグメント条件、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• GOV.UK Service Manual ― Start by learning user needs ― サービス要件より先に利用者、目標、状況、課題を理解する原則を確認
• Christensen Institute ― Jobs to Be Done Theory ― 状況下で求める進歩として Job を見る実務的説明を確認
• Harvard Business Review ― Know Your Customers' “Jobs to Be Done” ― JTBD の背景、状況、機能・社会・感情面の説明を確認。閲覧環境により全文購読が必要
• OpenStax ― Principles of Marketing: Market Segmentation ― 市場セグメンテーションの定義と主要な切り口を確認

第12章 3C は何を決めるために使うのか

第11章では、他部署の管理者承認が必要で、導入期限のある設定担当者を初期支援の候補としました。顧客課題が見えても、自社がその課題を解くべきか、どの方法で価値を届けるかはまだ決まりません。

競合がオンライン面談を提供しているから、自社も同じ面談を始める。顧客が AI を望んでいるから、自社も AI 機能を加える。社内にサポート担当がいるから、人手で対応する。このように顧客、競合、自社を別々に見ると、見つけた情報をそのまま施策へ変えてしまいます。

3C は、Customer（顧客）、Competitor（競合）、Company（自社）を整理するフレームワークです。しかし、3 つの欄を埋めることが目的ではありません。

3C は、顧客が重視する結果に対して、代替より意味があり、自社が実現・継続できる価値を選ぶために使います。

図 12-1 は、左から右へ「顧客が何を進めたいか」「今の代替は何を満たし、何を満たさないか」「自社は何を実現し続けられるか」を見ます。最後に、3 つの要約を並べるのではなく、価値仮説へ戻します。

3C は、意思決定に必要な関係を見落としにくくする実務上のフレームであり、分析結果を保証する完全な理論ではありません。制度、供給者、補完者、マクロ環境、組織政治、経済性をすべて網羅しません。今回の問いに必要な範囲を 3C で結び、足りない分析は第13章以降や専門確認へ渡します。

顧客、競合、自社の境界も固定ではありません。顧客企業の内製部門は顧客側の主体であり、同時に自社サービスの代替です。パートナーは自社能力の一部にも、将来の競合にもなります。分類の正解より、今回の選択へどう関係するかを優先します。

今回の意思決定は、「初期設定支援として、同期面談、非同期の権限依頼支援、両方の組み合わせのどれを試すか」です。本章の企業、機能、人数、工数は、方法を説明するための仮想例です。

意思決定と選択肢を定める
  ↓
顧客の選択基準と代替を確認する
  ↓
競合が価値を実現する仕組みを比べる
  ↓
自社の能力・費用・制約を確かめる
  ↓
3 つの関係から価値仮説を作る
  ↓
捨てる選択肢と次の検証を決める

12.1 3C の前に意思決定を置く

「3C 分析をしてください」だけでは、調査範囲が決まりません。市場全体、競合全社、自社の全部門を調べても、判断へ使えない情報が増えます。

最初に、次を一文にします。

8 月末までに、他部署の管理者承認が必要な設定担当者 20 社へ、同期面談、非同期の権限依頼支援、両方のどれを 4 週間試すか決める。

選択肢と評価基準も先に置きます。

評価基準は、14 日以内完了、支援工数、権限者への到達、重大な苦情、継続可能な運用です。3C で新しい情報が出ても、この意思決定と基準へ戻します。

分析基準日は 2026 年 8 月 10 日とし、まず 4 週間の試行可能性を判断します。競合仕様、顧客条件、自社人員は変わるため、試行終了時と、100 社へ拡張する判断時に再確認します。

小さな判断なら、次の 4 問から始められます。

1. 顧客は何を進めるため、今は何と比べているか
2. 代替はどの条件で選ばれ、どこで失敗するか
3. 自社は何を再現可能な形で実現できるか
4. 3 つを合わせると、どの選択肢を試すか

本章では、意味のある差を顧客の選択基準へ影響する違い、継続性を定めた期間に必要な品質と費用で提供し続けられること、と呼びます。短期試行で価値を確かめることと、長期に差が残ることは分けます。

12.2 顧客は属性情報ではなく選択の仕組みを見る

顧客の欄へ、年齢、企業規模、業種、ニーズを並べるだけでは足りません。今回の選択に関わる主体、状況、進めたいこと、代替、評価基準を見ます。

顧客を見るときに重要なのは、顧客が何を好むかだけではありません。誰が便益を受け、誰が作業や危険を負い、誰が拒否できるかです。設定担当者は面談を望んでも、IT 管理者が外部との画面共有を認めない場合があります。

選択基準は、顧客へ尋ねた重要度の順位だけで決めません。実際に何へ時間・費用を使ったか、何を理由に別の方法へ切り替えたか、どの条件で利用を断ったかを確認します。

顧客分析の成果物は「中小企業は支援を求めている」という一般文ではなく、次のような条件付きの仮説です。

他部署承認が必要で導入期限のある設定担当者は、一般的な画面説明より、権限者へ正確な依頼を届け、進捗を確認できることを重視する。ただし、外部共有を禁止する企業と、同期時間を取れない担当者は面談を選びにくい。

12.3 競合は同業他社だけではない

競合は、同じ製品分類に属する企業だけではありません。顧客が同じ進歩を得るために比較する方法が競合です。

今回の代替には、次が含まれます。

• 競合 SaaS（継続利用型のソフトウェアサービス）のオンボーディング支援
• 自社の営業・サポートへ個別に連絡する
• 社内の IT 管理者へ直接頼む
• 外部の導入代行へ委託する
• ヘルプや動画を見て自力で進める
• 表計算や旧システムを使い続ける
• 導入を延期または中止する

競合企業の機能一覧だけを作ると、無行動や内製の強さを見落とします。顧客が「何もしない」を選ぶなら、競う相手は別製品ではなく、変更の費用と危険です。

代替は、同じ条件で比較します。

「24 時間サポートあり」と「専任担当者あり」は、表面上の機能です。顧客が権限者へ到達できない課題に対し、その仕組みが何を変えるかを見ます。専任担当者がいても、社内の承認経路には入れないかもしれません。

競合の導入事例は、その企業が公開した成功例です。平均的な成果、失敗率、運用費用を直接示すとは限りません。第8章の方法で、定義、対象、期間、比較条件、出典へ戻ります。

公開仕様から分かるのは、公開時点で企業が約束・説明している内容です。実際の利用率、応答品質、担当工数、顧客ごとの契約条件までは確認できない場合があります。確認できない運用を推測で埋めず、「公開情報では不明」と残します。顧客への聞き取りや利用可能な試用を行う場合も、契約、利用規約、倫理に反する偽装や不正アクセスは行いません。

競合の模倣ではなく、差の意味を考える

競合にある機能が自社にないことは、ただちに弱みではありません。その差が、対象顧客の選択基準に影響するかを確認します。

差別化は、違うこと自体ではありません。顧客が重視し、代替では満たしにくく、自社が継続して実現できる意味のある差です。

競合も反応します。依頼テンプレートは模倣しやすく、競合が同様の支援を追加する可能性があります。値下げ、提携、対象顧客の変更も考えます。

次の表は競合行動の予測や発生確率ではなく、反応が起きた条件でも価値仮説が成り立つかを見るシナリオです。

最初の試行で確かめるのは、顧客価値と運用可能性です。長期の防御力は、蓄積する学習、顧客接点、業務への組み込み、信頼、流通、再現しにくい能力が生まれるかという別の仮説として扱います。

12.4 自社は保有資源ではなく実現能力を見る

自社の欄へ、ブランド、技術、人材、顧客基盤を並べても、今回の価値を提供できるかは分かりません。資源を、顧客結果を実現する活動へつなぎます。

試行責任者はカスタマーサクセス責任者、データ確認は分析担当、安全・権限の承認は情報管理責任者とします。4 週間の試行後、次を分けて判断します。

• 20 社まで: 既存 2 人で実施し、1 社あたり工数と例外を測る
• 100 社を次の候補として検討: 顧客構成、支払・継続、週あたり総工数、既存業務への影響、仕組み化できる作業を再確認する
• 上限超過: 対象を絞る、自動化する、採用・提携する、中止するを比較する

能力は「できる／できない」の二値ではありません。

• 現在すぐにできる
• 小規模ならできる
• 仕組み化すれば繰り返せる
• パートナーとならできる
• 法令・契約・安全上、行わない

20 社の試行を人手で実施できても、2,000 社へ同じ方法を続けられるとは限りません。試行の実行可能性と、事業としての拡張可能性を分けます。

自社評価では、強みを過大評価しやすくなります。「顧客に近い」「技術力が高い」のような表現は、今回の活動へどう効くか、競合や代替と比べて差があるか、再現できるかを証拠で確認します。

弱みも、一般的な欠点ではなく、価値仮説を実現するうえでの制約として書きます。競合より従業員数が少ないことではなく、例外対応が週 20 時間を超えると通常サポートが維持できないことが制約です。

詳細な経済性は第5部で扱いますが、試行でも粗い下限を見ます。1 社あたり支援時間、追加ツール費用、既存業務から失う時間、顧客が現在の代替へ払う費用を記録します。価値があっても、提供するほど通常業務を壊す案は、対象変更か中止の候補です。

12.5 3 つを重ねて価値仮説を作る

3C の分析は、3 つの要約を並べたところでは終わりません。関係を一文へ戻します。

顧客:
他部署承認と期限があり、同期時間を取りにくい設定担当者は、
権限者へ正確な依頼を届け、進捗を確認したい。

競合:
面談、動画、代行はあるが、時間制約、情報共有、費用の条件で選ばれにくい。
社内連絡と先送りが主要な代替である。

自社:
権限要件を説明し、メールを送る能力はあるが、
承認状態の記録と大量の例外対応はまだできない。

価値仮説:
権限者への依頼準備を非同期で支援し、必要な例外だけ人へつなぐ。

この仮説は、自社の現在能力に合わせて小さくしています。最初から完全な承認管理機能を作るのではなく、依頼テンプレート、権限者の連絡先確認、返信がない場合の人への引き渡しを試します。

価値仮説の構成要素を、証拠状態へつなぎます。

同じ資料を複数の確証として数えません。顧客の発言、競合の公開資料、自社の社内見積もりは、生成方法と限界が違います。各 ID から原記録、反対例、更新日へ戻れるようにします。

証拠状態はプロジェクト責任者がレビューします。「確認済み」は原記録が該当記述を直接支え、定義・対象・期間を確認した状態、「一部確認」は構成要素の一部だけを直接確認した状態、「仮説」は証拠からの推論、「未実測」はまだ観測していない状態です。状態を変えたら、確認者、日付、理由を台帳へ残します。

最初に、安く反証できる条件を置きます。

価値仮説を、次の観点で確認します。

すべてが強い必要はありません。弱い箇所を未確認として残し、試行で何を学ぶかを決めます。

12.6 3C の事実、解釈、判断を分ける

12.5 の証拠台帳は、価値仮説の構成要素を継続的に更新するための記録です。本節の表は、一つの記述を事実、解釈、代替説明、判断へ分けるための思考手順です。同じ情報でも、3C のどこへ置くかより、推論を分けることが重要です。

「競合は弱い」「自社は信頼されている」「顧客ニーズが高い」は、事実ではなく評価です。何と比べ、どの証拠から、どの条件で言えるかを書きます。

3C の情報が矛盾する場合もあります。顧客価値は高いが、自社には安全に提供する能力がない。自社には能力があるが、顧客は無行動を選ぶ。競合より優れていても、顧客にとって差が重要ではない。その矛盾が、投資、提携、対象変更、見送りの判断になります。

12.7 3C を使わなくてよい場面

3C は、顧客・代替・自社の関係をまとめて選ぶ必要があるときに有効です。すべての相談で大きな分析を行う必要はありません。

意思決定が小さく取り消し可能で、顧客、代替、自社能力が既に分かっているなら、4 問だけで始められます。反対に、大規模投資、撤退、新市場参入では、3C だけでなく市場規模、産業構造、経済性、リスクを後続章で詳しく確認します。

3C を作った結果、どの選択肢も変わらないなら、分析範囲が広すぎたか、問いが曖昧です。表の完成度ではなく、選択と次の検証が変わったかで評価します。

3C の調査は、主要な顧客条件と代替、自社の実行制約を同じ基準で比較でき、残る不確実性が試行でしか確かめられない状態で止めます。新しい競合を探し続けず、決定期限、調査上限、選択を変える情報の有無で終了します。

12.8 AI に 3 つの欄を埋めさせず、関係を批評させる

ここでの AI は、調査を代行して結論を出す道具ではありません。確認済みの材料を渡し、関係の抜けや都合のよい解釈を点検する補助役として使います。

AI に「この会社の 3C 分析をして」とだけ頼むと、一般的な顧客像、有名な競合、抽象的な自社の強みを生成します。出典のない市場知識や、実在しない顧客ニーズが混ざる可能性があります。

確認済みの証拠と意思決定を渡します。

意思決定:
同期面談、非同期の権限依頼支援、両方のどれを 20 社で試すか。

入力:
- 顧客: 参加者 ID 付き発言、行動ログ、役割・権限表
- 競合: 原資料を確認した代替比較表
- 自社: 担当者、工数、機能、契約・安全制約

依頼:
1. 各記述を事実、解釈、仮説、未確認へ分ける
2. 顧客の選択基準に関係しない競合差を除く
3. 各自社能力が、どの顧客結果をどう実現するか示す
4. 主要な代替として無行動・内製・先送りも含める
5. 価値仮説を支持する証拠と反対例を並べる
6. 顧客価値はあるが自社が実現できない案を示す
7. 自社は実現できるが顧客価値が弱い案を示す
8. 次に確認すべき不確実性を一つ提案する

AI が新しい競合、機能、顧客行動を挙げた場合は、資料候補として扱い、第8章の方法で原資料を確認します。AI の一般知識を、競合の現行仕様や顧客の事実として表へ入れません。

AI は、関係の抜け、都合のよい解釈、反対例を探す批評役に向きます。最終的にどの顧客を選び、どの能力へ投資し、どの代替と競うかは、資源と責任を負う人間が決めます。

12.9 選ぶ案と捨てる案を示す

3C の成果物は、顧客、競合、自社の説明資料ではありません。選択、理由、前提、捨てた案、次の検証を示します。

現状維持も、捨てた案として記録します。追加支援の費用や危険が便益を上回るなら、何もしない判断もあり得ます。

考えてみる問い

最近作った競合比較表を一つ選び、各差について「どの顧客の、どの選択基準を変えるか」「自社はなぜ継続して実現できるか」を書いてください。答えられない差は、今回の判断に必要でしょうか。

3C を使うとは、3 つの情報群をきれいに整理することではありません。顧客が重視する結果、現在選ぶ代替、自社が実現できる活動を関係づけ、試す価値仮説と捨てる案を選ぶことです。

第13章では、選んだ顧客群がどの程度存在し、どこまで到達でき、市場がどう変化するかを見ます。TAM、SAM、SOM と PEST を、巨大な数字や外部要因の一覧ではなく、投資範囲と前提を決めるために使います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の 3C 関係表、能力表、価値仮説、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• 大前研一『The Mind of the Strategist: The Art of Japanese Business』McGraw-Hill、1982 年 ― 顧客・競合・自社を戦略的三角形として見る 3C の背景を確認
• U.S. Small Business Administration ― Market research and competitive analysis ― 顧客、市場、競争優位、競合比較で確認する項目を確認
• Harvard Business Review ― What Is Strategy? ― 異なる活動の組み合わせ、トレードオフ、適合の説明を確認。閲覧環境により全文購読が必要
• GOV.UK Service Manual ― Start by learning user needs ― 顧客の目標、状況、課題を先に理解する原則を確認

第13章 市場の大きさと変化を読む

第12章では、他部署の管理者承認が必要な設定担当者へ、非同期の権限依頼支援を試す案を選びました。20 社で価値を確かめるだけなら、小さなチームでも始められます。しかし、専用機能を開発し、人を採用し、販売へ投資するには、試行の先にどれほどの機会があるかを考える必要があります。

ここで「この市場は 1,000 億円ある」という調査会社の数字を見つけても、投資判断はできません。その数字に、今回の顧客がどれほど含まれるか、自社が届けられるか、何年の数字か、売上になるまでに何が必要かが分からないからです。

市場規模は、どこかに存在する一つの正解ではありません。対象、価値、単位、期間、価格、到達方法という前提から作る推計です。

TAM（総需要機会）、SAM（提供条件を満たす市場）、SOM（能力と資金の範囲で獲得を目指せる市場）は、市場を大きく見せるための数字ではありません。投資範囲を段階的に定め、検証すべき前提を見つけるために使います。PEST も外部要因の一覧ではなく、その前提が時間とともにどう変わるかを考えるために使います。

今回の企業、顧客数、価格、比率は方法を説明するための仮想例です。予測値ではなく、計算と判断のつながりを見るための仮定です。

13.1 市場規模の前に投資判断を置く

「市場規模を調べてください」だけでは、必要な精度も範囲も決まりません。新機能へ 2 週間使う判断と、10 人を採用する判断では、必要な証拠が違います。

今回の意思決定を、3 段階に分けます。

市場規模が直接必要なのは、主に 3 段階目です。試行前に世界全体の市場を精密に推計しても、対象者が支援を使うかは分かりません。反対に、工数の大きな開発や採用を決めるのに、20 社の反応だけでは足りません。

最初に、次を明記します。

• どの投資を、いつ決めるのか
• どの顧客の、どの課題に対する市場か
• 顧客数、利用件数、年間支出、売上のどれを測るのか
• 何年時点、どの地域、どの通貨・税区分で比べるのか
• どの前提が変わると、選択が変わるのか

本章では、2026 年 8 月時点の仮定を使い、2027 年度に専用機能へ投資するかを考えます。市場の単位は税抜円による年間売上機会、地域は日本、対象は法人向け業務 SaaS の初期設定支援とします。数えるのは、1 年間に発生する新規導入案件です。同じ企業の更新は含めず、別製品の新規導入は別案件として数えます。

本章では、次の言葉を区別します。

仮に専用機能の初期投資を 600 万円、初年度の追加運用費を 240 万円とするなら、年間売上 432 万円だけでは初年度に回収できません。この粗い条件を先に置くと、「市場があるか」ではなく、「どの売上・期間・学習なら段階投資に値するか」を問えます。厳密な採算と投資評価は第 5 部で扱います。

13.2 TAM、SAM、SOM は異なる制約を答える

TAM（総需要機会）、SAM（提供条件を満たす市場）、SOM（能力と資金の範囲で獲得を目指せる市場）は、3 つの同心円として紹介されることがあります。しかし、重要なのは円の大小ではなく、各段階で何の制約を加えたかです。

用語の定義には資料や組織による差があります。とくに SOM を「獲得可能市場」とする場合と「予測売上」に近く扱う場合があります。略語だけで合意せず、この案件で加える制約と単位を表に残します。

TAM は「世界中の SaaS 売上」ではありません。今回の価値と無関係な支出を含めると、数字は大きくなっても判断との距離が広がります。

今回なら、次のように境界を置けます。

TAM:
初期設定で他部署の承認を必要とする国内の法人 SaaS 新規導入件数
× 1 件あたりの想定価格

SAM:
TAM のうち、自社製品の対象業務・企業規模・安全要件に適合し、
現在の販売・支援方式で提供できる範囲

SOM:
SAM のうち、2027 年度に識別し、接触し、契約し、
提供能力の上限内で支援できる範囲

TAM から SOM へ一律に「10%、その 10%」と縮めてはいけません。地域、適合、到達、契約、供給能力という別々の制約を、一つずつ根拠へ結びます。

13.3 トップダウンは境界を見つける

トップダウン推計は、広い統計や業界資料から、対象条件を順に絞る方法です。公的統計や信頼できる業界調査を使えば、桁や上限を短時間で確認できます。

仮に、次の資料が得られたとします。

1 件あたり 60,000 円の想定価格を仮定すれば、最後の 6,000 件は税抜年額 3.6 億円です。ただし、この数字は事実ではありません。複数の仮定を掛けた結果です。顧客が感じる価値や表明した支払意思とも、実現売上とも区別します。

トップダウンでは、各段階の意味を確認します。

• 「法人数」は事業所数やアカウント数と同じか
• 「SaaS 導入」は新規契約か、既存契約を含むか
• 30% は観測値か、少数インタビューからの仮説か
• 価格は現在の支出、表明した支払意思、将来の料金のどれか
• 同じ母集団・地域・期間の比率を掛けているか

異なる調査の比率を掛け合わせるときは、母集団の違いが誤差になります。大企業を中心にした導入率を、中小企業を含む法人数へ掛ければ、対象を過大に見積もるかもしれません。

トップダウンは、詳細が分からない初期に上限と桁を知るのに向きます。一方、販売経路、獲得速度、提供上限を直接は示しません。SOM を作るには、現場から積み上げる必要があります。

13.4 ボトムアップは事業の仕組みを試す

ボトムアップ推計は、実際に識別・接触・契約・提供できる単位から積み上げます。

今回の 2027 年度計画を仮置きします。

計算は次のとおりです。

1,200 社 × 25% × 80% × 30% = 72 社
72 社 × 60,000 円 = 年間 4,320,000 円

ここで終えると、販売側だけを見た数字です。提供能力も確認します。

担当者が使える時間: 週 20 時間 × 48 週 = 960 時間
1 社あたり初期支援: 4 時間
理論上の上限: 240 社
通常業務と例外のため 50% を確保: 計画上限 120 社

需要側の 72 社（計画上は約 70 社）は、計画上限 120 社を下回ります。この仮定では供給能力より、有料購入率が制約です。SOM の件数は、需要から見込む件数と、品質を保って供給できる件数の小さい方です。仮に購入希望が 180 社へ増えても、現状の SOM は 120 社で頭打ちになります。売上予測だけを上げず、対象制限、自動化、価格、採用、提携を選ぶ必要があります。

この式は既存の顧客接点を使う基準計画です。新規参入や新しい販売経路では、次の段階が加わります。

到達可能な見込み客 × 接触率 × 商談化率 × 契約率
× 提供可能率 × 想定価格

広告、紹介、販売パートナーなど経路ごとに、件数、期間、獲得費用、対象の適合率が違います。獲得費用は上の件数式とは別に採算へ反映します。SAM が大きくても、新しい経路を作る投資と時間を置かなければ初年度 SOM には入りません。

ボトムアップの利点は、数字が事業活動へつながることです。弱い仮定が分かれば、試行で観測できます。欠点は、現在の販売経路や提供方法に引っ張られ、将来の新しい経路を過小評価しやすいことです。

13.5 二つの推計が一致しない理由を調べる

トップダウンとボトムアップは、一致させるための二方式ではありません。差を手掛かりに、境界、到達方法、時間軸、能力のどこに問題があるかを調べます。

今回の仮定では、トップダウンの SAM は 6,000 社、ボトムアップの初年度 SOM は 72 社です。約 1.2% しか獲得しないから悲観的、とは限りません。SAM は提供可能な範囲、SOM は 1 年以内に到達する計画だからです。

推計が大きく違うときに平均を取ると、理由が消えます。定義を揃え、それでも残る差を、未知の仮定として記録します。

13.6 市場規模の数字が作られる過程を残す

市場規模には、元の観測値と推計者の判断が混ざります。「市場は 3.6 億円」とだけ書くと、再計算も更新もできません。

推計表には、少なくとも次を残します。

市場調査会社の数字も、そのまま事実扱いしません。調査対象、定義、推計方法、基準年、予測方法が公開されているかを確認します。詳細が有料で見えない場合、確認できたのは要約の数字だけです。重要な投資を、その数字だけへ依存させません。

成長率にも注意が必要です。前年 1 億円から 2 億円になれば 100% 成長ですが、絶対額は 1 億円増です。複数年の年平均成長率は開始年と終了年を滑らかにつなぐため、途中の急増・減少を隠します。過去の成長率を、そのまま将来へ延長しないようにします。

13.7 PEST は外部要因を前提の変化へつなぐ

PEST は、Political（政治）、Economic（経済）、Social（社会）、Technological（技術）の観点で外部環境を見る方法です。各欄へニュースを貼るだけでは、意思決定につながりません。

外部の出来事を、影響の経路、変わる仮定、観測指標、対応へつなぎます。

この表は将来を当てる予言ではありません。「規則が厳格化する」も現時点では仮説です。重要なのは、起きた場合にどの計算セルが変わり、どの判断を見直すかです。外部変化から結果までに時間差がある場合は、規則の公布、顧客審査の変更、契約条件の変更、利用率の変化を順に観測します。

外部変化には正負の両方があります。規則の厳格化は外部支援を難しくする一方、安全に配慮した仕組みへの需要を高める可能性があります。一方向の物語へ決めつけず、反対の経路も置きます。

PEST を広く行う価値があるのは、投資期間が長い、外部環境への依存が大きい、過去の実績を将来へ延長しにくい場合です。4 週間の文言変更のように、小さく取り消せる判断なら、重大な制度・安全制約だけを確認すれば十分です。

事業責任者が四半期ごとに仮説を見直し、規則、主要 API、顧客の安全審査に重大な変更があれば期中でも更新します。ニュースの件数ではなく、計算前提か対応を変える事象を記録します。

13.8 点予測を感度分析へ変える

市場推計は、前提を変えると結果も変わります。感度分析は、一つまたは少数の入力を変え、結果への影響を調べる方法です。シナリオ分析は、同時に起こり得る複数の前提を、内部で整合する一つの状況として組み合わせます。前者で影響の大きい変数を見つけ、後者で変数同士の関係や対応を考えます。

初年度 SOM の式を使います。

年間売上 = 判定可能顧客数 × 適合率 × 到達率 × 有料購入率 × 年間単価

単一の楽観・基準・悲観シナリオだけでは、どの前提が結果を動かしたか分かりにくくなります。まず、一つずつ変えます。

他の値を基準に固定し、万円未満を丸めた仮想計算です。基準値は税抜年額 432 万円です。最も幅が大きいのは有料購入率です。したがって、法人数をさらに精密にするより、試行で利用と購入を分けて確かめる方が、今回の判断価値は高いと分かります。

工数も同時に見ます。1 社あたり 4 時間なら計画上限は 120 社ですが、例外が増えて平均 8 時間になれば 60 社です。購入希望が 72 社でも 12 社分は提供できません。購入率の上昇が売上へ直線的につながるのは、供給能力に余裕がある範囲だけです。

前提同士が連動する場合は、一つずつ変えるだけでは足りません。価格を上げると有料購入率が下がる、対象を広げると適合率や支援品質が下がる、といった関係をシナリオで確認します。

本章では各前提へ確率を割り当てた期待値までは扱いません。確率を置けるだけの反復データがない段階では、範囲、境界、シナリオを使い、判断が変わる条件を明示します。

感度分析の目的は、幅を付けて予測を安全に見せることではありません。結果を動かす前提を特定し、追加調査、実験、契約、段階投資のどれで不確実性を扱うか決めることです。

13.9 AI には計算と反証を任せ、前提を決めさせない

AI は、式の展開、単位の統一、複数ケースの再計算、欠けた前提の指摘に使えます。一方、「この市場の TAM を出して」と頼むだけでは、異なる定義の数字をつないだり、根拠のない比率を補ったりする危険があります。

入力には、意思決定、定義、数値、出典、確度を含めます。

意思決定:
2027 年度に初期設定支援の専用機能へ投資するか。

固定する定義:
- 単位は国内の年間売上機会、税抜円
- 顧客は他部署の管理者承認が必要な法人
- SOM は 2027 年度内に識別、接触、契約、提供できる範囲

入力表:
各変数について、値、単位、対象期間、出典、
観測／外部推計／代理指標／仮定の区分を付ける。

依頼:
1. TAM、SAM、SOM の各計算式を示す
2. 単位、母集団、期間の不一致を指摘する
3. 数値を補わず、不足は未確認と記す
4. 各変数を一つずつ動かした感度分析を行う
5. 前提の連動を含む反対シナリオを 2 つ作る
6. 選択を変えやすい前提と、安く確かめる方法を示す
7. すべての計算を再現可能な表として出す

AI の計算結果は、表計算や短いスクリプトで再計算します。特に割合、複利、通貨換算、桁、期間の扱いを確認します。AI が示した統計や市場資料は、存在、本文、定義、日付を原資料で確かめます。

AI は、前提を置いた責任を負いません。市場の境界、価格、獲得可能性、投資上限を決めるのは、その資源と結果に責任を持つ人間です。

13.10 数字ではなく投資条件を結論にする

市場分析の成果物は、大きな TAM のスライドではありません。どこまで投資し、何を確かめ、どの条件なら拡大・変更・中止するかです。

今回の仮想例なら、次のようにまとめます。

20 社は価値と運用を学ぶ試行対象、100 社は次に案内する母集団、1,200 社は年間に対象条件を判定できる母集団です。100 社すべてが購入するという意味ではありません。

無料試行の好意的な発言を、有料購入の証拠にはしません。課題の発言、無料利用、具体的な価格提示への反応、発注手続き、有料契約、更新では、確かめている仮説が違います。購入仮説については、顧客が行動し、時間・費用・組織上の負担を引き受けるほど証拠が強くなります。更新は継続価値の証拠ですが、課題の原因を単独で証明するものではありません。

試行では価格を提示し、購入しない理由も記録します。価格を変えれば購入率、対象顧客、支援要求も変わるため、独立した数字として扱いません。限られた期間に複数経路や価格を同時に動かしすぎず、その段階で選択を最も変える未知を一つ定めます。

毎月見る先行指標は、対象判定数、案内到達率、価格提示後の購入率、1 社あたり工数、重大な安全・品質問題です。対象が少ないなら市場境界、到達しないなら経路、購入されないなら価値・価格、工数超過なら提供方法を見直します。現在の経路で届かないことと、市場自体が存在しないことを混同しません。

市場が大きくても、自社が対象を識別できず、届けられなければ、今回の SOM は小さいままです。市場が小さく見えても、高い価値を少数へ継続して提供できれば、投資に値する場合があります。

考えてみる問い

最近見た市場規模の数字を一つ選び、その数字の対象、単位、期間、計算、出典を書いてください。次に、その数字が 2 倍または半分なら、自分の意思決定が本当に変わるかを考えてください。変わらないなら、先に確かめるべき前提は何でしょうか。

TAM、SAM、SOM を使うとは、巨大な円を描くことではありません。課題の範囲、提供条件、到達速度、供給能力を分け、投資を段階化することです。PEST と感度分析を加えると、外部変化や誤差に対して、どの前提を監視し、どこで判断を改めるかが見えます。

第14章では、市場の中で利益と交渉力がどこへ集まり、競争圧力がどう変わるかを扱います。市場規模が大きいことと、自社が価値を得られることは同じではありません。5 フォースとバリューチェーンを使い、競争と価値の構造へ進みます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の TAM、SAM、SOM の制約表、推計記録、PEST の影響経路、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• U.S. Small Business Administration ― Market research and competitive analysis ― 市場規模、需要、価格、飽和度など、市場調査で確認する基本項目を参照
• 総務省統計局 ― 政府統計の総合窓口 e-Stat ― 日本の公的統計を検索し、統計表の定義・対象・時点へ遡る入口として参照
• HM Treasury ― The Green Book ― 不確実性、感度分析、シナリオ分析を意思決定へ組み込む考え方を参照
• Francis J. Aguilar『Scanning the Business Environment』Macmillan、1967 年 ― 後に PEST などとして整理される外部環境走査の歴史的背景を確認。現在一般的な略称そのものの原典とは断定しない

第14章 競争と価値の構造を読む

第13章では、初期設定支援の対象を 20 社で試し、100 社へ案内した結果から、専用機能への投資を再計算する計画を立てました。市場の大きさと到達可能性が分かっても、その市場で自社が利益を得られるとは限りません。

顧客が年間 6 万円を払っても、その多くが販売パートナー、基盤サービス、専門人材の費用へ流れるかもしれません。魅力的な機能を作っても、顧客が容易に乗り換え、競合がすぐ模倣できれば、価格は下がります。市場が成長しても、交渉力を持つ主体が価値を得る場合があります。

5 フォースは、既存競合、新規参入、代替品、買い手、供給者から生じる競争圧力を見るフレームワークです。バリューチェーンは、価値を生む活動と、その活動に必要な費用・能力・つながりを見る方法です。

5 フォースとバリューチェーンは、業界を説明して終えるための道具ではありません。価値がどこで生まれ、誰が取り分を得て、どの活動へ投資するかを決めるために使います。

本章では、次の言葉を使います。

異なる種類の結果と負担を機械的に減算する定量式ではありません。会計利益や厳密な経済レントは第 5 部で扱います。本章では、価値を生むことと、その対価が自社へ残ることを分けるための操作的な定義として使います。税、外部性、金額にしにくい便益の完全な配分までは扱いません。

今回も架空の法人向け SaaS を扱います。企業数、価格、工数、反応は方法を説明する仮定です。

14.1 分析の前に選択を置く

「業界の 5 フォース分析をする」では、範囲が広すぎます。業界境界の置き方によって、競合も買い手も供給者も変わります。

今回の意思決定は、次の 3 案から 2027 年度の投資先を選ぶことです。

評価基準は、顧客の完了率、安全性、3 年間の粗い利益、拡張速度、依存先への交渉力、学習の蓄積です。現状維持も比較対象に残します。

分析範囲は「国内法人向け業務 SaaS のうち、他部署承認を伴う初期設定支援」とします。業界全体ではなく、今回の価値と活動が競う範囲です。基準日は 2026 年 8 月 10 日、投資期間は 3 年とします。

境界は事実として固定しません。「初期設定支援機能」「業務 SaaS 本体」「導入代行サービス」の 3 つでも分析し、選択が変わるかを確認します。機能市場では模倣、SaaS 本体では解約と製品間競争、代行市場では専門人材と販売経路の圧力が強く見える可能性があります。

選択肢と期間を定める
  ↓
各競争圧力が価格・数量・費用・投資へどう作用するか見る
  ↓
顧客価値を生む活動と、費用・能力・依存先をつなぐ
  ↓
補完者と構造変化を含むシナリオを作る
  ↓
投資する活動、避ける依存、監視条件を決める

14.2 5 フォースは利益への圧力を読む

5 フォースの成果物は、「競争が激しい」「参入障壁が高い」という評価表ではありません。それぞれの圧力が、選択肢の価格、販売量、費用、必要投資、危険へどう伝わるかを示します。

5 フォースは産業平均の収益性へ働く構造を見る枠組みであり、個社の成果を直接決めません。不利な構造でも、異なる対象、活動、費用、関係の組み合わせによって平均と異なる成果を得る企業はあります。

圧力は「強・中・弱」で終えず、根拠、変化条件、影響する選択肢へ結びます。同じ圧力でも、A、B、C への作用は異なります。

圧力同士も独立ではありません。API の標準化は供給者の切替えを容易にする一方、新規参入と模倣を増やし、買い手の選択肢を広げます。5 項目の点数を足すのではなく、変化が複数の経路を通る様子を見ます。

14.3 既存競争は企業数では決まらない

競合企業が多いから競争が激しく、少ないから穏やかとは限りません。次の条件を見る必要があります。

• 顧客から見た差が小さく、価格で比較されるか
• 固定費が大きく、空き能力を埋めるため値下げしやすいか
• 市場成長が遅く、既存顧客の奪い合いになるか
• 乗換え費用が低いか
• 撤退費用が高く、利益が低くても供給が残るか
• 競合の目的や収益源が異なるか

今回、依頼テンプレートだけなら模倣は容易です。競合 SaaS が無料機能として追加すると、単独課金は難しくなります。一方、顧客ごとの権限条件、例外経路、完了結果から学び、製品の初期設定へ組み込めれば、機能名が同じでも活動の組み合わせは異なります。

既存競争を見る目的は、競合一覧を増やすことではありません。「A の専門支援」「B の機能」「C の提携」のどこが価格競争になり、どこへ固有の能力を作れるかを選ぶことです。

14.4 新規参入障壁は自社を守る壁とは限らない

参入障壁は、新しい供給者が同じ市場へ入り、既存企業と競うために越える必要がある条件です。規模の経済、顧客の乗換え費用、流通へのアクセス、必要資本、規制、固有能力などがあります。

ただし、「自社には顧客データがあるから参入障壁だ」とは断定できません。確認するのは次です。

1. その資源が顧客価値や費用差へ実際に効くか
2. 新規参入者が購入、提携、公開情報、別経路で代替できるか
3. 参入者が既存事業から顧客接点や技術を転用できるか
4. 自社も同じ障壁によって新しい顧客へ届きにくくないか
5. 障壁が制度・技術の変化で低下しないか

管理 API の標準化は、B の開発費を下げます。しかし、その恩恵は競合にもあります。自社の参入を助けると同時に、他社の模倣も容易にします。

障壁は企業単位ではなく活動単位で見ます。画面を作る障壁は低くても、安全な権限情報を扱う運用、顧客内の承認経路へ適合する設計、導入結果を学習へ戻す仕組みは作るのに時間がかかるかもしれません。

14.5 代替品は同じ製品分類の外にある

第12章でも、競合を同業他社に限定しませんでした。5 フォースでいう代替品は、異なる方法で同じ顧客結果を満たすものです。

今回の代替には、社内 IT 部門への依頼、導入代行、販売会社への相談、表計算による継続、導入延期、製品自体の解約があります。生成 AI が権限依頼文を作ることも、一部活動の代替になり得ます。

代替圧力は、存在だけでなく次の式で考えます。

代替の魅力
= 得られる結果
- 価格
- 時間、学習、移行、調整、安全上の負担

自社機能が無料でも、顧客側の調整に 10 時間かかれば、高価な代行が選ばれる場合があります。反対に、自社支援の成果が高くても、導入自体を延期できる顧客には「何もしない」が強い代替です。

上の式は数値をそのまま足し引きする計算式ではなく、顧客が比べる便益と負担を漏らさないための概念式です。

代替圧力が強いなら、競合より多機能にするとは限りません。代替を選ぶ理由が予算なら価格・対象を見直し、組織内調整なら依頼経路を変え、安全上の不安なら収集情報と責任を明確にします。

14.6 買い手の力は顧客の大きさだけではない

大企業だから交渉力が強いとは限りません。買い手の力は、購入量の集中、選択肢の多さ、比較の容易さ、乗換え費用、内製可能性、価格への敏感さ、買い手にとっての重要度で変わります。

買い手の交渉力を下げること自体を目的にしてはいけません。顧客を囲い込み、データ移行を不必要に難しくする方法は、短期的な乗換えを減らしても、信頼、規制、安全、長期関係を損ないます。

競争圧力を弱めるための合意、排除、価格設定、データ利用は、独占禁止法、契約、公正な取引、顧客利益に反してはなりません。法的評価が必要な施策は専門家へ確認します。

目指すのは、顧客が離れられない状態ではなく、離れる自由があっても価値を選ぶ状態です。学習データを使う場合も、契約、同意、目的、安全、削除可能性を守ります。

14.7 供給者は部品会社だけではない

法人 SaaS では、クラウド、認証、決済、生成 AI、外部 API、専門人材、販売パートナー、導入支援会社が供給者になり得ます。供給者が少ない、切替えが難しい、自社の購入量が小さい、供給者が顧客へ直接進出できる場合、交渉力は強まります。

B は人手依存を下げても API 依存を高めます。C は拡張を速めても、顧客接点と学習を提携先へ渡す可能性があります。供給者の力は費用だけでなく、品質、速度、情報、将来の選択肢へ作用します。

供給者を複数化すれば常に安全になるわけではありません。統合、監査、教育の費用が障害時の損失より大きいなら、単一供給者との契約、移行手順、データ持出しを整える方がよい場合があります。

14.8 補完財は 5 つの圧力の外から価値を変える

補完財は、自社の製品と一緒に使うと顧客価値を高める製品・サービスです。5 フォースの基本枠には独立した力として入りませんが、実務では無視できません。

今回なら、ID 管理、社内ワークフロー、販売パートナー、導入支援、監査サービスが補完者です。管理 API が普及すると B の価値が上がります。導入支援会社の品質が上がると C の価値も上がります。

補完者は協力相手であると同時に、取り分を交渉する相手です。顧客接点を持つ補完者が初期設定支援を自ら提供すれば、競合や供給者へ役割が変わります。分類を固定せず、誰が顧客を持ち、誰が標準を決め、誰が切替え可能かを見ます。

14.9 バリューチェーンで活動と取り分をつなぐ

バリューチェーンを、部署一覧として作っても投資先は決まりません。顧客結果を生む一連の活動を置き、各活動の価値、費用、能力、依存、学習を見ます。活動は必ずしも直線ではありません。例外対応から対象判定や製品設計へ学習が戻る循環も含みます。

プラットフォームや多面市場では、同じ主体が買い手、供給者、補完者を兼ね、片側の価格が別側の参加を変えます。その場合も役割名を固定せず、取引ごとに誰が価値を生み、費用を負い、条件を決め、別の参加者を呼び込むかを追います。

活動ごとに「内製か外注か」を決めます。重要だからすべて内製するのでも、安いからすべて外注するのでもありません。

• 顧客価値と差へ強く効くか
• 失敗時の安全・契約責任を負えるか
• 学習を自社へ蓄積する必要があるか
• 規模によって費用がどう変わるか
• 供給者を切り替えられるか
• 他の活動との適合が必要か

例外対応を提携先へ任せても、例外の種類と結果を自社が学べなければ、製品改善が止まります。反対に、一般的なメール配信基盤を独自開発しても、顧客価値の差にならない場合があります。

価値の取り分は、顧客が払った金額から単純に活動費を引くだけでは決まりません。希少な能力、顧客接点、標準、データ、切替え可能性、契約上の権利を持つ主体が交渉力を持ちます。価値を生む活動と、取り分を得る力を分けて確認します。

14.10 二つのフレームを選択へ重ねる

5 フォースは業界・エコシステムから利益を圧迫する構造を見ます。バリューチェーンは、自社と関係者が価値を生む活動を見ます。二つを重ねると、どの活動へ投資し、どの依存を避けるかが見えます。

現状維持の費用には、未完了、解約、支援工数だけでなく、例外を学べず将来の選択肢が狭まる機会費用も含めます。

現時点の証拠状態を揃えます。

現時点では、A を小規模に続けて例外と成果を学び、B は依頼作成と状態確認の反復部分だけを段階開発し、C は自社で扱えない顧客固有調整に限定する組み合わせを候補とします。

これは「全部やる」という意味ではありません。活動ごとに境界を引き、順序を決めています。先に A で主要な未知を確かめ、反復可能な部分が分かったら B へ投資し、特殊性が高い部分だけ C を使います。

最初の 30 日は、防御力を作る投資ではなく、価値と活動を学ぶ期間です。

A を主実験とし、時間の 80% を割り当てます。B は A の中で依頼・通知を手動模擬し、C は候補 2 社への条件照会に限定します。3 つの本格実験を同時には行いません。

30 日後に事業責任者が、A の継続、B の設計着手、C の限定試行、現状維持のいずれかを決めます。追加調査だけを結論にせず、未確認事項が残る場合も投資上限と次の期限を置きます。

提携の最低条件は、サービス水準、事故責任、顧客データの利用・削除、再委託、監査、顧客への説明、契約終了時の記録移管です。満たせない場合は、速度が上がっても C を選びません。反対に、信頼、流通、専門知識を早く得られ、学習を双方へ戻せるなら、提携は単なる外注より価値があります。

依頼テンプレートが模倣されたら、機能差ではなく完了結果と例外学習が残るかを確認します。API 費用が想定の 2 倍を超え、手動経路より総費用が高ければ B の範囲を縮小します。専門人材を 60 日以内に確保できず品質が落ちるなら、A の対象を絞るか C を試します。閾値は予測ではなく、判断を先送りしないための仮置きです。

14.11 競争シナリオを AI に批評させる

AI に「この業界の 5 フォース分析をして」と頼むと、有名企業と一般的な強弱評価を埋めがちです。現在の契約条件、顧客の乗換え、供給者の仕様、競合の費用までは、入力なしに分かりません。

確認済みの資料と、未確認の仮説を分けて渡します。

意思決定:
A の人による支援、B の自社開発、C の提携へ、
2027 年度の資源をどう配分するか。

入力:
- 顧客の代替、価格、乗換え、内製に関する証拠
- 競合の公開仕様、価格、対象、更新日
- API、専門人材、提携先の契約・費用・切替条件
- 活動別の工数、品質、失敗、学習
- 事実、解釈、仮説、未確認の区分

依頼:
1. 各圧力が価格、数量、費用、投資へ至る経路を示す
2. A、B、C で影響が異なる点を比較する
3. 同じ主体が補完者、供給者、競合へ変わる条件を示す
4. 競合の模倣、供給者の値上げ、標準化の 3 シナリオを作る
5. 各シナリオで価値を生む活動と取り分を得る主体を示す
6. 出典のない固有名詞・数値を作らず、未確認と記す
7. 選択を変える追加証拠を提案する

AI が作るシナリオは予測ではありません。現在の選択が異なる条件でも成立するかを試す反証材料です。競合仕様、API 条件、価格、規制は原資料へ戻ります。

競合調査では、公開資料、正当に利用できる試用、顧客が共有を許可した情報を使います。身分の偽装、規約違反、不正アクセス、機密情報の誘導は行いません。

圧力仮説には、根拠、反対証拠、確認日、影響する選択肢、見直し条件、責任者を残します。事業責任者が四半期ごと、3 年計画は年次で見直し、API の重大変更、主要提携の終了、規制変更があれば期中でも更新します。

人間は、業界境界、許容する依存、顧客との責任、投資する能力を決めます。AI に圧力の点数を付けさせても、その点数を投資判断の根拠にしません。

14.12 フレームワークを使わなくてよい場面

5 フォースとバリューチェーンは、大きな投資、新市場への参入、価格低下、供給依存、内製・提携の選択を考えるときに役立ちます。

一方、原因が分かっている小さな不具合を直す、法令適合を専門家へ確認する、既に決めた短期試行を運用するといった場面では、大きな産業分析は不要です。顧客価値が未確認なら、第11章と第12章の検証が先です。

調査は、主要な圧力が選択肢の価格・数量・費用・投資へどう作用するかを説明でき、重要活動の内製・提携・購入について次の検証を決められたら止めます。業界の全企業、全供給者、全活動を網羅する必要はありません。

考えてみる問い

自社サービスの価値を生む活動を一つ選び、その活動を止められる、値上げできる、代替できる主体を挙げてください。その主体は価値を多く生んでいるから交渉力があるのでしょうか。それとも、切替えにくい場所を持っているからでしょうか。

5 フォースを使うとは、5 つの欄を評価することではありません。利益を圧迫する経路と、それが選択肢によってどう異なるかを読むことです。バリューチェーンを使うとは、活動を並べることではありません。顧客価値、費用、能力、依存、学習をつなぎ、どこへ投資し、何を任せるかを選ぶことです。

第15章では、第11章から本章までに見た顧客、競合、自社、市場、外部変化、競争構造を、選択肢へまとめます。SWOT を情報の一覧にせず、どの強みをどの機会へ使い、どの危険に対して何を変えるかを決めます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の圧力経路表、活動・依存表、AI による競争シナリオの手順は、以下の資料を踏まえた本書独自の整理です。

• Michael E. Porter『Competitive Strategy: Techniques for Analyzing Industries and Competitors』Free Press、1980 年 ― 5 フォースと産業構造分析の基礎を確認
• Michael E. Porter『Competitive Advantage: Creating and Sustaining Superior Performance』Free Press、1985 年 ― バリューチェーン、活動、競争優位の関係を確認
• Harvard Business Review ― The Five Competitive Forces That Shape Strategy ― 5 つの競争圧力が産業の収益性へ作用する説明を確認。閲覧環境により全文購読が必要
• Harvard Business Review ― What Is Strategy? ― 活動の違い、トレードオフ、活動間の適合を確認。閲覧環境により全文購読が必要
• Adam M. Brandenburger、Barry J. Nalebuff『Co-opetition』Currency Doubleday、1996 年 ― 補完者と、協力・競争が同時に起こる関係を確認

第15章 SWOT を意思決定につなげる

第11章から第14章まで、顧客課題、自社と代替の関係、市場の大きさ、競争圧力、価値を生む活動を見てきました。情報は増えましたが、それだけでは 2027 年度に何へ投資するかは決まりません。

SWOT は、Strengths（強み）、Weaknesses（弱み）、Opportunities（機会）、Threats（脅威）を整理する方法です。簡単に始められる一方、「ブランド力がある」「人材が足りない」「AI 市場が伸びる」「競争が激しい」といった感想の一覧になりやすい方法でもあります。

SWOT は、会社を診断する採点表ではありません。確認した内部能力と外部変化を組み合わせ、選択肢、前提、捨てる案を明確にするために使います。

今回も、他部署承認を伴う初期設定支援を題材にします。第14章で置いた選択肢は、人による支援 A、承認支援機能の自社開発 B、導入支援会社との提携 C、現状維持です。

15.1 SWOT の前に決定と証拠を置く

「自社の SWOT 分析をする」では、会社のあらゆる特徴と社会のあらゆる変化が入り込みます。最初に、誰が、いつ、何を決めるかを置きます。

2026 年 9 月末に事業責任者が、30 日試行の結果をもとに、A の継続、B の設計着手、C の限定試行、現状維持のどれへ次の 3 か月の資源を配分するか決める。

評価基準は、顧客の完了改善、安全性、支援工数、3 年間の経済性、学習の蓄積、依存先への切替可能性です。

SWOT へ入れる情報は、第11章から第14章で確認した証拠または明示した仮説に限定します。新しい事実を思いつきで追加しません。

SWOT は因果、競争優位、施策効果を証明しません。確認済み情報と仮説を一つの選択へ集約する判断を助ける簡便な手掛かり（ヒューリスティック）です。分析単位、期間、比較対象を変えれば分類も変わります。

基準日は 2026 年 8 月 10 日です。各 ID には台帳上で確認日、原資料、失効条件、更新責任者を持たせます。顧客証拠は試行終了時、製品能力は仕様変更時、API・提携条件は見積もり有効期限または契約変更時に更新します。台帳の責任者は事業責任者、各原資料の更新は担当部門が行います。

15.2 内部と外部を分ける基準

Strengths と Weaknesses は内部要因、Opportunities と Threats は外部要因です。しかし、「制御できるものが内部、できないものが外部」とだけ分けると迷います。能力は完全には制御できず、外部環境へ働きかけることもあるからです。

本章では、今回の意思決定期間に、自社が所有・配置・設計・契約によって直接変える責任を持つものを内部要因とします。顧客、競合、供給者、制度、技術標準など、自社だけでは決められない条件を外部要因とします。

提携能力は自社の内部能力ですが、提携先の価格・品質は外部条件です。契約は両者をつなぐ手段です。このような中間領域では、一語を一象限へ押し込まず、自社が変える部分と相手に依存する部分を分けます。

同じ事象が機会と脅威の両方になる場合があります。分類の重複を無理に消さず、影響経路を分けます。管理 API の標準化は開発費を下げる機会であり、新規参入を増やす脅威でもあります。

15.3 強みは褒め言葉ではなく選択に使える能力

「ブランドが強い」「顧客に近い」「技術力が高い」は、そのままでは強みではありません。今回の選択肢で、顧客結果、費用、速度、危険、学習を代替より有利に変える能力かを確認します。

強みの記述には、次を含めます。

誰に対して
どの活動で
どの結果または費用を
何と比べて変えられるか
どの証拠で言えるか

今回の S 候補は、「製品の権限要件を説明できる担当者が 2 人いる」です。しかし、20 社を支援できても 1,000 社へ拡張できるとは限りません。現在能力と拡張能力を分けます。

S1: 既存担当者は、対象製品の権限要件を確認し、20 社規模の依頼文をレビューできる。現時点で 100 社以上の例外対応能力は未実測。

強みが将来も続くとは限りません。担当者の退職、競合の模倣、技術標準の変化で失われます。強みごとに有効期間と失われる条件を置きます。

15.4 弱みは一般的な欠点ではなく選択を妨げる制約

人が少ない、予算が少ない、知名度が低いという一般論を並べても、何を変えるかは決まりません。弱みは、選択肢の実行や成果を妨げる内部制約として書きます。

W1: 承認状態を記録できないため、B を提供するには状態モデル、通知、安全確認の設計が必要で、30 日以内の本開発はできない。

弱みは、直す、避ける、借りる、受け入れるのいずれかです。すべての弱みを解消する必要はありません。

15.5 機会は追い風ではなく自社が行動できる外部条件

市場成長、制度変更、AI の普及は、それだけでは機会ではありません。自社の対象顧客と活動に影響し、期間内に行動できる条件である必要があります。

機会は、次の形で書きます。

O1: 管理 API の対応製品が増え、自社の対象顧客で利用できるなら、承認状態確認の開発・運用費を下げられる。ただし、契約条件と対応率は未確認。

機会には窓があります。競合も使える標準技術なら、早く学ぶ価値はあっても長期の独占的な強みにはなりません。発生条件、対象、期限、自社が取る行動を記します。

15.6 脅威は怖い出来事ではなく選択を変える外部条件

「競争激化」「景気後退」「規制強化」のような言葉は広すぎます。どの選択肢の、価格、数量、費用、危険、実行可能性をどう変えるかを書きます。

T1: 管理 API の価格が基準見積もりを大きく上回るか、顧客データ条件を満たせない場合、B の対象範囲を縮小し、手動経路または C と比較する。

脅威には、起きる確率だけでなく影響、検知時点、対応可能時間があります。確率を精密に置けなくても、起きたことをいつ知り、不可逆な投資の前に切り替えられるかを考えます。

15.7 4 つの欄から重複と感想を除く

SWOT の初稿を作ったら、各記述を検査します。

「顧客基盤がある」は S、「市場が拡大」は O と分類できても、両者を組み合わせた行動がなければ残す価値は低い記述です。

15.8 クロス SWOT は選択肢を増やすために使う

クロス SWOT は、S・W と O・T を組み合わせて選択肢を作ります。一般に SO、ST、WO、WT と呼ばれます。

TOWS は外部の O/T と内部の S/W の組み合わせから戦略案を作る考え方です。本章では、その組み合わせ作業をクロス SWOT と呼びます。4 類型は候補を広げる観点であり、網羅的でも相互排他的でもありません。

クロス SWOT から出た案は、正解ではなく候補です。同じ案の言い換えを束ね、現状維持、延期、撤退も加えます。組み合わせ数を増やすことより、前提の異なる案を作ることを優先します。

15.9 選択肢を評価し、捨てる案を示す

候補を、最初に置いた評価基準へ戻します。

安全性を最低条件とし、満たさない案は他の得点にかかわらず除外します。そのうえで、顧客成果 30%、3 年間の経済性 25%、実行可能性 20%、学習 15%、切替可能性 10% を暫定の重みとします。重みは客観的真理ではなく、事業責任者が何を優先したかを記録するためのものです。

顧客成果と経済性の重みを入れ替えて順位が変わるかも確認します。小さな重み変更で結論が変わる、または点差が評価誤差より小さい場合、合計点だけで決めません。最低条件、不可逆性、30 日で得られる追加証拠を比較します。

SWOT の成果物は 4 象限ではなく、この選択と理由です。強みを使わない案、弱みを直しすぎる案、機会の確認が間に合わない案は捨てます。

ここでの「見送る」は永久棄却ではありません。B 全面開発は手動模擬で成果と反復性を確認するまで、C 全面委託は品質・責任・データ条件を確認するまで再検討しません。機会を取る案には、実施費用だけでなく、同じ人と時間を A の学習へ使えなくなる機会費用も含めます。

30 日間は第14章と同じく A に 80% を配分し、B は A 内の手動模擬、C は 2 社への条件照会に限定します。9 月末に事業責任者が必ず資源配分を決め、追加調査だけを結論にしません。

決定時には、A を続ける顧客数と時間上限、B に着手する場合の費用上限と対象機能、C を試す案件数と契約条件、現状維持なら再検討日を記録します。SWOT の更新作業は意思決定会議を含め 4 時間を上限とし、選択を変えない追加項目は調べません。

15.10 AI に分類させ、人間が重要度と行動を決める

AI は、多数の記述の重複、内部・外部の候補分類、組み合わせ案、反対解釈の生成に使えます。しかし、入力にない強みや市場機会を補わせてはいけません。

意思決定:
30 日後に A 継続、B 設計、C 限定試行、現状維持から選ぶ。

入力:
- ID 付きの確認済み事実と仮説
- 各項目の出典、確認日、状態
- 選択肢、評価基準、制約、期限

依頼:
1. 内部要因と外部要因へ候補分類する
2. S/W、O/T の両方になり得る記述を示す
3. 重複、抽象語、比較対象のない評価を指摘する
4. SO、ST、WO、WT から前提の異なる案を作る
5. 各案を支持する ID と反対証拠を示す
6. 入力にない事実や数値を作らず、未確認と記す
7. 選択を変える追加証拠を提案する

AI の分類は決定ではありません。「API 標準化」を O に置くか T に置くかより、B の費用と模倣へどう作用するかが重要です。重要度、許容する危険、資源配分は責任を負う人間が決めます。

15.11 SWOT を使わなくてよい場面

SWOT は、複数の内部能力と外部変化を統合し、選択肢を比較するときに役立ちます。第11章から第14章までの調査を一つの意思決定へ集約する今回のような場面です。

一方、原因が分かっている不具合を直す、単一の契約条件を確認する、既に選んだ実験を運用する場合は不要です。顧客課題や外部環境が未調査なら、SWOT で推測を整理する前に証拠を集めます。

項目が 2、3 個しかなく選択肢が明らかなら、比較表だけで十分です。SWOT を作っても選択、捨てる案、次の検証が変わらないなら、その分析は省略できます。

考えてみる問い

最近作った SWOT から一項目を選び、「何と比べて強い／弱いのか」「どの選択肢を変えるのか」「何が分かれば分類を変えるのか」を書いてください。答えられない項目を残す理由はあるでしょうか。

SWOT を使うとは、4 つの欄を埋めることではありません。内部能力と外部条件を証拠へ戻し、組み合わせから選択肢を作り、評価基準で選び、捨てる案と次の検証を残すことです。

第5部では、選んだ案が事業として成立するかを財務から確かめます。第16章では、PL、BS、CF を別々の表として覚えるのではなく、利益、資産・負債、現金のつながりから事業を読みます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の証拠台帳、記述検査、クロス SWOT、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• Albert S. Humphrey『SWOT Analysis for Management Consulting』SRI Alumni Newsletter、2005 年 ― SWOT の実務史に関する本人の説明を参照。ただし起源には複数の説明がある
• Heinz Weihrich「The TOWS Matrix—A Tool for Situational Analysis」Long Range Planning、1982 年 ― 外部要因と内部要因を組み合わせて戦略案を作る TOWS の整理を確認
• U.S. Small Business Administration ― Market research and competitive analysis ― 競争優位、市場、顧客、競合を確認する基礎項目を参照
• Harvard Business Review ― What Is Strategy? ― 選択、トレードオフ、活動間の適合を確認。閲覧環境により全文購読が必要

第5部 事業の経済性

顧客価値があり、市場へ到達でき、競争上の選択が妥当でも、事業が必要な現金を生み、投資を続けられるとは限りません。この部では、売上、費用、資産、負債、現金、顧客単位の経済性、投資の不確実性を、意思決定へつなげます。

財務三表や指標を暗記するのではなく、数字がどの取引から生まれ、どの前提で変わり、何を隠すかを扱います。AI は資料の抽出、再計算、シナリオ比較を助けますが、会計方針の確定、法令・税務判断、投資責任は人間と専門家に残ります。

第16章 財務三表から事業を読む

第15章では、人による支援 A を主実験とし、承認支援機能 B を手動で模擬し、提携 C の条件を照会する方針を選びました。顧客成果が改善すれば、次は開発、採用、販売へ資源を配分します。

しかし、「売上が増えそう」「利益が出そう」だけでは投資を決められません。年間契約を獲得しても入金が後なら、給与を払う現金が足りなくなることがあります。開発費を支払っても、会計上はすぐ全額が費用にならない場合があります。借入で現金が増えても、利益が増えたわけではありません。

財務三表は、同じ事業活動を異なる側面から表します。

• PL（本書では Profit and Loss Statement、損益計算書）は、一定期間の収益と費用から利益を示す。制度・文脈により Income Statement、Statement of Profit or Loss などの名称も使われる
• BS（Balance Sheet、貸借対照表）は、ある時点の資産、負債、純資産を示す
• CF（Cash Flow Statement、キャッシュ・フロー計算書）は、一定期間に現金がなぜ増減したかを示す

財務三表は、別々の数字として読むものではありません。取引が利益、資産・負債、現金へどう現れ、どこに時間差と判断があるかを追うために使います。

図 16-1 は、PL、BS、CF を左から右へ別々に読むのではなく、下の「顧客単位の経済性」と行き来して見ます。売上が増えても、提供費用、売掛金、採用、開発投資で現金と能力が詰まるなら、次の投資判断は変わります。

本章の金額と企業は説明用の仮想例です。会計処理は契約、会計基準、重要性、企業の状況によって異なります。実際の決算、税務、開示判断は経理責任者、公認会計士、税理士などへ確認します。

PL、BS、CF は同じ仮想企業を題材にしますが、理解する関係だけを抜き出した教育用の数値であり、期首残高や全取引を含む完全な連動モデルではありません。

16.1 三表の前に判断を置く

今回の意思決定は、2027 年 1 月に承認支援機能へ 600 万円を投資し、支援担当者 1 人を採用するかです。意思決定者は事業責任者、財務数値の確認責任者は経理責任者とします。

確認する問いは次です。

1. 現在の事業は利益を生んでいるか
2. 利益は現金の増加につながっているか
3. 売上成長のため、売掛金や開発資産へいくら固定されるか
4. 借入返済と投資後も、給与・仕入を払えるか
5. 数字の変化は事業の改善か、会計方針や時期の違いか

三表を読む精度も判断に合わせます。小さな可逆的実験なら月次の管理数字で足りる場合があります。大規模投資、借入、買収、法定開示では、専門家が確認した財務情報と詳細な注記が必要です。

16.2 PL は期間の成果を表す

PL は、期間内に認識した収益と費用を対応させ、利益を示します。入出金の一覧ではありません。

仮想企業の 2026 年 12 月の PL を見ます。単位は万円、税金は説明を簡単にするため省略します。

売上総利益率は 70%、営業利益率は 10% です。しかし、比率だけでは良否を断定できません。開発投資の段階、価格、顧客構成、費用の分類、季節性、前年・計画との差を確認します。

PL で最初に見るのは、売上と利益の大きさより、変化の構造です。

売上の変化
= 顧客数 × 単価 × 利用・契約期間の変化

利益の変化
= 売上の変化
- 提供量とともに増える費用
- 期間に固定的な費用
- 一時的な費用

この式は分類を考える概念式です。実際には値引き、解約、複数プラン、為替、返金などが加わります。第17章で収益構造を詳しく扱います。

16.3 BS は時点の資源と請求権を表す

BS は決算日時点のストックです。左側の資産は企業が支配する経済的資源、右側の負債は外部への義務、純資産は資産から負債を引いた残余を示します。

2026 年 12 月末の仮想 BS です。単位は万円です。

基本関係は次です。

資産 = 負債 + 純資産

これは企業価値の算定式ではありません。会計上認識されない人材、組織能力、顧客関係、自社ブランドがあり、計上額と現在の市場価値も一致しない場合があります。

売掛金 500 万円は売上の一部がまだ現金になっていないことを示します。前受金・契約負債 200 万円は、現金を受け取っていても、まだ将来のサービス提供義務が残ることを示します。

BS の残高だけでなく、PL の規模との関係を見ます。売上が横ばいなのに売掛金が急増していれば、入金条件の長期化、回収遅延、期末の販売集中、計上判断を確認します。

16.4 CF は現金の増減理由を表す

CF は、現金の増減を営業活動、投資活動、財務活動へ分けます。

仮想企業の 12 月の現金増減を単純化します。

営業利益は 100 万円でも、営業 CF は 20 万円です。説明用に、非資金費用 +30 万円、売掛金増加 -80 万円、前受・未払等の純増 +20 万円、その他営業項目 -50 万円とすると、100 + 30 - 80 + 20 - 50 = 20 万円です。これは間接法による橋渡しの概念例です。さらに投資 150 万円を行い、借入 100 万円を得たため、現金は 30 万円減りました。

CF の表示には、営業収入・支出を種類別に示す直接法と、利益から非資金項目や運転資本変動等を調整する間接法があります。表示方法が違っても、元の現金取引の経済実態が変わるわけではありません。

営業 CF がプラスでも、必要な投資と返済を賄えるとは限りません。反対に、成長投資で一時的に現金が減ること自体が悪いとも限りません。投資の成果、資金余力、回収期間を合わせて見ます。

16.5 利益と現金の時間差を取引から追う

三表の関係は、個々の取引から追うと理解しやすくなります。ここでは厳密な仕訳ではなく、主な作用を示します。

年間料金を受け取った月に 120 万円すべてを売上とするとは限りません。契約内容と履行に応じて期間配分される場合、現金が先、収益が後です。掛け販売では収益が先、現金が後です。

利益と現金の差は誤りではありません。しかし、差の理由を説明できなければ、現金化までの期間、反復性、一時要因、見積もり依存、回収可能性を確認します。本章では、これらを利益の質を見る観点とします。

16.6 ストックとフローを混同しない

PL と CF は一定期間のフロー、BS はある時点のストックです。月間売上 1,000 万円と月末現金 800 万円を直接比べても意味は限定的です。

ストックの増減は、期間中のフローと再評価・振替などから生じます。

期末現金 = 期首現金 + 期間中の現金増減
期末利益剰余金 = 期首利益剰余金 + 期間利益 - 配当等

残高を見るときは、何日分・何か月分の活動に相当するかへ直します。現金 800 万円が多いかは、毎月の支払、入金の確実性、借入返済、投資予定で変わります。

16.7 三表のつながりから違和感を探す

違和感は不正や失敗の断定ではありません。追加確認が必要な変化です。

一つの説明へ飛びつかず、代替説明を置きます。売掛金増加は成長の結果かもしれず、回収悪化かもしれません。顧客・契約・月別の内訳へ戻ります。

比較するときは、期間、単位、連結範囲、会計方針、通貨を揃えます。前年同期、予算、同業、事業部を比べても、定義が違えば誤った示唆になります。

16.8 注記と会計方針まで読む

三表の数字だけでは、収益をいつ認識したか、開発支出をどう扱ったか、資産の価値をどう見積もったかが分かりません。重要な会計方針、見積もり、不確実性、関連当事者、偶発債務、後発事象などの注記を確認します。

同じ事業活動でも、判断や基準によって表示時期・区分が異なる場合があります。会計方針の変更や見積もりの変更で利益が動いたなら、事業そのものの改善と分けます。

研究開発・ソフトウェア支出も、支払ったから必ず直ちに全額費用、または必ず資産になるわけではありません。目的、利用形態、将来便益、適用基準などで扱いが異なります。本章の「設備・ソフトウェア等」は処理を決める例ではありません。

上場企業の分析では、監査済み財務諸表だけでなく、有価証券報告書、決算説明資料、適時開示を使い分けます。会社説明は経営者の見方を知る資料ですが、監査の対象範囲や指標定義を確認します。

16.9 投資前に短期の資金繰りへ戻す

三表を理解したら、600 万円を一括で支払えるかを短期資金繰りへ戻します。

期末見込は 800 + 250 - 300 = 750 万円、最低現金を引いた余力は 350 万円です。この仮定では、600 万円の一括投資は最低現金を割ります。B は 200 万円までの設計・手動検証へ分けると期末見込は 550 万円です。採用費はこの 200 万円へ含めず、試行後まで未承認とします。限定外注とも比較します。

毎週、期首現金、契約上の入金日が確定した入金、高確度だが未確定の入金、確定支払、裁量投資、期末見込を更新します。期限を過ぎた売掛金を確定入金へ含めません。

売掛金は利益があっても入金前には支払へ使えません。前受金は現金を増やしますが、将来サービスを提供する義務も増やします。どちらも「現金がある／ない」だけで安全性を判断しません。

借入返済日と最低現金を置き、基準ケースで 3 か月分の確定・高確度支払を賄えないなら、投資を段階化します。具体的な必要月数は入金の安定性、資金調達可能性、契約上の制約に応じて経理責任者が決めます。

週次見込で最低現金を割る場合、事業責任者は新規の裁量支出と採用を停止し、経理責任者と回収、支払条件、投資延期、資金調達を同日中に見直します。会計上の利益を理由に支出を続けません。

16.10 AI に抽出させ、三表の関係を再計算する

AI は、長い開示資料から表候補を抽出し、期間比較、勘定の増減、三表の関係、確認質問を作る作業に使えます。ただし、PDF の表崩れ、単位、括弧による負数、累計と四半期、連結と単体を誤ることがあります。

意思決定:
600 万円の開発と 1 人の採用後も資金を維持できるか。

入力:
- 原資料名、ページ、対象期間、連結範囲
- PL、BS、CF と注記
- 単位、通貨、負数表記

依頼:
1. 数値を原資料の表・行・列とともに抽出する
2. PL は期間、BS は時点、CF は期間を明示する
3. 利益から営業 CF への主な差を列挙する
4. 売掛金、契約負債、固定資産、借入の増減を示す
5. 事業変化と会計方針・一時要因の候補を分ける
6. 単位・期間・連結範囲が違う比較を止める
7. 不一致を推測で補わず、確認質問にする

抽出した数字は、原資料の該当セルへ戻り、表計算などで再計算します。合計、前年差、比率、現金増減、BS の貸借一致を確認します。AI の説明が会計方針を確定するものではありません。

機密の月次試算表、給与、顧客別債権を外部 AI へ入力する場合は、契約、権限、保存、学習利用、匿名化を確認します。許可がなければ入力しません。

16.11 三表を使わなくてよい場面と専門家へ渡す場面

小さな文言変更や数日のユーザー調査に、完全な三表モデルは不要です。使える時間、直接費、成功・中止条件だけで判断できる場合があります。

一方、資金調達、配当、税務、収益認識、開発費の資産計上、減損、企業結合、継続企業の前提などは、一般的な説明だけで決めません。適用基準と契約を確認し、専門家へ渡します。

考えてみる問い

利益が出ているのに現金が減った月を一つ選び、営業・投資・財務のどの活動で減ったかを分けてください。その減少は、成長のための意図した投資、回収の遅れ、費用の増加、返済のどれでしょうか。

財務三表を読むとは、PL、BS、CF の項目を覚えることではありません。同じ取引が期間利益、時点の資源・義務、現金の増減へどう表れ、その時間差と判断が事業の何を示すかを追うことです。

第17章では、PL の売上と費用をさらに分解します。顧客数、単価、利用、継続、提供費用から、1 顧客を獲得し支援する経済性と、事業全体の損益分岐点を見ます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の仮想三表、取引対応表、違和感の確認表、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• 企業会計基準委員会（ASBJ）― 会計基準 ― 日本の会計基準と適用指針を確認する入口として参照
• 金融庁 ― EDINET ― 有価証券報告書など法定開示の原資料を確認する入口として参照
• IFRS Foundation ― IAS 1 Presentation of Financial Statements ― 財務諸表一式と表示の原則を確認
• IFRS Foundation ― IAS 7 Statement of Cash Flows ― 営業・投資・財務キャッシュ・フローの区分を確認
• IFRS Foundation ― IFRS 18 Presentation and Disclosure in Financial Statements ― 2027 年 1 月 1 日以後開始年度から IAS 1 の表示・開示規定を置き換える新基準として更新対象を確認

第17章 収益構造とユニットエコノミクス

第16章では、利益と現金が一致しない理由を財務三表から読み、600 万円の一括投資を 200 万円の段階投資へ分けました。次に知りたいのは、その投資を広げるほど事業がよくなるかです。

顧客が増えるほど売上は増えます。しかし、獲得費、初期設定支援、基盤費、問い合わせ対応も増えます。平均売上が同じでも、長く継続し自力で設定できる顧客と、短期間で解約し例外対応が多い顧客では経済性が違います。

ユニットエコノミクスは、事業を顧客、契約、注文、拠点などの反復単位へ分け、1 単位を獲得・提供・維持する経済性を見る方法です。

ユニットエコノミクス（顧客や契約一単位の採算）は、LTV（顧客生涯価値）と CAC（顧客獲得費）の比率を出すためだけのものではありません。成長させる単位、直す活動、止める獲得を選ぶために使います。

本章の数値は、他部署承認を伴う初期設定支援を提供する架空の法人 SaaS の例です。税金、資本コストなどは単純化します。

17.1 指標の前に単位と意思決定を置く

今回の意思決定は、2027 年 4 月から初期設定支援を新規顧客全体へ広げるか、他部署承認が必要な顧客だけへ限定するかです。

ユニットは「1 法人契約」、観測開始は契約月、期間は 24 か月とします。1 法人に複数利用者がいても 1 契約として数えます。追加拠点や大幅なプラン変更は別の拡張売上として記録します。

最初に固定する定義は次です。

会社、会計、分析目的によって費用区分は異なります。略語だけを共有せず、分子、分母、期間、税込・税抜、配賦をデータ辞書へ残します。

17.2 月次経常収益を数量・単価・継続へ分ける

ここでは、月末時点の継続契約が翌月にもたらす月額換算額を月次経常収益（MRR）と呼びます。会計上その月に認識する売上高とは区別します。

月末 MRR
= 月初 MRR
+ 新規売上
+ 拡張売上
- 縮小売上
- 解約売上

「売上が 10% 増えた」だけでは、値上げ、新規獲得、既存顧客の拡張、解約減少のどれか分かりません。成長の源泉によって、再現性と必要投資が違います。

仮想企業の 1 か月を見ます。

売上は 5% 増えています。しかし、新規獲得を止めると 30 万円減る構造です。既存顧客だけの変化は 40 - 20 - 50 = -30 万円だからです。

17.3 費用を固定・変動の二択で決めつけない

固定費は一定範囲で提供量が変わっても総額が変わりにくい費用、変動費は提供量に応じて変わる費用です。ただし、多くの費用は完全な二択ではありません。

1 人の支援担当者が月 40 社を扱えるなら、顧客が 39 社から 40 社へ増えても人件費は変わりません。41 社で採用が必要なら費用は段階的に増えます。平均費用を直線で延長すると、能力上限を見落とします。

17.4 限界利益で追加の 1 単位を見る

本章では、限界利益を売上から数量に応じて増減する費用を引いた額として使います。

実務では「限界利益」「貢献利益」の費用範囲が組織により異なります。本章の定義を、定義確認なしに他社・他資料との比較へ持ち出しません。

限界利益 = 売上 - 変動費
限界利益率 = 限界利益 ÷ 売上

月額 6 万円、基盤・決済 1 万円、平均支援費 2 万円なら、顧客当たり月次限界利益は 3 万円です。ただし支援費 2 万円が能力上限内の配賦なのか、追加顧客で実際に増える費用なのかを区別します。

限界利益が正でも、固定費、開発投資、借入返済を賄えるとは限りません。反対に、初月だけ支援費が高くても、長期の累積粗利が十分なら獲得する価値があります。

17.5 損益分岐点は前提付きの境界

固定費が月 600 万円、顧客当たり月次限界利益が 3 万円なら、単純な損益分岐顧客数は 200 社です。

損益分岐顧客数 = 固定費 ÷ 顧客当たり限界利益
600 万円 ÷ 3 万円 = 200 社

この計算は、単価、変動費、顧客構成、能力上限が一定という前提です。支援担当者の追加採用が 200 社の前に必要なら、固定費が段階的に増え、境界も変わります。

損益分岐点を達成目標と同一視しません。現金回収、成長投資、安全余力、税・返済を含まないためです。

17.6 CAC は獲得活動と顧客群を対応させる

CAC（Customer Acquisition Cost、顧客獲得費）は、顧客を獲得するための費用を新規顧客数で割った指標です。

CAC = 対象期間の獲得費 ÷ 同じ活動から獲得した新規顧客数

営業・マーケティング費 600 万円で 30 社を獲得したなら、単純 CAC は 20 万円です。しかし、次を確認します。

• 広告だけか、営業人件費、ツール、代理店、イベントも含むか
• 当月費用と当月契約を割ってよい販売期間か
• 無料登録、商談、契約、入金のどれを獲得とするか
• 新規獲得と既存顧客の更新・拡張費を分けたか
• 自然流入と有料施策を同じ平均にしたか

法人営業では、費用を使った月と契約月に時間差があります。案件やコホートへ獲得活動を対応させ、単月の分子・分母を機械的に割りません。

例えば 1〜3 月に営業・マーケティング費 600 万円を使い、その活動から 4〜6 月に 30 社が契約したなら、この案件コホートの CAC は 20 万円です。自然流入顧客を混ぜず、案件 ID と獲得経路で対応させ、共通人件費の配賦規則も固定します。

17.7 LTV は未来の事実ではなくモデル

LTV（Customer Lifetime Value、顧客生涯価値）は、顧客関係から得る将来価値の推計です。本章では、顧客当たり累積粗利として扱います。

将来キャッシュフローを資本コストなどで割り引く定義もあります。本章の粗利モデルは、運転資本、税、資本コストを含む企業価値評価ではありません。第18章で現在価値を扱います。

データが十分なら、契約月コホートごとに実績を積み上げます。

24 か月 LTV
= 1 顧客当たり各月粗利の合計
- 契約固有の維持・解約費用

簡易式として、月次粗利を月次顧客解約率で割る方法が使われることがあります。

簡易 LTV = 顧客当たり月次粗利 ÷ 月次顧客解約率

月次粗利 3 万円、解約率 2% なら 150 万円です。しかし、この式は毎月同じ解約確率を置く幾何分布、解約率の定常性、顧客の同質性、一定粗利、十分な観測といった強い前提を置きます。拡張・縮小、契約期間、解約率の時間変化、資金の時間価値も単純化しています。

新規事業で 3 か月しかデータがないのに、2% の解約率から 50 か月の寿命を断定してはいけません。観測済み累積粗利と、その先の推計を分けます。

17.8 LTV/CAC 比率だけで投資を決めない

仮に LTV 150 万円、CAC 20 万円なら LTV/CAC は 7.5 です。大きいほど常に良いとは限りません。

• LTV が短い観測から過大推計されている
• 獲得費に営業人件費が入っていない
• 高い価格のため成長機会を逃している
• 獲得を絞りすぎ、組織能力を使えていない
• 粗利はあるが回収が遅く、現金が足りない
• 平均が顧客群の赤字を隠している

回収期間も見ます。

CAC 回収期間 = CAC ÷ 顧客当たり月次粗利
20 万円 ÷ 3 万円 = 約 6.7 か月

年間前払いか月払いかで、同じ会計上の粗利でも資金負担は違います。第16章の現金表へ戻します。

17.9 平均をセグメントとコホートへ分ける

初期設定支援を全顧客へ広げる判断のため、顧客群を比べます。

この表は各群 20 社を 12 か月追えたという仮想例です。実務では母数、観測開始、観測打切り、再契約を明示し、追跡期間に満たない顧客を単純な非継続へ数えません。

85% は 17 社、70% は 14 社に相当し、差は 3 社です。小標本から安定した差を断定せず、追加コホート、顧客構成、信頼区間、解約理由を確認します。

月次粗利は同じでも、獲得費、支援能力、継続が違います。「承認あり」は支援工数が高い一方、継続が高い仮説があります。支援が継続を生んだのか、もともと重要度の高い顧客が継続したのかは、この表だけでは分かりません。対象内で支援方法以外の条件をできるだけ揃えて段階導入し、完了、支援時間、3・6・12 か月継続を比べます。無作為化できない場合は対象選定規則と群差を残し、因果効果を断定しません。

契約月コホートで、価格、製品、獲得経路、支援方法が同じ時期の顧客を追います。古い顧客と新しい顧客を一つの平均へ混ぜると、改善前後を誤ります。

17.10 感度分析で選択を変える前提を探す

LTV は解約率の小さな変化で大きく動きます。月次粗利 3 万円の場合です。

解約率を精密に見せるより、観測期間、顧客数、信頼区間、解約理由を確認します。価格を上げると粗利は増えても獲得・継続が下がる、支援を増やすと提供費は増えても継続が上がる、といった連動をシナリオで扱います。

今回、最も選択を変えるのは、支援が 12 か月継続率をどれほど改善するかと、1 社 6 時間の支援を仕組み化できるかです。LTV の小数点ではありません。

事業責任者は 3、6、12 か月時点で判断します。3 か月では完了率、支援時間、返金・未回収、6 か月では初期継続と CAC 回収、12 か月では群別累積粗利を見ます。支援が完了を改善し、1 社 6 時間を能力上限内へ収め、12 か月累積粗利が CAC と追加支援費を上回るなら限定拡大します。満たさなければ対象縮小、支援設計変更、獲得停止を選びます。

自然流入、営業、パートナーなど経路別に CAC と回収期間を置きます。ここでの 12 か月累積粗利は売上から基盤、決済、支援を一度だけ控除した額です。追加獲得投資はその範囲内を暫定上限とし、費用を二重控除しません。返金・未回収を反映した現金回収でも確認し、全社平均で赤字経路を隠しません。支援担当者が月 40 社の上限へ達する前に、採用後の段階固定費を再計算します。

売上・粗利の定義では、無料期間は売上 0、返金は対象月の売上から控除し、未回収は会計上の売上と現金回収を分けます。貸倒れ見込みは適用基準と社内方針に従い、経理責任者が確認します。

3 か月時点で 1 社当たり支援が 6 時間を継続して超える、または月 40 社の能力上限を超える見込みなら、継続効果を待たず全体拡大を停止します。

17.11 AI にモデルを作らせ、コホートで再計算する

AI は、指標定義の候補、集計式、SQL や表計算式、感度分析、異常値の説明候補を作れます。入力にはデータ辞書と意思決定を含めます。

意思決定:
初期設定支援を全顧客へ広げるか、他部署承認ありへ限定するか。

入力:
- 契約 ID、契約月、セグメント、獲得経路
- 月次売上、値引き、返金、提供費、支援時間
- 解約・再開・拡張・縮小の定義
- 獲得費と案件の対応期間

依頼:
1. 指標の分子、分母、期間、除外を先に示す
2. 契約月 × セグメント × 獲得経路でコホートを作る
3. 観測済み累積粗利と将来推計を分ける
4. CAC に含む費用と時間差を示す
5. 簡易 LTV の前提と破綻条件を示す
6. 支援時間を含む提供能力上限を計算する
7. 集計を再現する式または SQL を出す
8. 欠損、重複、再契約を推測で補わない

AI の出力は、少数の契約を手計算し、全体集計と照合します。単位、税込・税抜、月・年、顧客・契約・利用者、平均・中央値を確認します。AI が示した「健全な比率」を普遍的な基準として採用しません。

17.12 指標を使わなくてよい場面

顧客が数社しかなく販売方法も定まらない段階では、精密な LTV/CAC より、実際の入金、支援時間、解約理由、次の契約を追う方が有効です。

単発販売、公共サービス、広告型、多面市場では「1 顧客」の単位と価値の流れが異なります。SaaS の式をそのまま当てません。

考えてみる問い

自社の CAC または LTV を一つ選び、分子、分母、期間、費用範囲、観測と推計の境界を書いてください。別の担当者が同じデータから同じ数字を再現できるでしょうか。

ユニットエコノミクスを使うとは、魅力的な比率を示すことではありません。売上と費用を反復単位へ対応させ、セグメントとコホートで違いを見つけ、成長させる単位、直す活動、止める獲得を選ぶことです。

第18章では、これらの推計を使って投資を選びます。将来の売上・解約・費用は確定していません。回収期間、現在価値、シナリオ、段階投資を使い、不確実性の中でどこまで資源を拘束するかを考えます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の定義表、コホート比較、感度分析、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• Paul W. Farris ほか『Marketing Metrics: The Manager's Guide to Measuring Marketing Performance』第 4 版、Pearson、2021 年 ― CAC、顧客価値、維持率などマーケティング指標の定義と利用上の前提を参照
• U.S. Securities and Exchange Commission ― Non-GAAP Financial Measures ― LTV/CAC の定義資料ではなく、標準化されていない指標の定義、調整、比較可能性に注意するため参照
• IFRS Foundation ― IFRS 15 Revenue from Contracts with Customers ― 契約、履行義務、収益認識を確認する公式資料として参照

第18章 投資判断と不確実性

第16章では、最低現金を守るため 600 万円の一括投資を 200 万円の段階投資へ分けました。第17章では、初期設定支援を広げる条件を、顧客群別の累積粗利、CAC 回収、支援能力から決めました。

それでも将来の売上、継続、費用は確定していません。予測値を一つに決めて投資採算を計算すると、入力の精密さが意思決定の確かさに見えてしまいます。

投資判断では、未来を一点で当てようとしません。選択肢ごとの現金、前提、不可逆性、学習価値を明示し、どこまで資源を拘束するかを決めます。

本章の金額は架空例です。税、資本構成、会計処理を単純化しています。実際の投資、借入、税務判断は財務責任者と専門家が確認します。

18.1 投資案を現状維持と段階案へ分ける

意思決定者は事業責任者、財務前提の確認者は経理責任者です。2027 年 1 月に次から選びます。

延期と見送りは同じではありません。延期には再判断日、責任者、待つことで得る情報、待つ費用があります。それらがなければ、延期は実質的な見送りです。

18.2 投資、費用、機会費用を分ける

会計上の資産・費用区分と、意思決定上の投資は一致しません。本章では、将来の成果を得るため現在の現金、人、時間、選択肢を拘束する行為を投資と呼びます。

機会費用は、その資源を次に良い別案へ使えなくなる価値です。200 万円の開発支出だけでなく、開発者が解約改善へ使えた 2 か月も比較します。

次善案を実際に失うなら、その利益差を増分 CF に含めます。ただし、人件費にも機会費用にも同じ金額を入れる二重計上を避けます。金額化できない能力不足は、別の評価条件として示します。

既に支払い、どの案を選んでも回収できない費用は埋没費用です。「ここまで 300 万円使ったから続ける」は将来判断の理由になりません。続ける案と止める案の将来差を比べます。

18.3 増分キャッシュフローで比べる

投資案では、その案を選ぶことで現状維持から増える現金流入・流出を比べます。既存事業全体の売上を投資効果として数えません。

段階開発 B のうち、3 か月後のゲートを通過して追加開発へ進む枝の基準ケースを仮置きします。追加 400 万円は自動支出ではありません。単位は万円です。

第1段階で証拠が得られなければ、-200 万円で中止します。証拠が得られたときだけ -400 万円の枝へ進みます。このように、段階案は最初から -600 万円を確定する案ではありません。

売上ではなく、追加提供費、追加支援、維持費、獲得費、運転資本を反映した増分 CF を使います。既存顧客が新プランへ移るなら、旧売上を失うカニバリゼーションも控除します。

18.4 回収期間は流動性の問いに使う

回収期間は、累積 CF が初期投資を回収するまでの期間です。

比較用に、段階開発 B の進行枝を割引前で見ます。0 か月に -200、3 か月に -400、1 年目に +240、2 年目に +360 で累積 0 となるため、時点 0 からの単純回収期間は 2 年です。

回収期間は「最低現金を守れるか」「不確実な遠い将来へ依存しすぎないか」を見るのに役立ちます。しかし、回収後の CF と資金の時間価値を無視します。短い案が必ず大きな価値を生むとは限りません。

18.5 現在価値は異なる時点の現金を比べる

将来の 100 万円は、現在の 100 万円と同じではありません。別の用途へ投資できること、将来予測に危険があること、物価などが理由です。

現在価値は、将来 CF を割引率で現在へ換算します。

PV（現在価値） = 各時点の CF ÷ (1 + 割引率)^経過年数
NPV（正味現在価値） = 各時点の PV の合計

教材上の仮定として割引率を 10% とし、段階開発 B の進行枝を計算します。これは対象企業の資本コストを推定した値ではありません。3 か月は 0.25 年として扱います。

NPV が正なら、置いた前提と割引率のもとで価値を増やす見込みです。しかし、入力が正しいことを証明しません。

割引率へ事業リスクを全部押し込むと、どの不確実性が重要か見えません。市場、解約、費用、技術、実行の前提は CF シナリオへ明示し、割引率は資本コストと時間価値を財務責任者が確認します。名目 CF には名目割引率、実質 CF には実質割引率を使い、税前・税後も揃えます。

NPV が正でも、最低現金を割る案は実行できません。また、ここで計算したのは進行枝です。第1段階で中止できる価値を含む段階案全体の期待 NPV ではありません。段階案全体の期待 NPV を計算するには、ゲート通過確率の根拠と、中止枝・進行枝それぞれの CF が必要です。

18.6 予測を一点でなくシナリオへ分ける

シナリオは、独立した数字を楽観・悲観へ動かすだけではありません。顧客行動、提供能力、競合反応が整合する状況を作ります。

次表の「3 年流入合計」は、投資支出と割引を反映する前の 1〜3 年目の増分 CF 合計です。単位は万円です。

確率を置ける反復データがない段階では、無理に期待値を作りません。各シナリオで選択が変わる境界を探します。

判断時には各シナリオの追加支出を含む NPV と最低現金を再計算します。確率の根拠がない段階では期待値の大小ではなく、低位でも耐えられるか、どの切替条件で中止するかを比べます。

18.7 感度分析と切替値で重要な前提を探す

感度分析は、一つの入力を変えたときに NPV や最低現金がどう変わるかを見ます。切替値は、選択が変わる入力値です。

追加投資の切替値は、1〜3 年目の流入の現在価値約 831 万円から初期 200 万円を引き、3 か月時点へ戻した概算です。ほかの切替値は仮想例で、継続率から粗利、支援時間から能力上限へつながる式を作って再計算します。重要なのは、経営会議で「売上予測は妥当か」と広く議論するのではなく、「継続改善が +3 pt を超える証拠があるか」と問えることです。

18.8 不可逆性と学習価値で投資順序を決める

一括開発、採用、長期契約は取り消しにくい選択です。手動模擬、短期契約、限定実装は比較的取り消しやすく、情報を得られます。

段階投資の価値は、支出を遅らせることだけではありません。200 万円で次の情報を得て、400 万円を出さない権利を残すことです。

学習価値が高い実験は、次を満たします。

• 選択を変える未知を測る
• 反対結果も観測できる
• 本投資より安く早い
• 本番との差を説明できる
• 終了後に追加・中止を選べる

そのうえで、200 万円より小さい手動模擬、既存ツール、短期外注で同じ未知を測れないかを問います。段階投資は本投資より小さいだけでなく、選択を変える証拠を買う小さな実験であるべきです。本章では中止権の価値を金額評価せず、進行枝の NPV へ上乗せしません。

延期にも費用があります。競合が先に顧客接点を持つ、顧客課題が続く、チームの学習が遅れる場合です。「情報が増えるまで待つ」を無料の選択と考えません。

18.9 段階投資のゲートを契約にする

200 万円の第 1 段階を承認するとき、追加 400 万円まで同時承認しません。

第1段階の 200 万円を承認するときに、次のゲートも契約します。中止時の撤退費用と、設計・データなど再利用できる成果物も記録します。

対象、比較基準、観測期間、欠測、重大例外、重大事故の定義は開始前に固定します。事業責任者が提案し、経理責任者が現金と前提を確認し、安全・法務の確認責任者が停止権を持ちます。ゲートに届かなければ、期限や指標を後から変えて成功扱いせず、中止、変更、新しい上限付き実験から選びます。データ不足だけを理由に追加 400 万円へ進まず、必要なら新しい仮説と上限を承認します。

18.10 AI に複数案を計算させ、式を検証する

AI は CF 表、回収期間、NPV、感度分析、シナリオ表を作れます。しかし、時点、符号、単位、税、終価、割引率を誤ることがあります。

意思決定:
600 万円一括、200 万円段階、120 万円外注、延期、見送りから選ぶ。

入力:
- 各案の時点別増分 CF
- 税・運転資本・追加維持費の扱い
- 割引率と根拠
- 最低現金と支払予定
- 顧客、継続、支援時間、API 費用の前提

依頼:
1. 年月と単位を固定し、CF の符号を表示する
2. 回収期間と NPV を案別に計算する
3. 現状維持との差だけを使う
4. 低位・基準・高位・逆風の前提を整合させる
5. NPV と最低現金の切替値を示す
6. 埋没費用を将来比較から除く
7. 段階投資の中止権を残す
8. 再計算可能な式を出す

AI の結果は表計算や短いスクリプトで再計算します。CF の時点、年・月、万円・円、名目・実質、税前・税後が揃っているか確認します。AI に割引率や確率を根拠なく決めさせません。

18.11 数字だけで決めないが、数字を曖昧にしない

安全、法令、顧客信頼、戦略上の学習は金額にしにくい場合があります。無理に金額へ変換せず、最低条件、定性的影響、責任者を別に示します。

一方、「戦略的に重要」という言葉で費用と現金を隠しません。金額化できない便益が、NPV の不足を埋めるにはどの程度必要か、切替値で示せます。

小さく可逆的な実験なら、精密な NPV を作らず、支出上限、最低現金、成功・中止条件で十分です。大規模で不可逆、長期、借入を伴うほど、詳細なモデルと専門確認が必要です。

経営会議へ出す投資メモは、少なくとも次の 4 点を 1 ページにまとめます。

• 今承認する支出上限と、まだ承認しない額
• 現状維持を含む代替案と、次善案の機会費用
• 次の判断日、予約済みの判断会議、買う証拠、その負担の小さい取得方法
• 追加、中止、変更を分ける切替値、責任者、撤退費用、再利用資産

考えてみる問い

最近の投資案について、既に使った費用を除き、これから増える CF、次善案の機会費用、選択が変わる前提、最初に買うべき情報を書いてください。

投資判断とは、最も精密な予測を採用することではありません。現状維持を含む選択肢を増分 CF で比べ、時間価値と資金制約を確認し、不可逆な支出の前に安く重要な情報を得ることです。

第6部では、分析から解決策の設計へ進みます。第19章では、最初の案を正解にせず、現状維持、撤退、段階案を含む選択肢を作り、評価基準へ戻します。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の仮想 CF、シナリオ、切替値、段階ゲート、AI 検証手順は、以下の資料を踏まえた本書独自の整理です。

• HM Treasury ― The Green Book ― 選択肢評価、感度分析、切替値、楽観バイアス、シナリオの考え方を参照
• IFRS Foundation ― IAS 7 Statement of Cash Flows ― 営業・投資・財務 CF と非現金取引の扱いを確認
• Richard A. Brealey、Stewart C. Myers、Franklin Allen、Alex Edmans『Principles of Corporate Finance』第 14 版、McGraw Hill、2025 Release ― 現在価値、NPV、資本予算、リアルオプションの基礎を参照

第6部 解決策をつくり、確かめる

分析は、正しい説明を作るためだけに行うものではありません。意思決定者が選べる解決策を作り、重要な不確実性を小さくするために行います。

この部では、問題の理解から解決策へ移ります。第19章で現状維持や撤退を含む選択肢を作り、共通の基準で比較します。第20章で選んだ価値を一文にし、第21章で大きく作る前に小さく確かめます。

AI は案を大量に出せます。しかし、似た案を言い換えて数を増やしたり、実行条件を無視したりもします。この部では、AI を発散、整理、反証に使い、何を選び、どの危険を引き受けるかは人が決めます。

第19章 選択肢をつくる

第18章では、一括投資、段階投資、外注、延期、見送りを、現金と不確実性から比べました。投資計算が精密でも、比較する案が一つしかなければ、意思決定は「承認するか、拒否するか」に狭まります。

解決策を考えるとは、最初の案を磨くことではありません。異なる仕組みで目的を達成する選択肢を作り、同じ評価基準で比較します。

19.1 最初の案を仮説として扱う

ある SaaS 企業で、「初期設定につまずく顧客が多いので、案内機能を開発したい」という相談を受けたとします。案内機能は解決策の一つですが、まだ答えではありません。

最初の案には、少なくとも次の仮説が隠れています。

• つまずきの主因は操作方法が分からないことである
• 製品内の案内を見れば顧客は完了できる
• 開発は人による支援や対象変更より効果的である
• 完了率の改善は継続や粗利の改善につながる

案を否定するのではなく、何が正しければ有効なのかを分けます。すると、同じ目的を別の仕組みで達成する余地が見えます。

19.2 解決策を機能名から作らない

「チャットボット」「ダッシュボード」「研修」のような名詞から始めると、その機能を作る議論になります。先に、誰のどの行動や状態を、どの制約下で変えるかを置きます。

対象:
契約後 14 日以内の小規模顧客

変えたい状態:
初期設定の完了率を 55% から 75% 以上へ上げる

制約:
3 か月、初期支出 200 万円以内、支援担当者の追加採用なし

この目的なら、情報を分かりやすくする、作業を減らす、代行する、対象を変える、提供時期を変える、といった異なる方向から案を作れます。

19.3 異なる仕組みの選択肢を作る

案の数だけを増やしても、同じ仕組みの言い換えなら比較になりません。まず、変化を起こす仕組みを分けます。

この段階では採点しません。早く評価すると、説明しやすい既存案だけが残るからです。一度発散し、似た案を束ねてから比較します。

選択肢づくりは、主要な原因仮説に対して異なる変化の仕組みがあり、現状維持、撤退、段階案が揃ったら一度止めます。会議には時間上限を置きます。新しい案が既存案と同じ因果経路の言い換えになるなら、数を増やす必要はありません。ここでいう異なる仕組みとは、顧客の状態が変わるまでの因果経路が異なることです。

19.4 現状維持、延期、撤退を必ず含める

新しい施策同士だけを比べると、何もしない費用と、やめる価値が見えません。

• 現状維持: 現在の提供を続ける。顧客離脱と支援負荷が残る
• 延期: 判断日を決め、選択を変える情報を待つ。学習遅延が生じる
• 撤退: 顧客通知、契約終了、データ移行、残存費用、担当者の再配置を含め、対象顧客や機能提供をやめる
• 段階案: 小さな証拠を得た後に、本投資を再判断する

現状維持は費用 0 ではありません。過去の損失ではなく、これから比較する期間に失う粗利、顧客信頼、担当者の時間を基準案の CF と能力へ反映します。撤退も失敗ではなく、目的に対して資源配分を変える選択肢です。

19.5 評価基準を案より先に決める

案を見てから評価基準を作ると、好みの案が勝つ基準を選べます。意思決定者は比較前に、目的、最低条件、評価基準、証拠を決めます。

この例では、次のように分けます。

最低条件を満たさない案は、合計点が高くても採用しません。採点で相殺できない条件を先に分けることが重要です。

基準と重みは、案を見る前に意思決定者が承認します。顧客・現場担当者は顧客負担と運用を、技術・法務・財務の確認者は各制約と証拠を確認します。評価参加者が多くても、最終決定者と停止権を持つ役割を曖昧にしません。

19.6 望ましさ、実現可能性、事業性を証拠へ戻す

望ましさ、実現可能性、事業性は便利な整理ですが、3 つの丸を埋めるだけでは判断できません。

• 望ましさ: 誰の行動や成果が変わる証拠があるか
• 実現可能性: 技術だけでなく、人、運用、法務、時間の制約を満たすか
• 事業性: 増分粗利、現金、能力、機会費用に耐えられるか

「顧客が欲しい」「技術的に可能」「売上が増える」というラベルではなく、観測事実、推定、未検証仮説を分けます。

19.7 重み付けは判断を透明にするために使う

重み付き評価は、基準ごとの点数に重要度を掛けて比較する方法です。最初に最低条件で不適格案を除き、残った選択肢だけを同じ期間、予算、対象、成果範囲で比べます。

100 点換算 = Σ（各基準の点数 × 重み）÷ 5

重みの合計は 100、点数は 5 点満点です。次の点数は説明用の仮置きで、実運用では各点数の隣に証拠を記録します。各基準の 1、3、5 点を評価前に定義します。例えば顧客成果なら、1 点は「改善を示す観測なし」、3 点は「小標本で代理指標が改善」、5 点は「対象群との比較で完了率が基準を超えた」とします。

最終行は基準ではなく計算結果です。100 点換算は表示を揃えるだけで、元の主観的な点数より精密な情報へ変わるわけではありません。

点数は事実ではありません。誰が何を重視し、どの証拠で評価したかを可視化する道具です。顧客成果と継続粗利のように同じ因果を重ねて数える基準や、点数差が同じ意味にならない尺度を安易に加算しません。安全や法令のように他の便益で相殺できないものは、最低条件にします。

証拠がなく点数を付けられない項目は、無難に 3 点とせず「未評価」または範囲で示します。順位が未評価項目や重みの小さな変更で逆転するなら、結論は頑健ではありません。ここでいう頑健とは、妥当な前提変更の範囲でも選択が変わらないことです。

合計点だけで決めず、次を確認します。

• 重みを少し変えると順位が逆転するか
• 1 点と 5 点の根拠を説明できるか
• 評価者が変わると大きく割れる基準は何か
• 最低条件違反を高得点で隠していないか

順位が重みに敏感なら、正解が出たのではなく、価値判断か証拠が未確定だと分かります。

例えば顧客成果の重みを 35 から 25 へ下げ、その 10 を経済性へ移したときに順位が変わるかを再計算します。未評価項目を最低から最高まで動かしても選択が変わらないなら、その調査は今は不要かもしれません。調査にも費用があるため、選択を変える情報を優先します。

上の例でも、代行の 85 点が自動的な採用を意味しません。顧客成果の点数が未検証なら、代行とテンプレートを少数顧客で比べ、その結果で再評価します。同時実験による顧客の混乱、提供能力、順序効果が大きい場合は、対象を分けるか順番に試します。重要な項目が未評価なら、今は選ぶ段階ではなく学ぶ段階です。

実験後は、目的と制約が変わっていなければ同じ基準で再評価します。顧客や事業の目的自体が変わったなら、点数だけを更新せず、問いと比較範囲から設計し直します。

19.8 ポートフォリオとして組み合わせる

一つの案だけを選ぶ必要がない場合もあります。ただし、良い案を全部足すと、責任と実装が複雑になります。

例えば、短期は 20 社へ手動代行して原因と支援時間を測り、中期は多い作業だけテンプレート化し、証拠が得られた部分だけ製品へ実装します。これは単なる盛り合わせではなく、学習順序を持つ段階案です。単独案と比較するときは、同じ 3 か月、200 万円以内、同じ対象顧客という境界を守ります。

組み合わせるときは、依存関係、総費用、運用能力、各段階の中止条件を再計算します。

初期比較では、すべての案に詳細見積もりを求めません。費用の桁、能力上限、致命的な依存関係を確認し、候補を絞ってから詳細化します。

19.9 AI に広げさせ、人が境界を決める

AI は、異業種の類似策、制約を反転した案、撤退や非開発案を出すのに向きます。

目的:
契約後 14 日以内の初期設定完了率を 55% から 75% へ上げる。

制約:
3 か月、200 万円以内、追加採用なし。

依頼:
1. 説明、削減、代行、標準化、対象変更、提携の仕組み別に案を出す
2. 現状維持、延期、撤退、段階案を含める
3. 同じ仕組みの言い換えを束ねる
4. 各案が有効になる仮説と、失敗する条件を書く
5. 小さな検証と、追加投資前の中止条件を書く
6. 私の最初の案を優遇しない

AI が出した案は、顧客、現場担当者、技術・法務・財務の責任者と確認します。存在しない能力、契約上できない運用、根拠のない効果を除きます。顧客情報や社内機密を入力する場合は、利用環境と契約を確認し、必要最小限へ匿名化します。

19.10 選択肢比較を意思決定記録にする

最終成果物は得点表ではなく、次の順で記入する意思決定記録です。

• 変えたい状態と期限
• 比較した選択肢と、除外した案
• 意思決定者、確認者、停止権を持つ役割
• 最低条件、評価基準、尺度、重み
• 各評価の証拠、推定、未知
• 重みを変えたときの順位変化
• 採用案、採用しない理由、反対意見、再検討を発動する条件
• 採用、実験、延期のいずれへ進むか
• 次の検証、責任者、判断日、中止条件

選ばなかった案も残します。前提が変われば、以前の次善案が最善になることがあるからです。

考えてみる問い

最近の提案を一つ選び、その機能名を使わずに目的を書いてください。次に、異なる仕組みの 3 案、現状維持、撤退、段階案を作り、案を見る前に決める最低条件と評価基準、まだ点数を付けられない項目を一つ書いてください。

選択肢を作るとは、案を大量に並べることではありません。目的と制約を固定し、異なる変化の仕組み、現状維持、撤退、段階案を比較可能にすることです。評価表は結論を自動化するためでなく、証拠不足と価値判断を見えるようにするために使います。

第20章では、選んだ解決策が誰の何をどう変えるのかを、機能の列挙ではなく価値提案の一文へ削ります。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の仮想事例、選択肢表、評価表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• HM Treasury ― The Green Book ― 現状維持を含む選択肢の作成と評価、感度・切替値の考え方を参照。本章の SaaS 事例と選択肢生成手順は本書独自の整理
• UK Government ― The Aqua Book ― 分析の品質保証、前提、不確実性、意思決定者と分析者の関係を参照。本章の評価尺度と意思決定記録は本書独自の整理

第20章 価値提案を一文にする

第19章では、初期設定の完了率を上げるため、ガイド、作業削減、代行、テンプレート、対象変更を比較しました。選択肢を決めても、「テンプレート機能を提供します」だけでは、顧客にとって何が良くなるのか、社内が何を作るのかを揃えられません。

価値提案は、魅力的な宣伝文句ではありません。誰の、どの状況を、何によって、どのように変えるかを、検証可能な一文へ圧縮した仮説です。

20.1 機能と価値を分ける

機能は、製品やサービスが備える手段です。価値は、その手段によって顧客の行動、結果、負担、危険がどう変わるかです。

「AI を搭載」「ダッシュボードで可視化」「伴走支援」は機能や提供方法です。それ自体を価値と呼ばず、誰の何が変わるかまで下ります。

20.2 対象を属性だけで決めない

「中小企業」「若者」「管理職」は広すぎます。同じ属性でも、置かれた状況、達成したいこと、代替手段、制約は異なります。

この章の例では、対象を次のように置きます。

契約後 14 日以内で、専任の導入担当者がおらず、
通常業務と並行して初期設定を行う従業員 50 人未満の顧客

対象を狭める目的は市場を小さく見せることではありません。誰に対するどの価値を検証したかを明確にすることです。証拠が得られて隣接する状況へ広げる場合も、顧客の制約と因果仮説を再検証します。

法人向けサービスでは「顧客」を一人として扱いません。

同じ人が複数の役割を担うこともあり、その場合は役割を統合して記録します。組織ごとに名称も置き換えます。誰が困るか、使うか、支払うか、成果を評価するかを分け、価値と負担が一方へ偏っていないか確認します。価値は便益だけでなく、金銭、時間、学習、不安など顧客が引き受ける負担との差で考えます。

20.3 課題を不満の言い換えにしない

「使いにくい」「効率が悪い」「DX（デジタル技術を用いた事業・業務の変革）が進まない」だけでは、何を変えるべきか分かりません。課題は、顧客が進めたい行動、妨げ、結果を分けて記述します。

顧客が口にした要望と、観察された課題も分けます。「動画が欲しい」は解決策の要望であり、動画を見れば完了するとは限りません。

20.4 変化を観測できる言葉で書く

「効率化する」「成功へ導く」「体験を向上する」は方向を示しますが、達成したか判定できません。観測可能な変化へ近づけます。

• 初期設定の完了率
• 完了までの日数
• 顧客が自力で終えた作業の割合
• 1 社当たりの支援時間
• 完了後の主要機能利用率

数値目標を必ず宣伝文句へ入れる必要はありません。しかし、社内の価値提案仮説には、何を観測するかを添えます。指標だけを改善し、顧客成果を損なわないための反対指標も置きます。例えば完了率が上がっても、誤設定、設定後の手戻り、重大な問い合わせが増えていないかを確認します。

価値は一段で生まれません。この例では、テンプレートにより判断作業が減る、14 日以内の完了が増える、主要機能の利用が始まる、顧客成果と継続が改善する、提供企業の粗利へつながる、という因果の段階があります。完了率は先行指標であり、それだけで継続や採算まで証明しません。

20.5 価値提案の一文を組み立てる

まず、社内で検証するための型を使います。

[状況にある対象] が、
[妨げ] によって [望む行動・結果] を達成できないとき、
[仕組み] によって、
[現在の代替] より [重要な変化] を得られるようにする。

この例なら次のようになります。

専任の導入担当者がいない小規模顧客が、自社に必要な設定を判断できず利用開始が遅れるとき、業種別テンプレートと短時間の確認支援によって、ヘルプ検索と個別質問を繰り返すより少ない作業で、契約後 14 日以内に初期設定を終えられるようにする。

現在の代替は、比較期間、作業時間、問い合わせ回数、顧客と提供者双方の費用で具体化します。一文は長くても構いません。最初の目的は広告ではなく、仮説の欠落を見つけることです。対象、課題、仕組み、比較対象、変化のどれかが書けなければ、調査か選択肢設計へ戻ります。

価値提案は顧客へ提供する価値の仮説です。エレベーターピッチは、その仮説と証拠、次の行動を相手に合わせて短く伝える形式です。ポジショニングは、対象市場で代替や競合と比べてどの位置を取るかを示します。3 つを同じ文章と考えません。

20.6 エレベーターピッチで判断材料を揃える

短いピッチは、聞き手を勢いで説得するためではありません。限られた時間で、次の会話へ進む価値があるかを判断してもらうために使います。

対象:
どの状況にある誰か

課題:
何を進めたいが、何に妨げられているか

提供:
どの仕組みで変えるか

価値:
現在の代替より何が良くなるか

証拠:
何を観測済みで、何が未検証か

次の行動:
相手に何を判断してほしいか

顧客向け、経営会議向け、実行チーム向けでは、最後の判断が異なります。核となる価値仮説は変えず、必要な証拠と次の行動を相手に合わせます。顧客には実際の仕事と不安の言葉を使い、社内の「完了率」「累積粗利」をそのまま押し付けません。未検証事項をすべて読み上げる必要はありませんが、まだ確認していない成果を保証として約束しません。

20.7 広すぎる価値提案を削る

次の兆候があれば、一文を広げすぎています。

• 「あらゆる」「誰でも」「すべて」を使っている
• 対象が複数の状況を含む
• 課題が 2 つ以上の因果経路を持つ
• 機能が箇条書きのように続く
• 「効率化と売上向上と満足度向上」を同時に約束する
• 比較対象がない

複数の価値がある場合も、最初に顧客が選ぶ理由を一つ置きます。副次的な価値は、証拠や別の対象向けの提案へ分けます。

20.8 強い言葉より強い証拠を使う

「圧倒的」「革新的」「劇的」と書いても、価値は強くなりません。比較対象、観測期間、対象数、反対結果を示します。

観測済み:
手動支援を受けた 20 社中 16 社が 14 日以内に完了した。

比較:
同じ選定条件の過去顧客では 20 社中 11 社だった。

未検証:
テンプレートだけで同じ結果になるか、12 か月継続が改善するか。

この情報から因果を断定はできません。しかし、何を知っていて、次に何を確かめるかは伝えられます。

この比較には、時期、顧客構成、支援を受けた顧客の選定、欠測の差が残ります。16 社と 11 社の差を手動支援の因果効果とは呼びません。また「役立つ」という発言と、購入、更新、追加料金の受容は別です。契約、継続、前払い、実際の利用など、顧客が負担を引き受ける行動も証拠として確認します。ただし、その行動も価格、契約期間、解約条件、既存の代替費用に左右されます。

20.9 AI と往復して一文を削る

AI は、対象の混在、機能語、曖昧な効果、証拠の欠落を指摘させると役立ちます。

以下の価値提案をレビューしてください。

1. 対象、状況、課題、現在の代替、仕組み、変化、証拠へ分解する
2. 書かれていない要素を推測で補わず「未記載」とする
3. 機能を価値として書いた箇所を指摘する
4. 広すぎる対象と、複数の課題を指摘する
5. 観測可能な表現へ直す。ただし根拠のない数値を作らない
6. 反証される条件を示す
7. 顧客向け、経営会議向け、実行チーム向けに短くする

AI が整った文章を作っても、顧客がその言葉を使うとは限りません。インタビュー記録、行動ログ、営業・支援記録へ戻し、意味が変わっていないか確認します。AI に顧客の発言や効果を捏造させません。

必須要素と未検証箇所が見え、次の顧客会話や実験を設計できたら、一文の推敲を一度止めます。顧客が一文を聞いて自分の状況を自分の言葉で説明できるか、具体的な質問や試用など次の行動へ進むかを観察します。反応が弱ければ表現だけを直し続けず、対象の状況、課題、現在の代替、提供する仕組みの順に仮説へ戻ります。

20.10 一文を固定せず、判断履歴を残す

価値提案はブランドの永久不変な標語ではありません。対象、課題、選択肢、証拠が変われば更新します。

初期段階では、日付、変更箇所、根拠、次の検証だけを残します。投資や利用者が増えたら、次の項目を持つ価値提案仮説シートへ広げます。

• 変更前と変更後の一文
• 変えた要素と理由
• 新しく得た証拠
• 狭めた対象と、除外した対象
• まだ未検証の因果
• 次の判断日

各要素には、観測済みの証拠、未検証仮説、確認責任者、次の検証を対応させます。製品責任者が価値提案仮説を承認し、顧客・事業・技術の確認者が証拠と制約を確認します。

本章の成果物である価値提案仮説シートには、今回の判断に応じて次の要素を置きます。

• 対象の状況、役割、現在の代替
• 妨げ、仕組み、期待する変化
• 観測済みの証拠と反対指標
• 最も重要で未検証な仮説を一つ
• 確認責任者、次の検証、判断日

文章だけを頻繁に変え、提供や検証が変わらないなら、学習ではなく言い換えです。価値提案の変更を、顧客選択、提供方法、指標、実験へ反映します。

考えてみる問い

自社のサービスを機能名なしで一文にしてください。対象の状況、妨げ、現在の代替、仕組み、観測したい変化を分け、まだ証拠がない部分へ印を付けてください。

価値提案を一文にするとは、複雑な事業を美しい言葉で隠すことではありません。対象、課題、仕組み、比較、変化、証拠を同じ仮説へ結び、欠けている部分を見えるようにすることです。

第21章では、この一文に含まれる仮説を分け、最も重要で不確実なものから、小さな実験で確かめます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の SaaS 事例、価値提案の型、エレベーターピッチ、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• Alexander Osterwalder、Yves Pigneur、Gregory Bernarda、Alan Smith『Value Proposition Design: How to Create Products and Services Customers Want』第 1 版、Wiley、2014 年 ― 顧客の仕事、痛み、利得と価値提案を対応させる考え方を参照
• Geoffrey A. Moore『Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers』第 3 版、HarperBusiness、2014 年 ― 対象市場、代替、差別化を含むポジショニング文の考え方を参照

第21章 小さく試して学ぶ

第20章では、価値提案を対象、妨げ、現在の代替、仕組み、変化、証拠へ分け、最も重要で未検証な仮説を一つ指定しました。その仮説を確かめないまま完成品を作ると、実装の進捗が学習の進捗に見えてしまいます。

小さく試すとは、小さな製品を作ることではありません。次の意思決定を変える証拠を、許容できる費用と危険で得ることです。

図 21-1 は、左から右へ「価値提案のどこが未知か」「反対なら計画が変わる仮説は何か」「どう試すか」「何を観測するか」を見ます。最後は成功報告ではなく、追加、変更、中止の判断へ戻します。

21.1 仮説を一つの文へ分ける

「業種別テンプレートは成功する」では、何を試すか決まりません。価値提案に含まれる仮説を分けます。

仮説は「誰について」「何をすれば」「何が観測される」「どの期間で」を含むようにします。複数の仮説を一つの実験へ詰め込むと、結果の理由が分かりません。

本章でいう実験は、無作為化比較だけを指しません。顧客観察、ユーザビリティ評価、手動提供、技術検証、限定リリースなど、仮説に対して証拠を得る計画的な試行の総称です。

21.2 重要度と不確実性で順番を決める

すべてを同じ深さで検証する必要はありません。反対だったときに選択が変わる重要な仮説と、証拠が弱い仮説を先にします。

安全、法令、重大な顧客損害は、発生確率が低く見えても先に確認します。重要度を売上だけで決めません。

設計の重さは、判断の投資額、不可逆性、顧客損害、法令・安全上の危険に比例させます。低額で可逆な判断なら、支出上限、少数顧客、短い観察で十分なことがあります。大きく不可逆な判断ほど、比較、専門確認、監視、記録を強くします。

21.3 MVP、プロトタイプ、PoC を目的で分ける

用語は組織によって異なります。本書では、成果物の見た目ではなく、何を学ぶかで分けます。案件開始時に、チーム内で使う定義と完了条件を合意します。

画面を作ればプロトタイプ、コードを書けば PoC という分類ではありません。顧客価値が未知なのに技術 PoC だけ成功しても、投資判断には足りません。

方法を選ぶ前に、紙、表計算、手作業、既存ツールで同じ仮説を反証できないかを問います。忠実度の高い実装が必要なのは、現実の性能、連携、運用でなければ測れない場合です。

21.4 実験を意思決定から逆算する

実験計画は方法からではなく、結果によって何を決めるかから作ります。

意思決定:
業種別テンプレートへ追加 400 万円を投資するか。

最重要仮説:
必要項目を事前選択すると、設定品質を下げず 14 日以内の完了が増える。

比較:
事前に定義した対象で、テンプレートあり／現在手順を比べる。

観測:
完了、所要日数、支援時間、誤設定、手戻り、主要機能利用。

判断:
追加、変更、中止の条件を開始前に固定する。

実験名、ツール、画面数から始めず、意思決定、仮説、観測、判定の順に設計します。

実験計画は、少なくとも次を一箇所にまとめます。

• 意思決定と最重要仮説
• 対象、比較、選定方法、観測期間
• 方法と実施内容
• 主指標、反対指標、探索指標、観測時点
• 追加・変更・中止の基準値
• 顧客への説明、危険、停止手順
• 意思決定者、実験責任者、分析者、停止権を持つ確認者
• 結果を確認する会議日

低リスクで可逆な試行なら、「3 社へ手作業で提供し、1 週間以内に自力完了できるかと重大な手戻りを観察する。担当者時間は合計 12 時間まで。苦情または誤設定で停止し、翌週の会議で継続を決める」という一段落でも構いません。

21.5 成功条件と中止条件を開始前に決める

結果を見てから基準を変えると、ほぼ何でも成功と説明できます。例として 3 か月の判定を置きます。

次の条件は構造を示す架空例です。「比較基準」「上限」は空欄のまま開始せず、案件の基準率、許容差、能力、現金から意思決定者が数値を固定します。

成功条件だけでなく、反対指標、停止権、撤退手順も決めます。良い結果でも、提供能力、担当者時間、同時実験数、現金の上限を超えるなら、拡大を保留します。データが足りないことを理由に、自動延長しません。再実験は、事前に定義した実施不備で解釈不能だった場合に限り、回数、追加予算、期限を意思決定者が再承認します。

21.6 検証したふりになる指標を避ける

ページ閲覧、登録、デモへの好意的反応は、学習の手掛かりにはなりますが、価値の証明ではありません。

ただし、強い証拠ほど高価で危険な場合があります。初期の弱い証拠で明らかに反対なら安く止め、残った仮説だけ強い証拠へ進めます。

指標は開始前に分けます。主指標は意思決定の中心、反対指標は主指標の改善と引き換えに起きる損害、探索指標は次の仮説を見つける観測です。探索指標が良かったという理由で、主指標の未達を成功へ変更しません。

21.7 比較できる観測を作る

変化を見るには、何と比べるかが必要です。無作為化比較が常に可能とは限らず、実施しても群間の干渉、割付どおり使われないこと（順守不良）、倫理、小標本の問題が残ります。誰に対する効果を知りたいのかを先に定め、少なくとも対象選定、開始時点、観測期間、欠測、併用施策を記録します。

過去顧客との比較には、時期や顧客構成の差があります。同時期の比較群にも、顧客同士への情報共有や担当者差があります。因果を断定できない場合も、どの別説明が残るかを書きます。

母数を慣習的に 20 社と決めません。意思決定を変える最小の差、現在の基準率、ばらつき、欠測、実施可能性から設計し、必要なら統計や調査の専門家が確認します。統計的に偶然とは考えにくい差と、投資や顧客にとって意味のある差は同じではありません。十分な精度を得られない小標本では、各社の経路、中央値、範囲、重大例外を示し、結論の対象を限定します。20 社中 16 社のように母数と実数も示します。

欠測した対象を単に除外せず、なぜ記録が欠けたかを確認します。離脱、利用不能、連絡断が原因なら、欠測そのものが価値や実施可能性の結果かもしれません。

実施中は、誰をどの条件へ割り付け、何を提供し、顧客が実際に何を使い、計画から何が逸脱したかを記録します。仕組みが効かなかったのか、提供されなかったのか、使われなかったのかを分けます。逸脱があっても全結果を捨てず、どの推論へ影響したかを評価し、解釈できる対象と範囲を限定します。

21.8 実験そのものの危険を管理する

「実験だから」は、品質、安全、法令、顧客説明を省く理由になりません。

• 顧客に試行範囲と既知の制約を説明する
• 同意、個人情報、機密情報の扱いを確認する
• 重大事故時の停止権と連絡先を決める
• 元の状態へ戻す方法とデータ保持を決める
• 不利益を受けやすい顧客へ偏らないか確認する
• 本番との差と、一般化できない部分を記録する

顧客を無料の実験資源として扱いません。参加に必要な時間、想定される不利益、得られる便益、失敗時の復旧や補償を事前に決めます。重大事故だけでなく、苦情、支援能力超過、現金上限を超えた場合も停止できるようにします。

不可逆な損害があり得る場合、小さな対象数だけでは安全になりません。専門確認、隔離環境、段階的な権限、監視を先に置きます。

21.9 AI で実験案を作り、解釈を反証する

AI は、同じ仮説に対する複数の実験、交絡、反対指標、代替説明を出すのに役立ちます。

意思決定、仮説、対象、制約、既存証拠を示します。

1. 最も安く反証できる方法から 3 案出す
2. 各案が直接測る仮説と、測れない仮説を分ける
3. 比較対象、選定差、欠測、併用施策を挙げる
4. 成功、変更、中止、再実験の条件案を出す
5. 顧客・提供者の危険と停止手順を挙げる
6. 結果が良い場合と悪い場合の代替説明を出す
7. 根拠のない母数、効果量、確率を作らない

AI に実験結果を要約させると、平均へ収束させ、反対事例を軽く扱うことがあります。元データ、除外、欠測、例外へ戻り、集計を再現します。顧客データは利用環境と契約を確認し、必要最小限にします。

AI の出力を実験設計や判定材料へ使う場合は、付録 E「AI 出力レビューシート」で、入力した事実、推論、根拠のない補完、機密情報の扱いを確認します。レビューシートは承認印ではなく、判断に使う前に人が見るべき論点を落とさないための確認です。

意思決定者が追加・変更・中止を選び、実験責任者が計画どおり実施し、分析者が集計と限界を確認します。安全・法務などの確認者は停止権を持ちます。小規模チームで兼任する場合も、実施者の解釈を別の人が確認します。

21.10 学びを次の選択へ変える

実験の成果物は「成功しました」という報告ではありません。次の意思決定記録です。

• 何を決めるための実験だったか
• 事前に置いた仮説と判定条件
• 実施内容と計画からの逸脱
• 観測結果、欠測、反対事例
• 残る代替説明と未検証仮説
• 追加、変更、中止、再実験の決定
• 責任者、次の期限、支出上限
• 早期判定後も監視する遅れて現れる成果・損害
• 中止後の顧客対応、データ、成果物、担当者の再配置

期待と異なる結果も、安く不可逆な投資を避けられたなら価値があります。一方、何も選択を変えない実験は、興味深い情報を得ても投資として弱い可能性があります。

考えてみる問い

第20章で作った価値提案から、反対なら計画が最も変わる未検証仮説を一つ選んでください。それを最も安く反証する方法、比較、観測、反対指標、追加・変更・中止条件を書いてください。

小さく試すとは、機能を減らした完成品を早く出すことではありません。選択を変える未知を一つ選び、目的に合う試し方を使い、結果を見る前に判定条件を固定し、学びを追加・変更・中止へ変えることです。

第7部では、この分析と検証を、相手が判断でき、組織が実行できる提案へ変えます。第22章では、結論、根拠、選択肢、危険、次の行動を、相手の意思決定順に組み立てます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の仮想実験、判定表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• GOV.UK Service Manual ― Making prototypes ― 学びたいことに応じて試作品の精度を選び、早期から反復する考え方を参照
• David J. Bland、Alexander Osterwalder『Testing Business Ideas: A Field Guide for Rapid Experimentation』第 1 版、Wiley、2019 年 ― 仮説、実験、証拠、学習の対応を参照
• Eric Ries『The Lean Startup』Crown Currency、2011 年 ― MVP と検証による学習の考え方を参照

第7部 提案と実行

良い分析や実験結果があっても、相手が何を決めればよいか分からず、実行する人が動けなければ成果にはなりません。

この部では、第22章で提案を相手の意思決定順に組み立て、第23章で立場の違いを会議の論点と合意へ変え、第24章で責任者、期限、依存関係、見直し条件を持つ実行計画へ落とします。第25章では、顧客ヒアリングへの同席、価値の言葉への翻訳、動くモック、メンバーとの直接協働を、次期体制と予算の承認へつなぎます。

AI は構成、反論候補、議事録、進捗整理を支援できます。しかし、権限、利害、信頼、責任を引き受けることはできません。誰が何を決め、実行し、影響を受けるかを人が明示します。

第22章 提案を相手の意思決定に合わせる

第21章では、業種別テンプレートの仮説を小さく試し、追加、変更、中止を選べる証拠へ変えました。分析結果を時系列に並べて説明しても、経営会議が知りたい「今、何を承認するのか」には答えられません。

提案とは、調べた内容を報告することではありません。意思決定者が選択肢、根拠、危険、次の行動を比較し、責任を持って決められる形へ編集することです。

本章では、3 つの成果物を分けます。提案は推奨と根拠を示して選択を求める行為、判断票は会議前に選択肢を比較する資料、決定記録は会議後に決定と条件を残す正式な記録です。

22.1 説明する順序と判断する順序を分ける

分析者は、依頼、調査、発見、検討、結論という順で仕事をします。意思決定者は通常、次の順で知りたいと考えます。

1. 何をいつまでに決めるのか
2. 推奨する選択は何か
3. なぜ今それを選ぶのか
4. ほかに何と比べたのか
5. 何が不確実で、失敗時にどう止めるのか
6. いくら、誰が、いつまでに実行するのか

作業日誌の順ではなく、相手が判断する順に並べます。結論を先に言うことは、根拠を隠すことではありません。相手が検証すべき主張を先に示すことです。

22.2 一つの提案で一つの意思決定を求める

「新規事業について」「AI 活用について」という題名では、会議の終了条件が分かりません。

意思決定:
2027 年 1 月から 3 か月、20 社を上限に、
業種別テンプレートの限定提供へ 200 万円まで投資するか。

決定者:
事業責任者

期限:
2026 年 12 月 15 日

相談、情報共有、意見交換、承認を同じ資料へ混ぜません。複数の決定が必要なら、依存関係と決める順番を分けます。

資料と確認の重さは、金額、不可逆性、顧客損害、法令・安全、部門横断性に比例させます。少額で可逆、低リスクの判断なら、決めること、推奨、根拠、上限、中止条件、責任者だけの短いメモで十分です。

22.3 エグゼクティブサマリーを判断票にする

エグゼクティブサマリーは本文の短縮版ではありません。それだけで意思決定の骨格を確認できる1ページです。判断票には版、作成者、情報の基準日時を付けます。

決めること、推奨、成立前提、比較、主要な未知、承認条件、次の判断は必須です。ほかは重要性に応じて詳しくします。数字には期間、単位、比較対象を付けます。「売上 20% 増」ではなく、どの顧客群の、何月から何月までの、何との比較かを書きます。

22.4 結論を主張と根拠へ分ける

「段階導入を推奨する」だけでは、好みと区別できません。結論を、検証できる主張へ分けます。

結論:
200 万円の限定提供を承認し、追加投資は留保する。

根拠 1:
課題は対象顧客で反復して観測されている。

根拠 2:
手動提供では完了と支援時間に改善の兆候がある。

根拠 3:
一括開発より、設定品質と継続の未知を小さくできる。

条件:
最低現金、安全、提供能力の上限を守る。

各根拠には、事実、推定、判断を示します。観測、比較、モデル、専門判断など証拠の種類と限界も示します。出典があることと、因果関係や一般化が強いことは同じではありません。複数の弱い根拠を大量に並べても、強い根拠にはなりません。

22.5 選択肢と推奨しない理由を示す

推奨案だけを説明すると、比較を行ったか分かりません。

採用しない理由は、案を永久に否定するものではありません。どの前提が変われば再検討するかも残します。

推奨を先に示すと、後の情報がその案を基準に見えるアンカリングが起きます。現状維持を含む選択肢と評価基準は推奨を作る前に合意し、同じ基準で評価します。重要な案件では分析に直接関与していない確認者が主張と証拠を点検し、その確認者の利害関係も開示します。

22.6 不確実性と反対意見を提案に含める

提案を強く見せるために未知を隠すと、承認後に信頼を失います。次を分けます。

• 分かっていることと出典
• 推定したことと計算方法
• まだ分からないこと
• 反対結果が出たときに変える選択
• 少数意見と、その意見が正しくなる条件

「リスクがあります」では不十分です。原因、起きる結果、兆候、予防、発生時対応、責任者を書きます。安全や法令の最低条件は、期待便益で相殺しません。

反対意見は推奨者が都合よく弱めず、可能なら意見を述べた本人が要約を確認します。誰が反対したかより、どの前提と証拠が争点で、何が起きれば再検討するかを残します。

22.7 スライドを情報の倉庫にしない

1 枚のスライドには、原則として一つの主張を置きます。題名を「市場分析」ではなく、「対象市場は大きいが、初年度は支援能力が成長上限になる」のような結論にします。

本文は、題名の主張を検証する証拠だけに絞ります。詳細な計算、出典、定義、比較分析は付録へ置き、質問時にたどれるようにします。意思決定を変えない分析は資料へ詰め込まず、保管先だけを示します。

色だけで良否を伝えず、記号と文章を併用します。図表には結論、単位、期間、出典を付け、文書の見出し順と読み上げ順を揃えます。提案者が口頭で補わなくても、判断票から付録の根拠へたどれるようにします。

ただし、1 枚 1 メッセージを機械的な規則にしません。一つの意思決定に必要な比較表を無理に分割すると、選択肢を同時に見られなくなります。視線の単位と判断の単位を揃えます。

22.8 相手に合わせても事実を変えない

経営者、財務、現場、技術、法務では関心が違います。

相手に合わせるのは、順序、詳細、用語、次の行動です。都合の悪い数字を相手別に隠したり、同じ指標の定義を変えたりしません。

22.9 AI で構成と反論を検査する

AI は、資料の構造、冗長な説明、想定反論、根拠の欠落を点検できます。

意思決定者、決めること、期限、選択肢、推奨、根拠、未知、
最低条件、次の行動を示します。

1. 判断する順にエグゼクティブサマリーを構成する
2. 各主張と、それを直接支える証拠を対応させる
3. 事実、推定、判断、未検証を分ける
4. 推奨しない選択肢への最も強い反論を作る
5. 財務、現場、技術、法務の立場から不足を指摘する
6. 根拠のない強い表現と、定義の変化を指摘する
7. 新しい数字、出典、顧客発言を作らない

AI にもっともらしい出典、数値、引用を補わせません。主張と証拠の対応は原資料へ戻って確認します。機密情報は利用環境と契約を確認し、必要最小限へ匿名化します。

22.10 提案前に意思決定可能性を確認する

資料完成後ではなく、会議前に次を確認します。

• 決定者が出席し、決定権を持っているか
• 必要な確認者が事前に内容を見たか
• 選択肢と評価基準が合意されているか
• 資金、能力、安全の最低条件が確認されたか
• 追加情報が必要なら、誰がいつまでに出すか
• 承認、条件付き承認、見送り、中止を記録できるか

条件付き承認は、条件、確認責任者、期限、条件未達時の扱いを決めます。情報不足で判断できない保留は承認と区別し、待つ情報、再判断日、無決定の費用を記録します。全体を決められなくても、支出上限付きの調査など、今決められる範囲へ問いを狭められないか確認します。

事前確認は、定義、事実、実行不能な条件を会議前に直すために行います。結論への反対や未解決の価値判断まで水面下で消し、会議を追認の場にしません。会議で決められない構造上の理由を、スライドの追加で解決しようとせず、権限、参加者、事前確認、議題を直します。

22.11 決定を正式な記録へ変える

会議後は、判断票をそのまま議事録にせず、次を決定記録へ残します。

• 決定、条件、決定日時、決定者
• 決定に必要な会議体の成立条件と最終責任者
• 採用しなかった選択肢と理由
• 反対意見と再検討条件
• 成立前提と、変化時に再提案する責任者
• 実行責任者、期限、支出上限
• 翌営業日までに始める最初の行動
• 決定時に予想した結果と観測期限
• 記録の配布先と確認期限

記録担当者が作成し、決定者が内容を確認します。会議中に判断票の数字や条件が変わった場合は、版を上書きせず差分と理由を決定記録へ残します。後の結果だけで当時の判断を評価せず、その時点の情報、選択肢、手順が妥当だったかを振り返れる状態にします。

考えてみる問い

最近の提案について、「誰が、いつまでに、何を決めるか」を一文にしてください。次に、推奨、比較した選択肢、根拠、主要な未知、最低条件、次の判断を 1 ページへ並べてください。

提案とは、分析を短く見せることではありません。相手が選択肢と代償を理解し、未知を引き受け、次の行動へ責任を持てるように編集することです。

第23章では、資料だけでは解けない立場の違いを、会議の目的、論点、決定事項へ変え、合意形成を進めます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の SaaS 事例、エグゼクティブサマリー表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• Barbara Minto『The Pyramid Principle』第 3 版、FT Publishing International、2026 年 ― 結論と根拠を階層化し、読み手の問いへ答える構成を参照
• U.S. Securities and Exchange Commission ― A Plain English Handbook ― 読み手を基準に、明確で簡潔な文書を設計する考え方を参照

第23章 合意形成とファシリテーション

第22章では、提案、判断票、決定記録を分け、意思決定者が選択肢と代償を比べられる形へ編集しました。しかし、資料が正しくても、営業、支援、開発、財務、法務では見ている成果と引き受ける負担が異なります。

合意形成とは、全員を同じ意見にすることではありません。誰が何を決めるかを明確にし、立場の違いを検証可能な論点へ変え、反対意見と条件を残したまま実行できる状態を作ります。

ファシリテーションとは、参加者が必要な情報と異なる意見を出し、会議の目的に沿って判断や次の行動へ進めるよう、話し合いを設計・進行することです。単に場を盛り上げたり、全員を賛成させたりすることではありません。

23.1 正しい答えだけでは人が動かない

同じ段階案でも、役割によって見え方は変わります。

反対は無理解や抵抗とは限りません。その人だけが知る実行上の制約、評価制度、顧客との約束、損失の偏りが含まれることがあります。

心理的安全性は、全員が快適で同意する状態ではありません。対人関係上の不利益を恐れず、質問、懸念、失敗、異論を共有できる状態です。個人の性格ではなく、チーム内で共有された認知として扱います。匿名窓口が存在するだけで保証されず、日常の応答、報復の有無、リーダーの行動を見ます。成果基準や説明責任を下げることとも異なります。

23.2 関係者を肩書だけで分類しない

会議前に、少なくとも次の役割を確認します。

• 意思決定者: 最終的に選択し、結果への責任を持つ
• 実行責任者: 決定後の仕事と資源を引き受ける
• 確認者: 財務、技術、法務、安全などの条件を確認する
• 影響を受ける人: 顧客、現場担当者、提携先など
• 停止権を持つ人: 最低条件違反で実行を止められる
• 進行役: 発言、論点、時間、決定手順を管理する
• 記録者: 決定、条件、未決事項を残す

一人が複数役を担う場合もあります。役職が高い人の発言だけでなく、実行知識と影響の大きさから参加者を選びます。

影響を受ける人が全員参加できるとは限りません。顧客や欠席者の意見は、事前インタビュー、代理人、文書コメントで集め、要約を本人が確認できるようにします。会議後に決定が意見を正しく扱ったかを返します。

23.3 会議の目的を開始前に固定する

会議には異なる目的があります。

一つの会議ですべてを行うと、情報共有に時間を使い、最後の数分で決定を迫ります。今回の会議がどこまで進む場かを招集時に明示します。

会議を開くこと自体を前提にしません。権限、基準、影響範囲が明確な少額・可逆の判断は、期限付きの非同期コメントと決定記録で済ませられます。回答期限を明示し、沈黙を同意と扱いません。会議の参加人数、時間、事前作業は、判断の不可逆性、影響、対立の大きさに比例させます。

23.4 立場の対立を論点へ変える

「営業は賛成、開発は反対」という表現では、解決できません。主張の背後にある関心、前提、証拠、条件を聞きます。

立場:
対象顧客を絞るべきではない。

関心:
既に提案中の顧客との約束を守りたい。

前提:
対象外にすると商談が失注する。

確認する論点:
提案中顧客の何社が対象外になり、代替提供で維持できるか。

合意条件:
既存商談には期限付きの代行を用意する。

人と意見を分け、反対者を説得対象に固定しません。前提が正しいなら案を変える用意を持ちます。

23.5 事実、解釈、価値判断を分ける

対立の原因が、データ不足とは限りません。

• 事実の違い: 顧客数、費用、事故件数など。出典と定義を確認する
• 解釈の違い: 同じ事実から異なる因果や予測を置く。追加証拠やシナリオで比べる
• 価値判断の違い: 成長、現金、安全、公平の優先が異なる。決定者が代償を選ぶ
• 利害の違い: 負担と便益の配分が異なる。役割、資源、補償を設計する

価値判断をデータの追加だけで解決しようとしません。逆に、確認できる事実を「価値観の違い」で曖昧にしません。

23.6 発言しにくい情報を先に集める

会議では、肩書、専門性、発言速度、過去の関係によって情報が偏ります。

• 会議前に個別または匿名で懸念を集める
• 最初に各自が一人で論点を書く
• 役職順ではなく、実行に近い人から確認する
• 発言者ではなく主張と証拠を記録する
• 進行役が最後に意見を述べる
• 少数意見を決定記録へ残す

匿名化は率直さを助けますが、責任ある対話を置き換えません。報復や不利益の危険がある場合は、相談経路と保護を先に整えます。通報者や相談者を特定できる情報は、会議資料へ必要最小限しか載せません。

発言順の工夫だけでは、雇用評価、契約打切り、専門資格、ハラスメントなどの構造的な権力差を解消できません。上司や契約相手を通さない相談窓口、匿名経路、利益相反の開示、報復を防ぐ手順を組織として用意します。

反対を表明した人へ、代替案作成や追加調査を自動的に押し付けません。追加作業は重要性と役割に基づいて割り当てます。

23.7 内容上の立場と進行役を分ける

進行役は、すべての内容に意見を持たない人である必要はありません。しかし、自分の提案を通す役と、発言・論点・手順を管理する役を同時に担うと偏りが生じます。

重要な会議では役割を分けます。分けられない場合は、進行役の立場を開示し、発言順、評価基準、決定方法を事前に固定します。

進行役が管理するのは、次です。

• 会議の目的と終了条件
• 発言機会と時間
• 論点、決定済み、未決の区別
• 根拠のない断定と人格攻撃の停止
• 決定権と決定方法
• 駐車場へ置く別論点と回収期限

未決論点には、論点責任者、必要な情報、期限、再び扱う会議または決定手順を付けます。駐車場を先送りの一覧にしません。

23.8 合意と全員一致を分ける

合意には段階があります。

全員一致を待つと、責任者が決めない状態になることがあります。決定者は反対意見を理解し、条件と代償を記録したうえで決めます。反対者に、賛成したふりを求めません。

ここで合意状態は各人の立場、決定は権限を持つ人や会議体の選択、コミットメントは決定後に引き受ける行動です。受容を沈黙や諦めと取り違えないため、参加者が決定、条件、自分の役割、残る反対を自分の言葉で確認します。受容した人が実行へ協力する範囲と、支持していない判断を分けます。

23.9 決定方法を議論前に決める

投票、多数決、合意、責任者決定には用途があります。

• 発想の選好投票は候補を絞る参考に使う
• 安全や法令を多数決で上書きしない
• 専門判断は資格と責任を持つ確認者が行う
• 資源配分は権限を持つ意思決定者が決める
• 会社や契約で定めた会議体の成立条件を守る

議論の結果を見てから決定方法を変えません。誰が決めるか不明なら、内容の議論へ入る前に解消します。

本章では、安全・法務などの最低条件違反で止める権限を「停止権」と呼びます。一般的な意見対立を止める拒否権とは区別します。

23.10 会議設計を一枚にする

会議または非同期判断を始める前に、次を一枚へまとめます。

• 目的、終了条件、決めないこと
• 版、作成者、情報の基準日時、資料配布期限
• 意思決定者、成立条件、参加者、欠席者の代替参加
• 事前資料、既知の論点、評価基準
• 決定方法、停止権を持つ確認者
• 議題ごとの時間、進行役、記録者
• 未決論点の責任者と回収方法
• 決定記録の配布先、異議申立て経路、結果確認日

反復会議では毎回ゼロから作らず、前回の設計から変わった目的、論点、参加者、基準だけを更新します。資料が期限までに届かず準備できない場合は、判断範囲を狭めるか、会議を情報確認へ変更します。

時間切れなら未検討の論点を無視して承認せず、その場で決められた範囲と残る論点を分け、責任者と再判断日を置きます。

新事実、最低条件違反、記録の重大な誤りが判明した場合は、決定記録に定めた責任者または独立相談窓口へ再提起します。受領確認と初回回答期限を定め、単なる不満と決定を再開する条件を分けます。

23.11 AI を事前整理と記録に使う

AI は、関係者別の論点候補、議題、反論、議事録の整理に使えます。

会議の目的、決定者、参加者、選択肢、評価基準、既知の懸念を示します。

1. 役割別の期待、負担、懸念を仮説として列挙する
2. 立場を、関心、前提、証拠、合意条件へ分ける
3. 事実、解釈、価値判断、利害の論点を分ける
4. 発言しにくい人から見た不足を挙げる
5. 会議後は決定、条件、反対意見、未決、責任者、期限を整理する
6. 発言していない内容、合意、感情を推測で作らない

AI は関係性を調整できません。誰に先に話すか、どの懸念を公開してよいか、沈黙が同意か恐れかは人が判断します。録音、文字起こし、個人情報、機密情報は参加者への説明と利用環境を確認します。

23.12 会議を決定記録と次の行動で閉じる

終了前に、記録者が読み上げます。

• 決まったことと決まっていないこと
• 条件付き承認の条件と確認者
• 反対意見と再検討条件
• 実行責任者、最初の行動、期限
• 次に結果を確認する日

参加者はその場で誤りを訂正します。会議後は第22章の決定記録として配布し、決定者が確認します。合意の雰囲気ではなく、誰が何をするかで閉じます。

受容した人が協力できない資源制約を後から発見した場合、態度や忠誠心の問題にせず、責任、範囲、期限、資源を再調整します。

結果確認時には、少数意見が正しくなるとされた条件が実際に起きたかを振り返ります。反対者の勝敗や人事評価に使わず、当時見落とした情報と次の意思決定手順を改善するためです。

考えてみる問い

最近の対立を一つ選び、会議を開く必要があるかを判断してください。必要なら、各人の立場を、関心、前提、証拠、合意条件へ分けます。次に、それが事実、解釈、価値判断、利害のどの違いかを分類し、誰がどの方法で決めるかを書いてください。

合意形成とは反対を消すことではありません。異なる立場から実行上の情報を取り出し、事実、解釈、価値判断、利害を分け、決定権と停止権を明確にして、反対意見を残したまま次の行動を可能にすることです。

第24章では、決定した提案を、優先順位、責任者、期限、依存関係、指標、見直し条件を持つ実行計画へ変えます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の SaaS 事例、会議目的表、合意状態表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• Roger Fisher、William Ury、Bruce Patton『Getting to Yes』改訂版、Penguin Books、2011 年 ― 立場と利害を分け、人と問題を分離する交渉の考え方を参照
• Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, Vol. 44, No. 2, pp. 350–383, 1999 ― 対人リスクを取れるというチームの共有認知と学習行動の関係を参照

第24章 実行可能な計画へ落とす

第23章では、立場の違いを論点へ変え、決定権、停止権、反対意見を残したまま合意を実行可能な状態へしました。しかし、「段階案を進める」と決まっただけでは、誰が何を終えれば成果へ近づくかは決まりません。

実行計画は、作業と日付の一覧ではありません。望む成果から必要な変化を逆算し、責任、依存関係、資源、指標、見直し条件を結んだ意思決定の連鎖として作ります。

図 24-1 は、左から右へ「成果」「必要な変化」「作業と責任」「依存関係」を見ます。下段の指標と見直し条件は、計画どおり進んでいるかだけでなく、前提が崩れたときに何を再選択するかを示します。

24.1 提案と実行の断絶を見つける

提案が実行へ移らない典型的な理由があります。

• 「推進する」「強化する」で行動が終わっている
• 成果ではなく成果物の完成を目標にしている
• 複数部署が担当で、最終責任者がいない
• 依存先の承認やデータを予定へ入れていない
• 日程はあるが、担当者の能力上限を見ていない
• 問題が起きても計画を変える条件がない
• 承認後の最初の行動が決まっていない

計画書の詳細を増やす前に、決定記録の条件と実行上の制約が接続しているかを確認します。

承認時の成果範囲、費用上限、固定期限・目標日、能力上限を計画の基準線として保存します。日々の予測更新は基準線を上書きしません。成果範囲、最低条件、費用上限、固定期限を変える場合は、決定記録で定めた意思決定者が再承認します。

24.2 成果から必要な変化を逆算する

「テンプレートをリリースする」は成果物です。この案件で望む成果は、設定品質を守りながら、対象顧客が 14 日以内に初期設定を終えられることです。

最終成果:
対象顧客が設定品質を保ち、14 日以内に初期設定を終える。

必要な行動:
顧客が自社に合う型を選び、確認し、設定を完了する。

必要な提供:
業種別テンプレート、短い確認支援、誤設定の検知。

必要な能力:
型の更新、支援、監視、停止、問い合わせ対応。

成果、行動、提供、能力の因果を置くと、「機能は完成したが使われない」を途中で検知できます。

24.3 作業を完了条件まで分ける

「テンプレートを作る」だけでは、完了を判定できません。

完了条件は「担当者が終わったと思う」ではなく、次の作業や判断を安全に始められる状態です。

24.4 責任者と協力者を分ける

一つの作業に複数の関係者がいても、結果を説明する最終責任者は明確にします。

この役割表は、本書独自の簡易な整理です。RACI（実行・最終責任・相談・共有の役割整理）など特定の略語を埋めることが目的ではありません。責任の空白、二重承認、過度な通知、停止権の欠落を見つけるために使います。

24.5 依存関係と待ち時間を計画へ入れる

作業時間だけでなく、承認、調達、顧客募集、データ取得、法務確認などの待ち時間が日程を決めます。

依存関係には所有者、必要日、現在状態、代替を付けます。「相手待ち」を担当者不在の状態にしません。

24.6 優先順位を同時進行数へ変える

すべてを優先すると、着手だけ増えて完了が遅れます。優先順位は、次に何を始めるかだけでなく、今は何を始めないかを決めます。

次の観点で順番を決めます。

• 最低条件と重大な危険を先に解消する
• 後続の多くを止める依存関係を先に解く
• 選択を変える重要な未知を先に測る
• 能力上限を超えない同時進行数にする
• 中止された作業から人を解放する

個人やチームごとに同時進行上限を置き、緊急追加時には何を止めるかを同時に決めます。

計画上の稼働を 100% まで埋めません。問い合わせ、障害、レビュー、学習に必要な余力を明示し、緊急対応を隠れた残業で吸収しないようにします。

24.7 期限を約束と予測に分ける

期限には性質の違いがあります。

• 固定期限: 法令、契約、顧客イベントなど動かせない日
• 目標日: 現在の前提で目指す日
• 予測日: 実績と残作業から更新する見込み日
• 判断日: 継続、変更、中止を決める日

すべてを固定期限として扱うと、遅れを隠し、品質や安全を削ります。固定理由と、動かせる範囲を明示します。予測日は一点だけでなく、「前提が維持されれば 2 月 10〜17 日」のように範囲で示します。範囲は恣意的（しいてき。明確な根拠なしに都合よく決めること）に広げず、残作業、実績、依存関係、能力、置いた前提を添えます。範囲や中心が変わったときは、基準線との差と理由を残します。

大きな作業は、完了日だけでなく、途中で未知が分かる確認点を置きます。遅延を最終日に初めて発見しません。

24.8 先行指標と遅行指標を結ぶ

遅行指標は最終成果を示しますが、変化を知るのが遅れます。先行指標は途中の行動や状態を示します。

活動量だけを成果と呼びません。先行指標と成果の因果が崩れたら、指標か計画を見直します。

指標ごとに定義、対象、母数、期間、データ源、欠測の扱いを固定します。提供数や完了率が目標になることで、対象選定や完了定義を都合よく変えないよう、反対指標と個別事例を確認します。定義を変える場合は、変更日、理由、旧定義と新定義、過去値を再計算したかを記録し、比較不能な系列を接続しません。平均が改善しても、特定の顧客群や現場担当者へ負担が偏っていないか分布を見ます。

顧客成果や採算が良くても、従業員の健康、安全、法令、顧客の権利など金額化しにくい最低条件を維持します。

24.9 危険への対応表を行動へ変える

危険を赤黄緑で並べるだけでは実行できません。

兆候は、危険が発生する前に行動できる観測です。責任者は報告するだけでなく、予防と発生時対応を開始する権限を持ちます。

24.10 見直し条件を開始時に決める

計画は守る対象ではなく、成果へ近づくための仮説です。次の場合に見直します。

• 成立前提が変わった
• 最低条件または支出上限へ近づいた
• 重要な依存関係が期限までに解消しない
• 主指標と反対指標が判定境界を超えた
• 能力上限に達した
• 新しい選択肢や重大な証拠が得られた

見直しは、遅れを責める会議ではありません。継続、範囲変更、順序変更、資源追加、保留、中止を再選択する場です。

先行指標が改善しても遅行指標が変わらない場合は、作業量を増やす前に、両者を結んだ因果仮説を見直します。

現場の権限で解消できない資源不足、部門間の優先順位対立、最低条件違反、基準線変更は、決定記録に定めた意思決定者へ期限付きで上げます。エスカレーションには、事実、影響、既に試した対応、必要な決定を添えます。

24.11 AI で進捗を整理し、兆候を検査する

AI は、決定記録から作業候補、依存関係、危険、週次要約を作れます。

決定、成立前提、条件、成果、期限、責任者、資源上限を示します。

1. 成果、行動、提供、能力へ分ける
2. 作業ごとに完了条件、最終責任者、確認者を示す
3. 依存関係、待ち時間、代替を示す
4. 同時進行上限を超える箇所を指摘する
5. 活動、先行、遅行、反対、能力指標を分ける
6. 危険の兆候、予防、発生時対応を対応させる
7. 計画からの逸脱と見直し条件を整理する
8. 根拠のない期限、進捗率、担当者を作らない

AI の要約は、更新されていないタスクを正常に見せたり、現場の疲労や顧客の不安を落としたりします。責任者が原記録と現場を確認し、非構造的な兆候を補います。個人の監視や自動評価へ使う場合は、目的、権限、説明、公平性を確認します。

24.12 実行計画を一枚にする

実行計画は、判断と実行が切れないように、次の要素を一箇所で追跡できるようにします。一枚は意思決定に必要な概要であり、詳細作業、計算、証拠はリンク先で管理します。

• 版、作成者、基準日時、承認済み基準線
• 最終成果、必要な行動・提供・能力
• 作業、完了条件、状態、最終責任者、確認者
• 依存関係、受渡条件、必要日、代替
• 固定期限、目標日、予測範囲、判断日
• 先行・遅行・反対・能力指標
• 危険、兆候、予防、発生時対応、停止権
• 見直し条件、エスカレーション先、次の判断日

状態は、未着手、進行中、待ち、阻害、完了など、完了条件に基づいて示します。根拠のない「80% 完了」は使いません。阻害には解消責任者、期限、現場で解消できなければ上げる条件を付けます。

少額・短期・可逆な実行なら、「望む成果、最初の 3 作業と完了条件、責任者、時間・費用上限、中止条件、次の判断日」だけを書いて始めます。費用、期間、関係者、依存関係、損害の可能性が増えたとき、または最低条件や部門横断の調整が必要になったときに確認を厚くします。

24.13 計画を実行記録として更新する

週次または判断点で、次を更新します。

• 完了した成果と未完了の完了条件
• 成立前提と依存関係の変化
• 指標、反対事例、顧客・現場の兆候
• 能力、現金、同時進行上限
• 決定した変更、中止、追加
• 責任者、期限、次の判断日

更新頻度は危険と変化速度に合わせ、変化のない項目を機械的に書き直しません。計画の初版と基準線を保存します。基準線変更には、変更前後、理由、成果・費用・期限・能力への影響、承認者、承認日を残します。予定どおりだったかだけでなく、何を学び、なぜ選択を変えたかを追跡します。

緊急時に同時進行上限を一時的に超える場合は、例外の理由、対象、終了日、通常状態へ戻す責任者を決めます。

中止した作業は、関係者への通知、アクセス停止、契約、データ保持・削除、残作業、成果物の保管、担当者の再配置まで閉じます。状態だけを「中止」に変えて仕事を残しません。再利用できる成果物と判断の学びは、第8部の案件記録へ渡します。

考えてみる問い

最近決まった提案を一つ選び、承認済みの成果・費用・期限・能力を基準線として書いてください。次に、最終成果、必要な行動、提供、能力へ分け、最初の 3 作業について完了条件、責任者、依存関係、先行指標、反対指標、見直し条件、再承認が必要な変更を書いてください。

実行可能な計画とは、作業を細かく並べることではありません。成果への因果、責任、依存関係、資源上限、指標、危険、見直し条件を結び、状況が変われば理由を残して再選択できる状態を作ることです。

第8部では、実行の成功と失敗を案件の中だけで終わらせず、背景、仮説、判断、行動、結果として記録し、次の案件で使える知見へ変えます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の SaaS 事例、役割表、指標表、危険表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• Project Management Institute ― A Guide to the Project Management Body of Knowledge (PMBOK Guide), 第 8 版、2025 年 ― 価値、ガバナンス、スコープ、スケジュール、資源、不確実性の考え方を参照
• UK Infrastructure and Projects Authority ― Project Routemap: Setting up projects for success ― 複雑な大型プロジェクト開始時の能力、ガバナンス、実行環境を確認する考え方を参照

第25章 現場に入り、次期体制と予算をつくる

ここまでの章では、顧客を理解し、価値仮説を小さく試し、提案を実行計画へ変える方法を扱いました。しかし、部門横断の新規事業やサービス改善では、資料を渡すだけでは前へ進みません。顧客ヒアリングへ同席し、設計をレビューし、顧客に届く言葉へ翻訳し、動くものを一緒に作りながら、次期の体制と予算を承認可能な形にする必要があります。

この仕事の成果は、本人が活躍し続けることではありません。顧客、現場、意思決定者の間に学習の循環を作り、次の期間を組織自身で進められる状態へ移すことです。

25.1 五つの依頼を一つの仕事として設計する

五つの依頼は、別々の作業ではなく一つの因果でつながります。

ヒアリング件数や画面数だけを進捗にしません。各活動が、次の意思決定に必要な証拠を増やしたかで確認します。

25.2 最初の二週間で現場の地図を作る

着任直後から解決策を提示する前に、依頼者、意思決定者、実行者、顧客接点、予算管理者を確認します。肩書だけでなく、実際に情報が集まる人、拒否権を持つ人、作業が集中している人を見ます。

最初の二週間で、少なくとも次を一枚にします。

• 下半期に決めるべきことと承認日
• 現在の顧客仮説、事業仮説、技術仮説
• 進行中の案件、会議、成果物、既決事項
• 意思決定者、予算所有者、実行責任者、専門確認者
• 顧客へ接触できる経路と同意・情報管理の条件
• チームの能力、予定稼働、兼務、ボトルネック
• 予算編成、採用、外注、契約に必要なリードタイム

聞き取りだけで作らず、既存資料、会議観察、実際の作業を突き合わせます。認識が食い違う箇所は、誰かの誤りと決めず、確認すべき論点として残します。

25.3 顧客ヒアリングでは三つの役割を合意する

同席前に、主質問者、深掘り・時間管理、記録者を決めます。同席者が途中で競うように質問すると、話の流れが切れ、顧客の回答も誰に合わせるかで変わります。

事前の 15 分で次を確認します。

1. この面談の後に変え得る意思決定
2. 現在の仮説と、反対なら計画が変わる点
3. 必ず聞く最近の具体的な経験
4. 見せるものと、反応を誘導しない見せ方
5. 主質問者、追質問者、記録者、終了時刻
6. 録音、機密、個人情報、利用目的の説明

面談中は、「欲しいですか」より、直近にいつ、何をし、どこで止まり、誰に頼り、何を失ったかを聞きます。解決案を見せた後は、好意的な感想ではなく、理解できない箇所、使わない理由、現在の代替、導入権限を確認します。

終了直後の 15 分で、記録を次の四列へ分けます。

設計レビューでは、質問の美しさではなく、意思決定との対応、対象者の偏り、誘導、倫理、記録方法、終了条件を確認します。詳細は第10章と付録 D を使います。

25.4 顧客の言葉を価値のストーリーへ翻訳する

翻訳とは、顧客の発言を広告らしい言葉に言い換えることではありません。顧客が経験する順番を保ちながら、社内の機能、技術、計画を意味のある変化へ結び直すことです。

次の順で一つのストーリーを作ります。

対象と場面:
誰が、どの状況で困るのか。

現在のやり方:
今は何でしのぎ、どんな負担や危険があるか。

転換点:
なぜ今のままではいけないのか。

提供する仕組み:
何をすることで、行動がどう変わるか。

得られる変化:
時間、品質、安心、売上など何が観測可能になるか。

証拠と限界:
何を確認済みで、何がまだ仮説か。

次の一歩:
相手に何を試し、判断してほしいか。

同じ事実でも、利用者には仕事の変化、現場責任者には運用と危険、経営には投資理由と撤退条件を示します。ただし、相手に合わせて確認状態や不確実性を変えてはいけません。第20章の価値提案と第22章の意思決定順を組み合わせます。

レビューでは、顧客が実際に使った言葉との対応、機能から始まっていないか、効果を言い過ぎていないか、反対理由へ答えているかを確認します。

25.5 動くモックを学習装置として作る

最初に、モックを見た後に何を決めるかを一文にします。画面一覧や技術選定から始めません。

実装の忠実度は仮説に合わせます。

作業は、当日動く縦の一経路を先に作ります。サンプルデータ、失敗時表示、リセット方法、説明文を含め、デモ担当者しか操作できない状態を避けます。AI で生成したコードや画面も、機密、権利、安全、障害や利用環境にかかわらず使えるアクセシビリティ、誤操作を人が確認します。

毎回のレビューは「見た目の好み」「仮説を測れるか」「本番化に必要な品質」を分けます。モック段階で本番品質を要求せず、本番化するならモックの近道や手動部分を明示して作り直します。

25.6 関係構築は一緒に仕事を終えることで行う

関係構築を、会食や定例 1on1 の回数に置き換えません。信頼は、約束した小さな仕事を一緒に終え、判断理由を開示し、現場の貢献を成果へ反映することで育ちます。

メンバーごとに、次を確認します。

• 担っている仕事と、公式の役割との差
• 成功と評価の基準
• 顧客について知っていること
• 止まっている判断と依存先
• 得意なこと、学びたいこと、避けたい負荷
• 自分に期待する支援と、越えてほしくない境界

助言だけで終わらず、ヒアリング準備、モック作成、レビュー、予算計算のいずれかを共同作業にします。成果物には共同作成者と判断者を記録し、外部支援者が手柄を回収しません。

一方、個人的な信頼で正式な承認や異議申立てを代替しません。1on1 で得た機微情報を本人の同意なく共有せず、課題を共有するときは個人評価ではなく仕事の構造へ戻します。

25.7 下半期の成果から必要な能力を逆算する

体制図を先に描くと、知っている職種を並べるだけになります。まず、下半期末までに得たい顧客・事業成果と、期間内に通過する判断点を置きます。そのうえで必要な仕事量と能力を見積もります。

成果:
対象顧客で価値仮説を検証し、限定提供の継続可否を決める。

判断点:
顧客課題の優先、MVP開始、限定提供、拡大・変更・中止。

必要な仕事:
顧客調査、サービス設計、実装、データ分析、営業連携、運用、法務・安全確認。

必要な能力:
各仕事を完了・確認できる知識、経験、権限、稼働。

供給方法:
既存メンバー、育成、異動、採用、業務委託、共通部門。

人数ではなく、役割ごとの仕事量、必要時期、予定稼働、兼務、余力を見ます。1 人月を一律に 160 時間として埋めず、会議、レビュー、休暇、問い合わせ、学習、管理を含む実績から利用可能時間を置きます。特定の一人だけが持つ顧客関係、技術、承認権は、人数が足りていても単一障害点です。

25.8 体制は三案を同じ条件で比べる

「理想体制」だけでは、予算制約の下で承認者が選べません。最低限、次の三案を同じ成果期間と費用範囲で示します。

各案に、実現できる成果、対象外、役割、人数・稼働、開始可能日、依存関係、費用、主な危険、停止条件を付けます。人数を増やせば比例して速くなるとは仮定せず、採用期間、オンボーディング、レビュー能力、連携コストを入れます。

25.9 予算要求を費目表ではなく投資判断にする

予算は「必要そうな金額」の合計ではなく、何を学び、どの成果を得るための支出かを説明します。

費用は少なくとも次に分けます。

• 人件費: 既存人員の増分、採用、業務委託、管理・レビュー時間
• 制作・技術費: 開発、デザイン、クラウド、AI、データ、ツール
• 顧客検証費: 募集、謝礼、訪問、調査運営、サポート
• 品質・統制費: セキュリティ、法務、アクセシビリティ、監視、保険
• 立上げ・移行費: 採用、教育、データ移行、契約終了、引継ぎ
• 予備費: 金額だけでなく、使える条件と承認者を定義

金額には、単価、数量、期間、開始月、税込・税別、既存予算との重複、資産計上の扱いを記録し、財務担当者と確認します。売上や削減額だけでなく、顧客損害の回避、学習価値、将来の選択肢も分けて示します。効果の二重計上を避け、既存人員を無料と扱いません。

要求は段階化します。例えば、最初の承認では顧客調査とモックまで、次のゲートでは限定 MVP、結果が基準を満たした場合だけ採用と本格開発へ進みます。各ゲートに成果、証拠、支出上限、判断日、追加・変更・中止条件を置きます。投資計算の詳細は第18章を使います。

25.10 予算承認の逆算カレンダーを作る

「下半期開始までに予算が必要」だけでは遅れます。執行開始日から逆算し、次を置きます。

1. 取締役会・経営会議などの最終承認日
2. 事業責任者と予算所有者の合意日
3. 財務、人事、調達、法務、情報セキュリティの確認期限
4. 見積取得、採用承認、契約審査の開始日
5. 体制三案と費用モデルの初回レビュー日
6. 顧客証拠と MVP 結果を反映できる最終日

予算所有者とは早期に、承認基準、予算科目、上限、予備費、採用枠、資料様式を確認します。完成した提案を最後に持ち込むのではなく、荒い三案の段階で不足情報と反対理由を聞きます。

25.11 90日で依頼を体制案へ変える

期間は案件に合わせて調整します。標準的には次の順で進めます。

毎週、顧客から学んだこと、変わった仮説、動く成果物、体制・予算への影響、次に必要な決定を一枚で共有します。活動報告だけにしません。

25.12 支援の終了条件を決める

直接手を動かすほど、外部支援者がボトルネックになる危険があります。開始時に、誰へ何を移すかを決めます。

• 顧客ヒアリングを設計・実施・記録できる
• 顧客の証拠から価値提案を更新できる
• 最重要仮説に合うモックや実験を選べる
• 設計レビューの観点と決定記録を運用できる
• 体制の能力差と費用を更新できる
• 予算ゲートで追加、変更、中止を提案できる

共同実施、相手主導での実施、自走とレビューの三段階で移します。テンプレートだけを渡さず、実案件で一度使い、判断理由と例外まで共有します。

考えてみる問い

今回の五つの依頼について、90日後に誰が何を決められる状態にしたいかを書いてください。次に、最初の二週間で会う人、同席する顧客面談、作る一つの動く経路、比較する体制三案、最初の予算承認日を置いてください。

現場に入る仕事では、ヒアリング、言葉、モック、関係、体制、予算を別々に完成させません。顧客の証拠を価値仮説へ変え、動くものから必要能力を学び、その能力を体制と段階予算へ変えます。付録 H の実践シートを使うと、この流れを一つの案件として管理できます。

第8部では、この過程で得た成功と失敗を、次の案件で使える知見として残します。

第8部 経験を知見に変える

案件が終わっても、経験が自動的に会社の知見になるわけではありません。結果だけを残すと、なぜその判断をしたかが消え、成功は美談に、失敗は個人の責任に変わります。

この部では、第26章で背景、制約、仮説、判断、行動、結果を当時の情報とともに記録します。第27章で複数案件から再利用できる条件を見つけ、本書とプレイブックを安全に更新します。

AI は大量の記録を整理し、似た案件や矛盾を探せます。しかし、機密性、個人情報、後知恵、少数意見を誤って処理する危険があります。何を残し、誰が閲覧し、いつ公開するかを人が決めます。

第26章 成功と失敗を記録する

第25章では、顧客の証拠、動くモック、メンバーとの協働を、次期体制と段階予算へつなげました。案件が終わった後に「成功」「失敗」だけを付けても、次の案件で何を再利用すべきかは分かりません。

経験を知見へ変えるには、結果から物語を作るのではなく、当時の背景、制約、仮説、選択肢、判断、行動、結果を時点ごとの証拠とともに再構成します。

26.1 結果だけで判断品質を決めない

良い結果が出ても、危険を無視した偶然かもしれません。悪い結果でも、当時得られた情報から妥当な選択だった可能性があります。

結果を無視するのではありません。結果と判断過程を別に評価し、次の選択を改善します。

26.2 記録を案件終了まで待たない

記憶は、結果を知った後に一貫した物語へ書き換わります。重要な判断点で、次を残します。

• その時点で分かっていた事実と出典
• 置いた仮説、推定、未知
• 比較した選択肢と評価基準
• 採用した選択と、採用しなかった理由
• 反対意見と再検討条件
• 予想した結果と観測期限
• 次の行動、責任者、支出上限

第22章の決定記録と第24章の変更履歴が、そのまま振り返りの一次資料になります。

振り返りの深さは、金額、顧客・従業員への影響、安全・法令、計画逸脱、未知、再利用可能性に比例させます。目立つ成功と失敗だけでなく、一定の基準で通常案件も抽出し、都合のよい事例だけを選びません。

通常案件では、決定、当時の予想、実際の結果、学び、次に変える一つの行動から記録します。重大な影響、高額、不可逆、部門横断、再発案件では、背景、反対意見、欠測、情報区分まで確認を広げます。参加者、時間、成果物にも上限を置きます。

26.3 背景と制約を結果から分ける

案件記録は、少なくとも次の順で作ります。

背景:
顧客、事業、組織はどの状態だったか。

目的:
誰の何を、いつまでに変えようとしたか。

制約:
現金、時間、人、能力、法令、安全、契約は何だったか。

仮説:
何が正しければ選択が有効だと考えたか。

判断:
何と比べ、誰が、どの条件で決めたか。

行動:
実際に何を行い、計画から何が逸脱したか。

結果:
顧客、事業、現場、安全に何が起きたか。

学び:
どの条件で次の判断を変えるか。

結果欄に解釈を混ぜず、観測事実、推定、評価を分けます。

26.4 時系列で予想と実際を並べる

案件終了時の総括だけでは、途中の学びと変更が消えます。