変化に適応するために開発者がしてきたこと 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （１）
13年前のプロジェクトの体験談からテストを用いた「変化ヲ抱擁セヨ」の本質を読み解く
はじめに
今回から、数回に渡り、昨年１２月に行われた『テスト駆動開発』翻訳者の和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談記事をお届けします。
お二人は、１０年以上前に、当時はまだ珍しかったアジャイル（エクストリームプログラミング）プロジェクトで、同じチームで開発に取り組んだ仲間です。
お二人の対談を通じて、当時のプロジェクトの思い出を皮切りに、「１人のエンジニアとして腕を磨き本当にいきいきとお仕事を行えているのか」「プログラミングの技と魅力を次世代に伝承できているのか」そしてその結果としての「健全なビジネスの継続的成長のための健全なコード」という『時を超えたプログラミングの道』のテーマについて、存分に語っていただきます。
（司会進行／賑やかし：天野勝、懸田剛）
どうぞお楽しみください！
対談スタート！！
懸田：今日のテーマ、お願いします。
天野：お願いします。
和田：『健全なビジネスの継続的成長のためには健全なコードが必要だ』
懸田：（仮）仮説。
和田：『健全なビジネスの継続的成長のためには健全なコードが必要だ』というテーマですね。
懸田：そうですね。
天野：お願いします。
まずは軽く自己紹介
天野：本日の流れとしましては、まず最初、お二人が何者なのかというところでですね、和田さんと家永さんと、あとは、二人の関係も少しお話しつつ、対談ということで、伝説のXPプロジェクトのその後を語るみたいな感じで、スッと流れていただけると。
和田：分かりました。好きなだけしゃべります。
和田：じゃあまず自己紹介から。
家永：どっちから行きますか。
和田：じゃあ僕からで。自己紹介で和田卓人といいます。ネット上だとt-wadaさんと呼ばれていて、はてなはハイフン(t-wada)でツイッターはアンダースコア(t_wada)で、Githubはどっちも無い(twada)という。一番最初にハイフン使ったがためにすごく間違い易いID運用を強いられる羽目になったんですけれども、ハイフンのt-wadaさんになったのは、実はこの永和さんのプロジェクトがきっかけなので、ちょうどそのイニシャルの土地に戻ってきた。
家永：はてなブログ
和田：はてなダイアリー。ブログじゃなくてダイアリー、日記、Web日記というので、僕の何て言ったらいいんですかね、ネット上での僕のアウトプットの始まりとなるプロジェクトと、その時の仲間と対談できるというのは、ちょっと何て言うかな、熱い感じです。上がっている感じです。
和田：最近で言うと、オーム社さんから『テスト駆動開発』という本を出しまして、僕は、翻訳をしたんですけど、一度絶版になったケント・ベックの『Test Driven Development by Example』という本を新たにゼロから訳し直して、付録も追加で書いたんですけど、これはきっと後で話出てくると思います。なので、今、まさに『テスト駆動開発』を再度自分の中で咀嚼して再評価して、みんなに伝えるという２周目、３周目ぐらいの啓蒙フェーズに入り始めたところです。今日はよろしくお願いします。
家永：よろしくお願いします。
和田：はい、あなたは誰ですか？
家永私は家永英治と申します。永和に2003年に入って、最初は今そこにいるボスの天野と仕事をしていました。だけど、開発プロジェクトの経験が無かったので、開発の方をやらせてほしいという事をリクエストをさせてもらって、２番目のプロジェクトとして、ちょうど和田さん、角谷さんが入っているプロジェクトに参加させてもらいました。そこで初めてエクストリームプログラミング（XP）や、テスト駆動開発（TDD）みたいなものを直接ペアプロ（グラミング）という形や、あるいはホワイトボード（を使って）設計を一緒にやるなど、頻繁に対話しながらやるというのを参加させてもらったというのがきっかけです。
家永：最近は、ロール的にはスクラムの登場でアジャイルコーチというニーズが増えてきたので、それでアジャイルコーチという形で（プロジェクトに）関わらせてもらったりとか、あるいはもう一度開発側に戻る形で実際に開発をやったりしてます。最近は、プロダクトオーナー（PO）の支援みたいな仕事をする事が多いです。今日はよろしくお願いします。
和田：よろしくお願いします。
二人の馴れ初めは「伝説のXPプロジェクト」
天野：馴れ初め的な感じは何ですかね？
家永：たぶん僕が入ったのは2004年だったかな。５年だっけ、忘れたな。
和田：アジェンダに「伝説のXPプロジェクトのその後を語る」と書いてあるんですけど、いわゆる「伝説のXPプロジェクト」というやつが、僕と家永さんが同じチームに入って行っていたプロジェクトで、
家永：リーダーが、角谷さんがいて、
和田：そうですね、角谷さんがリーダーでやっていたという形で、僕がそのプロジェクトにジョインしたのが、2004年の７月１日だと思うので。
家永：じゃあ2005年だな、僕は。
和田：2005年ぐらいかな。
家永：たぶん2005年の２月ぐらいに参加したので、２、３月中旬に参加して、和田さんとかぶっていたシーズンは、たぶん半年、
和田：もうちょっと長かったんじゃないかな、どうだろう？僕が１年半いたので、だから2005年いっぱいぐらいはいたと思うんですね、きっとね。そのへんで一緒にやっていたということですかね。
家永：当時、入っていた時は、ちょっとビビったね。
和田：ビビったというのは、怖いという意味？
家永：怖いというのもあったし、これレベル高いなぁと思った。ちょっと背伸びしながらいろいろやっているとこはありましたね。
和田：家永さん途中からジョインしましたからね。メンバーの入れ替えみたいなのがあって、１回目の入れ替えがあって、２回目の入れ替えで家永さんが入ってきたんじゃない？
家永：はい、はい。
和田：なので、その時すでにもう動作しているコードがあって、ドメインモデルみたいなのがあってみたいなところから途中から入るという話だったので、そういう難しさみたいなのはきっとあったと思います。
家永：和田さんにはちっちゃいホワイトボードの何か手持ちA4サイズかB5か忘れましたけれども、あれにこういう設計になっているんだよというのを丁寧に（描いて）説明してもらったりとか。
和田：そうですね。
伝説のXPプロジェクトは「全部入り」
家永：実際に一緒にペアプロという形で開発をするっていう。当時、４人いたのか。４人で頻繁にペアプロを交代しながら？
和田：そうですね。基本的に、XPというアジャイルソフトウェア開発のとても、少なくとも当時すごいホットだったプロセスに割と純粋に準拠したというか、全部入りでやってみようみたいなプロジェクトで、それがそのビジネスオーナーの方、プロダクトオーナー（PO）の方の要望でもあって、
家永：POが何かXPをすごい気に入っていた。
和田：そうそう。なので、全部入りでやってみよう、と。だからプランニングミーティングみたいなのやるし、テスト駆動開発をするし、ペアプログラミングをするし、何ならメタファー（※1）も使うしみたいな感じで。
（※1：『Extreme Programming Explained』の初版で紹介されていたプラクティス。システムのアーキテクチャについて関与者で考えたり共有する際にメタファー（隠喩、たとえ）を使うというもの。第二版では削除された。）
家永：同席まではできなかったけど、POがこちらにわざわざ訪問してもらって、その後にたまに座席に一緒に来て。当時、技術的に、道具立てがよく分からないから、一緒に見てもらうみたいな、そういうことが頻繁にできてたチームだったかなと。
和田：そうそうそうそう。（プロジェクトの）位置付け的には、実はたぶんもうちょっとでっかいプロジェクトの一部みたいな形だったので、でっかいお客さんがいて、そのお客さんのビジネスを進めるための一種のミドルウェアみたいなのを作っていたわけですね。
家永：プロセス指向フレームワークとか言われていましたね。別チームがORマッパーを作っていました。
和田：そうですね、いわゆる僕たちが作っているものの上に乗っかって、かなり大きめの業務システムを作る本隊みたいなやつがリモートにいて、時々リリースのために物理的にそこに行くという。
家永：その時のリリース作業も、ソースコードをコミットしに行くって。
和田：そうそうそう。
家永：最初その手順も少し大変な感じがしてたけど、だんだん慣れましたけど。
和田：ネットワークとかが、今もそうかもしれないけれども、気軽につなげるような相手先ではなかったのと、扱っているドメイン自体も気軽にネットワークをしに行けるようなドメインではなかった。もうちょっと秘匿性の高いドメインだったので、古式ゆかしいCD-ROMに焼いて物理的に持っていって、向こうでアーカイブを展開して。
家永：焼くのも大変で。
和田：15年前のリリースの姿。
家永：今だったら、こうじゃないかもしれないですね。
和田：そういうプロジェクトに、僕は１年半ぐらいいました。僕の前にリーダーの角谷さんともうお一方が、何ヶ月先行したのかな？１ヶ月か２ヶ月ぐらい先行して、要件定義みたいなのをお客さんが先でされていて、それを持って帰ってきていよいよ最初のイテレーションというのを始めようという時に、僕ともう一人が入ってきて４人チームになって始まったのが、第１期伝説XPプロジェクト、チーム角谷の第１期メンバーみたいな感じ。
家永：最初は何か使い捨てプロトタイプというか学習プロトタイプ作っていたとか作ってなかったと聞いた。
和田：僕が入る前までは、いわゆるUMLのモデルがあった状態。つまりコードは一行も無くて、UMLを使ってお客さまと一緒にモデリングをして、ゆるい合意を取って、実際にいわゆる受託開発みたいな形で持ち帰って開発しようというので、４人チーム体制で持ち帰って開発するという、一番最初から僕は入ったという形。
家永：はいはい。それが僕が入った時には、もう次のリリース、実際の上側のリリースも決まっていたのかな。
和田：たぶんそうだと思います。
家永：あれか、和田さんがちょうど抜ける直前、直後ぐらいなのか、リリースが。
和田：リリースがね、きっと。
家永：それによって動いていたという、そんな記憶が思い出してきた。
XPコーチは「プレイングコーチ」
和田：まだ僕しかいない時期の話になってしまうのであれなんですけれども、一番最初に僕が入ってきて、僕はコーチというロールで、
家永：ポジション的にはコーチ。コーチと言っても、実際にコードも書くし、
和田：うん、プレイヤーですね。
家永：完全にプレイヤーとして。
和田：プレイイングコーチみたいな感じで入りました。その前までは何千人月みたいな超巨大公共プロジェクトにいたところから、一気に４人チームに入ってきて、何か何もかも違うみたいな感じで、僕もすごいテンション高まって始まりました。
家永：もうちょっと時間を進めてみますか。
和田：うん。
ペアプロや共同所有で成長
家永：当時、一緒にやっていた印象は何だろうな、先ほども出たけど、ペアプロのさっき話したっけ、定規（※2）の話とかで。
（※2： 汚いコードを書くと定規でペシペシぶたれるという、鬼コーチの振る舞いを受けていたという逸話。）
和田：そうですね。
家永：最初僕、まだその時、開発者としては、僕は二つ目のプロジェクトで、１年目は開発自体はやってなくて、ほぼ新人ぽいところはあった。それで結構、角谷さんとか和田さんとか、あるいはもう一人のメンバーにいろいろ指導を受けながら仕事を覚えていった。それで後半、みんなが抜けた後、僕がリーダーを引き継ぐという、ポジションでやっていた。
和田：でしたね。
家永：最初、そういう意味で言うと、ペアプロでコードを覚えていくというのが、将来そこまでは自分自身は見越してなかったけれど、一緒にやるという行為を通じて学ぶことができた。ある部分だけ自分がコードを知っているんじゃなくて、全てを通じてのコードの全部意味を通して、どこに修正箇所を入れていけばいいのかとか、何か障害が起きた時にどう直せばいいんだろうかというところを考えられることができた。いわゆるコードの共同所有なんだけど、それを後によく「ペアプロやってて良かったわ」と。（ペアプロについては下記記事を参照）
和田：共同所有して良かったなと思う？
家永：というところはありますね。あとはそうですね、後半で見ると、抜けた後、後に大きいプロジェクトということで、一回ちょっとヒヤッとすることがありましてね。それ話したことあったかな？
和田：いや、無いと思う。僕が抜けて、角谷さんも抜けた後？
家永：そうですね、角谷さんも抜けた後、コウイチが入ってきて、二つ目のちょうどね、そのフレームワークを使って一つ目のプロジェクトが動き出して、さらに何かエンハンスでやっていこうというような動きと、別のプロジェクトという形でそのフレームワークを使って、
和田：横展開みたいな。
当初の想定ではダメ…さあどうする？
家永：それが二つ並行で進むうちに一つ目の方で結構、もやもやとした事が起きた！！何が起きたかというと、ちょっと細かい話になるんですけど、プロセス指向フレームワークで出てくる要素の条件分岐や並列実行などの、テストしてたパターンが結構シンプルなやつになってた。だけど、実際にアプリ開発側で描いていたワークフローがもっと複雑なもので、それ自体それを実際に実行しようとすると、僕らが作ってきたモデル自体が対応できていなくて、いくつかの組み合わせのパターンがどうやら動かないぞっと。
和田：おお。
家永：結構ヒヤッとして、それが「次いつまでにリリースなんだよね」とか、急に言われて、最初ドキッとしました。けれども、最初にやった事って、先にテストの足場を整えなきゃ、テスト網が作れるものを整えなきゃということ。（時間とって自動化に取り組んでいたけれど）プロセスを描いてコードを生成して、実際にテストで動かして確認の仕組みが、実は道半ばな所だったんです。
和田：そうですね。
家永：そこを整えて描いてテストできるまでのターンアラウンドをどうやったら短くできるだろうか、という足場を整えていって、テストパターンを増やして、「動かない」というところをはっきりさせて、それで内部のモデルの足りない、その（初期開発）当時としてはこのモデル要らない、内部的に実装には要らないよねと位置付けていたやつを、これはやっぱり要るというふうに判断して、復活させて一生懸命それは（テストが）通るというところを作るという作戦を実施してた。
家永：この作戦自体は僕自身が判断してやっていたところがあるけれども、事前に角谷さんとか和田さんにテストで自分の足場を整えて、中身のリファクター、少し大きめなリファクターができる足場を整えて攻めていくというところを、事前にいろいろ一緒にやっていたおかげで、足場整えて取り組もうの作戦でいこうを思いついて、それで何とかしのぎ切ったという。ちょっとまぁ終電の時間が（笑）週末までは働かなかったけど、終電直行はありました。
和田：頑張らなきゃいけないイテレーション。
家永：ここで踏ん張らないといけないみたいなことがありました。
和田：その頃って、バーンダウンチャートってまだやっていました？（※2）
（※2：このプロジェクトのバーンダウンチャートが日本で最初に発表されたバーンダウンチャートだった。）
家永：その頃はね、ちょっとやってなかったですね。
和田：もう卒業してたみたいな感じ？
家永：そうそうそう。
使い手が知るテストパターン
家永：あの時は、その教訓もあったのか、さらに外側のニーズというか、テストパターンというのが、もうちょっと使い手側の所に足を運んで話を聞きにいかないと拾い切れないというのは、だいぶ自分の中では課題感を持ちました。BDD(Behaviour Driven Development／ビヘイビア駆動開発)とか、Acceptance TDDとか、ああいう活動も何か重要だろうなあというのは感じてた。本来なら一緒の座席で近くに話しているのがいいんだけれども、その当時はそうは行かなかったので、足を運んで話を聞きに行って、それをテストパターンとして描いてというところが、自分の中ではもっとやっていかないと抜けが起きるんだろうなあというのは、すごい教訓としてはあったかなと思います。
和田：それ大事な所は、たぶん僕らは最初、持ち帰り開発というのをやっていて、例えば、ビジネスオーナーの方が要件とか仕様自体も、僕らと一緒に考えたり伝えたりしてくれる話だったんだけど、いわゆるリアルなビジネスケースみたいなの。
家永：依頼する人と実際の使っている人の違い
和田：やっぱりもうちょっと複雑だったという話があるので、やっぱり実際に使っている人にどれだけ近づけるかというところが結局、現実の問題を解決できるソフトウェア作るには、何て言うか、クリティカルですよね、決定的に大事。（受け入れテストのループについては下記記事参照）
和田：それで僕らの開発の一番最初の時は、そもそも、その部隊（利用者側のチーム）自体同時に動いていて、あまり要件自体もちゃんとしたのが無くてみたいな感じで、全て並行開発で手探りみたいな感じだった。だけど、一回リリースを経た後では、リアルなユースケースがあって、それに対してリアルなユースケースをかなえられないと知った時にどう行動したかという時に、要するに実装から距離の遠い、今でいうエンドツーエンドテストみたいなものを、例えばビジュアルに書けるようにして、実際にこれこの通りこいつは動かないねという失敗を再現させる受け入れテストを書いた。
家永：そうですね。そういう意味で言うと、ちょっと不幸もあって、一回リリースしてから、それ実際に使い始めるまで少し期間があって。
和田：あった、あった、分かる。
家永：たぶん６ヶ月とか３ヶ月かちょっと期間は忘れてしまいましたけど。
和田：リリースしてから実際に使われるまでに期間が空いた。
家永：期間が空いていたので、ちょっとそこらへんあんまり気に掛けていなかったけど。実際に使い始めて「ああ」みたいな、気付くのは、その当時ありましたね。
モックをやめた話
家永：あとは、そういう意味だと、もう一つは、あの当時、面白いなというか、結構テストの網というのを結構ユニットテストと、当時はファンクショナルテストというのと、あと、実際にEJBだったので、デプロイして動かすという(デプロイ時間がかかって面倒！！)
和田：そうですね。
家永：あれはアクセプタンス（受入）テストと呼んでいたかな。
和田：僕らはアクセプタンステストと呼んでいたけど、なぜ、アクセプタンステストと呼んでいたかというと、お客さんと一緒に週の頭に（テストを）書いたからなんですけど、レイヤー的にはインテグレーションテストみたいな感じですね。（テストの四象限で言うとQ３に当たるもの。テストの四象限については下記リンク参照。）
家永：というのを３つやっていて、皆さんが抜けてから、僕の判断でやめたのが、モックに力を入れるのはちょっとやめておこうというもの。
和田：そうですね。最初すごくモックオブジェクトをいっぱい使って、ユニットテストの一番小さい粒度のユニットテストは、いわゆるテスト駆動開発の流派で言うところの、 London School とか、 Mockist Style と言われるテスト対象以外が全部モックオブジェクトというスタイルだったんだけど、長期間開発すると、身動きが取りにくいんですよね、結構。
家永：ライブラリー自体もちょっとイケてないというか、リファクタリングが付いてこれないような、その当時としてはちゃんと残念な道具もあってか（当時はモック対象のメソッドを文字列で書くライブラリを使っていた）、それで「これ毎回メンテ無理やわ」と思った。代わりに一番力入れていたのは、僕が入ってからファンクショナルテストのところが、ちょうど費用対効果というか、学習サイクルと実際に確認したい動作パターンの機能性を確認するのに一番良いサイクルがあって、そこに力を入れるというようなスタイルになっていきました。（モックの使い所は下記記事参照）
家永：先ほど何か途中までしか動かないというのを、テスト側にも工夫を入れながら、当時、非同期処理というのが、最後まで一筆書きで通るというのが、まだ当時、最初の頃は無かったんだけれども、そこテスト側はもうちょっと一工夫して、最後まで動作確認ができるようにみたいな仕掛けを用意したりとか、工夫しながらやって動作確認を頻繁にやりながら、設計の所も改善できるようにというところを、すごく力を入れていたというのがあります。
和田：そこで言うファンクショナルテストというのは、なるべくモックオブジェクトを使わずに、なるべく本物を使うけど、テストを動かす基盤自体は本番のいわゆる当時で言うところのEJBコンテンツの上で動かすんじゃなくて、メモリー上で動かす。
家永：その当時はDBにはつないでいた。（時間がかかるデプロイはせずに）
和田：データベースは本物を使って。
家永：データベースにはつないでいて、当時、コアとなる所がプロセス指向フレームワークの、いわゆるエンジンと呼ばれる所で、いろんなプロセスのパターンの動きのバリエーションが僕の時はちょうど増えていくという、キャンセルができるとか、フォークジョインのバリエーションホーキジョイン(※3)という何か。
(※3) nパターンにフォークしてジョインする箒（ほうき）型のジョイン
和田：すごい、ドメイン言語で、ドメイン用語ですね。
バリエーションを増やしていくために
家永：何かそういうバリエーションを増やしていくというのも、
和田：いわゆるソフトウェア、ミドルウェアのジャンルで言うところのワークフローエンジンを作っていたので。
家永：そのバリエーションを増やしていくというところを、実際に機能性としてエンジンがそれを動かせるよねっていう。
和田：機能がつまり、僕らは一番最初の線路を作るみたいなところで、線路プラスαみたいな感じで、まず最小限のプロセス制御ができるみたいなところから進んでいったけど、家永さんがリーダーした時期はまさにいろんな図形が描けるようにした。
家永：そこからバリエーションを増やしていくというのをやった。
和田：一番ソフトウェアが、拡張性とか保守性の面で試練を受ける時であり、かつうまく設計していると、どんどんバリエーションが増やしやすい時期。
家永：それを当時やっていたところはありましたね。その時にリグレッションテストの役割としての、当時ファンクショナルテストがすごい助けになった。これによって意図せず壊れていれば気付くだろうし、そのレッドになった意味を調べていって、これがテスト側が何かおかしい場合もあるけど、ファンクショナルに関してはそんなに、そっちよりも何か「ここに影響があるんだ」というのを気付く。
和田：だから基盤、つまりEJBコンテナであるとか、Webサーバであるとか、そういったものを疑う余地を作らずに、メモリー上で、でも大部分は本物の状態で動かすというテストだから、動かない、思った通りに動かない時に疑うのは自分たちであるという、テストの信頼性としては高いですよね。
家永：そしたら、いわゆる突き進んで無理だったらとりあえず戻ると。戻ってもう一回来た道を戻って、もう一度攻め順を考え直してやるとか、そういう事をやってました。そのリファクタリングのステップ幅に関しては、当時角谷さんとか和田さんとか、あるいは懸田さんとかに「幅がでか過ぎるから先行けないんだよ」というのを教わっていたので、一歩一歩でか過ぎてこれムリやわと思ったら、下がってもう一回ステップを狭めて攻めるみたいなところをやっていた記憶がありますね。
和田：そういう意味だと、リファクタリングとかの歩幅の調整をするというスキル自体は、たぶん僕たちのチームはペアプログラミングを通じてチーム全員がそういう感じでできるようになってた。
二人（＋α）の対談はまだまだ続きます。次回は「リファクタリングの変化」「粘土こねこね設計」「フィードバックループを外側へ」の３本をお届けします。お楽しみに！！
