私はひどい花粉症があって、毎年春から初夏にかけて日々花粉症にものすごく悩んでいます。時には1日ティッシュペーパーを1パック使い切るほどひどい日があります。それだと、あんまり仕事できないので、毎年強い薬を処方してもらって、それに頼って症状を抑えています。既に5月末だし、もう大丈夫だろうと思って、先日薬飲むのをやめたら、翌日からくしゃみや鼻水が止まらなくなりました。やはり花粉症を甘く見てはいけなく、今日はペアプログラミングの実践現場を見学しに行く大事な日でもあるので、昨夜はしっかり薬を飲みました。おかげで、今日とてもいい気分です。天気もよく、いかにも風光明媚な夏日の光景です。

訪問先は経済情報サービスを運営している株式会社ユーザベースで、私も知らない会社です。先日久しぶりに会った友人がその会社に就職していて、自社サービスの開発にアジャイル開発手法「ペアプログラミング」を実施していることを聞いて、ぜひ見学させていただけないかと懇願したことが訪問のきっかけとなります。

アジャイル開発

アジャイル開発といえば、トヨタの生産方式が由来となっていたそうです。米国の研究者がトヨタの生産方式を研究し、「リーン生産方式」として体系化していました。この「リーン生産方式」をシステム開発に応用する考え方（リーン思考）がリーンソフトウェ開発と呼ぶようになり、その傍流に「アジャイル開発」があるというわけだそうです。
アジャイルという言葉を聞いたのは実に十数年前でしたが、聞いただけで深く勉強しようとしませんでした。その時のプロジェクトマネジメントといえば、私が完全に自己流で、WBSももっぱらExcelを使っていました。いろいろ試行錯誤しながら、開発手法を応用する大切さを痛感してきました。
人類の発展の歴史からみれば、人間は日々の生産活動から得た経験値をまとめて理論化し、それをまた生産活動に応用することで、生産性を高まってきたともいえると思います。開発現場も同じで、理論化した開発手法の応用は開発の効率化にとって不可欠だと考えています。自己流は偶にうまく行ったとしても、生産性を劇的にアップすることがあるまい。話が脱線してしまいますが、我々も独自の実践として、ソースコードやテスト設計書などの自動生成によって、属人的な要素を可能な限り排除することで、劇的な生産性アップをもたらすシステムジェネレーションツールを９年前にリリースしました。

アジャイル開発の話に戻りましょう。実は我々も数年前からお客様の現場や自社製品開発のプロジェクトにスクラムというアジャイル開発手法応用し始めました。いろいろ制約もあって、部分的な適用に過ぎず、効果も多少出ていますが、期待していたほどでもなかったです。最もうれしかったのは、ようやくウォーターフォール開発の地獄から脱出するための一歩を踏み出したことです。日本にアジャイル開発手法を応用している現場はどれくらいあるか、そういう現場の実態をどうなっているかとよく考えていました。
そのため、友人から自社で20人前後のチーム全員がペアプログラミングで開発しているという話を聞いた時、正直驚きました。ペアプログラミングは二人で一人の仕事をするような感じで、アジャイル開発手法の中で、私が最も抵抗がある手法と言えます。友人の話によると、ものすごく効果が出ていて、毎日の仕事がすごく楽しんでいるとのことです。しかし、友人もペアプログラミングをやり始めた当初はいろいろ不慣れで、よく上司の林CTOに叱られたそうです（笑）。そのわくわく話していた姿に本当に感心しました。また、彼のおかげで、我々がそのペアプログラミングの開発現場に見学することも林CTOから許可をいただきました。

職場環境

株式会社ユーザベースは恵比寿に所在しています（7月に六本木に移転する予定だそうです）。恵比寿には私が来日した翌年(2003年)客先の現場で数ヶ月くらい常駐したことがありました。そのあともほとんど来ることがなく、十数年ぶりの感じで本当に懐かしいです。周りに高層ビルが少ないので、遠くからも訪問先の恵比寿ファーストスクエアというビルがよく見えます。
約束時間よりも10分早い16:20に所在階の10階に着きました。エレベーターホールからオフィス入り口のところに張られたでかいガラスの壁を通して、中の様子ものぞけます。スーツというところか、我々みたいにビジネスカジュアルの姿もほとんどなく、完全カジュアルスタイルになっている感じです。我々の客先現場でよく禁止となっているジーパン、半ズボンやサンダルなどを着ている姿も廊下に出入りしています。第一印象として、自由奔放な仕事環境との感じです。
友人が林CTOとともに現れ、我々を中に案内してくれました。入り口に面している壁のところには独立した広い空間があり、壁側は投影用スクリーンやワイトボードが置かれ、外側は数十人ほども座れる弧状の階段式座席となっています。ぱっと見バンド演奏用の舞台のように見えますが、ここでは対外のセミナーや勉強会もよく行われるらしいです。中には人々が机やワイトボードを囲んで三々五々打ち合わせしています。

我々もそちらの空いているスペースに案内されました。林CTOはとても厳しい方だと想像していましたが、対面で会話すると、温厚で話しやすい印象でした。友人とともにペアプログラミングの適用実態を淡々と紹介していただきました。

ペアプログラミング実施概要

ここでのペアプログラミングは一年ほど前に林氏がCTOになってから始めたが、林CTO自身がアジャイル開発の経験が長く、10年以上前からもたくさんのプロジェクトでいろんなアジャイル開発手法を携わていたとのことです。そこでウォーターフォール開発の弊害を確実に克服できることなどアジャイル開発の効果を実感し、もうウォーターフォール開発には戻れないと仰っていました。

