掲載日:2014.11.10
このエントリーをはてなブックマークに追加

三年予測ートップリーダーと考えるエンジニアの未来ー

プログラミングを楽しくする手段としてTDD(テスト駆動開発)を広めたい

プログラマ 和田卓人

プログラマ。タワーズ・クエスト取締役社長。TDD(テスト駆動開発)の伝道師として知られる。学生時代からオブジェクト指向分析・設計に傾倒。父親の会社を手伝う形でプログラマとして働き始める。XP(エクストリーム・プログラミング)を実践する人々との出会いがきっかけでTDDの誕生を知る。TDDの伝道師としての活動を10年以上続けている。TDDのシンボル、グリーンバンドを左手に付けている。


「コードを書けないなら帰ります」

和田卓人には、あるエピソードがある。公共系の大規模プロジェクトにSE(システムエンジニア)として呼ばれた面接の場で、Excelによる仕様書などの文書作成が主な業務だと告げられると、「コードを書けないなら帰ります」と言い放ったのだ。2002年のことで、和田はまだ20代半ばだった。
「若かったと思います。特に生意気な性格だったわけではないのに、なぜかその時にはそう言えた」
ここで本当に帰ってしまったら、日本のTDD(テスト駆動開発)の歴史は変わっていたかもしれないが、そうはならなかった。「方式チーム」と呼ばれていた、壁際の異色の一角に目が止まった。ホワイトボードの書き込み、机の散らかりよう、本棚に技術書が目立つことなど、明らかに他のチームとは「匂い」が違う集団だった。とっさの判断で「このチームならやってもいいです」と和田は伝え、そのようになった。
この方式チームは、巨大プロジェクトの中でフレームワークの開発や整備など共通技術を手がける役割を持っていた。和田はこのチームでプログラマとして腕を振るい、やがてリードプログラマに抜擢された。
「あの一瞬に妥協しなかったのは良い選択でした」
常識的な考え方では、受託開発の巨大プロジェクトの中で仕様書など文書を作成しプログラマを管理する仕事は、プログラマよりも「上流」の仕事であり、待遇も良いはずだ。だが、和田はプログラマとして能力を発揮できる道を選んだ。今もその姿勢を守り続けている。
このチームで、TDD(テスト駆動開発)の基本である、「テストコードを書きながら開発する文化」をチームに伝える経験を得た。その後10年以上にわたり「TDDの伝道師」としての役割を続けることになる。

「テストもプログラミング対象にできるんだ!」

「テスト」という言葉に、苦手意識を覚える人もいるかもしれない。ソフトウェアテストといえば品質管理の手法であり、プログラマにとっては面倒で厄介な存在だととらえられる場合もある。
実は、かつての和田もそうだった。「自分は生粋のプログラマだと思っていた。コードを書くことは好きだったが、テストは嫌いだった。テストで動作を確かめる手順を迂遠に感じたり、自分が書いたコードが壊れているわけがないと自信過剰だったりしていた」と振り返る。
TDDとの出会いは、JUnitに触れたことだ。JUnitは、TDDの提唱者ケント・ベックらが開発した、Java言語向けのユニットテスト用フレームワークである。
「衝撃を受けた」と和田は当時の印象を語る。
JUnitでは、テストをプログラム本体と同様にコードとして記述する。プログラムを作る際に、プログラムが取るべき挙動をプログラミングできるのだ。
「テストもプログラミング対象にできる!」
今では当たり前のように普及している概念だが、この当時は衝撃的な発見だった。
「プログラミングが楽しくてしょうがない年頃だった。楽しめる領域が広がると考えました」
和田は、プログラミングを楽しむだけでなく、テストをも楽しむことを発見したのだ。

教条主義的なTDDは「好きじゃない」

アジャイル開発手法は議論が多い分野だ。TDDにも、批判の声が上がることがある。
和田は「自分が伝えているのは、狭義のTDDというわけではない」と話す。TDDの範囲を狭く考えると、「必ず最初にテストを書く」「失敗するテストを書くまではコードを書いてはならない」といった教条主義的な考え方に向かってしまう。「それはものすごく窮屈で圧迫的。開発が楽しくなることにつながっていない。TDDをルールとしてとらえる考え方は僕自身は好きじゃない」。
「テストを書くこと」をルールとしてとらえ、人間を型にはめていくと、「一人一人の創造性が死んでしまう」。最悪の場合には、コードの規模が大きくなりすぎてテストの保守が大変になりすぎ、改善をやめよう、という皮肉な状況が生じかねない。「それはTDDが死んでしまった状況」だというのだ。
「プログラミングを楽しくしようと思ってテストを書こう。そうすれば、テストが改善をぐるぐる後押ししてくれる」。プログラミングという人間の営みが持つ「楽しさ」、プログラミング本来の「原始的な強み」を引き出すために、テストを書くのだ。

TDDのDは「ドライブされる」のD

和田は、TDDは「テストに引っ張られて、開発に弾みがつく」手法だと説明する。「TDDのDはdriven(駆動される)のD、テストが開発のリズムを作り、引っ張っていく」。
「テストファーストがTDD(テスト駆動開発)になったことには、大事な意味があります」。XP(エクストリーム・プログラミング)のプラクティスとして「テストファースト」という言葉がまず有名になった。ここからTDDという概念が生まれた。「『テストファースト』という言い方だと、テストを先に書いて、コードを書いて終わりだと思われてしまう。TDDは、テストを書くことによって、設計が変わったりコードが変わったりするところに大きな意味がある。テストが、気付きを得て方向修正をする際の触媒になる。だからテストが開発を『駆動』するんです」。
テストが存在することにより、プログラムの大胆な修正、変更を恐れずに、自信を持って開発を進められる。TDDは、プログラム本来の楽しさを損なわず、味わいながら開発をドライブしてくれる。これが和田の考えなのだ。
TDDは1人でも始められる
このエントリーをはてなブックマークに追加

Vol.4 プログラマ兼経営者 登大遊氏

「"ハック"精神を貫き「低レイヤー」の技術に注目した製品群を送り出す
天才プログラマ兼経営者がつくば市で会社を10年続けている理由」

Vol.9 レッドコーダー 秋葉拓哉氏

日本の競技プログラミングを世界水準に引き上げる

Vol.12 経営者 清水亮氏

すべての仕事はプログラミングになる、だからハードを作る

Vol.3 UI研究者 増井俊之氏

「遅いスタートを乗り越え、発明家の目線を持ち続け、
Appleからも招聘されたUI研究の第一人者が若い世代に贈るメッセージ」

Vol.6 計算機科学者、未踏統括PM 竹内郁雄氏

Googleも欲しがった「実時間GC」を作り上げた
日本有数のハッカーは今、若い人材の発掘に情熱を燃やす

Vol.13 プログラマ 増井雄一郎氏

ITの変化は激しい、だから個人にチャンスが巡ってくる

DODAエージェントサービス 専任のキャリアアドバイザーが、キャリアアドバイスから求人紹介、退職フォローまでを一貫してサポートします。ご利用になりたい方は、こちらからご登録をお願いします。はじめて退職する方のために3分でわかるエージェントサービスのメリットを紹介 エージェントサービスに申し込む(無料) 3分でわかるエージェントサービスのメリット