TL;DR
- 私達のチームの1年以上のモブワークの体験記
- モブワークいいぞ
- フロー効率が上がる
- 知識が個人ではなくチームに蓄積される
- 新人の成長も早い
- 定期的な振り返りでモブワークを調整しよう
- モブワークでも大幅に人が入れ替わるときつい
はじめに
私達のチームでは1年以上モブワークをメインで開発してきました。
本記事は1年間モブワークを続けてみて非常に体験が良かったので、どういった点で良かったかを紹介します。
悪かったところも書こうとしたのですが、今のチームの状況では大きなものが見つかリませんでした。
また、１年でチームメンバーもかなり変わりました。
特に2月からは、私以外のチームメンバー全員が入れ替わりとなりました。
直近の対応、チームメンバーの変遷とその時々でのモブワークの様子を最後に書いてみます。
なお、私達のチームでは、モブ「プログラミング」だけでなく、稟議などの作業系もモブでやることがあるため、以降ではモブ「ワーク」と呼びます。
※モビング、モブワークいずれの言葉も、物騒な意味を表すこともあるそうです。日本ではモブワーク・モブプロという言い方が浸透しているのでこの場ではこういう表現にします。
モブワーク(プログラミング)とは
端的にいうと、
「3人以上で同じ場を共有しながら、1つの成果物を作るという作業のやり方」
のことです。
ペアプロに似ていて、それが3人以上になっただけではと思うかも知れません。
しかし、1年間続けて感じたのは、モブワーク内でのメンバーの動き方や、チームで得られるものがかなり異なるなという点です。
モブワークってなに？どうやればいいの？という方は、ぜひ成功する実践的モブプログラミングの記事を読んでみてください。
モブワークを始める際に十分な情報が載っています。
まずはチームメンバー全員、同じ時間を共有する形で読み合わせると良いでしょう。
私たちのチームの状況
以下の状況です
- サーバーレスWEBアプリケーションの新規開発
- 正式なユーザーはまだいない
- スクラム開発
- フルリモート(開発メンバーは関東圏、大阪それぞれいる)
- メンバー
- スクラムマスター 1人
- プロダクトオーナー 1人
- 開発メンバー 3人(※)
- ただし、開発メンバーは3 -> 2 -> 4 -> 3 -> 5 -> 3と人数が変わってきた。(詳細は チームメンバーの入れ替わりとモブワーク 参照)
モブワークの進め方
都度振り返りをしながら現在は以下に落ち着いています。
- モブとタイピストパターン
- タイピスト×１
- ナビゲーター×１
- その他：モブ
モブワークを1年続けてどうだった?
何が良かったの？
良かったところが結構たくさんあるので、雑多に列挙していきます。
フロー効率の最大化
もともとモブワークを始める目的が、このフロー効率の最大化でした。
モブワークはWIP制限の最右翼です。
アジャイル開発におけるWIP制限の重要性は、今この記事を読んでくださっている人であればご存知だと思います。
モブワークは作業しているその瞬間からレビューを受けているような状態です。
したがって、フィードバックが速攻で来るので、レビュー待ちの時間がほぼありません。
コードレビューのタイミングは、プルリクが作られてからなるべく早く行うことが良いとされているので、この効果は非常に大きいでしょう。
(参考：Speed of Code Reviews)
レビューや各種差し込みによるタスクの切り替えもほとんど発生しません。
タスク切り替え時のコストは馬鹿にならないので、1日を通してタスク切り替えがほとんど発生しない状況は生産性を大きく伸ばします。
ハマる時間が少ない
プログラムを書くにあたって、ハマる時間の多寡で実装スピードがかなり左右されます。
モブワークをすると、4つの理由でハマることが少なくなります。
1. 知識・観点がメンバー分だけ使える
人によって持っている知識は異なるため、そこにいるメンバーの知識の総和分、調べることなく前に進めます。
また、調べる際も、異なる視点から調べられるので、問題を短時間で解決できる可能性が上がります
2. 見逃しが減る
同じコードに対して複数人の目が入るので、そもそも見逃しが減ります。
1と若干被りますが、実装方法を考える時やコードを書く時も、
非常に早い段階から複数の観点でチェックが入るので、ハマりづらくなります。
3. ナビゲーターがタイピストに指示を出すタイミングで一度言葉にするので、そこで思考が整理される
自分がハマっている内容を口に出して説明すると、
説明しているうちに問題がすっと解決される経験をした人は多いと思います。
これは、話しているうちに思考が整理されるためです。
モブワークではナビゲーターが口にした実装内容をタイピストが打ち込むというプロセスで進むため、自然と思考が整理されます。
これがハマるのを未然に防いでいます。
4. ハマって視野が狭くなる前にリセットできる
モブワークでは時間を区切って役割を交代するので、ドはまりする前にストップがかかります。
一旦頭の切り替えができるので、ハマるっているうちにどんどん視野が狭くなる事象を回避できます。
知識の共有が常に行われる
モブワークをする中で、自然と知識の共有が行われます。
共有される知識は、ドメイン知識、開発ツール、アルゴリズム、デバッグ方法、社内手続きなど、多岐にわたります。
共有が行われる知識によってもたらされるメリットが異なる場合もあります。
ここでは、メリットベースでいくつか分けて挙げてみます。
1. 属人化されている範囲が非常に狭くなるため、この人がいないと価値が提供できないということが起きない
特定の人しか知らない(調べればわかるがチーム外への確認で時間がかかるなど)社内手続き的な部分や、ドメイン知識が共有されることで享受できるメリットです。
突発的な休みだったり、突然のチームからの離脱だったりと、メンバーが欠けても作業は止まりません。
体調不良で休んだときに、しんどいおもいをしながら引き継ぎをする必要もありません。
チームからメンバーが離脱しても、開発速度が極端に遅くなることもありません。
このように、ベロシティがかなり安定します。
スクラム開発では、ベロシティが安定して初めて享受できるメリットがたくさんあります。
というか、ベロシティが安定しないと健全なスクラムとはいえないと言ってもいいかもしれません。
モブプロをすることでベロシティが安定し、スクラムチームも安定します。
2. ドキュメントの管理コストが減る
属人化していると、「この人がいないと終わるor考古学が始まる」という状況に陥ります。
それを防ぐためにドキュメントを書きますが、これがなかなか厄介です。
そもそもドキュメント書くのに時間はかかりますし、ドキュメントは一瞬で陳腐化します。
陳腐化しないようにメンテするコストは馬鹿にできません。
今有効かわからない断片的に散らばったドキュメントと、実際のコードとにらめっこしながら、考古学をした経験は結構あるんじゃないでしょうか。
モブワークを続けていると、そういった知見はチーム全体に貯まります。
知識の濃淡はあれど、概ねメンバーが徐々に持つことになるので、必要なドキュメントの量が減ります。
もちろん、全く不要になるわけではありません。
コードに近い部分(コメント、JSdocなど)に残しておくとか、
時間が経過してもここは早々変わらないよねというドメイン知識やそれに紐づく仕様のまとめなど、
ある程度残しておいたほうが良いものもあります。
何をどこに書くかは、チームの置かれた状況によるので良い塩梅を見つける感じです。
新規メンバーが来たときにどうするんだとなりますが、上記の最低限のドキュメントに目を通してもらいつつ、モブワークの中で学んでいくことになります。
3. ジュニア(新メンバー)がシニアの問題解決の様子・コードを書く様子を直接見られるので成長が速くなる
リモートワークで特に活かされるメリットですね。
出社していたときは、シニアの元へ相談しにいくと、手元や画面が見える状態で色々教えてもらえました。
その時にショートカットやツール、デバッグのときの着眼点、手の動かし方など、色々と見えていました。
こういった部分は、リモートワーク＆個々人での開発だとなかなか見えない部分でもあります。
モブワークでは、手元はさすがに見ることはできませんが、それ以外の部分でシニアの手の動かし方、考え方が見られます。
ジュニアがナビゲーターをやっているときは、アドバイスをもらって改善する機会が頻繁にあります。
その結果、ジュニアの成長速度が速くなります。
ジュニアではなくとも、シニアの新メンバーで全く別の技術スタックから来た人の場合も、
今まで使うことのなかった知識が非常に早くキャッチアップできるので、新メンバーの定着にも有効です。
作業進捗の同期コストが下がる
スクラムのデイリーMTGが進捗の共有だけで終わってしまう、何なら進捗共有も終わらないということありませんか。
モブワークをやっていると、この進捗の共有はほとんど必要ありません。
プロダクトオーナーに看板見せつつ、スプリントゴールを達成できなさそうな要因を取り除く(大体開発メンバーの外にある問題。)ことに集中できます。
楽しみは人数倍、苦しみは人数割！！
1. 楽しみは人数倍!!
ハマっていた部分が解消された時、テストがすべて通ったとき、良いデモができた時、適度に分割されたタスクがテンポ良く消化されているとき、リファクタしてスッキリした時etc...
日々開発していて、やった！と思える小さなことはたくさんあります。
こういった楽しい経験をチームで分かち合えるという点でも私はモブワークが好きです。
2. 苦しみは人数割
ハマった時、スプリントゴールの達成が厳しそうな時、日々開発をしていると厳しい局面に合うことはしばしばあるでしょう。
こんなときも、一人で抱え込まない、相談するまでのコストがほぼない状況というのは、メンタルに良いです。
悪かったところは？
今のところモブワークが原因の悪かった点は見つかっていません。
やりづらさを感じたところは色々な場面でありましたが、
モブワークのやり方を都度見直すことで、やりやすくなっていっています。
見直した点については、後ほどモブワークをやりやすくするためにで書きます。
もしやりづらさを感じている部分があるのであれば、
モブワークそのものよりも、モブワークのやり方や、チーム自体に原因があるのでは？と考えると良いと思います。
(参考：リーダー＆マネージャーのためのモブプログラミング)
いやいや、強いて言えば？
強いて挙げるのであれば、チーム外の勉強会がなんとなく申し訳なくて参加し辛い(するときもある)というものがあります。
弊社では、業務時間に野良勉強会があちこちで開催されるので、この辺に参加し辛いなぁと思うことがあります。
プライベートの理由での中抜けとかなら結構気軽に抜けられます。
ただ、毎週勉強会がある場合は、その時間は必ず他のメンバーにすべてを任せることになるので、なんとなく申し訳なくなってしまいます。
もちろん、勉強会で得てきたことをチームに還元する時間を作れば良いし、
そもそも自己研鑽を業務時間で行うのは推奨されていて、勉強会に参加するのは良いことなので、
私個人の気持ちの問題ですね。
とは言え、新しく入ってきたメンバーでそういった時間が欲しいと考える人もいると思います。
その場合は、ここで書いたことを共有して気にせず行っておいでというのが良さそうです。
モブワークをやりやすくするために
過去にモブワークでやりづらさを感じたことがないかというと、全くそんな事はありません。
その場合はモブワークそのものが問題ではなく、モブワークのやり方の問題である場合がほとんどです。
この章では、私のチームで意識していたこと、やりづらさを感じたところへの対応を紹介します。
モブワークを始める前の認識合わせ
全員でモブワークを始める前に認識をあわせておくと良いでしょう。
私達のチームでは、メンバーが入れ替わるたびに以下を行っています。
- モブワークの目的・メリットの認識合わせ
- やりづらさを感じたら、モブワークのやり方は変えても良いということの共通理解
- 共通の資料の読み合わせ(成功する実践的モブプログラミングがおすすめ)
モブワークの定期的な振り返りをする
毎週スプリントレトロスペクティブ中や、別途時間が必要であればモブワークに特化した振り返りをしています。
モブワークでやりづらさを感じたこと、逆に良かったところなどを列挙して、
継続すること・止めること・新しくやることを決めます。
週１回だと忘れるので、毎日モブワークを始めるときにそれを眺めてから始めます。
モブワーク開始前にアイスブレイクの時間を設ける
モブワークではコミュニケーションが非常に重要です。
何しろ常に繋いでいる状態です。
コミュニケーションがぎこちないとモブワークの成果(開発物・メンバーの成長・チームに蓄積される知識。)に直接影響します。
したがって、特に新メンバーが来たときは、重点的に毎日朝の時間15~30分ほど雑談を設けるようにしました。
モブワーク以外の個人作業・自習の時間を作る
スクラムチームで行うほぼすべての作業をモブワークでやっていますが、
モブワーク以外の時間も作っています。
新メンバーにはモブワークをスムーズに進めるためにも、基本的な知識の自習が必須です。
また、一人で作業することで、モブワークで学んだことを復習できるため、知識の定着も早いです。
使っているツールやコードの書き方などはもちろんそうですが、
わからない部分の調べ方や、自分ひとりで成果物を作れるという時間も成長には不可欠だと思っています。
分担することでチームのリソース効率をあげるという目的ではなく、
モブワークによるメリットを最大限享受することを狙って、モブワーク以外の時間を確保しています。
手を動かす前にPBIにおけるタスクの洗い出し、分割、着手順を決めておく
これはそもそもバックログリファインメントでPBIをReadyの状態にしていれば自ずとそうなっていくのではとも思います。
設計もモブワークで行うので、手を動かす時間・設計やタスク整理の時間など、
その時々のモブでやる時間区別しておくとやりやすいです。
その上で、更に細かくタスクを分割してやる順番を決めておくと、
モブワークの切り替えが行われても、「次に何するんだっけ？」みたいに迷う時間が少なくなります。
TDDでのタスク一覧を作るイメージですね。
そのままTDDで開発するのもありです。
交代時に、次の交代までの短期ゴールを決める
モブワークにかぎらない話ですが、複数の細かなタスクに同時に手を出してしまい、結局何をやっているかわからなくなることがあります。
モブワークでは、今何をやっているかがモブ内で認識が合わないと、個人作業よりも顕著に進みが悪くなってしまいます。
そこで、役割交代の時間の区切りを利用します。
交代時間単位でタスクを切り出し、モブ内で共通認識を持って取り組むことで、
考えるべき対象に集中できるため非常に進みがスムーズになります。
誰がやっても同じ結果になる作業は分割する
モブワークをするメリットが享受できない、脳死でひたすら手を動かす系の作業は、
分担してそれぞれ個別で進めたほうが早いです。
例えば、テストデータ作成とか、打鍵とか、Renovateの対応とか。
こういうのは少し異なる繰り返し系の作業が多いので、
最初の１回だけモブでやり認識をあわせたら、後は分担して繋いだまま個別作業します。
1日の終わりに、翌営業日のタスクを確認する「夕会」をする
特にメンバーにレベル差があるときに有効です。
翌営業日、誰が休んでも作業が止まらないように、タスクベースで何やるのかの認識をあわせます。
「仮に明日自分ひとりになっても、タスクは進められるか」という質問で確認すると良いでしょう。
もし上記の質問にNOであるメンバーがいれば、そのメンバーが取り組めるレベルにタスクを更に分解したり、分からない部分を補足したりします。
今、そして今後の課題
サポートが始まったときのモブワークの運用
今のチームは実際に社内で触ってもらってみてFBをもらうという点はできているのですが、まだ運用のフェーズではありません。
したがって、日常業務として、ユーザーからの問い合わせが入ったときにどのようにモブワークを行うのかは未知数です。
社内評価制度との折り合いの付け方
弊社ではMBO＋360°多面評価で評価されます。
多面評価は問題ないのですが、MBOの扱いが若干難しいと感じています。
MBOは、組織の目標が降りてきて、それに対して個人が何を達成するのかを定めて、その結果を評価するという運用が想定されています。
したがって、チーム全員でタスクを消化するモブワークとは相性が悪いと感じています。
現状では、MBOの目標は以下を記載しています。
・個人ではなくチームとしての成果
・チームメンバーの成長への貢献
・個人の成長を組織への貢献に結びつける
上司がモブワークのことを理解し、チームとして成果が出ていればOKという共通認識があれば良いのですが、ここの認識にズレがあるとMBOを書くのは非常に難しくなりそうだと思っています。
チームメンバーの大半が入れ替わるときつい
モブワークをやっているとチームに知識が蓄積されるので、ある程度メンバーの入れ替わりに強いです。
とは言え、チームメンバーが一人を残して全員変わるみたいなことになるとさすがにきついです。
2月から私以外のチームメンバー全員が入れ替わりとなりました。
そうなると、私以外がナビゲーターになったとき全く進まなくなります。
モブワークの取り組み自体は非常に良いのですが、スプリントゴールが達成できないという状況にもなってしまいました。
そこで、以下のように対応し、現在はなんとか毎週の成果物を出せています。
- モブワークは継続
- ナビゲーターの比率を自分多めにする
- 技術キャッチアップの時間を設ける
- 開発メンバー以外に以下を説明し、合意
- 現状では自分ひとりでゴリゴリ開発を進めるより、モブワークをやるほうがベロシティは出ない
- モブワークのメリットを享受するための先行投資として、モブワーク継続
- 最低限のベロシティは死守
- 間に合わなそうであれば、自分だけで進める時間を作る
この対応が正解かはまだわかりません。
ただ、この先行投資がそろそろ回収できそうだなと感じています。
[おまけ]チームメンバーの入れ替わりとモブワーク
前述した開発メンバーの入れ替わりの推移と、その時のメモを雑多に書いています。
おまけで若干雑ですが、もし興味があればご覧ください。
「こんな時どうしてたの？」みたいに深堀りしてみたい点があれば、コメントいただければそれに回答します。
登場人物
入れ替わりがやや込み入っているので、以下のように記号を割り振り、
チーム参加時点での各メンバーの状況を説明します。
- 初期メンバー
- A : チーム立ち上げの前は同じような技術スタックで開発
- B : チーム立ち上げの前は同じような技術スタックで開発
- C : チーム立ち上げの前は全く異なる技術スタックで開発(★筆者)
- ヘルプメンバー
- D : チーム参加前は一部異なる技術スタックで開発
- E : チーム参加前は一部異なる技術スタックで開発
- 新規メンバー
- F : 全く異なる技術スタックのオンプレシステム開発。別チームと兼務
- G : 全く異なる技術スタックのオンプレシステム開発。
時系列とメンバー
2022年 1月
開発スタート！
チーム3人(A, B, C)
- モブワークで開発することを決定
- このときはタイピストがブツブツ言いながら手を動かし、モブがツッコミ入れる形式
- 3月頭くらいにモブとタイピストパターンに変更
- 定期的にモブワークの振り返りしつつ、6月くらいに自分達のチームにあった型が出来上がった
- 今振り返ると、最も開発スピードが早かったのは、3人で慣れてきた6月時点
2022年 7月
1人チームを離れる
チーム2人(B, C)
- ここから4ヶ月はペアプロに
- 属人化解消ワークをやるも、引き継ぐことはほぼなし
- 実装スピードはほぼ落ちなかった
- 上記はモブワークやっていたからこそ
- 片方が休むとWIPが増えてしまう
2022年 11月
さらに1人チームを離れることが決まったので、2人がヘルプ参加
チーム4人(B, C, D, E)
- 新メンバー受け入れ
- 個々人でやったほうが早いのではという意見もでたが、モブワークの背景説明をしたところ納得してもらった
- 実装スピードはかなり落ちた
- メンバー減少よりも、メンバー増加のほうが一時的にスピードが低下する
- 一部実装はヘルプメンバーに知見を提供してもらって、実装速度が上がった
- モブワークをやっているチーム同士、定期的にチーム間でメンバーの入れ替えをすると知見の共有がはかどる
2022年 12月
予定通り1人チームを離れる。
チーム3人(C, D, E)
- サービスの技術選定や、環境構築をし、周辺のドメイン知識に詳しい人がチームを離れる
- 実装スピードがガクッと落ちた
- 低速ながらスプリントでのインクリメントは積み上げることができていた
- Cが休んでも完全に開発が止まることはなかった
- チームに知識が蓄積されていることの恩恵をかなり受けた
- 心の底からモブプロやっていて良かったと感じた
- MVP開発が無事終了
- ユーザーに触ってもらう準備ができた
～現在(2023年 3月)
ヘルプメンバーが離れ、新メンバー2人が参加。
チーム3人(C, F, G)
- 今まで扱っていた技術が全く異なるメンバー参加
- Cが休んだ場合は開発がほぼ止まる
- 実装スピードが更に落ちた
- スプリントゴールが達成できなくなることも発生(現在は改善)
- 今までやっていたストーリーポイントが全く参考にならなくなった
- ヘルプメンバーが元のチームに戻った
- モブワークの体験が良かったみたいで、持ち帰ったチームでもモブワークをやっている様子
- 新人を受け入れつつモブワークを行うノウハウが溜まってきた
おわりに
この記事は1月末から書き始めたのですが、その間に「リーダー＆マネージャーのためのモブプログラミング」というスライドが公開されて、「もうこれに全部書いてあるし、こっちのほうめっちゃ読みやすいじゃん」ってなりました。
「まぁ、うちのチームではこんな感じというのが見せられれば誰かのためにはなるだろうから。」と気にせず公開することにしました。
さて、非常に長い文章になってしまいました。。。
ここまで読んでくださった方、お疲れ様でした。そして、本当にありがとうございます。
モブワークを取り入れて何が良かったのか感じられる文章になっていたら良いなと思います。
なるべく書ききったつもりですが、「こんなところどうだった？こんな時どうした？」みたいなご質問があれば、時間を見つけてお返事します。