はじめに
「レガシーコード」――この言葉を聞いて何を思い浮かべますか？
もしかしたら、COBOLで書かれたコード、Windows NT 4.0用のコード、書いた人がわからなくなってしまったコードなどが思い浮かぶかもしれません。
しかし、このレガシーコードをメインテーマとして正面から扱っている書籍『Working Effectively with Legacy Code』（WEwLC ※1）では、レガシーコードについて異なった見解を示しています。そう、「明日自分の書くコードもレガシーコードになるかもしれない」というWEwLCが発するメッセージは、私たちに切実に迫ってくるのではないでしょうか。
この連載では、WEwLC読書会の有志が、WEwLCが語りかけるものや、現実の課題への活かし方などを対談形式で紹介していきます。この本が発するメッセージについては連載の中でおいおい明らかにしていきたいと思います。まず初回となる今回は、WEwLCに出会う前に各人が抱えていた課題や WEwLCとの出会いなどについて語っていきます。これにより、有志の面々がWEwLCによって変わる前に直面していた課題を明確にしていきたいと思います。
実プロジェクトで遭遇したエンバグと引き継ぎの問題（中谷）
テストの必要性はわかっていたけれど…
川西：第1回目のテーマは「レガシーコード前夜」ということで、WEwLCに出会う前に遭遇していた課題や、WEwLCとの出会いなどについてお聞きしたいと思います。 WEwLCに出会う前に、テストとか品質といったものに対してどういう課題を抱えていたかとか、うまく取り組めていなかった部分とか、もともとどういう印象を持っていたかとか、そういう事柄について語り合えれば良いと思っています。
ではまず中谷さんから、もともと抱えられていた課題はありましたか。
中谷：まずはユニットテストですかね。必要性はとても強く認識できていたんですが、なかなか習慣づけられない。
テストがないとバグを作り込んでしまうというのは感じていて、後で痛い目に遭うので書かないといけない、書けば楽をできるかもしれない、そういうのは頭ではわかっていました。ただ、いざ開発が始まると、納期などいろいろ言い訳してしまうんですよね。
すでにテストを書いていないコードベースが大量にあるのに、「ここだけテストを書いてもな」という意識が働いてしまったり、それでも「やっぱり必要だから」と思って、実際に新しく開発したコードにテスト書いてみたりしても、いまいちピンとこない。
読書会でもよく論点として挙がっていましたが、「ここにテストを書くのでいいのか」とか、「privateメソッドのテストできない」などという問題がありますよね。それから、テストの項目についてもどこまで網羅性を求めていくのか─なにしろ、すでにテストを書いてないコードが大量にあるのでカバレッジとかあまり意味ないんですよね。指標がない。
かといって、そのコードを外に見せて「どうすればいいですか」なんて相談できるわけもなく、「理屈では必要であることは大変強く認識しているけど、でもどうしたらいいのかさっぱりわからない」という状況でした。
川西：この辺りは難しい問題ですよね。みなさん共通の悩みだと思います。
和田：テストを書かないとレガシーコード増える一方ですもんね。もちろん、WEwLCを読む前の「レガシーコード」という言葉の意味づけは違っていたかもしれませんが。
中谷：WEwLCを読む前は、テストがないコードを呼ぶ名前がなかったので議論のしようもなかったですね。テストを書いた方がいいのはわかるけど、テストを書かないのが悪いことだとはわからない。
川西：書かないことで何か具体的な問題があったのでしょうか？
中谷：やっぱりエンバグですね。特に複数人で開発していると、各メソッドがどういう仕様なのか必ずしも細かいところまで理解しているとは限らないので「動作確認」する場合でもいろいろ抜けてしまって。
高橋：自分が変更したものの影響範囲も、「このあたりのはず」くらいの当たりを付けて、作業を始めちゃうこともありますからね。
残すもの、残されるもの―引継ぎの問題
中谷：それから、デブセン[2]にも出てましたが、転職することになった時に、引き継ぎでどれだけのものを残せばいいのかわからないという問題が出てきました。
実際、それまでいくつものプロジェクトを引き継いできた経験では、どれだけドキュメントを残してもらっても、結局読むのはソースでしたね。逆に残す側になった時に、そのころには大量のコードのうち自分が書いた量が一番多くなっていて、「そのドキュメントを書くってうわあどうしよう」となりました。その頃は、まだテストがドキュメントになるという認識もなく、できるだけのことはしたつもりですが、やっぱりきっと「あんまり役にたたないなあ」とか思われてるのかもなあ、と申し訳なく感じていました。
高橋：そういう前夜だった中谷さんがこの本に出会って、最初に目を通した時にどう思ったかを聞いてみたいですね。
中谷：出会ったきっかけは、実は「RESTful Web サービス」の読書会です。
高橋さんの[3]RESTful読書会に関するブログの記事に和田さんのWEwLCに関する記事へのリンクが張ってありました。和田さんの記事はそれ以前に見ていたんですが、そのときは詳細についてはスルーしていました。ただ、高橋さんのリンクをきっかけにもう一度読み直してみたらWEwLCという本が気になって、実際に目次を見て「自分のことが書いてある！」「これは読まねばなるまい」と感じたのが読書会参加の動機です。
高橋：やっぱり目次って重要だなぁ。
OSSと実務のギャップ（大中）
Seasarでの経験と業務での経験
川西：続いて、大中さんのWEwLC前夜について伺います。
大中：私は今まで開発途中のプロジェクトに途中から入ることや、派生開発／二次開発で入ることが多かったので、やはりテストがないと、その時点でビハインドでスタートになることは感じていました。テストがないコードを修正して、手動でテストすると、どうしてもカバーしきれない部分が出てくる。テストを書けばバグがなくなるとは限らないですが、テストを書いてない部分にはどうしても一定量のバグが残っているという実感があります。
それから、私の場合はSeasarのコミッタをやってまして、その中でも特にSeasar2やS2Daoといったプロダクトは、しっかりテストが用意できています。ですから、テストハーネス[4]に守られながら確認しながら開発ができるということのメリットはわかっていました。ただ、実務の方だとそれがなかなかできない、そのギャップに悩んでいたという感じですね。
中谷：みなさんそうだと思いますが、「仕事だとできない」ってのが不思議ですよね。
大中：Seasarの場合は、Mavenでビルドするから、テストが通らないとそもそもリリースできないんですよね。
川西：なるほど、ある意味強制力が働いていたということでしょうか？
大中：そうですね。手を入れる部分にもともとテストが用意されている場合に限ってですけれども。OSSでもテストが用意されていないプロダクトもあって、あることをきっかけに見直したらボロボロバグが出てきて、半泣きになりながらテスト書いたりもしましたので。
中谷：でもMavenによる強制力というのが理由なら、仕事でもMaven使えばいい、で済んでしまいますよね。
川西：確かに。どちらかというと、大中さんが経験されたOSSでは、「強制力」というよりも「テストを書くきっかけ」があったということでしょうか。
大中：テストを書くきっかけという意味では、フレームワークやO/Rマッパなどは機能にひもづく画面がなく目視では確認できないので、動作確認として自動ユニットテストを書くのが自然になる、というのが挙げられるかもしれませんね。
和田：それ、ありますね。
高橋：テストを書かないと動作確認できませんから。そのためのダミーアプリとか作るほうが大変ですし。
川西：作っているものの性質として、ユニットテストを書くのが自然だったということでしょうか。ただ、業務では違ったのでしょうか？
大中：違ったのだと思いますが、WEwLCを読む前の時点だと、何が違うのか認識できてなくて、悶々としていたという感じの方が強いですね。
仕事でも自分の担当部分だけはなんとかしようとしていた時もあったのですが、工数にテストを書く部分が組み込まれてないのでスケジュール的にタイトになることと、チーム全体にテストを書くことのメリットをうまく伝えきれなかったということがありました。全体の流れを変えるところには、なかなか至らなかったです。
WEwLCとの出会い
川西：そのような時に、WEwLCに出会ったということでしょうか？ きっかけは、先ほども話題に出ていた和田さんのブログ記事？
大中：はい。その記事はコメント欄が大炎上するほど盛り上がっていて、「これだけ盛り上がっているのを無下にするのももったいないよな」と思って……。
和田：手を挙げたと。すばらしい。英雄ですね。
大中：「Restful Webサービス読書会」の懇親会の帰り道に、和田さんに相談したと記憶しています。
和田：あ、そうだったかもしれないです。即答でお願いしたと思います。
xUnitでのテストを使い始めるも…
PHPでの経験（高橋）
川西：それでは引き続き、高橋さんにお伺いたいと思います。
高橋：長らくPHPを使ってWebアプリケーションを作ってきてるんですが、経験した中では「テストといえばブラウザをたたくことでしょ？」というのがほとんどのチームのやり方でした。先ほども話題に出てましたが、下のレイヤを作るためにxUnitなどのテスティングフレームワークを使うというよりは、ドライバの出来損ないのようなものを書き捨てていた状態が多かったです。「それじゃいかんなぁ」とxUnit系をちゃんと使おうと思って、和田さんの記事などを見ていました。これを小さな新規案件とかで試してみたら、想像以上にうまくいったので「これだ！」と。
PHPの開発案件って、意外とリプレースの案件が多くて、特にこの数年だとPHP4で書いたコードをPHP5に対応させることも含めて、リプレースが多いんですよね。社内のメンバーが作ったものではなく、全く別の会社が作ったソースを元にするということもあったりしました。「こんなのどうしたらいいんだよ……」と途方にくれていたのが、WEwLCを読む前夜でしたね。
中谷：全く別の会社が作ったコードをメンテするって、Web系だとよくありますよね。
高橋：ですね。まぁ、自社のコードでも似たようなことは多々あるんですけど。PHPのような言語で作った案件でも、短納期で寿命が短いと思っていたら、ずっと使われてることがよくあるんですよね。それで結局、つぎはぎだらけのコードが回ってくることになります。
開発者テストの良さを伝える難しさ
高橋：あとは、他のメンバーに開発者テストの良さを説明するには、新規案件にだけ役に立つということでは説得力が弱かったという問題もありました。それを何とかしたいなぁというのもありました。
川西：結局、仕事でxUnitを使うというのが理想論で、現実論になりづらかったということでしょうか。
高橋：そういう状態でいたときに読んだのが、和田さんのブログの記事でした。「新しいコードをTDDで書き始めるのは良い。では、今あるコード、テストコードの無いコードはどうすればいいの？ というTDD界隈の最大級のFAQに真正面から立ち向かっている本です。」というブログの言葉に「おお！」っと思いました。
ということで、私も本を買ったのは読書会開催決定後ですね。
炎上プロジェクトを繰り返さないために（川西）
テストに興味を持つ
川西：自分の場合は、炎上プロジェクトをきっかけに、何年か前からテストについて勉強するようになったのがそもそものきっかけなんですよね。
高橋：川西さんがフォーカスされていたテストは、ここにいるほかのメンバーとはちょっと違いますよね？
川西：そうですね。ここでは品質関連のテストですね。ただ、始めはあまり違いがわかってなくて、とりあえずテストというキーワードでいろいろ勉強しました。自分の場合は、はじめに出会ったのが開発者テストのコミュニティではなく、品質関係のコミュニティだったということです。
開発者テストへの興味とWEwLC
川西：ただ、TDDとか開発者テストにも凄い興味があって、和田さんの記事などを読んだりはしていました。その一環で、Developers [Test] Summitというイベントに参加したんですね。その後、出演者の方々のブログを見ていたら「読書会が実現に向けて動き出しました」と書いてあり、 WEwLCに出会ったという感じです。
もともとうちの部署では、ほぼ100％が既存コードの機能追加の案件です。自分たちが作成した部分以外にはユニットテストがないので、「WEwLC＝テストのないコードテストを書くための本」というところに魅かれて、本を読んでみよう、さらに読書会に参加してみようとなりました。
中谷：品質関連のテストから始めてTDDにたどり着いたというのは、何だか不思議な感じがするんですが、特に魅かれたポイントはなにかあったんですか？
高橋：QAテストでバグを発見しても手戻りが大きいから、「もっと前でつぶしとけ！」と思ったとか？
川西：品質関係のテストをしたいということよりも、プロジェクトを炎上させたくないというのが、もともとのモチベーションでした。だから、品質のためのテストとか開発のためのテストとかに、あまりこだわらずやろうということだったと思います。
高橋：川西さんの場合は、部署の他のメンバーにも勧めてたんですよね？
川西：勧めてはいたんですが、結局、自分以外の人がやり始めたのは最近ですね。
高橋：最近でもやり始めている人が出ているのがいいんだと。
xUnitを使う中でのレガシーコード問題（和田）
和田：私もWEwLCに出会う前夜のことを話せばいいですか?
高橋：そうですね。お願いします。
チームかくたに時代
和田：実はよく覚えてないんです（笑）。
たぶんWEwLCが出版されたのは、2004年終わりごろだったと思います。それから、角谷さんとWEwLCのことを喋った記憶があります。となると、本を買ったタイミングは、私がまだ「チームかくたに」（※5）にいたころで、本が出てすぐだったのではないかなと思います。
もともと著者のMichael Feathersの名前は、たしかC2.comやTDD本家メーリングリストなどで知っていました。当時、TDDやリファクタリングの議論はC2.com とYahooGroupsで行われていて、それを購読していたので、WEwLCを書いているのが誰であるかは知っていました。
その上で、実際に本を読んで嬉しかったのは、中谷さんが最初の方で言っていたことと同じで、レガシーコードの問題や解法に関して共通の語彙が手に入ったことでした。ひとつひとつのdependency breaking techniqueや方針は、TDDをやっている人の間ではある程度知られていることだったのですが、名前がなかったなかったというか、それぞれ勝手な名称で呼んでいる状況でした。
川西：なるほど。WEwLCは共通の名称がないことによる言葉の混乱が起こる前に、手を打ったわけですね。
和田：そうです。
それから、角谷さんとは、「"To me, ... " と書かれているのが清々しい」と話した記憶があります。
WEwLC自体は出てからも日本では全然脚光を浴びなくて、Jolt Awardにもノミネートされるかと思ったら全然されないし、日本で書評といえばomoさんと、あとどなたかがブログに書いていたくらいでした。
java-jaの講演とブログのエントリ
和田：その後、java-jaに行ってTDDとペアプログラミングの講演をしたときに、「テストのないコードがもうあるんですが」という質問を受けてWEwLCの書名を出して説明しました。ただ、資料には書いてなかったのでブログに書きました。そしたら炎上した。
川西：日本ではWEwLCに着目をしている人はいたかもしれないけれど、しばらくはあまり表に現れてこなかったという感じでしょうか。その炎上ブログ以前は。java-jaでご質問された方も、その場にいらした方も、WEwLCは初めて聞かれたという感じだったのでしょうか？
和田：そうです。それまではややマイナーな本の部類なのではないかと思います。タイトルが良くなかったのかも。ちょっと前までは、シリーズ買いとか著者買いするタイプの人でないと手に取らないかもしれませんね。今では定番本と呼ばれるまでに地位が向上しているといいなと思いますが……。
xUnitのコミュニティの中でのレガシーコード問題
川西：少し話は戻るのですが、WEwLCで提起されているような問題は、もともとTDDをされていた方々は意識されていたという理解でいいのでしょうか。語る言葉がなかったというだけで。
和田：TDD MLではいつも「これってどうやってテストする?」という議論をやってたので、テクニックのいくつかはよく知っているものでした。TDD MLはこれテストできないんですという議論が多かったので、テストファーストという議論とは別に、テストしにくいもの、テストがないものをどうするかという議論をしていました。
川西：なるほど。「これってどうやってテストする?」の「これ」というものの中にレガシーコードが時折、あらわれてきていたということでしょうか。
中谷：「どうやってテストする」ということはテストが書かれてないコードがそこにあるということだから、だいたい全部レガシーコードでは？（笑）
和田：そうそう（笑）。TDDではないですが、xUnitを使った自動化の対象としては、レガシーコードも該当するんでしょうね。
そういう質問や議論にRon Jeffriesとか、Kent Beckとか、Dave Astelsとか、J.B Rainsbergerなどが答えてたのがTDD MLやJUnit MLでした。
高橋：豪華メンバーだ……。
川西：「すでにあるコードもTDDで開発されていてテストがあるのが理想的」なんだけれども「現実世界にはすでテストされていないコードがある」という中で、テストされていないコード（レガシーコード）を全部捨てて、TDDで書きなおすこともできない。だから現実的には、「レガシーコード対策のような xUnitの使い方も必要というだ」ということでしょうか。
高橋：「必要だと思っているけど、やり方がわからないからテストしないという流れを断ち切らないとね」ってことですかね。テストしないで痛い目にあってるわけだし。
和田：レガシーコードに後からテストを書くというのは、xUnit源流の考えではないです。ただ、既存コードをテストしやすいようにするコード改変テクニックという形で知識が集まってきたような記憶があります。xUnit自体はKent Beckが作ったものですからTDDのためのものという側面が強いです。まあTDDという言葉はxUnitが出来てからかなりあとの産物ですが。
川西：なるほど。いずれにしろ、WEwLC前夜のうちから、 xUnitのコミュニティの中で「このテストどう書くの？」という形で、レガシーコードの話題が出てきていたわけですね。
まとめ
以上が第1回となります。いかがだったでしょうか、皆様も既存のコードについて同じような問題をもたれているのではないでしょうか。今回話したメンバーも含めて、たくさんの人たちが集まって、読書会で実際にWEwLCを読んだわけですが、読んだ結果それぞれのメンバーが今どう思うか？ 現実の課題にどう適用できそうか？ ということについては次回以降に明らかにしていきます。
さて、次回は、その課題を解決するための道を開くための、WEwLCの基本的な考え方について話していく予定です。
