日本市場のGTMを90日で検証する：投資判断につなげる実行計画

この計画の使い方

日本市場への投資を決めるには、市場規模の説明や好意的な商談だけでは足りません。誰が、なぜ今、何を購入するのか。購入までにどの条件を満たす必要があり、自社は採算の合う形で提供できるのか。その根拠を集める必要があります。

本稿は、海外のB2Bテクノロジー企業が、90日間で次の投資判断に必要な材料を集めるための実行案です。日程や判断基準はOlkanaが提案する計画用の枠組みであり、日本市場の平均値ではありません。90日で判断の精度を高めることを目指しますが、その期間内の受注を約束するものではありません。

1. 調査内容より先に、何を決めるかを決める

まず、限定的な日本向け営業活動に投資する、パートナー経由の販売を試す、用途を絞る、投資を保留する、といった判断を一つ選びます。その判断によって動く人員、ローカライズ費用、技術支援の工数も明記します。決裁者のいない調査は、情報収集を続けるだけになりがちです。

検証方針を次の六項目で一枚にまとめましょう。

• 顧客：業種、企業規模、想定する購買関係者。
• 課題：一つの業務と、現状の費用・負担・リスク。自社の推測だけでなく顧客の事実で確かめる。
• きっかけ：その課題への対応が必要になる具体的な出来事。
• 提案：範囲を定めた評価や購入提案と、想定価格帯。
• 制約：製品、契約、提供体制のうち、採用を止める可能性が最も高い条件。
• 判断：誰が、いつ、どの根拠で次の投資を決めるか。

「日本企業にはAIセキュリティが必要」という仮説は広すぎます。「社内AIアシスタントの利用拡大に向け、機密情報へのアクセス権限を説明できるようにしたいチーム」という仮説なら、確認すべき業務や関係者を具体化できます。これは説明用の仮説であり、日本企業全般や特定企業の状況を述べたものではありません。

2. 1〜15日目：前提を分解し、致命的な障害を探す

不確実性を、課題の緊急性、顧客との接点、相手が時間や予算を投じる意思、提供準備、顧客獲得の採算に分けます。それぞれに担当者、検証方法、証拠を残す場所を決めます。総合点だけで判定しないことが重要です。提案するデータの扱いに重大な問題があるなら、優れた営業資料で埋め合わせることはできません。

AIやセキュリティ製品なら、構成図、データの種類と流れ、提供形態、該当する委託先、アクセス制御、保存・削除の仕様、既知の制限、サポート範囲、障害時の連絡体制を整理します。回答には「文書で確認済み」「設定による」「未対応」の区分を付けます。法令や契約に関わる論点は、適切な専門家に確認してください。本稿は適法性を判定するものではありません。

NISTの任意利用のAIリスク管理フレームワークは、活動をGovern、Map、Measure、Manageに整理しています。質問を組み立てる参考になりますが、製品が顧客の管理基準や日本の要件を満たすことの証明ではありません。NIST AI RMF

事業拠点の設立は別の検討事項です。JETROは法人設立、在留資格、税務、労務などの手続きに関する情報を公開しています。専門家に確認する論点の整理に使い、個別の販売形態を確認せずに「日本法人は必須」「日本法人は不要」と決めつけないようにします。JETRO：Setting Up Business

この段階の成果物は、仮説一覧、事実に基づく評価用資料、顧客との検証開始前に解消すべき障害の一覧です。

3. 16〜35日目：提案の評判ではなく、購買につながる課題を確かめる

最初の方針に沿って候補企業を選び、業務の責任者、予算を持つ人、技術・リスクを確認する人の見方を集めます。少数の対話は定性的な探索であり、市場全体の需要を推計する調査ではありません。返答がなかった対象も記録します。紹介で接点を持った相手と、面識のない相手とでは、反応が異なる可能性があります。

質問は、実際の行動が分かる形にします。

1. この問題が直近で起きたとき、何がありましたか。
2. 現在はどのように対応し、誰が時間や費用を負担していますか。
3. どのような出来事があれば、対応の優先順位が上がりますか。
4. 評価、承認、運用、支払いは、それぞれ誰が担当しますか。
5. 検証開始を妨げる条件は何ですか。
6. 検証に成功しても、購入前に残る手続きは何ですか。

