角谷信太郎と林尚之がアジャイル開発を語る「いまなぜエクストリームプログラミング（XP）なのか？」

「いまどきエクストリームプログラミングで大丈夫か？」

アジャイル開発の方法論やフレームワークはいくつかありますが、ユーザベースのスピーダ事業では執行役員CTOである林尚之さんの主導によりエクストリームプログラミング（XP: eXtreme Programming）を全面的に採用しています。2023年3月にはアジャイル関連書籍の共訳・監訳などで幅広く活動される角谷信太郎さんがエクストリームプログラミング顧問として就任し、エンジニア組織の向上に取り組んでいます。

当初は「いまどきXPで大丈夫か？」と半信半疑だった角谷さんですが、かなりの規模でXPを実践できていることに驚いたそうです。そんな角谷さんと林さんが、アジャイル開発を推進する上で大切なことは何か？拡大する開発組織全体をアジャイルに保ち続けるにはどうすればよいのか？について正面から語り合いました。

ユーザベースがアジャイル開発を始めるきっかけ
最高のプロダクトというより「最高の開発チーム」を作りたい
全員が「このチームをよくするには？」を考えるしかない
「いまどきエクストリームプログラミングで大丈夫か？」
凸凹してたアジャイルへの認識を揃えてベースを作る
エンジニアリング組織の秩序が自発的に形成されるには
いい感じに動く指針となる原則を自分たちの言葉で
合わせて読みたい参考記事

ユーザベースがアジャイル開発を始めるきっかけ

── 林さんは、この記事が掲載される「Agile Journey」を運営する株式会社ユーザベースのCTOですが、最初はユーザベースの社員だったわけではないとお聞きしています。

林　はい。2013年に、SPEEDA¹というプロダクトの開発にフリーランスとして参加しました。ローンチから3年くらいたった時期だったので、すでにサービスとしての機能は充実していて、そこから海外展開を含めたグロースを目指していたフェーズだったと思います。

── フリーランスでの参加ということは、ユーザベースは複数あるお仕事の1つだったわけですね。

林　そうです。初期は週に2日という契約でした。ぼく個人としても、いろいろ別のことをやろうと考えていた最中だったので、ユーザベースの案件はその中の1つという立ち位置でした。

── そこからユーザベースの開発チームを率いていく立場になられるわけですが、そのころのユーザベースの雰囲気で何か印象的だったことはありますか？

林　良い意味で「まさにスタートアップ」という雰囲気を感じていました。メインでサービスを開発したテックリード的な方をはじめとする社員のエンジニアと、当時からJava界隈で有名だった矢野勉さん（@t_yano）がいて、全部で十数人のチームだったのですが「社員のほうが立場が上」みたいな空気がまったくなかったんですよ。むしろ「業務委託の人は高いスキルを持って協力してくれる人だ」というリスペクトを感じていました。

── 当時、ユーザベースの開発スタイルはすでにアジャイル型と呼べるものだったのでしょうか？

林　いえ、特にアジャイル開発をやっているというわけではありませんでした。会社としてオープンなコミュニケーションが推奨されていて、閉鎖的でない空気もありましたが、そういう空気の中で個人がそれぞれの責任範囲を頑張っていくという開発スタイルだったと思います。

ぼく自身、特に自分から「アジャイルでやりましょう」と提案するようなこともなく、どちらかというと目の前の課題をひたすら愚直に解決していました。

── その後、現在に至るまでユーザベースでは林さんを中心としてアジャイル型の開発を実践していくわけですが、何かきっかけがあったのでしょうか？

林　ぼくがユーザベースを手伝うようになって半年ほどたったころ、当時のエンジニアのマネージャーから「今よりも良い開発をするには、どうすればいいと思う？」という相談を受けたんです。

それで、以前からいくつかの現場で導入して、継続して勉強していたこともあり、「それならXPというものがあるのでやってみませんか？」とお伝えしました。それがきっかけで、2013年の末ごろからユーザベースの開発チームでXPを始めることになったのです。

最高のプロダクトというより「最高の開発チーム」を作りたい

── 少し時間をさかのぼりますが、林さんはAgile Journeyの立ち上げにあたって「2005年ごろにアジャイルに関心を持った」と書かれています。そのころの話を聞かせてください

林　その記事にも書いたとおり、アジャイルに関心を持ったのは2005年ごろ、いわゆるウォーターフォールの開発に関して疑問を感じていた時期でした。それで、自分が一人でできることを部分的に取り入れながら、やれる範囲でアジャイル型開発の経験を積み重ねていった感じです。

