英国コーンウォールで開かれた第５回‘Agile on the Beach’カンファレンスで， InfoQは，UnrulyのAlex Wilson，Benji Weber両氏と話をする機会を持った。両氏は‘Product Development in an Unruly Mob’と題したプレゼンテーションを行って，Unrulyソフトウェア開発チームがその能力を最大限に発揮する上で，モブ(mob)プログラミングをいかに活用したかを論じていた。
InfoQ: Alex, Benji, こんにちは。今日はご一緒頂いてありがとうございます！あなた方の所属しているUnrulyは，ソフトウェア開発産業の中でも，アジャイルアプローチを仕事にフル活用していると言う点で非常に高い評価を受けていますが，どのような活動をしているのか，なぜ企業としてこの方法を選択したのか，少し説明して頂けますか？
Wilson/Weber: UnrulyはOpen Webで公開したビデオの視聴追跡と共有を行う，広告技術の企業です。
Unrulyでは以前からずっとXP(Extreme Programming)の原則を採用しています。開発チームではペアプログラミングや継続的デプロイメント，テスト駆動開発を創業当初から実践してきました。さらに珍しいと思うのは，Unrulyでは迅速なフィードバックというXPのコア原則を採用して，組織全体が(製品開発以外でも)変化を受け入れていることでしょう。
InfoQ: 今回の’Agile on the Beach’カンファレンスでは，お二人ともモブプログラミングの話をされましたが，これがどのようなものか，どのようなメリットがあるのか，簡単に説明をお願いします。
Wilson/Weber: モブプログラミングとは，“同じ時に，同じ場所で，同じことを，同じコンピュータ上で行っている，すべての優秀な人々”(Woody Zuill氏による定義) のことです。 私たちはこれを，(すでに採用している)ペアプログラミングの次のレベルアップだと考えています。
Woody Zuill氏は，モブプログラミングのヒントを，Llewellyn Falco氏から得たと記しています。氏は私たちと同じように，チームから多くのものを得るのではなく，チームから最高のものを得ることを目標にしているのです。
Unrulyでは昨年1年間，3～6人のグループでモブプログラミングを定常的に行ってきました。通常のワークステーションに大きめのデスクとスペースを用意して，全員がその周りに座るか立つかします。50インチのディスプレイを使っていますので，全員がコードを見ることができます。ドライバ用にはサブモニタが用意されています。
Wilson/Weber: モブを通じて，私たちは一緒に学び，個々のエクスペリエンスを結び付けます。今回のAgile on the Beachのセッションで私たちは，Patrick Lencioni氏の著書 “Five Dysfunctions of a Team”を取り上げました。モブプログラミングは，すでに確認されている障害に対処するだけでなく，私たちが気付いていなかった潜在的問題を顕在化する(そうすれば対処も可能になります！)効果もあるのです。
モブプログラミングはチームの効率化に貢献します。全員がモブするすべての機能開発に関わるのですから，設計はよくなりますし，サポートもより効率的にできるようになります。ペアプログラミングに比べると中断による影響が少ないので，タスクもこれまでより早く完了できます。
InfoQ: モブプログラミングがアプローチとして実行可能であるとチームが判断する上での，(技術，プロセス，社会的などの)必要条件はあるのでしょうか？
Wilson/Weber: よく聞かれる質問です。“ペアをやりたくないと言われたらどうするのか”という，XPの実践者に寄せられる典型的な疑問と同じようなものなのでしょう。理屈で言うとモブプログラミングは，ペアプログラミングより易しいはずです。１対１というのは，特に新人にとってプレッシャに思えるかも知れませんから。
当社では，仕事について説明する時，まず最初にこの協力的なプラクティスのことを話しています。ですから，すでに入社の時点で，このような極めてコラボレーティブな作業環境に満足できる人を選択していることになります。モブプログラミングを試してみるように，すべての人たちを説得したいと思っているかも知れませんが，パーソナリティは人それぞれですから，誰もがみな社交的でなくてはならない，ということではないのです。
技術的なプラクティスに関しては，そうですね，開発プロセスのフィードバックループが遅いと，グループ開発を効果的に運用するのは難しくなると思います。テストスイートの実行に数分以上必要だったり，あるいはコンパイルに長くかかるようであれば，退屈になったグループのメンバは，スマホを見て半日過ごすことにもなりかねません。しかし，モブプログラミングは，技術的プラクティスの向上にも役立ちます。例えばモブでは，コードを全員で一緒に書くことから，コードの集団所有や継続的インテグレーションといったものも暗黙の内に含んでいます。
何よりも重要なのは，決められた作業方法を強いるのではなく，安全で寛容な，チームが自分自身で向上できるような環境を提供することです。Woodyがよく言っているように，“アートを作り出すことではなく，アートがなくてはならないような環境を作ることが目標”なのです。
このような環境が実現することで，すべてのチームメンバが何も恐れず，ためらわず，さらには自分たちの方向性に対して自ら発言することへの迷いもなく，モブに参加することができるようになります。私たちがモブプログラミングを試して，採用したときに感じた安心感はここにあります。それはまた，私たちが育もうと努力を続けてきた，Unrulyの文化の一面でもあるのです。
InfoQ: 今の話にあったWoody Zuill氏は，モブプログラミングの提唱者であり，“見積不要(no estimate)”運動でも知られています。あなた方は氏の影響を強く受けていますが，氏のこのような考え方は，よりよい作業方法を模索する上で役に立ちましたか？
Wilson/Weber: 私たちが最初に，通常の作業としてモブプログラミングを試してみようと思ったのは，Woody Zuill氏の講演がきっかけでした。導入を決定したのはその後です。それ以来，自分たちに合った方法をいろいろ試してみています。
実は先日，Woodyが私たちの所へ来て，実際にモブプログラミングセッションに参加してくれたのです。
見積を廃止するという話はまだ出ていません。一般的なプロジェクトチームというものが，Unrulyにはないのです。代わりに製品開発チームを編成して，さまざまな領域で，自分たちの製品に加えることができる新たな価値を探すということをしています。これらの領域で，次に実施する開発作業のコストを理解しておくという行為は，私たちにとって非常に有益です。成果にならないようなバックログ項目を，長くて退屈な会議を行って見積もるという，アンチパターンを回避したいのです。
InfoQ: Unrulyがモブプログラミングの導入に成功したことで，設計あるいは開発プロセスの今後の改善点としてはどのようなことを考えていますか，あるいはどのようなテクニックを試してみたいですか？
Wilson/Weber: コーンウォールに来るまでの４時間半の車中ずっと，その話題で盛り上がっていました。私としては，モブプログラミングの次のステップは“フラッシュモブ”(Agile on the Beachのセッションでもこの話をしました)なのではないかと思っています。コアチームの発想に縛られるのではなく，開発者がチームにも固執せず，最高の価値を生み出すことができるような，もっともっと柔軟な方法を試してみたいと思っています。この方法では，特定のタスクを達成したら解散するか，あるいは他のチームのペア/モブに自由に参加して学習/創造を行う，短時間の“フラッシュモブ”形式を採用します。自己組織型チームならぬ，自己形成型(self-forming)チーム，ですね。
このような環境を推進するためには，Open Spaceの基本原則(学ぶべき，あるいは貢献すべきものがそこになければ，それが可能な他の場所をさがすこと)が優れた基準になると思います。
ですが私たちにはまだ，製品の立ち上げから運用中の維持管理に至るまで，チームが製品ライフサイクル全体を把握するという私たち好みの開発アプローチと，この方法を完全に融合させるという課題が残っています。
InfoQ: お時間を頂き，ありがとうございました。その他，InfoQ読者に伝えたいことは何かありますか？
Wilson/Weber: ロンドン近郊に住居があって，最先端のXPプラクティスに関する議論や習得に興味をお持ちなら，私たちは毎月1回，Extreme Programmers Londonというミートアップを行って，プロセスよりも技術に観点をおいた話し合いをしています。ミートアップのページはこちらです – http://www.meetup.com/Extreme-Programmers-London/
Wilson, Weber両氏のビデオ‘Product development in an Unruly Mob’は，Agile on the BeachのYouTubeチャネルで見ることができる。