MVPで進めるプロジェクトマネジメント—スコープの再定義と合意形成プロセス

こんにちは。モノタロウの大道です。
2019年に新卒入社し、現在入社7年目です。普段はプロジェクトマネージャー（以下、PM）としてモノタロウサイトの開発に携わっています。

本記事では、私が担当した「加工品プロジェクト」の経験をもとに、Minimum Viable Product（以下、MVP）のプロジェクトを進める難しさに焦点を当てて、次の2点についてお話しします。

MVPプロジェクトにおいてミニマム（以下、M）を定義する難しさ
MVPでプロジェクトを進めるうえで大切にしてほしいこと

※MVP以外の手法を否定する意図はありません。

1．背景：なぜMVPで挑むのか

はじめに、モノタロウの過去の新規事業プロジェクトの傾向と、MVPで新規事業に挑む理由、そして本プロジェクトの概要についてお伝えします。

モノタロウの過去の新規事業プロジェクトの傾向

どうしても開発が重い

当社は2025年10月に創業25周年を迎えました。

企業の成長の反作用として、私たちは巨大な長寿システムとお付き合いしていかなければなりません。

システムのモダナイゼーション化は並行して進んでいるものの、提供しているサービスが幅広いため、一案件あたりの影響範囲が大きくなることは避けられません。結果として、開発工数が重くなりがちです。

部門割が強く、他観点が弱い（ビジネスサイド⇔テックサイド）

会社の成長に伴い、組織の拡大とドメイン分割が進んだことで、縦割りが強くなり、他部門視点が弱くなる局面があります。

MVPの成功事例が少ない

上記の組織的な背景から、当社ではシステム開発を伴う新規事業プロジェクトではウォーターフォールを採用する場面が多く、MVPの取り組みは限定的でした。

過去にMVPの導入に挑戦した新規事業プロジェクトでは、システム開発のスコープを必要最小限に絞り切れず（結果的に作りすぎてしまった）、初回リリース後の継続投資（追加開発・拡張）につながらないまま中途半端な状態で終わってしまい、MVPとしての成功事例には至っていないというのが現状です。

それでもMVPで挑む理由

MVPの成功事例が少ないからこそ、私たちがMVPに挑む意義があります。

MVPは、巨大な長寿システムや多部門の調整を前提とする私たちが、新規事業の導入と導入後の拡張・撤退のサイクルを柔軟に素早く回すための最適な手法です。大規模な初期投資に踏み出す前に、顧客価値と需要を小さく確かめることで、費用対効果を最大化させることができます。

このような背景のもと、新規事業プロジェクトをMVPで再挑戦することになり、そのプロジェクトのPMを私が担当することになりました。本記事では、そのプロジェクトで直面した課題と、その課題をどう乗り越えたかをお伝えします。

加工品プロジェクトについて

私がPMを担うことになったプロジェクトの概要を説明します。

名称：加工品プロジェクト
プロジェクト概要：モノタロウサイト（www.monotaro.com）に「加工品を図面描かずにウェブで簡単手配」ができるシステムを構築する。
目的：加工品の取り扱いを拡大し、モノタロウサイトの取扱商品の幅を広げていく。
体制：
- ビジネス：新規事業開発室（役割：企画、起案）
- テック：ECシステムエンジニアリング部門ほか（役割：システム開発）←私はこちらに所属
対応期間：
- 1年10か月（2023年6月～2025年4月）
  - 企画～要求定義：1年1か月（2023年6月～2024年7月）
  - 要件定義以降：9か月（2024年7月～2025年4月）
関連部門と参画人数：
- 7部門1室計30名（＋ベンダー協力7名）

「非設計者向けの加工品販売サービス」という新規事業の大規模プロジェクトであり、新規性・不確実性が高い中での初回リリースであったため、「M（ミニマム）のスコープの定義」がこのプロジェクトの鍵でした。

実際の加工品の販売画面。パラメーターの入力値に応じてリアルタイムに図面が描画される。

www.monotaro.com

２．プロジェクトの前提のすり合わせ（トレードオフ・スライダーとMの仮置き）

私がPMとして参画したのは、要求定義フェーズの終盤でした。 PMとして参画後、まずは関係者間で前提の認識を揃えました。

トレードオフ・スライダーの作成

トレードオフ・スライダーとは、プロジェクトにおける「Quality（品質）」「Cost（予算）」「Delivery（納期）」「Scope（スコープ）」の優先順位を可視化するツールです。

今回の加工品プロジェクトにおいては、新規事業をMVPで検証するという方針に基づき、以下の優先順位でプロジェクト関係者と合意しました。

ポイントは、Delivery（納期）が最優先で、Scope（スコープ）が一番優先度が低いところです。

**Delivery（納期）** ＞Cost（予算）＞Quality（品質）＞ **Scope（スコープ）**

商品スコープを確定

「MVPのMと定めることができる最小単位のスコープ」をビジネスサイドで選定し、そのスコープについてステアリングコミッティ（以下、ステコミ）の合意を得ました。

ここまででプロジェクトの前提を揃えることができました。

３．加工品プロジェクトで発生した問題

プロジェクトの優先順位と商品スコープの合意が取れたことだし、これから要件定義も順調に進められるーーと思っていたのですが、実際には要件定義フェーズで3つの問題に直面しました。

