モブプログラミング - Woody Zuill氏とのインタビュー

ソフトウェア業界におけるクレイジーなアイデアの歴史の中で、XP（ペアプログラミングとテスト駆動開発を用いる）が初めて登場したときの影響は、かなり大きなものだった。モブプログラミング（Mob Programming）は、それをもう一歩進めたように見える。モブプログラミングとは、チーム全員が同じ時に、同じ場所で、同じコンピュータ上で仕事をするソフトウェア開発手法だ。

2016年5月1日と2日にマサチューセッツ州ケンブリッジで開催された最初のMob Programming Conferenceで、Woody Zuill氏がモブプログラミングについてのキーノートを行った。そこで彼は、モビングをやってきた4年間に、誰もが尋ねる質問について語った。InfoQではQ&Aと記事で紹介する。

本記事は、キーノートのふりかえりと、モブプログラミングの導入方法、IT業界における主な問題、モビングに合った他の活動、モビングの目的に関するZuill氏とのインタビューとの2部構成だ。

キーノート: モブプログラミングとは?

XPの歴史、そして幹部レベルのシニア（非IT）マネージャーに技術的プラクティスを説明する難しさを考えると、「5人のチームが1つのコンピュータで仕事をするのはどれだけ生産的なのか？」という疑問がわくのは当然だろう。これに対して、Woody Zuill氏は2つ回答した。

1. 仕事を複数人に分けるのは効率的である、という根拠はどこにあるのか？ これはRobert C. Martin氏によるITの歴史のレビューや、Peter Drucker氏の「ナレッジワーカー」に関する研究に非常に近い。知識労働の評価に工場の基準を使うのには、説明はあれど証明に基づく根拠はない（私の知る限り）。
2. 目標は、生産的であることではなく、効果的であることだ。リーンプラクティスに反し、生産的であって効果的でないことは、すぐに無駄を生み出すのに良い方法だ。

ソフトウェア開発中にチームが直面する主な問題は、モビングすることで消えていく。

• コミュニケーションの問題がなくなる。チーム全員が同じ場所にいて、必然的にむき出しになるためだ。
• 質問のための（質問に答えるための）待ち時間。問題は生産性ではなく、回答を得ることだ。この場合、バックログに新しい項目を追加するのは無駄でしかない。一日中一緒に仕事をすることで、問題は消えていく。
• 技術的負債。これはソフトウェア開発で最も形のないものだろう。ITでは、チームが製品にゴミを持ち込むと、そのままにされるものだ。モビングにより、品質は継続的に高まる。

2012年頃、Hunterでの彼のチームは、新しいプラクティスを試していた。Twitterで少し議論したあと、彼はカンファレンスでやっていることを説明し始めたという。プレゼンテーションのたびに同じ質問が出るので、彼はPeter Block氏の次の言葉を心に留めながら、質問に答えるスライドを書くことにした。

「他人の経験の価値は、希望を与えることだ。どう進むべきか、進むべきかどうかを教えることではない」

彼は巧妙な質問をした。「なぜチームはこんなやり方で仕事をするのか？」。聴衆の答えは様々だったが、彼の答えは違っていた。チームがモブで仕事をする唯一の理由は、チームがそうすると決めたからだ。

おそらくこれは、モビングがアジャイルマインドセットと非常に一致するところだ。Alex Krivitsky氏が2011年に書き換えた（「Individuals and Interactions」のところ）のと同じように、（アジャイル）マニフェストよりもアジャイルだろう。それを得るため、モブプログラミング「マニフェスト」（そう呼んでいる人がいるかわからないが）は次のことに従う。

同じことを、同じ時に、同じ場所で、同じコンピュータ上で仕事をする優秀な人たち

最初のマニフェストとは2つの大きな違いがある。

• 第一に、行動を一致させることで、モブは集中し連携する。モブの間は、同時に一つのことを一緒にやることにコミットし、仕事を個人に分割しない。これはほとんど、XPがそう見えるはずだったものだ。これは共同所有を保証する。
• 第二に、この連携のおかげで、チームが同じ場所にいるか分散しているかに疑問の余地はない。全員が一緒に仕事をする必要があるという点において、そのことには意味がない。また、バーチャルに仕事をするための効果的なツールが登場したことも助けになっている（joinMe、HangOutなど）。そういう仕事のやり方で知られているチームもある（Cucumberチーム、Corgibytesなど）。

このパターンを実現し強固にするために、彼は強いペアプログラミングの導入について説明した。Llewellyn Falco氏は次のように定義している。

アイデアをあなたの脳からコンピュータへ移すために、あなたは他人の手を使わなくてはなりません。

モブプログラミングについて、Woody氏は非常に控えめだ。彼が一緒に仕事をしてきたチームは、いくつかのプラクティスを試してきただけだ。役に立つと思ったプラクティスをどんどん使っただけだ。コードの臭いに気づいて、チームに技術的スキルを高めるよう頼んだだけだ。彼は次のように語っている。

その仕事をしている人が、一番うまく仕事のやり方を決められるのです。

モブチームの典型的な1日は、1時間の学習セッションから始まる。スタンドアップでやる必要はない。そのあと、チームは1日8時間未満で、プロダクトに取り組む。少しすると、プロダクトオーナーはフルタイムに近い形でチームの一員になった。ここでは次のような原則が適用された。

