モバイルチームのモブプログラミング解剖 - Cybozu Inside Out

こんにちは、モバイルチームの向井田 (@mr_mkeeda) です。

サイボウズではあらゆる業務でモブプログラミング(通称モブプロ)が実施されていて、モバイルチームでも同様に毎日モブプロしています。この記事では、入社してから4年間、私が毎日やっているモブプロを紹介します。

この記事で知れることざっくりまとめ👇

モブプロ環境
モブプロ参加者の役割
モブプロの長所と短所
私のモブプロに対する感想

モブプロ環境

チーム内にリモートワークをしている人や複数の拠点にいる人などが混在しているため、モブプロは基本的にZoom通話で行われます。予めモブプロの時間とZoom会議室を決めておき、時間になったらZoom通話開始です。

1つのモブプロの参加人数は2〜4人です。 2人の場合はペアプロともいいます。私の体感だと4人以上は手持ち無沙汰になる人が出てきます。できれば3人までがおすすめです。

モブプロ参加者の役割

私が機能開発をするときにやっているモブプロは ドライバ と ナビゲータ という2種類の役割があります。

ドライバ

ドライバとはモブプロ中に実際に手を動かして作業する人を指します。ドライバは作業をモブプロの他の参加者に共有するために画面共有します。私の場合はAndroidアプリの開発をしているので、Android Studio、Androidエミュレータ、ターミナルなどのウィンドウを画面共有します。

ドライバは作業をできるだけモブプロ参加者に公開したほうがよいです。よくあるのが、画面共有外でブラウザを開いてWeb検索をするパターンです。見つけたWebサイトを見てドライバ以外の人が何か思いつくかもしれないですが、共有されていないとその可能性は潰えてしまいます。共有して問題のない作業はすべて画面共有に映してしまうのをおすすめします。

ナビゲータ

ナビゲータとは作業者であるドライバをサポートする役割です。サポートの内容は様々ありますが、いつもやっているのは以下です。

サポート1: ドライバへの指示

ナビゲータがドライバに対して明確にやってほしい作業がある場合は、それを指示します。例えば、「〜のクラス名は抽象的でわかりにくいので変更しよう」「〜のエラーをもっとよく見せて」などです。

ドライバがチームに入ったばかりの人の場合や、取り組む作業に詳しくない場合は、ナビゲータがしっかり指示を与えて作業を進めていきます。

️☝️ドライバの自主性

ドライバはナビゲータの指示に従うだけで自分自身で思考してはいけない、というわけではありません。むしろ、モバイルチームのモブプロはドライバ自身がガツガツ作業を進めて良いというルールです。ドライバの思考をモブプロに反映できたほうがより多様な視点で作業が進むため、メリットが大きいと考えています。

ドライバが自身の考えで作業をすすめる場合は、ナビゲータに思考の内容を共有してあげると良いです。どういう考えでコードを書いているのかがナビゲータに伝われば、ナビゲータはその考えを元に新たに発想でき、作業のクオリティが上がっていきます。

️☝Zoomのお絵かき機能

Zoomには画面共有上に線や矢印を書いて、画面上に注釈を付けるお絵かき機能があります。モブプロ中はこのお絵かき機能を多用しています。

使い所

コードの特定の箇所を指示したいとき
考えている設計を図で表したいとき

複雑な図を書くのは向いていませんが、カジュアルに図式化して口頭での説明を補足する分には十分便利です。モブプロ中のお絵かきについては、過去のブログでも紹介されています。

サポート2: 不明確な部分の調査

コードを書いていると上手く動かず行き詰まってしまうときがあります。行き詰まったときは、ドライバと共に原因を追求します。ドライバの画面を見て共にエラーを調べる場合もあれば、ドライバとナビゲータが別々の視点でそれぞれ調べる場合もあります。

利用しているメソッドが意図したものか確証を得たいとき、他の良い実装例がないか探すとき、など作業を止めずとも調査できる場合もあります。こういう場合はドライバには進められる作業をやっておいてもらい、作業の裏でナビゲータが調べます。調べて分かった内容は必ずその場でドライバに共有します。

サポート3: 実況スレにメモを残す

ナビゲータはモブプロの内容をメモする役割も担っています。タスクの内容、実装の意図、遭遇したエラー、試した実装案など、とにかく作業時のログを残します。メモは将来の実装者に向けてコード以外の付加情報を残すために書きます。モバイルチームでは弊社製品であるkintoneに開発スペースを作り、バックログごとにスレッドを立ててメモを残しています。このスレッドのことを実況スレと呼んでいます。

