Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

モブプロにやりづらさを感じて改善した話

Sansan 事業部プロダクト開発部の光川です。

私が所属している関西支店のチーム(MAIDO)では、よくモブプログラミング(以下、モブプロと記載)による開発を行っています。

f:id:mitsukawa_sansan:20190419181512p:plain

この記事では、私が新入社員としてモブプロによる受け入れを体験した中で

  • 初めてのモブプロに感じた悩み
  • チームがモブプロの課題をどう改善したのか
  • 新入社員目線で感じたモブプロの効果

をご紹介します。

これから新人の受け入れにモブプロを使おうとしている人や、既にモブプロを実践しているけれど課題感を持っている人に向けて、私たちの挑戦がヒントになれば幸いです。

なぜモブプロを始めたのか

MAIDOチームでは、半年ほど前からモブプロを取り入れています。

当時のチームは入社1年未満のメンバーが半数を占めていたため、下記のような課題を抱えていました。

  • 社歴の浅いメンバーへの知識の共有
  • 今後継続的に増えるであろう新規メンバーの教育コスト
  • 一部のメンバーに実装作業が偏ることによるレビュー待ちタスクの滞留

その解決案として、モブプロを導入しました。

初めてのモブプロに感じた悩み

私自身、過去にペアプロは何度か参加したことがあったのですが、モブプロは初めてでした。 入社後にモブプロを体験し、次のような印象を受けました。

  • ペアプロと比べて質問しづらい
  • 作業のペースが掴みにくい
  • どのくらい質問していいのか悩む
  • 時間配分がわからない(作業の全体像と現在の進捗度合いが見えない)
  • 後半に緊張感が薄れてしまい、タイピストの一人作業になりがち

モブプロが難しいものなのか、自分とメンバーのレベル差が大きいことが問題なのか、何がやり辛さの原因かわからずに悩みました。 そしてこのままでは自己の成長に繋がらないという焦りを、チームの振り返りで伝えてみました。

みんな感じていたモブプロの課題感

実は他のメンバーも課題感を抱いていたようでした。 モブプロを始めたのは良いが、ちゃんとしたやり方が出来てないのではないかという悩みもあったようで、 当時出版されたばかりだった モブプログラミング・ベストプラクティスを参考にチームのモブプロを見直すことにしました。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

みんなでモブプロの見直し

今回は見直した内容のうち、6つをご紹介します。

1. 役割の見直し

「タイピスト(ドライバ)」と「その他のモブ(ナビゲータ)」の役割の見直しを行いました。

見直し前は次のような役割でモブプロを行っていました。

  1. タイピストが自分で考えて実装する
  2. タイピストは実装を実況する
  3. その他のモブはわからないことがあればタイピストへ質問する

質問のタイミングが難しく、モブプロ中に疑問が解消できないという問題や、タイピストの役割が多く、タイピストのスピードによってチーム全体の進捗度合いが左右されるため、習熟度の低い状態のメンバーがタイピストをすることのプレッシャーが重いといった問題がありました。

そのため、本に従って次のように役割を変えました。

  1. タイピストは頼まれたことを実装する
  2. その他のモブがタイピストへ実装して欲しいことを伝える
  3. タイピストはその他のモブの要望を理解できない時にわかるまで質問する

この変更により、タイピスト-モブ間のコミュニケーションの頻度が上がりました。

タイピストが作業を始める前に必ず会話が発生するため、そのタイミングで自分も積極的に質問ができるようになりました。 更に質問をせずともタイピスト-モブ間の会話を聞くだけで、実装の背景や意図をキャッチアップしやすくなりました。 タイピストとして参加するときも、その他のモブとして参加するときにも、自身の知識の蓄積にも繋がっている実感が持てるようになりました。

また、タイピストの役割だったものをタイピストとその他のモブで分担したことで、習熟度の低い状態のメンバーがタイピストをする際の負荷が軽減されました。

f:id:mitsukawa_sansan:20190419142826j:plain
役割の定着のために、本より各役割を引用してディスプレイに貼っていました

2. モブプロ開始時の認識合わせ

毎回モブプロの開始前に、次の項目の認識合わせを行いました。

  • モブプロの目的(学習 or タスク完了)
  • 課題の概要の確認とタスク分割
  • 休憩タイミング

モブプロの目的では、チームとして学習とタスクの完了のどちらを優先すべきなのかを毎回すり合わせます。 メンバー全員で意識を共有しておくことで質問の心理的ハードルが低くなり、目的が「学習>タスク完了」の場合には初心者的な質問であっても躊躇せずに聞くことができました。

また、その回に取り組む課題の概要を全員で認識し、タスクに分割して付箋に書き出しました。 その時点でタスクに分割することが難しければ、調査の時間を取ることにしました。

分割したタスクを書いた付箋は見えるところに貼っておき、タスクの作業が完了したら剥がします。 そのため、あとどのくらいで作業完了になるのかが把握できるようになりました。

