こんにちは。SmartHRで基本機能を開発しているプロダクトエンジニアの前川です！ 基本機能ではLeSS(Large-Scale Scrum)を用いた複数チームでのスクラム開発をしています。私の所属するチームでは最近、モブプログラミングを導入しました。そこで、実際に経験しての感想をご紹介します。
モブプログラミングとは？
モブプログラミングはソフトウェア開発のアジャイルな手法の一つで、チーム全体が協力してコードを一緒に書き、問題解決、設計、デバッグ、テストなどの作業を共同で行います。
主な特徴
- チーム全体の協力
- すべてのチームメンバーが同じタスクに取り組むため、問題の多角的なアプローチが期待できます。
- 知識共有
- チームメンバー間で知識共有が促進されます。プロダクトの経験が浅いメンバーは経験豊富なメンバーから学び、結果としてチーム全体の技術的な能力が向上します。
- 品質向上
- チームメンバーが一緒に作業することでコードの品質を改善し、バグや問題を早期に発見し修正できます。
導入の経緯
チームに新メンバーが2名加わったのと、新しい機能開発が始まるのを機にモブプログラミングを導入することにしました。以前は、個人またはペアプログラミングでの作業が主でしたが、この方法では属人化が進み、コードレビューにかかるコストが大きく、手戻りが発生しやすい状態でした。今回モブプログラミングを導入することで、サービスに対するドメイン知識の理解、コード品質の改善、そして問題の早期発見を実現し、開発プロセス全体の効率向上を狙っています。
早速チームで試してみた
メンバー構成
- 既存メンバー3名
- 新メンバー2名
導入当初の進め方について
- モブプログラミングの時間を確保するために参加メンバーのカレンダーの予定を登録する
- Zoomを使ってオンラインで進める
最初の感想、どうだったか...
最初、ドメイン知識がない状況でドライバーを担当することに対して、緊張と不安がありました。また、今まで人に見られながらコーディングする経験がなかったので最初はすごく恥ずかしかったです。
しかし、モブプログラミングでは他のメンバーの知見を共有しながら進められるので、新人でも与えられたタスクに対して大きく詰まることもなく、比較的スムーズに作業を進めることができました。新人にとってモブプログラミングは、幅広い知識を吸収しながらタスクを進められる良い方法だと感じました。
一方、長時間モブプログラミングで進めるとメンバー全員疲労が溜まり、集中力が続かない、メンバーの時間が合わないといった問題もありました。
やってみての課題
- 長時間続けると疲労が溜まり集中力が続かない
- 別の打ち合わせなどで出入りがあると状況の把握が難しくなる
- チームメンバーのいずれにも知見がない課題に直面した時にタスクが進捗せずに時間だけが過ぎていく
課題を改善した
これらの課題を改善するため、チームで取り組んだ内容は以下の通りです。
タイマーを使ってドライバーを定期的に交代する
モブプログラミングはドライバーが長時間同じ作業を続けるため、疲労が蓄積し集中力が切れたりすることが多くありました。 そのためタイマーを25分または50分で設定し時間になったら強制的に小休憩を挟み、ドライバーを交代することをルールとしました。
後から入ってきたメンバーには都度現在の状況を共有する
5人のメンバーで開発をすると、毎回全員が同じ時間に集まれるわけではなく打ち合わせなどの諸事情によりZoomへの人の出入りが多く発生します。 そういった状況でも内容についていけるように、後から入ってきた人には必ず状況を説明する時間を作るようにしました。
全員が何も分からない場合は一度解散して調査した上で改めて集合する
チームメンバーのいずれにも知見がない課題に直面した時、その場では誰も分からず何も進まなくなるような状況があります。そういった場合はモブプログラミングをしていてもただ時間が過ぎていってしまいます。 その場合は思い切って一度解散し、各自で作業をして調査をした上で再集合するようにルールを決めました。
モブプログラミングの最後にふりかえりを実施する
モブプログラミングを実施してみて課題が毎日のように出てくることがわかったので、1日の最後にふりかえりを実施するようにしました。
改善後の進め方について
- モブプログラミングの時間を確保するために参加メンバーのカレンダーの予定を登録する
- Zoomを使ってオンラインで進める
- タイマーを使って60分枠(50分作業 + 10分休憩)または30分枠(25分作業 + 5分休憩)で進める
- 時間がきたらドライバーを交代する
- 1日の終わりに振り返りをしてホワイトボードツールのmiroに改善点を書いていく
オフラインでのモブプログラミング体験
出社してチームビルディングをする機会があったので、オフラインでのモブプログラミングを実施してみました。
実際にやってみて感じたオンラインとオフラインでの違いについて紹介します。
オフラインでのメリット
- 他メンバーの楽しむ様子、困っている様子を読みとれるのでより団結して取り組める
- オンラインよりもメンバーの意見が出やすい
オフラインでのデメリット
- 会場の設営や準備に時間がかかる
- 各自のPCの拡張ディスプレイがない場合が多いため作業しづらい
まとめ
モブプログラミングには以下のようなメリット・デメリットがありました。
メリット
- 朝会の時間が短くなった
- サービスのドメイン知識がメンバー全員に共有される
- Ruby on Rails初心者でも安心して進められる
- レビューのコストが大幅に削減される
- 属人化しない
デメリット
- 単純な調査・実装のタスクに対しては、チーム全体の開発リソースを割くのは効率が悪いため向いていない
- 自分の集中力に関わらずモブプログラミングが続くので疲れがち
今後も、定期的にモブプログラミングの機会をもうけて、チーム全体でコードの品質を保っていきたいと思います。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
