CTOのアマドです。最近はめっきりコードを書く量が減ってしまいましたが楽しくやっております。本日は最近よく考えている「コミュニケーション」という題材について。
「Timersではエンジニアのコミュニケーション能力を重視してます」と言っていましたが、最近もはやこれはTimersのエンジニア独自の話ではなく、全てのエンジニアが必要とする能力だと確信するようになってきました。
最近ではエンジニアに限らずどんな職種でもコミュニケーション能力が求められていたり、プライベートでもより良い人間関係を築くためのコミュニケーションについて議論されています。職種やシチュエーションを問わずコミュニケーションについて議論されていることは、人間そのものが「社会的な生き物」だということの裏返しなのですが、単に「コミュニケーション能力」と言ってしまうと、あまりに一般的すぎてとらえどころがありません。
議論の対象を「ソフトウェア開発エンジニアに求められるコミュニケーション能力」に絞り、エンジニアらしく定義設定をきちんと行うところから考えていきましょう。
結論からいうと
ソフトウェア開発という仕事＆コーディングという活動は「いかに円滑に他人（＆未来の自分）と協調しながら行うか」が基本。なのでコミュニケーション能力は必須。
「コミュニケーション」の定義
先にはっきりさせるべきなのは、 コミュニケーション＝おしゃべり能力ではない ということです。 コミュニケーションが包括する概念の中に「おしゃべり能力」（饒舌さ、社交性など）も含まれますが、それはあくまで「コミュニケーション」が包括する幾多の概念の中のひとつの要素です。
ではコミュニケーションという言葉の定義の確認。 英語なので、英語辞書から引っ張ってきましょう。
The imparting or interchange of thoughts, opinions, or information by speech, writing, or signs. (Dictionary.com)
口頭、筆記、あるいは記号を用いて思考、意見、情報を伝える／交換すること。
この定義を元に話を進めます。
ソフトウェア開発におけるコミュニケーション
ソフトウェア開発の現場では様々な区分のコミュニケーションが行われます。 切り口は様々だと思いますが、自分のこれまでの経験や知識を元に代表的なものにまとめてみました。
コーディング
コーディングという活動自体ひとつのコミュニケーションです。それは人間と機械のコミュニケーションだけではなく、自分と他の開発者（未来の自分含め）とのコミュニケーションも含んでいます。
下記の作業を考えてみてください：
- わかりやすい変数名をつける
- 変更容易性のためにモジュールを疎結合にする
- コメントを書く
これらは全てプログラムの処理性能自体に何の影響も及ぼしません。モジュールを疎結合にすることなんてむしろ性能に悪影響を及ぼすことの方が多いです。
ではなぜやるのでしょうか？
それはもちろん、他人が読みやすかったり他人が修正しやすくするためです。プログラムの動作に関する情報や意図を伝える、ということをコードを書きながら常に行なっているのです。これはまさに「コミュニケーション」という言葉の定義そのものですね。
オブジェクト指向というパラダイムなんてまさに人間達がやりやすいために作り上げられた概念です。
つまり、「コミュニケーション能力なんて必要ない」というのは「汚いコードでも動けばいい」と言っているのと同義なのです。
弊社では「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」は入社時に必読図書として必ず読んでもらうようにしてます。基本的な内容が多いですが、他人に読まれるコードを書く時のガイドとしてすごく大事な内容が書かれている良書です。
議論（意見交換）
エンジニアであればコードを書く以外のコミュニケーションも行いますよね。
ここでいう「議論（意見交換）」とは、相手の意見を聞き、自分の意見を伝え、その応酬を行いながら何らかの結論に導く、という活動のことを指してます。ソフトウェアの方向性について意見をぶつけ合うことも、ある問題への対処法を話し合うのも、コードレビューも、ここに入ります。
アジャイル開発ではチームで円滑なコミュニケーションをとる事が前提です。日々起こる変化ついてチームメンバー間で建設的に話し合い協調しながら、変化に対応していく開発モデルです。アジャイルマニフェストにも「 プロセスやツールよりも個人と対話を 」と書いてあります。
……と言いつつ、ウォーターフォールであっても、ひとつの工程の最中では議論や意見交換の場は当然のようにあるのではないでしょうか。オープンソースではメーリングリスト、チャット、issue上でソフトウェアの方向性について様々な意見交換が行われております。
例えば機能追加の要望をissueとして書く時なんかは、バグ報告に比べてコードで語れる量が少ないことも多く、「なぜこの機能があった方がいいのか」などを適切な意思伝達を行う文章で補わなければいけません。
一方で管理者側はそういった機能要望に対する回答を適切に行う必要もあります。ソフトウェアのロードマップにそぐわないなどの理由により機能追加に応えることが出来ないこともあります。そういう時に適切な回答ができないと反論が来たりして、意見のすれ違いによる議論の泥沼化もありえます（そういうissueはオープンソースを色々見ているとたまに見かけます）。
対面でさえ難しいような議論を、顔が見えない中で、誤解のないように効率的に行わなければいけません。オープンソースの舞台で活躍しているエンジニアはこういった意見交換の術をきちんと身につけています。
情報共有
意見交換になる手前で、単純な「共有」というものがあります。一方通行でも良いので、読み手に対して何らかの情報や意見を提供することです。例としては：
- 見つけた課題をissue/チケットとして起票すること、あるいは口頭/チャットで報告すること
- 書いたソフトウェアについて、読み手に伝わるようなドキュメンテーションを書くこと
- Pull Request の中で意図や背景を適切に説明すること
エンジニアリングをしていてこういった場面に遭遇しないことはほぼないはずです。こういった１つ１つの情報共有の場面でも、適切で明解な意思伝達ができるかできないかでチームの生産性にも影響が出ますし、開発しているソフトウェアの品質にも影響が出てきます。
ちんぷんかんぷんなドキュメンテーションでは誰も利用できず仕様や設計について混乱が生まれるだけですし、意図のわからないPull Requestをレビューしろと言われても（コード読んで自明なbugfixでもない限り）レビュワーとして非常にレビューしにくくなります。
ということで
以上のように、エンジニアとしてやっていくのであればコミュニケーション能力は必須なのは明確かと思います。適切に自分の意見や思考を伝達する能力が身についていなければ、良いコードを書くことはできないし、複数人数でソフトウェア開発をすることも難しくなるはずです。
優れたエンジニアを目指す方々は、あらためて自分たちが行なっているコーディングなどの活動を「コミュニケーション」だと認識し、そこに少しだけ意識を向けて日々の活動に取り組んでみてください。
プラスの効果があるのではないでしょうか。
……と言いつつ「意識を向けて」なんて抽象的な言葉で終わらせるのもアレなので、次はエンジニアとしてのコミュニケーション能力を向上させるためにできること、という内容で書いてみたいと思います。
子育て家族アプリFamm、カップル専用アプリPairyを運営する Timers inc. では、現在エンジニアを積極採用中！急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！
採用HP : http://timers-inc.com/engineerings
