ここ4ヶ月ほど、ほぼ1日中、3人で同じモニタに向かって仕事をする、いわゆるモブプログラミングやモビングと呼ばれるスタイルで仕事をしている。
この中の一人が僕だ。
僕達は常にこの3人で仕事をしているので、その結果がモビングの効果なのかそれともこの3人だからなのかはわからないけど、これまでの経験で感じたことを書いてみたい。また、既に2人は感想を書いているのでそちらと見比べるのも面白いかもしれない。
アイディアが沢山出てくる
何をしたらいいのかさっぱりわからないということがほとんど無くなったし、これ以上できることは無いと思ったときも、何か他にできることが無いか、という「もう一押し」の案が出てくる。自分が何かをうっかり忘れていて、他の誰かが指摘してくれるということも多い。自分が何かを思いついたときは「めっちゃそれいいっすね!」みたいなフィードバックがすぐ返ってくるのも楽しい。
知識の共有
これを知っているのは自分だけという不安から解放された。明日休むからこれお願い、みたいに休みを取るときに引き継ぎをする必要がない。休んだ日にslackを気にする必要もない。休んでいる間に自然に自分の仕事が進んでいる。
ペアとモブ
モビングを一日中していると疲れる。それでも毎日続けられるのは3人だからだと思う。ペアよりひとり多い分Avaliabilityが高い。たまに2人で仕事をすることももあるけどそういう時はより消耗がはげしいので、こまめに休憩を挟むようにしている。
やり方について
モブプロの本によると、1つのマシンを全員で使うのがスタンダードのようだが、僕達はそれぞれの自分のMacBook ProをAirPlayでディスプレイを奪い合いながら使っている。また本によればドライバは操作役に徹するのが基本のようだが、僕達はその辺は気にせずドライバも積極的に意思表示する。
そしてもうひとつの決まりごと
最近、チーム3人でモブワークしているんだけど、なにかを終えたら全員で「やったー\(^o^)/」ってやる文化が本日導入された
— もひゃ (@onjiro_mohyahya) 2019年3月26日
終わったぜー!という気持ちになれるので最高
これは先日Agile Japan 2018(年度) サテライト<札幌>に参加したときに教えてもらったものだ。
モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める
- 作者: マーク・パール,及部敬雄(解説),長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2019/02/23
- メディア: 単行本
- この商品を含むブログを見る
効率はどうなのか
わからない。モブで働くのと3人別々に働くのを単純に比較する方法は(記憶を消し去ってもう一度やる以外は)無いと思う。ただ、もし仮に一人で同じことをやっていたら、そもそも同じゴールに辿り着くことはできないと思う。
チームについて
上手くいっているのは、僕等3人がとてもモビングに向いていたからなのかもしれない。とにかく一緒に仕事をしている2人は経験豊富で、かつHRT(謙虚・尊敬・信頼)を大切にするエンジニアだ。
僕は考えを言葉にするのは上手くないけど、ふわっと「なんか違う」というと「それはこういうことですか?」「たとえばこうだったらどうですか?」などと色々な質問をつかって僕の考えを引き出してくれる。元々の僕の考えとは全然違うものを相手が受けとっていることもあるけど、それがまた新しいアイディアを生んだりもする。そうやって、他人の言葉を借りて自分のアイディアが熟成される瞬間を見るのはとても面白い。
問題に対する理解度を見誤っていないか
プログラミングの仕事は以前と比べて難しくなっているかはわからないが、取り扱う規模が大きくなっている感じはする。自分達で書くコードのだけでなく、ライブラリやフレームワーク、インフラ、ビルドツールなどさまざまな知識が必要とされる。それらを全部理解する必要は無いし、実は10%くらい理解していればそこそこの物は作れるのがいいところなんだけど、思いもよらないところではまってしまうこともある。つまり、未来を予測するのが難しくなってきている。
時々、プログラマーはこういう理解度が低くて未来が予測できない状況の中で物を作ることに慣れすぎて麻痺しているんじゃないかと思うことがある。「だいたいこんな感じでしょ」と。3人でやっていてもやっぱり間違うことはあるけれど、ひとりで不安を抱える時間は無くなった。
課題
モビングしていると結構楽しいし、辛い仕事も前向きで取り組むことができる。これはとてもいいことなんだけど、一方で辛い仕事を受け入れすぎていないか、我慢が効く分、その辛さを生み出している本質的な問題を避けていないかと思うことはある。
なので最近はスコープを広げて、チームの外とも協力しながら問題の本質にせまることを意識して仕事をしている。これを「ラインを押し上げる」と呼んでいる。常に押し上げればいいわけではなくて、例えば目の前で障害が発生している時は原因究明や再発防止よりもまず復旧作業が必要となる。状況に応じて適切なラインコントロールができるようになることがこれからの課題だと思う。