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

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

（なんちゃって）モブ・プログラミング（もどき）でスキルを伝授してみた参照

環境

以下を 2 回

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

以下を 4 回

  • 人数: 5 名(学生 4 名 A と B と C と D、自分)
    • 学生 2 名は自分の知り合い、もう 2 名は初対面
    • 知り合いの学生は以前一緒にペアプロ、モブプロをしている
    • 初対面の 2 名は片方はプログラミングが苦手、もう片方はプログラミングが得意
  • 場所: Starbucks
  • 機器: MacBook Air 1台、大型ディスプレイなし、ホワイトボードなし

以上、合計六回

やり方

（なんちゃって）モブ・プログラミング（もどき）でスキルを伝授してみた参照

実践した結果の気づき

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

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

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

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

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