生成AIを調査や資料作成に使い始め、事業開発全体の進め方も変えたい。しかし、企画案を早く作れても、社内確認や次工程への引き継ぎに時間がかかり、顧客検証までなかなか進めない。
こうした状況で本当に問うべきは、「生成AIに何ができるか」よりも、「各工程で誰が確認し、どの条件がそろえば次へ進むのか」という業務設計です。生成AIに任せる作業の選定は、この設計の見直しと必ずセットで考える必要があります。
本記事では、BtoB企業の事業開発担当者に向けて、既存フローの棚卸しから、企画・検証の実践手順、人による評価と意思決定、試行後の改善までを解説します。
INDEX
生成AIは、市場資料の要約や顧客の声の分類、企画案・試作品のたたき台作成などに活用できます。ただし、作成したものを誰が確認するか決まっていなければ、次の工程で止まってしまいます。生成AIによる作業支援と、成果物の受け渡し方や判断手順の変更を組み合わせて考えることが重要です。
以下は、見直し前後のフローの一例です。実際に変更する範囲は、自社の業務や承認ルールに合わせて決めます。
|
工程
|
見直し前のフロー例
|
生成AIを組み込んだフロー例
|
人が確認・判断すること
|
|
調査・企画 |
調査資料を完成させてから企画担当者へ渡す | 生成AIで情報と課題仮説を整理し、不足情報を追加調査しながら企画を具体化する | 根拠の妥当性、優先して検証する課題 |
|
企画・試作 |
詳細な企画書の完成後に試作を依頼する | 検証目的と必要条件を共有し、生成AIで画面・資料・コードのたたき台を作る | 試作範囲、内容や動作、顧客に提示できる品質 |
|
検証後の対応 |
結果を報告し、次の会議で対応を決める | 生成AIで記録と変更点を整理し、承認済みの範囲は担当者が修正する | 仮説の見直し、追加投資や方針変更の要否 |
表の内容は、このあとの章で順番に説明していきます。
調査と企画の往復や、小さな試作を用いた検証は、生成AIが登場する以前からある考え方です。生成AIを組み込む際は、その反復に必要な情報整理や試作の負担をどこまで減らせるかを確かめます。
また、担当者に判断権限を持たせることは、生成AIの機能ではなく業務設計上の変更です。顧客との日程調整や必要な品質確認まで一律に短縮できるとは限らないため、作業と待ち時間を分けて見直します。
生成AIを組み込む前に、現在のフローのどこで作業や判断が止まっているかを把握します。
作業時間と引き継ぎ・承認の待ち時間を分けて整理し、今回見直す工程を決めましょう。
まず、進行中または直近の案件を一つ選び、調査、企画、試作、顧客検証の流れを並べます。各工程について、作業内容、成果物、担当者、確認者、次へ進む条件を整理しましょう。
所要時間は、担当者が作業した時間と、確認や承認を待っていた時間に分けます。差し戻しがあれば、情報不足、要件の変更、確認者との認識のずれなど、発生した理由も記録しましょう。
例えば、企画資料の作成よりも、提出後の追加説明に時間がかかっている場合があります。この場合は、資料作成を生成AIで支援するだけでなく、確認者が必要とする情報をあらかじめ成果物に含める見直しが必要です。
棚卸しの結果を基に、「顧客の声を整理する負担を減らす」「企画から顧客検証までの日数を短くする」など、今回改善する課題を定めます。そのうえで、生成AIに任せる作業と、合わせて変更する手順を決めましょう。
例えば、インタビュー記録の整理に時間がかかっているなら、生成AIでの分類・要約と担当者による確認を試します。一方、試作への着手が遅れているなら、詳細な企画書がどこまで必要か、検証目的と必要条件を共有すれば始められるかを検討します。
対象は、必要な情報を利用でき、確認担当者を確保できる工程から選ぶことが重要です。全工程を一度に変えるのではなく、変更範囲を限定して試すことで、何が改善し、どこに負担が残るかを捉えやすくなります。
ここからは「企画・構想」と「仮説・検証」それぞれで生成AIを活用した事業設計ポイントを解説します。各段階で渡す成果物と進め方を具体化しましょう。
大まかなポイントは以下です。
以降の内容を参考に、企画〜検証の各段階で渡す成果物と進め方を具体化しましょう。
調査を始める前に、「何を判断するために、どの情報が必要か」を決めましょう。例えば、法人向けサービスの構想なら、対象となる業務、現在の対処方法、残っている負担などを比較軸にできます。
次に、利用可能な市場資料、商談記録、顧客インタビューの記録を用意し、生成AIに共通点・相違点・不足情報を整理させます。商談記録や顧客インタビューには、機密情報や個人情報が含まれる場合があります。入力前に、データの学習利用・保存・アクセス権限などの取り扱いを確認し、社内ルールに沿って当該情報を扱える生成AI環境を使用してください。整理に不要な顧客名や個人を特定できる情報は、削除・マスキングしておきましょう。
依頼時には、対象範囲、比較軸、参照元を残すこと、資料にない内容は推測と明記することを伝えるのが重要です。
最新情報が必要な場合は、検索機能や接続先で取得できる範囲を確認します。出力だけで判断せず、元資料の公表日や対象市場を確かめましょう。
生成AIが整理した内容を担当者が元資料と照合し、次の形式にまとめて検証へ渡します。
|
項目
|
記載する内容
|
|
対象顧客・利用場面 |
誰が、どの業務や状況で困っているか |
|
課題仮説 |
何が負担となり、どのような改善が必要と考えられるか |
|
根拠 |
仮説を支える記録・資料と、確認した事実 |
|
未確認事項 |
推測にとどまる点、追加調査や顧客確認が必要な点 |
仮説を支持する情報だけでなく、当てはまらない顧客や反対の発言も残します。次の工程で検討すべきことが明確になれば、調査資料の量を増やすことに終始せず、顧客に確かめる段階へ進めます。
試作では、今回確かめる仮説から必要な範囲を決めます。利用手順が伝わるかを確かめるなら画面の試作、提供価値を顧客の利用や反応から学ぶならMVPを検討しましょう。
MVP(Minimum Viable Product)は、事業仮説を検証するための最小限の製品・サービスのことです。単に機能を減らした未完成品や、見た目のたたき台を指すわけではありません。何を検証するかによって、必要な形が変わります。
生成AIに試作を依頼する際は、次の情報を共有します。
説明資料ならテキスト生成、画面イメージなら画像生成、操作できる試作ならコード生成など、目的に応じて使い分けましょう。
生成した画像を顧客への提示や公開資料などに使用する際は、利用サービスの規約に加え、既存の著作物との類似や、他者のロゴ・人物の表現など、第三者の権利に関わる点を確認してください。権利侵害の懸念が残る場合は、そのまま使用せず、社内の担当部門などに確認しましょう。
例えば、法人向けの申請支援サービスを検証する場合、申請内容の入力から確認結果の表示までを試作し、裏側の確認は担当者が行う方法もあります。これは一例ですが、すべてを自動化する前に、顧客にとって役立つ流れかを確かめる考え方です。
生成したコードや画面は、担当者が内容・動作を確認します。検証用データを使い、実装済みの機能と仮の表示を区別したうえで顧客に提示しましょう。必要な期間は試作範囲や連携の有無によって変わるため、作成・確認・修正を含めて計画します。
試作を始める前に、検証先、確認する仮説、期間、次の判断に必要な情報を決めます。営業担当者が顧客との窓口を担っている場合は、検証への協力依頼や説明範囲も相談しておきましょう。
協力を得られる顧客数や検証に使える時間が限られる場合は、試行回数を増やすこと以上に、一回で何を確かめるかを絞ることが大切です。
検証では、顧客に実際の業務場面を想定して試してもらい、操作が止まる箇所、追加説明が必要な点、現在の方法から切り替える際の障害を確認します。「便利そう」という感想だけでなく、どの業務で使うか、何が解決しないまま残るかを聞き取りましょう。
BtoBの場合利用者と決裁者が異なるため、購買の意思決定に関わる人や部門(DMU:意思決定関与者)を整理します。利用者には業務への適合性、決裁者には期待する成果と費用、情報システム部門には連携や運用条件など、それぞれが判断する事項を確認します。
稟議に必要となる費用対効果や、既存システムとの関係も確認事項に含めることが重要です。一度の検証ですべてを確かめる必要はなく、今回の対象と次回以降の課題を分けます。
既存顧客に試作品を提示する際は、正式な提供を約束するものと受け取られないよう、検証目的と対応範囲を説明します。開示する情報の範囲を事前に決め、商談中の案件があれば、その提案内容との関係も整理しておきましょう。
検証後は、顧客の発言や行動、仮説を支持・否定する事実、修正案を生成AIで整理します。担当者が記録と照合し、次に変える点と、追加で確かめる点を決めておきましょう。生成AIが生成した想定反応は、実際の顧客による評価と区別してください。
生成AIを業務に組み込む際は、出力の確認項目と、事業を進める判断条件を共有しておきます。
誰が確認し、どこまで担当者が進められるかを決め、品質確認と意思決定の両方を支える体制を整えましょう。
生成AIが作成した資料や試作品の品質と、その内容を根拠に事業を進めてよいかは、分けて評価します。資料が整っていても、顧客の課題や導入条件が確認できているとは限りません。
ここで重要なのは、判断そのものを属人的な感覚に委ねないことです。「どの条件がそろえば次へ進み、何が欠けていれば止めるか」を、検証を始める前にチームで決めておきます。生成AIが作業を速くするほど、判断の回数は増えます。そのたびに基準がぶれれば、速くなったはずのプロセスがかえって停滞します。判断を速く、かつ安定させる土台は、AIの性能ではなく、事前に合意した判断条件の明確さにあります。
生成AIは100%ではなく、時に誤った内容や出典を示すことがあります。本記事では、出力を確認する観点を次のように整理してみました。
|
観点
|
確認すること
|
|
正確性 |
数値・記述が元資料と一致し、試作品が想定どおりに動くか |
|
根拠 |
出典が実在し、記載した主張を支えているか |
|
目的との一致 |
今回の調査や検証に必要な内容がそろっているか |
|
不足・偏り |
重要な条件、反対意見、仮説に合わない事実が抜けていないか |
そのうえで、事業を進める判断では、顧客から得た事実、未解決の課題、次の検証に必要な費用と人員を検討しましょう。判断の条件は、検証を始める前に、「進む」「直してもう一度試す」「止める」の3つに分けて書いておきます。
|
判断
|
条件の例
|
|
進む |
想定した利用者の半数以上が、同じ悩みを挙げている |
|
直してもう一度試す |
悩みは確認できたが、試作品の操作でつまずく人が多い |
|
止める |
前提にしていた悩みが、検証先で確認できなかった |
数字の基準は、結果を見る前に責任者と決めておきましょう。仮説が支持された場合は次へ進み、前提が外れた場合は修正や見送りを判断します。判断材料が不足している場合は、追加で確かめる内容を明示することも忘れてはなりません。
出力を確認する役割と事業を判断する役割は、同じ人が担う場合もあります。その場合も、確認事項と判断の記録を分け、資料の完成度だけで進行を決めないようにしましょう。
事業開発、営業、開発などの関係者について、確認する内容と判断権限を決めます。部署名を固定するよりも、自社で誰がその役割を担えるかを整理することが実務につながります。
|
役割
|
担当内容例
|
|
事業開発の担当者 |
検証目的、成果物、次の対応案を整理する |
|
顧客接点を持つ担当者 |
検証先との調整、顧客の背景確認、既存商談との整合を確認する |
|
技術面の確認者 |
試作品の動作、データの扱い、既存環境との関係を確認する |
|
推進責任者・決裁者 |
予算や方針の変更、次段階への移行を判断する |
例えば、承認済みの検証目的・予算・情報の利用範囲内で行う文言修正は担当者が進め、対象顧客の変更や追加予算が必要な場合は責任者に相談する、といったルールを設けます。判断を求める際は、変更点、根拠、影響をそろえて渡します。
必要な専門確認は確保しつつ、すべての修正を定例会議まで待たせない運用を検討しましょう。確認担当者と期限を決めることも、工程間の停滞を減らすための具体策です。
合わせて、利用する生成AI環境、入力できる情報の範囲、成果物と確認履歴の保存先を共有します。依頼文や確認項目は、使った条件と修正点を添えて蓄積し、他の担当者が再利用できる形に整えましょう。
設計したフローは、一つの案件で試し、実際の進行と担当者の負担を確かめます。
時間短縮だけでなく、手戻りや判断材料の充足も振り返り、他の案件へ展開できる進め方に整えることが重要です。試行する案件は、次の条件を確認して選びます。
開始前に、対象工程、期間、担当者、成果物の条件、評価指標を決めます。比較には、同じ種類の作業や類似案件の記録を使います。ただし、案件の難易度や担当者、成果物の範囲が違えば、その差も残しておきましょう。
効果は、生成AIを使った回数だけでなく、次の観点で確認します。
|
評価すること
|
確認する指標・記録
|
|
進行の速さ |
企画から顧客検証までの日数、工程ごとの待ち時間 |
|
確認の負担と総工数 |
出力の確認・修正にかかった工数と、資料準備や生成AIへの依頼も含む総工数 |
|
手戻り状況 |
差し戻しの回数と理由、同じ問題の再発状況 |
|
判断材料の充足 |
事前に決めた確認項目がそろったか、未確認事項が明示されているか |
仮説を見直すための修正と、情報の抜けや共有不足による手戻りは分けて記録します。顧客検証で前提が変わったこと自体を、プロセスの失敗と評価しないためです。
作成時間が減っても確認・修正が増えた場合は、入力情報や依頼方法、利用範囲を見直します。承認待ちが残った場合は、確認者が必要とする情報や権限の設定を振り返りましょう。
一つの案件で得た結果だけで、全社的な効果まで判断することは避けます。試行で確認できた改善点と適用条件を残し、同様の案件へ広げながら、成果物の形式や手順を整えていきましょう。
生成AIを事業開発に組み込むには、作業の効率化と合わせて、成果物、引き継ぎ、人が判断する条件を見直すことが重要です。企画・検証の目的を明確にし、生成AIによる情報整理や試作を、顧客から学び、次の対応を決める流れにつなげます。判断条件においては、「進む・直す・止める」をどう判断するか、検証の前に書いておくことが重要です。
まずは一つの案件で試行し、総工数や待ち時間、手戻り、判断材料の充足を確認しましょう。その結果を成果物の形式や役割分担に反映することで、自社に合う進め方を整えられます。
生成AIの定着を分けるのは、ツールの性能そのものではありません。「誰が確認し、どの条件で次へ進むか」という業務設計を、自社の手で描き直せるかどうかです。
わたしたち電通B2Bイニシアティブは、BtoB事業の成長を加速させるデマンドジェネレーションとブランディングのプロフェッショナルです。
電通グループの強みである広範なネットワークと豊富なデータ資産、そしてBtoBに特化した専門チームの知見を活かし、以下の領域をトータルで支援します。
わたしたちの核にあるのは、広告コミュニケーションで培ってきた「人の心を動かす力」です。この力を活用し、経営・人材・組織・事業といったあらゆるレイヤーにおける課題に向き合いながら、具体的な施策の実行から最終的な成果を分析・改善し続けるためのサイクルの創出まで伴走します。
単なる「施策の提供」にとどまらず、強いブランドづくりや売れる仕組みの構築を通じて、企業の持続的な成長と信頼性の高いパートナーシップの実現を目指します。
デジタル領域における、BtoBに特化した多様なご支援が可能ですので、ぜひ一度ご相談ください。