PoohSunny's blog

生きるために食べるのか、食べるために生きるのか。

ウチのチームがモブってるとき

はじめに

このブログは、モブプログラミング Advent Calendar 2018の3日目の記事です。

qiita.com

前日のエントリーは @mohiraさんの、「モブプロで技術書を攻略する!」でした。今日の話はベーシックに、自分の周りのモブプロ事情の話をします。

モブをやるときに悩んだこと

モブプロに可能性を感じて、導入するときにうまくいかなかった理、悩んだことがここまで多々あります。それは、既にTAKAKING22さんが初日のエントリーで言及していたこれにハマっていました。

大きな誤解の一つとして、多くの方が分担作業とモブワークを二者択一のように考えがちです。私達も1日中モブワークをしていますが、正確には仕事の質や状況に合わせて分担作業とモブワークを切り替えながら仕事をしています。

というわけで、ウチのチームでよくモブになってる状況、仕事をまとめてみます。

ウチでよくモブってるとき

障害対応

頻度は少ないですが、一番自然にモブになってます。場合によっては部署や組織を跨いで、壁一面のホワイトボードで状況確認したり、その中で必要に応じてソロワークして同期したり、といったこともします。

手戻りがあったとき

これはここ1年くらいで増えたケース、最初はリーンソフトウェア開発のラインストップを参考にしつつ、手戻り(例えば開発テスト中にバグが見つかった!みたいなとき)に必ず声をかけて集まるようにしていました。それまでは、何かバグが見つかると担当チーム間をそれぞれ引き渡して対応していたのですが、そうすると情報の連携不足や元々の知識・経験の違いなどがあって解決までにかなり時間を要していたのですが、それがググッと縮まりました。今では重大な手戻りなどがあった際に自然にモブになっているような状態になっています。

要件・案件の理解をしているとき

いわゆる要件定義のタイミング、案件を知るときに、全員で説明を聞き、質問をし、議論をします。一人だと観点として落としてしまうようなことをなるべくなくすためこの形です。この後の実際にコードを書いたりテスト設計したりするタイミングでは、ここで同期とった内容を元にソロワークで分担することもあります。

設計してるとき

設計もモブでやります。厳密には設計の場合はチーム全員ではなく、2人以上のユニットを組んで実施して、あとでチーム全員でレビューしたりもします。レビューするなら全員で設計したらいいのでは?と思われるかもしれませんが、ウチのチームでは「モード」を重視してこの形になっています(「設計者モブ」になっている時は気がつかないことも、「レビュアーモブ」になると気づいたりします。この差が「モードの違い」だと捉えています。)

困ったとき

何か自分で困った時、つまづいたとき、相談したい時、ねぇねぇと相談してからのペアプロ、モブプロに発展することがあります。(必ずというわけではない)

まとめに代えて

ここまで、ウチのチームがモブってる時をピックアップしてご紹介しました。

大事だな、と思っているのは、必ずXXしなければいけない、なんてことはないということです。今のやり方うまくいってる、効率的だ、うまくいっていない、非効率だ、というのは実際手を動かしているチームが一番肌で感じられると思います。やっていて違和感がないことを大事にしながら、これからも適材適所でモブっていきたいと思っています。