「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読んで

書籍

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

この本を選んだ理由

  • モビングについて単純に興味がある。
  • 自チームはペアでの作業を行っており、モビングからも良い知見が得られるのでは…と思ったから。

所感

※かっこ書きは本の中の章番号。

良かった点

  • モブプロとペアプロとの違い(1.2)が書いてある。
    • ペアプロだと意見が食い違うと膠着するが、モブプロはチームなので個人を否定された感が少ない。(1.2.1)
      • 今はペアで動いているため意見の対立=個人否定になりかねない。この部分を解消できるのはモブプロの大きな意味に感じる。
    • モブプロはペアより中断しにくい。ペアだと片一方が病気、会議、電話で中断すると作業が止まる。(1.2.2)
      • 休みがちな方とペア組んでいるので分かる...凄くよく分かる…。
    • モブプロ効果測定は難しいので、コンフリクト解決、欠陥数、学習度、チームメンバーの改善効果の所感を利用すると良い。(1.3.2)
      • 確かに効果測定はどうやるのだろうか?と感じていた。モブプロやる前に測っておくべきだなぁ。得られた成功を記録しておくと上長への説明に役立つらしい。ふむふむ。
  • モビングの軌道修正方法がかかれている(4)
    • エキスパートがいる場合のモビングはタイピストではなく、モブのコーチとして知識の穴を埋める形で参加してもらうと良い(4.1.3)
    • 手探りなモビングの場合は、タイムボックスを決めて個人で探求する方法(4.2.3.1)や強いモビング(=進行役を設けアイディアは進行役に委ね、進行役からのみタイピストに依頼する)を使いバラバラの意見をまとめる(4.2.3.2)
    • 些細な仕事のモビングの場合は、無理に皆で同じ仕事をする必要はない。振り返りや体制を整えたりすればよい。(4.3.3)
      • メリハリって大事だなぁ。引き出しとして覚えておきたい。
  • モブプロの核心であるフロー効率について書かれている。(7)
    • フロー効率を表すのに高速道路の例を用いている(7.1.1)
      • 全ての車が一定スピードではないので、どこかで急ブレーキすると後ろ全体に影響を与え、いつ目的地に到着するか予測することが難しい。一方、フロー効率重視だと車間距離に余裕があり、目的地到着の予測がつきやすい。(7.1.1.1)
        • これはなるほどと思った。フロー効率の良さは目的地到着の誤差が少ないという点なのか!
    • 仕事を早く始めることが目標ではなく早く終わらせることが目標。(7.3)
      • ここがモブプロの本質のような気がする。未完成では意味がないことを皆理解すべき。
  • モブプロ実施で漠然と遅くなったと感じるのであればエンドツーエンドで考えてみるとよい。(8.2.1)
    • コードの部分だけみてもしょうがない。もっと広い視点でみれば早くなっている。モビング/ペアリングの効果を聴かれた際はこの点を意識して回答したい。

その他

  • 無駄とは何か?業務全体の効率化を考えていくとモビングという手法に落ち着いたのかなぁと個人的には思った。
  • チーム/組織として働く上で人との繋がりは大事であることを本を読むたびに感じている。