── そのころ角谷さんはすでにアジャイル関連のカンファレンスや書籍の翻訳で活躍されていましたが、お二人は当時から接点があったのでしょうか？

角谷　いや、特に接点はなくて、自分が林さんとお会いしたのはつい最近、2022年の2月に声をかけてもらったのが最初です。なので、林さんの最初のモチベーションのような部分はよく知らなくて、今日はそれを伺いたいと思っていました。

林　モチベーションという意味では「最高の開発チームを作りたい」ということなんですよね。

角谷　「最高の開発チームを作りたい」というのは、林さんが普段からよく使う表現ですよね。そう考えるようになったきっかけが気になります。例えば当時どんな書籍を読んでいましたか？

林　いろいろと読んでいましたが、特にケント・ベック（Kent Beck）の『Extreme Programming Explained: Embrace Change』には大きな影響を受けていますね。ただ、最高の開発チームを作りたいと考えるようになったのは何かに憧れたとか感化されたというわけではなくて、自分の実体験を積み重ねた結果です。

Extreme Programming Explained: Embrace Change

著者: Kent Beck

Addison-Wesley Professional

── かなり早い段階からプロダクトや技術よりもチームに視点が向けられていたのが興味深いです。

林　「最高のチーム」とは何かをちゃんと言葉にしておくと、ぼくの定義では「最高のプロダクトを生み出せる能力を持ったチーム」となります。もし目標が「最高のプロダクト」だと、そこまでの過程に意識が向かなくなってしまう可能性があると思っていて、それは嫌だなと。例えば、お金や時間をかけることで、最高の開発チームでなくても最高のプロダクトを実現できる可能性はあるんじゃないかなと。

そうではなくて、自分がやりたいのは、このチームであれば何を作っても成功する、もしくは、成功する確率が高いチームを作ることなんです。自分の興味が「そういうチームをどうすれば作れるか」にあるとはっきり意識したのは、2010年ごろで、それから「最高の開発チーム」という言葉をよく使っています。

── それは「エンジニアが集まったときにそういうチームになるような仕組みを作りたい」というような意味合いでしょうか？

林　仕組みを作るのも1つですね。ただ、それだけではないと思っていて、最高のプロダクトを「どうやって」作っていくか、その「How」をずっと考えていて、仕組みも「How」の1つかなと思います。

── たしかに。

林　エンジニアだけでは最高のプロダクトはできないですし、PdMや営業、カスタマーサクセスの人達も含めて「開発チーム」だと思っています。そういう前提で、どうすれば最高の開発チームになるかをずっと考えている感じです。アジャイルのプラクティスなども、そのための大事な手段の1つだと捉えています。だからこそアジャイルに対してしっかりと取り組みたいなと。

── ユーザベースでXPを始めた2014年ごろには、すでに最高の開発チームを意識されていたことになりますが、例えば自分で起業して最高のチームを作るという選択肢も検討されたのでしょうか？

林　ユーザベースに入社することになったのは2017年なのですが、その際には独立して自分で事業を作ることも選択肢として考えていました。ぼくの中では「最高の開発チームを作りたい」っていうのがまずあるので、そのために自分で会社を作るのか、それともユーザベースにジョインするか、という選択肢がありました。

自分で会社を作れば、すべてを自分がコントロールして意思決定しやすいメリットはありますが、当然ながら事業として売り上げを立てるのがハードルになります。未経験の自分にとっては難易度が高い。

一方、それまでに4年くらいフリーランスの立場でXPをやらせてもらっていたこともあって、ユーザベースにジョインするという選択肢には「この会社だったら、自分が考えていることをいろいろと実践できる」という実感がありました。声をかけてくれた創業メンバーからも「最高の開発チームを作るならユーザベースでやってほしい」と言われたりして、それで自分では会社を作らずに社員になったという感じです。

── アジャイルにどう取り組んだかという話では、経営層やマネージャー層をどう説得すればいいかという悩みもよく聞くので、その心配がないことが入社前から分かっていたのは大きかったように思えます。

林　そうですね。実際のところユーザベースの経営陣は、自分たちでアジャイルという言葉を使っていたわけではもちろんないのですが、ぼくから見て「アジャイルな思考で常に考えているな」という印象でした。

全員が「このチームをよくするには？」を考えるしかない

── 林さんが目指す最高の開発チームについて伺ったところで、それをどうやって作るのかが気になります。フリーランスとして参加していたユーザベースのチームでは、まずXPをやるところから始めたのですよね。

