優秀なプログラマを雇う方法

2008/10/17-3

「A Guide to Hiring Programmers: The High Cost of Low Quality」という記事と、その記事への捕捉として後ほど投稿された「A follow up to "A Guide for Hiring Programmers"」という記事がありました。プログラマの雇い方というタイトルではありましたが、内容はもう少し広いです。一部著者の熱すぎる想いが加熱しているように見える部分や、アメリカ的事情に見える部分もありましたが、全体的に興味深い内容でした。

以下、2つまとめた要約です。 3番までが一つ目の記事で、4番以降が二つ目の記事要約です。誤訳等が含まれている可能性があるので、是非原文をご覧下さい。

概要

Perlのコミュニティでプログラマを雇う事(特にPerl開発者)を話し合っていて、以下の点で知人達と合意ができた。

どのようなプログラミング言語であっても、良いプログラマを発見するのは難しい。そして、良いプログラマは通常プログラマの5～10倍の性能を発揮する。
通常の給与体系ではプログラマのスキルよりも開発言語をベースにしていることが多い。
特定の開発言語Xのエキスパートを探す必要はない。開発言語Xを勉強する意欲のあるエキスパートプログラマであれば良い。エキスパートは知らない開発言語であっても数週間で覚えてしまう。
エキスパートプログラマが完全に在宅勤務できる体制について真剣に考えるべきだ。自分のまわりの地域だけからプログラマを探そうとする行為は、得られるプログラマを制限してしまう。 Linux,Apache,Firefoxなど、成功している多くのオープンソースを見てみるとタイムゾーンが違う世界各国の開発者が「リアルで会うことなく」成果を出しているのがわかる。
Perlは良い言語だが、PerlよりもアジャイルではないJava/C/C++/C#などを経験した後でやる方が良い。

1. 何故良いプログラマを発見するのがこんなに難しいのか

最も簡単な理由は、企業が良いプログラマを長く引き止めるために努力をするから。もう一つの理由は、どのフィールドであってもエキスパートは全体のうちの少数であるから。そのため、そもそも良いプログラマのプールが少ない。

これによって、マネージャがとりあえず通常のスキル、もしくはそれ以下のプログラマを雇うことを判断する場合がある。しかし、これは技術指向企業にとっては大きな過ちである。

質の低いプログラマは、初心者的質問、質の低いコメント/ドキュメンテーション、によって他のプログラマの時間を奪う。質の低いコードは他者が後で直すはめになる。

企業は、開発者を頭数で考えるのをやめなければならない。どちらかというと開発者はアーティスト、著者、デザイナー、アーキテクト、科学者、CEOなどと似ている。誰でもいいからといって、いい加減にCEOを選ぶような経営戦略部署があるだろうか？そこに間違った人を配置するよりも、空席のままにした方が良いということはわかる。プログラミングでも同じである。

開発経験のある人であれば、エキスパートは10倍以上の効果を出せるということを知っている。しかし、企業がエキスパートに支払う給与は10～20％増しが良いところである。 10倍の性能があるから10倍払えと言っているわけではない。ただ、より多く払う事によって結果的に節約ができることもある。

例を考えてみよう。例えば、15人の通常プログラマを年間6万ドルで雇って合計90万ドルを人件費とするかわりに、5人のエキスパートを合計120万ドルで雇うときの利点と欠点を考えてみよう。

欠点

プログラマを探すのに多くの時間がかかる。
このクラスの開発者からは、あなたの会社で作っているものが「つまらない」と判断されてしまうかも知れない。賢い人は普通の人がつまらないと思うことを、もっとつまらないと思う。
そのうちの一人が会社を去ると、会社のリソースの20％が消失したと受け取られることがある。もしくは、それより多くの知識が会社から歩いて出て行ってしまったことになる。

利点

各開発者は良い給料を維持するために仕事に専念する。給与だけではなく、同僚が優秀であれば仕事に対する満足度も上昇する。
人数が少ないため、チームメンバ間でのコミュニケーションオーバヘッドが減少する。
エキスパートは群れている。スタッフにエキスパートが一人いれば、同じフィールドのエキスパートを発見するのが容易になる。
PCや携帯電話などの設備にかかる費用が抑えられる。
社員のための事務処理が減る。 15人よりも5人の方が社員数が少ないので書類や聞き取りなどに要する手間が減る。
結局事務経費を30万ドル節約できる。ストックオプション、退職金、健康保険、その他色々。

