プリセールスエンジニアとしてよくヒアリングしていることをまとめてみた
2025.03.24よくヒアリングしている内容をまとめてみた
こんにちは、のんピ(@non____97)です。
以前、Amazon FSx for NetApp ONTAP(以降FSxN)への移行相談時のヒアリング内容を以下記事にてまとめました。
FSxNと一年中戯れている人間と思われていそうな私ですが、年間30件ほどプリセールスエンジニアとしても提案活動をしています。
その中で、「案件内容や案件難易度、案件規模に関わらず、これはヒアリングしておこう」という内容がまとまってきました。
「プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで」という本に書いてある内容も多いのですが、以降紹介します。
ちなみに、この本は全員買いましょう。
書評もあります。
前提
前提です。
こちらの記載している内容の前提は以下のとおりです。
- インバウンドで問い合わせを受けて、提案をする前段階にヒアリングする内容
- 毎回全部聞くのではなく、営業メンバーが事前にヒアリングしている場合や自明な場合は割愛することもある
- ピンポイントな技術的な課題に対してのヒアリングではない
- 記載内容以外にも、プロジェクトに応じてヒアリングする内容は大きく変動する
- あくまで共通的にヒアリングする内容について言及
- 移行なら移行用、アセスメントならアセスメント用、システム開発ならシステム開発用とプロジェクトの内容によってそれぞれヒアリングする詳細は異なる
よくヒアリングしている内容
打ち合わせの場のゴール設定
まず、打ち合わせの場のゴール設定を行います。
特に複数プロジェクトが走っていたり、規模が大きい場合はとても一回の打ち合わせで終わらないことがあります。
この打ち合わせでは、どの範囲について議論し、何をゴールとするのかを事前に合意してからヒアリングを始めます。
打ち合わせの期待値を揃えるためにも必ず確認します。
プロジェクトの背景と目的、想定している手段
プロジェクトの背景と目的、想定している手段を確認します。
最初はついつい「プロジェクトの概要を教えてください。」とヒアリングしがちです。
このような問いだと、回答する側としては、とりあえず知っている情報をズラッと回答することになるでしょう。
何を目的に何を達成したいのかを把握しなければ、何を持って「プロジェクトが成功した」のか判断することができません。
そのためにプロジェクトの背景と目的を理解することが最も重要です。
重要な事柄は最初に確認しましょう。まずは以下のようなポイントでヒアリングすると良いでしょう。
- どのような目的か
- 何を達成したいのか
- なぜ達成したいのか
- 具体的に達成したい目標は何か
- 主な評価軸の例
- コスト
- パフォーマンス
- セキュリティ
- 可用性
- 運用の簡便さ
- スケジュール
- 主な評価軸の例
- その目的を達成するためにどのようなシステム、どのような取り組みを考えているのか
- なぜ、そのシステム、取り組みが必要か
- どのようなアーキテクチャを考えているか
- 構成図はあるか
- どのようなサービスを使うか
- なぜ、そのサービスを使用しているか
このタイミングで
- 目的
- 目標
- 想定している手段
の要素を確認します。
「想定している手段」も含まれていますが、これは目的と目標を整理する材料として使用します。
ヒアリングした結果、それぞれの要素が噛み合っていない場合もあり得ます。
そのまま鵜呑みにしてプロジェクトを進めると、モノが出来上がった際に「思ったのと違う」となりかねないため、丁寧に確認します。
目的を確認すると、「コンテナを導入したい」や「DRできるようにしたい」など手段が目的になっている場合もあるでしょう。そのような場合は「なぜその目的を達成したいのか」を確認すると、異なるアプローチによって実現することが正解だったりします。
このように手段から隠れた目的や目標を探って合意をしたり、手段の方向性を正したりする意味合いでも、現在想定している手段についても早めに確認します。
前提条件
プロジェクトの中で守る必要がある前提条件を確認します。
「前提条件を教えてください」だけだと、範囲が広すぎるのでいくつかの視点を交えてヒアリングすると良いでしょう。
例えば以下の要素が挙げられます。
- 機能/非機能要件
- 使用しなければならないモノ
- クラウド
- 言語
- ミドルウェア
- フレームワーク
- プロトコル
- スケジュール
- 就業場所
- コミュニケーション方法
- 契約形態
ヒアリングをする際は前提条件の調整が可能かも確認します。
「前提条件として挙げたものの実は調整は可能です。」といったこともままあります。
以下も踏まえてヒアリングすると、後々プロジェクト開始後の交渉をする際にスムーズに調整を行えるでしょう。
- 条件の温度感
- 必須なのか、努力義務なのか、「もし可能なのであれば...」レベルなのか
- その条件を設定する背景
- その条件を満たせない場合の影響
前提条件を後から変更できることは稀です。後から変更しづらい要素も早めにヒアリングしましょう。
前提条件が非現実的な場合は撤退するという判断もあり得ます。
前提条件を把握しない、もしくは前提条件を守れないにも関わらず、プロジェクトが開始してしばらくした後に「やっぱりその前提条件への対応は無理です」は双方に取って何もメリットがありません。
難しいことは難しいと素直に伝えましょう。提案書やプロジェクト計画書に前提条件に対するアプローチや、対応が難しいかもしれない場合はリスクとしてキチンと整理して書いておくのが誠実だと思います。
座組
プロジェクトメンバーおよび、連携が必要な相手はどこかを整理するために座組を確認します。
主に以下のような要素を確認します。
- 誰が
- いつ
- どのような役割として
- どの範囲に対して
- 何を担当するか
- どのようなコミュニケーションパスをとるか
特に他ベンダーやヒアリング相手の組織の他チームも入る場合は念入りに確認しましょう。
ここでヒアリングする内容は役割分担の材料にもなります。自身が提案する範囲や、調整が必要な人数にも大きく影響があるでしょう。
「何を担当するか」は特に抜け漏れが無いように意識します。
- 要件定義
- 設計
- 構築
- テスト
- 運用
レベルだと粒度が甘いことがあります。作成するリソースレベルや環境レベルで担当者が変わったり、「セキュリティ」といった横串で全体を見る役割のメンバーも存在し得ます。
簡単にプロジェクト体制図や役割分担表、RASICチャートのようなものを画面投影しながら作り上げても良いでしょう。
プロジェクトのステークホルダー
座組と関連してステークホルダーも確認します。
ヒアリング相手の組織内で調整する相手および、どのような利害が発生するのかを確認します。特に大規模な提案の場合、相手社内の調整難航する場合があります。
整理する際の視点は以下の2つです。
- ポジション
- 例
- 決済者
- PM/PL
- 設計/構築の担当者
- テスター
- 運用者
- 利用者
- 関連するプロジェクトのPM/PL
- 例
- 損得が発生する場面
ステークホルダーが整理されていると、調整が必要となった場面でスピーディな調整が行いやすいです。
場合によってはプロジェクトの定例に参加いただくアプローチも取れるでしょう。
利害関係者と調整が必要になる場面があることを伝え、事前に関係性を整理してもらいましょう。
プロジェクト体制関連については以下記事も参考になります。
プロジェクトの意思決定者
プロジェクトで誰が意思決定者なのかを事前に確認します。
正しく認識していない場合、プロジェクトの打ち合わせに普段参加されていない方からの鶴の一声でちゃぶ台をひっくり返されることも稀にあります。
意思決定の方に適切なインプットをするために打ち合わせに参加いただくことも検討しましょう。
また、プロジェクトの意思決定者が重要視していることと交えて確認します。重要視していることがコストなのであればコスト、パフォーマンスなのであればパフォーマンス、実績であれば過去事例の紹介を提案書に盛り込むというアプローチも可能です。
なお、組織やプロジェクト規模が大きい場合、分野によって意思決定者が異なる場合もあります。
予算と稟議
予算と稟議周りについて以下要素を確認します。
- ランニングコストはどの程度を想定しているか
- そのランニングコストの算出スパンはどの程度か
- 月額なのか
- 年額なのか
- 5年なのか
- イニシャルコストはどの程度を想定しているか
- ランニングコスト、イニシャルコストについて予算取りをしているか
- 既にある予算の超過が見込まれる場合、どのような調整が必要か
- 検討の余地がなくなるレベルの金額はどの程度からか
- 稟議を回すハードルが高くなる金額はどの程度からか
- 稟議を回すのにかかる時間はどの程度か
- 金額ごとに変わるのであれば、その金額も
あまりにも想定と見積もりした金額が離れている場合は、スコープや要件などを調整することになります。
なお、「どのぐらいでできると嬉しいですか?」と聞きがちですが、オススメしません。
安ければ安いに越したことはないですし、聞いた手前それを超過する金額を提案で出しづらいように感じます。
スコープや要件を調整することなく、相手方の予算に合わせに行った金額を提示するとプロジェクトが失敗する確率は上がってしまうでしょう。
稟議についても確認しているのは発注いただく際にかかる時間を把握するためです。数ヶ月かかるようであればプロジェクトの開始時期に影響しますし、追加発注をいただく前提の場合はその見積もりをいつまでに提示しなければならないのかの目安にもなります。
スケジュール
スケジュールについて以下のような内容を確認します。
- プロジェクト全体の期間はどの程度を想定しているか
- 依頼したい範囲は、どの程度の期間を想定しているか
- その期間内に対応が必要な内容は何か、どのような状態になっている必要があるか
- プロジェクトのハードリミットはあるか
- どのような理由からハードリミットになっているか
- PoC完了や中間報告、判定会などプロジェクトのマイルストーンの目標時期はいつごろか
- 関連しているプロジェクトがある場合、そのプロジェクトと本プロジェクトが関係するマイルストーンとその時期はいつか
前提条件としてヒアリングしている場合もありますが、改めて確認します。
プロジェクト開始後に「実は関連プロジェクトがあって、そことの兼ね合いで今すぐに対応完了させて欲しい」などといったことにならないように周辺プロジェクトについても確認しておくと良いでしょう。
QCDの優先度
QCDの優先度を確認します。
今までヒアリングした前提条件の各条件や予算、コスト、スケジュール、要件の内容について、特に重要視しているポイントを優先度を付けて整理します。
追加要件が出てきた場合など何か調整ごとが発生した際に、どのような視点で調整をするのかの指標となります。
早めにQCDの優先度を合意することで、後の調整をする際に期待値のコントロールが行いやすくなります。
このタイミングで整理するのは発散してきた内容について、収束させる意味合いもあります。
現時点で気にしているポイントやリスクと感じていること
明確な懸念点やリスクおよび、漠然とした不安のようなものがあるか確認をします。
ここで上がってくることは言うなればプロジェクトの関心ごとでもあります。ヒアリングした内容は提案書にも記載して、それらに対するアプローチを整理します。
プロジェクトに悪影響を与える要素については潰せるものなら潰したいところです。解決策を知っている場合はその場で回答をすることもあります。
早期に解決することが難しい要素なのであれば、プロジェクトのリスクとして提案書に書いて、プロジェクト運営の中で適切にリスク管理を行えるようにします。
依頼したい内容、期待していること
このタイミングでようやく依頼したい内容について確認します。
確認の観点は以下のとおりです。
- 支援を通して、どのような状態になることを期待しているか
- どのようなアウトプットを望んでいるか
- そのアウトプットを望む背景
- そのアウトプットはどのように活用される想定か
- どのような役回りでプロジェクトに入ることを希望しているのか
事前に、前提条件や予算、スケジュールを把握しているのであれば、そのインプットを活かしながらヒアリングしましょう。ただし、相手からヒアリングした側から「予算的に〜」や「スケジュール的に〜」と返してしまうと、提案は前に進まないですし、回答する側からしてもあまり気分は良いものではないと考えます。
話の流れで即断すると検討の可能性も潰してしまうので、一度回答内容を受け止めてから現実的な落としどこを探っていきましょう。
ただし、達成したい目的と依頼内容がミスマッチしている場合は早めに相手に知らせてあげ、より良いアプローチについて提案すると良いでしょう。
現行環境について既に困っているポイントや改善したい箇所
既存の環境がある場合についてのヒアリングにはなりますが、現行環境について既に困っているポイントや改善したい箇所も確認します。
「困っているほどでもないけれども、ついでに直したいなど」といったこともあります。
場合によっては追加提案できる要素かもしれないので、ヒアリングしておきましょう。
提案予定のプロジェクトからの派生プロジェクトの有無
運用保守周りなど、提案予定のプロジェクトから派生するプロジェクトが発生する可能性があれば、簡単にヒアリングをします。
提案書にもネクストステップとして盛り込んでおきましょう。
支援のゴールとアウトプットの認識合わせ
これはヒアリングではないのですが、ここまででヒアリングした内容をベースに、現時点で自信が想定している支援のゴール、アウトプットの認識合わせを行います。
大作な提案書を作ってから「期待していた提案と違う」となると悲しくなります。自分がヒアリングしたことを整理する意味合いも込めて、どのような方向性の提案をするのかを事前に伝えておきましょう。
使用できそうな自社のメニューがあれば、そのメニューの概要についても簡単に触れておきます。
契約形態
請負契約や準委任契約と、契約形態について確認します。
場合によっては請負契約以外はNGといった場合もあります。
自分達が対応できる契約形態なのか把握しておきましょう。
支払いサイトと支払い方法
支払いサイトと支払い方法についても確認します。
場合によっては後からの調整では遅いこともあるため、事前に把握しておきましょう。
再委託の可否
再委託の可否について確認します。
場合によってはフリーランスのエンジニアや、グループ会社のメンバーもプロジェクトに参画する可能性もあります。
後から調整し始めると時間がかかる要素だと思うので、早めに確認しておきましょう。
提案書提出予定日の認識合わせ
提案書提出予定日の認識合わせを行います。
希望があれば、その希望も確認します。
ネクストアクションの整理
一通りのヒアリングが完了したら、最後にネクストアクションの整理をします。
- いつ
- 誰が
- 何を
を整理して合意しましょう。
意識していること
一覧
個人的にヒアリングする際に意識していることは以下のとおりです。
- まずは聞くこと
- 事実と推測を整理しながら会話すること
- ヒアリング内容は回答者のバックボーンと話の展開の流れの意識すること
- 「ここはリスクかもしれない」という自分の直感を信じること
- 問題を先延ばしにしないこと
- 自分がPMの立場として、最終的に責任を持つ意識でヒアリングすること
まずは聞くこと
まずは、聞きましょう。
自身が提供しているサービスや支援実績紹介は二の次です。目的を達成する = プロジェクトを成功させるためにはまずは情報収集をして、どのような状況にいるのかを把握をします。
もちろん、相手が求めている or 求めていそうであれば、サービスを売り込むのはアリです。
事実と推測を整理しながら会話すること
回答は場合によっては不正確なことがあります。特にインパクトが大きい要素については、それが事実なのか、推測なのかを整理しながらヒアリングしましょう。
場合によっては事前に「このような内容についてヒアリングしますよ」と共有をしておくと、相手方も整理して回答できるでしょう。
これは自分が打ち合わせで回答する立場の時もそうです。不確実な情報や自信がない場合は正直に「100%の事実ではないこと」を伝えて回答しましょう。
ヒアリング内容は回答者のバックボーンと話の展開の流れの意識すること
ヒアリングをするにあたって、多くの質問を投げかけることになります。難しい用語を交えた質問は答える側からすると疲れてしますし、特にオープンクエスチョンの場合は「何でこんなこと聞くんだろう」と、意図も分からないことについて答えるのは不安に感じます。
少しでも回答者のストレスを軽減するために、回答者のバックボーンと展開を意識しながらヒアリングをしましょう。
展開がぶつ切りになってしまう場合はヒアリングする意図も添えましょう。
「ここはリスクかもしれない」という自分の直感を信じること
だいたい悪い事柄への直感は当たります。
その悪い事柄への直感が顕在化し、プロジェクトに悪影響を及ぼさないように早め早めに行動します。
直感が外れたらラッキーです。杞憂で済んで良かったですね。ただ、それは運です。運に自分の仕事の出来を任せすぎないようにしましょう。
問題を先延ばしにしないこと
早く行動しましょう。
問題を先延ばしにしたことによって取り返しがつかなくなるケースもあります。
早く行動しましょう。
自分がPMの立場として、最終的に責任を持つ意識でヒアリングすること
色々ヒアリング内容の例を紹介しましたが、結局は「自分がPMの立場として、最終的に責任を持つ」という気持ちで望めば、自ずとヒアリングしたいことはたくさん出てくると思います。
プロジェクトの成功につながるヒアリングを行おう
私がプリセールスエンジニアとしてよくヒアリングしていることをまとめてみました。
「こんなこともよくヒアリングしている」などあれば、ぜひ教えてください。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
