はじめに
2019/2/23に刊行されました、「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」という書籍を読みました。
本稿はおおむね、その内容のうち特に感銘を受けた部分について取り上げ、解説したものです。
帯に「一緒に働くだけで個人とチームが成長する」とありますが、まさにその通りだと感じました。
当書は、モブプロの何が良いのかわからないという方、モブプロをどのように始めれば良いのかわからない方、またモブプロの良さはわからないが上司やメンバーをどうやって説得しようと考えている方にとってもおすすめです
モブプロ、効率下がらないの？
モブプロは簡単に言えば、３人以上のメンバーが一つの画面の前に集まり、一人が実際に操作をし周りの人々（モブ）がなんやかんやと言いながら開発を進めていく手法のことです。
直感では、1/3になるとは言わずとも３人が並行で開発をするより効率が劣るような感じもしますよね。
フロー効率を改善する
エキスパートの生む問題
あるチームでそれぞれの分野におけるエキスパートがいて、各々が独立に開発しているとします。
それぞれのエキスパートはお互いの領域について詳しくありません。
さて、このような時に発生する問題はどのようなものでしょうか？
まず、誰か一人でもいなくなった場合に困った状況になるのは明らかです。
また、特定の分野のタスクが短期間で増えた場合、その分野を他のメンバーでカバーすることができず、結果としてサービスのリードタイムにおけるボトルネックとなります。
いわゆる、属人化が進んでしまった状態ですね
リソース効率とフロー効率
リソース効率
リソースの稼働率が高いことをリソース効率が良いと言います。
換言すれば、チームメンバーみんながそれぞれ仕事を持っていればいるほどリソース効率が良いということです。
フロー効率
サービスのリードタイムが短くなることをフロー効率が良いと言います。
例えば、複数の仕事を並列して進めるより同じ仕事を分担してみんなで進めたほうがフロー効率が良いと言えます。
＊リソース効率をフロー効率については記事「フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ）」がわかりやすいです。興味のある方は、ぜひお読みになってください。
上の例におけるような属人化が進んだチームでは、リソース効率を高めることがは非常に容易いですが、フロー効率を向上させることは難しいです。
それぞれがお互いの分野を知らないので、同じ仕事をみんなでというのが苦手なチームになってしまっているからです。
モブプロはゼネラリストを生む
モブプロは、みんなで一つの作業を進めていくわけですから、色々な場面で行うことで自ずとゼネラリストがたくさん生まれることになります。
ゼネラリストが生まれるということは、もし特定領域においてタスク量が増えた場合カバーを行いやすく、そういった点においてボトルネックを生みづらいチームになるという強みを得ることになります。
他にも、効率が良いと言える要素はたくさん
合意プロセスの省略・改善
みんなで意見を出し合いながら作業を進めているということは、その時点で一定の合意が得られているということになります。
また、評価行程として考えても、品質が向上することは明らかで、不具合などを埋め込む可能性が低くなります。
これはつまり、手戻りという顧客に対する価値を生まない状況に陥る自体を避けやすくなるということです。
ノウハウの共有
特定の分野に関する知識の共有を経てゼネラリストが生まれやすいということは上述いたしましたが、これは特定の分野における知識だけにおける話ではなく、汎用的な知識をメンバーで幅広くシェアし生産性を高めることも可能です。
ショートカットやツールなどに対する知見が得られることはもとより、人それぞれコードの書き進め方や考え方を垣間見ることで得られるものって少なくないですよね。
新人の教育
プロジェクトの先輩がどのように操作していくかを実際にみる時間がたくさん与えられることは、新人の方々に良い影響を及ぼす可能性は高いですし、教育のために何か他の仕事を引き換えとする必要がなくなります。
おわりに
短い記事でしたが、モブプロに対する興味をもつ機会になっていただければ嬉しい限りです。
私個人としては実は完全なる新人で、恥ずかしながらチームという目線で考えを進めていくことがあまりできていませんでしたが、今回当書を読み本当に、そのような目線で考える良い機会となったなぁと感じました。
謝り等ございましたら、ご指摘頂けますと幸いです。
レッツ、モブプロ！