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

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

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

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

この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。 前提として、「モブプログラミングはすべてにおいて最＆高だからやるべきだ！」とは全く思っていません。

ですが、SNSなどを見てもネガティブなことを言ってる人のほとんどはやったことがないか中途半端にやって失敗してこじらせてるだけなので、少しでもやってみたいと思う人の助けになればと思って書いてみます。

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

モブプログラミングにおいては効率云々の話が一番多いです。 なので様々な現場で講演をするたびに、マイナーチェンジしながらこれに答えてきました。なかなかよい資料だと思うので、ぜひ御覧ください（Speakerdeckの資料をこの機に更新しました）

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

おそらくこの手の話をする際には、前提として（普段やっている＝自分が知っている）分担作業と比較して効率が悪いというのだと思います。 まずは主観として、実際に1年半近く自分たちでモブプログラミングをしたり、研修やワークショップなど様々な場面でモブプログラミングをやってきて、効率が悪いと思ったことがありません。効率が悪かったらとっくにやめてます。

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

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

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

ところで、一体「分担＝効率がいい」というのはいつからそう思っていたのでしょうか。

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

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

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

「チーム」全員で同じ「仕事」をする、なのでエンジニアに限った話ではありません。

どのようなチーム、どのような仕事においてもモブプログラミングの利点を活かすことができます。デザイナーだけのチームでモブデザインをすることもできますし、チームの範囲を広げてエンジニアもデザイナーもビジネスオーナーもいるチームでモブプログラミングをすることもできます。 モブプログラミング発祥の地であるHunter Industriesでモブプログラミングを始め広めた、Woody Zuil氏やChris Lucian氏に話を聞いた際、彼らのチームもデザイナーやプロダクトオーナーがモブに出入りしながら仕事を進めているそうです。 私達のチームでもモブプログラミングをよくしていますが、開発作業だけでなく、お客さん向けの資料をつくったり、カスタマーサポート対応をしたり、様々な仕事をモブで取り組んでいます。モブ “プログラミング” という名前ですが、モブ “ワーク” という名前の方が実態には近いです。 少し話は逸れますが、とあるチームが私達の現場に遊びに来て一緒にモブプログラミングをした時に、そのチームのプロダクトオーナーの方が話していたことがとても印象的でした。 「エンジニアはずっと黒い画面に向かってひたすらタイピング（プログラミング）している仕事だと思ったけれど、こんなに人と話したりググったりしながら仕事をするんだって初めて知りました」 彼女と開発チームは長年一緒に仕事をしている仲ですが、エンジニアが実際に仕事をしているところ見るのは初めてだったそうです。 「モブプログラミング体験によって、エンジニアが仕事している姿や働き方を知ることができたので、彼らとのコミュニケーションが変わりそうだ」 という話をしながら彼女は帰っていきました。 このエピソードはチームに限った話ではなく、相手の仕事をわかったふりしているだけで理解していないことがほとんどです。人間の本質としてわからないものにはやさしくできないもので、それは仕事上のコミュニケーションに少なからず影響しているはずです。「一緒に働いてみる」だけでお互いの仕事を少しでも理解できるのであれば安いものだな、と思います。

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

「ずっと教えてるだけ」になっても、チームにとって必要なことであればそういうモブプログラミングをすればいいと思います。 そのようなチーム構成の場合、モブプログラミングをしていなくても経験豊富なメンバーが新人のサポートやフォローアップをしながら仕事を進めているのではないでしょうか。モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。 「ずっと教えてるだけ」が億劫になる気持ちはわかりますが、どのような方法をとるにせよメンバーの教育が必要なチーム状況であればやるしかありません。むしろ一緒にモブプログラミングをすることで、

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

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

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

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

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

なりません。 前述の通り、モブプログラミングをするからといってチームの状況や関係性が変わるわけではありません。ただし、モブプログラミングをすることでコミュニケーション機会が集中するので、チームの状況や関係性がわかりやすく表れます。 チーム内に一緒にいたくない人がいる場合は、モブプログラミングをすることでストレスが一気に貯まります。チーム内に仲が悪い組み合わせがある場合は、モブプログラミングをすることで簡単に喧嘩が始まります。チーム内で声が大きいシニアエンジニアがいる場合は、モブプログラミングをすることでその人ばかり発言してうまく進まなくなります。仲がいいだけで効果的な議論ができないチームの場合は、順調に進んでいるときはいいけれど問題が発生すると立ち止まってしまいます。 チームの関係性や心理的安全はなにかをすればできるものではなく、日々の活動の結果として徐々に蓄積されていくものです。モブプログラミングしたくらいで心理的安全になるくらいなら誰も苦労していないでしょう。そんな甘えは捨てて、チームに向き合いましょう。 というのはバッサリしすぎている気がするので一言だけ。 モブプログラミングをすることで、自分たちが気づいていなかったメンバーやチームの強み・弱みを発見しやすいです。チームビルディングのための情報収集を目的にモブプログラミングを試しにやってみる、というのは手段としてありかなと思います。

まとめ

いかがでしたでしょうか。 よく話に出てくる代表的な誤解について自分の考えを書いてみました。 最初に書いた通り、モブプログラミングが万能だとは思いませんが、自分はモブプログラミングから多くの学びを得ました。その学びを必要な人には惜しみなく渡していきたいと思っています。 ここに出ている以外にももしわからないことなどあれば、 #モブプログラミング悩み相談 をつけてツイートしてくれれば、たまに拾って答えてみます。それ以外にも何かあればダイレクトにご連絡ください。ベストエフォートで対応します。

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

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