状況設定

モブプロをやる動機は開発チームによってそれぞれだと思いますが、この記事では私の経験ベースで以下の前提で話を進めます。

モブプロ導入前の課題
- チームメンバーの業務知識やバックグラウンドに結構差がある状態
- それぞれが別々のタスクを進めておりレビューコストが高い
- タスクの技術的難易度が高く見積もりの精度が悪い
モブプロの目的・期待
- 業務知識の属人化排除
- レビューコストの削減
- 設計段階でのリスク洗い出しによる見積もり精度の向上
モブプロの進め方
- チームが取り組む開発はすべてモブプロ化
- 分散開発やらない
- チームはプロダクトオーナーの決めた施策を優先度順に開発していく

モブプロによって起こった変化

チーム全員の知識がひとつの課題に集中するため設計や実装の議論がとても活発になった
その結果施策のあいまいさや矛盾点などの指摘がたくさん出るようになった
- とくにそもそもの施策の仮説の立て方や、リリース後の仮説検証の方法、KPI設定の観点についての指摘が多かった
これまでより数字という文脈で施策を考える観点がチーム内に生まれてきた
指摘をチェックリスト化してグルーミングやプランニング時点で精査することで施策自体のクオリティが向上した
手戻りによるリリース遅延や仮説の甘さからくる施策自体の失敗が減った

施策のあいまいさや矛盾点などの指摘をどうフィードバックしてもらったか

私の場合、施策は以下のようなフォーマットで書くことが多いです。

ユーザーストーリー
- 誰々として何々ができる。それは何のためだ。
ビジネス価値
背景となる課題・仮説
受け入れ条件
プラットフォーム
- ウェブ（PC）
- ウェブ（スマホ）
- スマホアプリ
デザイン
KPI（検証クエリと目標値）
リスク
ステークホルダー

チームが開発に入る前にこれらをまとめたものを順に説明し矛盾点がないかをチェックしてもらいます。

当初は実際に開発に入ってから施策の問題点に気づくケースが多かったため、ふりかえりなどでその問題点の観点をリスト化していきました。

その結果できあがったチェックリストが以下になります。

# プランニングに進む前にチェックすることリスト

- [ ] その施策、目的と手段合ってる？
- [ ] 受け入れ基準を明確にする（絶対実装するライン、プランニング結果や実装途中でやらない判断ができるライン）
- [ ] KPIの計測方法が明確になっている
- [ ] 技術検証が必要か？（パフォーマンス懸念、新技術利用、構造的なリファクタリングなど）
- [ ] UIデザインをレビューは必要か？
- [ ] ユビキタス言語を決める（日本語）
- [ ] そのストーリー、見積り可能になってる？
- [ ] プランニング前までにやっておくことのSMARTなアクションを決める

この観点で施策をチェックすることであいまいさや矛盾を取り除くことができ、精度を向上させることができました。

モブチームとプロダクトオーナーの接点

プランニング前のチェックの取り組みによってチームが施策そのものについて深く考えるようになると、次やる施策のクオリティが低かった場合グルーミングでメンバーから詰められるという事態が発生します笑

プロダクトオーナーとしてはなかなかプレッシャーのかかる状態にはなるのですが、正しい指摘は素直に受け入れ、間違った指摘はプロダクトオーナーの考えをしっかり伝えるというコミュニケーションがとても重要になります。

また、メンバーは数字の組み立て方まで指摘をするのでKPIを主体的にとらえることができるようになるというメリットがあります。定期的なKPI確認のイベントではプロダクトオーナーの説明がよりチームに理解してもらえる状態をつくることができます。

チーム全体として施策そのものへの関心が高まるので施策のブラッシュアップのアイデアなどの提案をもらえる機会も増えます。

開発の最中でも、モブプロの場合はつねに会話しながら開発を進めるのでプロダクトオーナーが近くに座っていれば状況を把握しながら進めることができ、チームもわからないところが出てきたときにすぐプロダクトオーナーに聞くことができるので分散しての開発よりかなり効率がいいと考えています。

モブプロはグロースハック系の施策に向いている

モブプロの事例を見ていると新規開発やプロトタイピングでやってみたという話が多いように思いますが、個人的にはすでに運用しているサービスの数字をグロースハックするチームでこそモブプロの力を最大化できるのではと思っています。

長期スパンで数字を追いかけていくチームはモブプロで強いチームになれるのでぜひ試してみてください。