IT営業の初回ヒアリングでは、顧客の要望を集めるだけでなく、解決したい業務課題と、提案前に確認する条件を分けて持ち帰ります。「必要な機能を聞いたが、技術担当に説明できない」という場面では、誰が何に困っているのか、何を変えたいのか、何が未確認かを整理し直すのが出発点です。
本記事は、システムやITサービスの導入を提案する営業向けに、質問項目と記録方法を紹介します。初回商談の整理例であり、この表を埋めれば要件定義や見積もりが完成するというものではありません。
初回の到達点は、課題と次の確認事項を共有すること
厚生労働省のjob tagは、ITのコンサルティング営業について、顧客の課題に対して情報システムやサービスを提案し、システムエンジニアなどと連携する職業として説明しています。job tag「コンサルティング営業（IT）」
営業がその場で実現方法や納期を断定するより、確認できたことと技術判断が必要なことを分ける進め方をおすすめします。本記事では、初回の到達点を次のように置きます。
- 解決したい業務課題と、対象となる利用者が分かる。
- 希望する機能と、その機能で変えたい業務を結び付けられる。
- 提案前に確認が必要な条件、確認先、次の行動が分かる。
顧客が話した要望と、関係者が合意した条件は、同じ欄にまとめないようにします。IPAの解説でも、要求を文書化し、関係者と合意して要件とする考え方を紹介しています。IPA「要件定義とは？」
初回ヒアリングで確認したい項目
次の表は、商談の準備に使う質問例です。すべてを一度に聞き切るための台本ではありません。顧客が既に提供した資料を読み、重複を避けながら、提案に必要な不足を確認します。
| 論点 | 質問例 | メモに残すこと |
|---|---|---|
| 背景 | 今回、検討を始めたきっかけは何ですか | 起きた変化、困っている業務 |
| 現状 | 誰が、どの順番で、何を使って処理していますか | 担当部門、手順、現行システム |
| 問題 | どの場面で、どのような手戻りが起きますか | 発生場面、頻度の確認状況、影響 |
| 目標 | 導入後、何が変われば改善したと判断できますか | 期待する状態、確認方法 |
| 範囲 | 今回変えたい範囲と、維持したい範囲はどこですか | 対象業務、対象外、連携先 |
| 条件 | 利用時期や運用上、変えられない条件はありますか | 時期、利用時間、データ、制約 |
| 検討体制 | 利用部門・IT部門・決裁に関わる方は誰ですか | 役割、追加確認に必要な相手 |
| 予算・進め方 | 予算は確定していますか。比較・判断の流れはどうなっていますか | 確定/目安/未定、検討段階 |
予算が未定であれば、未定と残します。担当者の想定額を、会社として承認された予算のように扱わないことが重要です。資料の提供を依頼するときも、秘密情報を含む原本の提出を当然とせず、共有可能な範囲で確認します。
曖昧な要望は、業務の場面に戻して具体化する
「使いやすくしたい」「効率化したい」と聞いたら、評価の言葉を具体的な業務へ置き換えます。ここでは、受注入力の相談を受けた架空の場面で考えます。
顧客が「入力を効率化したい」と話した場合、すぐに「自動入力機能を付けましょう」と決めず、次の順に確認できます。
- 何の情報を、どの画面やファイルへ入力しているか。
- 同じ情報を別の場所へ入力し直しているのか、承認待ちが長いのか。
- その作業は誰が担当し、どの場面で困るのか。
- 転記をなくしたいのか、確認作業を減らしたいのか。
- 改善したことを、何を見て判断するか。
記録は、例えば次のように分けます。
| 区分 | 記入例 |
|---|---|
| 顧客の発言 | 受注情報を二つのファイルへ入力している |
| 確認済みの範囲 | 商談参加者が担当する業務についての説明。他部門は未確認 |
| 営業側の仮説 | 転記の重複を減らせる可能性がある |
| まだ確認すること | 二つのファイルが必要な理由、入力項目の差、連携できるか |
| 次の確認先 | 業務担当者と現行システムの管理者 |
この表は実際の顧客事例ではありません。「重複入力がある」から「連携で解決できる」までを一足飛びに確定しないための例です。
機能以外の条件は、技術担当と確認する
導入する機能だけでなく、その機能を使い続ける条件も整理します。IPAはシステム化要求の検討で、機能面と非機能面の両方を挙げています。非機能面の例には稼働率、応答時間、セキュリティなどがあります。IPAによるシステム化要求の整理
初回商談では、専門用語の数値を無理に回答してもらうより、業務への影響を聞き、詳細を技術担当と具体化します。次は持ち帰り方の例です。
| 顧客への確認 | 技術担当へ渡す論点 |
|---|---|
| 使えないと特に困る曜日・時間帯はあるか | 稼働時間、停止可能な時間、保守の条件 |
| 一度に利用する人や、処理が集中する時期はあるか | 想定負荷、応答時間の確認条件 |
| どの部門が、どの情報を見られる必要があるか | 認証、権限、データの分類 |
| 既存システムと受け渡しする情報は何か | 連携方式、データ形式、管理者との確認 |
| 障害時にどの業務を先に再開したいか | 復旧対象、復旧時間、戻すデータの時点 |
回答がない欄を営業の判断で補完せず、「顧客確認待ち」「技術検証が必要」と残します。実現可否、性能、費用、納期については、前提と確認担当者をそろえてから回答します。
商談後は、決まったことと宿題を分けて返す
商談の最後に、理解した課題と未確認事項を短く読み合わせます。後で議事メモを送る場合も、発言を並べるだけでなく、次の行動につながる形に整えます。
IPAの機能要件の合意形成ガイドでは、図表に記述し、漏れや矛盾を確認し、発注者と開発者が一緒にレビューする進め方を紹介しています。初回商談でも、理解した内容を相手に確認できる形へ戻す参考になります。IPA「機能要件の合意形成技法」
例えば、次回までの確認事項は以下のように残します。
| 確認事項 | 担当 | 完了の目安 |
|---|---|---|
| 現行の入力項目 | 顧客の業務担当者 | 共有可能な項目一覧を確認 |
| 既存システムの連携条件 | 顧客の管理者と技術担当 | 提案で前提にできる方式を整理 |
| 今回の対象範囲 | 顧客の検討責任者 | 対象と対象外の認識を確認 |
| 次回提案の内容 | 営業担当 | 確認済みの前提と未確定条件を添える |
実際のメモには、担当者と合意した期限も加えます。返事がないことを合意と扱わず、重要な相違が残っていれば、その点を次回の確認事項にします。
初回ヒアリングを終える基準は、質問数ではなく、次の担当者が何を確認すればよいか分かることです。まずは質問表のうち、対象業務・困っている場面・変えたい状態を準備し、確認済みの事実と仮説を分けて記録してみてください。提案から導入後までの職務全体は、IT営業の仕事内容でも整理しています。