こんにちは。エンジニアの佐々木です。

厳しい冬も終わり、だいぶ暖かくなってきました。クラシコムのオフィスがある国立市大学通りは、桜も満開になりいつもより多くの人で賑わっています。ちょうどオフィスの窓から桜が見えるので、窓の近くにテーブルを寄せてお昼を食べる人もちらほら。花粉がめちゃくちゃつらい季節ではありますが、各々春を楽しんでいます。

さて。僕らエンジニアは最近、タイトルにある通りモブプロを本格的に導入し始めました。この記事では、なぜモブプロを行うことになったか、導入してみて感じたメリット・改善ポイント、どんなときにモブプロを行うべきかについて、社内で得た知見を記載します。

モブプロとは

まずモブプロについて説明しておきます。

モブプロとはモブプログラミングの略称です。「モブ」は群衆という意味で、複数人で同時にプログラミングを行います(人数はだいたい3〜5人が目安らしい)。1台のパソコンをモニターに接続して、1人がドライバーとしてプログラムの編集作業を行い、他のメンバーがナビゲーターとなり、ドライバーや他のメンバーとコミュニケーションをとりながら設計・実装を進めていく方法です。

なぜモブプロを行うようになったか

現在進行しているプロジェクトで、Ruby on Rails で作られたショッピングカートをLaravelで書き直す作業を行っています。(詳しくは Railsで作ったショッピングカートをLaravel+Vueでリライトする理由 に記載)

そしてそのプロジェクトが進んでいる途中で、事件は起きました。

「RailsからLaravelにそっくりそのまま移行するの大変…そもそもの設計も見直したい！どう！？」

という意見が発生。

そこで

「DDD(ドメイン駆動開発)導入してみない？」
「設計はみんなでやらない？」
「じゃあ、モブプロやらない？」

となり、ちゃぶ台をひっくり返すような形でプロジェクトは半分振り出しに戻りました。

この判断が正解だったかどうかは、このプロジェクトが完了したときにわかることですが、今のところモブプロを行ったことで作業効率が下がったような印象もなく、アプリケーションの設計は改善されたと感じています。

進め方

僕らのモブプロの進め方を紹介しておきます。

基本的な流れ

1. これから始める作業の内容を共有
2. フィーチャーブランチを一つ用意し作業開始
3. ドライバーは1〜2時間作業を行う。キリの良いところで交代する
4. 交代のタイミングでgit commit、push。次のドライバーはpullする
5. 交代するとき、だいたい疲れているので10分程度の休憩を挟む
6. 交代するとき、マシンも各々のマシンに替えている。エディタやPCの設定など、ドライバーが作業しやすい状態にするため
7. 上記を繰り返す

その他

まだ細かいルールは作っておらず、進めつつ改善を加えるようにしています。

• 少しでも進捗が出たらみんなで拍手して喜びを分かち合う
• 同時にDDD(ドメイン駆動開発)を取り入れて進めているので、スプリントの最初にドメインモデルの設計をメンバーで行い、設計が完了したタイミングでモブプロを開始している
• Mobster(モブプログラミングをするマシンにMobsterが入ると最高だった)を試す
• 日によってドライバーの順番をじゃんけんで決めたりランダムで決めてくれるプログラムを使う
• 他の細かなタスクも各人が行えるよう、時間は10〜17時に行うこととする(営業時間は9〜18時)

など

モブプロをやってよかったこと

では実際に、モブプロをやってみてどうだったかについて詳しく書いていきます。実際にモブプロをしたメンバーからも意見をもらいまとめた内容になっています。

メリット

• その場で合意ができるため、レビューや共有の時間が省けてよい
• その場で意見を言える、手戻りが少ない
• 設計・実装の意図を深く共有できる
• 共通の認識、ユビキタス言語ができ、その後の作業が効率よくできる
• みんなでやっている感があるので、楽しい
• メンバー間で知見・ドメイン知識を共有できて、勉強になる
• 分からないことがあったとき、ナビゲーターが調べてくれるので、ドライバーはコーディングに集中できる
• チームワークが良くなる
• 特に新規プロジェクトのベースができるまでは、モブプロでやった方が早そう
• 他の人がどんなことを考えてどんな風に開発を進めているのかがわかり勉強になる

他、気づいた点

• 議論の結果を実装に落とし込んだり、分担してコードを書いていくためには、コードでドメインロジックが表現できている、疎結合になっている、変更容易性が高いといった、アーキテクチャや品質が整っていてこそだなと思う。
• なので、「モブプロなら良いコードが書ける」わけではなくて「モブプロできるコードは良いコード」なのではないか
• 各々こだわりがあり、いろんな視点があるというのを実感

モブプロ、ここが難しい！

やってよかったことと同様に、進めていて難しいなと思ったポイントもメンバーに聞いてまとめました。

• 長時間作業は負担が大きい。ドライバーのローテーション回数をもっと増やしたい。
• ドライバーの順番決めと時間計測ルールをもう少し固めたい
• 設計・実装の意図を、その場にいない人にも共有する仕組みを考えた方が良いかも（ドキュメンテーションに関するルールとか）
• 「あとでやる」リストがあると良い
• 大きいホワイトボードがあると良い
• モブプロでやる、やらないの判断基準。スプリント計画に沿って組み込めるようできたらいい
• 今まで1人で行っていた作業を複数人でやるので、ストーリーポイントの見積もりが難しい（どこを基準にしたら良いか分からない）
• モブプロ中はそれ以外の突発的なタスクなどへの対応が遅れがち
• モブプロで着手するタスクの粒度をもう少し細分化してドライバーのローテーションを回したい

これらは少しずつ改善を加えていきたいところです。

どんなときに行うべきか

難しいと思ったポイントの一覧にも記載がありますが、どんなタスクをモブプロでやるべきかの判断基準が僕らの中でまだ完全には定まっていません。ただ、今回改めて振り返ってみると、こんなタスクやこんなタイミングのときにモブプロをすると良いのではないかというのは見えてきました。

モブプロをすることで、お互いの知見・ドメイン知識の共有ができたり、レビューを省けたり、チームワークの向上につながるメリットがあることを踏まえると

• 新規プロジェクトの初期
• 新人エンジニアが複数人加入したとき
• 大きめのユーザーストーリー
• 並行して進めるのが難しいタスクが続いているとき

などがモブプロでやるべきタスクやタイミングなのかなと思っています。スプリント計画時に試行錯誤して組み込もうとしているところなので、トライアンドエラーを繰り返したり、他の事例を参考にするなどして徐々に効果・効率を上げていきたいなと思っています。

まとめ

クラシコムで行っているモブプロについて書いてきました。実際にやってみて、チームビルディングの一環としても機能しているし、技術力やドメイン知識の底上げにもつながっていると感じます。2018年3月から始まった取り組みなので多くの改善ポイントはありますが、継続して取り組んでいきたいと思います。

僕らはまだまだたくさんの仲間を探しています。ペアプロやモブプロをしたことがない方でも、エンジニアとして純粋に良いものを作りたい・開発をしたいという方は、ぜひ一度オフィスに遊びに来てみてください。