モブプログラミングを1年以上継続するコツ

こんにちは、メディアプロダクト開発部のマーケティングサービス開発グループ(通称msdev)の id:asonas です。msdevウィーク最後の記事です。チームメンバーの記事も是非読んでみてください。

マーケティングサービス開発グループでは毎週月曜日13時から17時の決まった時間にモブプログラミングを実践しています。 このモブプログラミングの枠は1年以上継続していて、毎週様々な課題の解決や機能の開発をしています。この記事ではモブプログラミングを長く継続するためのコツをお伝えします。

モブプログラミングとは

まず、モブプログラミングとは、チームメンバーが同時にコーディングを行う手法です。重要な点はこの「チームメンバー」にはソフトウェアエンジニアだけではなく、プロダクトオーナーやデザイナーのような方々も含まれていることです。スクラムガイド(2020)の開発者と同じように考えてもらうと自然かもしれません。

モブプログラミングにはいくつかのメリットがあります。第一にチーム全員が共通の目標に向かって協力するためコミュニケーションの質が向上します。また、プロダクトに深く関わることで、知識の共有が促進され、チーム全体でより高い品質のコードを書くことができます。

さらに、モブプログラミングは開発プロセスを迅速化できます。複数の開発者が同時に機能を実装することで、エラーやミスがすばやく発見され、修正できます。これにより、開発プロセスがスムーズに進み、品質の高いコードをより迅速に提供できます。また、機能の実装途中に意見の分かれるポイントが出てきたときには、プロダクトオーナーやディレクター、デザイナーの方々の意見も取り入れることで"戻し"の作業を省くことができます。

モブプログラミングはチーム全体の知識や技術レベルを向上させることができます。開発者が一緒に開発をすることで、新しいアイデアやテクニックを学び、開発者自身のスキルを向上させることができます。これによりチーム全体の技術力が向上しより高度なプロジェクトに取り組むことで、いわゆる暗黙知から形式知、形式知から暗黙知へのループがモブプログラミングを通して回せます。

このようなモブプログラミングを2021年12月から16ヶ月以上実践しています。また、私たちのモブプログラミングは社員だけではなく、株式会社えにしテックさんの darashi さんと cafedomancer さんを招聘して毎週実践しています。

1年以上開催するうえでどのようなコツが必要でしょうか?

darashiさんとcafedomancerさんは遠方からZoomを使ってモブプログラミングに参加してくださっています。よくある定義として「ペアプログラミング・モブプログラミングはひとつのコンピューターでやる」とありますが、昨今の開発体験の進化により、Zoomによる画面共有や VSCode の Live Share などのツールの発展により遠隔地にいてもモブプログラミングは充分に満足できる形で開催できます。一昔前だと開発者全員でひとつの開発サーバーにsshで入ってscreenやtmuxのようなターミナルマルチプレクサのセッションを共有してコードを書いていましたね(なつかしい。10年以上前の話ですが)

定期的にモブプログラミングを実践するいくつかの良い方法を紹介します。 ひとつは毎週決まった曜日と時間に開催することです。

私たちのやっているモブプログラミングは毎週月曜の13時から17時に固定して実施しています(年末年始の休暇、祝日などが無い限りは基本的に開催です)。

これは私たちがスクラムを実践している点も関係しており、スクラムガイド(2020)には、

スクラムイベント スプリントは他のすべてのイベントの⼊れ物である。(略) スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されて いない会議の必要性を最⼩限に抑えるために⽤いられる

とあります。私の中ではモブプログラミングもスクラムのイベントのひとつ*1 として取り組んだほうがお得だと思っていることです。

また、モブプログラミングは13時から17時の間で実施されるのでその朝会で取り組むことを決めています。モブプログラミングで取り組みたいことは日々のスクラムイベントから適宜Issueに起票されてラベルで管理されています。

ふたつ目は毎週のログを取ることです。

開催時に必ず全員で見るGoogleドキュメントがあります。僕たちのチームでは「モブプロメモ」と呼ばれています。

モブプロメモの様子

朝会で取り組むことが決まれば事前にこのモブプロメモへ書いておきます。13時になりZoomへ人々が集まり、モブプログラミングで取り組みたいことをオーナーがメンバーに説明をして開始となります。 基本的には、このメモには会話した内容のメモやコードを書きながら発生した議論をまとめたりしてあとから読み直せるようにしています(全文をメモするようなことはしません)。 モブプロは毎週開催しておりその成果物はPull Requestになりますが、休暇などで参加できない方に向けてもこのメモは役に立ちます。

モブプログラミングの座組

誰から取り組むか、という点については毎週の参加者でランダムに順番をきめています。

その日の参加者の名前を書きつつshuffleするスニペット

