日経BPから出版されている「モブプログラミング・ベストプラクティス」を読みました。
現在3名という少人数チームで開発に取り組んでいます。
全員でレビューを実施しているのですが、レビューを実施する中で認識合わせが必要になり、レビューに遅れが出るケースがたびたび発生するようになりました。
認識合わせの負荷を下げるために、モブで設計や実装を行うのはどうかという議論がたびたび出ており、ペアプログラミングを実施する機会が多くなっています。
自分自身、ペアプロする機会はまだ少ないものの、ペアプロを独自の進め方で実施している気がしていて体系的に学べる物はないか探していたところ「モブプログラミング・ベストプラクティス」に出会いました。
「モブプログラミング・ベストプラクティス」を読んで
- レビューや実装を進める中で認識合わせの機会が増えてきた
- チーム内でドメイン知識や実装に対するレベルに開きが出てきた
- タスクが属人化している
という悩みを持っている方にはちょうどよい書籍ではないかと感じています。
この記事は「モブプログラミング・ベストプラクティス」を読んで得たことを紹介することで、この書籍に興味を持っている方の参考になりそうかどうかの判断材料となれば幸いです。
モブプログラミングの進め方を学んだ
「モブプログラミング・ベストプラクティス」を読む前は、モブプログラミングの進め方は以下のような理解でした。
- ドライバーとナビゲーターに分かれる
- ナビゲーターに言われたことをドライバーが実行する
- このときドライバーは自分の考えている実装を施しても良い
- 30分程度でドライバーを交代する
「モブプログラミング・ベストプラクティス」を読んで認識したのは、ペアプログラミングとモブプログラミングがごちゃまぜになっているということでした。
実際のモブプログラミングの進め方は以下の流れ。
- 準備：お膳立て
- モブでひとつの仕事に取り組むことの意義を説明する
- モビングでの役割分担を説明する
- モブが解決する問題の概要を説明する
- タイピストの順番を決める
- タイピストは自分の考えている実装を施してはいけない
- 考えを実装するにはモブに賛同してもらうか、他の人にタイピストを交代してもらう
- 本体：モビングインターバル
- 最初のタイプストにキーボードを渡す
- タイマーを10分にセットして開始する
- モブ全員が協力して問題の解決のために努力する
- 10分経過したら、タイピストは作業を中止して次の人に交代する
- セッション終了の20分前まで、タイマーをセットし直して、インターバルを繰り返す
- しめくくり：経験からの学習
- それまでのセッションを振り返り、うまくいったこと、うまくいかなかったことを挙げ、次回の改善方法を議論する
「モブプログラミング・ベストプラクティス」を読むことで、役割の理解が深まるとともに、モブプログラミングの具体的な進め方を学ぶことができました。
読む前後では進め方の解像度が段違いです。
ここでの紹介は省略しましたが、「モブプログラミング・ベストプラクティス」ではそれぞれのフェーズでかけるべき具体的な時間まで記載されており、行動に落とし込めるところまで紹介されていました。
モブプログラミングで陥る可能性のあるトラブルの対処法を事前に学べた
「モブプログラミング・ベストプラクティス」では、モブプログラミングを実施、定着させていく中で陥りやすい問題についても具体的に紹介されています。
しかも、モブプログラミングに取り組む前、取り組み始めてから、定着後の長期的な視点といった、チームの実情に合わせた問題と解決方法を提示しています。
- 取り組む前において、どのようにステークホルダーに対してチームで1つのタスクに取り組む意義を伝えるかといった始めるにあたって障壁となりそうなことの乗り越え方
- モビングを行うチームメンバーにエキスパートがすでにいる場合・みんなで手探りで進めていく場合それぞれの進め方
- モビングが定着したあとに新メンバーが入ってきたらどのようにフォローしていくか
というように、起こりそうなことを先回りして解説してくれています。
これにより、将来の不安を払拭した状態でモブプログラミングを始められる自信を「モブプログラミング・ベストプラクティス」は与えてくれます。
モブプログラミングの効果の再認識と新たなメリットを得た
著者や訳者はモブプログラミングの経験が豊富な方々です。
我々がモブプログラミングに対して「恐らくこういう効果が得られるだろう」と期待していることが本当にそうなのかどうかを「モブプログラミング・ベストプラクティス」は教えてくれます。
著者らがモブプログラミングから得たものとしては、
- 属人性の排除
- 経験の浅い人々のスキルアップ
- 品質向上
などのメリットを享受したとのこと。
また、モブプログラミングは「フロー効率」を重視する働き方です。
対極は「リソース効率」を重視する働き方。
リソース効率を重視すると、仕事は直前の仕事の影響を受けていつ終わるか予想ができなくなります。
フロー効率を重視すると、リソース効率は下がるが物の流れは早くなり、他のものの影響を受けにくくなる。
結果、終点にいつ着くかの予測ができるようになるそうです。
チーム力の底上げができるという期待している効果が得られることが再認識できた上に、仕事の見通しも立てやすくなるという別なメリットも知ることができました。
モブプログラミングの進め方を整理する
モブプログラミングの進め方を学んだでもお伝えしたように、「モブプログラミング・ベストプラクティス」ではモブプログラミングの具体的な進め方を紹介しています。
紹介した進め方以外にも、具体的なノウハウがたくさん書かれています。
まだまだ頭に入り切っていないノウハウもたくさんあるので、実務を進める中で必要なノウハウを整理してスムーズに進められるようにできればと考えています。
本1冊まるまるモブプログラミングについて書かれているので、まとめるのは大変かもしれません。
インデックスを作成し、困ったときに引き出せるような形でまとめておきたいところです。
この記事では「モブプログラミング・ベストプラクティス」を読んで得た、モブプログラミングの進め方、問題の改善方法などを紹介しました。
モブプログラミングについて、ペアプログラミングと混同していた部分があったことがわかり、改めて読んで良かったと感じています。
非常に具体的に取り組み方が書かれていたので、モブプログラミングを実践できそうです。
経験に基づいた問題に対する対処法も豊富に記載されていたので、困ったときに開くバイブルとしても役立ちそうです。
「モブプログラミング・ベストプラクティス」について、まだまだ紹介できていない部分も多いです。
モブプログラミングをやってみたい、モブプログラミングをやっているけど問題が起こってなかなかうまく進められないという方は、ぜひ一度読んでみてください。
