Webプロダクトやアプリのアイデアが見えてきたとき、次に考えやすいのは「どこに依頼するか」かもしれません。 ただ、その前に少し整理しておいた方が、その後の相談や見積もりは進めやすくなります。
MVP開発を依頼したいと思っていても、その時点ではまだ、何を最初の範囲にするのか、誰にどの価値を届けたいのか、どこまでを今回の対象にするのかが曖昧なことは珍しくありません。 むしろ、その曖昧さが残っているからこそ、依頼先を比較しようとしても判断しにくくなることがあります。
この記事では、MVP開発を依頼する前に整理しておきたいポイントをまとめます。 最初から全部が決まっている必要はありません。けれど、何を確かめたいのか、何を最初の対象として扱いたいのかが少し見えているだけでも、その後の相談は進めやすくなります。
まず、MVPで何を確かめたいのかを整理する
MVPという言葉はよく使われますが、相談の場では人によってイメージがかなり違うことがあります。
ある人は、最低限の機能だけを入れた最初の版を思い浮かべます。 別の人は、ユーザーに見せて反応を確かめるための小さなプロダクトを思い浮かべます。 また別の人は、ほぼ正式版に近い最初の公開版を考えていることもあります。
そのため、依頼前にまず整理しておきたいのは、何を確かめるためのMVPなのかです。
たとえば、次のような違いがあります。
- そのアイデアに本当に需要があるのかを見たい
- 想定している流れや使い方が自然に機能するかを見たい
- 社内説明や意思決定のために、具体的な形がほしい
- 最小限の範囲で、初期公開や初期運用を始めたい
同じ「MVP開発を依頼したい」でも、ここが違うと、必要な範囲も進め方も変わります。 逆にここが曖昧なままだと、依頼先との会話でも「何を作るつもりなのか」が少しずつずれていきやすくなります。
最初から全部を作る前提にしない
アイデアを考え始めると、必要に思えるものは増えやすいものです。
- この機能も必要かもしれない
- 管理画面も必要そう
- 予約も決済も通知も必要ではないか
- ユーザー向け画面だけでなく社内向けも必要ではないか
こうした発想自体は自然です。 ただ、最初の相談の時点でそれらをすべて同じ重さで並べると、MVPとして何を扱うのかが見えにくくなります。
依頼前に整理しておきたいのは、今回の最初の範囲に入れるもの と 今回はまだ入れないもの を分けて考えることです。
この段階では、きれいに確定しきれなくてもかまいません。 それでも、たとえば次のように分けておくと、相談は進めやすくなります。
- 最初の版で必ず必要なもの
- あった方がよいが、最初はなくてもよいもの
- 将来的には必要そうだが、今回はまだ扱わないもの
MVP開発の相談では、この切り分けがそのまま見積もりや進め方に影響します。 何を入れるかだけでなく、何を今回は入れないか も大事な整理です。
誰のためのものかを言葉にする
機能の話に入る前に、意外と重要なのが「誰のためのものか」です。
ここでいうのは、単なる属性の話ではありません。 たとえば、
- どんな人が
- どんな場面で
- 何に困っていて
- その結果、何ができるようになると価値があるのか
ということです。
この部分が曖昧だと、機能の優先順位も決まりにくくなります。 逆にここが少し見えていると、最初のMVPとして何を扱うのが自然かを考えやすくなります。
依頼前に、完璧なペルソナや市場分析が必要という意味ではありません。 ただ、少なくとも
- 今回まず届けたい相手は誰か
- その人にとっての最初の価値は何か
が見えていると、何を最初のMVPとして扱うかも判断しやすくなります。
画面だけでなく、使われ方も考える
MVPの相談では、つい画面の話だけで考えがちです。
- この画面が必要
- ログイン画面が必要
- 一覧画面が必要
- 詳細画面が必要
もちろん画面は重要です。 ただ、それだけではまだ足りません。
実際には、
- どの順番で使うのか
- 何を入力するのか
- 操作したあと何が起こるのか
- 管理側では何を扱うのか
- 例外やエラーが出たときどうなるのか
といった流れも、早い段階で少し見えていた方が相談しやすくなります。
依頼前にここまで細かく仕様化する必要はありません。 けれど、どんな利用の流れを想定しているか がまったくないままだと、見積もりや相談で話が広がりやすくなります。
相談時点で決まっていなくてもよいこと
ここまで読むと、「やはりかなり整理してからでないと依頼できないのでは」と感じるかもしれません。 でも、そういうことではありません。
実際には、依頼前の段階で決まっていないことがあるのは自然です。
たとえば、次のようなことは未確定でも珍しくありません。
- 具体的な画面数
- 細かい文言
- すべての機能の優先順位
- プロトタイプ寄りで進めるか、本番初期版寄りで進めるか
- 実装の細かい方式
- 将来どこまで拡張するか
大事なのは、何が決まっていて、何がまだ決まっていないかを自分でも把握しておくことです。
「全部決まっていない」こと自体が問題なのではなく、 「何が未決定なのかが見えていない」ことの方が、相談では負担になりやすくなります。
見積もりだけ先に取りたくなるときに起きやすいこと
MVP開発を依頼するとき、最初に費用感が気になるのは自然です。 ただ、見積もりだけを先に取ろうとすると、前提の違いが見えないまま金額だけ比べることになりやすいです。
たとえば、同じ「MVP開発」でも、
- どこまでの範囲を含むのか
- 管理画面があるのか
- ダミーデータ前提なのか
- 実際のデータを扱うのか
- 初期公開を想定するのか
- 例外処理や周辺機能をどこまで入れるのか
によって、見積もりの前提はかなり変わります。
そのため、依頼前に整理しておきたいのは、 金額だけではなく、その金額がどんな範囲や前提に基づくものなのかを見ることです。
費用を知りたい段階でも、最初に考えるべきことは意外と「いくらか」だけではありません。 むしろ、どこまでを今回の対象にするか の整理が先に必要なことがあります。
依頼先を見るときに確認したいこと
MVP開発の依頼先を考えるときは、実績や金額だけでなく、進め方も見た方がよいです。
たとえば、次のような違いがあります。
- 仕様が固まってから受ける前提なのか
- 構想整理から一緒に進めるのか
- 最初の範囲を切ることに慣れているか
- 小さく始める前提で話せるか
- 相談の段階で前提や未決定点を整理してくれるか
MVPの相談では、単に「作れるか」だけでなく、今の段階に合った整理の仕方ができるか も大切です。
まだ構想が完全には固まっていない段階では、詳細仕様や完成形の話にすぐ飛ぶより、まず前提や対象範囲を揃える方が自然なことがあります。
相談前に用意しておくと役立つもの
最後に、相談前にあると進めやすいものをまとめます。
- 今考えているサービスやプロダクトの簡単な説明
- 誰に向けたものかのメモ
- 最初に届けたい価値のメモ
- 参考にしているサービス
- 必要そうだと思っている機能の一覧
- 今回はまだ決めきれていないこと
- 予算感や希望時期
- 社内で気になっている論点
これらが完璧に揃っている必要はありません。 箇条書きでも、ラフなメモでも十分です。
大事なのは、依頼前の段階で 何を作るかを細部まで確定すること ではなく、 何を最初に確かめたいのか、どこまでを最初の対象にしたいのかを見えやすくすること です。