林　 XPのプラクティスとして分かりやすいのは、ペアプログラミングの導入だと思います。それからテストですね。完全なE2Eテストを書き始めたり、いわゆるテスト駆動開発を始めたり。

継続的インテグレーションの仕組みや、バーンダウンチャートによるチームの状況の可視化もこのときから始めました。見積もりの仕方も、それこそ角谷さんたちが翻訳された『アジャイルな見積りと計画づくり』を読みながら実践していきました。

アジャイルな見積りと計画づくり価値あるソフトウェアを育てる概念と技法

著者: Mike Cohn
翻訳者:安井力、角谷信太郎

マイナビ出版

── それらのプラクティスを順番に導入していった感じですか？

林　いや、わりと一気にガラッと変えました。さらに、プラクティスをしっかり導入することにより品質が担保できるようになったので、細かくブランチを切ってレビューしてマージするのではなく、1つのブランチにみんなでプッシュしていくようにもしました。最近だと「トランクベース開発」と呼ばれるスタイルですね。

── それだけガラッと変えるのは、チームが十数人だったから可能だった？

林　それはあったかもしれません。それまでの仕事を通して技術的な面で信頼みたいなものは得られていたと思うので、「林がいいと言うならやってみよう」という感じで受け入れてもらえた気はします。

── 現在の林さんの立場は、ユーザベース全体でそういう開発スタイルを主導される役割だと思いますが、ここまでスケールさせるのに苦労したところはありますか？

林　アジリティが高く、かつ組織やチームが自己組織化されていれば自然とスケールできるはず、という考え方でいます。なので「これを実践したからスケールした」というものは特になくて、常に「今いる組織の状況を改善し続ける」ことだけをやってきた感じですね。その結果、自然とスケールされていったというか……。

── とはいえ、十数人であれば林さん個人の目が届くけれど、百人を超える全社だと難しくなりそうに思えます。どこかで「自分の目が完全に届かなくなってつらい」となる場面もあったのでは？

林　もちろん、新しく入ってくる方が増えたので顔と名前が一致するまでに時間がかかるようになったとか、各チームがやっている作業でパッと即答できないものが出てきたとか、そういうことはあります。

しかし、そもそも「ぼくが細部まで把握していなければみんながうまく動かない」っていうことはないはずなんですよ。なので「完全に目が届かないことを問題にはしていない」と言ったほうがいいかもしれません。

── 実は知らないところですごく困ってるチームがあるけれど報告がない、といった状況もあるのではないかと思いますが、それはどうやって避けるのでしょうか？

林　各チームでバーンダウンチャートを作っているので、オフラインのときには帰り際にホワイトボードを見て「あー、なんかちょっと困ってそうだな」みたいに把握できます。最近はオンラインのことも多いので、Slackに週1回は自動でバーンダウンチャートがポストされるようにしていて、それを見て「みんなの想定とは違う状況になってるのかな」みたいに状況を把握しています。

あとは、1on1ならぬ「チーム・オン・ワン」をやっています。

── チームのメンバー全員が林さん一人を相手に困りごとを話す会、という感じでしょうか？

林　はい。そうです。当然、すべてのチームが常に最高にうまくいってるなんてことはないし、ぼく自身にも伸びしろや課題もあります。各チームのエンジニア全員が「このチームをもっとよくするには？」を考えることによって、少しずつチーム全体としてアジャイルへの取り組みを改善していくしかありません。

── そうした取り組みによりチームは変化していけるものなのでしょうか？

林　うまく変化するケースもありますが、例えばアジャイルに詳しい人がポンと入ったくらいでは変わらないこともあります。「チームシャッフル」といって、5人ほどのチームなら3カ月に1回くらい一人か二人ずつメンバー入れ替えたりもしています。

それでも変わらない場合は、チームメンバーと話し合って、自分たちの進め方・考え方を一度リセットしつつ再スタートしたらうまくいき始めた、みたいなケースもあります。

── うまく変われなかったケースでは、チームの課題に必要な文脈やドメイン知識を、チームシャッフルだけで引き剝がすのが難しかったということでしょうか？

林　そう言えるかもしれません。実際にチームシャッフルしても前のチームの仕事を完全にやらなくなるわけではなくて、必要があれば手伝うし、一時的に前のチームのメンバーとペアプロもします。 3カ月後のチームシャッフルで以前のチームに戻ることも可能です。

あとはユーザベースのやり方として「暗黙知を暗黙知のままとしてドキュメント化しない」という方針があり、そういうことも影響していたかもしれません。

