アカツキでエンジニアリングマネージャをしている島村です。
普段はソーシャルゲームアプリの開発やエンジニア組織への取り組みなどをしています。
さて今回は自分のチームのエンジニアを対象にモブプログラミング（以下モブプロ）のワークショップを開催したのでその取り組みについて紹介させていただきます。
モブプログラミングワークショップ開催について
今回の講師として、日本のモブプロの先導者として著名な及部さん（@TAKAKING22）にお願いしました。
モブプロを知らない方に端的に説明すると、モブプロとは「チーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピュータですること」とのことです。
今回、及部さんにお願いした経緯としては、ゆのん(@yunon_phys)との1on1時にチームのスキルトランスファーがうまく進まないと相談していた時に、「及部さんにモブプロのワークショップでもやってもらう？」と案をもらったのでお願いすることに。
早速Messengerで連絡をとり快諾をいただき、1回の顔合わせとリモートのMTGを得て開催の運びとなりました。
みなさんも気軽に相談してみてはいかがでしょうか。
モブプログラミングの準備
当日までに準備したこと
- メンバーの対象者選定とチーム分け
- ワークショップの課題選定（自販機）
- スプリントプランニングに「モブプロ研修 4時間」を組み込む。
対象者はC++エンジニア10名とRubyエンジニア3名の13名。
これを3チームに分けました。
- C++エンジニア 5名 * 2
- Rubyエンジニア 3名
課題は、言語が違うチームになるので共通で「自販機」としました。
当日の準備
- 机３つと人数分の椅子
- モニター3台
- ホワイトボード３枚
- 人数分の付箋とペン
- お菓子
スケジュールとしては以下の流れで全行程4時間。
- 15:00-15:30 Head Firstモブプログラミング
- 15:30-15:40 ワークショップ準備
- 15:40-16:40 モブプログラミングワークショップ 1
- 16:40-16:50 中間ふりかえり＆質疑応答＆休憩
- 16:50-17:50 モブプログラミングワークショップ 2
- 17:50-18:20 成果共有＆ふりかえり
- 18:20-19:00 現場でのモブプログラミング
及部さんから事前に「初めてモブやると疲れるから研修おわったらそのまま帰れるようにしたほうがいいですよ」とのことで定時の19時に終わるように設定しました。
ワークショップの内容について
及部さんよりモブプロの歴史や事例を交えつつ注意点など説明いただき、その後、課題やワークショップのルールなど進行の説明があり、ワークショップの実施という流れです。
進めるにあたった以下を強く意識して実施してもらいました。
「HRTの原則」はアカツキでも大事にしていることです。
ルールは「テストすること」だけ。
RubyチームもC++チームも普段から単体テストは書いていたのでここは特に抵抗なく進めることができました。
ワークショップのスライドは公開の許可を頂いているのでぜひスライドを参照していただければです。
モブプロ実施
モブプロ中は真剣に話す場面や笑顔で意見を交わす場面など見られました。時折「やったー」という声が聞こえてきます。
普段一緒に仕事しているメンバーなのでチームビルディングが必要のない分スムーズに始められた印象です。
一つのモニターを一人がタイピングして、周りに立ちながらアドバイスする姿は、障害対応しているときの姿に近いですね。一つのタスクを複数人数で取り組むときは自然とこの形になるのですね。
休憩を挟んだ2回のモブプロの時間を終え、お互いのチームの成果を報告し振り返りを実施しました。
以下はあるチームのふりかえり結果です。どのチームも「疲れた」は出ていましね（笑
その後、ふりかえりででた参加者からの疑問や疑念に対するクエスチョン(を、最後の及部さんからのまとめプレゼンでアンサー*1 する形となりました。
開催場所が社内のカフェのあるラウンジで開催したこともあり、他チームのエンジニアがフラッと見に来て興味深そうに見学していきました。そういう所から波及もしてくれるとうれしいですね。
感想
気になったことは「モビングの重要なポイント」として話された以下のところ。
リソース効率とフロー効率に関しては@i2keyさんの以下の資料がわかりやすいですね。
自分たちのプロジェクトを見返すとリソース効率に傾倒しているので改めてチームで話し合ってみるのもおもしろいと思いました。
またOutcomeについては最近よく話されるようになりました。
スクラムで進めているのであればPOとユーザストーリーにより担保されている部分もあるのでしょうけど、スクラムでないチームでも成果物(Output)とそれに関するOutcomeを話すのはとても有効と感じます。先日のRSGT2020でもギルドワークスの中村洋さん(@yohhatu)がその観点からの話もされていました。
speakerdeck.com
暗黙知のくだりもSECIモデルをベースに話されており、価値観としてはスクラムと通じるところがあることがわかります。
今回の悩みであったスキルトランスファーの課題にも効果があることが伺えますし、メンバーからもその点は感触を掴めたという感想がありました。
まとめ
今回、実施前はメンバーからはモブによるワークが非効率に感じていると声がありましたが、最終的には全員ポジティブな結果が返ってきました。
実施した2日後にはモブを試すチームも出てきており、小さな変化は起きている感じがします。
及部さんの資料にもありましたが「モブプログラミングを現場に導入するか どうかは正直どうでもいいことです。 」で「（分担作業とモビングを）仕事の質やチームの状況に合わせて 使い分けられる方がチームとして強い」ということが大事に思います。
分担開発（リソース効率）とモビング（フロー効率）の使い分けを柔軟に選択できるチームは強そう。
本質は、チームが生み出す価値を最大化するために何ができるか、何をすべきかをチームで考える。そのためにシンプルなコミュニケーションの機会を増やし、チームで判断し続けることが重要であることを知ることができました！
最後に
アカツキでは 一緒にハートドリブンな世界を実現するエンジニアや、組織の成長、課題解決に取り組んでくれる仲間を募集しています！
*1: 参考：モブプログラミングのよくある誤解
