見出し画像

ITエンジニアとしてコミュニケーションで意識していること〜必ずWhyを確認する〜

こんにちは、IT エンジニアのえんじびあ(@EngiBeer_)です。

僕は新卒から IT エンジニア、時には PMO として働いてきた経験を経て今 30 代に突入しているのですが、技術面だけでなくコミュニケーション面でも多くのことを学びました。

まだまだ修行中の身ではありますが、今まで学んできてこれからも意識していきたいことの一つ一つを自分の言葉でまとめることで、改めて整理したいと思い記事を書いています。

この記事では、「必ず Why を聞く」ことについてまとめていきます。

色々なシチュエーションで飛んでくる相談

IT エンジニアや PMO として働いていると、色々な人から色々な相談を受けることがあります。
例えばこんな感じです。

  1. このシステムって、こういうデータを出せたりする? by ビジネス部門

  2. この機能を追加するとしたら、どれくらいの期間(工数)でできる? by マネージャー

  3. ここの実装、上手くできないんですよね〜 by 後輩

  4. 今度の会議の資料作りが大変なんですよね〜 by 同僚

大体具体的なシチュエーションに困っていて、解決策を聞かれることが多いです。
こういった相談に対して、いつも意識して行っている流れがあります。

質問には、まず答える

まずは聞かれた質問に端的に答えます。当たり前じゃないかという感じですが、これが意外とできていない人が多い。
僕も、回答に対して制約事項や前提条件があった場合、先にそういったものから話し始めてしまうことがよくありました。

上記の例の内、相談色の強い 3.4.はさておき 1.は YES/NO で答えられる質問ですし、2.は〜ヶ月/〜人月など定量的に答えられる質問です。
それであれば、まず YES/NO や数字を答える。制約事項や前提条件がある場合は、後に続けて説明する。

これが一つ意識していることです。

一段踏み込んで、Why(目的・背景)を聞く

その次に意識していることが、合わせて必ず Why、つまり目的や背景を聞くということです。

上で 4 つの相談を例に挙げましたが、相談の文面上は What や How、つまり具体的な物事や手段について聞かれていたり、それ以前のふわっとした相談になっています。

しかしそれぞれ必ず相談の背景には目的や事情があるはずで、例に書き足すとこのようになります。

  1. このシステムって、こういうデータを出せたりする? by ビジネス部門

    1. 目的:抽出したデータから分析レポートを作成し、事業計画見直しに役立てたい

  2. この機能を追加するとしたら、どれくらいの期間(工数)でできる? by マネージャー

    1. 背景:マネージャーの先のビジネス部門から照会を受けており、回答したい。ビジネス部門は、まだ詳細な要件には落とし込むことはできていないが、この回答を元にシステム化予算を確保する予定だ

  3. ここの実装、上手くできないんですよね〜、調べてみたら、結構技術的にハードルが高くて by 後輩

    1. 目的:ビジネス部門のプラスアルファの要件のための実装

  4. 今度の会議の資料作りが大変なんですよね〜 by 同僚

    1. 背景:ソフトウェア品質についてマネージャーへ報告する

これらを引き出すため、「ちなみに、〜部門に頼まれたとかですかね?」「ごめん、この実装チケットはどういう経緯で出た要件だっけ?」など、合わせて必ず目的や背景を聞くようにしています。

相談した側としても、協力姿勢で一段踏み込んで質問されることに困ることはないので、快く背景を教えてくれることがほとんどです。

目的・背景から、最適なアプローチを提案する

目的や背景を聞く理由は、それに応じた最適なアプローチを提案するためです。

最適なアプローチは、相談した側が当初思い描いていたアプローチとは全く異なることも少なくありません。
例えば、最初の例に対して提案するアプローチも追記してみます。

  1. このシステムって、こういうデータを出せたりする? by ビジネス部門

    1. 目的:抽出したデータから分析レポートを作成し、事業計画見直しに役立てたい

    2. アプローチ→ それなら、実は別のこのシステムからも似たようなデータが出せるので、そちらで十分か確認してみては?

  2. この機能を追加するとしたら、どれくらいの期間(工数)でできる? by マネージャー

    1. 背景:マネージャーの先のビジネス部門から照会を受けており、回答したい。ビジネス部門は、まだ詳細な要件には落とし込むことはできていないが、この回答を元にシステム化予算を確保する予定だ

    2. アプローチ→ それなら、もう少し要件を詰めないと予算の根拠が薄すぎてお互い損するため、時間を取って要件を詰めましょう

  3. ここの実装、上手くできないんですよね〜、調べてみたら、結構技術的にハードルが高くて by 後輩

    1. 目的:ビジネス部門のプラスアルファの要件のための実装

    2. アプローチ→ プラスアルファということでビジネス部門に問い合わせたところ、ハードルが高いのであれば他の機能を優先で問題ない事が判明

  4. 今度の会議の資料作りが大変なんですよね〜 by 同僚

    1. 背景:ソフトウェア品質についてマネージャーへ報告する

    2. アプローチ→ マネージャーの〇〇さんは、メトリクスデータを直接見られればよく、丁寧な資料は要らないタイプ。データをとりあえず出してみては?

繰り返しになりますが、最適なアプローチというのは相談者の最初の一言とはかけ離れたものであることがあります。

だからこそ、相談者の最初の一言には過剰に囚われず、目的や背景をヒアリングしてゼロベースで提案をしたり、一緒に考えるようにしています。

ひと手間のおせっかいは自分のことも助ける

何か相談を受ける度に必ず目的や背景を聞き出すというのは、正直なところ手間でもあります。
聞かれたことへの回答だけで済ませたり、ふわっと相談にはふわっと回答で済ませることもできます。

しかし、適当な対応で済ませて何か事態が悪化した場合、組織として収束させることになり、結局は自分も巻き込まれる可能性が高くなります。実際にそういった経験をしたことも多々あります…

それであれば、最初からひと手間かけて相談されたこと以上のことをヒアリングし、自分の考えうる最適なアプローチを提案する

この方が Win-Win の関係を築けますし、姿勢としてもポジティブです。

中々時間や心の余裕が無いと上手くできないこともありますが、今後も意識して続けていき、上手くなりたい習慣です。

この記事が参加している募集

仕事について話そう

この記事が気に入ったらサポートをしてみませんか?