世にある多くの仕事はコミュニケーション能力が必要不可欠です。
エンジニアもその例に漏れず、コミュニケーション能力はとても大事です。
どんなに優れたスキルを持っていても、チームやクライアントとの適切なコミュニケーションがなければ、プロジェクトがスムーズに進行せず、成果を上げることが難しくなります。
エンジニアにとってのコミュニケーション能力は、業務を効率的に進めたり、問題を迅速に解決したりするために必要な能力です。
そういったコミュニケーション能力を身につけることで、あなたの市場価値はより高くなるでしょう。
この記事では、僕が普段気を付けているコミュニケーションのアレコレについて説明します。
「この記事を読めば完璧！」とまでは言えませんが、コミュニケーションに関する致命的な失敗は避けられるはずです。
基本的なコミュニケーション
まずはどのシーンでも重要な基本的なコミュニケーションについてです。
と言っても大して難しい事ではありません。
元々できている人もいるでしょうし、仮にできていない人でも少し気を付ければ改善可能なものばかりです。
聞き上手になる
まずは相手の意見を聞きましょう。
相手の意見や要望をしっかりと聞き取ることで、誤解を避けてより正確な情報を得ることができます。
あなた自身の意見ももちろん大事ですが、相手の話を遮るようなことは極力避けましょう。
※話が無駄に長引いていたり、脱線したりしているような場合は強引な中断も止む無しです
明確で簡潔な表現
技術的な内容の説明は大抵難しかったり複雑だったりするものです。
したがって、明確で簡潔な表現が求められます。
専門用語や複雑な説明は、相手に理解されないことが多いため、簡潔な言葉で要点を伝えるようにしましょう。
図やチャート等の視覚的な資料を活用するのも効果的です。
評価や意見は素直に受け取る
仕事をする上で、同僚や上司あるいはクライアントから評価や意見をもらうことがあると思います。
そういった評価や意見は、改善の機会と捉え、まずは素直に受け取ることにしましょう。
もちろん全部が全部有用なものとは限りませんが、無用だと思っていたものが有用だったということも十分あり得ます。
まずは素直に受け取ってみて、有用な評価や意見を取りこぼさないようにしましょう。
相手への敬意を忘れない
相手が不快に感じないような言葉遣いや態度を心掛けましょう。
攻撃的な言い回しや否定的な表現は避け、相手を尊重する姿勢を持ち続けることが大切です。
特に、異なる意見を持つ相手でも、立場や感情を考慮し、冷静かつ建設的な対話を目指しましょう。
進捗はまめに報告する
日次の進捗共有ミーティングがある職場の場合はそれほど意識する必要はありませんが、そうでない職場の場合はまめに進捗共有をするよう心掛けましょう。
最低でも日に1回は進捗共有をしておきましょう。
共有先はプロジェクトリーダーとエンジニアリーダーにしておけばまず間違いないです。
問題が発覚したらすぐに報告する
システム開発に限らずですが、何かしらの問題に出くわすことは珍しくありません。
問題が発覚したらすぐに他のメンバーに報告しましょう。
問題の種類や規模にもよりますが、とりあえずはエンジニアリーダーに報告しましょう。
問題がプロジェクト全体に関わりそうな場合は先んじてプロジェクトリーダーにも報告しておくと良いです。
問題に出くわしたが、あなただけでも解決できるような場合もあると思います。
そういった場合でも、「○○の問題に出くわしたが、△△の対応をして解決しました」とエンジニアリーダーに報告しておくと良いです。
素早く反応する
口頭のやり取りのような同期コミュニケーションであれば問題ありませんが、メールやチャットのような非同期コミュニケーションの場合はできるだけ素早く反応しましょう。
反応がないと相手は不安になります。
余計な不安を相手に抱かせないようにしましょう。
すぐに内容を確認することが難しくても、メールであれば「後程確認します」だけの返信や、チャットであればリアクションを付ける等だけでもしておくようにしましょう。
ただし、反応したっきり対応を忘れてしまうことがないように気を付けてください。
メールであれば重要マークを付ける、チャットならブックマークしておく等の工夫をしましょう。
エンジニア同士のコミュニケーション
お互いに助け合う
同じエンジニアであっても、技術的なスキルやプロジェクト内での担当機能は異なります。
あなたにとっては簡単なタスクでも、他のエンジニアには難しいタスクが発生することもあるでしょう。
他のエンジニアが苦戦しているようであれば、ぜひとも助けてあげてください。
「助ける」と言っても、そのタスクを全部巻き取れと言っているのではありません。
「ソースコードのどこを参照すればよいか」「どういう実装をしたら良いか」のような簡単なアドバイスで十分です。
逆にあなたが苦戦している時は、他のエンジニアに助けを求めると良いでしょう。
そうやって助け合う環境が整っていれば、開発の効率化はもちろんのこと、全体のスキル向上にもつながります。
知識の共有とドキュメント作成はまめに行う
開発を進めていくと、機能の実装担当者でないと気づきにくい課題や問題点に出くわすことがあると思います。
また、「機能は作ったけどデバッグや設定手順がけっこう複雑」みたいなこともあるあるだと思います。
そういった時は、積極的に知識の共有とドキュメント作成を行いましょう。
そうすることで、他の人が同じ問題に出くわしてもより効率的な解決が期待できます。
また、知識やドキュメントは場合によってはエンジニア以外にも共有する必要があります。
プロジェクト全体に関わることであればプロジェクトメンバー全員、企画や運用に関わることであればプランナー、画像やデザイン関連であればデザイナー、といった感じです。
気軽に相談できる関係性を構築する
他のエンジニアと気軽に相談できる関係を築くことは非常に重要です。
「なかなか話しかけられない相手と連携を取って開発を進める」なんて場面には大抵の人は出くわしたくないはずです。
そうならないためにも、普段からまめにコミュニケーションを取って、気軽にやり取りできる関係を築いておきましょう。
「友達のような関係になれ」と言っている訳ではありません。
(もちろん友達になっても良いです)
仕事上必要なやり取りを気兼ねせずに行えるようになっていれば十分です。
他職種とのコミュニケーション
不要な説明は避ける
エンジニアは知っておくべき事が、必ずしも他職種のメンバーが知るべき事とは限りません。
他職種のメンバーは、エンジニアリングの専門用語や技術的な内容については深い知識を持っていない場合が多いですが、それで問題ない場合がほとんどです。
他職種のメンバーに何かを説明する際は、できるだけ技術的な詳細に立ち入らないことがポイントです。
相手が知らなくても問題ない技術的な部分は省略し、シンプルかつ要点を押さえた説明を心掛けましょう。
例えば、システムのサーバーサイドのレスポンスが遅いことを説明する場合は、データベースのインデックスやロジック部分の実装等の技術的な要因を詳しく話す必要はありません。
「サーバー側でのデータ処理が遅くなっているため、レスポンスが遅くなっている」と簡潔に説明するだけで十分です。
ただし、相手にさらに詳細な説明を求められた場合や、問題の対策を議論するためにどうしても技術的な部分について触れざるを得ない場合は別です。
そういった時は、できるだけわかりやすく技術的な部分の説明をしましょう。
相手が知りたい情報は必ず付け加える
他職種のメンバーとやり取りをする際、彼等・彼女等が特に関心を持っている情報を提供することが重要です。
プランナー相手であれば機能の実装可否だけでなく実装工数、デザイナー相手であれば画像素材の修正や追加作成が必要かどうか、等になります。
例えば、プランナーから「○○みたいな機能を実装できる？」という質問に対し、できる・できないだけでなく「1～3日くらいで実装可能です」「まず実装できるかどうかの調査に1日ほどかかります」みたいに具体的な時間も添えて回答する感じです。
※「そもそもプランナーが最初に工数も聞いておくべきでは？」と思う人もいるでしょうが、あくまで例なので許してください
「そうは言っても他職種の人が知りたい情報がよくわからない」と思う人もいるでしょう。
そういう時は、今まで他職種の人としたやり取りを思い返してみてください。
毎回追加で質問される内容はないでしょうか？
心当たりがあるのであれば、それが他職種の人が知りたい情報です。
(もし心当たりがなければ、あなたは必要な情報をきちんと提供できている可能性が高いです)
相手の意見を正確に把握する
エンジニア同士でも持っている知識・経験の違いはありますが、他職種ともなればその違いはさらに大きくなります。
「あなたが持っている知識・経験を他職種のメンバーは持っていない」だけでなく、「他職種のメンバーが持っている知識・経験をあなたは持っていない」ということも多々あります。
お互いが上記のようなことをきちんと理解できていれば問題ありませんが、そうでない場合はとたんにコミュニケーションが難しくなってしまいます。
相手の意見が「よくわからなかった」「なんとなくしか理解できなかった」みたいな時は、相手が自身の知識・経験をあなたも持っている前提で話をしている可能性が高いです。
そういう時はきちんと不明点について質問してください。
相手の態度が「これくらい知ってるでしょ？」みたいに見えたとしても、臆せず質問するようにしましょう。
外部とのコミュニケーション
クライアント(顧客)とのコミュニケーション
クライアントとのやり取りでは、彼等・彼女等の期待を正確に把握し、それに応えることが求められます。
技術的な詳細ではなく、成果や進捗状況の報告を求められる場合が多いです。
先ほども少し触れましたが、余計な説明を省き、クライアントの期待する情報を明確に伝えましょう。
また、クライアントからの要望やフィードバックは、丁寧に対応しましょう。
難しい要望を無理に受け入れる必要はありませんが、その場合でも「○○の理由で、対応が難しいです。」等のきちんと理由を添えた上で断るようにしましょう。
どのような回答になるとしても、忘れないうちに素早く回答しましょう。
外部パートナーとのコミュニケーション
システム開発は社内だけでなく、外部の組織と共同で開発を行う場合もあります。
「○○の機能はA社、△△の機能はB社が開発担当」「C社が開発したライブラリを使って、D社が新システムを開発」みたいな感じです。
外部パートナーとのコミュニケーションは社内と比べて頻度が少なくなりがちです。
そのため、お互いの認識がずれてしまう問題はたびたび見かけます。
少なくとも双方の役割や責任は常に明確化しておくようにしましょう。
また、言った言わないの水掛け論にならないように、議論等で決定した事については必ず明文化し、外部パートナーに共有を行うようにしてください。
まとめ
今回は僕が普段気を付けているコミュニケーションのアレコレについて説明しました。
どれもそこまで難しい事ではありません。
なんなら人によっては楽勝な事かもしれません。
しかしながら、これらをきちんと行っているエンジニアは意外と少なかったりします。
もし今まで気にしていなかったことがあるようであれば、ぜひとも試してみてください。
今回説明したのは、あくまでもエンジニアとして開発業務をこなすのに必要なコミュニケーション能力です。
僕個人は、今後もエンジニアとしてずっと開発業務を続けたいと思っているので、これだけでも問題ありません。
一方、今後のキャリアプランとしてエンジニアリーダーやマネージャー、CTOを目指していく人にとっては少々物足りない内容だったと思います。
その様なキャリアプランを目指す場合は、さらに高度なコミュニケーション能力が必要となります。
今後もし、何かの間違いで僕がそのような役職についたら改めて解説してみようと思います。
コメント