本記事は、ハンズラボ Advent Calendar 2019 - Qiitaの21日目の記事です。
昨日は、@jxxpsameさんのFace++のDetect APIを使って女装コンテストを採点してみたでした！
はじめに
最近テストをせずに虫歯になってしまった@jnuankです。
みなさんモブプロは好きですか。
私は、好きです。
モブプロのみならず、モブワークと呼ばれる、みんなで一つのことをやり遂げるって感覚がとても好きです。
（そういう感覚なので、読書会とかABD会とかもちょいちょいやってたりします）
とはいえ、現場では導入してない状態だったのですが、
とあるきっかけで、今回チームでやっていた改修案件でモブプロを導入しました。
導入のきっかけから、実践してみた時のうまくいったいかなかったの知見を書いていきたいなと思っております。
導入のきっかけ
タイトルから察せられるとは思いますが、
私のチームメンバーが一人、来月いっぱいで退職するという話がきっかけでした。（9月当時）
その時のチームの状況
退職予定のメンバーを仮にAさんとすると、
- 現在改修中のシステムがある
- その時点でAさんしか把握していないコードベースがあった。
- 最近新メンバーがJoinしてきたばかりで、そのメンバーの教育も込みでスケジュールを立てないといけない
- スケジュールを引いても、Aさんが在籍中にシステム改修終えられる予定にはならない
- 加えて、引き継ぎ資料を作って貰う時間も、そこに入れていくと余計に足りない
いろいろと考えた結果、モブプロで知識を寄せ合って解決しようということになりました。
今回の改修案件の特徴
- 修正対象のプログラムが重複している
- 同時に改修は難しい。というか事故りそう。
- 一個一個の修正自体は、0.25人日と少ない
- 修正、テスト、レビューと分担してやると情報の同期の方に時間を使いそう
- 改修と言いつつ、10年来の闇が肥大化したコードベースのため、調査の方に時間が掛かりそうだった
今回のチームとしての課題
- システムの知見をAさんから、他のメンバーへちゃんとトランスファーしたい
- 新しくJoinしたメンバーに対して、自動テストの重要さを知ってもらいたい
- 自動テストをやったことがなかったので
モブプロ導入することにより期待した効果
- ドキュメントやコードだけでは伝わらない暗黙知の共有
- 一緒に仕事するので、実装過程から共有ができる為
- レビュープロセスの廃止
- 一緒に仕事を進める為、その場でレビューができる
- どうしてそのコードを書いたのか理由を訊かなくて良い
- 情報同期（ミーティングなど）を削減
導入をする前に、メンバーへの説得
いきなりやるぞ！ と言っても、Aさん含めてモブプロ自体はメンバーみんな初心者（かくいう私も現場に取り入れるのは初）。
まずは上記に書いたような案件の特徴とチームの課題、そしてモブプロで期待できる効果を、簡単なスライドにまとめて説明をしました。
加えて、@TAKAKING22さんのモブプログラミングスタートアップマニュアルも併用して説明。
反対されるかと思いましたが、意外とすんなりOKを貰えました。
（後から聞きましたが、やはり効果に関して半信半疑だったそうです）
やったこと
とりあえず午後の半日を使って、モブプロを2週間続けました。
2週間という期間を決めたのは、良くなかった場合は、そこで区切りとして止めるタイミングになるからです。
どんなプラクティスの導入でも期間を決め、効果を測定して、そこでチームとして続ける(&カイゼン)or止めるかを判断するタイミングは重要だと思いました。
もう一つ重要だったのは、モブプロ終了後のふりかえりとしてYWTを使ったことです。
このときにモブプロ自体、やってみてどうだった？ という感触をメンバーたちに聞いたり、
今日コード改修やってみて、この辺りが分かった分からなかった、じゃあ次に何をやっていこうなどの話をしていきました。
ふりかえり手法として、チームは週次でKPTをやっていたので、今回のモブプロふりかえりもKPTで良いかと思いましたが、チームが新しい取り組み（経験）をして、その効果を測定するという観点でいくと、YWTの方が積極的に意見が出しやすいなという狙いがあったためです（この狙いは、成功したと思っています）
結果
実際にやってみて、うまくいったこと、いかなかったことを書いていきます。
うまくいったこと
- 開発・テスト・レビューと役割分担した場合のスケジュールと比べ、３人日ほど巻けた
- 開発とレビューがその場で同時に終わるのが大きい
- 一見、ぐちゃぐちゃで「うっ…」ってなるようなコードでも、全員で紐解いていこうとするので、パワーが出る
- 「とりあえず見よう」と誰かが言ってGoGoって感じの雰囲気になる
- コードからではわからない、あるメンバーしかしらない暗黙知を共有することができた
- 「これってどういう意味？」「あー、それはですねー…」という会話が頻繁にあったので、暗黙知を引きずり出せた感覚はある
- 情報同期のためのミーティングは削減された。
- 週次ミーティングとかは形的にはやるけど、45分とかかからず、10分くらいで終わる。（みんな一緒に仕事しているので）
うまくいかなかったこと
- こちらは、2週間の測定後に続けていった時の話にはなりますが、最初は巻いていたスケジュールも、だんだんAさんから知識を共有することを重視するようになり、進みが遅くなっていったこと
- モブプロベストプラクティスで述べられている、デイケアモブと呼ばれる現象だと思われる
- これに関しては、納期・知識共有・品質などのトレードオフスライダーをホワイトボードで書いて、いまチームで何を重要視するのか、というのを可視化し、チーム内で認識を合わせていった
- 結果的には、リリース納期はそこまで押していなかったので、「知識共有」を重視するようにした
チーム全体としての気付き
- 最初は半信半疑だったが、1日やってみて効果を実感
- ホワイトボードで思考整理&図解説明できるのが良い
- 絶えずコミュニケーションするので、相当疲れる
- その分、開発効率は高いと感じている
モブプロ自体より、その後の副次的な効果が大きかった
始めるまでは、メンバーはモブプロの効果自体には半信半疑でした。
ただやってみると、その効果を実感して、他でも応用するようになってきました。
たとえば、リリースのときや他でのバグ調査の時でも、ホワイトボードを引っ張り出してきて、みんなで1つの端末に集まり、モブリリース、モブバグ修正なんてのが自然にやるようになっていました（特にAさん）。
ふりかえりやホワイトボードの効果も良かったと実感しており、「じゃあふりかえりやりましょうか」「ホワイトボード使って説明しましょうか」なんていう意見がわずか2週間くらいで出てきたのが、とても良かったと思っています。
また、うちのチームが大々的にモブプロをやるかつ、その効果をSlack上でアピールしたことにより、
オフィスのレイアウト変更時に、モブプロも可能なフリースペースを多めに作ってくれました。
（元々フリースペース増設案はあったと思うけど、3割以上はうちのチームがその案を後押ししていると思う）
まとめ
いまのチームですが、改修案件が終わってから、特にモブプロをやっていません。
あくまでモブプロも道具や開発スタイルの一つだと思っているので、いまの状況ではガッツリ、モブをやるタイミングではないと思っているからです。
これがまたやらなければいけないタイミング（メンバーの異動とか、新規案件開始時の意識合わせとか）になったら、また始まるだろうと思います。
という形で、異動、退職などで、チームメンバーが入れ替わる場合、
知識の共有目的でモブプロをその時だけ導入するのも有りなんじゃないかな、と思っております。
最近取り組んでいるTeam Learning Sessionのこと
ちなみに、モブの代わりというわけではありませんが、
いまのチームではLearning Sessionというものを試しています。
これは、チーム上必要な仕事（仕事で必要なツール、言語、FW、運用のTIPSなど）をモブ形式で教え合うチームの勉強会のやり方です。
下記のブログで紹介されていたのを見て、いまゆるく試している最中です。
仕事をよりクリエイティブにするための「Learning Session」ノススメ - LINE ENGINEERING
これに関しての所感は、またどっかで書けたらいいなーと思っております。
参考にしたもの
モブプログラミングスタートアップマニュアル
モブプログラミング・ベストプラクティス
KPTとYWTの違いは？～KPTがうまくいかない理由と、YWTの特性を考える - Qiita
仕事をよりクリエイティブにするための「Learning Session」ノススメ - LINE ENGINEERING
明日のハンズラボ Advent Calendar 2019 22日目は @t-nmr さんです