モブプログラミング Advent Calendar 2019 22日目の記事です 1。
はじめに
大学の研究開発の現場やIT勉強会にモブプログラミングを取り入れたりしています。
取り入れ事例：Tech Meetup with Mob Programming
私の業務の一つに、学生（学部4年生・大学院生）の研究成果を実用化まで進める担当があるのですが、これは例えるならば「未経験の新人」が書いた機能・モジュール・ライブラリなどの成果物を複数・短期間でリリース可能まで持って行くという作業になります。
2018年は、これににモブプログラミングを取り入れましたが、色々な反省点も多く。2年目の今年はどんな工夫をして変化があったか、という振り返りの記事にあります。
1年目の反省
1年目はモブプログラミングの環境（プロジェクター、ホワイトボード、Mobstar、etc...）を用意して、自分の担当する学生プロジェクトでモブプログラミングをスタートしました。詳しくは昨年度のアドベントカレンダーの記事「モブプログラミングの試みと未来への所感 」に記載していますが、まずは環境を整えて、みんなでひとつの課題を達成してみるというスタイルを取り入れた形です。
ここで、
- 一部の開発期間が短縮した
- 開発が始まるまで未定の部分を全員で共有して議論・方針決定できた
- チームメイトのスキルや経験値もふまえて、改善点を確認できた
という利点を実感できたものの、
- モブプログラミングの時間が限られてると大きな成果が現れない
- モブプログラミングの進捗は、参加する各個が進捗を出せる裏付けにはならない
- ドライバーまかせになってしまう・モブに割り込み業務があり集中できない⇒悪循環の定常化
という課題がでてきました。
これらを解決して、モブプログラミングをもう少し根付かせる、というのが2019年の目標になりました。
2年目の工夫と変化
アンチパターン・ベストプラクティスへの気づき
2年目に入るにあたり、すこしモブプログラミングの事例をしっかりと勉強しておこうと思い、いくつか書籍を読んでみました。
- Zuill, W. & Meadows, K.(2016) "Mob Programming A Whole Team Approach"
- マーク・パール (著), 及部敬雄（訳）, 長尾高弘（解説）(2019) "モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める"
とくに後者は日本語で読めるモブプログラミングの指南書としてよく紹介されていますね。
この2冊を読んで気がついたのは モブプログラミングにも細やかなアンチパターン・ベストプラクティスがある ということでした。
それぞれの本の中では、私たちの課題に対する直接的な回答もありましたし、工夫をすれば自分たちの現場のモブプログラミングも、もっと「しっくり」くるかもしれない、そんなエッセンスも学び取れました。
その工夫を実現するために、2019年は モブプログラミングにトレーナー役を作る ことにしました。
モブではなく、トレーナーとして参加する
十分な時間をとったモブプログラミングは成果が見られるが、それ以外では成果が出づらい、各個の作業の進捗につながってないという我々の課題を考えると、つまり、モブプログラミングで共有・フィードバックする機会があった知識・技術的な内容が参加者に定着していない ことを表しているのではと仮定しました。
それはなぜだろう？と考えてみると、自ら課題にあげていた **「タイピストまかせになる・モブに割り込み業務があり集中できない」**がやはり大きな部分ではないかと思いました。
- 全員がモブプログラミングに集中できているか？
- 個々の貢献度に大きな差が出ていないか？
- 共有すべき知識・技術はふり返られているか？
このあたりをうまくアレンジするために、今年は自分の役割を モブの参加者ではなく、モブプログラミングのトレーナー役 として特別な位置づけを設定して、自分たちのモブを変えていこうと思いました。
自分がトレーナーとして動くために、以下の点に意識しました。
1. タイピスト・モブとは（できるだけ）別のテーブル・イスに座る
スペースの許す限り、タイピストとモブのいるテーブルから一歩離れた席に座りました。これだけで、タイピスト・モブとも別の人という区分けが気軽にできる気がします。
また、自分はトレーナー役として参加するので、変則的な対応をする旨も、最初に付け加えてモブを開始しました。
2. モブの状態を見て、助言する
タイピスト・モブとしての役割は基本的に参加者だけに任せて、自分はその進行を助けたり、モブプログラミングとしてはこうした方が良い、という助言を積極的に行うようにしました。
例えば、だれかの提案がモブの中で合意がとれていない（納得できていない人、分かってないけど質問できないでいる人がいそう）な雰囲気であれば、タイピストを止めて確認 を促しました。また、議論が煮詰まってしまったときには休憩を、予定の終了時間がギリギリになってきたときは振り返りや、次回までの各自の作業内容の確認などを促しました 2。
結果的に今年は複数のチームのモブプログラミングにトレーナー役として入ったのですが、ほぼ共通して助言することがあった内容は以下のような項目です。先に紹介した書籍に書かれている内容も取り入れています。
1. **内職はしない。**モブプログラミング中の内容に関わるメモや簡易の検索は良いが、関係のない仕事や、関係があっても時間がかかるものはルールを定めて別に行う。
2. **分からない・確認しておきたいことは残さない。**どんな質問・確認であっても容認して受け止め、全員の不明点を解消する。
3. 全体のOKがないまま操作やコード化しない。（たとえ教員や先輩からの提案であっても）特定の誰かの意見や指示だけで進めない。
4. **（特にタイピスト）自分の想像や知識だけで進めない。**モブのゴーサインを待つ。提案があるのならモブと交代する。
5. **（当たり前だけど一応）攻撃や差別、ハラスメントをしない。**どんなときも相手を傾聴し、チームの力になることが大切。意見の衝突や感情的になりそうな時は休憩を促す。
6. **時間や順番を守らずに進めない。**タイピストとモブの交代タイミングはもちろん、全体の時間にも気をつける。仮に時間をオーバーしても振り返りを犠牲にしない。
3. たまにはモブのひとりに戻る
実際には参加者は学生、自分は（学生かられば）テックリードという元々の立場はあるので、参加者だけでは技術的な解決が難しそうな場面に出くわした場合は、モブに戻って技術的な提案をしました。
ただし「タイピストはやらない」を徹底しました。トレーナーがタイピストまでやってしまうと、せっかく明示したトレーナーという特別な役割が薄まってしまうと考えました。 3
4. メンバーに流動性を取り入れる
いままでは、固定のメンバーだけでモブプログラミングをやっていたのですが、興味のありそうなメンバーには声をかけて、試しに参加してもらう機会を積極的に作りました。例えば、別のプロジェクトのメンバーにも入ってもらうとか。基本的には大学院生と学部4年生のチームだけど、学部2, 3年生も興味がありそうだと誘ってみるとか。
さらに、この「試しに参加してもらう」を良い機会として、上記の助言をモブプログラミングの参加者全体に改めて周知したり、他のグループであった良かった・良くなかったムーブを周知したり といったことを兼ねました。
5. 振り返りを評価する
モブプログラミングの終了時間間際に振り返りを行うことを意識付け、また振り返りの内容についても少し深くなるように助言をしました。例えば、ゴールをどのくらい達成したか。次回はいつやるのか。次回までの各個の宿題は決まっているか。
良いモブプログラミングの終盤は本当に疲れていて、一息つきたい気持ちも全員が高まっていますが、あやふやにならないよう踏ん張る係をトレーナーがやりました。
変わってきたこと
トレーナー役として動いて一年間、以前よりも良くなってきたことが増えました。
- モブプログラミング以外の個人作業でも、具体的な開発の進捗がみられるようになってきた
- メンバーから「○○について/○○の部分はモブプログラミングで進めたい」と要望がくるようになった
- モブプログラミングを行えるチームや人が増えた
各個の開発の進捗は、1年目よりも目に見えて良くなってきました。モブプログラミングの中でできるだけ不安や不明な所、別の意見をもったままに成っている人が少なくなるように確認したり、モブプログラミング間の各個の課題・タスクをふり返りで具体化した部分がポイントで、モブプログラミングの中で新しく出てきた知識・技術の共有・フィードバックの取りこぼしが少なくなってきている現れかなと思います。
メンバーが主体的に「モブプログラミングをやりたい」と要望することが増えました。個人の作業になってしまうとどうしても個人でなんとかしなければ、という気持ちも生まれがちですが、一緒のプロジェクトの中で頼り・頼られ・教え・教わることが自由にできる雰囲気がでてきているようです。
モブプログラミングを行えるチームや人が増えてきたのも大きな喜びです。昨年までは私が直轄して（かつ、私が呼びかけて）モブプログラミングをやっているプロジェクトだけしかありませんでしたが、現在、私が全く参加していない（けれどもモブプログラミングとして進んでいる）プロジェクト も出てきました。ことあるごとに「モブプログラミングはいいぞ」と周知しているのもありますが、試しにモブに参加してみたメンバーが、新しいモブチームを作って進めているのを見ると、さらなるモブプログラミングの可能性を感じずにはいられません。
終わりに
今回は、 助言を主体とするトレーナー役を作る、変則的なモブプログラミングチーム を作ることで、昨年度までの課題を予防し、新たなモブプログラミングの広がりにつながる事例が見えてきました。
とはいえ、トレーナー役が今のところ誰でもできる状態ではなかったり、気を抜くとやはりアンチパターンが再発してしまったり、ということも実際には起こっています。
助言の内容をもう少しうまくまとめたり、モブプログラミングを行う上での手順をラップするような何かを作ってあげることで、いろんな場面に共用できそうなノウハウ化もできそうな気がするので、引き続き「モブプログラミングのよさを発揮するにはどうすればよいか」に取り組んでいきたいなと思う次第です。