チーム全員で取り組む！モブ設計の実践 - Link and Motivation Developers' Blog

こんにちは。リンクアンドモチベーションでエンジニアをしています。竹井と申します。PythonとVue.jsを用いて、日々プロダクト開発に取り組んでいます。

先日、私たちはより素早く安定的な開発と価値提供を目指して、プロジェクト初動に”モブ設計”手法を導入しました。その経験を通じて得た気づきを以下にて共有していきたいと思います。

プロジェクト初動におけるモブ設計の活用

背景

従来の開発フローでは、個々のメンバーが設計書の作成や見積もりを行い、それらを相互レビューするという流れをとっていました。しかし、このフローでは設計作業が個人に閉じてしまっていることやレビューを通した修正により手戻りが発生してしまうなどして、作業日数として約1週間の時間が消費されていました。

この消費時間を短縮できないかと考えた結果、私たちはモブ設計を導入することに決めました。

モブ設計の実行方法

モブ設計とは、モブプログラミングと同様に、チーム全員が同じ画面を見ながら設計書を作成する方法です。今回、私たちは以下のような取り組み方でモブ設計を実施しました。

作業日数は1日を確保
モブ設計前の各資料の準備に1日を使用
- 準備では、現状想定しているざっくりの画面遷移図だけ用意
開発に関わる開発者全員（バックエンド、フロントエンド両面）が参加
Google Meetを使用し、リモートで実施
ドライバー（画面共有を行う人）が設計書の作成をリードする
ナビゲーター（資料作成の指示を出す人）が指示やコメントをする
最初に要件定義書、画面遷移図を読み合わせて、その後、各設計書を作成

今回用意した作業日の中では、以下の資料作成を行いました。

設計書の作成
- 画面遷移図の作成
- APIのIF定義
- DB定義
- 画面毎の仕様定義
実装チケットの作成

解消課題と得られた恩恵

では、実際にモブ設計を行ってみてどうだったか。以下に、その結果と気づきを共有します。

1. 作業日数の短縮

シンプルに”早さ”を体感しました。この後項番4. 「不確実性の高い箇所を全員で認識して走り始める」で記述する効果もありますが、作業待ちの時間なども含めて従来1週間程かかっていたプロジェクト初動の設計作業を、今回はわずか2日に短縮することができました。

レビュー依頼のフローが省略され、モブプログラミングのようにスピーディーに作業が進むため、非常に効率的でした。

また、従来は設計後に話し合いを進める中で設計の手戻りが発生することもありましたが、モブ設計では全員が一堂に会して話し合うため、全員で同意をした上で次のフェーズに望めることができ、結果として、その後の手戻りが大幅に減少しました。

2. 副作用の早期発見

次に、"副作用の早期発見"です。従来の設計フローでは、フロントエンドやバックエンドが別々に分断して設計を行なっていたため、各領域からの質問や意見が後から出ることがありましたが、モブ設計では領域問わず全員が同時に会議に参加しているため、その場で意見を出し合うことが可能となりました。

これにより、一部の領域だけで話し合っていたら気づかなかったであろう、設計の副作用を早期発見し、その場で改善案を即判断することができました。

3. 設計 vs チームの構造で取り組める

モブ設計によって、全員で同時に設計に取り組むことで、チーム全体として問題を解決する構造で取り組むことができました。

いままでの方式だと「設計の作成者」と「それを見るレビュー者」という構造が生まれてしまいましたが、全員で目線を合わせて設計に対して取り組むことで、全員が共有認識を持ちながらプロジェクトに立ち向かう構図を作ることができました。

4. 不確実性の高い箇所を全員で認識して走り始める

これまでのプロジェクト進行では、初動時点で完璧な見積もりと設計を完成させ、スケジュールの全体像を明確に把握した上で実装を進めていました。

しかし、この進行方法では、具体的なイメージがまだ形成されていない初期段階での設計議論が空中戦のように長引いてしまい、実装フェーズに入るのが遅れ、全体の進行遅延につながってしまう場合がありました。さらに、実際に実装を進めて、システムを動かす/結合する中で、設計の修正が必要な箇所に気づき、これに伴う手戻りが進捗の遅れを招くケースも発生していました。

そこで、プロジェクトの初動時点で完璧な見積もり・設計を完成させようとすることをやめました。

代わりに、プロジェクト初動の段階では、現段階ではわからない/決められない事柄のような不確実性の高い箇所を全員で明確に認識し合い、その優先度を定めた上で、別途に進行する設計タスクとして明確に切り分けました。

従来の「設計フェーズが全て終了してから実装フェーズに移る」という工程進行をなくし、「不確実性の高い箇所の設計」と「今着手できる実装」を並行で持ちながら走り始められるようにしました。 また、動作するシステムの実装を進めながら具体的なイメージを高めつつ、必要な設計を必要なタイミングで行うことができるようになり、後半で発覚するような設計の手戻りも減少しました。