こんにちは。スマートキャンプでエンジニアリングマネージャーをしている米元です。 本記事はスマートキャンプ Advent Calendar 2019 - Qiita の16日目の記事です。
皆さんの会社ではモブプログラミング、通称「モブプロ」をやっていますか?
興味を持っている方は多いものの、
- なんだか楽しそうだけど実際どんな効果があるのかわからない
- 効率悪くなりそうなので上司から許可が出ない
などの理由でなかなか導入に踏み切れないケースが多いのではないでしょうか。
スマートキャンプでは数ヶ月前からスクラムを用いたアジャイルな開発プロセスを取り入れていますが、その一環としてモブプログラミングも導入しています。
この記事では実際に数ヶ月間モブプロを実践してきたメンバー達にモブプログラミングのメリット・デメリットについてのアンケートを行い、その結果を赤裸々に書いていこうと思います。
なおモブ「プログラミング」だけでなくレビューや調査などの他の作業でも複数人で作業をすることがあるため、以下の文章では単に「モブ」もしくは「モブワーク」と記載している場合があります。
- 今までの会社やプロジェクトで、業務でのモブ経験はありましたか
- モブプロのメリット
- モブプロのデメリット
- 印象的なエピソードがあれば教えてください(良いこと悪いこと両方)
- モブプロをこれからも続けたいですか?
- 改善したい点があれば教えてください
- モブプロに対する感想をどうぞ!
- 結果から分かった事
- まとめ
今までの会社やプロジェクトで、業務でのモブ経験はありましたか
ほとんどのメンバーが経験が無く、今回が始めてだったようです。
モブプロのメリット
情報共有、共通認識の形成
技術・知識の情報共有とそれによる作業効率の向上、チームで共通認識を作れる事に対する効果が多くあがっていました。
- 朝会の時間が短くなった
- 実際に手を動かす姿を見ることで新入りメンバーが作業する上での勘所を効率よく吸収できる。オンボーディングにもよい
- 知識共有、規約の共通認識
- 進捗も常に全体で共有できている
- 開発ラインが1つになるので、全体を通して何が動いているか?を全体で認識しやすくなる
- 集合知が取れること
- リスクがある部分を並行して検証できること
- チームの課題をすぐに発見・取り組めること
レビュー
レビューに関するメリットを上げている人も多かったです。
- 知らないプルリクが存在しなくなった
- レビューがないことでPRの放置がなくなる
- 口頭で共有しながら進められる、レビューがその場で即完了する
- レビュー工数が少なくなる、手戻りが少なくなる
フロー効率
フロー効率についてあげているメンバーもいました
・フロー効率を意識できること。
後の「印象的なエピソードがあれば」とかぶりますが、モブでタスク消化しているものに関してはコーディングの後に軽く全員でレビューしてマージが即座に行われていきます。
そのため、レビューによって一つのタスクに対する作業者が変更になることがなく、それに伴う待ちも発生しません。割とレビューのやり取りによるストレスは結構あるので、それがないだけでメリットだと感じます。
その他
また、チームで作業することにより精神的な負担が和らぐケースもあるようです。
- 辛いタスクが少しだけ辛くなくなる(バグ調査とかは最適)
モブプロのデメリット
メリットだけでなくデメリットも多く感じているようです。
複数人でやることによる集中力や意思決定の問題
- ナビゲーターはかんたんにオブザーバーになれるし、他のこともできるし、モブに参加しようという意思が参加者に必要。
- 人数が増えてくると発言する機会が少なくなり、集中力散漫になる
- 3人以上になると開発スピード落ちやすい(個々の集中力、発言機会、やることが低下する)
- いろんな解釈・意見があるようなタスクだと「船頭多くして船山に登る」といった状態になりかねない。
- 案外ミスを見逃す(誰かが見てくれてるだろうとか、細かい作業でみんなに見られてると思うと焦ってとかかな...)
作業内容によって時間効率が落ちる問題
- 参加者全員の時間を消費するので、簡単なタスクほど時間効率が落ちる
- 細かいリファクタリングなどは言葉でドライバーに伝えるのが難しく、もどかしさがある
- 個人でできるタスクをやるのは向いてないし、むしろ遅くなる
スケジュールやモブへの出入りの問題
- 予定を合わせるのが難しい&一人になったときに作業が不明確になる
- メンバーが揃わず、入れ替わりになると、作業効率悪い
- 抜け時や入り時がわからない
その他
- 個々人の達成感が削がれることがある(自分が書いたコードにアイデンティティを感じる場合など
- アウトプット量が減っていると感じることがある(プロセス指標を取っていないのでなんとも
- モブプロの業務ノウハウを持っていないため、何がよくて何が悪いか、それを判断するのが難しい
- 後に残らない情報が増えがち
- 普通に仕事するよりかはとても疲れる。
デメリットというよりまだまだベストプラクティスが見つかっていないというのが現状のようです。
印象的なエピソードがあれば教えてください(良いこと悪いこと両方)
良かったこと
開発チームだけでなく他部署とのモブワークのエピソードもありました。
- マーケティングを担当しているメンバーとデザイナーとエンジニアチームで全員集まって技術検証をやったことがあった。お互いの知識を全部出しあい、検証ができて気持ちよかった。全員で集まることで情報の齟齬や「調整」「交渉」などが発生せずスムーズに進んだ。
他にも複数人でやることのメリットが感じられたエピソードとして以下のようなものがありました。
- 大きい変更作業をみんなで検討・実装することで認識共通化できて、作業やりやすいね!ってなった
- 難しい仕様を考えるとき、全員が考えるので軌道修正を細かく可能だった
- 面倒なドキュメント作成のタスクをモブで共同編集することで心理的な障壁を下げつつ効率よく完遂できた
悪かったこと
以下のように悪い面でのエピソードもありました。
- 全員でレビュー項目を漏らしたことがある
デメリットにもあげられていた、人数が増えて注意力が散漫になってしまった時に発生したのかもしれませんね。
モブプロをこれからも続けたいですか?
半分のメンバーは「どちらとも言えない」との意見でした。
これはメリット・デメリット両方感じていることと、今のモブプロのやり方が最適という訳ではないと感じている事からこのような結果になっているのだと思います。
改善したい点があれば教えてください
集中力について
- 全員がモブに集中できるような環境、作業を全員の脳で並列でやれている感覚を持てるような方法を見つけたい。
- 全員が集中して短時間で効率的・高成果なモブにしたい
- 長時間やると意識が分散しがちなところ
パフォーマンスについて
- パフォーマンスを高めるために
- モブ自体のやり方改善(ドライバー以外の立ち振舞いなど)
- ペアプロや個人作業時間の確保
- チームの人数が増えても開発速度が上がらない、3~4人いると持て余しがち
モブと個人作業使い分けについて
- モブの使用すべき箇所の定義をしっかりして、個人作業でできるものを分離していきたい
その他、改善のために必要なこと
- モブによるメリット・デメリットを定量的に図れるようにしていきたい。その上で改善策を練れるようにしたい。
- 正直なところ、チームで改善することに限界を感じてます。こういう方向に向かうと明確に示してあげられる人がいないとモブプロの改善はこれ以上進んでいかないだろうなと。そういった点で、経験・知見のある方を招聘した上で、実業務で一緒にモブプロをしてもらい、こういう形だとめっちゃアウトプット出てるよね!って言えるようにしたいです。
モブプロに対する感想をどうぞ!
良さを感じている人、楽しい人、難しさを感じている人など様々でした!
- モブが当たり前になってきたここからがスタートですね。
- 純粋にワイワイ開発するのは楽しいのでモブは好きです
- 月・火・水を個人 or ペアで進めて、木・金をモブはパフォーマンスよい。重めのタスクは月・火・水でもモブを柔軟にまぜる
- 思ったよりもパフォーマンスは落ちない(レビュー工数やバグ率)けど、ちゃんとやらないとそこそこパフォーマンス落ちる。基本的には楽しい
- チームを選ぶプラクティスだなと感じてます。結構取り入れてから時間経ってみんなの中でフロー効率に対する意識が体に染み付いているような気もするので、ちょっとずつモブでやる範囲を減らしても良いのかなとは思います。
- やり辛さも多々あるが、メリットも多い!慣れやベストなやり方にたどり着くのがとても難しい。
- 必要ならやればいいし、必要なければやらなくていいものだと思う
- 基本的には好印象です!手段の1つとしてうまく使い分けができるのが良いと思うので、メリデメを明確にした上で、使い分けられる用になるべきかな?と考えてます。
結果から分かった事
数ヶ月間、実際にチームで実践してみて様々なメリット・デメリットがあることが分かりました。
私が実際にメンバーから意見を聞いたり、このアンケート結果を読んでモブを円滑に進めるために必要だと感じたポイントは以下の3つです。
モブに適した作業はモブで行い、個人に適した作業は個人で行う(なんでもかんでもモブではやろうとしない)
モブプロには前述したように
- 情報・知識・技術の共有
- フロー効率が上がる
などのメリットがありますが、作業内容や進め方によってはデメリットがあることも分かりました。 そもそもモブに向いてない作業(誰がやっても同じ結果になるもの、定型化した作業など)は個人でやるなど、作業内容によって使い分けるのが良さそうです。
環境を整える
弊社の場合、メンバーが開発とは別の会議(他部署との会議、エンジニアのMeetupの運営会議、ブログ運営の会議など)に参加してモブを抜けたり、そもそも最初からいなかったりする場合があり、モブの実施自体がうまく出来ない事が何度かありました。 メンバーが同じ時間に作業が出来るようにメンバーや他部署の人にも協力してもらって会議のスケジュールを調整するなどの工夫が必要だと感じました。 実際に定例系の会議についてはメンバーが被らないようにしたうえで同じ時間帯に実施するように調整中です。
また、現在はモブがしやすいように大型のディスプレイやドライバーの変更時にPC切替えがスムーズに出来るように購入したりするなどハード面での環境の整備をしていますが、これらによってモブワーク時のストレスを取り除く事も重要な要素であると感じました。
何のためにモブをするのか、チームで認識を合わせる
1とも被りますが、作業内容やプロジェクトの状況・メンバーの志向性・チームの状況などによっても、モブでやるべきではない事もあるでしょう。
モブをすることに拘って作業効率が下がったり、メンバーの不満が溜まっては本末転倒です。
最初はまずやってみるところから始めるのが良いと思いますが、ある程度やってみてからは改めてチームで振り返りを行い、そもそもモブワークに何を求めるのか、何の目的で行うのかを認識を合わせたうえで進めていくのが良さそうです。
まとめ
以上、弊社で実践してみて分かった事をまとめてみました。 これから導入を検討している方や導入したもののうまく進められていない方に少しでも参考になれば幸いです。
個人的には、「モブプロ最高!」のような結果ではなく、課題や改善点もしっかり出してくるところがスマートキャンプのエンジニアらしいなと思いました。 今後は社外の知見のある方にも頼りながら、モブワークの練度を上げつつ目的に応じて実施するかどうかを決めていくようなスタイルになっていきそうです。
さらに詳細を聞いてみたい、実際にモブを体験してみたいという方がいればぜひ弊社オフィスまで遊びに来てください! hrmos.co
次回のAdvent Calendarは瀧川によるfullstoryとlogrocketについての記事です。お楽しみに! qiita.com