先日考えていた、一人でやるか、みんなでやるか、の参考になるかと読んでみた。
- モブプログラミングはフロー効率を重視したアクション
- リソース効率を重視すると、この仕事はこのメンバーにしかできない、というような、ボトルネックが発生しやすい
- スペシャリストになる、というと良いことのように聞こえるけど、この本では「スペシャリストになってしまう」という属人性の高い状態だという捉え方
- 属先生軽減のためのアクション
- モブで向かうべき活動についても分析されている
- 極端にクリエイティブで手探りで進めるような仕事は、全員で手探りになってしまうので、一人でやったほうがよい
- 頭を使わない些末な仕事も、一人でやったほうがよい
- その間の、日常的な普通の業務はモブでおこなって、全員が均等に知識を持つようにする
- モブプログラミングの目的をチームのチーズと合わせるための、上司説得用のテンプレートもある
- 「（ここに人名）はドメインについてのすばらしい知識を持っている。この知識をチーム全体で共有したい。モブプログラミングは、解こうとしている問題の理解を完全なものにしてくれる」
- 始め方
- 短い時間から始めましょう。モブタイムを設けるなど
- 勤務時間が合わなければ、朝と夜の2回設けるなど
- 育児の都合で早めに来たい人もいれば朝が苦手な人もいるので、2回場を設けるのはよさそう
日本語版が出たのが2019年であり、コロナ前に書かれた本で、机のレイアウトなどについても解説されていた。
リモートでのモブプロは、この本では悲願達成みたいな扱いで、いろんなツールの紆余曲折がありついに成し遂げることが出来ました、みたいな感じ。
この本の時代から比べると、Live Shareがあったり、ツール的には進化してきているけど、人々はいまだに「一人とみんな、どっちが好きか」とか言っているわけで、進化したツールをどう使うか？というメンタル面はあまり変わっていないように思う。
個人的に、AかBか、という問いをしているとき、だいたい、その二項対立はおかしい、両方のいいとこどりがいい、という結論になるのだろうな、と思いながら考えているのだけど、実際その通りで、こういった場合に適した性質のもの、という結論、ということだと思う。