「追加要求」の顕在化

要件定義を進める中で「オプション機能」の要求が顕在化しました。

「オプション機能」とは、加工した商品にバリ取り加工やテープ貼付け面（表裏）などの指定を行う機能です。

要求定義事項には含まれていなかったため、当初の予定よりも以下の検討事項が増え、複雑性が増すことになりました。

料金計算パターン
形状パターン
オプション加工の設定

※後のフェーズで、これは「追加要求」ではなく実態は「要求漏れ」だったことが判明するのですが、それについては後述の「４．すれ違い解消の取り組み」のセクションで詳述します。

ユーザーインターフェース（以下、UI）の追求による意思決定の遅延

加工品プロジェクトでは、UIの妥当性を高めるため、UI決定のプロセスの中に「ユーザーテスト」を取り入れることになりました。「ユーザーテスト」とは、検討中のデザインで主要機能が動作する状態の静的なテスト用ページを用意し、実際のモノタロウサイトのお客様のうちプロジェクトのターゲット層から、テストにご協力いただける方を募集し、実際にテスト用ページを触っていただき、使い勝手やご感想を伺うテストです。

ユーザーテスト実施による収穫（顧客の生の声、ニーズの理解）は大きかった一方で、ユーザーテストを実施するたびに新たな課題や発見が見つかり、テスト実施→デザイン見直し→テスト実施→デザイン見直し…というサイクルが重なり、気がつけば、要件定義終了時期に迫ってもなおUIが確定しない事態に陥りました。

プロジェクトの優先順位の逆転（納期優先→スコープ優先へ）

上記の影響でスケジュールが遅延し、やむなく延長することになりました。

結果として、実態の優先順位が「スコープ＞納期＞予算＞品質」へと傾き、プロジェクトの判断基準が当初合意したトレードオフ・スライダー（納期優先）の優先順位と異なっていたことで、MVPの「M」の考え方についてテックとビジネスサイドですれ違いが発生しました。

**Scope（スコープ）** ＞Delivery（納期）＞Cost（予算）＞Quality（品質）

トレードオフ・スライダーを作成した当時は、Delivery（納期）最優先で合意したにもかかわらず、実際はスコープ優先に傾き、プロジェクトの延長判断がとられていました。

この動きがトレードオフ・スライダーで定めた判断基準と異なっていたため、プロジェクトの動きに対して、プロジェクトメンバー内で疑問が湧いてきました。

ビジネスとテックのそれぞれの思い、背景

少し加工品プロジェクトの話からずれますが、ビジネスとテックのすれ違いが生まれてしまったのは、歴史的な背景が絡んでいます。

冒頭で話した通り、当社では新規事業のシステム開発においてMVPの導入実績はあるものの、MVPの成功事例がありませんでした。

システム開発のスコープを必要最小限に絞り切れなかった（結果的に作りすぎてしまった）。
初回リリース後の継続投資（追加開発・拡張）につなげることができなかった。

この背景から、ビジネスとテックのそれぞれで、異なる「ミニマム」のビジョンを持つようになりました。

この背景によって、今回の加工品プロジェクトにおいてもビジネスとテックですれ違いが発生したというわけです。

MがブレれるのはMVPでは珍しくありません。重要なのは、ブレをどう収め、意思決定を行い、前に進めるかです。次章では、加工品プロジェクトで実際に採用した打ち手を紹介します。

４．すれ違い解消の取り組み

私たちは、対話による前提の再確認と、エビデンスにもとづくMの再定義の二本立てで進めました。

前提・目的の再確認と合意形成

プロジェクト関係者と事実を再整理し、話し合いを続けた結果、プロジェクトが考える前提・認識がプロジェクト関係者内でずれていることが判明しました。

加工品プロジェクトのメインの目的は「加工品の取り扱い拡大」ですが、補助目的として「加工品サービスのユーザビリティ検証」も含まれていました。そこで、「ユーザビリティ検証に必要な最低限のUI検証はMに含める（そのうえでQCDSを適用する）」という線引きで合意しました。

「追加要求」ではなく「要求漏れ」だった（情報公開のタイミングの問題）

追加要求として課題に上がっていた「オプション機能」について、関係者と話し合いを続けた結果、実は「追加要求」ではなく「要求漏れ」であることが分かりました。

もともとビジネスサイドとしてはこの機能を実現したかったものの、要求定義時点でその情報を出し切ることができず、要件定義の段階で初めて情報を出すことになってしまったということが分かりました。

エビデンスにもとづくMの再定義

要求漏れの「オプション機能」が本当にユーザーのニーズがあることを示すために、市場調査を行いました。モノタロウサイトの利用ユーザーのうち今回の加工品プロジェクトのターゲット層に対して、「オプション機能」の有無が購入に与える影響を調査しました。市場調査の結果、「オプション機能がないと加工品の購入に至らない」というケースが一定数存在しました。この市場調査の結果から、「オプション機能」の明確なニーズを確認することができました。

上記の話し合いとエビデンスを元に、「初回リリースのスコープにオプション機能と最小限のUIの追求を含める」という方針で、ステコミ合意のもとスケジュールを延伸することになりました。

このプロセスを通じて、今回の加工品プロジェクトはすれ違いを乗り越え、無事にサービスインを迎えることができました。