2. エキスパートプログラマとは何か？

経験がエキスパートの鍵ではあるが、その言語を続けた期間だけが重要なのではない。複数の分野で働いた事のあるジェネラリストの方が良い開発者である場合もある。開発者が過去にシステム管理者をやった経験があるとなお良い。

私が知る最高の開発者達には元々ジャーナリスト、数学者、言語学者、など普通はソフトウェア開発と結びついていない職業だった人もいる。

エキスパートは良いツールを使い、成果物にこだわる。また、怠け者であり、苦労するよりもスマートに働くことを好む。エキスパートは、複雑な解決方法よりもシンプルな解決方法を好み、コードも読みやすい。

これらは、次の開発者に作業を引き継ぐ時に大きな差となる。特に、次の開発者がエキスパートではない場合に差は顕著となる。

3. エキスパートプログラマを雇いたくなる理由

ソフトウェアが良く落ちますか？バグが多いですか？ユーザから使いにくいと言われますか？簡単な問題を解決するために複雑な説明書を読まなければならないですか？

これらに「yes」と答えているのであれば、あなたが雇っているプログラマは通常もしくは、それ以下の開発者でしょう。

エキスパートがいる環境で働いていると、物事はシンプルに進む。ソフトウェアは使いやすく、変更も行いやすい。ものごとがただただ流れるように行われていく。

多くの人生での出来事と同じように、払った分だけの価値を得られる。

4. これってプログラマ以外にも適応可能

これらの視点は、プログラマだけではなくデザイナなどに対しても適応できる。もちろん営業職に関しても、言える。

5. エキスパート以外はいらないのか？

エキスパート以外を雇わない事が良いと考えているのかって？答えは「yes」だ。多くの場合、企業はそのような状況を作るように努力すべきだ。

ただし、より巨大な製品を作ろうとしている大企業の場合はどうだろうか？恐らく無理だと思う。

単に50人の開発者が必要という条件であれば、全てをエキスパートにするのは難しいと思われる。しかし、その中の10～15人ぐらいがエキスパートであれば、開発が効率化されると信じている。ただ、多くの場合、1～3人のエキスパートが全体を率いていく。

エキスパートを雇えないのであれば、時間の経過とともに経験を積んでエキスパートになれるような人材を雇うべきだ。

6. どうやったらエキスパートになれるの？

どんなエキスパートであっても最初は初心者である。昔、誰かが合気道を数年習って黒帯を取得した時に「これで学び始められる」と言われたという話を聞いた事がある。プログラミングでも同様だと思う。

ということで、エキスパートになるにはどうするか？あなたのフィールドで出来るだけのことをしましょう。同じ事をやり続けるだけではエキスパートにはなれない。

多くの開発者が自分の心地が良い場所から出ようとしない。新しい言語やツールを試してみたりしながら、もっと簡単に/高品質に何かができないかを探求すべきだ。

オープンソースプロジェクトに参加するのも良いかも知れない。コード品質が改善されるし、他人のコードを見る機会にもなる。実際には、コントリビュートできないかも知れないが、他の開発者がどうやっているかを見ることはできる。

7. どうやってエキスパートを発見して雇うの？

オープンソースプロジェクトに関わってきた開発者の仕事振りを調べるのは簡単だ。他人とどのようにして活動をしてきたかは、メーリングリストを見ればわかる。また、オープンソースに関わること自体が創造に対して愛があることを示している。

マークシート的な試験は意味がないと思う。引っ掛け問題に受験者が引っかかることもある。どうやって問題を解決していくかの過程の方が、既に脳細胞に入っている情報よりも重要な場合もある。

8. 多くはマーケティングとマネージャのせい

悪いマネージャは、どんなチームやプロジェクトでも崩壊させる。エキスパートの数などは関係ない。

マーケティングは短すぎる納期で仕事を了承してしまったりする。しかし、実際に責任をなすりつけられるのは開発者である場合が多い。

私からのマーケティングやマネージャへのアドバイスは、問題点を開発者のところまで持ってきて納期を相談することだ。まず最初に予定ありきなプロジェクトが多すぎる。これは逆だ。

ただ、どうしようもない場合もある。 2000年の1月1日は、どうやっても変わらない。 Y2K問題の期日は、誰にもどうしようもなかった。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！