チームにモブワークを取り入れてみた話

この記事は食べログアドベントカレンダー2023の16日目の記事です🎅🎄
食べログシステム本部の品質管理室のSET(Software Engineer in Test)チームで自動テストの仕事をしている@shibu_shibuです。
私はSETチームの「仲良しリーダー」という謎の役割を担っており、みんなで仲良く働くために日々頑張っています。(仲良し至上主義ではないので仲良くないこともいいことだと思ってます)
今回はSETチームが仲良く働けるようになったきっかけであるモブワークについてお話しします。

はじめに

エンジニアの皆さんは、オンボーディングの際や作業に詰まった時、問題解決が必要な時以外にも勉強のためにペアプログラミングやモブプログラミングをすることがあると思います。
同じようにSETチームでは、要件を固めたり方針を決めたりスケジュールをひいたり設計のために図を書いたりする際に、担当者一人だけではなくてチームのみんなでモブワークをして取り組んでいます。
初めからモブワークを取り入れていたわけではなく、模索をして今の形にたどり着きました。

はじめに
① 基本的な朝会夕会で状況共有だけしていた時期
② 当てずっぽうの奥義期
- 奥義MTGを取り入れた結果
- ここで登場したモブワーク
③ モブ全盛期
④ モブ全盛期を経て現在
最後に

① 基本的な朝会夕会で状況共有だけしていた時期

MTGが金曜に詰まっていた時期の時間割

SETチームでは今年の8月からモブワークを取り入れ始めました。
それまでも、チーム全員ではないまでもそれぞれの作業ユニットごとにTeams会議を繋いで画面共有をして相談し合いながら作業することがありました。
しかし、これだとユニット内の情報共有はうまくいくのですが、朝会や夕会、チーム全体が集まるMTGでチーム全体に作業内容や決まったことを報告してもいまいち他の人が何をしているか理解しきれていなかったり、認識合わせに時間がかかることが多々ありました。

朝会・夕会で日々の課題を共有する時間を十分に取れていなかった

朝会、夕会では各個人とユニットの状況共有をしていたのですが、30分の時間内に作業内容まで事細かに報告するには時間がかかりすぎるので、各々報告内容をまとめて報告して課題について深掘りする時間がない状態でした。
作業者以外に状況や課題の理解ができていないので、困った時などにすぐに気づいてヘルプに入れなかったり、チームとして他のユニットの作業を理解してサポートし合う体制がまだできていませんでした。

週に1度のチームデモに時間がかかりすぎていた

1週間取り組んだ内容について詳細に共有するのは週に1度の木曜日の「チームデモ」のタイミングのみなので、チーム全体が内容を理解するのにも時間がかかりました。
設定している時間は1時間半でしたが、上回ることもしばしばあり、上手く回っているとは言えない状態でした。

スプリント終了間際にフィードバックをもらい撃沈

上記の課題や状況を細かく共有できていないことが原因ですが、週に1度のチームデモの場所で、大きなフィードバックをもらうことが多々ありました。
週の始めや半ばにFBをもらったり方針を変えるタイミングや仕組みがなく、1週間を上手く使いこなせずに不完全燃焼で終わることがありました。
私たちは品質に関する仕事をする当事者なので、日頃からシフトレフト、シフトレフトと言っているのですが、それにもかかわらず、スプリントの最後にどでかいフィードバックをもらう仕組みを回していたのです。

その状況を打破しようとまずは「当てずっぽうの奥義MTG」をいうものを入れてみました。

② 当てずっぽうの奥義期

当てずっぽうの奥義期の時間割こちらは「アジャイルサムライ」の第7章のタイトル「当てずっぽうの奥義」から拝借して命名したMTGです。
SETチームでは1週間スプリントで、金曜日にバックログリファインメントをしてタスクを積み、月曜日から木曜日までそれらのタスクを完了できるよう頑張って働く、というスタイルでした。
しかし、もちろん当たり前ですが、月曜日に始めてみて思ってなかった課題が出たり、一日進めた結果これは想定していたやり方だとこのスプリント中に終わらないなということが出てきます。
その課題共有の仕組みが十分ではなかったため、課題が発生すると上手く回らなくなるというのがSETチームのうまくいかない時のパターンでした。
そこで、リファインメント時には想定してなかった課題が発生した際にみんなの力を借りて相談したいこと、少し進めてみて見積もりよりも工数がかかりそうな場合に期限内に終えるための作戦の相談など、各々の相談を持ち寄る「当てずっぽうの奥義MTG」をスプリントの真ん中にとることにしました。

