優れたプログラマーの条件──コードを書く力だけではない9つの心得

理想のプログラマーとはどんな人物でしょうか。7歳からコーディングを始め、百万ドル規模のアプリを作り上げたコンピュータの天才?それとも、10年、20年の経験を積み、あらゆる言語(もちろん「良い」言語だけ)を操り、あなたがコーヒーをおかわりしている間にウェブサイトを構築してしまうベテラン開発者?あるいは、その美しさに周囲が感嘆の涙を流し、同時に嫉妬で歯ぎしりするほどのコードを書き上げる「コードの芸術家」?

どれも魅力的ですが……実は、優れたコーディングスキルだけでは不十分だと言ったら信じてもらえるでしょうか。良いプログラミングは、優れたプログラマーの条件の半分にすぎないのです。

もちろん、コードの書き方を知らなければ良いコーダーにはなれません。しかし、プログラマーに必要な「コンピューター以外の側面」は、意外と見落とされがちです。プロの開発者としての仕事には、コーディングとはまったく関係のない、「プロフェッショナルであること」に関わる要素がたくさんあります。真のプロとは、仕事を期日どおりに完了させ、チームの一員として協力でき(単なるヒーローではなく)、最終的に雇用主やクライアントにとって価値ある存在になれる人のことです。

では、優れた開発者の特徴とは何でしょうか。以下にいくつか挙げます。他にもたくさんあるはずです。

1. クリーンなコードを書く

はい、これは実際にコーディングに関する項目です。コーディングも条件の一部だと言いましたよね。良いコードの本質は、まず動作すること、他の開発者が理解できること、そしてあまり苦しまずにリファクタリングできることです。コードはコンピューターと通信するだけでなく、人間ともコミュニケーションを取るべきものです。数ヶ月前のコードに戻って、「過去の自分は一体何を考えていたんだっけ?」と思い出すのに膨大な時間を費やした経験はありませんか。適切な名前付けと整理された関数、コメント、ドキュメントは、将来の他人(そして未来の自分自身!)の時間を節約し、その何倍もの見返りをもたらします。

良いコードを書くための参考書籍(アフィリエイトリンクではありません):
『Clean Code』
『達人プログラマー(The Pragmatic Programmer)』
『リファクタリング:既存のコードを安全に改善する』

2. トレンドを追い続ける

Web開発のトレンドがどれほど猛烈なスピードで変化しているかは、誰もが知っています。最新の流行を追いかける「お調子者コーダー」になる必要はありません。しかし逆の極端、つまり現状に満足して怠けてしまうと、「恐竜コーダー」になってしまいます。それはもっと悪いことです。いくつかの中核となるスキルを磨きながら、業界の他のトレンドやニュースにも最低限精通しておく──そんな絶妙なバランスが理想的です。

常に変化する業界の最新情報をキャッチするのに役立つメディアをいくつか紹介します。他におすすめがあれば、ぜひコメントで教えてください。

Hacker News
A List Apart
Smashing Magazine
CSS-Tricks

3. 新しいことにオープンで、素早く学ぶ

まだコーディングを学び始めたばかりなら、自分を責めすぎないでください。1週間でAngularをマスターしろと言っているわけではありません。ただ、どんな問題に対しても、その解決策が「まだ自分の知らないもの」である可能性にはオープンでいてください。「まだ」というのが重要なポイントです。知らないことは、単純に「学べば身につくスキル」であり、自分の道具箱に追加できるものなのです。

新しいことをできるだけ速く、効率的に学ぶことが大切です。習得が早ければ早いほど、コーディングしたり他の新しいことを学んだりする時間が増えます。「学ぶこと」自体も、学べるスキルなのです。

4. 集中して効率的に働く

人間の脳はシングルスレッドで動作するため、マルチタスクは不可能だとよく言われます。タスクを切り替えることはできますが、それは非効率であり、決して理想的ではありません。とはいえ、仕事や状況によっては、中断が日常茶飯事という人もいるでしょう。だからこそ、限られたコーディング時間を最大限に活かすことが不可欠になります。

仕事時間とプライベート時間をできるだけ分け、互いに侵食し合わないようにしましょう。たとえば、数分ごとにSNSをチェックしていては、生産性が削られてしまいます。作業中は他のブラウザタブを閉じ、適切な目標に達するまで着実に作業を続けることで集中力を高められます。ポモドーロタイマーを使って25分程度の集中セッションで作業するのも、目の前の単一タスクへの集中に役立ちます。

さらなる読み物:
Cal Newport著『Deep Work(ディープワーク)』

5. タスク完了までの時間を正確に見積もる

これは難しい課題で、正直なところ私自身もまだ改善途中です。しかし、自分の能力を時間で正確に評価できるのは非常に価値のあるスキルです。会社勤めでも独立していても、甘い見積もりはプロジェクトのスケジュールを狂わせ、周囲の人に余計な負担をかけます。最悪の場合、作業時間を大幅に低估すると、自分や雇用主の金銭的損失につながります。