• 良さを高める: これはKent Beck氏が『XP Explained』で説明したものだ。うまくいっているように見えることがあれば、それをもっとやろう。
• ふりかえり: 成果の改善がもっとうまくできるよう、少なくとも1日1回、チームは自分たちのプラクティスを見直し、調整し、良さを高める。
• 毎週の訓練: コーディングスキルを改善するため、訓練することを必須にする。

Robert Henri氏は要点をこうまとめている。

目的は芸術作品を作ることではなく、芸術作品を当たり前にするような素晴らしい状態になることです。

結論として、モブプログラミングは学ぶ姿勢のためだ。 * 共有したいこと * 初心者のアイデアに注意を払おう

彼はモブプログラミングを「やるべきこと」として推進していない。むしろ、もっとこまめなふりかえりとチームの基本的なケアを促している。ここで説明したプラクティスと同じくらい重要なことは、モビングは意図的にチームによって異なるということだろう。

モビングの間、モブにいる全員がむき出しにされる。つまり、うまくやるためには心理的安全を保証する必要がある。これはRichard Kasperowski氏が2日前に紹介したコアプロトコル（Core Protocols）に関する説明に非常に近い。おそらくこれは、コアプロトコルを使ってアジャイルオープンスペースとモブプログラミングがモダンアジャイルを定義しているためだ。

Woody Zuill氏とのインタビュー

InfoQ: インタビューを受けて頂き、ありがとうございます。キーノートのあと、IT業界は壊れていると説明していましたが、それについて、あなたの考えを教えてもらえますか？

業界が壊れているとまでは言っていないと思うのですが、私たちが従ってきたプラクティスの多くは、単なるしきたりにすぎません。Grace Hopper准将はよく言っていたそうです。「人間は変化に対して過敏だ。「いつもこうやってきた」というのが好きなんだ。私はそれと戦おうとしている」。「それがいつものやり方だから」というだけでやっているときには、改善の機会だと思っています。

InfoQ: その観点から見て、ビジネス状況を改善するためには、何をすればよいと思いますか？

うまくいっていることに注意を払い、その良さを伸ばす方法を見つけられないか実験すること、それがとても役立ちます。例えば「モブプログラミング」を見つける前のことですが、一部の開発者がてこずっている仕事について調べようと、集まってミーティングをしたことがありました。問題部分をいくつか調べた後、そのミーティングで一緒に取り組み始めました。何かアイデアを提案して、自席に戻ってコードに取り組むのではありません。私たちはコードにある問題を特定し、チームとして修正するよう、全員一緒に仕事をやり始めたのです。これが非常に効果的であることに、私たちは気づきました。そして、協力することで「良さを高める」ことができるか確かめる実験として、そのやり方を数日間続けることにしました。これは見事にうまくいきました。このことが、日々チームとして「モブプログラミング」することにつながりました。

InfoQ: モビングの第一人者として、モブプログラミングのアイデアをどうやって会社に取り入れていますか？

モブプログラミングには多くのメリットがあると自負していますが、私が目の当たりにし経験してきたメリットが、万人に当てはまるとは思っていません。でもチームにモブプログラミングを紹介するよう依頼されたときには、ワークショップを開いて、ソフトウェア開発の性質、チームとして仕事をするメリット、アイデアを共有して対立をうまく処理するテクニックについて探るようにしています。

InfoQ: 読者がモブプログラミングに納得したとして、モビングを徹底的に導入するにあたり、何かアドバイスはありますか？

少しずつ前進しましょう。モブプログラミングの実験をすることに関心があるなら、手始めに単純なコード練習や型で一緒に仕事をしてみると良いでしょう。プロダクションコードに取り組むというプレッシャーなしに、一緒に仕事をする練習ができ、どうすれば上手に有意義なやりとりができるのか学べます。つまり、モブプログラミングとは、うまく一緒に仕事をするために学ぶということなのです。

InfoQ: 見方を変えて、スクラムのように、コーディング以外にもモブプログラミングは使えると思いますか？

アジャイルやエクストリームプログラミングと同様、モブプログラミングはソフトウェア開発のためのものですが、同様のコンセプトは他のタイプの仕事にも役立ちます。デザイン、マーケティング、ハードウェア設計、ドキュメントなど、ほとんど何にでも使えるでしょう。一緒にうまく仕事をするということは、様々な分野でメリットがあります。

InfoQ: ファシリテーターのためのワークショップで、あなたはこう言っていました。「それはモブプログラミングのためではない」。モブがモブのためでないのなら、モブは何のためですか？

あなたがやっている仕事、一緒に仕事をしている人たちというコンテキストにおいて、重要な原則やプラクティスを見つけるためです。モブプログラミング自体は、仕事のやり方を決められるようになることの副産物にすぎません。モブプログラミングというのは、こまめで定期的なふりかえり、うまく仕事をすることへの意識、良さを高めることから、どのように良い成果が得られるか、実践している環境で起こったことです。うまくやることができれば、どんなコンテキストであっても、適切なプラクティスの組み合わせが見つかるでしょう。

InfoQ: モブプログラミングをもっと深く理解したい人に、何かおすすめはありますか？

Youtubeに3分動画があります。面白いのでここから始めると良いでしょう。1日8時間「モブプログラミング」をしている私たちのオリジナルチームをお見せします。

また、Kevin Meadows氏と私は本を書いており、手に入れることができます。

カンファレンスで行われたトークビデオやポッドキャストも多数あります。私はモブプログラミングに関するフリーのオンラインセミナーをよくやっています。また、いつでもビデオカンファレンスで質問に答えますよ。