（なんちゃって）モブ・プログラミング（もどき）を何回か実践しての気づき

このブログをご覧のみなさん、こんにちは。

モブ・プログラミングとは？

（なんちゃって）モブ・プログラミング（もどき）でスキルを伝授してみたに詳細は記載しています。

環境

以下を 2 回、

人数: 3 名(学生二名、自分)
- 学生一名は自分の知り合い、もう一名は初対面
- 自分の知り合いの学生は以前一緒にペアプロをしたことがあり、ある程度プログラミング能力がある
- もう一名はプログラミングが苦手で、書籍などを“読んで”学んでいる
場所: Starbucks
機器: MacBook Air 一台、大型ディスプレイなし、ホワイトボードなし

以下を 4 回、

人数: 五名(学生 4 名、自分)
- 学生二名は自分の知り合い、もう二名は初対面
- 自分の知り合いの学生は以前一緒にペアプロ、モブプロをしたことがあり、ある程度プログラミング能力がある
- 初対面の二名は片方はプログラミングが苦手、もう片方はプログラミングが得意
場所: Starbucks
機器: MacBook Air 一台、大型ディスプレイなし、ホワイトボードなし

の合計六回実施しました。

やり方

（なんちゃって）モブ・プログラミング（もどき）でスキルを伝授してみたに記載の方法です。

実践した結果の気づき

ペアプロと異なり、人数が奇数でも実施できる
情報共有がし易く、学びも多い
- 以前ペアプロをした時よりも短時間で学生のレベルが向上した(ように見えた)
一人で作業するのに比べて疲労度が高い
- 特にペアプロもしたことがない人は疲労度が高かったので、適切なタイミングで休憩を挟むのが良いと感じた
時間当たりの成果物の品質がよい
- 別途コードレビューや Pull Request でレビューする場合、「いまからそこ修正するの！？」みたいなことが起こるので、そう考えると全員で作り、CI さえ通ればマージして良いというのは時間当たりの成果物の品質は良いなと感じた
メンバー間の関係性によって、問題が浮き彫りになる ← New!!

メンバー間の関係性によって、問題が浮き彫りになる

五人ではじめてモブ・プログラミングをした際にそれは起こりました。

学生の一人が Driver として書いたコードが一見正しいが、考慮漏れによるバグがあるものでした
- それは FizzBuzz で例えると、15 の時に Fizz, Buzz, FizzBuzz と三つ出してしまうような間違いです
そこで Navigator の自分が「そのコードだとこれこれこういう場合にエラーになると思うんだけど、意図を教えてもらえる？」と確認したとこと、「うっさいな、黙ってろよ」というなかなかなお返事を頂戴しました
ここでうまい返しができず、彼はコードを書き切り、次の Driver にバトンタッチする時間になりました
が、誰もバトンタッチしません
- 後でご飯を食べている際に確認したところ、彼以外の全員が彼の書いたコードに問題があると認識していたものの、ピリピリした雰囲気に指摘できなかったとのことでした
この火中の栗を拾うのは自分だけか…と諦めながら Driver になりました
口で言っても通じないので、コードで示すしかないかと彼の書いたコードだとコケるテストコードを書きました。
当然テストがコケるので、「テストコードコケるのでプロダクトコード直しますね」と言ってから直そうとしたら背後から肩を掴まれ「そういう感じ悪いのやめろや」というなかなかなコメントを頂戴しました
ここでもう相手するのが面倒になり、やらなくていい言い訳を考え始めました
- そもそもこれ(=実装しているコード)は彼らの宿題であって自分にとってはバグが存在しても一ミクロンも困らないわけだし、バグってても自分自身は困らないなぁなどなど
と言い訳を考えていたら、肩を掴んでいる学生以外から肩を掴んでいる彼に「相手に失礼なそういう態度やめなよ」と指摘がでてきました。
そして、それを契機に他の学生からもフォローがされます
自分以外の学生三人によるフォローで彼のイライラはおさまったものの、実装については手付かずです
で、結局そのバグの修正だれがやったと思います？
私です

結局、（なんちゃって）モブ・プログラミング（もどき）の後にご飯をみんなで食べて、なんでそんなに突っかかってきたのかは判明しました。上で 4 回実施と書いている通り、わだかまりはなくなり、（なんちゃって）モブ・プログラミング（もどき）を続けている関係ではあります。 ※これはモブ・プログラミングに限った話ではなく、チームでワークする際、すべてに当てはまると思われる問題だなぁと思います。