プログラマーの本来のコミュニケーション能力とは

XPエクストリーム・プログラミング入門―変化を受け入れるや実装パターンなどの本でケント・ベックはコミュニケーションの重要性を説いています。そういういう話を聞いて「やはり、プログラマーは技術力ではなくコミュニケーション能力の方が重要だ」と思うのは間違いです。これらの本で主張されているコミュニケーションとは、挨拶がきちんとできるとか、場の空気を読めるとか、上司に対する報連相ができるとか、（そういったことも一応まったく無関係ではないとは思いますが）、そういったヒューマンスキルのことではなく、「いかに他人に理解しやすいわかりやすいコードを書くか」ということを主に主張しているのだと私は理解しています。「XPはコミュニケーションが重要」ということを聞いた時に、実に多くの人々が勘違いしているのではないかと思うのですが、XP的にコミュニケーション能力が高いプログラマーとは、第一にわかりやすいコードを書くプログラマーということが重要ということです。必ずしも口下手でチームのムードメーカーでなくても、わかりやすいコードや文書を書けるプログラマーもいるわけですから、ヒューマンスキルの面のみでコミュニケーション力の有無を判断するのは間違っていると思います。
多くの開発の現場では、プログラマーのスキル依存性の排除などの名目で

ひとつの処理ごとにクラスを作成する（BLogicなどのクラスを継承するなどの規約つき）
ひとつのテーブルごとにクラスを作成する
番号など無意味な接頭辞や接尾辞をクラス名やメソッド名をつけることを押し付ける

など、プログラマーの表現能力、コミュニケーション能力の大部分を奪ってしまうような規約が横行しています。*1そこではJavaなどのオブジェクト指向言語が本来が持つ抽象データ型、カプセル化、高凝集性、多態性などコードの可読性を高めるという機能はほとんど殺されてしまっています。そもそも顧客はもちろんSEとPGがコードでコミュニケーションするということすら重視されていないようです。
コードが誰にも読みやすくきれいに書かれていれば、機能追加やバグ対応は圧倒的に簡単になり、コードの流用も容易になります。ベックも主張しているように、これは単にプログラマーの美意識や自己満足ということではなく、関係者に大きな経済的メリットをもたらします。*2 プログラマーのコミュニケーション能力としては、こうしたわかりやすいコードを記述する能力が本来はもっと評価されるべきだと思います。

*1:これはネタかもしれないと、ちょっと信じられないのですが、もっとひどいところがあるようです。派遣PG時代の思い出 - Togetterこのような世界が現実に存在するのなら、本当に悲しいことです。インスタンス生成を否定し、C#ですべてpublic static宣言することを推奨する上から目線のベテランSEとか、こういう人のことを正に老害というのでしょう。

*2:これは、単に教科書にそう書かれているということだけではなくて、私自身あるパッケージベンダーにSESで（偽装請負的ですが）プログラマーとして何年も常駐作業をした経験を通してそう感じるものです。政治的な理由でのキャンセルなどを除いて、プロジェクトをオンスケを完成させる成功率は確実に高くなるし、バグ発生率も低くなるし、部品やフレームワークの再利用性の向上で利益率も長い目で高くなります。下請けの側でも技術力などで信頼してもらうことでリピートの受注率は向上します。