自己紹介
初めまして、モンスター・ラボで「チーフテクノロジスト」という肩書きで仕事をしている稲村です。
ここ数ヶ月は、新規自社事業のスマートフォンアプリを作ったりしています（専らサーバ側ですが）。
このエントリの内容
このエントリでは、タイトル通り「できるプログラマ」について書きたいと思います。と言っても私が以前一緒に仕事をして「この人は出来る！凄い！」と感じたその内容を書きますので、できる人全般の話ではないです。ある意味限定された個人的な体験に依ってはいますが、何かしらの参考になれば幸いです。
先に結論
このエントリで書く「できるプログラマ」は、
1. 選択肢を持つ
2. 制約条件を把握する
3. 「常に」条件に応じた選択・判断を行う
という話です。
このエントリの「できるプログラマ」像
一口に「できる」と言っても、実に様々なタイプがあります。例えばこれまで無かったアルゴリズムや設計思想などを考案して作り上げる、非常に高い生産性を発揮する、どんな言語や環境でもすぐにキャッチアップしてものを作ってしまう、他人のコードのバグをすぐに見つけて解決する、フロントからバックエンドまで一人でカバーできる、などなど挙げていけばキリがありません。
その中で今回書くのは、「条件に応じた生産性と品質で安定したアウトプットを出す」プログラマです。
条件に応じた生産性と品質とは
仕事でプログラミングをする際には、ほぼ常に何かしらの前提条件があります。開発期間（たいてい短いw）、一緒に開発するメンバーの経験（たいていでもないけど浅い）、技術的に未知な部分がある（けどやる事は決定している）、メンテナンスが開発メンバーとは別なのでそれを考慮する必要がある、再利用可能な汎用性の高いものを求められている、仕様未確定部分が多いけど取り敢えず見えてる部分から開発を始める必要がある、中身は何でも良いけどとにかくすぐ動くものが必要、などなどこちらも挙げていけば山のように出てきそうです。
これらの前提条件を満たす範囲で、最大限の生産性（作り上げる速度）と品質（バグが少ない、十分なパフォーマンスが出る、可読性やメンテナンス性が高いなど）を確保する事を、ここでは「条件に応じた生産性と品質」と呼んでいます。
なお、そのプログラマが最大限の生産性と品質を確保しているとどうやって私が判断したかは、エントリの趣旨から外れるので割愛します。
「できるプログラマ」と話して凄いと思った事
端的に言うと、マクロレベルからミクロレベルまで、その人の成果物に関して「何故そうしたのか？」という質問をすると、常に明確な答えが返ってきました。
具体的には、「何故このアーキテクチャパターンを採用したのか？」「何故このフレームワークを使っているのか？」という様な広い範囲に関わる質問から、「何故この変数名にしたのか？」「何故ここはメソッド分割していないのか？」といったソースコード1行1行に関する質問まで、私がした全ての質問に対して理由付きの答えが返ってきました。
曰く、「最近話題の○○も考えたけど、メンバー学習時間を考えると納期的に厳しいから××にした」「スコープが限定されていて使い方が明確だからこの変数は機械的に命名した」「よく使われる△△というライブラリと合わせれば後でメンテナンスする人が分かり易いから、（用途からすると）ちょっと冗長だけどそのシグネチャに合わせた」「時間が無くてまず動くものを、という話だったのでそこはハードコードした。今後改善の時間がとれたらスクリプト化するつもり」、などなど。
つまり、自分の成果物について、完全に説明が出来るのです。
何も考えないでプログラミングする人はあまり居ないと思いますが、「なんとなく」「検索して出てきたコードをコピペしただけ」「流行ってるから使ってみたかった」みたいな、いわば根拠や再現性の無い説明がどこにも出てこないというのは、これは凄い事だと思いました。
何故説明出来るのか考えてみた
よく勉強している、様々な経験を積んでいる、センスがある、といった解釈では漠然としていて真似するのが難しいので、もう少し分析してみた結果、以下の3点に分けて捉えられるのではないかと思い至りました。
「できる」の分析
1. 選択肢を持つ
何かを判断する為には選択肢が必要です。もしJavaで文字列連結の仕方を"+"しか知らなかったら、適切かどうか検討する余地も無く常に"+"するしか無いですし、Strutsしか知らなかったら採用是非も何も無い訳です。
同じ前提条件でプログラムを作り続けるのであればそれに合った1つのやり方だけ知って、それをひたすら繰り返すというのもありかもしれませんが、常に同じ前提条件である仕事など実際には無いと思うので、もしそう思ったとしたら「トンカチを持っているから全てが釘に見えている」状態を疑った方が良さそうです。
ではどうすれば選択肢を持てるかといえば、これはシンプルに、普段の勉強と、色々な仕事経験の積み重ねだと思います。誤解の無いように言うと、上記の「できるプログラマ」も、あらゆる選択肢が事前に全て頭に入っているという訳ではもちろんなくて、必要な時に勉強したり他人に訊いたりして、選択肢を作っていました。
2. 制約条件を把握する
この制約条件が大きな判断基準となる為、期限や仕様以外にも、求められているものを出来るだけ網羅的に把握した方が、より適切な判断ができると思います。
例えば自分のプログラムを誰が読むのか、誰が使うのか、メンバーが使う場合にスキルレベルはどうか、ライブラリとして再利用される部分はあるか、システムの寿命はどのくらいか、ステークホルダーがどのくらいシステムを明確にイメージ出来ているか、などなど、プロジェクトや自分の役割によって色々あるでしょう。
なお、どの条件も満たす事ができる選択肢が複数ある場合（良い状況ですね）、前提条件以外の判断基準、つまり一般的な意味で「良い」プログラミングを選択する事になります。これによって、条件の範囲内で最大の生産性と品質を確保できます。
3. 「常に」条件に応じた選択・判断を行う
上の方で「マクロレベルからミクロレベルまで」と表現しましたが、要は極端な言い方をすれば、仕事でアウトプットをしている間は常に判断し続けているという事になります。その為には、1.で書いた選択肢が存在し、かつ判断基準が存在する（2.の制約条件の把握が出来ている）事が前提となります。
もちろん判断のレベルは様々なので、イディオム的にほぼノータイムで進められる部分もあるでしょうし、選択肢を吟味して「本当に条件に合っているか？」を熟考する場合もあるでしょう。いずれにしろ文字通りのノータイム、つまり判断無しで決定(?)する状態は避け、選択肢が無い場合はマズイ、条件を満たせない可能性があると思うようにしたいところです。
終わりに
以上、私が以前出会った「できるプログラマ」について簡単に分析してみました。
念のためですが、そのプログラマのコードにバグが無いという訳では無いですし、判断ミスも当然あります。ただ、複数の選択肢を持った上で条件に合わせて判断するという事の繰り返しで作っているので、バグがあった時に何が問題だったかも分り易いですし、判断ミスの修正も的確で速かったです。
こうして書いてみると、割と普通の事で、プログラマだけではない話でもありますが、私自身の経験として「なんかとにかくスゲー人だ！」という最初の印象から、「自分もこうすれば良いのではないか？」というという大体の理解が出来てホッとしたというところまで進んで良かった記憶があるので、このエントリを読んで頂いた皆さんの参考になれば嬉しいです。