実況スレのメモは後から検索できてこそ価値があります。そのために以下の工夫をしています。

メモはタスクごとに整理する
タスク番号を発行する
上記の OMSBL-2452 というのがタスク番号です。
私たちはkintoneにタスクアプリを作ってタスク管理しています。
コミットメッセージにタスク番号を含めておく
コミットメッセージ例
OMSBL-2452: AGP7.0+ だと Hilt も 2.37+ にする必要があったので、Hilt を最新の2.39.1までアップデート

これらの工夫をしておくと、コードから実装時の実況スレを辿れるようになります。あるコードを書いたときの実況スレを見つける場合は、以下の手順を実行します。

Git Blameで各行のコミット履歴を表示する
Android Studio や IntelliJ だと行番号を右クリック → Annotated with Git Blame が便利です。
コミットメッセージに含まれているタスク番号を控えておく
kintone上をタスク番号で検索

実況スレのメモを残しておくと、実装当時にモブプロに参加していない人もある程度コードの意図を知ることができます。これは新メンバーだけでなく欠席した場合も当てはまります。また、モブプロに参加していても時間が経つと実装の経緯は忘れます。(私は1週間も経てば忘れる自信があります😇) メモはメモをした本人にとっても当時の実装経緯を思い出す情報になるため、とても役に立ちます。

役割の名称

Googleでモブプログラミングを検索すると、上記のナビゲータのサポート内容のうちいくつかは別の役割名で呼ばれている場合があります。例えば、Mob Programming Patternsではサポート2: 不明確な部分の調査を Researcher、サポート3: 実況スレにメモを残す を Recorder という名前で紹介しています。

モバイルチームのモブプロでは、ドライバ以外の人は特に区別せず、全てナビゲータと呼んでいます。特に私の場合はペアプロがほとんどなので、ナビゲータと呼ばれる1人がいろいろな役割を担っているのだと思います。

モブプロの長所と短所

個人的に思うモブプロの長所/短所を紹介します。

長所

参加者がお互い成長できる

1人作業だと作業から得る学びは作業した人のみに限定されますが、モブプロは1つの作業で複数人が学びを得られます。参加者が感じた学びを他の参加者へ共有することで、さらなる学びが得られる場合もあります。

学びの内容は、ベテランエンジニアの思考の仕方といった大きなものから、Android Studio の便利Tipsのような小さなものまで様々です。私はドライバが何気なく使っている便利なツールやショートカットを知れるのが地味に好きだったりします。

コンテキストが揃う

モブプロは同じ作業をみんなで共有して行うため、続けていると作業のコンテキストが徐々に揃っていきます。モブプロで開発をしている場合は、コードの書き方、実装背景、技術的な課題感などの開発上のコンテキストが参加者間で揃います。コンテキストが揃っていくと少ない会話でも意図が正しく伝わりやすくなるため、単純にコミュニケーションが楽ですし、設計のスピードも上がります。

短所

働く時間をあわせないといけない

サイボウズは働く時間と場所を社員一人ひとりが自由に決められます。この自由な働き方はとても良い文化なのですが、一緒に作業するモブプロとは相性が悪いです。

勤務場所の違いはZoom等のビデオ会議システムで解決できますが、勤務時間の違いはどうしようもありません。モブプロ参加者で稼働日、始業時間、ランチの時間、就業時間、ミーティングのタイミングなどを合わせる必要があるため、予定の共有が必須です。幸いサイボウズは自社製品のGaroonで全社員の予定を共有しているので、予定調整の負荷はそれほど高くありません。

自分のペースで思考しにくい

ドライバをやっているとナビゲータがいろいろ意見や指示を出してくるため、ドライバの思考を邪魔してしまう場合があります。この現象は、思考速度の違い、作業の熟練度合い、コンテキストの有無、参加者の性格など様々な要因によって引き起こされます。一人で考え抜きたいタイプの人にとっては、モブプロに苦手意識を持つ大きな要因になるかもしれません。

私は一人で考え抜きたい気持ちより、他者の考えを取り入れて作業を効率的に終わらせたいと思う気持ちを大切にしています。自分一人で悩んで作業と向き合うより、優秀なチームメンバーを頼ったほうが速く仕事が終わった経験をしているからです。