最終更新日 2024年12月20日
重要な打ち合わせや個別の検討会で、顧客からの質問に的確に答えられないエンジニアは意外と多い
ITインフラ系のプロジェクトでは、技術検討会や重要な打ち合わせで顧客と会話することはよくありますが、その際、顧客の質問にしっかりと答えることが大切です。
質問に対して適切に答えられないと、顧客との信頼関係に悪影響を及ぼす可能性があるからです。
しかし、顧客の質問に的確に答えるのはなかなか簡単ではありません。
多くのエンジニアが、技術検討会や重要な打ち合わせでの質問に対して意図を正確に読み取れなかったり、回答がずれてしまったり、曖昧な表現で顧客を混乱させてしまうことがあります。
その結果、顧客とのコミュニケーションにおいて問題が生じることも少なくありません。
X(旧Twitter)では以下のような投稿されていました。
このような投稿がされていることからも、顧客からの質問に的確に回答することに苦戦している人が多いことが分かります。
顧客の質問に分かりやすく的確に回答できるようになるために必要なポイント14選とは？
まず、私がインフラエンジニア(PM)として現場で実践している、技術検討会等の重要な場面で顧客から質問を受けた際、的確に回答するための考え方やポイント14選を伝授します。
ポイントを確認して、自分に足りないところを認識して改善していきましょう。
- 結論から回答する
- 前提や経緯を前置きする
- いくつの観点で回答するか最初に述べる
- 想定される質問の回答を準備する
- 目的について事前に確認する
- 理由は何なのか事前に確認する
- ネクストアクションについて事前に確認する
- 事実と解釈をごっちゃにしないこと
- 相手が知りたいことを回答すること
- 上手い言い回しで伝えること
- 確定情報のみを回答すること
- 細かく想定を考える
- 回答までの時間稼ぎをする
- 持ち帰る
結論から回答する
これはインフラエンジニア(PM)だけではないかもしれませんが、技術検討会等の重要な場面で質問を受けた際は、基本的には結論から答えるようにしましょう。
結論から答えるのは、その方が質問相手が分かりやすいからです。
ちなみに結論の意味は以下の通りです。
１ 考えたり論じたりして最終的な判断をまとめること。また、その内容。「調査の—を出す
結論（けつろん）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
２ 論理学で、推論において前提から導き出された判断。終結。断案。⇔前提。
質問に対して結論から答えると分かりやすい理由は、相手が最初に一番重要な情報を得られるからです。質問者は、結論を先に回答してもらうことで、全体の話の流れが見えやすくなり、後続の詳細や理由付けがの内容をスムーズに理解できます。
結論から回答した場合としなかった場合を比較してみましょう。
以下は実際に私が顧客から受けた質問です。
質問：
このシステムですが、パフォーマンスがあまり出ていませんが、この問題は解決できそうですか？
回答：
はい、このシステムのパフォーマンス問題は解決可能だと考えています。
問題の原因はデータベースクエリの最適化不足であるため、改善策としてインデックスの見直しとキャッシュの導入を考えています。
このように、結論(解決できるかできないか)を先に回答することで、その後の話は、解決に向けたの問題の原因や対策の話なんだろうなと予想しながら話を聞くことができます。
一方、結論を後回しにして回答した場合はどうでしょうか。
質問：
このシステムですが、パフォーマンスがあまり出ていませんが、この問題は解決できそうですか？
回答：
現在、データベースクエリの処理に時間がかかっており、インデックスの最適化が不足しています。また、キャッシュを利用していないことが原因でパフォーマンスが低下しています。そのため、これらの対策を行うことでパフォーマンス問題は解決できる見込みです。
上記の例だと、問題点の説明から始まるため、結論にたどり着くまでに時間がかかり、聞き手は「解決できるかどうか」を知るために最後まで待つ必要があります。
待つ間はどっちなんだろうと考えながら話を聞くことになり、何が言いたいのか最後まで分かりません。最終的には回答をもらえるものの、前置きが長くなかなか回答をもらえないので顧客のフラストレーションが溜まってしまいます。
上記のように結論から回答することで、話の全体像が分かり、そのあとどのような話が続くのか予想可能になり、結果、スムーズに話の流れを理解することできます。
特にITインフラのプロジェクトで技術的な質問をされた場合、話がややこしくなったり、複雑な説明が必要になる場合が多いので、必ず結論(最終的な判断)から回答するようにしましょう。
実際に現場の定例会で問い合わせがあった質問
①ネットワーク帯域についての質問
質問：
このネットワークが遅い原因は何ですか？
回答：
原因はルーターの帯域不足です。特定の時間帯にトラフィックが集中し、最大帯域を超えていることがログで確認されました。
解決策として、ルーターを上位モデルに置き換えるか、トラフィック分散のためにルーティングを再構成することを提案します。
②サーバー障害についての質問
質問：
サーバーが応答しなくなった理由は何ですか？
回答：
原因はディスクの容量不足です。ログファイルが増えすぎてディスクがフルになり、OSが動作しなくなっていました。
ログのローテーション設定を適切に行うか、ストレージ容量を増加させることで再発を防ぐことが可能です。
③障害復旧についての質問
質問：
システムが停止した際、最初に何を確認すれば良いですか？
回答：
最初に電源とネットワーク接続を確認してください。電源とネットワーク接続が原因であることがほとんどです。
その後念のため、ログを調査してエラーメッセージを確認してください。
前提や経緯を前置きする
質問に対する回答をする際、前提や経緯の前置きが必要なケースがあります。下記のケースに当てはまる場合は、回答する前に、前提、経緯について補足しましょう。
ちなみに前提と経緯の意味は以下になります。
１ ある物事が成り立つための、前置きとなる条件。「匿名を—に情報を提供する」「結婚を—につきあう」
前提（ぜんてい）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
２ 論理学で、推論において結論が導き出される根拠となる判断。⇔結論。
物事のこみいった事情。事件の経過。「これまでの—を語る」
経緯（いきさつ）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
質問の前提が誤っている時
質問してきている相手があまり状況を理解できていないと思われる時は、質問に対する回答が相手の中で成り立つように状況や経緯を最初に補足しましょう。
たまに定例会に参加したりする人がいきなり質問してくるケースなどに、状況を簡単に前置きしてから回答します。
実際に現場の定例会で問い合わせがあった質問(前提を補足するとよい例)
①非推奨な設定値についての質問
質問：
なぜメーカーで非推奨なのにこの設定を入れているのですか？
前提を前置きする場合の回答:
回答にあたりまず前提から補足させていただきますと、現在の環境ではこの設定は非推奨ではありません。非推奨となるのはある特定の環境化でこの設定を入れたときのみです。
その上での回答となりますが、こちらの設定値に関してはディスクのデフラグを防ぐために入れさせていただいております。
上記の良い例は、前提(そもそも非推奨ではない)⇒回答の順に説明しています。文頭で何について話すかを最初に明示することで、聞き手が迷子にならないようにしています。
質問：
なぜメーカーで非推奨なのにこの設定を入れているのですか？
好ましくない回答(結論から回答した場合):
こちらの設定値に関してはディスクのデフラグを防ぐために入れさせていただいております。
そもそもですが、現在の環境ではこの設定は非推奨ではありません。非推奨となるのはある特定の環境化でこの設定を入れたときのみです。
上記の例では結論から回答していますが、この場合、質問の前提が間違っていると、そのまま誤った前提に基づいた結論を伝えてしまうことになります。その結果、顧客が結論を誤解してしまう可能性があります。
さらに、後から前提が間違っていることを指摘した場合、最初に伝えた結論が正しく理解されていないと、顧客が再度解釈し直さなければならず、混乱を招く恐れがあります。
理想は理解に躓くことなくスムーズに話を聞けることです。
上記の悪い例の場合は、その後の説明で理解できるかもしれませんが、説明の順番が良くないため、一度理解につまずきます。説明した内容の中で聞き手が話の内容の理解に一度でも躓くと説明がわかりにくい人と思われてしまいます。
このように、結論を理解するために必要な前提を質問者が十分理解していない場合や誤った理解をしている場合、結論から回答しても理解できないことがあります。その場合は、結論を理解するために必要な状況や経緯を前段として補足するとスムーズに理解できます。
相手が話について来れていない時
会議の中で相手が話について来れてないなかで質問をしてきた場合は、まず状況を簡潔に整理してあげてから回答するようにしましょう。
例えば、質問内容がおかしな内容になっているときです。
技術的背景が理解できてない上で質問してきているケースが多いです。状況を整理してあげないとその後の回答内容が理解できず、再度説明し直しになったりする場合もあり、手戻りになります。
定例会は時間が限られているため、こうした手戻りは無くしたいところです。
実際に現場の定例会で問い合わせがあった質問(まず状況を整理してから話すと良い例)
①ある課題に対して進捗を確認された場合
質問：
この●●の課題ですが、進捗があまり追えていなくて申し訳ないのですが、現在どのような状況でしょうか。
状況を整理してから回答:
こちらの課題は、一部の通信がファイアウォールで意図せずブロックされているという課題です。事象の原因解析に加え、お客様からのご要望により3つほどメーカーへ問い合わせを実施しておりました。
現在のステータスとしては、メーカーからの回答を踏まえ、事象の原因解析を行っております。
上記は課題の発端とこれまでの進捗について簡潔に回答した上で、現在のステータスを回答しています。このように回答することで、質問に対する回答である現在のステータスについて誤解なく理解することができます。
このように、顧客が状況を理解していない場合はまず状況から補足してあげると無理なく理解することができます。
回答内容に条件や制約がある時
質問に回答する際、その回答が特定の条件で成り立つときや、制約があるときは、前提として最初に補足すると相手は理解しやすいです。
制約や前提を先に述べることで、誤解や行き違いを防げます。特にインフラエンジニアでは、技術的な内容や専門的なことを議論する場合、前提が異なると全く別の結論になってしまうことがよくあります。
また、補足を最初にすることで、相手がその回答の背後にある論理や理由を理解しやすくなります。このため、回答全体の内容が頭に入りやすく、結果的に相手の納得感も高まります。
例えば、中小企業におけるコストの対策について説明する時であれば、「この対策は中小企業に向けたもので、コストの面から考えて大企業には適さない可能性がある」と前置きすれば、その説明が中小企業向けに限った説明と分かります。
条件を絞った説明であることがわかるため、誤った理解(大企業にも当てはめられる説明として理解するなど)も防ぐことができます。
実際に現場の定例会で問い合わせがあった質問(条件や制約を前置きする場合)
①サーバー更改に関する質問
質問：
新システムの稼働に際して、現行のサーバーを引き続き利用したいと考えていますが、スペック的に対応可能でしょうか？
回答(前提として条件を明示する)：
現在の利用状況と新システムの推定負荷がほぼ同等であるという前提でお答えします。その場合、現行サーバーで対応可能と考えられます。ただし、処理件数が大幅に増加する場合や、高度なセキュリティ対策が追加される場合には、サーバーのスペックを増強する必要が出てくる可能性があります。
②ファイル共有システムの導入に関する質問
質問：
新しいファイル共有システムの導入に際して、現在使用中のファイルサーバーのデータ移行を検討しています。移行するファイル数が多くなる見込みですが、年内にどれくらいのファイルを移行できるか見通しを教えていただけますか？
回答(前提として条件を明示する)：
現在の移行計画で、11月中に移行元のデータ整理が完了するという前提でお答えいたします。その場合、年内に最大50TB分のデータ移行が可能です。それ以上の容量となる場合は、データを段階的に移行するスケジュールについて、改めて調整させていただきます。
背景知識の補足が必要な時
人によって解釈が異なる言葉や、曖昧な表現、専門用語については、最初にその言葉の意味や定義を説明してから回答することで、誤解を防ぎ、相手に正しく理解してもらうことができます。
例えば、「Microsoftのセキュリティグループ」という言葉には異なる解釈がありえます。セキュリティグループが、ただの静的なグループを指している場合もあれば、メール機能が有効なグループを含むこともあります。
このように、何を指しているかが曖昧な場合は、最初にその言葉の意味をはっきりさせることが大切です。
実際に現場の定例会で問い合わせがあった質問(言葉の定義を前置きする場合)
①セキュリティグループの一括登録に関する質問
質問：
Microsoft365におけるセキュリティグループを大量に複数作成していただきたいのですが、スクリプト等で一括作成は可能でしょうか。
回答(言葉の定義を前置きする場合)：
おっしゃっているセキュリティグループが、静的なセキュリティグループとメールが有効なセキュリティグループである前提で回答いたします。
その場合、利用させていただいているAzureADモジュールを使用して一括登録が可能となります。しかし、動的グループは作成できないため、その場合別のモジュールを検討する必要があります。
いくつの観点で回答するか最初に述べる
質問に対する回答で複数の回答がある場合は、回答する前に「●●●と▲▲▲と■■■の3つの観点で～～」といくつの観点での回答になるか先に話した方が分かりやすいです。
最初に回答の枠組みを示すことで、どのように話が進むのか相手が把握できます。
回答が構造化されていると、聞き手は話の流れを追いやすく、全体像を理解しやすくなります。
また、聞き手は頭の中でそれぞれのポイントを整理しやすくなり、理解が深まります。
結果、複雑な情報でもスムーズに理解できしやすくなります。
実際に現場の定例会で問い合わせがあった質問
①後継のネットワーク機器の検討状況の確認
質問：
現在使用しているネットワーク機器がEOLになり、リプレイスが必要になりますが、後継の機器としてどのような製品で検討されていますか？
回答(前提として条件を明示する)：
現在3つの製品に絞り検討しています。
1つ目が、Cisco Catalyst 9000シリーズ、2つ目がJuniper Networks EXシリーズ、3つ目がArista Networks 7000シリーズです。
それぞれ独自の機能を持っていますが、現在使用してるのが、CiscoのCatalystであるため、同様のCisco Catalyst 9000シリーズで考えています。
②インシデント対応状況の確認
質問：
先日のインシデントについて現在確認中とのことですが、何を確認されているのですか？
回答(前提として条件を明示する)：
現在2つの観点でサポートに確認をしております。
1つ目が、今回のエラーログは何が原因で出力されるか考えられる可能性を、RHELに確認しております。
2つ目に、今回のエラー出力により本作業の完了が遅れる可能性がございますが、後続作業への影響を念のため確認しております。
想定される質問の回答を事前に準備し、その回答内容を自分で十分に理解する
顧客と会話する前に、事前に質問されそうなことを整理し、回答を用意しておくことをお勧めします。
あらかじめ回答を用意しておけば、定例会で突然質問されても慌てずに対応できます。
逆に、予想外の質問や十分に考えていない観点からの質問が飛んでくると、どうしても誤った回答をしがちです。
また、会話の際、聞かれる可能性がある質問は自分で納得できるまで確認・理解しましょう。
理解度のレベル的には相手に自分の言葉で説明できるレベルまで持っていく必要があります。
なぜなら、自分では理解していても、相手に説明できなければ、その質問に対して回答できないからです。質問に回答できるレベルまで落とし込むには、自分の言葉で説明できるレベルまで持っていく必要があります。
例えば、ネットワークの業務でVlan の設定変更をするのであれば、Vlanでネットワークを論理的に分割とはどういうことか、サーバー系の業務で脆弱性対処のためにパッチ適用をするのであれば、その脆弱性はどのようなもので、今のままだと具体的にどのような影響があるのかなどです。
文字で読んで理解したで終わらせるのではなく、自分の言葉で相手に説明できるレベルまで落とし込みましょう。
目的は何か
技術的なことや作業に関する質問など、何らかの目的が絡むことが定例会の議題となっている場合は、必ずその目的を確認して答えられるようにしましょう。
理由は2つあります。
1つ目の理由は、ITインフラのプロジェクトでプロジェクトマネージャーとして働いていると、目的や意図を頻繁に聞かれるためです。例えば、「この製品のこの機能は何のためにあるのか」「この作業は何のためにするのか」といった質問を受けることがよくあります。
2つ目の理由は、目的を組み込んだ回答の方がわかりやすいからです。複雑な技術に関する質問の場合、その技術が何のために存在するのかを前置きしてから回答すると、背景を理解しやすくなり、聞き手がより納得しやすくなります。
例えば、業務用端末に割り当てるIPアドレスの払い出しを依頼され、「管理用ネットワークのセグメントを割り当ててください」と言われたとします。
この場合、「管理用ネットワークセグメントに業務用端末を割り当てられません」と答えるだけでは、相手に理解してもらえないかもしれません。それは、セグメントを分けている目的が伝わっていないからです。
そこで、次のように回答を組み立てると良いでしょう。
「管理用セグメントのIPアドレスは、ネットワーク機器にアクセスさせないために分けられているため、業務用端末に管理用ネットワークセグメントのIPアドレスを割り当てることはお勧めできません。」
このように、目的を含めて説明することで、相手により理解してもらいやすくなります。
質問に対する回答を準備するときは、その作業はそもそも何ために行なっているのか、その技術は何を目的としているのかなど目的を確認するようにしましょう。
当方では重要な定例会に臨む前に以下のような観点で目的の確認をしています。
- 資料の目的(何のための資料か)
- 作業の目的(何のために作業を行うのか)
- 技術の目的(どのようなことを実現する目的の技術なのか)
最後に目的の意味について補足ですが、目的は、何かをする際に「目指す結果」や「達成したいこと」を指します。つまり、「なぜそれをするのか」という最終的な目標です。
１ 実現しようとしてめざす事柄。行動のねらい。めあて。「当初の—を達成する」「—にかなう」「旅行の—」
２ 倫理学で、理性ないし意志が、行為に先だって行為を規定し、方向づけるもの。
目的（もくてき）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
理由は何か
定例会で話題に上がる内容については、事前に理由を確認しておきましょう。
例えば、顧客に作業を依頼する場合は、「なぜその作業が必要なのか」「顧客がなぜ行わなければならないのか」といった理由を明確にしておくことが大切です。
ITインフラのプロジェクトでプロジェクトマネージャーとして働いていると、顧客から理由を詳しく聞かれることが多いです。そのため、定例会で議題になる内容については、できる限り理由を確認して準備しておきましょう。
当方では重要な定例会に臨む前や顧客と会話する前に、以下のような観点で理由の確認をしています。
- その作業が必要になる理由
- 作業を依頼する場合は依頼しなければいけない理由(依頼する側で対応できない理由)
- その設定変更を行う理由(なぜその設定が必要なのか)
- 作業をその時期に行う理由
- 作業を延期できない理由(後続タスクとの兼ね合い等)
- そのコマンドを使用する理由
念のため理由の意味について補足します。
理由は、「なぜそれをする必要があるのか」や「なぜそのような結果になったのか」を説明するものです。つまり、行動や出来事の背景や根拠を指します。
１ 物事がそうなった、また物事をそのように判断した根拠。わけ。子細 (しさい) 。事情。「健康上の—で辞職する」
２ いいわけ。口実。「風邪を—に休む」
３ 哲学で、論理的関係においては結論に対する前提、実在的関係においては結果に対する原因。根拠。⇔帰結。
例: 「この作業を行う理由は、負荷が増大してシステムが不安定になったからです。」
目的と理由を混同する人が多いですが、、「目的」は目指しているゴール、「理由」はそのゴールを目指す必要性や動機です。
ネクストアクションを確認する
顧客とは会話する前や、定例会等で議題を確認する際は、次に何をすべきか、いわゆる「ネクストアクション」を合わせて確認するようにしましょう。この「ネクストアクション」とは、次に誰が何をするのかを明確にすることを指します。
例えば、通信障害が発生し、その原因の確認が完了した場合、定例会でその報告をするだけでは不十分です。次に誰がどのような対応を行うのかを具体的に決めておく必要があります。特に、何らかの課題に取り組んでいる場合は、次の行動が不明確だと課題の解決が進まなくなるリスクがあります。
さらに、対応する課題の数が増えたり、内容が複雑になったりすると、複数の対応が同時並行で進むことがあります。そのような状況では、次の行動を明確にしておかなければ、混乱が生じ、全体の進行が停滞してしまいます。
また、厳しい顧客は定例会の場で必ず「次に誰が何をするのか」を確認してきます。そのため、議題に関する「ネクストアクション」を事前にしっかり整理しておくことが重要です。定例会をスムーズに進めるためにも、この準備を怠らないようにしましょう。
回答する際は事実と解釈を分けよう
事実と解釈は、明確に分けて回答する必要があります。
その理由は、解釈をあたかも事実のように伝えると、顧客を誤解させてしまい、結果的に誤った判断や行動を引き起こす可能性があるからです。
特に、顧客が判断の材料として質問している場合、解釈を事実のように伝えてしまうと、それが前提となって誤った決断を下し、後に大きな問題に発展する恐れがあります。
たとえば、ネットワーク障害が発生した際、自分の見立てで「プロキシが原因かもしれない」と考えたとします。このとき、顧客から「原因は何ですか？」と質問された場合に「プロキシが原因です」と断定的に答えてしまうと、顧客はその情報を事実と受け取り、「障害の原因はプロキシだ」と上長や関係者に報告する可能性があります。
しかし、後から原因がプロキシではなく他のネットワーク機器であると判明した場合、顧客は再度報告を修正しなければならず、大きな手戻りや時間の無駄が生じます。
さらに、顧客からの信頼を損ねるリスクもあります。
このような事態を避けるためには、事実と解釈を明確に分けて伝える必要があります、先ほどの例であれば、次のように回答すると良いと思います。
「事実として、プロキシのログを確認したところ◯◯というエラーが記録されていました。このため、障害の原因はプロキシの可能性があると考えています。」
このように、事実を明確に伝えた上で、自分の解釈や推測を付け加えることで、顧客は誤解せず、適切な判断材料を下に判断ができます。
ITインフラの業界では、〜と思われます。や、〜と考えます。という言い回しがよく使われますが、これは解釈であり事実でないどういうことを明確にするために使っています。
相手が知りたいことを回答すること
定例会で回答する際は、相手が知りたいことに的確に答えることを意識しましょう。
自分の立場を守るための言い訳を含めるのはなるべくやめましょう。
なぜなら、相手が求めていない情報を伝えても、時間の無駄になるからです。
顧客からの質問が自分の得意分野に関するものであれば、つい詳しく話したくなるかもしれませんが、聞かれていることに絞って回答し、相手が知りたい情報だけを簡潔に伝えるようにしましょう。
ただし、回答内容を相手に正確に理解してもらうために、背景情報や経緯を簡潔に説明に加えることは必要です。
特に自分の立場を守るための言い訳はやめましょう。言い訳は話が長くなりがちで、なおかつ相手が求めている情報ではないことが多いため、不要な情報として捉えられることがあります。
上手い言い回しで伝えること
定例会などで顧客からの質問に回答する際は、できるだけ簡潔で伝わりやすい上手い表現を心がけましょう。説明が長くなるよりも、短くわかりやすくまとめた方が相手に伝わりやすくなります。
例えば、製品AでサービスAの動作を禁止する設定がされている環境があり、設定内容に考慮漏れがあり、サービスAだけでなく、サービスBの動作も禁止されていたとします。その状態でサービスBを使用して作業を実施したところ、製品Aの設定によりサービスBが使えなかったケースを想定します。この状況を顧客に報告する際、
「調査したところ、製品AでサービスAの動作を禁止する設定がされておりますが、その設定の〇〇の部分〇〇という値が設定されており、その値によりサービスBも含まれてしまう設定となり、結果、今回の作業時にサービスBが利用できなくなっていました。」
と長く説明するよりも、
「サービスAの動作を禁止する設定が既存の環境にあり、その設定に巻き込まれる形で意図せずサービスBも動作が禁止されていたことが原因でした。」
といった形で、「意図せず巻き込まれた」と表現する方がシンプルで伝わりやすくなります。
このように、少ない文字数で要点を押さえた説明で、相手により明確に内容を伝えられるように意識しましょう。
確定情報のみを回答すること
定例会などで顧客から質問を受けた際は、できるだけ確定した情報のみを伝えるようにしましょう。
未確定な情報を伝えると、話が不要に広がったり、顧客を混乱させてしまう恐れがあります。
場合によっては、追加で説明資料の作成を求められるなど、余計なタスクが発生することもあります。
例えば、メールが止まってしまった際、顧客から原因を尋ねられたとします。この時点で原因が特定できておらず、A、B、Cの3つの可能性がある状況だとします。
この場合に、「原因は調査中ですが、可能性としてA、B、Cが考えられます」と回答してしまうと、もし最終的に別の原因だった場合、A、B、Cがなぜ違うのか、また本当に無関係かといった追加調査や資料作成を求められる可能性があります。
一方で、この状況で「原因は現在調査中です」とだけ回答し、原因が特定できた段階で報告していれば、このような余計なタスクや時間の浪費は防げます。
このように、顧客を混乱させたり、無駄なタスクを増やさないためにも、確定情報のみを伝えることを意識しましょう。
回答までの時間稼ぎをする
即答が難しい場合は、まず相手の質問をおうむ返しで確認しましょう。おうむ返しをすることで、質問を再確認する時間ができ、回答を考える余裕が生まれます。
また、質問を聞き返すことで相手が質問の意図や背景をさらに詳しく説明してくれることもあります。
例えば、「この作業が延期になった場合、どのようなリスクがありますか？」と聞かれた際には、
「ご質問は、今回の〇〇作業が延期になった場合にどのような影響やリスクがあるか、という内容で間違いないでしょうか？」
と返します。
このように、即答が難しい場合は、まず質問をおうむ返しで確認することを意識しましょう。
質問の回答を持ち帰る
即答が難しい場合は、「持ち帰って確認します」と冷静に伝えましょう。
誤った情報を伝えたり慌てたりするよりも、確認の時間をいただく方が、顧客にも安心感を与えます。
特に、作業日程の延期などの相談は、後続タスクや他の作業との関連性があり、影響が大きい場合があります。その場で判断を下すのはリスクが高いため、一度持ち帰って検討する方が安全です。
また、その場での回答など十分な時間をかけて考えられない空中戦では、重要な内容や影響の大きい内容については「確認して改めてお伝えします」と伝え、慎重に対応するようにしましょう。
顧客からの質問に的確に回答できることの重要性
顧客からの質問に対して的確に回答できることは非常に重要です。
理由は信頼関係を築き、プロジェクトをスムーズに進めるために必要不可欠なスキルだからです。
顧客はPMやエンジニアに対して技術的な専門知識を期待しています。
質問に対してすぐに正確な答えが返ってくることで、顧客は「この人に任せれば安心だ」と感じ、信頼を勝ち取れます。
信頼関係がしっかりと築かれていれば、プロジェクトが複雑になったり問題が発生したりしても、顧客が炎上しません。
また、的確な回答をすることで、顧客が持つ不安や疑問を早い段階で解消できるため、プロジェクト全体の進行がスムーズになります。
例えば、依存関係や優先順位について明確に説明することで、顧客はどのタスクに注力すべきかを理解し、効率的な作業が可能になります。結果、後々の手戻りやトラブルを防ぐことができ、結果的にプロジェクトの成功につながります。
逆に、曖昧な回答や即答できない状況が続くと、顧客は不安を感じ、プロジェクトに対する不信感を持つことになります。
そのため、日頃から情報を整理し、顧客からの質問に迅速かつ的確に答えられるよう準備しておくことが重要です。
的確な回答を通して顧客との信頼を築き、スムーズなプロジェクト進行を実現することが、エンジニアとしての価値を高める重要な要素です。
ゴリタン
インフラエンジニアとして、ネットワークとサーバーの運用・保守・構築・設計に幅広く携わり、
現在は大規模政府公共データの移行プロジェクトを担当。
CCNPやLPICレベル3、AWSセキュリティスペシャリストなどの資格を保有しています。