
この記事の要点
- MVPとは、利用者に価値を届けられる最小限の機能だけで作り、実際に使ってもらって次の判断の材料を得るための製品です
- 範囲は「誰の、どの困りごとを、何で確かめるか」を先に決め、それに要らない機能は後に回して絞ります
- 使ってもらった後は、決めておいた物差しで結果を見て、広げる・直す・やめるのいずれかを判断します
新しいシステムやAIの仕組みを作るときは、最初から全部の機能を作るのではなく、価値を確かめられる最小限の範囲で作り、実際に使ってもらってから広げる進め方が向いていることが多いです。この最小限の形を MVP と呼びます。
最初に大きく作ると、使ってみて初めて分かる「思っていたのと違う」に気づくのが遅れ、作り直しの手間と費用が大きくなります。小さく作って早く確かめれば、方向を変える判断を早い段階でできます。
MVPとは
MVP(Minimum Viable Product)とは、利用者に価値を届けられる最小限の機能だけで作り、実際に使ってもらって次の判断の材料を得るための製品です。日本語では「実用最小限の製品」と訳されることがあります。
大切なのは「最小限」と「価値を届けられる」の両方です。機能を減らしすぎて、使う人の困りごとが解決しないものは MVP になりません。反対に、あったら便利な機能まで入れてしまうと、確かめるまでに時間がかかります。
試作(PoC)との違い
MVP と似た言葉に、PoC(概念実証)があります。PoC は、技術的にできるか、狙った精度が出るかを確かめるための試みで、実際の業務では使わないことが多いです。MVP は、実際の利用者に業務の中で使ってもらい、役に立つかを確かめる点が違います。
AIの仕組みでは、まず PoC で精度を確かめ、見込みが立ったら MVP として一部の業務で使い始める、という順で進めることがよくあります。PoC から本番へ進めるときの考え方は、AIの試し(PoC)で終わらせないためにで説明しています。
進め方の流れ
MVP は、仮説を決める、範囲を絞って作る、使ってもらう、結果を見て次を決める、の流れをくり返して進めます。1回で終わらせず、この流れを短い期間でくり返すのが基本です。2回目以降は、1回目で分かったことをもとに、足す機能や直す点を決めます。
MVP の進め方の流れ
1回で終わらせず、短い期間でくり返すのが基本です。2回目以降は、1回目で分かったことをもとに、足す機能や直す点を決めます
範囲の決め方
範囲は、「誰の、どの困りごとを、何で確かめるか」を先に決め、それに要らない機能を後に回して絞ります。機能の一覧から削っていくより、確かめたいことから必要なものを選ぶほうが、範囲を小さくしやすくなります。
使う人と困りごとを1つに決める
最初は、使う人と困りごとを1つに絞ります。例えば「営業の担当が、見積書を作るのに時間がかかっている」のように、誰が、何に困っているかを具体的に書きます。いろいろな部門の困りごとを一度に扱おうとすると、範囲が広がります。
確かめる物差しを決める
作り始める前に、何をもって「役に立った」とするかを決めます。
- 作業にかかる時間が減ったか
- 入力の誤りや手戻りが減ったか
- 使う人が続けて使っているか
- 使った人の満足の声や、困った点の声
物差しが決まっていないと、使ってもらった後に「良かった気がする」で終わってしまい、次の判断ができません。作業の時間なら、いまどのくらいかかっているかを、作る前に測っておきます。
後に回す機能を書いておく
範囲から外した機能は、捨てるのではなく「後で検討する一覧」に書いておきます。関わる人の希望を後に回すときも、一覧に残っていれば納得を得やすくなります。
範囲を絞るときに、後に回しやすいものの例です。
| 後に回しやすいもの | 最初の形の例 |
|---|---|
| 画面の細かな見た目 | 見やすさを保った、簡単な画面 |
| 例外の処理の自動化 | 例外は人が手で対応する |
| ほかのシステムとの自動の連携 | 最初はファイルの出し入れで受け渡す |
| 細かな権限の設定 | 使う人を限って、権限を単純にする |
| 帳票や集計の機能 | 必要な数字だけを一覧で出す |
ただし、情報の守り(ログインや権限、扱うデータの範囲)は、最小限の形でも省かないことをおすすめします。小さく作るときも、扱う情報に合わせた守りは最初から入れておきます。
使ってもらった後の判断
使ってもらった後は、決めておいた物差しで結果を見て、広げる・直す・やめるのいずれかを判断します。
- 広げる:物差しで効果が確かめられたら、使う人や業務の範囲を広げ、後に回した機能を足す
- 直す:効果は見えるが、使いにくさや足りない点があれば、直してもう一度確かめる
- やめる:思ったほど効果がない、使われないと分かったら、範囲を変えるか、取り組みをやめる
「やめる」も、小さく作ったからこそ選べる大事な判断です。大きく作った後では、かけた費用が惜しくなり、やめる判断がしにくくなります。
使ってもらう期間は、物差しの結果が見えるだけの長さにします。短すぎると慣れる前に判断してしまい、長すぎると次の判断が遅れます。
よくあるつまずき
MVP の進め方でよくあるつまずきは、範囲が広がること、物差しがあいまいなこと、使う人が限られすぎることの3つです。
- 範囲が広がる:関わる人の希望を少しずつ足していくうちに、最初の形が大きくなり、確かめるまでの期間が延びる。足したい機能は「後で検討する一覧」に書き、最初の範囲は変えない
- 物差しがあいまい:「便利になったか」だけを聞くと、人によって答えがばらつく。作業の時間や件数など、数えられるものを1つは入れる
- 使う人が限られすぎる:作った人の近くの数人だけに使ってもらうと、ほかの現場で起きる困りごとが見えない。普段の業務でその作業をしている人に使ってもらう
つまずきに気づいたら、範囲や物差しを見直してから次の回に進みます。最初の回で完璧な形を目指す必要はありません。
進めるときの注意
MVP で進めるときは、関わる人に「最初は小さな形で始める」ことを、前もって伝えておきます。完成品を期待していた人が最小限の形を見ると、がっかりしてしまうことがあるためです。
また、外部の会社に開発を頼む場合は、くり返して作り進める進め方に合った契約の形を選びます。範囲を最初に固めて作る請負より、作りながら決めていける準委任のほうが合う場合があります。違いはシステム開発の請負契約と準委任契約は、何が違うかで説明しています。作る範囲を決める要件の整理は、要件定義で決めること:はじめての方へも参考にしてください。
当社のご支援
当社のソリューション提供では、決めた課題に合わせて試作で確かめてから、AIを使った仕組みを作ります。業務システムを小さく作って広げたい場合はWebシステム開発、作りながら決めていきたい場合は専任のチームで進めるラボ開発でもお受けしています。どこから小さく始めるかの整理からご一緒したい場合は、お問い合わせからご相談ください。
- MVP
- 小さく始める
- 要件定義
- 導入
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。