── ドキュメント化しないというのは、意識してそうしているのですか？

林　はい、意識してやっています。誰かが信用できる完璧なドキュメントを書いても、やがて古くなって状況と合わなくなる。そういったリスクやメンテナンスのことを考えると、そもそも全員で知識量を上げていくほうがみんなも楽しいだろうという考え方です。

開発業務に関して不明な情報があれば、オフラインなら直接、オンラインでもバーチャルオフィスのGatherとかSlackで「ちょっといいですか？」と聞きにいくほうが早いですしね。

── エンジニアはそれでいいとして、チームにいる営業のメンバーなどは「ドキュメントがなくて困る」という状況にならないでしょうか？

林　エンジニアのエゴで何も書かないというわけではないので、対外的な説明の材料として必要だったり、エンジニア以外がいつでも見られる情報を提供する必要があれば、それはちゃんとドキュメントを作ります。あくまで開発チームにおける作業手順だったり、そういう日々の開発業務に関するドキュメントみたいなものは基本的に残していないという話です。

「いまどきエクストリームプログラミングで大丈夫か？」

── ここまで林さんが考える「最高の開発チーム」について伺ってきました。その中で角谷さんは「エクストリームプログラミング顧問」という役割で、特に「XP」を掲げている背景なども気になりますが。

角谷　正直に言うと、林さんから最初に相談されて「XPでやってます」と聞いたときには、「いまどきXPでやってるって、それ大丈夫？」みたいに思いました。

── 確かに、昨今のアジャイル開発ではむしろスクラムの相談になるケースが多そうですね。

角谷　実際その通りで、「アジャイルで困ってます」と言われてお手伝いに行くと、「皆さんが考えるスクラムと私が考えるスクラムが違うようなので、まずはスクラムガイドを一緒に読みましょう」みたいな話になることが多いんですよ。ユーザベースのようにXPを開発の仕方の中心に据えてやっているところって、2020年代だと絶滅危惧種とさえ言えるかもしれません。

それで半信半疑ながら林さんから話を聞いたら「全体で100人以上の開発者のほとんどを小さなチームに分けてXPをやっている」と、けっこうな規模でうまくXPをやれている。しかも、そこにはデータサイエンスのチームなんかも含まれている。「この規模でXPをやっていけるんだ！」と感動したことを覚えています。

── とはいえ、林さんとしては何か困っていることがあったので角谷さんに相談されたわけですよね。

林　はい。まず、ぼくが時間を割かないといけない業務が増えて、チームとアジャイルやXPの話をする機会が減っていました。そうでなくても全体の人数が増えているので、伝える回数を増やさないと以前と同じようには伝わらない。それが難しくなっていて、何とかしなければと考えていました。

それから、ぼくが一人でアジャイルの話をするより、もう一人別の角度で話をしてくれる人がいるほうが、聞く側としての説得感や納得感が増すだろうという意図もありました。単純にぼく自身が、アジャイルやXPの理解を深めるために角谷さんの話を聞きたいということもあります。

角谷　そんな話を伺ったので「じゃあ皆さんとアジャイルやXPの話をするところからやってみますか」と、開発者全員参加で『クリーンアジャイル』の読書会を始めることになりました。

Clean Agile 基本に立ち戻れ

著者: Robert C. Martin
翻訳者:角征典、角谷信太郎

アスキードワンゴ

── XPというとケント・ベックの白本（『エクストリームプログラミング』）^※が選択肢になりそうですが、それではなく『クリーンアジャイル』から読み始めた理由は何かあったのでしょうか？

エクストリームプログラミング

著者: Kent Beck、Cynthia Andres
翻訳者:角征典

オーム社

角谷　あの本だと、私から語りたいことが多過ぎて、永遠に終わらない読書会になってしまうんですよね……。ちょうど角征典さんと自分で翻訳した『クリーンアジャイル』が出たタイミングだったので、「XPでなくアジャイルだけど訳者がいるほうが面白いだろうから」と言ってこちらにしました。

※編注ケント・ベック『エクストリームプログラミング』: 表紙のイメージから「白本」とも呼ばれる『Extreme Programming Explained: Embrace Change』をケント・ベックが著したのは1999年。その後「アジャイルソフトウェア開発宣言（アジャイルマニフェスト）」を経て、2004年に改訂。日本語訳も初版（2001年）と第2版（2005年）それぞれで刊行されましたが、現在は上掲した第2版の新訳（2015年）が広く流通しています。本記事での同著作への言及も、基本的に以降この新訳第2版の記述をベースとします。

