こんにちは〜
人事評価機能を開発しているプロダクトエンジニアのnekoです。
人事評価機能の開発チームでは、2024年10月頃までモブプログラミングを主体とした手法で開発を行っていました。
チームにモブプログラミングを行うというルールがあり、大半の開発をモブプロで行っていたのですが、モブプロをうまく行えておらず、ソロ開発をメインに切り替えたときに起きた変化と課題についてお話します。
モブプログラミングそのものよりは、チームの課題多めで、モブプロを批判する意図はないので悪しからず。
モブプログラミングを行っていた背景
私は2024年4月に入社したのでそれ以前のことは詳しく分からないのですが、少なくとも私が入った時点ではモブプロメインの開発になっていました。
ちなみに、モブプロメインの運用を始めたのは、当初、様々な事情でチームメンバーの稼働が不安定だったからと伺っています。
モブプログラミングを行っていた背景にはいくつかの理由がありました。
- フロー効率重視で価値提供速度を上げるため（集中的に開発しリリースを早くする）
- 技術継承
- スキルアップ
- 品質向上
たしかに、モブプロを行うことでこれらのメリットを享受できる可能性は高いと思います。
一方で、モブプログラミングはハードなプラクティスでもあり、チームメンバーが疲弊したり、モブプロから抜けにくいなど課題もありました。
認識していたモブプロの課題
チームが認識していたモブプロの課題です。
レトロスペクティブで改善に向けアクションはしていたものの、うまく改善できずにいました……。
効率が悪く感じる
様々な要因があると思いますが、実際に効率が悪かったのかもしれません。
モブプロの利点である即時フィードバック等を活かし、早く、質の高いプロダクトを作れると良かったのですが、うまく享受できていなかった認識です。
実際にアンケートを取ってみましたが、全メンバーが効率が悪くなっていると感じていました。（かなしい）
リソース効率とフロー効率が要はバランスであるように、モブプロとソロもバランスだと考えていて、全リソースをモブプロに注ぎ込むのは得策ではなかったと思います。
抜けにくい
同期で作業していると抜けにくいと感じるメンバーの方がいました。
モブプロ自体がある程度ハードなことに加え、休憩を取りたいのに取れない、他のメンバーが頑張っているのに言い出しにくいなど、ストレスを感じやすい環境になっていたと思います。
そのような環境で仕事をするとパフォーマンスを下げる要因になりうるので、解消したかったです。
疲れる
ずっと同期で話しているので疲れます。
いや、結構疲れます。
モブプロ用のタイマーを使っていたのですが、キリが悪い等の理由で休憩をスキップしたりもしてました。（よくない）
また、当時は朝から夕方までモブプロでやっていたので、今振り返るとハードなことをしていたなと思います。
意思決定が難しい
モブプロではなくチームの課題な気がしますが、意思決定に時間がかかっていました。
集まって同期コミュニケーションを取ってる間に、何か意思決定が必要場面になると、議論が発散し結論を出すまでに時間がかかることがあり、課題に感じていました。
振り返りで議論しいくつかの施策を実施してみたものの、目に見えた改善はできていませんでした。
モブプロ→ソロにしてよかったこと
まずはよかったことです。
やはり並列でスピードを出すことと、拘束時間が減ることの効果が大きかったと感じています。
良いこともある反面、後記する課題にも書いていますが、質問へ回答やレビュー完了までの時間は延びてしまいました。
ベロシティが上がった
単純に並列で進められるのでベロシティが上がりました。
7ポイントから16ポイントくらいまで、約2倍上がりました。
並列で進めることで、より多くのチケットを捌くことができるようになり、開発効率がガッツリ上がりました。
かなりインパクトが大きい改善になったと思っています！
自分のペースで開発できるようになった
ソロなので、自分のペースで開発できます。
悩んだ時に一人でじっくり考えたり、好きなタイミングで少し休憩することもできます。
一部の実装を凝ってみたり、遊び心を出すこともできます。
メンバーによっては口頭のコミュニケーションより、文字ベースの方が得意という方もいるので、そういった方にとってもやりやすい環境になったのかなと思います。
（もちろん口頭の方が良いという方もいる）
人によっては労働環境が良くなったかも
これは完全に私事ですが、私の仕事部屋は二階にあり、冬でも日が出ると暑くなります。
冬に冷房はつけたくないので窓を開けたいのですが、モブプロ中は話す機会が多く、情報漏洩等の観点から窓を開けられずにいました。
また、ハウリングを防ぐためにイヤホンをしていましたが、耳の形に合っていないにも関わらず、ちょっと高いイヤホンなので意地になって使った結果、耳が痛くなってました。 完全に私の落ち度ですが、長時間使うイヤホンは自分の耳の合うものを使うと良いと思いました。（それはそう）
ソロメインになってからは、拘束される時間が減り、ちょっとしたストレスが溜まりにくくなったと実感しています。
モブプロ→ソロにあたって工夫したところ/課題
ここからは工夫したところや、現在もある課題について書いていきます。
ずっとモブプロをやってきたメンバーだったので、最初は戸惑うことが多かったです。
他のメンバーが何してるか分からない
ソロ開発に移ってすぐは、他のメンバーが何をしているのか分からず、透明性が低く、必要なサポートが行えない状況に陥っていました。
実装や仕様面に関しても、どのような背景で決定されたのか分かりにくく、レビュー時間が延びるなど悪影響が出ている箇所もありました。
そこで、議論した結果、Slack上でリマインダーと作業スレッドを作成するようにしました。
リマインダーは12:00、15:00、18:00に自動で投稿されるようになっており、そのスレッドに進捗を書き込むと行った具合です。
作業スレッドに関しては、別のチャンネルに担当するチケットのスレッドを立て、そこに考えたこと、悩んでいることなどを何でも書き込んでいます。
コードレビューのリードタイムが延びた
コードレビューが難しくなりました。
モブプロをしてた頃は、みんなが同期的に実装を進めていたので、ソースを見てすぐに内容を理解することができましたが、ソロでそうは行きません。
ソロの場合、なぜこのコードになっているのか、自身で考えを巡らせたり、調べる必要があります。
実装時に細かなフィードバックが無いため、レビューによる手戻りも発生しやすくなったと感じています。
レビューをしやすくするための工夫としてPull Requestのサイズを小さくしたり、Descriptionに変更内容を詳細に記載したりしていますが、それでもモブプロをしていた頃よりレビュー難易度が上がったと思います。
また、他の課題として、メンバーからのレビューが開始されるまでのリードタイムも延びてしまいました。
Slack上でレビュー依頼をしてレビューしてもらう流れなのですが、メッセージが流れて忘れられてしまう、レビュー依頼がたくさん飛んできてコンテキストスイッチが辛いなど、未だに課題が残っています。
相談するのが難しかった
口頭でシュッと聞けないため、相談することに一定のハードルが生まれてしまいました。
どこまでを自分で解決して、どこからメンバーに相談すれば良いのか迷いが生まれ、相談することを躊躇ってしまうことがありました。
また、質問から回答を得るまでのリードタイムが延びたことにより、ヤキモキしてしまったり、返信が来るまで不安という意見もありました。
そこで、戸惑わず相談して良いという共通認識を作り、解消に向かいました。
共通認識を作ることで現在は解消できていると思います。
相互理解が進みにくくなったかも...
メンバー同士で話をする機会が減ったため、相互理解が進みにくくなったような気がしています。
完全な憶測なので断定はできないですが、モブプロをやっていた頃はモブ中にちょっとした雑談や、その人の癖や考え方など、同期的に話しているのでわかりやすかったですが、ソロになってからそういった出来事は減りました。
ちょっとした悩みなど相談できるタイミングが減ってしまったので、小さな課題が残り続けないか、少しだけ気がかりです。
おわりに
今回はモブプロメインの開発からソロに切り替えたお話を書かせてもらいました。
特にベロシティ約2倍は個人的にインパクトが大きかったと思っています。
開発方法はチームの状況によって変わっていくものなので、今後も継続的に改善していきたいと思います〜
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
SmartHRではチームやプロセスを改善するチャンスがたくさんあります。
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
