エンジニアとコミュ力についてのあれこれ

はじめまして。NONAME Produceのフロントエンドエンジニアのキーウィです。

梅雨がかなり苦手なので毎日必死に生きています。まあテレワークなのであまり関係ないですがなんとなく気分が重くなりますよね？ならないですか。そうですか。

今回のnoteはエンジニアとコミュニケーション能力（以下コミュ力）の相関関係についてつらつらと書いてみたいと思います。

近年、IT業界で働くエンジニアにとって従来よりコミュ力が必要とされてきているのは各所で言われていたりもしますし肌身で感じるところでもあります。

僕がここ数年働いた職場で、この人はすごい..！と思うエンジニアは漏れなくコミュ力がとても高かった記憶があります。

課題解決のためにしっかりコミュニケーションをとりつつコードもごりごり書く姿、単純にかっこいいです。

時代の要請に応じてエンジニアにコミュ力が必要になったのは確かなのですがもう少し掘り下げて考えてみました。

目次

1. 開発手法の変化
2. 技術の多様化・複雑化と高機能な業務ツールの普及
3. エンジニアに必要なコミュ力とは？
4. 1. 地頭の良さ
5. 2. 難解なことをわかりやすく伝える力・例え話のうまさ
6. 3. 自信
7. 4. 本質的な課題の共有
8. 5. 論破しようとしない

開発手法の変化

まず外して考えることの出来ない要素として、開発手法の変化があると思います。

ソフトウェアやサービスの開発手法として、従来はウォーターフォール開発が採用されることが多かったと思います。

最初にしっかり要件定義をしてそれを実現するためにしっかり設計してそのとおりに作って、と言ってみれば当たり前の手法ですが、例えば2年越しのソフトウェア開発プロジェクトみたいなものでそんな開発手法を採用出来るなんて、なんというか時間に余裕があるというか気長というか危ないというかいろいろアレですね。

基本的にとても綿密に時間をかけて要件定義と設計をするのですがそれだけガチガチに仕様を固めて途中でクライアントの要望が変わったり別の新しい最高の技術が出てきたりしたらどうするんですかね？恐ろしいです。

僕は社会勉強のため（興味本位）とあるSIerに在籍していたことがあるのですが、その会社ではウォーターフォール開発を採用していました。

小学校の同級生が皆ロボットに見えると言って学校に行かずYouTuberになって賛否両論を巻き起こしている方がいますが、その是非は置いておいて、僕がその会社の開発フェーズで見たものはおそらく彼が見たであろう光景でした。

皆黙々と設計書に基づいて開発を行っておりコミュニケーションはほとんど発生しませんしガチガチの設計書があるので特に柔軟性を求められたりもしません。

とある方と帰りの電車で一緒になったのですが、

「〇〇さんってどのあたりの開発やってるんですか？」「〇〇です。」「そうなんですね！僕は〇〇です。」「そうなんですね。」以上の会話に発展しませんでした。The 縦割りの弊害ですね。

翻って最近のソフトウェア開発やサービス運用にはアジャイル / スクラム開発が採用されることが多いですね。

アジャイル開発はざっくり言うとウォーターフォール開発の工程をぎゅっと圧縮してそれを反復的に行っていくことで状況の変化への対応や必要に応じた機能追加等の柔軟性を担保しながらスピーディーに開発する手法だと思います（違ってたらすいません）。

堅牢性より柔軟性が重視されるため必然的にコミュニケーションも多く発生します。

限られた1サイクルの時間の中で最適なアウトプットをしてアウトカムを求めていくわけなので密なコミュニケーションなしには成立しないですよね。

そんなわけで全体的に旧来の寡黙でPCに向かって黙々とタイプしているエンジニア像からPMやディレクターのようにそつなくコミュニケーションを行うエンジニア像へ移行していっている印象です。

ただの技術屋ではなく課題解決に向けて皆で考えてコミュニケーションをとっていけるようなエンジニアが求められていますね。

技術の多様化・複雑化と高機能な業務ツールの普及

さて、2つ目に、技術の境目が曖昧になってきたことが挙げられると思います。

今この時代って完全に静的なサイトの方が珍しいですよね？

この10年だけで見ても、次々と新しい技術が出てきてそれらを体系的に把握するだけでも死にものぐるいという感じです（というか無理です）。

