コトラ（広報チーム） 
事業開発は、新しい事業機会を見つけ、顧客に求められる価値へ変え、事業として継続できる形に育てる仕事です。会議、顧客ヒアリング、調査、資料作成、社内調整など業務は幅広く、1日の予定も事業の段階によって変わります。
特に新規事業では、最初から正解があるとは限りません。仮説を立て、顧客や市場の反応を確かめ、関係者と調整しながら次の行動を決めることが日々の中心業務になります。
事業開発の仕事と担当範囲
新規事業の仮説づくりから検証までを担う役割
事業開発は、顧客や市場にどのような課題があり、自社がどのような価値を提供できるかを考え、事業として成り立つかを検証する役割です。アイデアを出すだけでなく、対象顧客、課題、提供価値、価格、販売方法、収益性などを具体化します。
仮説は、顧客へのヒアリング、既存の営業記録、問い合わせ内容、市場データ、競合情報などをもとに作ります。その後、試作品、提案資料、広告、説明ページ、商談などを活用し、実際の反応を確かめます。
顧客・市場・社内をつなぐ調整役としての役割
事業開発担当者は、顧客の困りごとを社内へ伝え、自社の技術や営業体制、予算、契約条件などの制約を踏まえて事業案を調整します。顧客の要望をそのまま受け入れるのではなく、再現性のある事業にする視点が必要です。
たとえば顧客から求められた機能があっても、開発コストが大きい、法的な確認が必要、他の顧客には必要性が低いといった場合があります。こうした論点を整理し、実現すること、後回しにすること、実施しないことを決めるのも重要な仕事です。
営業・企画・開発との仕事の違い
営業は既存の商品やサービスを提案し、受注や継続利用につなげる役割です。企画は市場や顧客の情報をもとに商品・サービスの内容を設計し、開発は技術や仕様を具体的な形にします。
一方、事業開発は、誰のどの課題を対象にするか、どのような価値なら対価を得られるか、どの部門や外部パートナーと進めるかを横断的に考えます。営業、企画、開発の間に入り、仮説を事業として前に進める役割といえます。
フェーズによって変わる業務内容
事業の初期段階では、顧客課題の探索や市場調査、事業仮説づくりに時間を使います。この段階では、インタビューや現場観察、競合調査、アイデアの整理が中心です。
試験導入や販売準備の段階では、顧客との商談、検証計画の作成、開発や法務との調整が増えます。事業化後は、売上、利用率、継続率などを確認し、改善の優先順位を決める業務が中心になります。
事業開発の1日に多い業務
事業方針や進捗を確認する会議
事業開発では、チーム内の進捗確認、経営層への報告、営業や開発との打ち合わせなど、会議の機会が多くなります。ただし、会議自体が目的になると、検証や顧客接点に使う時間が減ってしまいます。
会議では、現在の仮説、得られた事実、未解決の課題、次に決めることを明確にします。特に、売上や申込数だけでなく、顧客が検討を止めた理由、導入時の障壁、利用が続かない理由も共有することが重要です。
顧客の課題を探るヒアリング
顧客ヒアリングでは、商品案への感想だけでなく、顧客が現在どのような場面で困り、どのような方法で対応しているかを聞きます。「欲しいですか」と尋ねるだけでは、実際の行動や支払い意欲を十分に把握できません。
確認したい内容は、課題が起きた具体的な場面、現在の代替手段、不満、社内での意思決定者、予算、導入を止める条件などです。顧客の発言を一人の意見として扱い、他の顧客や数値データとも照らし合わせます。
市場・競合・利用状況の調査と分析
市場調査では、市場規模、成長性、競合の提供内容、価格帯、販売方法などを確認します。既存事業がある場合は、売上、利用頻度、継続率、問い合わせ内容、商談記録なども重要な情報源です。
新しい顧客課題を探す段階では、インタビューなどの定性情報から仮説を作り、その後にアンケートや行動データで広がりを確認する方法が有効です。一方、既存サービスの利用率低下などを調べる場合は、数値から問題が起きている場所を見つけ、顧客へ理由を聞く進め方が適しています。
提案資料・検証計画・報告資料の作成
資料作成は、会議のためだけに行うものではありません。顧客課題、仮説、検証方法、判断基準、必要な協力を整理し、関係者が同じ方向で動くために作成します。
検証計画には、何を確かめるのか、誰に聞くのか、どのような行動や数値を見ればよいのか、いつまでに判断するのかを記載します。実施後は、結果だけでなく、仮説がなぜ支持されたのか、なぜ修正が必要なのかを整理します。
開発・営業・管理部門との社内調整
開発部門とは実現できる範囲や優先順位を、営業部門とは顧客の反応や販売方法を、管理部門とは予算や契約、法務上の確認を進めます。事業開発担当者には、各部門の専門性を尊重しながら、事業全体の目的を共有する姿勢が求められます。
調整を後回しにすると、顧客に約束した内容を実現できない、試験導入の開始が遅れる、必要な予算が確保できないといった問題につながります。早い段階から関係者を巻き込むことが重要です。
事業開発担当者の1日の流れ
始業から午前中の情報確認と優先順位づけ
始業後は、顧客や社内からの連絡、前日の会議記録、検証指標の変化、業界ニュースなどを確認します。事業開発では想定外の依頼や課題が起こりやすいため、最初に緊急度と重要度を分けることが大切です。
その日の作業は、顧客対応、意思決定が必要な案件、検証を前に進める作業の順に整理します。緊急ではないものの重要な調査や資料作成の時間を、予定表に確保しておく必要があります。
午前のチーム会議と検証の進捗確認
午前中には、チームで前日の進捗や顧客から得た情報を共有する会議を行うことがあります。会議では、作業報告だけでなく、仮説に影響する事実が出たか、判断が必要な課題は何かを確認します。
たとえば、顧客から「導入したいが社内承認が難しい」という声が複数出た場合、単なる営業課題ではなく、導入手順や提案資料、価格設計に見直しが必要な可能性があります。
昼前後の顧客ヒアリングと商談準備
顧客ヒアリングや商談の前には、相手の業種、業務、過去のやり取り、確認したい仮説を整理します。質問を準備する際は、自社サービスの説明を急がず、顧客の実際の行動や困った経験を深掘りする設計が必要です。
ヒアリング後は、印象だけで終わらせず、事実、顧客の解釈、自社側の仮説を分けて記録します。次回の質問や提案に反映できる形で残すことが、調査の質を高めます。
午後の調査・分析と仮説の見直し
午後は、インタビュー記録、商談メモ、利用データ、市場情報などを整理し、仮説を見直します。定性情報では「なぜ困っているのか」「なぜ導入しないのか」を読み取り、定量情報では「どの顧客層に多いのか」「どの段階で離脱しているのか」を確認します。
調査結果は、対象顧客、課題が起きる場面、現在の代替手段、提供価値、購入や導入の障壁、検証指標に分けて整理すると、次の行動につなげやすくなります。
夕方の社内共有・資料作成・翌日の準備
夕方は、関係者への共有、翌日の顧客対応の準備、資料作成に充てる時間になりやすいです。会議やヒアリングで得た情報は、関係者の記憶が新しいうちに共有します。
翌日に意思決定が必要な場合は、結論、根拠、未確定事項、判断してほしいことを短く整理します。すべての情報を伝えるのではなく、相手の判断に必要な情報を優先することが重要です。
会議を事業の前進につなげる実務
会議の目的を意思決定・情報共有・課題解決に分ける
会議を設定する際は、目的を意思決定、情報共有、課題解決のいずれかに分けます。目的が混ざると、議論が広がり、結論が出にくくなります。
意思決定の会議では、選択肢、判断基準、推奨案を事前に提示します。情報共有の会議では、共有後に誰が何をするかを決めます。課題解決の会議では、原因の仮説と対応案を用意しておくと話し合いが進みます。
顧客ヒアリング前に確認したい仮説と質問項目
顧客ヒアリングの前には、何を明らかにしたいのかを決めます。商品案の評価だけを聞くのではなく、顧客の現在の行動を聞くことが重要です。
- どのような場面で課題が起きるか
- 課題が起きたときに、現在はどう対応しているか
- その対応にどのような不満があるか
- 誰が導入や購入の判断に関わるか
- 導入を見送るとすれば、何が理由になるか
会議後に決める担当者・期限・次の行動
会議後は、決まったことだけでなく、担当者、期限、次の行動を記録します。「検討する」「確認する」だけでは、作業が進まないことがあります。
たとえば、開発可否を確認する場合は、誰が、どの機能について、いつまでに、どの条件で回答するかを明確にします。次回会議の日程だけでなく、次回までに必要な材料も決めておくことが大切です。
関係者の認識のずれを防ぐ情報共有
事業開発では、同じ言葉でも部門ごとに意味が異なる場合があります。たとえば「導入可能」「販売可能」「開発可能」は、それぞれ技術、営業、運用、契約など別の前提を含みます。
共有資料では、前提条件、対象顧客、検証済みの内容、未確認の内容を分けます。顧客の発言と自社側の解釈も区別すると、誤解や過度な期待を防げます。
決まらない会議を減らす論点整理
会議で結論が出ない場合は、情報不足ではなく論点が混ざっている可能性があります。顧客価値、技術的な実現性、収益性、優先順位、リスクを一度に決めようとすると議論が進みません。
論点を分け、今回決めることと後で検証することを整理します。反対意見も、単に否定として扱うのではなく、どの前提に懸念があるのかを確認すると、次の調査や検証の材料になります。
顧客調査と分析を日々の業務に落とし込む方法
顧客の発言から課題の背景を読み取る
顧客が「時間がかかる」「使いにくい」と話しても、その言葉だけでは原因が分かりません。どの業務で、誰が、どの頻度で困っているのか、何を代わりに使っているのかまで確認する必要があります。
特に重要なのは、顧客が過去に実際に経験した出来事を聞くことです。理想や一般論ではなく、直近で困った場面、対応方法、発生した損失を聞くことで、課題の深さを把握しやすくなります。
定性情報と数値を組み合わせて仮説を検証する
インタビューや商談記録などの定性情報は、顧客がなぜ困るのか、なぜ選ぶのか、なぜ購入しないのかを理解するために役立ちます。一方、利用率、継続率、申込数、クリック数などの数値は、その傾向がどの程度広がっているかを確認するために役立ちます。
新しい市場を探索する場合は、顧客の声から仮説を作り、数値で優先順位を確認する流れが適しています。既存事業の課題を改善する場合は、まず数値で問題が起きている顧客層や利用段階を特定し、その理由をヒアリングで深掘りします。
調査結果を顧客像と提供価値に整理する
調査結果は、発言の要約で終わらせず、事業の判断に使える形に整理します。顧客像は属性だけでなく、業務や利用場面、課題の強さ、意思決定の条件で捉えることが重要です。
整理する際は、「誰が」「どの状況で」「何に困り」「現在はどう対応し」「何が変われば価値を感じるか」を一連で考えます。さらに、価格、導入負荷、社内承認、既存の代替手段など、利用を妨げる要因も残します。
小さな検証を繰り返して学びを増やす
大きな開発投資の前に、小さな検証で学ぶことが重要です。説明ページへの反応、資料請求、事前登録、試作品の利用、商談での提案、試験導入など、事業の段階に合わせた方法を選びます。
購入意向の回答だけで市場性を判断しないことも大切です。「欲しい」と答えても、価格、導入の手間、社内調整、競合比較などにより、実際の契約や継続利用につながらない場合があります。できるだけ実際の行動に近い指標を確認します。
調査結果を企画・開発・営業へ共有する
調査結果は、報告書で終わらせず、各部門の仕事に変換します。顧客が困る場面は企画や仕様に、顧客が使う言葉は営業資料や説明ページに、導入を止める理由は価格や支援内容に反映します。
共有する際は、「何が分かったか」だけでなく、「何を変えるべきか」「何を追加で確かめるべきか」を示します。調査の限界や、まだ判断できない点も明記すると、過度な一般化を防げます。
社内調整で押さえるべきポイント
関係部門ごとの関心と判断基準を理解する
営業部門は顧客ニーズや受注可能性、開発部門は技術的な実現性や工数、管理部門は予算や契約上のリスクを重視します。部門ごとに関心が異なるため、同じ説明を繰り返すだけでは合意を得にくい場合があります。
相手が必要とする情報に合わせて、説明の順序や資料を変えることが大切です。たとえば開発部門には要件の優先順位を、経営層には市場性、投資額、判断時期を明確に伝えます。
開発・予算・法務上の制約を早めに確認する
顧客から良い反応が得られても、開発期間、予算、個人情報の取り扱い、契約条件などの制約により、そのまま事業化できない場合があります。制約は後から発覚するほど、修正コストが大きくなります。
企画の初期段階から、最低限必要な開発要件、費用、運用体制、法務確認の論点を洗い出します。すべてを詳細に決める必要はありませんが、実現可能性を左右する条件は早めに把握します。
反対意見を事業改善の材料として扱う
反対意見は、事業を止めるためだけのものではありません。顧客価値が弱い、収益性が低い、運用負担が大きい、リスクが見落とされているなど、事業仮説の弱い部分を見つける機会になります。
重要なのは、反対の理由を具体化することです。「難しい」という意見に対して、技術、費用、顧客ニーズ、体制のどこに問題があるのかを分けて確認します。その結果を次の検証計画へ反映します。
意思決定者に必要な情報を簡潔に伝える
意思決定者への報告では、情報量よりも判断しやすさが重要です。最初に、何を決めてほしいのか、推奨する案は何か、判断しない場合の影響は何かを示します。
根拠としては、顧客の声、数値データ、競合状況、投資額、リスク、代替案を必要な範囲で整理します。詳細資料は補足として用意し、会議では論点を絞ると意思決定が進みやすくなります。
優先順位の変更と想定外の対応に備える
事業開発では、顧客からの要望、競合の動き、開発遅延、予算変更などにより、優先順位が変わります。すべてに対応しようとすると、検証の目的が曖昧になります。
変更が起きたときは、事業目標に対する影響、顧客への影響、対応期限、必要な工数を確認します。そのうえで、今取り組むこと、保留すること、中止することを明確にします。
事業開発の1日を充実させる仕事の進め方
会議・調査・作業時間の配分を定期的に見直す
会議が多いと、顧客調査や分析、資料作成の時間が不足しやすくなります。週単位で予定を振り返り、会議が事業の前進につながっているか、調査や検証の時間が確保できているかを確認します。
会議の目的が不明確なものは短縮、統合、非同期の共有に切り替えます。一方で、顧客との対話や仮説の見直しなど、事業の方向性に影響する時間は優先的に確保します。
緊急対応に追われないための時間の確保
急な顧客対応や社内確認が発生することを前提に、予定を埋めすぎないことが重要です。すべての時間を会議で埋めると、分析や判断が後回しになります。
集中が必要な作業は、会議が少ない時間帯に予定として確保します。調査結果の整理、検証計画の作成、重要な提案資料の作成などは、細切れの時間だけで進めようとしない方がよいでしょう。
仮説・判断・学びを記録として残す習慣
事業開発では、前提が変わりやすいため、なぜその判断をしたのかを残すことが重要です。記録がないと、同じ議論を繰り返したり、過去の失敗から学べなかったりします。
記録する内容は、仮説、根拠、検証方法、結果、判断、次の行動です。仮説が外れた場合も、失敗として消すのではなく、何が分かったのかを残します。
一人で抱え込まず関係者を巻き込む姿勢
事業開発は担当者だけで完結する仕事ではありません。顧客理解には営業やサポート部門の知見が、実現性の確認には開発や法務の知見が必要です。
早い段階から相談し、関係者が意見を出せる状態をつくることで、後工程の手戻りを減らせます。協力を依頼する際は、事業の目的、相手に依頼したいこと、期限、期待する成果を明確に伝えます。
不確実な状況で次の行動を決める考え方
事業開発では、十分な情報がそろうまで待つと判断が遅れます。一方で、根拠が弱いまま大きな投資を行うことも避ける必要があります。
重要なのは、現時点で最も不確実性が高く、事業への影響が大きい前提を見つけ、小さく確かめることです。顧客課題、支払い意欲、導入のしやすさ、継続利用、販売方法などを分け、次に何を確かめれば判断が前に進むかを考えます。
事業開発の1日は、決まった作業を繰り返すだけではありません。会議、顧客調査、分析、社内調整を通じて仮説を更新し、事業を前進させるための判断を積み重ねる仕事です。日々の業務を記録し、顧客の事実と数値をもとに次の行動を決めることで、不確実な状況でも事業の学習速度を高められます。