一点補足すると、必ずしも「X時間」と厳密に特定できる必要はありません。通常は範囲で示せばよいですし、プロジェクトの詳細情報が必要なので正確な見積もりはできない、と伝えても構いません。見積もり精度を高める第一歩は、コーディング中の時間を記録することです。(これは4番とも関連しています。作業中にネットサーフィンに耽っていなければ、見積もりは自然と正確になります)

6. 技術的な概念を非技術者に説明できる

イライラしますよね。コードブロックやメソッドの海を気持ちよく泳いでいたのに、現実世界に浮上して、プログラマーではない人たちにすべて説明しなければならないとき。彼らはソースコードを見ればわかるのに、なぜそうしないのか?

典型的なコーダーのステレオタイプは、地下の洞窟にこもって外部の世界に邪魔されずキーボードを叩くことにひたむきな一匹狼です。私自身、特に厄介な問題の解決に没頭している最中に中断されると、ペースが崩れて不機嫌になることを認めます。しかし、あなたと同じように、一緒に働く非技術者たちにも重要な役割があります。(少なくとも、彼らが皆と話をしてくれるおかげで、あなたは話さずに済んでいるのです!)

チーム全員とうまく協働するには、コードの話を相手が理解できる形で説明する必要があります。その第一歩は、あなたが「解決すべきコーディング問題」として世界を見ていても、他の人たちはお金、締切、クライアントといった原則を軸に動いていると理解することです。

相手の言葉と論理で会話できれば、優れたチームプレイヤーへの道は大きく開けます。たとえば、プロジェクトに新機能の追加を求められたとしましょう。「そんなのバカげてる、やりたくない!」と叫んで洞窟に逃げ込む代わりに、「この機能にはさらに20時間の作業が必要で、納期はおそらく延期になります」と説明すればいいのです。

7. エゴを職場に持ち込まない

これを毎日100%達成できるのは、ごく一部の優秀な人だけでしょう。しかし、仕事において純粋にエゴに突き動かされないよう努力することはできます。どういう意味か?つまり、自分を良く見せることだけが目的ではなく、プロジェクト、チーム、会社全体が良くなることを望むということです。自分だけでなく全員の成功のために尽力すれば、人はあなたと働くことを喜ぶでしょう。

自分の欲しいものを得るために他人を踏みつけるようなことをすれば、自分が渡る橋に火をつけているようなものです。そして崩落の時、あなたはその真ん中にいます。短期的な利益は得られるかもしれませんが、みんなに嫌われる「一緒に働きたくないあいつ」になりたいのでしょうか?

8. ミスを隠さない

失敗を好む人はいません。それは人間らしいことです。しかしプロフェッショナルである以上、ミスを隠したいという人間的な衝動を克服しなければなりません。

プロジェクトに悪影響を及ぼすミスを犯した場合、自分と共に働く仲間のためにできる最善のことは、すぐに白状することです。上司に伝え、クライアントに伝え、伝えるべき人に伝えて、被害の最小化に取り掛かりましょう。ミスを隠して誰にも気づかれないこともあるかもしれませんが、発覚した場合は信頼が大きく損なわれ、プロジェクト、ひいては自分の仕事さえ危うくなりかねません。

もちろん、些細なミス一つひとつを報告する必要はありません。しかし、修正に追加の時間がかかったり、重要なものを壊したりするミスについては、自分のためにも皆のためにも正直に認めるのが賢明です。長い目で見れば、そのほうがずっと良い結果をもたらします。

9. 助けを求め、助けを与えられる

行き詰まったり理解できないことがあったりしたら、質問することを恐れないでください。締切のあるプロジェクトに取り組んでいるなら、助けを求めれば1時間以内に解決策が得られるかもしれないのに、何時間も一人で悩むのは得策ではありません。

もちろん、Google、Stack Overflow、Slackなどを活用して、できる限り自力で進めることとのバランスは必要です。しかし、特に会社員の場合、「自立していて、何でも助けなしにできる人でいたい」という傾向があるように思います。それは本当に時間の浪費になりかねません。難しいかもしれませんが、プライドを飲み込み、助けが必要だと認めましょう。より早く学び、仕事を終えられます。

その裏返しとして、もちろん、他の人が助けを必要としているときに手を貸すことも大切です。私がWeb開発者として駆け出しだった頃は、会社の経験豊富な先輩たちに大いに頼り、それが上達の大きな助けになりました。私が経験を積むにつれ、今度は後輩たちがよく質問に来るようになりました。中断されるのはプログラミングで一番楽しい部分ではありませんが、チームプレイヤーであることの一部でもあります。深いコーディングの最中なら、「数分後に折り返すね」と伝えればいいのです。(本当に緊急の場合は別です)

誰かに助けを求められたら、次回も成功できるような形で手助けするよう心がけましょう。答えを渡すだけでなく、背景となる原理や問題の解決方法を理解できる文脈も添えるのです。いわゆる「魚を与えるより釣り方を教える」というやつですね。

これらの項目の中に、心当たりのあるものはありましたか?反対意見がある項目は?ぜひ下のコメント欄でお聞かせください!