外側のフィードバックループへ 〜 『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （２）

アジャイルが何周もして徐々に外側のフィードバックループへと目を向けていった話。

前回のおさらい

『テスト駆動開発』翻訳者の和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の第二回の記事です。

二人の出会いとなった「伝説のXPプロジェクト」の話題から始まり、変化に適応するために、ペアプロ、共同所有、テスト網の整備を行ってきた話で盛り上がりました。

さて、今回はどんな話題で盛り上がるのでしょうか？

リファクタリングの捉え方の変化

家永：最近はいわゆるケント・ベックやマーチン・ファウラーのリファクタリングという意味合いの、このミニマムステップはあんまり使われなくなっちゃった。

和田：そうですね。

家永：もうちょっと大きめのものをリファクタリングして、下手したらリライトぐらいの勢いのものを、みんなリファクタリングという。

和田：それリファクタリングという言葉の受容のされ方が何か変わってきたというか。

家永：だんだん変わっちゃって。

和田：単なる作り直しをリファクタリングと呼んでいる、それはある。

家永：ちょっと何だかなあという感じ。「えっ！？」と、ドキッとする事があります。

和田：それはありますね。テスト無しで変更するのをリファクタリングと呼んだりとか。

家永：全てテストのないのを、せめて全部とは言わないけど手動の動作確認をしないんだと。

和田：そうなっちゃうとただの書き直しですね。ファウラーのリファクタリングのステップというのは、だいぶ忘れられかけている。スモールステップみたいなやつがスキップされがちなのは、良い面と悪い面があるね。

和田：良い面というのはリファクタリングの（カタログの）うち、結構な割合で自動化されている。例えば、高機能なIDEを使うIntelliJとか、Eclipseとかを使うリファクタリングは自動化された手順の選択だけで動く。例えば、メソッドの抽出とかってファウラーの本だと、たぶん７ステップか８ステップぐらいあると思うんだけど、それが実際には、実際の開発環境上だと何か抽出したい所を普通に範囲選択して右クリックして、リファクタリングメニューで「メソッドの抽出」とやると「にょりっ」と普通に自動で（メソッドに）出せるみたいな感じになった。そうすると、本質的な作業というのは、リファクタリングのメソッドの抽出の前後で何がやりたいのかという話だから、細かいステップは機械に任せて、人間はもっと大づかみに考えたい事を考えるというふうに行けるようなったので、それは進化だと思う。

粘土こねこね設計とUNIXの哲学

家永：そういう意味だと、合わせ技というのを周りに教わったような。いったんインライン化して展開してからエクストラクトメソッド（メソッド抽出）してからの、別クラスにメソッド移動みたいなという何かそういうステップ。こんなステップあるんだと、当時はすげえと。

和田：そうですね、言語と環境によって全然やり方が違うというのがあるけど、少なくとも、僕たちはJavaで書いていて、当時Eclipseで書いていたんですけど、もう充分リファクタリング機能は強力だったので、テキストとしてコードを書くというよりも、もっと粘土とか立体的な何かをいじるみたいな感覚でペアプロしてたと思うんですよね。普通にコードのブロック自体をここからここまで選択して、脇に出したら思った形にならなかったから、逆向きの変換をしてインライン化をして元に戻してから、一次変数を出して、一時変数を上の方に持っていって。

家永：移動して。

和田：そこから下を範囲選択してエクストラクトメソッドするとうまい形に出るみたいな感じで。それって本当に何か粘土こねこねしているみたいなプログラミングのスタイルで、それが実際にできるレベルまで、当時の開発環境と当時のチーム自体が来ていたというのは、結構高いレベルに来ていたんじゃないかなとは思います。

家永：ちょっと余談ですが、粘土こねこねは、設計のメタファーでよくその当時も何か言っていたような。

和田：そうかもしれないですね。

家永：実際に何かひっつき虫(※1)を、当時は何かあれを粘土やりながら設計の何かこうメタファーを。

(※1) ひっつき虫についてはアジャツール 第13回 どこでも貼る！どこでもメモする！を参照。

和田：情報カード(※2)みたいなやつで、ストーリーカード、タスクカードを実際に紙媒体でやっていて、カードを壁に貼り付けたり、ディスプレイに貼り付けたりするために、ひっつき虫って商品名だと思うんだけど、何て言うの、粘着性の、

(※2) 情報カードについてはアジャツール第７回 付箋だけじゃない！情報カードが選ばれる理由を参照。

家永：あれをよく和田さんとか角谷さんがもみもみしていたのは。

和田：練り消しみたいなやつで（情報カードを）壁に引っ付けていたので、それがそのまんま設計のメタファーって。

家永：何かそういう感じはしていましたね。

懸田：いや面白いですね。

和田：でもある程度何かそういうコードをテキストファイルとして扱うのじゃなくて、もっと何かこねこねする設計の媒体みたいな感じで扱う感覚というのは、僕も当時のプロジェクトで得たものだったし、生きた設計みたいなものを次の形に変えていくものはできそうだなという手応えをつかんでいたので、やっぱり良い状態だったなと思いますね。

家永：かなり余談ですけれども、最近、同じチームのLISP好きの人がいて、

和田：LISP好き！

家永：電車の中で、しかも立ちながらプログラミングするという際に「このLISPのカッコの移動するのが良い感じなんだよ」みたいな事を言っていた。僕にはこの感覚が全然分かんなかったんだけど、そういうブロック単位でこねこねしながら形づくっていくというのを、彼はたぶん言いたかった。

