モブプログラミングのよくある誤解

ご意見・ご感想をお聞かせください!

このブログ記事はモブプログラミング Advent Calendar 2018 1日目の記事です。

モブプログラミング Advent Calendar 2018 - Qiita
モブプログラミング/モブワークに関するアドベントカレンダー。 - モブプロ/モブワークやってみた - モブプロ/モブワークやってみたい - うちのモブプロ/モブワークはここがすごい! - モブプロでこのブログを書いてみた などなど、やってみたことがあるかないかに関わらず書きたい人はぜひ書きましょう。

また空いてるので「書いてみようかな」って少しでも思った人はぜひ書いてください!

Advent Calendarはやったことあるかないかや、エキスパートであるかどうかに関係なく、この流れに乗ってアウトプットするぜっていう勢いがすべてだと個人的には思っております。せっかくなのでモブで記事を書いてみてはいかがでしょうか(ネタ提供)?

モブプログラミングのよくある誤解

この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。

前提として、「モブプログラミングはすべてにおいて最&高だからやるべきだ!」とは全く思っていません。ですが、SNSなどを見てもネガティブなことを言ってる人のほとんどはやったことがないか中途半端にやって失敗してこじらせてるだけなので、少しでもやってみたいと思う人の助けになればと思って書いてみます。

よくある誤解1 : モブプログラミングは効率が悪い

モブプログラミングって複数人で1つのPCで仕事をするんでしょ?
ペアプログラミングよりもさらに効率が悪いじゃん。生産性下がっちゃうよ。

モブプログラミングにおいては効率云々の話が一番多いです。

なので様々な現場で講演をするたびに、マイナーチェンジしながらこれに答えてきました。なかなかよい資料だと思うので、ぜひ御覧ください(Speakerdeckの資料をこの機に更新しました)

ポイントだけ解説します。

おそらくこの手の話をする際には、前提として(普段やっている=自分が知っている)分担作業と比較して効率が悪いというのだと思います。

まずは主観として、実際に1年半近く自分たちでモブプログラミングをしたり、研修やワークショップなど様々な場面でモブプログラミングをやってきて、効率が悪いと思ったことがありません。効率が悪かったらとっくにやめてます。

大きな誤解の一つとして、多くの方が分担作業とモブワークを二者択一のように考えがちです。私達も1日中モブワークをしていますが、正確には仕事の質や状況に合わせて分担作業とモブワークを切り替えながら仕事をしています。

それぞれに強み・弱みがあるので、その場その場で適切な方を自然と選択しています。分担作業しかできないチームよりも、状況に合わせて適切な仕事のスタイルを選ぶことができるチームの方がチームとして強いのは明らかです。

モブプログラミングから得た学びの中で一番衝撃的だったのは、これまでやってきたことのほとんどは「分担作業を前提としていかにそれをうまくやるか」だった=思考停止していた、というものでした。

ところで、一体「分担=効率がいい」というのはいつからそう思っていたのでしょうか。最近新卒研修に関わった際に、余計な社会経験のない彼らを観察していても、自然と分担作業を始めていたので、学校教育なのかもっと根深いところで我々に染み付いているような気がします。

この他にも様々な視点から効率について考察しているので、ご興味のある方はぜひ資料を御覧ください。

よくある誤解2 : モブプログラミングはエンジニアのプラクティスだ

モブ “プログラミング” だから、エンジニアがやるものですよね。
デザイナーがやる場合はモブ “デザイン” とかになるのかなー?

「チーム」全員で同じ「仕事」をする、なのでエンジニアに限った話ではありません。どのようなチーム、どのような仕事においてもモブプログラミングの利点を活かすことができます。デザイナーだけのチームでモブデザインをすることもできますし、チームの範囲を広げてエンジニアもデザイナーもビジネスオーナーもいるチームでモブプログラミングをすることもできます。

モブプログラミング発祥の地であるHunter Industriesでモブプログラミングを始め広めた、Woody Zuil氏やChris Lucian氏に話を聞いた際、彼らのチームもデザイナーやプロダクトオーナーがモブに出入りしながら仕事を進めているそうです。

私達のチームでもモブプログラミングをよくしていますが、開発作業だけでなく、お客さん向けの資料をつくったり、カスタマーサポート対応をしたり、様々な仕事をモブで取り組んでいます。モブ “プログラミング” という名前ですが、モブ “ワーク” という名前の方が実態には近いです。

少し話は逸れますが、とあるチームが私達の現場に遊びに来て一緒にモブプログラミングをした時に、そのチームのプロダクトオーナーの方が話していたことがとても印象的でした。

「エンジニアはずっと黒い画面に向かってひたすらタイピング(プログラミング)している仕事だと思ったけれど、こんなに人と話したりググったりしながら仕事をするんだって初めて知りました」

彼女と開発チームは長年一緒に仕事をしている仲ですが、エンジニアが実際に仕事をしているところ見るのは初めてだったそうです。

「モブプログラミング体験によって、エンジニアが仕事している姿や働き方を知ることができたので、彼らとのコミュニケーションが変わりそうだ」

という話をしながら彼女は帰っていきました。

このエピソードはチームに限った話ではなく、相手の仕事をわかったふりしているだけで理解していないことがほとんどです。人間の本質としてわからないものにはやさしくできないもので、それは仕事上のコミュニケーションに少なからず影響しているはずです。「一緒に働いてみる」だけでお互いの仕事を少しでも理解できるのであれば安いものだな、と思います。

よくある誤解3 : スキルが低いメンバーがいるからモブプログラミングは難しい