例えば、僕はフロントエンドエンジニアですが、クライアントサイドでもJavaScript等動的な部分は発生するし、サーバサイドでどういった処理がされるかを想定しながら実装を行うことは当たり前になっています。

サーバサイドエンジニアとの間で「どの部分はクライアントサイドで行ってどの部分はサーバサイドで行う」といったすり合わせも必ず発生します。

また、エンジニアに限った話ではなく、デザイナーとの協業もいろいろな形が存在します。

このレイアウトは実現可能か、この端末の場合レイアウトはどうなるか、サイト内のアニメーションをどの程度までデザイナーが策定するのか、画像を書き出すのは誰か、データ形式は何か、今ある技術でどれだけデザインと実装の相乗効果を生めるか..考えただけで頭痛が痛くなってきます。

これ、ある程度コミュ力がないとこなせないですよね。

それに加えて今はSlack等の高機能なチャットツールやオンラインホワイトボード等スピーディーなコミュニケーションのためのプラットフォームがたくさん存在し、抗いがたいコミュニケーションの洪水にさらされることになります。

エンジニアに必要なコミュ力とは？

エンジニア同士の会話って楽しいですよね？何より共通言語があるので。

でも今は上に書いた通り他職能の方との密な連携が必要になる局面が多々あります。

そこで、僕がエンジニアのコミュニケーションで必要だと思っているものをいくつかあげてみたいと思います。

1. 地頭の良さ

身も蓋もないですね。地頭の良さってどうやって測るんですかね？自分は地頭が良いんですかね？わかりませんが体感的にこの人は地頭が良いなーと思う時は多々あります。

地頭が良いと複数の職能のチームの中でどういうコミュニケーションが求められているのかがぱっとわかったり課題解決のために何が必要なのかがぱっとわかったりいろいろぱっとわかりますよね？

まああえて地頭を良くする方法を書くとすればいろんな属性の人と積極的に話したり、常に状況を客観視したりする癖をつけることなんじゃないかとなんとなく思っています（違ってたらすいません）。

2. 難解なことをわかりやすく伝える力・例え話のうまさ

エンジニアはわりと難解な言葉を振りまきがちな連中です。

当たり前ですがディレクターやデザイナーに「この変数がああだこうだでこのイベントが発生したときにこの関数が実行されて..」とか話してもわかるわけないですよね（わかる人もいます）。

なのでそれを抽象化して誰にでも理解出来るように伝える必要があります。

そこでうまく例え話を使えたりすると俄然伝わりやすくなったりします。建物に例えたりするのが定石ですよね（古い？）。

僕は例え話があまり上手ではありません。がんばります。

ちなみに弊社にはとてもおもしろい例え話をするメンバーが約2名います。結構笑えるし伝わります。

3. 自信

自分がよく知っていて自信を持っている技術に関してはわりとペラペラ喋れたりしますよね？

実際コミュ障（失礼..）っぽいエンジニアでも自分の領域のことになると俄然饒舌になったりします。

逆に自信のない技術だと自分でも何を言ってるのかわからなくなったりして人を迷宮に誘い込むことになります。

普段から実力をつけて自信をつけておくことでいざという時に円滑にコミュニケーションがとれることは確実かなと思います。

4. 本質的な課題の共有

何人かで話していてもその課題の本質が皆で共有出来ていないとまとまりがなくなりますよね？

エンジニアに限った話ではないですが、特にフロントエンドエンジニアは下流の工程にいる以上しっかりと本質的な課題を把握して話を進めないとキメラ的なものが出来上がってしまいせっかくのそれまでの工程が台無しになってしまいます。

5. 論破しようとしない

してどーすんねん、という話ですね。言わずもがな。
たまに論破自体が目的化してしまっている残念なエンジニアがいますが、仲良く良いものを作りましょう..

というわけでエンジニアとコミュ力の相関関係についていろいろ思うところを書いてみましたがいかがでしたか？

ツッコミやアドバイスなどあればコメントいただけると嬉しいです。

あと、現在弊社では地頭が良くてたとえ話がうまく自信があり本質的な課題にフォーカス出来て論破しようととしないバックエンドエンジニアを鋭意募集中です！！

いや、そんなに多くは求めません。僕もそんなに出来ていないので。

でも一緒に働きませんか？？