12歳くらいのとき、プロのプログラマーになるという目標を立てた。
そう断言できるのは、このとき左利きでありながら意識的に右手でマウスを操作することに決めたからだ。

考えはこうだった。もし同僚のコンピューターのトラブルを手伝うことになったとき、始める前にわざわざ彼女のマウスを反対側に動かしたくはなかったのだ。それは気まずいだろう。（もちろん当時はワイヤレスマウスの登場など予想もしていなかった……実際のところ、今でも習慣で右手を使っている。）

ずっと知りたいと思っていたことが一つある。プログラマーの典型的な一日はどんなものなのか、ということだ。このキャリアを追いかけて時間を無駄にしているのではないか？答えが見つかったのはずっと後のことで、そのためには自分自身がプロのプログラマーにならなければならなかった。この記事は、そんな数年間の迷いをあなたに味わわせないためのものだ。

この記事を読み進める前に、ぜひシリーズの第一回「Why I love Programming」も読んでほしい。

「プロ」と「趣味」のプログラミングは何が違うのか

一言で言えば、責任だ。
責任を持つことが求められる。

自由時間にプログラミングをするのは、後片付けをしなくていいパーティーを開くようなものだ。純粋に楽しい。飽きたら次に移ればいい。しかしプロのプログラミングはそうはいかない。仕事をやり遂げることが求められるのだ。

どんなアプリケーションにも、絶え間ないバグ修正やリファクタリング、時にはモンキーパッチさえ必要になる。コードの保守は遊園地のように楽しいものではない。ましてや他人のコードであればなおさらだ。

ジュニア開発者として

学校を出たばかりの頃は、自分はかなりイケてるプログラマーだと思っているかもしれない。はっきり言おう。そんなことはない。才能ある人たちがこの光る箱で何ができるのか、想像もつかないだろう。最初の数年間は、学ぶべきことが山ほどある。

プロのソフトウェア開発は長いプロセスだ。読みやすく、十分にテストされ、きちんとドキュメント化されたコードを書くのは多大な労力を要する。忍耐が必要になる。しかも、かなりの量がだ。自分に対しても、他人に対しても。

ジュニアの頃は物事を白黒だけで考える。コードを見て、これは全部間違っていると思う。正気の人間がこんなひどい化け物を作ったのか？！と。経験を積むにつれて、グレーの濃淡が見えてくるようになる。

やがて、あのベテランたちは自分より仕事が遅かったのではなく、慎重だったのだと理解するようになる。コードのテストの仕方やドキュメントの書き方を学ぶ。しまいにはUML図さえありがたく思えるようになる。

時代遅れになるということ

「世の中の動きは速すぎる。今日学んだことは明日には時代遅れになる。やるだけ無駄だ」。この言葉をキャリアを通じて数え切れないほど聞いてきた。よく聞く言葉だが、間違っている。

時代遅れになるようなものは、スキルとは呼べない。キャリアを通じて「Jenkinsの人」として知られるのではなく、「ソフトウェア品質の専門家」として知られたいはずだ。ヒント：もしJenkinsが何なのか知らないなら、それこそが要点だ。自分のスコープを狭めすぎてはいけない。本当に必要なスキルは決して時代遅れにならない。

時には、会社の新しい方針のせいで、あなたの美しい作品が時代遅れになることもある。気が滅入る話に聞こえるかもしれないが、これもソフトウェアビジネスの日常だ。適応しなければならない。一つアドバイスできるのは、あまり深刻に考えすぎないことだ。プロジェクトは手放しても、そこで得た知恵は手元に残せ。変化を受け入れよう。

完璧ではない世界でソフトウェアを書く

プロのプログラマーは常に欠陥や不足と向き合わなければならない。このゲームの名前は「制約のバランスを取ること」だ。締め切り、予算、コード品質は、考慮しなければならない競合する制約のほんの一部に過ぎない。現実を前にすれば、エレガントな設計も色あせていく。結局のところ、ソフトウェアでお金を稼ぎたいのなら、出荷しなければならないのだ！

私の知る最高の開発者たちは、実用性とエレガンスのバランスを保っている。どの部分が重要で、どの部分がそうでないかを知っているのだ。そうでない者は、必要になれば取って代わられる。

私自身は、常にエレガンス寄りだった。それは完璧主義者だったということの、ちょっとマシな言い方に過ぎない。実用的な部分は、苦労して学ばなければならなかった。

経験の浅いプログラマーを指導する

プログラミングが上達すればするほど、コードを書く量は減っていく。

その代わりに、ソフトウェアアーキテクチャやハイレベルな設計について考えたり、他の開発者が取り組めるように仕事を小さな塊に分割したりすることにより多くの時間を費やすようになる。ジュニア開発者の指導を始めることになる。採用にも多くの注意を払う必要が出てくる。会議で時間を過ごし、ビジネスサイドの人々とプロジェクトの目標について議論するようになる。ある人はそれを仲介役と呼ぶかもしれない。別の人はマネージャーと呼ぶだろう。

ビジネスの表も裏も知り尽くすようになれば、あなたは会社にとって不可欠な存在になる。マネージャーにならないかと声をかけられるかもしれないし、少なくともプロジェクト管理が徐々に自分の責任の自然な延長のように感じられるようになる。しかし気をつけてほしい。このゆっくりとした緩やかなプロセスは危険だ。フルタイムのプログラマーに戻るのは簡単ではない。あなたがプロジェクト管理に忙しくしている間に、他の人たちはコーディングスキルを磨いている。自由時間に追いつこうとすることもできるが、それは難しい。

優秀な開発者が素晴らしいマネージャーになるのを何度も見てきた。キャリアのある時点で、それは自分自身で決めなければならない選択だ。

どちらの道を選ぶにせよ、コミュニケーションの方法を学ぶことに時間を投資する価値はある。その中で共感は大きな役割を果たす。チームでのソフトウェア開発は非常に複雑で、目標をすり合わせたり問題を伝え合ったりすることに多くの時間が費やされる。実際のところ、あなたがお金をもらっているのはコミュニケーションに対してなのだ。これにはドキュメントも、テストも、コード自体も含まれる。

他の人と話し、彼らの悩みに耳を傾けよう。自分がマネージャーになりたくないとしても、ソフトウェアプロジェクトマネジメントについての本を読もう。上司の役割を理解する助けになるはずだ。

お金についてのひと言

ITで働く理由はたくさんあるが、お金はその一つではない。

将来の給料を基準にキャリアの決断をしたくなることもあるだろうが、そうしてはいけない。とても不幸になる。毎日8時間以上、点滅するカーソルの前に座って過ごすことになるのだ。それは膨大な時間であり、時間はお金よりもはるかに価値がある。

誤解しないでほしい。給料のいい仕事はたくさんある。ただ、ほとんどの場合、大金持ちにはなれないだろう。一攫千金を狙いたいなら、私には力になれない。不動産でも見てみるといい……。開発者として金持ちになる唯一の方法は、とてつもなく難しいことに取り組み、膨大な時間を費やし、そして運に恵まれることだ。つまりスタートアップだ。覚えておいてほしい。ビル・ゲイツ一人の裏には千の失敗がある。もう一つの方法は、プログラマーをやめてマネージャーになることだ。それについては前のセクションですでに意見を述べた。

最後に

コードを読むこと（そしてできれば書くこと）を学ぶべきだとは思うが、プロのプログラマーとして働くことは誰にでも向いているわけではない。「それだけの価値はあるのか？」と問うかもしれない。私にとっては正しい決断だった。あなたが自分自身の決断を下す助けに、この記事が少しでもなれば幸いだ。