社内勉強会でモブプログラミングをやりました
講師の方 twitter.com
モブプログラミングとは
チーム全員で
- 同じ課題に対して
- 同じ時間に
- 同じ場所で
- 同じマシンを使って
取り組むこと
構成
- ドライバー：実際にコードを書く人
- モブ：3~5人の調べたりあーだこーだ言うナビゲータ
モブプログラミングのいいところ
- Pull Requestのように最終的な結果の共有ではなく、思考過程を共有できる
- みんなでやるのでムダなハマりポイントがなくなる
必要なもの
- ディスプレイ（でかいやつかプロジェクターが好ましい）
- 書く人用のPC
- 調べる人用のPC
- ホワイトボード( 決定事項,TODOなどの情報を残す目的であったほうがよい)
うまくやるコツ
- 最低限のマナーを定義する (煽り、disはダメ)
- 分からない場合は正直に言う
- ドライバーはやろうとしていることを、口に出す（これが一番難しい）
- 適度に休憩を入れる
- 終わったら振り返り (今回はKPT法)
- ファシリテータを置く
ドライバーの交代方式
時間
長所: 均等にドライバーの順番が回ってくる
短所: タスクが途中で回ってくる。スイッチングコストが高くなりがち。タスク
長所: スイッチングコストが低い。高効率。
短所: 切り分け方によっては特定のドライバーに負荷が集中する。
今回
チーム
6名 (ほとんどC#エンジニア)
ドライバーの交代方式
タスク
取り組んだテーマ
始め方
選んだお題
FizzBuzz
3の倍数は"Fizz"
5の倍数は"Buzz"
15の倍数は"FizzBuzz"
それ以外は入力した数値をそのまま出力する一番優しい問題Combined Number
[5, 443, 32]などの数値を並べ替えて一番大きな数を作る問題
入力する数に制限はなく、「5, 51, 553」などのハマり問題にハマった…
進め方
- ホワイトボードを使って議論しながらざっくり作り方を決めてタスクを小さく切り分け
- ドライバーは１つのタスクを消化する。例えば、ArrayをListに変換するメソッドを実装。
- テストコードを書いて、テストを実行する。
- テストが通ったら、次の人が受けるタスクの空実装とテストコードを書いておく。
- 次の人は先の人が残した絶対にコケるテストを実行してテストが通らないことを確認する。
- テストが通るように機能を実装する。 → 4に戻る。
やってみて
とてもエネルギーを使う
一見単純に見えるFizzBuzzですら、全員の合意の上で完成とするのに2時間かかりました。コーディングで起きる対立
varは好きじゃない/いきなりreturnに入れず一度変数に格納してからがいい/その書き方だとメモリが～/1行だったら中括弧つけなくてよくない etc...難しいお題を選ぶとプログラミングに入れない
コミュニケーションをとることも目的の内なので、どうやって実装するかを話あえることは大事。だけど、難しいお題を選んでしまうと延々と議論し続けることに…
→ まずは、簡単な部分だけ抜き出してテストを書こうというアドバイスをいただきましたついでてしまう煽り
「ほぅ…では完璧なコードでも見せてもらいましょうか」といって次のドライバーに交代しないように 笑意識のすり合わせは一緒にやっていても難しい
一緒に議論していたはずなのに、いざ実装となるとズレが生じる。一緒にやっていてこれなのだから、普段からコミュニケーションをとることの重要性…Test Codeって大事 モブプロとは別の話になるが、C#といってもUnityから入った人が多いので、テストコードを書いたことある人がほとんどいなかったのでいい経験になった。
UnityでもTestRunnerとかZenjectとか色々テストができるツールがあるので学んでおきたい…
まとめ
レベル差や異なる思想が入り混じって、わいわいガヤガヤしながらできるモブプロは楽しかっただけではなく、チームメンバーを理解しあう非常に意味ある活動になりました。