変更した点

2週間スプリント
- リファインメントは2週目の金曜日にやって、2週間分の計画を立てる
- 1週目は課題を解決、2週目に課題がなくなった上でやり切る
当てずっぽうの奥義MTG
- スプリントの1週目の水曜日に当てずっぽうの奥義MTGで課題を解決する

奥義MTGを取り入れた結果

大成功！とまではいかないですが、ほどほどに上手くいったかと思います。

上手くいったこと
- スプリントの終わりまでユニットや個人で課題を抱えることがなくなった
- 困ったら相談する時間というのを作っておくことで、アドホックに打ち合わせを入れなくて良くなり相談のハードルが少し下がった
- リファインメント時の想定と違うことがあっても、「奥義MTGで相談して方向性を決めよう」となり柔軟に動けるようになった
解決しきれなかったこと
- ラーメン・フラペチーノ問題が起きてしまったこと (XP祭り参加の記事で紹介しているのでぜひご覧ください)
- 課題解決の仕組みはできつつあるが、チームで助け合うにはあと一歩という感じ

困った時に相談できる場が定期的に開かれている状況というのが、ヘルプを出すハードルが下がり、シャイな私や、他のSETチームメンバーには合っているように感じました。
定期開催することで、「今他の人は忙しくないか」、「こんなこと聞くためにMTGを開いていいか」、などシャイな人あるあるな躊躇いによる負担が減り、相談していい時間が事前に用意されていることは個人的に楽に感じました。
各々のチームの課題を共有はできるようになりましたが、まだお互いにやっている仕事の理解はもう一歩というところでした。

ここで登場したモブワーク

ここでテックリードにチーム全体でモブワークを取り入れてはどうか？という提案をもらいました。
今まで朝に30分、夕方に15分情報共有をしていましたが、その時間を1時間ずつに延長し、「朝モブ」「夕モブ」と名付けてモブワークすることにしました。

③ モブ全盛期

モブ全盛期の時間割

変更した点

朝会、夕会 -> 朝モブ、夕モブ
- 朝夕のスタンドアップミーティングは十分に時間を取る
1週間スプリントに戻す
- 2週間スプリントは効果があると感じられなかったため

朝モブ・夕モブでやること

できたこと、動くものをデモする
- お互いのやっていることを質問をしながら理解する
- フィードバックをし合う
コードを書いていて詰まった点、Gitの操作、仕様が分からない箇所などをモブで解決していく
- 課題になっていることを全部ここで解決できるようにみんなで解決策を考える

ちょうど新しいメンバーが入り、オンボーディングの時期でもあったので疑問点は朝夕にモブで解決していました。動いたものを見せて、そこで残っている課題のコードを見てもらいながらモブプログラミングをしたり、レビュアーにレビューを出す前に口頭でコードの概要について説明をしたりしました。

モブワークの効果

fundonelearn

上手くいったこと
- スプリント始めたての週初でも相談して方向転換ができるようになった
- お互いに何をやっているのか前より理解し合えるようになった
- 認識の違いが発生しても、その日中のモブで解消できる
- 相談のハードルが下がった
- 質問のハードルも下がった
- ナビゲーターの知識や小技や考え方を学ぶことができる
- 孤独感が減る
やっぱり上手くいかなかったこと
- ラーメン・フラペチーノ問題の再発（これはユーザーストーリー導入で回避）

モブワークを取り入れたことにより、当てずっぽうの奥義MTGでは解決しきれなかった「チームで助け合う」ことができるようになりました。
今までは1つのマイルストーンに対して作業を人毎に分割してしまうと、自分の仕事だけに集中するような仕事の仕方になってしまい、本来はお互いの仕事が関係し合うはずなのに完全に並行に作業をしていました。
お互いの作業が交差するタイミングで、お互いがなんの目的でその仕事をしていて今どういう状況なのか分からず、両方の作業を見ているリーダーに説明をしてもらってから、2つの作業を合流させていました。
仲が悪いわけではないにしろ、本来取るべきコミュニケーションが取れておらず、合流のタイミングで大きなPullRequestをマージするようなもので必ずコンフリクトが起きていました。
それらが日々のモブワークにより、小さい認識の違いのうちに見つけて解消ができるようになりました。
小さい認識の齟齬を見つけたり、お互いの疑問点をそのままにしてしまうとまた大きなPullRequestが出来上がってしまうので、毎日分からないことや疑問点をお互いに質問し合うようになりました。
今までは大きなPullRequestを持ち寄って、質問しあったり、Teams上で質問しあったりしていたので「今更こんなこと聞いていいのかな？」という質問や、「文章だと上手く伝わりにくいけど会議を開くほどでもないしな」という質問がその日のうちに口頭で聞いて解決できるようになりました。
質問のハードルが下がったことにより、お互いの作業の理解度がグッと上がってきました。
また、リーダーに依存していたコミュニケーションがメンバー同士で協力して課題が小さいうちに解決しながら進んでいくことができるようになりました。