凸凹してたアジャイルへの認識を揃えてベースを作る

── 実際に読書会を始めてみてどうでしたか？

角谷　皆さんから質問をもらったり話したりしているうちに、ちょっとずつ林さんの困りごとというか、課題も見えてきました。林さんも語っていたように、純粋に人数が増えて新しく入ってくる人も多くなると考え方がどこまで届いているか、認識がどこまで揃ってるのかを確認しづらくなるんですよね。

── 林さんの話にあったチーム・オン・ワンは、まさにそれを確認するアクティビティですよね。

角谷　チームと林さんが会話することでいい感じにやれる面は大きいと思います。しかし、どうしてもその場では分からないこともあります。例えば、「チーム・オン・ワンのセッションで交わされたメッセージをチームの一人一人はどこまで受け止められているか？」みたいなことって、その場では分からないんですよね。

そこで自分が「ふだんアジャイルで困ってることや悩ましいことを教えて」って聞くと、いろいろなことが見えてくるわけです。「字面だけで理解してしまっていたのかな」みたいな質問もけっこうあるので、そういう質問を通して「メンバー間での認識の凸凹」が分かります。

── 特にXPは、開発手法として見るとスクラムほどにはパッケージ化されていない印象があるので、多人数で考え方のベースを合わせるのは大変そうです。

角谷　ケント・ベックの白本に「XPで何をやるか」はいろいろ書いてあるんですが、その心というか、プラクティスや原則をどう解釈するかを飲み込むには時間がかかってしまうんですよね。アジャイルと一緒に育ってきたメンバーばかりなら何とかなるけど、規模が大きくなって途中から入る人が増えればやっぱりギャップができます。そこをちょっとずつ埋めるのが、ユーザベースにおける自分の役割だなと分かってきました。

── ユーザベースでの角谷さんによる読書会には何人くらい参加されているんでしょうか？

林　任意参加ではなく、可能な限り参加という運用にしているので、ほぼ全員初回から参加しています。

── もう2年くらいたっているわけですが、何か成果みたいなものは出てきていますか？

角谷　やっている当人としては「なんでこういう流れで、こういうプラクティスで仕事をやってるのか？」の意義づけとして一定の効果は出てるはず、という気持ちでやってます。

林　ぼくも、その点はすごく良かったと思っています。読書会参加者のアンケートでもポジティブな意見が圧倒的に多くて、「あのとき林さんが言ってたことの意味が分かりました」とか、「林さんと同じことを（角谷さんが）たくさん言ってました」といった反応があって、見事な再学習になっています。ぼくが伝えきれていなかったことを角谷さんに補完してもらえているので、間違いなくみんなの意識は上がっていると感じています。

角谷　逆に、林さんから見積もりや計画の心構えをレクチャーしてもらう機会なんかもあって、我ながら「チームの認識の凹凸を揃えてベースを作る」成果は出せているかなと思っています。

── 読書会には林さんも参加されているんですよね？

角谷　いえ。「みんなの率直な意見が聞きたいし、また別の視点で話をしたいから、林さんは来ないで」とお願いしました。「寂しいかもしれないけど」って。林さんはフラットを心がけていると思いますが、メンバーの人たちはどうしたってCTOや役員っていう人との間には上下とか距離を感じるものなんです。

── もともとは林さん自身が角谷さんの話を聞きたかったから声をかけたという話もありましたが……。

角谷　ちゃんと毎回録画して、それは渡しているので、あとから視聴してもらえているはずです。

林　はい、全部見てます。見ながら「ぼくが参加していなくて本当に良かったな」って思っています。ぼくがいたら途中で口を挟みそうな場面が何度もあるんですよ。

エンジニアリング組織の秩序が自発的に形成されるには

── この対談では「ユーザベースでどんなプラクティスをどう実践しているのか？」といった質問も想定していたのですが、ここまでの話を聞く限り、お二人とも「手法の導入」より「考え方をどう理解してもらうか」にコストをかけているのが印象的でした。

角谷　ソフトウェアを作るときは基本的に人がいっぱい絡むし、難しいし、時間がないわけです。それが大前提なので、腕力でバーンってやる以外のアプローチを探そうと思ったら、不確実なものを減らしながら、たくさんの人が決まった時間の中で、それぞれどう行動すればベストを尽くせるかを考えていく必要がある。それを開発する人たちみんなに考えてほしいというのが、アジャイル型開発というアプローチなんだと思っています。

