- 公開日
新規事業の検討でAIを使うなら、提案書へまとめる前に、確認済みの材料と未検証の見込みを分けます。顧客が困っていること、費用を払ってでも解決したいこと、自社が提供できることは、別々に確かめる必要があります。AIには分類や検証計画の下書きを任せ、人が原資料と照合して採否を判断します。
「仮説」「推測」「アイデア」の使い方は組織によって異なります。本稿では、仮説を検証したい主張、推測を限られた材料から導いた見立て、アイデアを実現を検討する提案として区別します。名前を付けただけで正しさが確定するわけではなく、根拠と次の確認を一緒に記します。
一枚の事業メモを材料ごとに分ける
架空の企画チームが、小規模事業者向けの予約変更管理サービスを検討するとします。手元には、公開されている既存サービス二社の機能表、協力店舗三店の担当者への聞き取りメモ、開発担当者の技術メモがあります。資料の内容も以下の件数も説明用の仮定です。
事業メモに、次の四行が混在しているとします。
- 比較した二社の機能表には、予約変更の通知機能が記載されている
- 聞き取りをした三店のうち二店の担当者が、変更連絡に手間がかかると話した
- 小規模店舗は月額5,000円なら新しいサービスを使うはずだ
- 変更受付から通知までをまとめれば、初年度に100店が契約する
さらに「音声で変更を受け付ける」という企画案も加わっています。このままAIへ提案書の作成を頼むと、困り事の発言、支払意思、将来契約数、機能の案が、一つの確定した市場像としてつながりかねません。
最初の二行でも、確認できた範囲を限定します。機能表の記載は、実際の動作や全競合の機能を確認したことではありません。二店の発言が記録にあることと、店舗全体で同じ困り事が発生していることも別です。
根拠と確認対象を同じ行に置く
AIへは、「次の資料を、記録で確認できる事項、検証する仮説、条件付きの見立て、企画案に分けてください。各行に根拠箇所と不足情報を付けてください。分類できないものは理由を残し、需要や実績を補わないでください」と依頼します。ここでは利用が認められた資料だけを入力し、個人名や不要な店舗情報は除く前提です。
期待する整理は次のようになります。これは未実行の出力例です。
| 記述 | この資料での位置付け | 根拠または前提 | 次に確かめること |
|---|---|---|---|
| 二社が変更通知機能を掲載 | 確認した事実の範囲 | 対象機能表の記載と取得日 | 対象プラン、制限、実際の利用条件 |
| 二店の担当者が手間を訴えた | 聞き取り記録上の事実 | 三店中二店の発言箇所 | 直近の具体的な作業と頻度 |
| 月額5,000円なら利用する | 需要仮説 | 価格受容の確認なし | 利用者と支払決定者の評価 |
| 初年度100店の契約 | 条件付きの予測 | 獲得経路・成約率が未確認 | 見込み客数、成約、継続の条件 |
| 音声で変更を受け付ける | 企画アイデア | チームが追加した案 | 必要性、認識誤り、確認方法 |
「初年度100店」は数字が具体的でも、裏付けのないままでは予測の妥当性を判断できません。試算へ残す場合は仮定値と表示し、その数字から市場規模を逆算して事実らしく書かないようにします。今回の材料だけなら、契約数の予測は保留できます。
需要は困り事と支払意思を分けて確認する
需要仮説を調べるときは、「便利だと思いますか」という感想だけで終わらせず、現在の行動を尋ねます。最近どの予約変更で何が起きたか、誰がどれだけ作業したか、現在は何で代替しているかを確認し、解決する必要の強さを把握します。
米国NSFのI-Corps Teamsの説明では、見込み顧客、パートナーなどとの対話を通じて、技術の事業機会を評価する顧客発見の活動を紹介しています。ここでの聞き取りは、そのような材料収集を行うための提案です。特定回数の面談や賛成意見の数だけで需要を保証するものではありません。
この例でまず確かめたいのは、「変更連絡が負担になっている店舗がある」と「その店舗が新サービスに費用を払う」の間です。現場担当者が困っていても、経営者が別の課題を優先していれば採用されないことがあります。使う人と支払う人が同じかも確認します。
検証計画には、対象店舗の条件、確かめる主張、方法、判断する資料、次の判断を記します。例えば、予約変更が頻繁な店舗へ、過去の作業記録と現在の代替手段を確認し、提示した機能と価格条件で試行に進む意思があるかを調べる計画です。実際の契約や費用の発生が伴う試行は、別途その内容の承認を得て行います。
都合のよい店舗だけに聞くと、残る市場を代表できません。協力店舗の選び方を残し、困り事がない店舗や現行サービスで足りている店舗の理由も確認します。回答が得られなかった店舗を、関心がないと自動分類することも避けます。
実現性は顧客の賛成とは別に確認する
音声受付の案に賛成が集まっても、予約日時の聞き違い、本人確認、変更の重複、既存システムとの連携が解決したことにはなりません。AIには必要な確認項目を整理させ、技術担当者が具体的な方式と利用条件を調べます。
この段階では、音声を受け付けた後に人が内容を確認する案と、変更処理まで自動化する案を分けます。後者は誤った日時や対象で変更すると影響が大きいため、対象者の確認、変更内容の承認、結果が不明な場合の扱いまで必要です。技術メモに「連携できそう」と書かれているだけでは、実装済みとは扱いません。
実現性の検証計画には、外部へ予約変更を送信しない模擬データで、受付内容を正しく取り出せるかを確かめるなど、影響を限定した方法を置けます。ただし、本稿の執筆ではその試験を実施していません。計画した確認、試験した範囲、本番で満たす条件は、資料上で分けて記録します。
採算についても、月額料金だけで判断せず、導入支援、問い合わせ、確認作業、障害時の対応を誰が担うかを見ます。費用が未確認ならゼロにせず、見積もる担当者へ渡します。技術的に作れることと、想定価格で続けられることは同じではありません。
提案書では確認状況が変わらないように書く
修正前の表現が「市場は予約変更の自動化を求めており、音声機能で初年度100店を獲得できます」なら、未確認の需要と獲得予測が、実現できることとしてつながっています。
今回の材料で書けるのは、「協力店舗三店の聞き取りでは、二店の担当者から変更連絡の負担が報告されました。月額5,000円での利用意思と、音声受付への需要は未確認です。まず対象店舗の作業と支払判断を確かめ、技術面では変更実行を伴わない条件で受付内容の確認方法を検討します」という範囲です。
企画担当者は発言記録と分類表を照合し、営業担当者には顧客条件と需要仮説を、技術担当者には機能の前提と試験計画を、事業責任者には予算と判断待ち事項を渡します。スライドへ要約する際も、「未確認」「仮定」「計画」の表示を落とさないようにします。
調べた結果で案を更新する
検証で想定に合わない結果が出たら、どの資料がどの仮説を支えなくなったのかを記録します。変更連絡の負担はあるが支払意思が確認できないなら、課題の存在を残しつつ、価格や提供方法を再検討します。音声受付が不要と分かれば、事業全体を直ちに否定せず、その機能案を外して考えられます。案を広げる段階と絞り込む段階で依頼をどう切り替えるかは、発散と収束でプロンプトを切り替える方法で扱っています。
他の業種へ展開する際は、同じラベルの表を再利用できても、顧客、支払主体、業務の頻度、必要な権限まで引き継げるとは限りません。根拠の対象を広げるときは新しい確認が必要です。事業資料を更新するたびに、何を実際に確かめ、どの判断を変えたかを残すことで、案の文章だけが先に確定してしまうのを避けます。
視点と実施条件を変えてアイデアを広げる方法は「AIのアイデアを広げるには視点と実施条件を変えて比べる」、事実・仮説・推論を分けて検証を選ぶ方法は「AIの事実と仮説と推論を分けて作業に合う検証を選ぶ」で解説しています。