川口さんに食べログでモブプログラミングについて講演してもらいました！

ちょうどSETチームでモブいいね〜となっているタイミングで、食べログのTDD(TabelogDeveloperDojo)で川口恭伸さんを招待して講演してもらおうということになりました。
川口さんといえばモブプログラミングの第一人者です。
タイミングも相まってモブプログラミングをテーマとして選定しお話をしてもらいました。
当日は食べログ以外にカカクコムの他の事業部からも60名ほどが集まり、チャット欄も大変盛り上がりました。講演が終わった後のQ&Aコーナーでモブの導入に関するハードルや、エンジニア以外の職種もみんなでモブをするにはどうしたらいいか、などの質問が川口さんに寄せられました。

川口さんの講演の様子

この中でお話が出た、「生産性を破壊するものたち」が私たちSETチームの中にもあったとこに気がつきました。
設計を考える人と実装者が異なり、伝言ゲームの末に異なったものができたり、伝言ゲームのためのミーティングが日中にたくさん詰まっていて作業時間が少なくなってしまったりということが起きていました。
それぞれが自分の力が原因で起きていると思っていましたが、川口さんがスライドの中で、「ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というピープルウェアの中での言葉を引用してくれました。
これまでチームメンバー間のコミュニケーションはMTG中が主でしたが、モブにより時間に余裕ができ、朝夕雑談がしやすくなりました。
コミュニケーションが問題だからといってコミュニケーションにだけ焦点を当てて特別なことをしなくとも、一緒に考える時間を十分に取るということで案外解決するものなのだな〜と思った次第でした。

本当はモブ始める時ちょっとドキドキしていた

個人的にはモブワークをすることはあまり気が進みませんでした。どちらかというと、まずは個人で調べたり考えをまとめたりしてから話したいタイプだったので、話し合ったりコミュニケーションを取りながら意思決定をしたりコードを書くモブワークが自分には向いていないと思ったからです。
腹落ちしてからでないと自信を持って話せないタイプなので、他の人との会話で理解できるまで何度も聞き返したりしてしまうのではないかと、スピードについていけるかが不安でした。(しかも食べログには早口の人が多い！)
しかし、その不安は杞憂でした。
それまでは、1回自分で頑張ってみてそれでも分からない時にやっと聞く、という癖がついていて、沼にハマったりして時間を溶かしていました。
モブの時間ができたので、分からなくなりそうな箇所のとっかかりだけでもまず聞こう、と思えるようになり、知っている人や詳しい人にまずは聞いてみるということが少しずつできるようになってきました。
今までの自分の働き方の大きい課題が、モブによって解消され、仕事中分からないことを抱えている焦りやストレスが少なく働けるようになってきました。

働きやすくなったことはわかった、成果はでたの？

モブワークを取り入れたクォーターに立てた自動化のOKRを達成できました！

アウトカム

元々のOKRではデータ作成にかかる時間25%削減を目標にしていましたが、結果的には95%の削減と大幅に目標を上回ることができました。
最初の予想だと、上記の時間の話で書いた通り、人数でスケールできないのでクォーターの期限に間に合わないのではと思っていたからです。
しかし、よかったこととして上記で何度も書いた通り、認識合わせやフィードバックで立ち止まることが減り、前に進めるための作業時間を十分に取れたので結果も出すことができました。

④ モブ全盛期を経て現在

長めの共有会をする期の時間割

1クォーター3ヶ月ほどモブワークを取り入れてみて、成功体験を得ることができました。
その次のクォーターからは、ガッツリチームでモブワークをするというよりも、朝会夕会の時間を長めにとり、お互いのやっていることと課題を共有する時間を十分に取る形に緩く変えていきました。
モブワークを得たチームで協力する体制を維持しつつ、チームで担う仕事のバリエーションも増えたので個々人の作業も増やして働くようにしました。今は各自で作業を分散して仕事をしながらも、相談ややっていることの共有をスムーズにできています。
今後もチームメンバーの人数や状況に合わせながら、またガッツリモブワークを取り入れるのもよし、今のような形を続けるのもよしで改善を続けていきたいと思います。