1. はじめに

カラダノートの堀内です。

開発チームでは最近モブプロ（モブプログラミング）をはじめました。その経緯や生の感想などを書こうと思います。モブプロの説明は端折ります。

なぜモブプロを始めたか？

当社ではエンジニアの採用を強化しており、ありがたいことに続々とエンジニアの入社が増えています。 1週間スプリントをベースにPDCAを回していることもあって、チームに入れば業務知識や既存のシステムのキャッチアップなどはうまく回っている実感があります。

一方で、技術面では、「技術のノウハウ共有」に課題を感じていました。

具体的に言うと、

「業務知識面では誰が何に詳しいかの相互理解が進んでいる」けど

「技術知識面では誰が何に詳しいかの相互理解が進んでいない」

という状態です。

そこでモブプロを導入し、「ノウハウの共有」および「この技術はこの人が詳しいという相互理解」を進めようと考えました。特に後者は、「誰が何に詳しいか」がわかっていれば「詳しい人に質問して答えにたどり着くスピードが上がる」点でより重要だと思っています。

「モブプログラミング・ベストプラクティスソフトウェアの品質と生産性をチームで高める」を参考に、まずはきっちり型通りにやるようにしました。

この本がとても参考になるのは、モブプロにもきちんと型、というか 役割とルール がきっちり明確になっている点です。

つまり、モブプロには タイピスト とモブという役割があり、それぞれ どのようなことが求められているか が明確に記載されています。

他にも、取り組むテーマの設定の仕方、モビングセッションとインターバルのタイムテーブルの設定、タイピストの交代ルールなどなど...、とにかく細かいところまで役割とルールが言及されており、この本の通りにやればグダグタにならずに取り組める点がとても良いです。

特に初回の開催で重視したルールは以下の３つです。

そのうえで、作業を開始する前に「このモビングセッションのゴール」を明確に設定しました。本のとおりまずは4人でやってみました。

前提としてメンバーが前向きに取り組んでくれたこともあり、初回のモビングセッションの振り返りで以下の手応えを感じました。

例えば、「開発サーバーののログを確認する」という作業一つとっても、様々なやり方があります。

など。そしてそれらにはメリットとデメリットがあり、内容を精査すれば やり方を標準化できる という次の課題が見えてきます。やり方を標準化できれば、オンボーディングにも役立ちますし、単純に作業効率と品質が安定し、情報共有の際の認識の違いも生まれにくくなります。

また、当初の目的である「この技術（やり方）はこの人が詳しいという相互理解」についても、振り返りでの議論を通して醸成できると感じます。特にツールの使い方などはその典型です。これは「普段自分がやらないやり方でやる」の恩恵でもあります。

モブプロ、本当に書籍どおりにやってみただけですが、とても大きな手応えを感じました。これも書籍どおり、 まずは5回やる を目標に取り組んでいこうと思います。

他にも細かい気づきはたくさんあったのですが、それはまた別の記事で書こうと思います。

それでは。