コードレビュー中にチーム内で以下の話が話題になった。
レビューで仕様のヌケモレや認識違いが見つかり手戻るのどうにかしたい。
チーム内ではテストが足りないとか、
設計書(ドキュメント)を作成していないのが問題では?という話になったんだけど、
何故設計をするのか?というところに着目したほうが良いのでは?と問題提議。
結局、お互いに認識確認するためだよねーとなったので、
その効率化のためにモブプロを提案してみた。
モブプロについて。
詳細は以下を参照のこと。
こちらもオススメ。
チーム内でも以下の点で盛り上がった。
- 仕様や設計を伝言ゲームで伝える必要が無いので効率的に出来る!
- 事前に意思疎通が取れているのでレビュー時に手戻りが起きない!
- そもそも実装しているところを見ているのでレビューがいらない!
そのため、試しに一度やってみようか!ということに。
モブプロに対する事前に指摘された問題
やる前に問題になったのはやはり効率が悪いのではないか問題。
- 単純に3人でバラバラに作業したほうが生産性が高いのでは?
3人で1時間やると工数的には3時間になる 3時間分の価値があるのか? - 我々のチームは知識量に偏りがあるので教育ばかりで先に進まないのでは?
これに対しては以下のように説明した。
単純に3人でバラバラに作業したほうが生産性が高いのでは?
事前の仕様説明やレビュー時の手戻りを含めて考えると一概にそうは言えない。
そもそも今だってタスクの見積もりも実績も取っていないので、
いまの効率が良いか悪いかも判断できないし、モブプロとも比較できないのでは?
我々のチームは知識量に偏りがあるので教育ばかりで先に進まないのでは?
確かにアウトプットするソースの量で言えばそのとおりかもしれない。
が、いまのチーム内では特定の領域をワンオペしている人がいるので、
その知識が共有されるメリットも考えると全体で見るとプラスだと思う。
特にいまのトラックナンバー1問題は本当にマズイと思う。
(その人が辞めたらどうするんだ…)
上記のような会話をしてそれなら一度やってみて考えようかーとなった。
ここで特に念押ししたのは合わないなら止めようとチームで合意したこと。
ストレス溜めてまでやる必要はないと確認した。
新しい事を導入する時は導入時も大事だけど、
止める条件も確認しておくことが大事だと思う。
また、それを確認するタイミングも予め定義しておくと良いと思う。
今回はモブプロの終わりに感想を聞くことにした。
実際にやってみた感想はまた別の記事で。
投稿日時点ではまだ2回しかやれてないが、
好評な部分も課題も両方ある感じ。
個人的には一度やってみることをオススメする。
ググれば結構やってみた!系の記事が多いので読んでみることを推奨する
何が良いって、やっている人たちが皆楽しそうなのが本当に良いと思う。
