徳冨優一氏（以下、徳冨）：「ゲームのように学ぶスクラム開発」をやっていきたいと思います。
アジャイルに興味のあるみなさん、どう学んでますか？ XPの白本から始まったアジャイル開発です。その後たくさんの本が出版されていて、本にはたくさん良さそうなことが書いてありますが、実践しようとするとわからないことだらけだったりしませんか。
自分のプロジェクトがスクラムを採用していると思っていたら、“ミルクボーイがアジャイルを説明したら”のネタになっていてハッとしたりしませんでしたか？ 今日はアジャイルの入り口にいる人たちに向けて、私が学んできた経験をおもしろエピソードとしてお話しします。
結論からいきます。まず素朴理論は重要です。自分で試してみるということですね。試して、自分で理論を作ることが大事なので、学ぶというよりも遊ぶ習慣が大切です。日頃から小さく試してみるのが生活の習慣になってきます。それはアジャイルの一部かなと思います。仲間と一緒にやると、楽しさも倍増して、学びも早くなります。
自己完結ではなくホンモノに触れること
次が、ホンモノに触れることです。ホンモノに触れるとものすごく時短ができるので、自分で勝手に解釈するのではなくて、できればホンモノに触れてほしいです。ホンモノに触れるために、できるだけその機会が近づくように行動しましょう。
エピソードを話します。学んだというのもちょっとおかしな表現で、僕からしたら日頃から遊んでるだけなんですよね。とはいえ、それでも大きな転換期はありました。最初に出会ったのはXPの白本でした。それまで読んだプログラミングの本とはぜんぜん違って、まずおやつが大事とか書いてあるんですよね。「なんだこのふざけた本は？」と思いました。それが最初の印象でした。
ただ、今あらためて読み返してみると、アジャイルのエッセンスはここに詰まっていると思います。そのぐらい大事な本なのですが、この時にマスターしたと自信をもって言えるのはペアプログラミングだけだったかなと思います。テスト駆動開発もこれがきっかけでやり始めたのですが、後日ぜんぜんわかっていなかったことを思い知らされました。
この頃、とても運が良かったことに、チームに恵まれていたんですね。「こんな本があるんだけど、一緒にペアプロ（ペアプログラミング）を試してみよう！」と言ったらノッてくれる、すごく機動力の高いチームでした。
実際に試してみるのはすごく大事なんですよ。試すことによって、どのタイミングでペアを交代するのがいいのかとか、スキルの差が大きい時と小さい時でどうなるのかとか、どんなコミュニケーションが有効かとか、いろいろと実験できて、自分の中でペアプロが有効であるという確認ができました。
スキルの差が小さい時に、恐ろしいスピードで設計が進化していく経験をして、衝撃が走ったんですよ。「一応はひと通りできた！」「あれ、このケースはどうなりますか？」「そこは両方を変えないとおかしなことになりますよね」「ここは別のクラスに切り出したほうがいいんじゃない？」。そんな侃々諤々ののちにできあがったコードはとてもすばらしい完成度でした。
もちろん機能するだけのコードは、お互い1人で書けるレベルなのですが、ペアで書くことによって、2人の叡智が詰め込まれ、短時間でとても凝集性の高いコードに育ったんですよ。「これは確かにエクストリームプログラミングだ！」と、それまでにないプログラミングの経験に、鳥肌が立ったのを今でも僕は忘れられないです。
やっぱり仲間は重要ですね。実験することが重要です。練習することが重要です。あとは、できれば成功体験です。失敗することもあるかもしれませんが、成功するとそれは強く印象に残るので、小さくても構わないので成功体験を積み重ねてほしいなと思います。
狐につままれたような体験で会議の概念が覆った
次は、会議の概念が根底から覆った話をします。これも学んだというのはおかしな表現で、たまたまホンモノを体験したという話です。これが1つの大きな転換点になりました。
それはね、同じ職場にKiro（原田騎郎氏）さんがいたんですよ。ご存知かと思いますが、株式会社アトラクタのCEOです。当時はもちろん会社は作っていなくて普通のサラリーマンでした。ただ、当時から貫禄はあった気がします。どう貫禄があったかは、ここでしゃべると録画が残るのでしゃべりません（笑）。
当時はまだ「アジャイル」なんて言葉がない時代でした。とても混乱しているプロジェクトにいました。といっても普通のプロジェクトはだいたいそうですよね。納品を目指してどんどん混沌としていきます。「この計画おかしいやろ？ 見直したほうがいいんちゃうの？」「シンプルな設計にしたほうがいいんじゃないの？」「やってることがちょっと的外れじゃない？ これ以上やると混乱するよ」とか、吠える邪魔者がいるんですよ。まぁ、その邪魔者の中心にいるのは僕なんですけどね。
そんなプロジェクトにアドバイザーとしてKiroさんがやって来ました。理由はよくわかりませんが、たぶんマネージャーがお助けマンとして呼んだのだと思います。「この人、誰？ お茶の水博士みたいな風貌やけど、外部の人間で情報知らん、経緯もわからないのにこの混沌どうにかできるの？」と思っていました。
彼は全員を集めてミーティングを始めたのですが、その第一印象が、僕にとっては最悪でした。「まず、課題を付箋に書け」って言うんですよ。でも、太いペンしか渡してもらえません。「これじゃあ狭くて文字数足りないよ」と言うと「一言で書け」と言うんですよね。
それに付き合って、全員があらかた書き終わると、書いた付箋紙をホワイトボードにペタペタ貼っていきます。彼は軽く質問しながら貼る場所を変えたり線を引いたりします。参加者には簡単な、浅い会話だけしかさせません。
学校や普通の会社の会議しか知らない僕にとっては、ゲームをしているというか、遊んでいるようにしか見えないんですよ。「なんなんこれ？」「何だこの奇妙な会議は？ もっとちゃんと話し合わないと事態の収束なんてできるわけないでしょ」と思いました。
その会議は1時間ぐらいで終わったんですが、そこで急に奇妙な感覚が芽生えるんですね。 なぜか、全員が合意する最重要課題が浮かび上がり、重要課題が浮かび上がって、真っ先に着手する改善策が決まっているわけですよ。もう狐につままれたような不思議な感覚です。僕はぜんぜん言いたいことを言ってないし、Kiroさんもみんなからぜんぜん情報が聞けてないんですよ。「なのに、なんで結果が出てるの？ 何なんだ、これは？」。僕は「この1時間にいったい何が起こったんだ」と思いました。わずか1時間しか経っていないのに、その結果なんですよね。これがまた強烈な経験でした。
今となっては種明かしはわかります。ふりかえり、KJ法、現状問題構造図などのツールを使っていたんですが、僕が知っている普通の会社の会議のやり方だったら、何時間かけてもこんな結果にならなかったんですよ。何ヶ月も混乱していました（笑）。
根底から会議が覆った瞬間でした。そもそも考え方が逆なんですよね。「話し合った結果として成果が出るんだよ」じゃなくて、「一定の時間内に成果を出すために何をどう話し・話さないか」。そういうことが大切だとわかりました。
説明なしで経験させられて、ハンマーで殴られたような衝撃とはこういうことやなと思いました。今から見れば、Outcome DeliveryやValue Stream Mappingなんかも同じパターンだと思います。結果から逆算して振る舞いを決めるということですね。
僕はなにもわかっていなかったので、起こったことを咀嚼するのにすごく時間かかりました。ホンモノの体験というのは本を読むよりも遥かに勝るなと思いました。ホンモノに気づくためには、起こったことをよく観察し、よく考えることが必要です。特に重要なのは、結果に着目することかな。新しいものをひとまず受け入れましょう。従来と違っても、拒否しないで、しっかり真似しましょう。
魔法のようなプログラミング ただただ美しい光景
次は、魔法のようなプログラミングに出会ったお話をします。これも学んだというのはおかしな表現で、ただもう魔法を見ました。目の前で起こっていることが理解できなかった。コーディングですよ。プログラミングなんですけど、ただそれはとても美しい光景でした。そういうお話です。
時代的には、「アジャイル」という単語が世間でザワザワしてきた頃だったかと思います。今でこそ僕も、リファクタリングの動画を「YouTube」に上げたりして広めようとちょっとがんばってるんですが、当時はわかっていなかったんですね。「何度でもリグレッションテストできるし、テスト駆動開発をしたほうがいいとは思うけど、テストコード書くのも時間かかるんじゃない？ トータルで考えた時に、開発効率がいいかどうかはめっちゃ悩ましいな」ぐらいに思っていたんですよ。わかっていなかったんですね。大きく勘違いしていました。
そんな私でしたが、アジャイル開発をやっているプロジェクトに参加できることになったんですね。ネイティブアジャイル開発みたいな感じの現場なので、誰かをわざわざ説得したりする必要がないんですよ。最初からペアプロなんです。「ああ、進んでいる現場ってあるな。でも俺もXP一応経験しているし、大丈夫やろ」って高をくくっていました。
そこでは、だいたいスプリントごとにペアを変える運用をしていました。スプリント中は固定ってことですね。入ったばっかりなので、数スプリントはキャッチアップフェーズです。タスクに一応サインアップはするんですが、ペアのパートナーにいろいろと業務のことだったり、コーディングスタイルだったり、そういうものを教わる感じです。自分のやってきたことよりもテストを細かく書くなと思っていましたが、キャッチアップはできるわけです。
ところが、それはある日突然やってきました。魔法に出会ったのは、2ヶ月ほど経った頃だったと思います。プロジェクトメンバーの中で、一番若い人とペアプログラミングすることになったんですね。ドライバーが彼になると、風のようにコードが変わっていくわけですよ。一度もテストが落ちないまま、次々とメソッドが増えたり減ったり、クラスが増えたりするんです。目も思考もぜんぜん追いつかないんですよ。
わずか10分ぐらいのできごとだったんですが、恐怖でした。「何やっているのかがわからへん……。こんなん真似できひん……」「ごめん。今何が起こったのかぜんぜんわからない。途中しゃべったこともわからない。申し訳ないけど、ゆっくり説明してもらえるかな」みたいな。もう屈辱ですよね。自分はプログラミングができると思っていたのですが、これからこんな若者が台頭してくるのかと思うと「やばい！」となったんですよ。プログラミングを生業として食っていけなくなる、そんな予感をして背筋が寒くなったのを覚えています。
ただ、その一方ですばらしい技術だと思いました。動いているシステムのコードを、安全にいくらでも書き換えられる。ミスってもいつでも直せる。そもそもウォーターフォールみたいに最初に設計を固める必要がなくて、設計そのものを遅延させられるんですよね。これはソフトウェア開発を激変させる革新的な技術だと思いました。ホンモノのTDDに出会った瞬間でした。
ただ、残念ながらそのプロジェクト内では僕はマスターできませんでした。幸いなことに、そのあともいろいろな人に教えてもらう機会に恵まれて、2年ほど経ってやっと自分で使えるようになったかなと思います。さっきと一緒ですが、ホンモノの体験は、100冊の本に勝るなと思います。教えてくれる人、コーチは大事です。
これがきっかけのエピソードで、どうやってマスターしたかというと、影響を受けたのは「Coderetreat」というイベントかなと思います。ちょっと紹介すると、1日中TDDを練習するイベントなんですよ。「コンウェイのライフゲーム」というのをやります。
そのイベントの主催者に「本当に45分で実装できるんですか？」と聞きました。主催者が「ええ、できますよ」と答えたので「いろいろな言語の参加者がいるじゃないですか。それを全部フォローできるんですか？」と聞いたら「全部はさすがに無理ですね。でも、開催前に3言語ではできるように練習してから開催してますよ」って答えたんです。
僕はただ未熟だっただけなんだなと思い知らされて、それから1ヶ月ぐらい1日タイムアタックして「45分で作るぞ！」という練習をしました。これができるようになったのが大きかったかなと思います。練習は重要です。残念ながら「明日からやれば、誰でもTDDができるんでしょ？」というものではなくて、「しっかり練習しましょうね」ということをちょっとお伝えしたかったです。
（次回へつづく）