持ち込んだ課題のオーナーからはじめても良いのかもしれませんが、私たちは特に気にすることなく、ランダムに順番を決めています。明確な理由付けはないですが、施策や課題の知識の偏りがチーム内にあります。この偏りをうまく利用する形で施策の目的や達成したいことはモブプログラミングを通して共有できるようになっています。

そこで私が大切にしていることのひとつとして、自分がドライバーの時は頭の中で思っていることをすべてしゃべるようにしています。「このコードの意図は何だろう」「なるほど、ブランドごとにトピックスの最新の1件を取ってきて、その順序でブランドの一覧を掲出しているのか」「フロントエンドのテストで行数を指定して実行方法はどうやるんだっけ」「ここのコードの修正はvimでやるほうが得意なのでvimに切替えますね」というようなことをしゃべるようにしています。これはドライバーが思っていることをすべて言うことでモブの方々がドライバーの思考を理解しやすくするためです。逐一しゃべりながらやるので少し大変なのですが、ライブコーディングのような感覚でやると楽しめます。エディタやツールのテクニックも実況しながらやると「それなに?」のような会話も発生します。時には取り組む課題とは関係のない話題についても触れて開発体験の共有をするのもよいなと実感しています。

ペアプログラミングでもそうですが、どんどん交代しながら課題を解決していくので、25分+5分休憩を1セットとして回していきます。2時間ほど経過するタイミングで休憩の時間を15分取っています。

5,6人で回していくとなんだかんだで3時間30分ほど経過するので、最後の30分の枠でふりかえりをします。 ふりかえりではよかったこと、取り組んだ課題の難しかったところ、白熱した議論についてなど様々なことが書かれています。

ある日の振り返りの様子。この日は業務分析をしたりReactのテストに苦戦する様子が描かれてる

私たちが実践するモブプログラミングのまとめ

カタはだいたいこのような流れです。ただ、このカタにハマらずブレることもままあります。前週に性能改善系の課題をこなしたときには冒頭で性能改善の様子をメトリクスを眺めたりもしますし、新しい参加者がいれば自己紹介をしたりしますし、Ruby/Rails、ReactなどだけではなくSQLを眺めてみんなでウンウン唸りながら改善をすることもありますしコードをほぼ書かずに業務分析をすることもあります。 おすすめのツールや設定、スニペットがあれば自慢してみたり、最近の技術的な話題で盛り上がることもあります。

モブプログラミングはとてもハードなプラクティスです。一日4時間もやるととてもヘトヘトになります。それでもチームのモチベーションを維持のためにも緩急をつけて、たまには雑談を挟むことで機械的な開催になることを避けるように心がけています。仕事として楽しめるような雰囲気作りもとても重要です。

モブプログラミングを実践するうえで、特にはじめて参加されるチームメンバーの場合はアプリケーションに精通していないこともあります。暗黙知が備わっていない、わからないことは当然あります。ドライバーになる人であれば分からない旨を伝えることも大事ですし、モブの方々も率先して自分たちが持つ知見を展開する心意気も重要です。ここのサイクルを回していくことでチームの生産性が向上しより早くユーザーに価値を届けることができます。

ただ、ここまで書いた内容は、一朝一夕でなしえたものではありません。毎週のふりかえり以外にもチームのモブプログラミングの意義を問うようなふりかえりも別途実施しました。チームメンバー各位がモブプログラミングに対する認識を揃えるなどを経て今のモブプログラミングのカタが完成しています。

モブプログラミングを継続してやっていくうえでメンバーの練度の差も次第に揃ってきます。特に導入時などはバタバタとしてしまうこともありました。それでも毎週のふりかえりの積み重ねでよりよい体験へと持っていくことができます。

モブプログラミングを長く続けることで対外的な登壇もしたりしました。前日の pndcatさんがKaigi on Railsで登壇するきっかけになったプロポーザルも実はモブプログラミングで取り組んだ成果でした。

kaigionrails.org

今は違うチームに異動してしまったのですが osyoyuさんもモブプログラミングで取り組んだことが採択されました。

kaigionrails.org

今回の記事では私たちのチームでうまく、そして継続的にモブプログラミングを実践する方法を紹介しました。定期的に開催しつつも、義務的にはならずソフトウェアエンジニアとして楽しく取り組めるような雰囲気作りを紹介しました。 もし私たちの取り組みに興味がありましたら、以下のリンク、またはTwitterなどでDMを頂ければカジュアルな面談からでも実施できればと思います。

cookpad.careers

*1:正確にはモブプログラミングはスクラムイベントの枠組みではありませんし、スクラムガイドには定義されていません。どちらかというともっと大きな枠組みの文脈で語られることが多いです。が、そこはスクラムやモブプロもXPのかけらということで解釈してもいいよなと考えています。