とある企業でモブプログラミングと、それを通して自分たちの仕事のやり方をどう変えていくのかについてお話する機会がありました。参加してくださったみなさんがコメントや質問で盛り上げてくださって、時間内に質問に答えきることができなかったのでブログにまとめてみます。
講演、ワークショップ、チーム支援などのお仕事の依頼はこちらからどうぞ！
Q&A
モブプログラミングに最適なチームサイズ、最大のチームサイズは何人くらいか？
チームの最適な人数は、3〜8人であるとよく言われます。その主な理由はコミュニケーション効率です。
-
Amazon CEO Jeff Bezos's Secret to More Efficient Meetings - Business Insider
Jeff Bezos thinks large meetings are unproductive. That's wh ...
www.businessinsider.com
単純にモブプログラミングをする際のコミュニケーション効率だけを考えれば、3〜5人くらいが最適な人数です。ただ、モブプログラミングをする目的次第では10人以上でモブプログラミングをすることも実際にあります。
たとえば、チーム内の知識移転や教育を目的にワークショップ形式でモブプログラミングをする場合、コミュニケーション効率よりもチーム全員で同じ時間を共有することの方が優先されるかもしれません。
効率だけでなく効果を考えて最適な場を設計できるとよいですね。
例えば「スキルレベルの差が大きすぎないこと」のような、モブプログラミングで取り組む際に気をつけた方がよい条件はありますか？
モブプログラミングはただのチームワークなので、モブプログラミングだからといって特別に気をつけることはあまり思いつきません。ただ、性質上コミュニケーション密度が濃くなるため、心理的安全性が低いチームの場合はストレスフルな場になりやすいので用法用量は守ったほうがよいでしょう。
ちなみに例示してくださったスキルレベルの差が大きい状態は、むしろモブプログラミングをうまく使いたくなるシーンです。モブプログラミングは必要な情報を必要なときにインプットすることができるので、教育効果が高く、知識移転に向いています。
モブプログラミングは新人教育もできますか？チームが集まる必要があるため、経験が少ない人がいると傍観してしまいそうだと思いました。
モブプログラミングの教育効果は高いため、新人教育や新しいメンバーの受け入れ時にうまく活用できるとよいでしょう。
スキル差がある場合に、なかなか仕事に貢献できなかったり、会話量のバランスが偏ってしまうことはあります。一番大切なことは、新人や新メンバーの方に「すぐに仕事に貢献することは難しいかもしれないですが、最初はわからないことをわかるようになることを大事にしてください」というようなことを伝えて、安心してその場に参加してもらうことです。
また、実際にモブプログラミングをするときのコツとして、わからなければ仕事を止めることができる権利を持っているドライバーを経験が少ないメンバーに多く担当してもらうように場を設計するとうまくいくことが多いです。
それ以外にも、
- 仕事を止めて理解を確かめる時間を定期的につくる
- モブプログラミング以外に個人で復習できる時間をつくる
などをやってみるとよいでしょう。人によって学習しやすいスタイルやペースは異なるので、相手に合わせてあげるとよいです。
コードを書いているときはググることも多いと思うのですが、モブプログラミングの場合はググるのもドライバーに担当してもらうのでしょうか？
それも一つの方法です。人によって検索ワードや検索方法が異なるので、そういった「ググる」を共通体験することにも価値があるでしょう。
私たちのチームではなにかに詰まづいたときは、自然とソロワークに切り替わって個々人の手元でググったりデバッグすることが多いです。そして解決策やよい情報が見つかった人がチームに共有をして、また自然とモブプログラミングに戻ります。
モブプログラミングをするからといって肩肘をはらずに、場面場面で最適な方法を選択できるようになることと、少しずつその切替をスムーズにしていくことを意識するとよいでしょう。
ドライバーが2人以上になることはあり得ますか？VS Codeなどの同時編集機能を使えば可能だと思います。
ドライバー2人以上にした方がよい場面であればやってみましょう。ただし、「なぜモブプログラミングを2つに分けないのか」という問いには答えられるようにしておいたほうがよいと思います。
私たちのチームでは、同時編集をする機会はあまりありません。同じ修正を複数ファイルに手作業でやらなければいけない場合に、一時的に同時編集で手分けして対応したことはあります。
エンジニア以外のメンバー（マネージャー、プロダクトマネージャー、ビジネスサイドなど）もモブプログラミングに入ることはありますか？
あります。
むしろ開発をしている最中に出た疑問点にその場で答えてもらったり、仕様変更の相談をリアルタイムで行ったり、できたものをその場で確認してもらうことで仕事がスムーズに進むので、よいかたちだと思います。そもそも仕事への貢献の仕方は人によってさまざまなので、必要であれば職種に限らず参加してもらえるとよいでしょう。
参加のタイミングについては、常に参加してもらってもよいですし、必要なタイミングで入ってもらうかたちでもよいです。
フェイストゥーフェイスで行うコミュニケーションと親和性の悪いエンジニアもいるかと思いますが、どう思いますか？
いらっしゃると思います。
ただし、それはモブプログラミングとしての課題ではなくチームの課題です。そのような多様なメンバーがいるチームでどう仕事をするのか。モブプログラミングをしないとしてもフェイストゥーフェイスでのコミュニケーションをしなければいけない場面やしたほうがよい場面はあるので、そのときにチームでどのように対応をするのか。
モブプログラミングは選択肢の一つに過ぎないので、チームに合わなければ他の選択肢をとればよいです。どちらか1つを選ばなければいけないわけではないので、チームや仕事に合わせて柔軟に対応してみてはいかがでしょうか。
常にモブプログラミングするスタイルでよいなと思っていることを教えて下さい。
前提として、私たちのチームの「常にモブプログラミングするスタイル」というのは、モブプログラミングをベースにしていますが必要に応じてソロワークやペアワークをしています。
その前提で、モブプログラミングをベースにしていてよいなと思う点は、
- アウトプットだけではわからないコツや考え方をお互いに学び合えること
- 同期が自動化されているので考えるコスト自体がなくなったこと
- インクリメント（つくったものが積み上がっていく）を実感できること
- ムダだと思うことが減ったこと
- 誰かが犠牲になることなく全員がエンジニアリングに向き合えること
- リモートワークにおいても常に話しているのでオフラインと違いを感じないこと
などがあります。
チーム内のコミュニケーションは円滑になる気がしますが、複数チームがある時のチーム間のコミュニケーションは何かしら工夫する必要があるのでしょうか？
そのとおりです。
チームでうまく仕事が進んでいたとしても、チームの外にいる人達とコミュニケーションをしていく必要はあります。
その際の工夫のコツとして、チーム「外」の人たちともキャッチボールだけでなくモブプログラミングのような共通体験を通したコミュニケーションを取り入れてみてもよいでしょう。
「チーム」というのは階層構造だと思うので、広い意味でもチームととらえてみるとふだん取り組んでいるチームワークとそれほど変わらないのかもしれませんね。
ソフトウェア開発以外の領域の活用事例あれば教えて下さい。
チームで同じアウトプットを目指して仕事をする場面であれば、ソフトウェア開発以外でもモブプログラミングを活用できます。
自分が実際にやったり聞いたことがあることだと、
- 翻訳
- 資料作り
- イベントづくり
- デザイン
- カスタマー対応
- メールライティング
などがあります。
仕様をつめるようなタイミングでは議論をして決まった内容をドライバーが代表して書くような進め方でよいでしょうか？
それでもよいと思います。
でもよく考えたら、モブプログラミングでなくても誰かが代表して文字や図を書いて意思統一を図っていくことはよくやってますよね。
フレックスや裁量労働制のような勤務形態との相性のよしあしはあるでしょうか？
そうですね、勤務時間がズレている場合はタイミングを考える必要はあると思います。
世界規模での多拠点開発であればタイミングを合わせることが難しいかもしれませんが、そうでなければ重なる時間はあると思うのでその時間に合わせればよいでしょう。
時間がズレて働いているチームの場合、チーム内での意思統一や知識移転の重要性が上がると思うので、重なる時間にモブプログラミングをすることはとてもよさそうです。
研究開発のような専門性がかなり個人に依存するような組織でもモブプロは機能するのでしょうか？
その「組織」が同じ目的のもとで協力してアウトプットを出そうとしているチームであるならば、いまでもなにかしらの方法を使って個々人が協力して仕事をしているはずですよね。
属人化している専門性を知識移転をしたい、あるいはお互いに専門領域の理解を深めたいなどであればモブプログラミングしてみる価値はありそうです。
日本語ネイティブではない方がいる場合に有効な工夫とかありますでしょうか？
そういう場面でモブプログラミングをした経験がないのでよい回答ができなくてすみません。
使用する言語がズレているチームで働いたことはあるので想像ではありますが、モブプログラミングをする際に使用する言語は最初に決めておいた方がよいだろうと思いました。
その前提であれば、言語に関してもテクニカルスキルと同じように考えて、スキル差があることを念頭においてチームワークを進められる気がします。一方で統一で使える言語がなかったり、あまりにも効率が悪いのであれば、無理にモブプログラミングを選択する必要はないでしょう。
