この記事で伝えたいこと
モブプログラミングの良書「モブプログラミング・ベストプラクティス」を読んでみました。どんなところが参考になったか、どんなところに疑問を感じているかなどをメモしたので、みなさんがモブプロをやる時の一助になればと思います。
はじめに
ペアプロ・モブプロをちゃんとやってみたいなと最近感じていて、なにか体系化されている情報があれば先に勉強しておきたいと思い、まとまっている本がないか探してみました。
最初はペアプロから調べてみたのですが、ペアプロに関する本っていうのが本当に見つからなくて、モブプロというテーマで評価の高いこの書籍を買って読んでみることにしました。
今までの自分のペアプロ・モブプロ経験
「ペアプロをする」「モブプロをする」という意識で取り組んだことは、今までありませんでした。PRを出す前にちょっと不安なことがあったら対面で確認してもらったり、必要に応じて同じコードを見て同期的に確認することはあり、それが結果として「ペアプロっぽくなってる」くらいです。
印象に残った箇所
リソース効率とフロー効率
モブプログラミングの考え方は、本質的にフロー重視であり、機能を安く作るのではなく、早く完成させることを目標としている。言い換えれば、リソース効率ではなくフロー効率を上げようという考え方だ。
リソース効率というのは各リソース(ここでは人)の稼働率や利用率を最大化する考え方で、どれだけ人が効率よく働けているかを重視します。
一方、フロー効率は実際に価値を生み出すまでのリードタイムを早くする考え方です。
モブプロをすると、「3人でやると効率が悪いんじゃないの？」という疑問が(主に管理職から)挙げられるのではないでしょうか。1人でやることをわざわざ3人で取り組むことになるので、当然の疑問だと思います。実際、リソース効率の観点では効率が下がります。
しかし、フロー効率を上げる方法としてはモブプロはいくつかの面で大きな効果があります。
例えば、属人性を減らすことができます。並行して作業すると各タスクは基本的に担当した人がコードやタスクの内容を把握していますが、モブプロで仕事を進めることで個人への依存を減らすことができます。これは特に、重要度や影響範囲の大きいタスクでメリットを感じやすいと思います。
また、チームメンバーがお互いのアイデアや知見を頻繁に共有できるようになり技術力の底上げやスキルアップにも繋がります。
他にも、レビューの効率が上がったり、品質が向上するというメリットもあります。3人分のリソースを割くという点で非効率な部分はあると思いますが、全員で認識を揃えながら開発を進めることで、将来的な開発の速さにつながったり、アイデアを共有することで得られるスピード感は体感できると思います。
モビングを実験として位置付ける
初めてモブプログラミングをしてみようというときには、実験として位置付けることが大切だ。そういう位置付けだと、期待が高くなりすぎず、参加者も心理的なセーフティネットを張ることができる。
これは直感的にもすごく大事だと思いました。新しい開発手法を導入する時って「こんなメリットがあるから」ってところに熱が入りすぎちゃうこともありますが、上手く噛み合わなかった時に「ダメだったね、やめようか」となってしまいかねません。
正直、新しい取り組みなんて最初はたいてい失敗するので、それを振り返ってカイゼンのサイクルに乗せていくことこそ大事だと思います。上司などを説得する時も「最初は上手くいかないかもしれないけど、こういったメリットがあるので継続的に取り組みたい」という合意をちゃんと取っておくべきかなと感じます。
モブタイマーを用意する
モビングインターバルは、10分間のタイマーをセットして始まる。10分にすると、モブのメンバー全員に数回ずつタイピストの版が回ってくるのでモブセッションが上手く回る。
話は飛びますが、モブプログラミングをやる時の話です。
少しややこしいのですが、モビングセッションというのが準備やふりかえりを含めたモブプロ全体のことで、実際にプログラミングを行う時間がモビングインターバルです。
タイマーで時間を測って交換するのはすごく良いなと思いました。時間の制限がないと交換のタイミングも難しいですし、短い時間で区切ることで、集中力も保てるようになる気がします。
ただ、10分っていうのは少し短すぎる印象もあるので、タスクの難易度や内容によって15分や20分くらいでもいいんじゃないかと感じています。大事なのは時間で区切ることかなと。
経験からの学習
セッションの最後の20分は、モビングを締めくくるためのレトロスペクティブ(反省会)に充てる。ここでは、モビングに参加したメンバーが感じたことを述べ合い、次回に軌道修正すべきこと提案する。
モブプロの一連の流れにふりかえりを入れるという発想がなかったので、少し驚きつつも非常に効果的ではないかと思います。モブプロに慣れていないチームだと細かいところで詰まったり上手くいかないことが多いので、ふりかえりがないと「なんか上手くいかないな」「モブプロってやり方自体が失敗だったかな」と考えてしまい、モブプロやめちゃう例もあるのではないかと思います。
もちろん、モブプロをやること自体が目的ではないのでチームやタスクの進め方に合わないのであれば無理に続ける必要はないと思いますが、やり方を工夫して効果を発揮するケースもあると思うので、最後に意識的に振り返りの時間を設けることは大事だと思います。
スクラムで開発を進めている方だと、スクラムイベントレトロスペクティブがあるのでこういう文化は当たり前だと感じる人も多いかもしれませんが、ふりかえりって意識しないと意外とできないんですよね。忙しい時ほどスキップしがちだと思います。
全体を通しての感想
この本を読んでみて、モブプロでありがちな失敗や、ベースとなる進め方を学ぶことができて非常に大きな学びとなりました。モブプロをこれから始める人にも、やったことがある人にもおすすめできる一冊です。
また、書籍の中で「モブプログラミングを直接の対象とする研究はまだ多くない」とも述べられていて、意識してモブプロに取り組むことは、まだまだメジャーな開発の手法ではない気がしています。大学の研究でモブプロを扱っておけばよかったな、と少しもったいない気持ちも感じています。いやー、当時は関心が全然違っていて仕方なかった。
直感的にもフロー効率を上げるのにモブプロが有効だと感じていて、ここ最近実践をしています。詳しい内容についてLTや記事でそのうち話せる機会を作りたいなと思っているので、よかったらその時も読んでいただけると嬉しいです。