![]() |
プログラマーを採用する際に重視すべき10の資質 |
プログラマーが有するスキルには大きな幅があり、彼らの出身国や文化もさまざまであるため、プログラマーの素性や経歴というものはそれぞれ異なっているはずである。とは言うものの、プログラマーの優劣に大きな影響を与える資質というものも存在しているのだ。そこで本記事では、プログラマーを採用する際に重視すべき資質を10個選んで解説する。
優秀なプログラマーはものごとを「ありのままに」捉えるということをしない:彼らは、きちんと動作しているように見えるものに対しても、詳細を学ぼうとその中身に深く踏み込んでいくのである。そして彼らがそういった態度をとることで、存在すら明らかになっていなかった問題が解決されることも多々あり、それは通常、深刻な問題を解決する早道なのである。こういった考え方を身に付けていないプログラマーはたいてい、自らが行っていることとその理由を理解するための根本的な知識を身に付けることができないことになり、それは目隠しをした状態で働くようなものなのである。応募者がかなり内気でない限り、好奇心を持っている場合には面接時にそれが前面に強く現れてくるはずである。
当たり前のことだと思われるかもしれないものの、プログラミングには論理的な思考が要求されるのである。「2 + 2 = 4」という計算ができる人は普通にいても、「2 + x = 4」という式から「x = 2」という答えを導き出せる人の数はそれよりも少ないのである。私が数学や科学をしっかり学んだプログラマーを優先して採用したいと常々考えている理由がここにある。数学や科学に造詣の深い人の方がプログラミングに秀でていることも多いとはいえ、数学や科学の知識の深さというものが論理的なスキルの指標となり得ることも多いということが重要なのである。私は応募者と仕事内容について話をする際、あえてすべてを口に出さず、相手がその内容を把握できるかどうかを見てみる場合がある。また、採用時にきっちりしたかたちで試験を行うのであれば、その際に論理的な思考能力の有無もテストするのが良いだろう。
これまた当たり前のことであるものの、プログラマーの生産性という観点で見た場合、コードのタイピング速度はあまり重要ではない。プログラマーの1日の大半は、読むという作業に費やされるのである。その対象は他人のプログラムや、コード例が掲載されているウェブサイト、ドキュメント、プロジェクトの仕様書などさまざまである。読むのが遅い、あるいはさらに悪いことに読んだことを理解できないプログラマーは、役に立たないばかりか、危険な存在ともなり得る。仕様書を誤読し、間違えたことに気付かずに3週間も無駄にするような人間など、チームにいてほしくないはずだ:プロジェクトの利害関係者にそういった遅れを説明するというのは、ばつの悪いことである。ただし、読むというスキルを採用時に評価することは、きちんとした評価手段を採らない限り難しいだろう。
詳細に対する注意力と好奇心は密接な関係にある。詳細に対して注意を払うプログラマーは、同レベルのスキルを持ちながらそういったことをしないプログラマーに比べて格段に生産性が高いのである。しかし残念なことに、採用時にこういった資質を見極めることはすこぶる難しい。とは言うものの、応募者のこういった資質が採用時に明らかになる場合もある。例えば、面接時に発せられる何気ない言葉や、その場で起こるちょっとした出来事から判断できることもあるのだ。
具体的な例を挙げると、私が以前に行った面接において、私の着ていたシャツをさりげなく誉め、自身もそのデザイナーの服を気に入っていると述べた応募者がいた。彼のこの行為は、彼に(ファッションセンスだけではなく)細部への注意力があるということを雄弁に語っているのである。そしてもちろん、細部への注意力の欠如が明らかな場合もある。ズボンのボタンが留まっていない、あるいは靴にトイレットペーパーがへばりついているといった身なりで面接の場に現れる応募者は、細部にまで注意を払っていないのだ!
あなたの会社がコンパイラやIDEといったプログラミングツールを開発しているのでない限り、あなたの会社で働くプログラマーは、プログラミングという領域を離れたプロジェクトで仕事をしていることになる。記者が記事のテーマに関して少しは理解していなければならないのと同様に、あるいは教師が担当科目についての役に立つ知識を必要としているのと同様に、優れたプログラマーは、自らの開発するソフトウェアが使用される環境について学ぶ能力を持っている必要があるのだ。もちろん、会計ソフトを開発するからといって、コンピュータ科学の学位に加えて公認会計士の資格も必要になるというわけではない。しかし、基本となる数学や、業務知識を理解できないプログラマーは、会社にとって重荷となるはずである。
私は、採用選考の最終段階に残った応募者に対して自社を案内し、業務の概要について簡単かつシンプルに、平易な言葉で説明することにしている。そして、私が話していることについて理解したことを示すような的確な質問を行う応募者や、他の方法で理解したことを示すような応募者に対して、最終的な採用選考で点数を上乗せするのである。
プログラミングを担う部門が、プログラマー教育のために予算や時間を割くことができるということは滅多にない。これは残念なことながら、今の業界の現実である。その結果、ほとんどのプログラマーはいったん学校を卒業すると、スキルを独学で身に付けることになるのである(助けを借りられる良き指導者が近くにいることが理想である)。そして、自己学習能力の高いプログラマーほど、プログラミング能力を向上させることになるのだ。
私は、面接相手が何か難しい技術について語ろうとした場合に「どうやってそれを学んだのですか?」と質問したり、「どうやって新たなスキルを獲得するのですか?」や「プログラミングに関連する本や雑誌、ウェブサイト、ブログなどを読んでいますか?」といった質問をよく投げかけたりする。採用するのであれば、社内の教育プログラム以外では何も学びたくないという応募者よりも、現在のプログラミング能力が今ひとつであっても、新たなプログラミングスキルを独力で学ぶ熱意のある応募者の方が遙かに望ましいのである。
プログラマーの中には「残業しない人」もいる。つまり、月曜日から金曜日の9時から5時まではプログラミング作業を行うものの、それ以外の時間にはプログラムのことについて一切考えないという人々のことである。それでもまったく問題はない--寝ても覚めてもプログラミングのことばかり考えているスーパーギークに誰もがなれるわけではないからだ。私は過去にこういった人々を採用し、人手不足を補ったり、プロジェクトの定型作業を任せたりしたことがある。しかし、優秀なプログラマー(スキルや経験のレベルにかかわらず)を採用する必要がある場合には、仕事への熱意のある人を採用する必要がある。
熱意は、正念場において、あるいは取り扱いの難しいテクニックや特殊なスキルなどを必要とするプロジェクトにおいて「成功を左右するもの」となる。詰まるところ、残業しない人々は、ものごとを行う最善の方法を学ぼうという動機付けを持っていないため、最善の方法とは限らない今まで通りの方法をとり続けるのだ。また彼らは、仕事のためではなく、お金のために働いているため、給与や諸手当を定期的に引き上げない限り、引き留めておくことが難しいのである。熱意は面接時にかなり明らかになるはずだ。あなたのプロジェクトについての話を聞いたり、自身の過去のプロジェクトについて語ったりする際に情熱を見せる応募者は、熱意を持っているはずなのだ。
あなたには、プロジェクトの開始から終了まで仕様に変更が発生しなかったという経験があるだろうか?おそらくないはずだろうし、私にもない。そしてこれは、1日足らずで終わってしまう短期プロジェクトも含めての話なのだ!変更にうまく対処できないプログラマーは、政府関係の契約でよくあるウォーターフォール型の長期プロジェクトに参加する場合を除き、あまりうまくやって行くことができないだろう。もちろん、こういったタイプのプロジェクトを貶めるつもりはない。だが、ほとんどのプロジェクトでは、適応力の欠如が致命的となるのである。
応募者が適応力に欠けている、すなわち変更への対処が下手であるかどうかは、面接時に、特に「要件はしばしば変更されましたか?」といった質問をすれば容易に明らかになる。そこで「もちろんです。しかし、そういったことはどのプロジェクトでも起こることであり、避けがたい現実ですから」といった答えが返ってくれば合格である。これに対して、目をむいて「そうなんです。だから何も完了させることができなかったのです!」などと答える応募者はおそらく、ほとんどの環境に適応することができないだろう。
「コミュニケーションスキル」といっても、「完璧な国語を話す」という意味ではない。これは「考えを正確に、かつ効率良く伝えることができる」ということを意味しているのである。図面や音声、ジェスチャーはすべてコミュニケーションスキルを構成するものである。自らの言いたいことを相手に伝える、あるいは理解してもらうことが苦手なプログラマーは、長い目で見れば効率的に仕事をこなせないということなのである。これは、電話による面接では的確に評価することが難しい能力であるのものの、対面の面接でうまくコミュニケーションができなければ、仕事でも苦戦することになるのは間違いないはずだ。
プログラマーは、自立心のある人間として知られている。実際のところ、私はそれが彼らの強みであると思っており、技術的なプロジェクトで働く人々を細かくマネジメントしなくても済むというのは素晴らしいことだと考えている。しかし、プログラマーの中には、「上司は私であり、あなたではない」という考えになじめない人も多いのである。これが専制君主的に聞こえるということは判っているし、実際そうである。マネージャーはしばしば、技術とは関係ない観点から決断を下す必要があり、そういった理由(機密事項や社内の政治問題、時間的な制約など)をチームに説明することができない場合もあるのだ。
私は、少しばかりの抵抗であれば(特にまずい判断に対してのものであれば)、奨励し、全面的に支持する。上司がまずい判断であることを認識しておらず、そのフィードバックが適切に行われている場合にはなおさらである。しかし、上司が「技術的な観点から見た場合、これがまずい考えであることは判っている。しかし、そうする必要があるのだ」と言ったのであれば、それが最終的な判断となるのだ。とは言うものの、ある種の「不良プログラマー」が上司の指示を無視し、自らの判断で行動するということがあまりにも多いのである。さらに悪いことに、そういったプログラマーは、上司がいかに愚かであるかや、プログラミングについて理解していないか(この主張は正しいこともあれば、正しくないこともある)といったことを誰彼構わず吹聴してまわる傾向にある。こういった行動はプロジェクトを失敗に導き、反感を呼び起こしてチームの士気を低下させることになるのである。
こういった精神構造は面接時に、特に過去の経験について尋ねた時にしばしば明らかになる。不良プログラマーは、面接のような場であったとしても、かつての上司のことについて「邪悪で、愚かで、漫画『Dilbert』に出てくるような、部下を奴隷のようにこき使う上司」だと語りたがるのである。これに対して、精神的に成熟したプログラマーであれば、「上司の判断には技術的な面で同意できないところもありましたが、そういった判断は技術とは関係ない観点を考慮に入れたうえでのことだと理解しています」といったことを述べるのだ。
この記事は海外CNET Networks発のニュースをシーネットネットワークスジャパン編集部が日本向けに編集したものです。海外CNET Networksの記事へ
ZDNET Japanは、Ziff Davisからのライセンスに基づき株式会社4Xが運営しています。
ZDNET Japan is operated by 4X Corp under license from Ziff Davis.
Copyright © 2026 4X Corp, Inc. All rights reserved. No reproduction or republication without written permission.