エンジニアのコミュニケーションの取り方

はじめに

私は大学生ですが、IT企業で1年間インターンをしています。webのアプリケーション開発のエンジニアとして働いています。webのアプリケーションとは、このnoteやGmail等のweb内で完結するアプリケーションです。

今回は、私が1年間仕事をして感じた、コミュニケーションの取り方について、書きたいと思います。たぶん、ビジネスというよりかはエンジニアとしてのコミュニケーションだと思います。

私が、文系の大学生だからこそ、エンジニアの特色だなと感じる点や、まだ一年しかたっていない成長段階というところから、独特な感性が共有できるんじゃないかと思っています。感想お待ちしております。

訳が分からない専門用語ばっかり

どの業界であっても専門用語は多いでしょうが、IT業界も同じです。また、呼び方もエンジニア特有の観点があったり、特に横文字が多く、似た言葉が多いのが頭を悩ませます。

「エンジニア独特の観点」というのがあるとだんだん言葉の関連性が見えてきますが、SQLだとか、SaaSだとか、アルファベットの羅列みたいなものも多くあり、覚えるだけで大変です。

分からないことを伝えよう

問題は、会議でよくわからない言葉が出てきて、その言葉中心で話が進められているとします。私が初めて開発のチームに入った時がそうでした。全く意味が分からず、とりあえず、わからないという意思表示をしました。

分からないときは、わからないと言うのは重要です。声に出さなくてもアクションでも出すべきだと感じます。その場で調べたり、表情で苦い顔をするだけでも、十分効果があると感じています。

事実、「ターミナル、コマンドプロンプト、DOS窓」と同じものに違う呼び方をすることが多く、人によって意味するものが違ったりします。知識のある人は相手との認識の違いに気を使って、リアクションを見ています。

大事な2つのポイント

大事なのは、「事実と意見を分ける」ということと、「自分が分かっていることを正確に伝える」ことだと感じています。

どちらも、基本中の基本ですが、それがとても難しく、意識していてもできていないことがあります。うまく話がかみ合ない時を冷静に振り返るとできていないことが多いです。

私の意識している話し方

私は下記のような構図で話すようにしています。

報告するとき
・自分がやったこと
・行動による結果
・自分の分析

質問するとき
・自分がやりたいこと
・自分のやったこと
・自分ができないこと
・自分の分析

具体的な例を交えて

上の説明だとわかりにくいので、具体例を出してお話します。例えば、カレーを作ったが、焦がしてしまったことを報告するとしましょう。

自分がやったこと
・基本的にレシピ通りに作りました。
・味が濃いのが好きなので、水の量だけ減らしました。
・ジャガイモが堅かったので煮込む時間を2分伸ばしました。
結果
・カレーが焦げていました。
自分の分析
・しっかり混ざっていないかったかもしれません。
・水を減らし過ぎたかもしれません。

混ぜるな危険

意識してる点は、かなり当たり前だと思えることも、事実と意見を分けることです。上の例だとしっかり混ぜなかったのが理由に感じますが、自分のやったことにその要素を入れていません。

また、結果と分析も混ぜちゃいけないと思っています。結果を「混ぜなかったため、カレーが焦げました。」という風にやっても駄目です。レシピに問題があった場合、その結果だと問題点がずれています。

通り道のように見る近道

あと、自分もやりがちなのが言葉で説明しようとすることです。必要なら、図を書いたり、実際にみせるのも重要です。百聞は一見に如かずというように、目で見る情報量に勝てません。

図や表を作る時間を惜しむ気持ちもわかりますが、認識のずれというのは、かなり重大な問題やさらに大きなタイムロスの種です。コミュニケーションもエンジニアリングの1つです。

終わりに

コミュニケーションのやり方だけでなく、頻度やタイミング等も働いていく上で重要だと感じています。自分は技術力と同じくらいコミュニケーションの重要性を感じています。