私達のチームでモブプログラミングをやろうとすると、新人が多いチームだからずっと教えてるだけになりそう。だからモブプログラミングは難しいです。

「ずっと教えてるだけ」になっても、チームにとって必要なことであればそういうモブプログラミングをすればいいと思います。

そのようなチーム構成の場合、モブプログラミングをしていなくても経験豊富なメンバーが新人のサポートやフォローアップをしながら仕事を進めているのではないでしょうか。モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。

「ずっと教えてるだけ」が億劫になる気持ちはわかりますが、どのような方法をとるにせよメンバーの教育が必要なチーム状況であればやるしかありません。むしろ一緒にモブプログラミングをすることで、

  • 効率がいい:個別に教えるのではなく、チーム全員にまとめて教えることができる
  • 過程を学べる:結果だけでなく過程を全員で共通体験しながら学ぶことができる
  • タイミングがいい:必要になったタイミングで必要なことを学ぶことができる

というメリットがあります。モブプログラミングの強みの一つは学習効果だと思うので、「存分に活かしてとっとと成長してもらおう」くらいのつもりでまずはやってみるのがよいでしょう。メンバーが成長してくれれば教えてるだけの関係性が変わるので、教える側にとってもメリットがあるはずです。

参考になるかどうかはわかりませんが、

  • チーム全員未経験の技術要素を
  • プロダクトのドメイン知識がいない遊びに来たエンジニアと一緒に
  • プログラミング未経験のビジネスオーナーと一緒に
  • プログラミング未経験の新卒同士で

などの条件下でモブプログラミングをやった経験はあります。同じモブプログラミングでも主とする目的は変わりますが、私はスキルの高い・低いを理由にモブプログラミングが難しいと感じたことはありません。

(難しいと感じた場合、モブプログラミングではなくその人と働くのが難しいのかも・・・)

よくある誤解4 : モブプログラミングをすれば心理的安全になる

心理的安全なチームっていいよね!
モブプログラミングをすれば心理的安全になりそう。

なりません。

前述の通り、モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。ただし、モブプログラミングをすることでコミュニケーション機会が集中するので、チームの状況や関係性がわかりやすく表れます。

チーム内に一緒にいたくない人がいる場合は、モブプログラミングをすることでストレスが一気に貯まります。チーム内に仲が悪い組み合わせがある場合は、モブプログラミングをすることで簡単に喧嘩が始まります。チーム内で声が大きいシニアエンジニアがいる場合は、モブプログラミングをすることでその人ばかり発言してうまく進まなくなります。仲がいいだけで効果的な議論ができないチームの場合は、順調に進んでいるときはいいけれど問題が発生すると立ち止まってしまいます。

チームの関係性や心理的安全はなにかをすればできるものではなく、日々の活動の結果として徐々に蓄積されていくものです。モブプログラミングしたくらいで心理的安全になるくらいなら誰も苦労していないでしょう。そんな甘えは捨てて、チームに向き合いましょう。

というのはバッサリしすぎている気がするので一言だけ。
モブプログラミングをすることで、自分たちが気づいていなかったメンバーやチームの強み・弱みを発見しやすいです。チームビルディングのための情報収集を目的にモブプログラミングを試しにやってみる、というのは手段としてありかなと思います。

まとめ

いかがでしたでしょうか。

よく話に出てくる代表的な誤解について自分の考えを書いてみました。
最初に書いた通り、モブプログラミングが万能だとは思いませんが、自分はモブプログラミングから多くの学びを得ました。その学びを必要な人には惜しみなく渡していきたいと思っています。

ここに出ている以外にももしわからないことなどあれば、

#モブプログラミング悩み相談

をつけてツイートしてくれれば、たまに拾って答えてみます。それ以外にも何かあればダイレクトにご連絡ください。ベストエフォートで対応します。

そして引き続き モブプログラミング Advent Calendar 2018 をお楽しみください!

モブプログラミング Advent Calendar 2018 - Qiita
モブプログラミング/モブワークに関するアドベントカレンダー。 - モブプロ/モブワークやってみた - モブプロ/モブワークやってみたい - うちのモブプロ/モブワークはここがすごい! - モブプロでこのブログを書いてみた などなど、やってみたことがあるかないかに関わらず書きたい人はぜひ書きましょう。

次は @mohirara さんです。
@mohirara さんのステキなモブプロ本はこちら。

モブプロ、やろうぜ! - mohira - BOOTH
## 概要 本書では、ペアプログラミングとモブプログラミング(ペアプロ/モブプロ)を紹介します。 これらはチームでのソフトウェア開発をよりうまく進めるための開発スタイルです。 ペアプロやモブプロというワードを聞いたことがある人は多いと思います。 しかし、実際に試したことがある方や、現場に導入したことがあるという方は少な...

合わせて読みたい

超アジャイルのすゝめ #TechOn東京
Tech-on MeetUp#03「Agile for Developers ~やってみよう!お作法だけじゃないアジャイルレシピ~」で、...
「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という講演をしてきた #CEDEC2018
CEDEC2018で、 @kawaguti と「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という...
明日からできる働き方改革「モブプログラミング」 WHOLE TEAM APPROACH
モブプログラミングについて話す機会があり、これまでの資料をアップデートした(まったく同じ資料では二度と話せない病)。少し大げさに聞こえるかも...
Agile Japan2018基調講演「モブプログラミングと”フロー”の力(Woody Zuill)」を聞いてきた #agilejapan
2018年7月19日に開催されたAgile Japan 2018に参加してきました。Agile Japanは2013年に講演した時ぶりに参加...
スポンサーリンク

ご意見・ご感想をお聞かせください!

フォロー・購読で最新情報をゲット!