モブ(mob)プログラミングは、プロダクトをアジャイル手法で開発する上で、古い習慣を新しく効果的な習慣に変えるための有効な手段だ。周りを人に囲まれた環境において集団で培われた習慣は、簡単に忘れることはない。モブプログラミングは各メンバに対して、新たな習慣を定常的に実践させることによって、それらを取り入れやすくする。チームは同じ作業の繰り返しを容認しない。仕事を行うためのよりよい方法を常に探しているのだ。
Hunter Industriesでソフトウェア開発ディレクタを務めるChris Lucian氏はAgile 2021で、モブプログラミングと集団的習慣(collective habits)による技術品質の改善について講演した。
習慣の改善はモブプログラミングによる自然な成果だ、とLucian氏は説明する。
複数の人たちが同時に同じコンピュータで作業するというのは、ある種のアカウンタビリティグループを持つということです。そこには常にフィードバックループが存在します。必然的に悪い習慣は排除され、よい習慣が植え付けられるようになります。
新たなグループが集まってモブが始まれば、そこにはあらゆる種類の有益な提案がある。Lucian氏が例を挙げる。
IDEに不慣れな人がいて、コードを手作業でフォーマットし始めるかも知れません。その開発者がひとりで作業しているのであれば、自分でオートフォーマットコマンドを見つけるまで、その作業をずっと繰り返すことになるでしょう。しかしモブならば、手作業でフォーマットをする度に、誰かにオートフォーマットを教えられることになるはずです。
これは全員がIDEに不慣れであったとしても同じで、ひとりがナビゲートし、ひとりが操作している間、他の誰かが機能を調べてオートフォーマットを見つけ、それをチームに教える、ということが考えられる。
こうした例を見れば、チーム全体のシステムが自然と改善される様子を簡単に見て取れるはずだ、とLucian氏は説明する。経験や好みは人それぞれ違うので、それぞれの習慣のベストな組み合わせを見つけて、それを全員で共有すればよいのだ。
モブのもうひとつの大きな副産物として、Lucian氏は、チームが反復作業に不寛容になる点に言及した。
テンプレート、オートフォーマット、リンティング(linting)といったマイクロオートメーション、データベーススキーマに基づいたすべてのコード生成手法は、作業のやり方なのであって、仕事を離れた場所で学ぶ類のものではありません。
モブプログラミングと集団的習慣によるチームの改善について、Chris Lucian氏にインタビューした。
InfoQ: モブプログラミングを通じて、どのように集団的習慣を作り上げたのですか？
Chris Lucian: 私たちがモブを最初に始めた時点で、すぐに非効率な部分が見つかりました。それまで使用していたプロセスやツールやフレームワークについて抱えていた、小さな問題がすべて見つかったのです。それらはおのずと明らかになりました。
モブの実施中は、チームのメンバが"名前を変えた方がいい"、"このエッジケースのためのユニットテストを書こう"、というようなことを絶えず言います。しばらくすると、チームの全員が仲間のよい習慣を身に着け、悪い習慣を排除するようになるのです。
InfoQ: 個々の習慣を変えるには何が必要なのでしょう？
Lucian: 外部のサポートを受けずに個人的な習慣を変えるための一番よいと思う方法は、使っているシステムにリマインダを設けることです。私はTrelloに個人的なかんばんを用意しています。"Real Habits Daily"というアプリを使って、自分が定期的に戻る場所に付箋を貼っておきます。そのメモを見て行動を起こすのです。最終的にこれがオートマチックになれば、リマインダもノートも不要になります。
この方法の一番大きな問題は、自分の習慣に対するフィードバックのないことです。習慣を変える必要性に気付くまでに、何か月もかかるかも知れません。どの習慣が改善できるかを周りの人に聞くこともありますが、状況を理解できていないことが少なくないのです。
InfoQ: プロダクトのバグを削減する上で役立った習慣について、いくつか例を挙げて頂けますか？それらの習慣にはどうやって気付いたのでしょうか？
Lucian: これから説明する習慣は、過去10年間にわたる繰り返しの結果、私たちのシステムに組み込まれたものです。
2011年にレトロスペクティブの実施と学習セッションを始めたのですが、作業は個人単位で、リリース間隔も1年半に1回程度でした。
モブを始めてから、先ほど説明したマイクロオートメーションを行うようになりました。そこで素晴らしいことが起きたのです。それまで業務外でユニットテストを学んでいましたが、あるモブで初めて、プロダクションコードでのユニットテストを試してみました。それ以来、ユニットテストを書くことが習慣になりました。誰かがその時のことを覚えているからで、しかもそれは毎回違う人なのです。
2012年には完全なユニットテストに移行して、手作業によるレグレッションを行うことで、サイクルタイムを2週間まで短縮することができました。私たちのユニットテストはその後さらに拡大して、同じ年内に毎日リリースが可能なまでになりました。
2014年にはスモークテストを自動化することで、半日単位でリリースできるようになりました。
2015年にはチームの規模拡大に着手しました。その後、段階的にテストピラミッドに移行して、7人程度のモブから1日14回以上のプロダクションリリースが可能になっています。
その間には、インフラストラクチャ・アズ・コード、継続的インテグレーション、継続的デリバリ、データベースの継続的デリバリ、パターンへのリファクタリング、クリーンコードといったことにも取り組みました。これらは学習セッションを通じて導入され、レトロスペクティブによってプロセス内で維持されてきました。
モブは、それが本当の習慣になるまで、忘れないようにしてくれる上で有効でした。これらのことをするためのリマインダは、今では誰も必要としていません。
InfoQ: 習慣を変えたことで、どのような影響がありましたか？メリットは何だったのでしょう？
Lucian: サイクルタイムが年単位から時間単位に短縮されたこと、習慣をデザインするためのチームの許容度が大幅に向上したこと、チームの幸福度が劇的に上昇したこと、などです。
現状に捉われて、イテレーションの速度が落ちることはよくありますが、グループが付いていてくれれば、そんなことはありません。相談相手がいつもそばにいるので、改善を目指す意識を失うことがないのです。
InfoQ: どのようなことを学びましたか？
Lucian: 私がチームに関連する習慣やモブのダイナミクスについて考え始めたのは、"Power of Habit"と"Atomic Habits"を読んでからです。どちらの書籍も、私たちの習慣がなぜこれほど急速に変化するのか、その理由を理解する上で役立ったと思います。
"Checklist Manifest"も良書だと思います。チームがマイクロレベルで忘れていたことをどうやって乗り越えるのか、その気付きを与えてくれます。習慣は必要な時に自然に形作られます。そして、そのフローを実現可能にするのがモブなのです。
そのための学習時間とレトロスペクティブとを組み合わせた"Virtuous Loop(好循環)"さえ生み出せれば、どのチームでもこのような結果を得ることができると思います。学習セッションがシステムに新たなアイデアを組み込むことを可能にして、レトロスペクティブが変化や実験を引き起こすのです。Virtuous Loopは改善と学習のサイクルなのです！