デザインスキルを重視する

2008年1月17日

採用場面を想像してみてください。数年間の経験を持つ候補者が2人います。青コーナーには、あなたが好むスタイルのデザインスキル（私の場合は、DRY、パターン、TDD、コミュニケーションしやすいコードなどの賢明な活用ですが、実際のリストは重要ではありません - 重要なのは、あなたが好むものであるということです）を幅広く備えた人がいます。しかし、彼女はあなたが使用している特定のプラットフォーム技術については何も知りません。赤コーナーには、これらの問題についてほとんど知識（または関心）がなく、プラットフォームをよく知っている人がいます - 言語のエッジケース、利用可能なライブラリ、ツールを自然に操作できます。彼らについての他のすべてが等しいと仮定し（このような思考実験以外では決してそうではありません）、あなたのチームにはこの候補者が埋めることができる明らかな穴がないとします。どちらを選びますか？

私の答えはシンプルです。幅広いデザインスキルを持つ人を選びます。優れたプログラマーは、新しいプラットフォームを比較的迅速に習得できるはずだと私は常に考えてきました。基本的なデザインの美学を学ぶことはより難しく、新しいプラットフォームへの持ち越し効果も高くなります。Javaで重要な優れた設計プラクティスは、.NETでも同様に価値があります。プラットフォームに慣れていないと速度は低下しますが（C#でリテラルクラス名を取得するにはどうすればよいですか？）、適切に設計されたコードを作成することが真の違いを生み出します。

幅広いデザインスキルは、完全に移植可能というわけではありません。Javaと.NETは言語としてはほぼ同等ですが、Rubyに移行すると、より多くの変更が生じます。関数型言語のような、大きく異なるものに移行するには、より大きな変化が必要です。いずれにせよ、新しい環境であらゆる設計習慣を盲目的に複製することはできません。しかし、新しい世界を認識していれば、非常に多くのことが引き継がれます。

Thoughtworksでは、この原則が証明されているのを目の当たりにしてきました。Javaの初期の頃、経験豊富な開発者がForteで学んだスキルが、Javaでの作業に優れた直感を与えてくれることを発見しました。私たちはEJB中心の考え方から早期に脱却しましたが、それは他のプラットフォームでの経験が私たちを導いたと考えています。.NETではさらに強く感じました。優れたスキルを持つJavaの経験豊富な開発者は、.NETやMicrosoftの経験が長くても、これらのスキルが不足している開発者よりも急速に効果を発揮することが何度もありました。その違いは、数か月ではなく、数週間（時には数日）で明らかになりました。

現時点では、この変化はRubyで最も顕著に見られます。今年はRubyプロジェクトがかなり進んでおり、ニーズを満たすために、中括弧言語の経験が長い人に頼ることがよくあります。ここでも、幅広いデザインスキルの価値を実感しています。

常に確実とは限りません。他のプラットフォームで経験を積んだ人が、新しいプラットフォームを学びたいと思っていない場合があります。学ぶ意欲はここで必要な要素です。プラットフォームのスペシャリストが幅広いデザインを学びたいと思っていて、幅広いデザイナーが新しいプラットフォームを学びたくない場合は、単一プラットフォームのスペシャリストを選びます。また、チームにプラットフォームをよく知っている人がいることも不可欠です。

Thoughtworksのほとんどの人は、プラットフォームの知識よりもデザインスキルを重視していると思います。多くのクライアントはその見解を共有していません。これは、実際的および倫理的な難しい選択につながる可能性があります.

強力なデザインスキルを持ち、プラットフォームのバックグラウンドがない人をチームに加えたいが、クライアントがプラットフォームで少なくとも2年の経験を主張している場合はどうなりますか？あなたの専門的な判断では、幅広い候補者は他の誰よりも生産性が高いでしょう。クライアントには正直である必要がありますが、一方で、クライアントはあなたの専門的な判断に対してお金を払っています。クライアントがプロジェクトの納品責任をあなたに負わせている場合、これは変わりますか？

私たちにとって、これらの質問は、経済的な利益が関係しているため、より重要です。ThoughtWorkerをチームに追加すると、その人の料金を請求します。クライアントがプラットフォームのスペシャリストである請負業者を雇った場合、私たちはその収入を得られません。多くの人にとって、これは状況における重要な事実ですが、プロジェクトマネージャーは、間違った人を追加するリスクが、1つの請求可能な収入よりもはるかに重要であることを十分に理解していることを期待しています。

あなたがクライアントにオープンであり、クライアントが幅広いデザインを持つ人のプラットフォーム知識の不足のために、仕事で学ぶことになるため、割引料金を要求している別のケースを考えてみましょう。あなたは、その不足にもかかわらず、彼女はそれらのデザインスキルにより、競合するプラットフォームの専門家よりも生産性が高いと確信しています。割引料金を受け入れるべきですか？

私たち、そして他のほとんどの職業の性質として、仕事で学ぶということです。プラットフォームのスペシャリストも、保守可能なコードを作成するのであれば、幅広い設計スキルを学ぶ必要があります。ここで重要なのは、プラットフォームよりもデザインを学ぶ方が難しいだけでなく、確実性も低いことを覚えておくことです。やる気のある幅広いデザイナーがいれば、彼女は時間内にプラットフォームを習得できると確信できます。しかし、逆の保証はありません。プラットフォームの詳細を学ぶのが得意な人もいますが、明確なコードの書き方を理解することはありません。

ここでは幅広いデザインスキルについて話しました。これは技術的な軸に違いをもたらすと信じています。しかし、幅広さには他にも次元があります。ソフトウェアプロジェクトのほとんどのリスクは、ビジネスパーソンとプログラマー間のコミュニケーションにあるため、ユーザーと適切にコミュニケーションできる候補者は、チームに大きなメリットをもたらします。

同様の問題は、問題領域の知識です。クライアントはしばしば自分のビジネスをすでに知っている人を求めますが、誰かが急速に十分な理解を得て役に立つようになると驚きます。ここでは、他者と協力する能力が中心であると私は長い間考えてきました。ドメインの専門家やプラットフォームの専門家と協力することで、幅広いスキルを持つ人は非常に迅速に効果を発揮できます。他のドメインの知識は、多くの場合、プロジェクトに驚くべき洞察をもたらし、類似点は驚くべき場所に現れることがよくあります。中核となる会計パターンが、表面上は会計のように見えない場所に現れることがどれほど多いかは注目に値します。最終的には、他者と協力する能力と、速く学ぶことができることが重要なスキルです。

ここでは深いプラットフォームの知識を軽視しているわけではありません。理想的な世界では、すべてのチームメンバーが優れた幅広いプログラマーであり、数年間のプラットフォーム経験、問題ドメインをよく理解しており、同様のシステムを少なくとも2回以前に作成しているでしょう。しかし、私たち全員が、私たちの世界がその理想からどれほどかけ離れているかを知っています。チームにはプラットフォームの知識が必要です。ギャップがある場合は、プラットフォームのスペシャリストに依頼してギャップを埋めようとします。しかし、それは、ほとんどの場合、幅広いデザインスキルを好むという私のデフォルトの立場を変えるものではありません。