最終更新日 2024年11月21日
インフラエンジニアとして働いていて、定例会での顧客からの質問に回答してもよくわからないと言われてしまう。。。的確に回答できない。。。
インフラエンジニアとして働いていると、定例会等で顧客に進捗を報告する機会が多くあると思いますが、その際、質問に的確に回答できるかが重要になります。
なぜなら、顧客からの質問や問いに的確に回答できないと信用を失いかねないからです。
しかし、顧客からの質問に的確に回答するのはなかなか難しいものです。
定例会で顧客から質問を受けた際、顧客の意図が汲み取れていない回答をしたり、質問に対する回答がずれていたり、何が言いたいのか不明瞭な回答をして顧客が困惑したりと、上手く回答できない人が多いように思います。
X(旧Twitter)では以下のような投稿されていました。
このような投稿がされていることからも、顧客からの質問に的確に回答することに苦戦している人が多いことが分かります。
顧客からの質問に分かりやすく的確に回答するために実践している方法
今回の記事では、私がインフラエンジニアとして現場で実践している、定例会で顧客から質問を受けた際、的確に回答する方法を伝授します。
今回の記事では、以下4つの観点で説明します。
回答方法
まず、定例会で顧客から質問を受けた際の、回答方法について、私が実際に現場で実践している方法を伝授します。
質問を受けた際の回答方法としては下記の3つのポイントがあります。
上記の3つのポイントについて以降で順に解説していきます。
結論から回答する
これはインフラエンジニアだけではないかもしれませんが、定例会等で質問を受けた際は、基本的には結論から答えるようにしましょう。
結論から答えるのは、その方が質問相手が分かりやすいからです。
ちなみに結論の意味は以下の通りです。
１ 考えたり論じたりして最終的な判断をまとめること。また、その内容。「調査の—を出す
結論（けつろん）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
２ 論理学で、推論において前提から導き出された判断。終結。断案。⇔前提。
質問に対して結論から答えると分かりやすい理由は、相手が最初に一番重要な情報を得られるからです。質問者は、結論を先に回答してもらうことで、全体の話の流れが見えやすくなり、後続の詳細や理由付けがの内容をスムーズに理解できます。
結論から回答した場合としなかった場合を比較してみましょう。
以下は実際に私が顧客から受けた質問です。
質問：
このシステムですが、パフォーマンスがあまり出ていませんが、この問題は解決できそうですか？
回答：
はい、このシステムのパフォーマンス問題は解決可能だと考えています。
問題の原因はデータベースクエリの最適化不足であるため、改善策としてインデックスの見直しとキャッシュの導入を考えています。
このように、結論(解決できるかできないか)を先に回答することで、その後の話は、解決に向けたの問題の原因や対策の話なんだろうなと予想しながら話を聞くことができます。
一方、結論を後回しにして回答した場合はどうでしょうか。
質問：
このシステムですが、パフォーマンスがあまり出ていませんが、この問題は解決できそうですか？
回答：
現在、データベースクエリの処理に時間がかかっており、インデックスの最適化が不足しています。また、キャッシュを利用していないことが原因でパフォーマンスが低下しています。そのため、これらの対策を行うことでパフォーマンス問題は解決できる見込みです。
上記の例だと、問題点の説明から始まるため、結論にたどり着くまでに時間がかかり、聞き手は「解決できるかどうか」を知るために最後まで待つ必要があります。
待つ間はどっちなんだろうと考えながら話を聞くことになり、何が言いたいのか最後まで分かりません。最終的には回答をもらえるものの、前置きが長くなかなか回答をもらえないので顧客のフラストレーションが溜まってしまいます。
上記のように結論から回答することで、話の全体像が分かり、そのあとどのような話が続くのか予想可能になり、結果、スムーズに話の流れを理解することできます。
特にインフラエンジニアで技術的な質問をされた場合、話がややこしくなったり、複雑な説明が必要になる場合が多いので、必ず結論(最終的な判断)から回答するようにしましょう。
実際に現場の定例会で問い合わせがあった質問(結論から回答するのが良い例)
①納期の延長確認
質問：
ヒアリングシートの回答期限ですが、2週間ほど期限を延ばしてもらうことは可能でしょうか？
回答：
期限を2週間延長することは可能です。ただし、その場合、後続のネットワーク構築作業完了日も後ろ倒しになるため、ネットワーク開通日が少々遅れる可能性がございますことをご了承いただきたく存じます。
②IPアドレスの払い出し依頼
質問：
業務用端末に対して、10.1.0.0/24（管理用セグメント）のIPアドレスを割り当てることは可能でしょうか？
回答：
回答としましては、技術的には可能ですが、管理用セグメントのIPアドレスを業務用端末に割り当てることは非推奨です。
理由は、セキュリティ的に好ましくないためです。
具体的には、管理用セグメントにはネットワーク機器の管理用インターフェースが接続されており、同じセグメントのIPアドレスを割り当てた場合、それらのネットワーク機器へアクセス可能になります。結果、意図しないアクセスが可能になるため、セキュリティ面を考慮すると推奨はできません。
前提や経緯を前置きする
質問に対する回答をする際、前提や経緯の前置きが必要なケースがあります。下記のケースに当てはまる場合は、回答する前に、前提、経緯について補足しましょう。
ちなみに前提と経緯の意味は以下になります。
１ ある物事が成り立つための、前置きとなる条件。「匿名を—に情報を提供する」「結婚を—につきあう」
前提（ぜんてい）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
２ 論理学で、推論において結論が導き出される根拠となる判断。⇔結論。
物事のこみいった事情。事件の経過。「これまでの—を語る」
経緯（いきさつ）とは？ 意味・読み方・使い方をわかりやすく解説 – goo国語辞書
相手が状況をよくわかっていない時
質問してきている相手があまり状況を理解できていないと思われる時は、質問な対する回答が相手の中で成り立つように状況や経緯を最初に補足しましょう。
たまに定例会に参加したりする人がいきなり質問してくるケースなどに、状況を簡単に前置きしてから回答します。
実際に現場の定例会で問い合わせがあった質問(前提を補足するとよい例)
①非推奨のモジュール利用の経緯についての質問
質問：
そもそもなぜ今回の作業にこの非推奨のモジュールを使うことになったんですか？
前提を前置きする場合の回答:
まず前提として、アプリの仕様変更について補足しますと、想定していたモジュールの利用には専用の認証用アプリの登録が必要となる仕様変更が直近でございました。
その上での質問の回答となりますが、御社のセキュリティチームへアプリの登録申請や代替モジュールの模索をしましたが、前者は承認が下りず、後者は代替モジュールが他になく、結果、こちらのレガシーなモジュールを使わざるをえなかった、というのが回答となります。
上記の良い例は、前提(アプリの仕様変更)⇨回答の順に説明しています。文頭で何について話すかを最初に明示することで、聞き手が迷子にならないようにしています。
質問：
そもそもなぜ今回の作業にこの非推奨のモジュールを使うことになったんですか？
好ましくない回答(結論から回答した場合):
結論から言うと、専用の認証用アプリの登録が承認されなかったため、非推奨のモジュールを使用せざるを得なくなりました。専用のアプリについて補足すると、想定していたモジュールの利用には専用の認証用アプリの登録が必要となる仕様変更が直近でございました。そのため、御社のセキュリティチームにアプリ登録の申請を致しましたが、承認が下りず、想定していたモジュールの利用は断念することとなりました。
上記の結論から回答する場合、「前提から言うと〜得なくなりました。」の結論部分を先に説明すると、相手が状況を知らない場合、この部分の内容を理解できません。
理想は理解に躓くことなくスムーズに話を聞けることです。
上記の悪い例の場合は、その後の説明で理解できるかもしれませんが、説明の順番が良くないため、一度理解につまずきます。説明した内容の中で聞き手が話の内容の理解に一度でも躓くと説明がわかりにくい人と思われてしまいます。
このように、結論を理解するために必要な経緯や状況を質問者が十分理解していない場合、結論から回答しても理解できないことがあります。その場合は、結論を理解するために必要な状況や経緯を前段として補足するとスムーズに理解できます。
ちなみに補足となりますが、結論から先に言おうとして前提と結論をくっつけて話そうとする人もいますが、一文が長くなりすぎるのでお勧めはしません。例えば以下のような回答です。
質問：
そもそもなぜ今回の作業にこの非推奨のモジュールを使うことになったんですか？
好ましくない回答(結論と回答を1文で説明する場合):
回答としましては、想定していたモジュールに直近で仕様変更が必要となり、利用には認証用のアプリの登録が必要となりましたが、御社のセキュリティチームでこのアプリの登録の承認が下りず、代替モジュールもないことから、レガシーなモジュールを利用する判断となりました。
上記の例では、文字数が抑えられるため、一見スマートに纏まっているように見えますが、聞き手からすると、質問の回答は何なのか探しながら回答を聞くことになってしまいます。また、回答をの中に、前提の内容も詰め込まれており、一文が長くなりすぎて、結局何が言いたいのかわからない回答になっています。
相手が話について来れていない時
定例会の中で相手が話について来れてないなかで質問をしてきた場合は、まず状況を簡潔に整理してあげてから回答するようにしましょう。
例えば、質問内容がおかしな内容になっているときです。
技術的背景が理解できてない上で質問してきているケースが多いです。状況を整理してあげないとその後の回答内容が理解できず、再度説明し直しになったりする場合もあり、手戻りになります。
定例会は時間が限られているため、こうした手戻りは無くしたいところです。
回答内容に条件や制約がある時
質問に回答する際、その回答が特定の条件で成り立つときや、制約があるときは、前提として最初に補足すると相手は理解しやすいです。
制約や前提を先に述べることで、誤解や行き違いを防げます。特にインフラエンジニアでは、技術的な内容や専門的なことを議論する場合、前提が異なると全く別の結論になってしまうことがよくあります。
また、補足を最初にすることで、相手がその回答の背後にある論理や理由を理解しやすくなります。このため、回答全体の内容が頭に入りやすく、結果的に相手の納得感も高まります。
例えば、中小企業におけるコストの対策について説明する時であれば、「この対策は中小企業に向けたもので、コストの面から考えて大企業には適さない可能性がある」と前置きすれば、その説明が中小企業向けに限った説明と分かります。
条件を絞った説明であることがわかるため、誤った理解(大企業にも当てはめられる説明として理解するなど)も防ぐことができます。
実際に現場の定例会で問い合わせがあった質問(条件や制約を前置きする場合)
①ネットワーク更改に関する質問
質問：
更改後のネットワーク構成で、現行ルータの利用を考えているのですが、現行ルータでも対応可能でしょうか。
回答(前提として条件を明示する)：
ネットワーク負荷の観点でかつ、業務で発生するトラフィック量が現状からあまり変化がないという前提での回答いたします。
その場合であれば現行ルータで十分対応可能と考えております。ただし、トラフィックが急増場合や、特殊なセキュリティ要件が追加される場合には、新しいルーターが必要になる可能性がございます。
②Googleクラウドへの移行に関する質問
質問：
オンプレミスからGoogleクラウドへの移行に伴い、Google WorkspaceとManaged Google Playを利用して社員のAndroidデバイスにアプリを配布するため、ヒアリングシートで配布対象のアプリをヒアリングして頂いていると思いますが、回答期限に間に合わない状況です。
配布するアプリの数が多くなる可能性があり、年内にどれくらいの数のアプリを登録できるのか見通しを教えていただけますでしょうか？
回答(前提として条件を明示する)：
今月(10月)までにご回答いただける前提での回答となりますが、その場合、年内に100個ほどであれば登録が可能です。
それ以上の個数になる場合は、段階的に登録するなど別途調整させてください。
背景知識の補足が必要な時
人によって解釈が異なる言葉や専門用語については、最初にその言葉の意味や定義を説明してから回答することで、誤解を防ぎ、相手に正しく理解してもらうことができます。
例えば、「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つ目に、今回のエラー出力により本作業の完了が遅れる可能性がございますが、後続作業への影響を念のため確認しております。
事前準備
次は定例会の事前準備として想定される質問に対する回答を用意する際何を意識すれば良いかを記載します。
定例会に臨む前には、事前に質問されそうなことを整理し、回答を用意しておくことをお勧めします。
あらかじめ回答を用意しておけば、定例会で突然質問されても慌てずに対応できます。逆に、予想外の質問や十分に考えていない観点からの質問が飛んでくると、どうしても誤った回答をしがちです。
そのため、定例会で想定される質問には、事前に回答を準備しておきましょう。その際、次の4つのポイントを押さえておくと良いです。
ちなみにこの章で解説する内容は下記の赤枠部分になります。
目的は何か
技術的なことや作業に関する質問など、何らかの目的が絡む質問の場合は、必ずその目的を確認して答えられるようにしましょう。理由は2つあります。
1つ目の理由は、インフラエンジニアとして働いていると、目的や意図を頻繁に聞かれるためです。例えば、「この製品のこの機能は何のためにあるのか」「この作業は何のためにするのか」といった質問を受けることがよくあります。
2つ目の理由は、目的を組み込んだ回答の方がわかりやすいからです。複雑な技術に関する質問の場合、その技術が何のために存在するのかを前置きしてから回答すると、背景を理解しやすくなり、聞き手がより納得しやすくなります。
例えば、業務用端末に割り当てるIPアドレスの払い出しを依頼され、「管理用ネットワークのセグメントを割り当ててください」と言われたとします。この場合、「管理用ネットワークセグメントに業務用端末を割り当てられません」と答えるだけでは、相手に理解してもらえないかもしれません。それは、セグメントを分けている目的が伝わっていないからです。
そこで、次のように回答を組み立てると良いでしょう。
「管理用セグメントのIPアドレスは、ネットワーク機器にアクセスさせないために分けられているため、業務用端末に管理用ネットワークセグメントのIPアドレスを割り当てることはお勧めできません。」
このように、目的を含めて説明することで、相手により理解してもらいやすくなります。
質問に対する回答を準備するときは、その作業はそもそも何ために行なっているのか、その技術は何を目的としているのかなど目的を確認するようにしましょう。
当方では重要な定例会に臨む前に以下のような観点で目的の確認をしています。
・資料の目的(何のための資料か)
・作業の目的(何のために作業を行うのか)
・技術の目的(どのようなことを実現する目的の技術なのか)
目的の意味について補足ですが、目的は、何かをする際に「目指す結果」や「達成したいこと」を指します。つまり、「なぜそれをするのか」という最終的な目標です。
１ 実現しようとしてめざす事柄。行動のねらい。めあて。「当初の—を達成する」「—にかなう」「旅行の—」
２ 倫理学で、理性ないし意志が、行為に先だって行為を規定し、方向づけるもの。
理由は何か
定例会で話題に上がる内容については、事前に理由を確認しておきましょう。例えば、顧客に作業を依頼する場合は、「なぜその作業が必要なのか」「顧客がなぜ行わなければならないのか」といった理由を明確にしておくことが大切です。
インフラエンジニアとして働いていると、顧客から理由を詳しく聞かれることが多いです。そのため、定例会で議題になる内容については、できる限り理由を確認して準備しておきましょう。
当方では重要な定例会に臨む前に以下のような観点で理由の確認をしています。
・その作業が必要になる理由
・作業を依頼する場合は依頼しなければいけない理由(依頼する側で対応できない理由)
・その設定変更を行う理由(なぜその設定が必要なのか)
・作業をその時期に行う理由
・作業を延期できない理由(後続タスクとの兼ね合い等)
・そのコマンドを使用する理由
念のため理由の意味について補足します。
理由は、「なぜそれをする必要があるのか」や「なぜそのような結果になったのか」を説明するものです。つまり、行動や出来事の背景や根拠を指します。
１ 物事がそうなった、また物事をそのように判断した根拠。わけ。子細 (しさい) 。事情。「健康上の—で辞職する」
２ いいわけ。口実。「風邪を—に休む」
３ 哲学で、論理的関係においては結論に対する前提、実在的関係においては結果に対する原因。根拠。⇔帰結。
例: 「この作業を行う理由は、負荷が増大してシステムが不安定になったからです。」
目的と理由を混同する人が多いですが、、「目的」は目指しているゴール、「理由」はそのゴールを目指す必要性や動機です。
回答内容を自分で十分に理解する
定例会で聞かれる可能性がある質問は自分で納得できるまで確認・理解しましょう。理解度のレベル的には相手に自分の言葉で説明できるレベルまで持っていく必要があります。
なぜなら、自分では理解していても、相手に説明できなければ、その質問に対して回答できないからです。質問に回答できるレベルまで落とし込むには、自分の言葉で説明できるレベルまで持っていく必要があります。
例えば、ネットワークの業務でVlan の設定変更をするのであれば、Vlanでネットワークを論理的に分割とはどういうことか、サーバー系の業務で脆弱性対処のためにパッチ適用をするのであれば、その脆弱性はどのようなもので、今のままだと具体的にどのような影響があるのかなどです。
文字で読んで理解したで終わらせるのではなく、自分の言葉で相手に説明できるレベルまで落とし込みましょう。
ネクストアクション
定例会で議題を確認する際は、次に何をすべきか、いわゆる「ネクストアクション」を合わせて確認するようにしましょう。この「ネクストアクション」とは、次に誰が何をするのかを明確にすることを指します。
例えば、通信障害が発生し、その原因の確認が完了した場合、定例会でその報告をするだけでは不十分です。次に誰がどのような対応を行うのかを具体的に決めておく必要があります。特に、何らかの課題に取り組んでいる場合は、次の行動が不明確だと課題の解決が進まなくなるリスクがあります。
さらに、対応する課題の数が増えたり、内容が複雑になったりすると、複数の対応が同時並行で進むことがあります。そのような状況では、次の行動を明確にしておかなければ、混乱が生じ、全体の進行が停滞してしまいます。
また、厳しい顧客は定例会の場で必ず「次に誰が何をするのか」を確認してきます。そのため、議題に関する「ネクストアクション」を事前にしっかり整理しておくことが重要です。定例会をスムーズに進めるためにも、この準備を怠らないようにしましょう。
回答するときに意識すること
定例会で顧客から質問を受けた際に意識すべきことについて3つのポイントを記載します。これらは、私が現場で実際に実践している内容です。
回答する時に意識することについては、画像の赤枠部分です。
質問に対して回答する際に意識した方が良い3つのポイントは以下です。
事実と解釈をごっちゃにしないこと
事実と解釈は、明確に分けて回答する必要があります。
その理由は、解釈をあたかも事実のように伝えると、顧客を誤解させてしまい、結果的に誤った判断や行動を引き起こす可能性があるからです。特に、顧客が判断の材料として質問している場合、解釈を事実のように伝えてしまうと、それが前提となって誤った決断を下し、後に大きな問題に発展する恐れがあります。
たとえば、ネットワーク障害が発生した際、自分の見立てで「プロキシが原因かもしれない」と考えたとします。このとき、顧客から「原因は何ですか？」と質問された場合に「プロキシが原因です」と断定的に答えてしまうと、顧客はその情報を事実と受け取り、「障害の原因はプロキシだ」と上長や関係者に報告する可能性があります。しかし、後から原因がプロキシではなく他のネットワーク機器であると判明した場合、顧客は再度報告を修正しなければならず、大きな手戻りや時間の無駄が生じます。さらに、顧客からの信頼を損ねるリスクもあります。
このような事態を避けるためには、事実と解釈を明確に分けて伝える必要があります、先ほどの例であれば、次のように回答すると良いと思います。
「事実として、プロキシのログを確認したところ◯◯というエラーが記録されていました。このため、障害の原因はプロキシの可能性があると考えています。」
このように、事実を明確に伝えた上で、自分の解釈や推測を付け加えることで、顧客は誤解せず、適切な判断材料を下に判断ができます。
インフラエンジニアの世界では、〜と思われます。や、〜と考えます。という言い回しがよく使われますが、これは解釈であり事実でないどういうことを明確にするために使っています。
相手が知りたいことを回答すること
定例会で回答する際は、相手が知りたいことに的確に答えることを意識しましょう。自分の立場を守るための言い訳を含めるのはなるべくやめましょう。なぜなら、相手が求めていない情報を伝えても、時間の無駄になるからです。
顧客からの質問が自分の得意分野に関するものであれば、つい詳しく話したくなるかもしれませんが、聞かれていることに絞って回答し、相手が知りたい情報だけを簡潔に伝えるようにしましょう。ただし、回答内容を相手に正確に理解してもらうために、背景情報や経緯を簡潔に説明に加えることは必要です。
特に自分の立場を守るための言い訳はやめましょう。言い訳は話が長くなりがちで、なおかつ相手が求めている情報ではないことが多いため、不要な情報として捉えられることがあります。
上手い言い回しで伝えること
定例会等で顧客からの質問に回答するときは、なるべく相手に伝わりやすく簡潔な表現で伝えるようにしましょう。同じ内容を話す場合でも、説明は長くなるよりも短くて済む方が良いからです。例えば、製品AのでサービスAのある動作を禁止する設定がされている環境があったとします。
確証を持ってから回答すること
回答が即答できないとき
回答までの時間稼ぎをする
持ち帰る
作業日を延期して欲しいなどの相談は、後続タスクへの影響や他作業との関連性があり、影響が大きい場合があり、その場での決断が危険のため持ち帰ったほうが無難です。また、空中戦だとどうしても考える時間が少ないため。
顧客からの質問に的確に回答できることの重要性
インフラエンジニアとして働く中で、顧客からの質問に的確に答えることは非常に重要です。
理由は、顧客からの質問に対して正確に回答できないと、信頼を失う可能性があるからです。
例えば、顧客との打ち合わせで技術的な質問を受けたとします。
なぜその設計になっているのか、なぜ特定の作業が必要なのかといった質問に、うまく説明できなければ、「この人には頼れない・信用できない・分かっていない」と思われてしまいます。
また、回答が曖昧だと、設計や作業への不信感を招き、考慮が不十分と見なされ、クレームになってしまう場合もあります。
そのため、顧客の質問に対して的確に答えることが、信頼関係を築く上で非常に大切です。
ゴリタン
インフラエンジニアとして、ネットワークとサーバーの運用・保守・構築・設計に幅広く携わり、
現在は大規模政府公共データの移行プロジェクトを担当。
CCNPやLPICレベル3、AWSセキュリティスペシャリストなどの資格を保有しています。