• 二人ずつ1ペアで、積極的にコミュニケーションをとりながら担当するユーザーストーリーを一緒に進んでいく。(あんまりにも頻繁にコミュニケーションをとっているので、周りの方からうるさいといわれたこともあったが、林CTOはそれを頬被りしているらしい(笑))
• 1時間か1.5時間（時間はチーム毎に決める）ごとにペア中の一人がシフトし、別の方とペアで担当ユーザーストーリーも変わる。
• 前回シフトしていないメンバーは次のシフト対象となり、一つのユーザーストーリーに担当する時間がMAX2シフト枠。
• 必ず一人は残っているので、メンバーが変わっても、ユーザーストーリーが変わることがなく、そのまま続けられる。
• メンバーが休暇などによって、全員がペアと組めない場合は一人でユーザーストーリーをやることがあるが、その人がずっと一人だけではなく、シフトによって変わる。
• 設計や方針が大きく変更が必要な場合は必ずチーム全員で話して、最善案を決めてからペア作業に戻る。
• マイクロサービスの開発がメインで、一つのマイクロサービスの開発着手時、設計段階として、最初のアーキテクチャ、CI環境、使用する技術、言語、FWなどはチーム全員で検討する。そのため、1個のシステムに複数の開発言語やDBを使用することとなる。開発言語はKotlinのほうが最も多い（他はclojure、Dart、Elixir等）。
• チーム全員で会話する場合(上記の設計段階や設計方針変更時の検討など)、必ずチーム全員で話して、しかも全員が自分の意見を言い出す（他の人とほぼ同じでも自分の言葉で説明する）。（友人はこのように述べています：そこは一番楽しいところですね！！普段の開発のようにリーダーが全て決めてあとはメンバーに実現してもらう形と違い、自分が考えた設計と他の人の案とぶつけ合って、それぞれのメリデメを理解し視野が広けるのでめちゃ勉強になります。そのためあえて林さんなどレベル高い方の案は最後に出してもらっています。）
• 早く本番リリースして、ユーザからフィードバックをもらってサービスを常に改善していくことを目指し、本番リリースの頻度が多い。
• ユーザーストーリーをみんなでポイント(相対工数)を評価し、ポイントが大きければ、複数のストーリーに分割する
• 細かい設計書を原則書かず、テスト駆動開発(TDD)の開発手法で要件を明確し、認識のずれを防ぐ。(テストケース自体が設計書となる)

ペアプログラミングの効果

ペアプログラミングといえば、二人で一つのユーザーストーリーをやるイメージですが、本当に二人分の成果を出せるか我々もすごく疑問を思っているところです。林CTOのプロジェクトも効果が疑問視されたことで以前いた現場の重役からやめてくれないかと言われたことがあったが、断ったらしいです。現在のユーザベースではやめて欲しいと言われたことは無いとの事です。友人がその疑問に対し、以下のように説明しました。

• 二人で一緒にやるときは、常に集中しないと、相手にやろうとしていることについていけなくなるので、作業中は全くさぼることができなく、精神がかなり集中していることで、頭の回転も速く、それでハイパフォーマンスを出している。またそのため、結構疲れやすいので、1時間ごとに10分くらいの休憩をとり、残業がほとんどしない（できない）。
• 二人で頻繁にコミュニケーションをとれていて、すべての内容がペアで合意済みなので、レビューは不要。また属人的な要因を排除でき、ソースにバグを埋める余地が少ない。
• ペアが固定ではないため、みんなと頻繁にコミュニケーションをとることができて、人間関係が良くなり、コミュニケーション力が劇的に向上。
• チーム全員がすべてのユーザーストーリーを担当しているので、誰か休暇などでいなくなっても、引き継ぎすらいらなく、ユーザーストーリーの継続に支障ない。
• またそれによって、スキルアップが早く、メンバーのスキルのばらつきが抑えられるだけでなく、みんなの知恵が成果物に反映できて、よりいいものを作れる。 私見ですが、単に二人一緒に一つのユーザーストーリーをやるだけだと、おそらく二人分の成果を出せなく、コミュニケーションを重視することによる作業効率の向上、作業ミスの低減、属人的な要素の排除、レビュー工数の削減などで総合的に二人が別々のユーザーストーリーやるよりも生産性を向上させることができたと思います。

利用するツールや手法

ペアプログラミングの適用に利用された以下のツールや手法が紹介されました。

• 看板
• プランニングポーカー(ユーザーストーリーの見積用)
• バーンダウンチャート
• テスト駆動開発(TDD)
• 継続的インテグレーション(CI)
• 振り返り(週単位)

ここは名前のみの紹介で、各項目の詳細を知りたい方はグーグルしてみてください。

後記

アジャイル開発手法自体はもう新しくないですが、日本のIT業界ではまたそれほど普及できていないのが現状です。従来のやり方を守るだけでは、一向に生産性アップが実現できず、ますますリードタイムにおいて後れをとることとなり、世界という舞台での競争ができなくなります。林CTOのような積極的にアジャイル開発を推進していく方には敬意を表したいです。また、今回このような貴重なチャンスをいただくこと、この場を借りて改めて感謝を申し上げます。

また、友人からご紹介された下記のサイトにもご参考されたい。
ペアプロ23条

周@ソフトシンク