林　ぼくの考え方も角谷さんとほとんど一緒です。 1つ付け加えるとしたら、やり方とかプラクティスから入るとイレギュラーな問題に陥ったときに対処できないので、自分たちで考えて自己組織化できるチームみたいなものを意識しているところですね。

角谷　林さんは「エンジニアリング組織の中で自発的に秩序を形成するようにしたい」って本気で思って、取り組んでますよね。

林　はい。プラクティスは守破離でいう「守」だと思っているので、もちろん大事なんですが、その本質をちゃんと学んで自分たちでアレンジして「破」や「離」ができるチームを作りたいですね。

── もしかしてプロダクトやプロジェクトよりも「自己組織化するチームを目指す」という林さんのアプローチを考えると、開発手法としてはXPと親和性が高いのでしょうか？

角谷　実は、XPで「自己組織化」は明言されてなくて、「自己相似性（Self-Similarity）」や「分割統治ではなく統治分割」という表現²を通して、そういう考え方がふわっと述べられています。具体的に何をしたらいいのかは教えてくれない。

むしろ自己組織化という考え方を中心においていたのはスクラムだったと言えます。スクラムガイドでも、最新の2020年版では「自己管理」という言葉になっていますが、2017年版までは「自己組織化されたチーム」が明記されていました。

林　そうだったんですね。でも個人的には、アジャイルに興味を持っていろいろ勉強していたときに「XPだと自己組織化が促進されやすいかも」という印象を抱いたのを覚えているんですよ。プログラマー側に焦点が当たっているように感じたというか。

角谷　 XPは「仕事でソフトウェア作るのに、どういうプログラマーになるといいかな？」をケント・ベックという人がひたすら考えて書き出したものなので、ソフトウェア開発者とかプログラマーの気持ちに寄り添っているのは間違いないです。

なのであの白い本も、短いけれどちゃんと読むのは大変です。それでユーザベースの読書会では別の本にしたんですが、そろそろ読み終わるので次はいよいよケント・ベックの白本でいいかもしれない。

林　もしかしたら正しくスクラムを理解している人と正しくXPを理解している人は、ソフトウェア開発において同じような行動をとれるチームを形成していて、それがぼくの考える自己組織化なのかも？

角谷　アジャイルマニフェストにある12の原則にも「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」とあるので、その理解でよさそうです。

とはいえ、私としては「自己組織化」というキーワードは取り扱い注意な概念だと思ってます。聞こえはいいけれど、適切に解釈して運用するのは難しいというか……。

いい感じに動く指針となる原則を自分たちの言葉で

林　実はチームのメンバーに大学で物質科学における自己組織化を研究していた人がいて、その人によると自己組織化とは「物質や個体が、系全体を俯瞰する能力を持たないにもかかわらず、個々の自律的な振る舞いの結果として、秩序を持つ大きな構造を作り出す現象」らしいのです。

それを聞いて、ぼくが目指したいのはまさにそれだなと感じました。経営を含めた組織全体を俯瞰する立場にはないメンバーが、それぞれ自律的に動いた結果、大きな秩序を持ったチームになるようにしたい。

人間ってわりと全体を把握したがるというか、知らない部分があると不安になる生き物だと思うんです。でも、全部を知っている人がいなくても、一人一人がいい感じに動いたら、結果的にかっこいい状況になれるはずだとぼくは信じていて、その「いい感じに動く」指針として、XPで示されている価値（values）や原則（principles）が個人的にしっくりくるのかもしれません。

角谷　組織の中で各自が自律的に振る舞うにあたって、良し悪しの基準に沿った行動をガイドするのが「原則」ですからね。

林　そういう意味で、これからやりたいこととして「価値」と「プラクティス」をつなぐ「原則」を自分たちの言葉で改めて作るというものがあります。

── それはXPにおける「原則」とは別に、ということですか？

林　はい。原則を自分たちで考えて言語化することが、これからぼくや角谷さんではないメンバー自身がXPを広めていく上で重要になるだろうと考えているんです。というのも、そういう言語化の実践って携わった人をめちゃくちゃ成長させるんですよね。ペアプログラミングのガイドラインを作ったときに感じたことですが。

「原則」を自分たちで再言語化してみることは、それが結果的にケント・ベックの白本にある「原則」とほとんど似た感じのものになったとしても、XPをスケールさせる上ですごく有効だろうなと。

角谷　やっぱり次は腰を据えてケント・ベックの白本を徹底的に読み込むしかなさそうですね。