• はてなブックマークに追加
  • Yahoo!ブックマークに登録
ギークエンジニアたちの哲学 vol.4
テストコードを書く文化を
     根付かせたい─和田卓人
日本におけるテスト駆動開発(TDD)のスペシャリストとして知られる和田卓人氏。講演活動やハンズオンイベントを通してテストの重要性を語り続けている。その深奥にあるプログラムの哲学とは──
(取材・文/広重隆樹 総研スタッフ/馬場美由紀 撮影/佐藤聡)作成日:14.03.31
大規模プロジェクトの中で

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

 そのころのことで一番印象に残っているのは、電子政府関連の公共システム開発に関わる大規模プロジェクトへの参加です。複数の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アンチパターン』を監訳するにあたってリレーショナル理論を再度学び直し、多くのものを得ました。

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


和田 卓人氏
和田 卓人氏 タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者
学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後ソフトウェアパターンやXP(eXtreme Programming)の実践に触れ、テスト駆動開発の誕生を知る。執筆、講演、ハンズオンイベント、企業向けコンサルティングなどを通して、テスト駆動開発の普及に努めている。トレードマークは、左手に付けたグリーンバンド(テスト駆動開発者の証)。『プログラマが知るべき97のこと』『SQLアンチパターン』(共にオライリージャパン)を監修。
  • はてなブックマークに追加
  • Yahoo!ブックマークに登録
あなたを求める企業がある!
まずはリクナビNEXTの「スカウト」でチャンスを掴もう!
スカウトに登録する

このレポートの連載バックナンバー

ギークエンジニアたちの哲学

熱い活躍を続けるギークエンジニアを仕事へと駆り立てているのは、どんな想いなのか。彼らキャリア観と、仕事や技術にかける想いを伝えます。

ギークエンジニアたちの哲学

このレポートを読んだあなたにオススメします

我ら“クレイジー☆エンジニア”主義!

なぜコードを書き続けるのか?ギーク増井雄一郎の原点

我ら“クレイジー☆エンジニア”主義!「Titanium Mobile」の伝道師、「MobiRuby」「Wri.pe」などの開発者として知られる、増井雄一郎…

なぜコードを書き続けるのか?ギーク増井雄一郎の原点

学生・社会人の枠を超え、競技プログラマの世界一が決定!

CODE VSが示すプログラマに必要な戦略と問題解決能力

7月21日(日)、六本木「ColoR」で、アルゴリズム活用力とコーディング技術を競い合うプログラミングコンテスト「CO…

CODE VSが示すプログラマに必要な戦略と問題解決能力

大興奮!「落ちゲー」アルゴリズムの熱き戦い

学生プログラマ日本一は誰?「CODE VS」決勝戦に潜入

学生プログラマ日本一の座を賭けた「CODE VS 2.0」の決勝トーナメントが、1月19日、六本木・ニコファーレで開催…

学生プログラマ日本一は誰?「CODE VS」決勝戦に潜入

明日に向かってプログラめ!!

倉橋浩一@WebObjectsは、YS-11を心より愛す

明日に向かってプログラめ!!旅客機の「YS-11」をご存じでしょうか。多くの人に惜しまれながら昨年9月30日に最終飛行を終えた、国産の双発プロペラ機です。そ…

倉橋浩一@WebObjectsは、YS-11を心より愛す

キーワードは「自由度」「スピード」「マルチタスク」

Webエンジニア「35歳限界説」は本当か?

SI業界を中心に長年囁かれ続けてきた、プログラマを中心とした35歳限界説だが、ここ数年で急速な成長を続けているWeb業…

Webエンジニア「35歳限界説」は本当か?

広める?深める?…あなたが目指したいのはどっちだ

自分に合った「キャリアアップ」2つの登り方

「キャリアアップしたい」と考えるのは、ビジネスパーソンとして当然のこと。しかし、どんなふうにキャリアアップしたいのか、…

自分に合った「キャリアアップ」2つの登り方

この記事どうだった?

あなたのメッセージがTech総研に載るかも

あなたの評価は?をクリック!(必須)

あなたのご意見お待ちしております

こちらもお答えください!(必須)

歳(半角数字)
(全角6文字まで)
  • RSS配信
  • twitter Tech総研公式アカウント
  • スカウト登録でオファーを待とう!
スマートグリッド、EV/HV、半導体、太陽電池、環境・エネルギー…電気・電子技術者向け特設サイト

PAGE TOP