和田：僕とLISPの関わりはEmacsというプログラミング環境なんですけど。LISPや、あとSmalltalkってREPL(※3)が強いから、だから何か動いているものを組み合わせて、もうちょっと中ぐらいのものを作る、ボトムアッププログラミングに本質的に向いていると思うんですよね。何か動くと分かっている、小さくて抽象的なもの、動くと分かっているものをいっぱい作って、それを組み合わせることで、中くらいの抽象的で動くと分かっているものを作るという手段。そこからテスト駆動開発が受けた影響もやっぱり大きいと思っていて、テスト駆動開発自体も本質的にはボトムアッププログラミングの一種だと思うんですよ。基本的には小さくて直交性が高くて抽象度も高いようなものを全て自分の思い通りに動くと分かっている状態をキープしながら、それを組み合わせて複雑なものを作っていく。

(※3)「Read-Eval-Print-Loop」の略で対話型実行環境のこと。ニコニコ大百科参照。

家永：何かよく言われるUNIX系の設計。

和田：そうですね、UNIXの哲学(※4)に近い。なので、僕の中だと全部つながっている感じで、その複雑なものを破綻せずに作る唯一の方法なんじゃないかなと思っているので、15年間飽きずに続けている。

(※4) 『UNIXという考え方』に詳しい。

家永：小さな部品の組み合わせで作っていく。

和田：そうですね。

フィードバックループを外側へ

家永：（そのプロジェクトの）その後を語る。そういう意味だと、二つのプロジェクトとしてフレームワークは実際に採用されて、一個の方は結構長く使われたというのはあるんだけれども、実際にたぶんオーナーとしてはそれをパッケージ化して、

和田：商品化まで来たかった。

家永：商品化まで行きたかったんだけども、残念ながらそれは。。。

和田：そこまでは至らずという。

家永：僕と角谷さんはまだ一回展示会に行って一緒に立ってチラシ配りとかやりましたけれども、実際にセールストークというのは、当時はそんなに意識してなかったけど、セールストークしづらい商品だなとか感じた。

和田：それは？

家永：実際に価格テストで「この値段か」というのを、（展示会の）その場に立って考える機会がでてきた。

和田：そういうのも、フィードバックループの一つで、早めにそういう場に立つというのは大事なんだなって思います。僕はその後の別のプロジェクトでも商品とかパッケージとかのプロジェクトをやっていたことがあるので、幕張メッセとかに行って、実際のチラシ作ったりとかお客さんに実際に採用を考えたお客さんと話をするという時に、このプロダクトのコアは何ものかなとか、パンチラインは何なのかなとか、そういったのって、もっと早めに考えるタイミングってあったんじゃないかみたいなのがありました。エレベーターピッチみたいなやつ。

和田：その後、時代がリーンスタートアップの時代になったり、デザイン・シンキングの話になって、もっとプロダクトのコアの価値を早いタイミングで考えるための思考のフレームワークみたいなのが出てきたのは、何周かした後のソフトウェア開発の世界だなと思っている。アジャイルが２周ぐらいした後の３周目ぐらい、プロダクトからどう出ていくかという話。

家永：お話聞いたところによると、私はやらなかったけど、一応パッケージデザイン(※5)は一緒にワークで作ったか、あったんじゃない？

（角谷氏「これはチームみんなで合宿してつくりました。段ボール箱に模造紙を貼って、クレヨンとかを使って絵を書いて…というワークショップをやりました。ちなみにそのワークショップは平鍋さんがファシリテーションしました。」）

(※5) インセプションデッキにも含まれるプロダクトのパッケージをコンセプト段階で構想する（＝顧客目線でプロダクトを考える）というプラクティス。当時は「プロダクトビジョンボックス」と呼んでいた。

和田：あといざ商標取ろうと思ったら、思いっきりかぶっていて名前を直前で変えるとか、そういうのがあった。

家永：パッケージ全部変える、大変だなあ。

和田：だからそれによってJavaでいうところのパッケージ名とかネームスペース全部リリース直前にネームスペース総取り換えみたいなことになった。

家永：大変だなあってやっていた記憶があります。あのパッケージデザインは描くまでは良かったんだろうけど、実際にやっぱり建物の外に出て、テストするというのが重要なんだろうなあ、というのは、後からもやもやと思う機会はありました。展示会、結局２回行ったのかな？何回行ったか忘れたな。

和田：いわゆるフィールドテスト。大事ですよね。

家永：フィールドテスト、チラシ配りとチラシ配ったやつの説明をするのだけど、まず人が来ないし、来ても食い付きがという、そんな雰囲気だった。「これは」という、なかなか売れるプロダクトを作るのは大変だなという。

和田：ちょうどたぶん時代は、良いものを作れば売れる、こういうものを作りたいと思っていた時代から、そうじゃなくて誰も正解は知らなくて、正解はどっちかというと、お客さまとその使われ方の中にあるから、その初期のαとかβとかプロトタイプみたいなところがどう使われるかから学んで、どうやって本当のニーズというのを掘り出していくかというところに時代がシフトしていく、まさに端境期にあったプロジェクトだと思う。

家永：その当時はね、リーンスタートアップ(※6)とか何もない。

(※6) 『Lean Startup』の出版は2011年、邦訳は2012年。

和田：その後出てくるから。まだない。だいぶあれからソフトウェアの作り方は変わったな。２周、３周ぐらいしているけど変わったなって思いますよ。だから最初のアジャイルソフトウェア開発、XPの白本の一番最初の時とかも、まだ誰かが正解を知っていると思って、正しいものを作れるって思っていた。だけど、どうやら「正しい、欲しいものって俺たち知らないな」というところに最初から立つというのには、まだ10年の歳月が必要だったみたいな感じだった。

家永：いやでも、売れるプロダクトを作るのは大変だ。