チームで2人の開発者が、3日間、ひとつの仕事に掛り切りになっていたら、あなたならどうするだろう？ある保険業のスタートアップが、チーム全体でモブプログラミングを試す決定をした。その結果、モブを始めた初日から、コードベースに対する知識が向上しただけでなく、一緒に作業することによって、お互いをよりよく知ることができたため、チームとしての効率も高くなった。
Johan Rouve、Alexandre Victoor両氏は、自らのモブプログラミングの体験をFlowCon France 2019で公開した。
氏らのチームはすでにペアプログラミングやランチを共にするなどしていたため、モブプログラミングを始めるのは難しくなかった、とVictoor氏は説明している。
ご存じのとおり、フランスでは、ランチタイムは非常に大切なものです。ランチに1時間、2時間を費やすことも珍しくありません。私たちはこの時間を、TDDの練習や、コード型(kata)によるリファクタリングなどによく利用していました。ですからモブを始めた時すでに、各グループはお互いに顔見知りだったのです。
一番難しかったのはモブデバッグだった、とRouve氏は言う。
予期しない動作を最初に調査しなければならなかった時は、本当に大変でした。皆がそれぞれ、自分のやりやすい方法を試すので、ナビゲータが交代する度にバグを追いかける方法が変わってくるのです。チームとして前進するために、自身のエゴは控えて、他のメンバの意見や、自身の考えとは相容れない考えを取り入れることも時には必要です。
モブプログラミングはチームに多大な影響をもたらした。常に一緒にいることは、技術的な判断を行う上で大きなメリットがある、とVictoor氏は言う。複雑な問題や難しいリファクタリングに取り組む上で、多くの勇気も与えてくれた。
Rouve氏の挙げるモブプログラミングの最大のメリットは、継続的な共有と学びにある — さらに、チームがベストプラクティスやコード標準を遵守する上でも、モブプログラミングには大きな効果がある。"より効率的にコミュニケーションすることで、作業は日に日に改善しています"、と氏は言う。
InfoQは、happnのフルスタック開発者であるJohan Rouve氏と、Comet MeetingでCTOを務めるAlexandre Victor氏にインタビューして、保険業のスタートアップであるFluoでのモブプログラミングの経験について話を聞いた。
InfoQ: Fluoでモブプログラミングに挑戦しようと思った理由は何ですか？
Alexandre Victor: そうですね、簡単に説明すると、私たちは当時、小さなスタートアップで働いていたのですが、コードベースには技術的負債を抱えていて、ビジネス上の期限に間に合いそうにありませんでした。状況を改善するためにペアプログラミングを試したところ、大きな効果があったのですが、それでも十分ではありませんでした。
ある日、スタンドアップミーティングで、チーム内の2人の開発者がとても動揺していました。3日間のハードワークの末に、自分たちの作業が滞っていることを認めなければならなかったからです。簡単な作業に思われたのですが、3日間懸命に作業したにも関わらず、その日の終わりまでに終了できるかどうか確証が持てていませんでした。ペアを替えるということは不可能だったので、多くの時間と労力を費やした結果としてギブアップする以外、彼らには方法がなかったのです。ビジネスパートナが作業の完了を待っていたので、彼らを支援して、可能な限り早くデリバリする方法を見つける必要がありました。
それで、スタートアップが終わった後、チーム全員が残って席に付いて、コードを読み始めたのです。その結果、昼までにソリューションの明確なアイデアが見つかって、タスクを完了することができました。
そこで、次のタスクもモブすることにしたのです。実際にその日以来、モブが途絶えたことはありません。
InfoQ: どのような課題があって、それにどのように対処したのでしょうか？
Victoor: すべての質問に答えられる知識が揃っていないと、モブセッションは難しくなります。
レガシコードを扱わなければならず、システムの動作を知っているメンバがいないような場合でも、モブプログラミングには優れた効果がありますが、マジックではありません。また、フラストレーションを感じるメンバのいないように、全員の意見が聞かれるようにするためには、進行役(facilitator)が必要になります。
InfoQ: 生産性の面では、どのような影響がありましたか？コードの品質面ではどうでしょう？
Johan Rouve: 急にモブプログラミングを始めたので、正確な測定はしていません。具体的な統計値というものはありませんね。ただ、全員が認めている興味深い事実として、ビジネス上の期限に遅れることはなくなりました。
コードの品質は向上しています。モブプログラミングによって、メンバ全員が作る最善のものだけが採用されるようになったので、できの悪いコードや、バグの紛れ込むリスクは非常に低くなりました。
Vircoor: モブプログラミングは、コードの単純化と共有意識を高める上で有用だろうと思います。
モブセッションでは、あらゆるアイデアが議論されるのですが、これは本当に素晴らしい問題解決方法です。ひとりで問題を解決しようとする場合には、その人のバイアスがあります。経験豊富な開発者であれば、過去の同じような問題で採用したソリューションを思い浮かべるかも知れませんが、このソリューションが最もシンプルであるとは限りませんし、現在の問題に対して最も効果的であるという保証もありません。
モブでは全員が発言して、アイデアと問題点を共有するのですが、これは最もシンプルな設計をする上で最善の方法であり、成果を全員が分かち合うことができます。
InfoQ: どのようなことを学びましたか？
Victoor: たくさんのキーボードショートカットといくつかのCSSですね ;)
チームメートのことばにもっと耳を傾けることを学んだと思います。他の人たちのまったく違った考え方や、同じ問題に適用可能なソリューションの数の多さに驚かされることは、今でも少なくありません。
Rouve: ショートカット、たくさん！"すごいな、どうやってやるんだい？"という会話を聞くのが、本当に好きなのです。
モブプログラミングは、同僚とよりよくコラボレートする方法や、複数の観点からソリューションを見つけ出す方法を教えてくれます。
InfoQ: モブプログラミングの導入を検討中のチームに、何かアドバイスはありますか？
Rouve: 協力を得やすく、モブによって肯定的な印象を与えられるようなタスクを選択することです。
フルタイムで実施する必要はありませんが、少なくとも一度は試してみてください。素晴らしい体験になると思います。
Victoor: 最初のアドバイスは、"あわてるな"ということです。チームに受け入れる土壌がなかったり、チームメートが望まない状況では、最初のモブセッションはスムースに進まないでしょう。
"乱取り(randori)"形式で始めるとよいと思います。乱取りの型(randori kata)は、部屋の全員が同じコンピュータ上で作業するコードエクセサイズです。これをやってみれば、モブセッションを実際に導入した場合にどうなるか、おおよその見当が付くと思います。
そして、全員がやる気になって導入の用意が整ったならば、チームにとって本当の"ピンポイント"で、知識の共有ができていないようなトピックを取り上げてモブを試してみてください。
いずれにしても、モブを強要しないことです。