どのタスクが完了したら休憩を取るのかも事前に決めておき、それも付箋に書くことにしました。 作業と休憩のメリハリつけて作業をするようになり、より集中力を保ちやすい環境となりました。

f:id:mitsukawa_sansan:20190607110848j:plain
タスクと休憩を付箋化してディスプレイに貼っていました

3. 細かい単位でふりかえり

モブプロ実施のたびに、細かい単位でのモブプロのふりかえりを行いました。

例えば、午前のモブプロの最後に一度ふりかえりを行い、午後のモブプロで午前のTryを実践しつつ行う日もありました。 その日の午後のモブプロは午前に比べて格段にやりやすく、午後のふりかえりではProblemがぐーんと減り、Keepが増えました。

また、Tryの定着や前回参加できなかったメンバーへの情報共有のために、過去のTryの付箋は残しておきモブプロ中に見える場所に貼るようにしました。

f:id:mitsukawa_sansan:20190419142744j:plain
実際に貼っていたTryの付箋

4. タイピスト10分交代制

タイピスト10分交代制を導入してみました。

元々は実装の区切りで交代を行っていたのですが、10分交代制にしてみると10分間という時間がとても短く、交代までの間で何らかの結果を残したいという気持ちが生まれました。 以前よりも自然と時間の経過を意識しつつ、集中力の高い状態を保つことできるようになりました。

f:id:mitsukawa_sansan:20190607110846j:plain
10分を測るためのタイマー

5. 共有PCと複数著者コミット

元々タイピスト自身のPCで作業をしていましたが、10分交代制によりタイピストの交代頻度が上がり、次のような課題が出ました。

  • タイピスト交代のたびにソースコードの引継ぎ(Commit&Push)が発生、PC交代の時間ロスが大きい
  • タイピストの番にコミット出来ないことが続くと自身の成果が見えなくなる

そのため共有PCを使うことにし、成果が見えなくなることへの対策として複数著者コミット(Co-authored-by)を導入しました。 これによりPC交代のための時間ロスが無くなり、コミットログからはチームの成果だということが一目で分かるようになりました。

f:id:mitsukawa_sansan:20190603200832p:plain
Co-authored-by を指定したときのコミットログ

6. 各自レビューの時間

10分交代制の慌ただしさに慣れていないせいか、普段なら見落とさないようなミスを見落としてしまうことがありました。

モブプロの利点としてレビュー時間を削減できるという点がありますが、モブプロの習熟度が上がるまでの間は、まずは品質を担保しようということで、モブプロの最後に各自で落ち着いてレビューをする時間を取りました。 それにより後工程でレビュー漏れが発覚することがなくなりました。

改善後のモブプロ

モブプロの流れ

私たちのチームではモブプロのタイムテーブルが次のようになりました。

  1. 認識合わせ (10 分)
  2. モブプロ 1 周目 (人数*10 分+休憩 5 分)
  3. モブプロ 2 周目 (人数*10 分+休憩 5 分)
  4. 各自レビュー(15分)
  5. モブプロのふりかえり(15 分)

1日に2回以上モブプロを行う日は気分転換のためモブプロの作業場所を変えてみる等で、長時間のモブプロでも集中力を切らさないということを意識しました。

モブプロにより得られた効果

チーム内で知識の共有ができた

モブプロのやりづらさが解消されてからは、知識の共有や教育といったモブプロのメリットを多く享受できるようになりました。 またぺアプロとの違いとして、タイピスト-その他のモブのコミュニケーションを第三者として聞くことにより、チームメンバーの技術・業務知識レベルを知ることができ、チーム内で各メンバーの強み/弱みを共有できるということに気づきました。

新人が居てもチームの生産性が下がらなかった

スプリント毎のチームのベロシティを比較したところ、新人が入る前後で大きな差異はありませんでした。 教育のための時間を取らずとも新人の受け入れをすることができ、受け入れによるチームの生産性の低下が回避できていました。

チームワークが良くなった

モブプロの改善に伴いコミュニケーションが活発になり、ショートカットキーや各自のツールの使い方を聞いてみる/共有するといった、業務知識以外のTips の共有が行われるようになりました。 また少しでもモヤっとしたらふりかえりでチームに共有し、全員で協力し合いながら見直しを重ねることで、チームのみんなと一緒に前向きな気持ちでモブプロの改善に参画することができました。

終わりに

モブプロが難しいことをチームに伝えてから、数か月間でモブプロがどんどん進化していきました。

改善後のモブプロに慣れていくうちに、自分がタイピストの番にモブからどんな要望が貰えるのだろかとワクワクしたり、要望を受けたタイピストがどんな手法で課題を解決するのだろう、といったことを楽しめるようになりました。

もし、モブプロについて悩んでいたら、一人で悩まずにモヤモヤした気持ちをチームにぶつけてみるところから始めてみてはどうでしょうか。

© Sansan, Inc.