父親がデータベース設計を得意にするソフトウェア・エンジニアで、受託開発の会社を経営していました。私は大学在学中からその仕事を手伝っていて、その延長で大学を出るとその会社の一員になりました。

　そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数のSIerやソフトハウスが関わり、要件定義に時間をかけ、膨大な設計文書をつくっては、何千人というエンジニアを投入する、典型的な大規模システム開発です。私はそこにSEの一員として参加することになりました。

　ただ、私は初日から生意気にも「Excelで設計書を書き続けるために来たのではありません」と嘆願して、基盤フレームワークや共有部品を開発するチームのほうに配置換えをしてもらいました。やりたいことに近かったからです。

　2002年から2004年までそのチームのリードプログラマとして仕事をしていました。新しい技術を取り込むため、自分たちで洋書の技術書を買ったり、本棚を共有するような、自由な雰囲気がありました。仕事は長時間労働で毎日終電でしたけれど、行き帰りの時間を使ってたくさん本も読めました。私のプログラマ人生の中で、あれほど勉強した時期はなかったと思います。

　そのころはブログブームはまだ始まっておらず、もちろんTwitterもなかったので、技術者たちの議論といえば主にメーリングリスト（以下、ML)が中心でした。私もオブジェクト指向設計やXP（eXtreme Programming）関連のMLに参加するものの、当時の綺羅星のようなエンジニアたちの議論を、しばらくは発言はせずに読むだけ。実はこう見えても、結構シャイなほうなので(笑)。

　最初にMLに投稿したのが、XPやリファクタリングに関する書籍で知られるマーティン・ファウラーさんの技術ドキュメント「データベースの進化的設計」の翻訳だったと思います。大規模システム開発の合間を縫って、こつこつ翻訳していました。2003年の春のことだったと思います。

　MLの方々は、暖かく評価してくれました。学生時代から勉強会に参加することはよくあったのですが、自分がこうした技術コミュニティに貢献できたのはこのときが初めてでした。

　アジャイル開発第一期ともいうべき、プログラミングの新しい考え方が登場したのがちょうどその時期、90年代末からゼロ年代初頭でした。テスト駆動開発（test-driven development; TDD）という考え方に出会ったのも、そのころです。XPの考案者でアジャイル・マニフェストの起草者の一人、ケント・ベックさんの『Test-Driven Development: By Example』という本が出たのが、2002年（邦訳は2003年）でした。このあたりはやはりアメリカが本場でしたので、私も本家MLに参加して、議論をずっとウォッチしたり、TDD本の生原稿を読ませて貰ったりしていました。

　そのころの全体のトレンドとしては、TDDについてはまだ「プログラマが変なことを言っている」という受け止め方も多かったと記憶しています。そもそも私自身も、テストに苦手意識がありました。自分では、こう書けば動くと思ってコードを書いているわけですから、自分の未熟さがテストで発見されてしまうのは、情けないし、辛いことでもあったんです。設計やプログラミングは楽しいけれど、デバックやテストは可能であれば短めで済ませたい──当時はそう思っていました。

　しかし、これは一種の食わず嫌いでした。自動テストを書くようになると、そもそもテストもプログラミング対象になるわけですから、コードをたくさん書きたくてたまらない若いプログラマにとっては、実は面白い領域なんです。しかもテストコードは、プロダクトのプログラミングとはちょっと違った発想で書く必要がある。やってみると奥深いんですよ。

　たしかにテストコードを書けば、それだけでコーディング量は倍以上になるかもしれません。「倍も書かなければならないのか、いやだな」と思うか、「倍も書いていいの？　楽しいな」と思うかは、人によって違うと思うけれど、私は後者のほうだったんです。

　つまり、私の場合、品質を向上させるとか、工数を削減するという目的じゃなくて、よりプログラミングの楽しさ、奥深さを感じたくて、プログラマとしての本能のままに、テストコードを書き始めたようなところがあるんです。

　開発者が自らテストコードを書くことの利点はたくさんあります。TDDの考え方でテストを書いていくと、結果として不具合も減りますし、なにより設計そのものの良し悪しに気づけるようになります。テストが書きにくいプログラムというは、そもそも設計に問題があることが多いんです。翻って、テストを書きやすい設計は、個々の責務のハッキリした良い設計であることが多いのです。

　テストコードはいわばオブジェクト同士を話し合わせる場でもあります。設計というのは紙に書くだけでなく、テストコードの中でも行うことができる。それまでオブジェクト指向設計を学んできたつもりでしたが、TDDを通して、まさに実践的なオブジェクト指向開発が身についたと思います。

　テストを書くことが、プログラマのスキルを磨くことにつながる──そういう確信が自分の中に生まれ、それ以来、TDDを人に伝える活動を行うようにもなりました。

　10年にわたって、書籍や講演、勉強会、あるいは企業向けコンサルティングを通して、テスト駆動開発の普及に努めてきました。かつては講演で「自分でテストコードを書いたことがある人？」と聞くと、手を挙げる人はほんのわずかだったんですが、今は半分ぐらいは挙手します。最初は半信半疑でも実際手を動かして書いてみて、良いものだと思ったからそれが人づてに広がっていく。そういう流れが確実に生まれています。

　オープンソース・ソフトウェア（OSS）を使うことが多くなり、かつOSSのほとんどにテストコードが書かれているということも、こうした変化を後押ししているでしょう。いまや、ある程度腕のあるプログラマがテストコードを書くのは普通のことになりましたし、テストコードは一種のプログラマの「たしなみ」のようなものになったと思います。

