今日チームでモブプログラミングを初めてやってみたのだけれど、最高だったのでテンションのままにブログを書く。
きっかけ
ふりかえりでたまたまJoy.Incの話になり、あの会社は全部ペアでやってるらしく、ペアプロしたくなるという話をした。
そうしたら、なんとチームメンバー全員(自分含め3人)がちょうど本を持っており読んでいる、読もうとしているところだった。
メンバー全員ペアプロの経験は殆どないに等しく、全然わからない笑
でも、とにかく試してみようよという話になった。
ただしチームメンバーは3人のためペアが組めない。
そこで、Scrum Gathering で見たモブプログラミングでやってみよう、ということになった。
なお、モブプログラミングについても当然経験はなく、ペアより多い人数の場合はモブと呼ぶ、くらいの理解しか無かった。
どうやったか
- 小さい会議室を半日確保
- 大きいディスプレイをひとつつなぐ
- ドライバーを中央に、ナビゲーター2人が横に付く
- 最初に実装するフィーチャーに対し、全員でタスクだしをする
- ソロでやるとしたら何からやるか、みたいな感じで付箋に書き出す
- 順番に並べて、ドライバーの前に配置する
- ドライバーの順番をじゃんけんで決めて、タスクに取り掛かっていく
- ドライバーは「まず〜します」みたいな感じで発言
- 気になったところあればワイワイガヤガヤ
- 端末は個別のものを使用、ドライバー交代時にディスプレイを繋ぎなおす感じ
- 20分~30分を目処に、キリの良いところで交代
- 交代のタイミングで、
git push
するので、続きからはじめる - 休憩は交代のタイミングで適宜
- 交代のタイミングで、
- プルリクやコミットは相談しつつ
- レビューが同時進行なので、作業内容振り返る感じ
- 皆で最終確認してからmerge
- CIが通ったらハイタッチ(するくらいの気持ちで)
モブプログラミングの風景
どうだったか
楽しい。
緊張感もあったのだけれど、やってみるととても楽しかった。
ただ、チームメンバー間での信頼関係や、敬意の有無がとても大切になるだろうとは感じた。
集中力が高まる。
協力体制になるので、他のことに気を取られる余裕がそもそもない。
完成度が高まる
これはある程度できあがった成果物ではなく、思考過程も踏まえた上で議論できるので、抜け漏れがなかったり、ブラッシュアップがしやすいからかもしれない。
スピードが上がる(かも)
時間的にはどうだったかという話だと、ソロでもできたかもしれないけど、せいぜいプルリクエストを出すところくらいまでだっただろうという肌感。
レビューしてもらって修正、マージまで同じ量終わらせるのは無理だったと思う。
3人というのがいい。
これはたまたまだったけど、3人というのはとてもいいと思う。
2人だと意見の相違があったときに、対立構造っぽくなってしまう。
また3人より多いと、熟練度がないとどうしても濃度が薄まりやすくなるのではないか。
レビューコストが下がり、質は上がる
例えばデータパターンが必要なテストコードなどは、同時進行だとレビューコストがすごく下がる。
どうしてもコードから意図を汲み取るのが難しいものをリアルタイムで一緒にやると理解が早く、アドバイスの質も上がった。
勉強になる。
他の人の作業を見られるのは、興味深いし刺激にもなる。
単純な成果物の質だけではなく、過程を見られるのは大きい。
どこから書くのか?みたいなこともそうだし、なぜそうするのか?というのも聞ける。
端末が別なのも、個々人で使ってるツールとか知られて、かえって良かったと思う。
難易度高いものに効果が高そう。
完成度の話とも連動するけど、試行錯誤の段階から意見や考えがアウトプットされ、協力体制で作れるのは大きい。
課題みたいなもの
遊びが少ない
集中度が高まって生産性は間違いなく上がると思うんだけど、疲労度は大きい。
また、ちょっと気になってることへの寄り道とかもしづらい。
(時にその寄り道が別のどこかで大きな効果を生むことがあるはず)
毎日1日中ずっと、というのは結構辛いだろうな、と思う。
少なくとも今は。
場所の確保
オフィスによるんだろうけど、自分のところでは数時間まとまった単位で場所を確保するのは難しい。
モブプロを実施する頻度を上げたいと思った時に、壁になるかも。
まとめ
モブプログラミング最高だった。みんなやればいいと思うし、積極的に勧めて行きたい。
メンバーも好感触で、とりあえず週一は固定でやろう、やりたいタスクがあったら適宜でやろうという話になってる。
これが正しいやり方かは分からないし、一回やってみただけで何言ってるんだと思われるんだろうけど、それくらい大きな感動があった。
モブプログラミングいいですよモブプロ。
はやくまたやりたい。