SaaS Product Team の野口です。
以前にもいくつかの記事で触れたように、SaaS Product Team では XP（エクストリーム・プログラミング）をベースとしたチーム開発に取り組んでおり、ほぼ全ての作業をペアで行っています。*1
かく言う私もこのチームに入ってから 1 年以上の間 *2、日々ペアプログラミングに取り組む中でわかってきたことがあるので、この記事で共有したいと思います。
XP はうまくいくことを極限（エクストリーム）まで推し進めることから生まれた
Kent Beck の『エクストリームプログラミング』の「はじめに」には、以下の記述があります。
本書は、良いソフトウェア開発チームの共通点を私なりにまとめたものだ。個人的にうまくできたことや、うまくできているところを目の当たりにしたことについて、私が考える最も純粋で最も「エクストリーム」な形で抽出している。（『エクストリームプログラミング』pp. xvii、強調は筆者）
また、インタビューでこのようにも語っています。
チームに、私が必要不可欠だと思うこと全てのツマミを10に上げ、それ以外はすべて省いてくれと求めました。（翻訳を Wikipedia「エクストリーム・プログラミング」より引用、強調は筆者）
このように、XP は、Kent Beck のソフトウェア開発における体験からうまくいっていたことを極限まで推し進めることから生まれたと言えます。
ペアプログラミングは XP の 5 つの価値を極限まで推し進める
XP では、チーム開発を導く共通の価値を 5 つ定めています。
全員がチームにとって大切なことに集中するとしたら、何に集中すべきだろうか？ XP では、開発を導く 5 つの価値を採用している。コミュニケーション、シンプリシティ、フィードバック、勇気、リスペクトだ。（『エクストリームプログラミング』pp. 16）
ペアプログラミングは XP の主要プラクティスの 1 つですが、個人的には XP のプラクティスの中でも最も核心に近く、XP を特徴づけるプラクティスだと考えています。なぜなら、ペアプログラミングは XP の 5 つの価値をいずれも極限まで推し進めるプラクティスだからです。
以下、5 つの価値それぞれについて、その理由を説明していきます。
注記
SaaS Product Team は全体で数十人のチームです。現在は SPEEDA / INITIAL / FORCAS Sales という 3 つの製品を扱っており、製品や、マイクロサービス・マイクロフロントエンドの単位で数名程度の小さなチームに分かれて日々の開発を行っています。以降の文章で出てくる「チーム」という言葉は、特に断りがない場合、この「数名程度のチーム」を指しているとご理解ください。
コミュニケーション
ペアプログラミングでは、常にコミュニケーションを取ります。
「常に」とはどういう意味でしょうか。文字通り、「常に」です。SaaS Product Team で愛用している「ペアプロの心得」にも、こう書かれています。
6.ドライバーをしているときに進行中の作業についてこれから何をするのか、いま何をしているのかについて話してますか? ペアプログラミングでは、15秒の沈黙ですら長すぎます。（強調は筆者）
このように、ペアプログラミングには絶え間ないコミュニケーションがあります。ずっとペアプログラミングをしていると、ずっとコミュニケーションを取り続けることになります。エクストリームなコミュニケーションです。
また、チーム全体でペアプログラミングに取り組んでいる場合、継続的なペア交代によって、ペア間のみならずチーム内でのコミュニケーションも取り続けることをシステムに組み込むことができます。私たちのチームでは、たとえば 1 時間に 1 回程度ペアの交代を行っています。具体的な交代の仕方については以下の記事に詳しいので、ご参照ください。
なお、この記事にも書かれているように、チーム間でのメンバーの入れ替えも行っていれば、チーム内のみならずチームをまたいだコミュニケーションを取り続けることもシステムに組み込むことができます。このようなチームメンバーの入れ替えが機能するのも、やはりペアプログラミングによって継続的なコミュニケーションと知識の撹拌が実現できているからだと思います。
シンプリシティ
シンプリシティを保つのは、難しいことです。シンプリシティの価値を十分理解したプログラマーでも、常にその価値を尊重できるとは限りません。
ペアプログラミングには、常に 2 人の頭脳、2 人の目があります。1 人がシンプリシティに反してしまいそうになったとき、もう 1 人がそれに気づかせてくれます。設計判断に迷ったとき、あるいはシンプリシティに反するような設計・実装を行ってしまっているように見えたとき、「最もシンプルで、うまくいきそうなものは何ですか？」（「エクストリームプログラミング」pp. 17）という質問を 2 人のうちどちらかが発することができます。そうやって、常にシンプリシティを保ち続けることができます。
また、ペアプログラミングでは常にコミュニケーションを取り続けているので、今すぐに必要とは限らない機能に気づいたら実装を延期したり、2 つの機能に同時に取り組んでいることに気づいたらストーリーを分割したり、といった判断も即座に行うことができます。目の前のコードだけに限らず、機能（ストーリー）やプロジェクトマネジメントの領域までを含む、エクストリームなシンプリシティです。
フィードバック
コードレビューというプラクティスがあります。これは、ある人が書いたコードに別の人がフィードバックを与えるための 1 つのやり方です。
ペアプログラミングでは、ペアのパートナーは、実装が完了してからではなく、常にフィードバックを与え合います。コードレビューのときを待つ必要はなく、むしろ常にコードレビューというフィードバックをしている状態と言えます。エクストリームなフィードバックです。
ペアで継続的にフィードバックを与え合えば、1 人でプログラミングしていたときよりもよい設計や実装を導くことができます。「ペアプロの心得」にもこう書かれています。
17.パートナー同士で設計、方向性、技法についての対立は起きていますか? 対立が起きていなければ、ペアは機能障害を起こしています。
対立から対話が生まれ、2 人の中で、またチームにとって真に最適な解が導かれます。
なお、SaaS Product Team におけるペアプログラミングとコードレビューとの関係については、以下の記事で考察されています。
個人的には、XP の価値・原則・プラクティスをすべて取り入れて活動していれば、別途コードレビューを行う必要が生じる可能性は低いと考えています。（もちろん、チームの状態や開発する対象にもよりますが）
勇気
ペアプログラミングの中には、いたるところで勇気を発揮する機会があります。
- ペアのパートナーに、技術的な対立を生むようなフィードバックを与える。
- 相手が何をしているのかわからないとき、手を止めて説明してもらったり、あえて自分が作業する。
- まずい設計や重大な問題を見つけたとき、見て見ぬ振りをせずそれに向き合う。
- 難しい問題があるとき、手探りでもとにかく進んでみる。
- 進んできた方向がシンプリシティなどの観点から間違っていたとわかったとき、立ち止まって引き返す。
- 行き詰まったとき、もっと頑張るのではなく、あえて休憩を取る。
そして、これらの機会は、ペアで作業しているからこそ、最大の機会となります。1 人では勇気が足りずにできないことも、2 人ならできます。エクストリームな勇気です。
といっても、勇気がすべてではありません。
勇気のみでは危険だが、他の価値と合わせれば強力だ。（『エクストリームプログラミング』pp. 19）
ペアプログラミングをしていれば、2 人のものの見方を合わせて、勇気と他の価値とのバランスを取ることができます。バランスが取れているとわかるからこそ、勇気を持って踏み出すことができます。
リスペクト
ペアプログラミングをしていると、常にペアのパートナーのコンテキストを取り込みながらコードを書くことになります。
それは、リスペクトを育む場所です。相手が何を大事にしてコードを書いているのか。何が得意で、何が苦手なのか。結果として書かれたコード。そのすべてをリスペクトしたとき、ペアプログラミングはうまくいきます。そして、チームが書いたコードへの将来のリスペクトにもつながります。「これはあいつ（ら）が書いたコードだから」などという言葉はそこには生まれません。
「ペアプロの心得」にもこう書かれています。
11.パートナーの仕事は自分の仕事であることを認識していますか? ペアプログラミングは、お互いに100%の責任を持つ共同作業です。「君の設計にバグがあるよ」「そのバグは、君の分担部分が原因だ」などと言ったり、考えたりすることは許されません。
ペアプログラミングでは、すべては「私たちが書いたコード」です。ペアプログラミングは、ペアのパートナーのアイデアや、今まさに書かれたコードをリスペクトし続けることであり、エクストリームなリスペクトです。
1 人でプログラミングをしていても、他の人や他の人が書いたコードをリスペクトすることはできます。そして、ペアプログラミングをしていれば、常にリスペクトを育む機会があります。
旅は続く
この記事では、ペアプログラミングが、XP の 5 つの価値をエクストリームにするのに重要な役割を担うことをお話ししてきました。
私見ですが、ペアプログラミングというプラクティスから XP の 5 つの価値への直接の影響があることを意識すると、ペアプログラミングへの取り組みの質も、そうしない場合とは少し変わってくるように思います。
『エクストリームプログラミング』では、XP のプラクティスは組み合わせて使うのがよいと言われています。
XP のプラクティスは組み合わせたほうがうまくいく。一度にひとつだけプラクティスを選んでも改善は見られるだろう。だが、組み合わせて使うようになれば、劇的な改善が見られるはずだ。プラクティスの相互作用が、その効果を増幅させるのである。（『エクストリームプログラミング』pp.34）
私が日々ペアプログラミングやテスト駆動開発を始めとする XP のプラクティスに取り組む中で、このことが意味するところがようやく少しずつわかってきつつあると感じます。それぞれのプラクティスは原則を通して価値を支え、それぞれの価値は支え合っています。
一緒にペアプログラミングと XP を探求しませんか？
私たち SaaS Product Team では、「技術力で、ビジネスをリードする」をミッション、「阿吽の呼吸で走り、進化する流体的組織」をビジョンとして、日々精力的にサービスの開発・運用に取り組んでいます。
そして、一緒にペアプログラミングや XP を探求し、ミッション・ビジョンの実現に向かって進んでくれる仲間を絶賛募集中です。
XP やアジャイルのマスターである必要はなく、「TDD、個人ではやってみたけど業務でもがっつりやってみたいんだよな」とか、「ペアプロ、たまにやってるけどもっとやりたいんだよな」といったレベルでも構いません。少しでも興味のある方はぜひご応募いただけると幸いです！
ペアプログラミングをしているのはわかったけど、組織文化についてもっと色々知りたいな、という方は、去年私が入社したばかりの頃に書いたこの記事も見ていただければと思います。