　プログラマのボトムアップ的な動きに対応して、企業の取り組みも変わってきました。テストコード開発やバージョン管理、自動化の仕組みを積極的に導入し、自社の開発文化を新しくしたい。そのための教育研修などに、講師として招かれることも増えました。

　Web開発や自社サービス開発の会社が増えてきたことも、テスト駆動開発が市民権を得るために一役買っていると思います。納品したら終わりではなく、自分たちが書いたものを自分たちで世話をして育てていくことで、コードやシステムこそが重要な資産となる。そういう企業にはTDDの考え方はよくフィットするんですね。

　私にとってのプログラミングは、職業であり、趣味であり、自己実現の対象でもあります。何より楽しくて、ワクワクするもの。逆に言えば、自分が書いたプログラムを嫌いになったり、自分がプログラマを続けることがいやになったりすることがあるとすれば、これほど悲しいことはない。

　楽しさを持続するためにこそ、テスト駆動開発は必要だと考えています。プログラミングの楽しさの根源は、自分が動かそうと思って書いたコードが、実際に動いたという瞬間にあります。初めてプログラムを書いて「Hello World」と出力させたときや、初めてJavaScriptで動的に画面を動かしたときの興奮を覚えているでしょうか。テスト駆動開発はプログラミングが持つ、そのワクワク感をずっとキープするための、私なりのやり方だといえます。TDDとは私にとって、プログラミングを、自分のコードを好きであり続けるための「悪あがき」のようなものなんです。

　私は、良いコードとはきちんと動くきれいなコードだと考えています。少し表現を変えてみると「穏当な」コードのこと。すごいテクニックがふんだんに使われているというより、必要十分なだけ使われていて、プログラムがやるべき仕事のそれぞれについて、わかりやすい名前が付けられており、いかにも読みやすく、見ただけで「これは動く」ということがわかる──そういうコードのことです。

　ただ、ひとつ懸念があります。プログラマが自分でテストすることを義務化しているようなプロジェクトはたくさんありますが、ときにはテストが「仕事をした」ことの言い訳になっている場合もある。テストを書いたから仕事は終わり、となってしまう。私はそこに留まってほしくないんです。そこからこそが大事なんです。

　テストコードが、プロダクトやサービスの改善につながっていかないといけない。テストコードがコードの、そしてビジネス全体の改善に向けた「弾み車」にならないといけない。

　少々乱暴なたとえですけど、テストは体重計のようなものと考えてください。体重計を買っただけではダイエットできませんよね。それに乗っただけでもダイエットにはならない。体重計にできることは、人に体重の増減に気づかせることだけ。その気づきが、食事や運動を通して痩せるための努力につながらないといけない。そのような改善が行われてこそ、初めて、テストコードの意味があるわけです。

　これからプログラマとして生きる人のためにアドバイスがあるとすれば、とにかく「手を動かす」ことを挙げておきます。本を読んだだけ、人に聞いただけでわかった気になるのは危険です。自分で動かすこと。

　もちろん刺激を受けるためには、TwitterなどのSNSで、あるいは勉強会などに出て、自分の会社以外のプログラマと交流することも大切です。そこですごい人のライブコーディングを見る、ほかの会社のプログラミング文化に触れる、それを自分の手を動かして再現してみしましょう。そうすることで自分のプログラミングにも幅が出てくると思います。

　自分のスキルの多様性を保つことの重要性は、言語についても言えます。プログラマとして、できればパラダイムの違う複数の言語に触れることが大事だと考えています。例えば、自分がPythonやRubyなどのLightweight Language（LL）を普段使っているのだったら、HaskellやScalaに触れてみるとか。違う視点でプログラミングを学ぶと、自分の日々の仕事の棚卸しやコーディングスタイルの見直しにもつながります。

　私も書籍『達人プログラマー』の教えに従い、年に一つ、新しい言語を学ぼうとしています。雑誌『日経ソフトウェア』（日経BPマーケティング刊）の年初企画で「2014年はGo言語がキャズムを超える」と言い放ってしまったので、今年はGo言語を少し触っています。Goは昨年の段階で爆発的にユーザーが増えている印象がありましたし、Goで実装されたプロダクトもよく見るようになりました。だから、今年は来るぞと。

　Go言語は「あれもできる、これもできる」というように仕様や機能を詰め込むのではなく、不要だと思えるものは言語から外しているところに筋の良さを感じました。「引き算の美学」といってよいかもしれない。結果として言語仕様が小さくシンプルになり、学ぶことも書くことも容易になる。そういう言語が好きなんですよね。

　プログラマにとって必要なことは、より広く言えば、複数の分野を学び続けるということではないかと思います。私も、毎日テスト駆動開発のことしか考えていないかといえば、そんなことはないんです。昨年、ビル・カーウィンさんの『SQLアンチパターン』という本を監訳し、周りからはけっこう驚かれました。学生のころ父親に薫陶を受けて以来、データベース設計は私のもう一つの軸足なのですが、『SQLアンチパターン』を監訳するにあたってリレーショナル理論を再度学び直し、多くのものを得ました。

　ほかの人のコード、複数の言語、異なる分野の技術……そういった多様性に触れることで、自分を磨いていく。それを継続すれば、一生ワクワクしていられる。きっといつか、この仕事を選んでよかったと思えるんじゃないかと思うのです。