発言内容、相手の立場、日付、その事実から判断できることとできないことを分けて残します。「デモが好評だった」は関心の根拠です。「技術担当者と検証日程が決まった」は評価に時間を使う意思の根拠です。どちらも予算承認を意味するわけではありません。

顧客層ごとに結果を比較します。負担の大きい課題があっても、検証を進める責任者が見つからないなら、接触数を増やす前にその理由を確かめます。面談のたびに用途が変わるなら、一つの大きな需要にまとめず、検証対象を絞り直します。

4. 36〜60日目：終了時の判断まで含めて検証を設計する

繰り返し確認できた課題を、範囲の決まった検証に変えます。現状の基準、目標、使用を許可されたデータ、連携範囲、双方の役割、時間、費用、結果を判断する会議を定めます。可能な場合は合成データや適切に利用許可を得たデータを使います。デモの見栄えのために、機密性の高い本番データの提供を求めないようにします。

例えばセキュリティ業務なら、合意した現状の運用と、一次対応にかかる時間や品質を比較する設計が考えられます。誤検知への対応、監査証跡、再現可能なエスカレーションも評価対象になり得ます。実際の基準は顧客と決めます。技術指標の改善だけで事業価値が証明されたとは扱いません。

開始前に、誰が次の段階を決められるのか、成功後にどの契約・購買手続きがあるのか、それでも購入を止め得る条件は何かを確認します。次の判断がない無償検証は、期限のない支援になりかねません。有償検証は支出意思のより強い根拠ですが、継続購入や他社への再現性まで示すわけではありません。

パートナーが関わる場合は、案件の管理、ヒアリング、導入、請求、サポートの責任を明記します。直接販売と比べた工数・採算も確認しましょう。紹介を得たことと、提供体制の合意ができたことは、異なる段階の成果です。

5. 61〜90日目：次の投資を、根拠に見合う規模で決める

結果は最初の方針に照らして確認します。選択肢を三つに分けると、判断が明確になります。

• 継続：特定の顧客層で同じ課題が確認でき、担当者が実際の時間や費用を投入している。重要な障害に解消方針と責任者があり、次の検証費用も負担できる。
• 修正：有用な兆候はあるが、判断できない変数が残る。顧客層や提案など主要な変数を一つ変え、より小さな追加検証を行う。
• 保留：緊急性が見られない、次の段階を進める人がいない、重要な条件を満たせない、提供工数に対して採算の見通しが立たない。

これは判断の考え方であり、共通の数値基準ではありません。件数などの条件を使う場合は、結果を見る前に合意しておきます。小規模な探索で独立した三社が検証に進めば、次の学習投資の根拠にはなり得ます。ただし、それだけで市場全体の安定した転換率が分かるわけではありません。

意思決定メモには、最初の仮説、それを支持する事実と反する事実、未解決の前提、支出と投入時間、次に必要な投資、再確認日を記載します。最終判断を担う人も明記します。

6. 学ぶための費用と、提供するための費用を分ける

ヒアリング、双方が合意した検証、条件を満たす商談、契約済み顧客を別々に管理します。各段階で、提供工数、営業技術支援の工数、経過日数も記録します。面談数が増えていても、対象の適合度が落ちたり、受注前の支援負担が膨らんだりすることがあります。

検証予算は、外部支出に、統一した人件費基準で評価した社内工数を加えて把握します。一度だけ必要な準備費用と、繰り返し発生する顧客獲得・提供費用は分けます。創業者がすべての技術説明を担当するなら、その時間もゼロ円にせず記録します。

90日目に問うべきことは、「次の投資を支える根拠は何か。次に費用をかけて解消する不確実性は何か」です。その答えが、次の実行計画になります。

今週から使える記録の形

重要な前提ごとに、仮説、必要な根拠、検証方法、担当者、期限、実際の観察、残る不確実性、次の判断を一行で記録します。計画を成立させなくする可能性が最も高い前提から始めましょう。最初の面談前に振り返り日を決め、否定的な情報も好意的な反応と同じように残します。