新規事業のシステムを「小さく」作る理由
既存の業務をシステムにする場合は、今の業務の流れが手本になります。一方、新規事業には手本がありません。利用者が本当に使ってくれるのか、どの機能が必要なのかは、始めてみるまで分からない部分が多く残ります。
この状態で最初から大きなシステムを作ると、使われない機能に費用をかけてしまったり、方向転換が必要になったときに作り直しが大きくなったりします。そこで、まずは事業の中心となる部分だけを作り、利用者の反応を見ながら育てていく進め方が有効です。
MVP（最小限の製品）とは
このように小さく作る最初の製品は、MVP（Minimum Viable Product：実用最小限の製品）と呼ばれます。「機能を削った未完成品」ではなく、利用者にとって価値のある体験を、最小限の範囲で実際に提供できるものを指します。
たとえば予約サービスなら、最初は「空き状況を見て予約できる」ことだけに絞り、会員ランクやポイントの仕組みは後回しにする、といった考え方です。
業務向けのシステムでも同じです。受講記録の管理なら、まずは「記録を入力し、一覧で確認できる」ことを作り、帳票の自動作成や集計の画面は、運用しながら必要性を見極めて追加していきます。
最初に作る範囲の決め方
「小さく作る」と言っても、何を残して何を削るかの判断は簡単ではありません。次の4つのステップで考えると、整理しやすくなります。
- 1
確かめたいことを1つに絞る
最初のシステムで確かめたいことを、一文で書いてみましょう。「保護者が、夜間でも疑問をすぐに解消できるか」「受講者の実技時間を、紙を使わずに正確に記録できるか」のように、誰の、どんな困りごとが解決されるかを明確にします。確かめたいことが複数ある場合は、事業にとって最も大事なものを選びます。
- 2
利用者の流れを1本だけ描く
利用者がサービスを知ってから、目的を達成するまでの流れを、最も基本的なパターン1本だけ描きます。「知る・アクセスする」「必要な情報を入力する、または質問する」「結果を受け取る」「運営側が内容を確認・対応する」といった形です。例外的なケースや、まれにしか起こらない操作は、この段階では考えなくてかまいません。
- 3
機能を3つに仕分ける
思いつく機能を書き出したら、「なければ成り立たない」「あると便利」「いずれ必要」の3つに仕分けます。迷ったときは、「この機能がなかったら、利用者は目的を達成できないか」と問いかけてみてください。達成できるなら、最初の範囲からは外せる可能性があります。
- 4
手作業で代わりにできないか考える
利用者が少ないうちは、運営側の作業を手作業で補うこともできます。集計は表計算ソフトで行う、通知はメールで個別に送るなど、システムにしなくても回る部分は後回しにします。手作業を続けるうちに、本当に自動にすべき部分が見えてきます。
| 分類 | 判断の目安 | 最初のシステムでの扱い |
|---|---|---|
| なければ成り立たない | 利用者の基本的な流れが途切れてしまう | 作る |
| あると便利 | なくても流れは成り立つが、使い勝手が良くなる | 利用者の反応を見て追加 |
| いずれ必要 | 利用者が増えたときや、事業が広がったときに必要 | 後回し（記録だけ残す） |
範囲を決めたら、関係者と一枚にまとめる
4つのステップで決めた内容は、「確かめたいこと」「利用者の流れ」「最初に作る機能」「後回しにする機能」の4つの見出しで一枚にまとめておきましょう。社内の関係者や開発を依頼する先と同じものを見ながら話せるので、途中で「やはりあの機能も」と範囲が広がるのを防ぎやすくなります。後回しにした機能も記録に残しておけば、アイディアを捨てたわけではないと関係者に伝えられます。
作ったあとの進め方
最初のシステムができたら、実際に利用者に使ってもらいます。そのうえで、次の点を確認しましょう。
- ステップ1で決めた「確かめたいこと」は確かめられたか
- 利用者がつまずいている画面や操作はどこか
- 運営側の手作業で、負担が大きくなっている部分はどこか
- 「あると便利」に分けた機能のうち、要望が多いものはどれか
この結果をもとに、次に作る範囲を決めます。小さな完成と確認を繰り返すことで、事業の方向と合ったシステムに近づいていきます。
「使われていない」ことも大切な結果
最初のシステムを公開しても、思ったほど使われないことがあります。これは失敗ではなく、大きな費用をかける前に分かった大切な結果です。どこで利用者が離れているのか、そもそも困りごとの捉え方が合っていたのかを見直し、次に作るものを決め直しましょう。小さく作っておけば、こうした方向転換にも対応しやすくなります。
小さく作るときの注意点
削ってはいけないものもある
個人情報の保護やデータの安全な保管、法令や規程で求められる記録などは、最初の段階から必要です。
後から広げられる作りにする
小さく作ることと、場当たり的に作ることは違います。機能を足していける作りかどうかを、開発を依頼する先に確認しましょう。
「最初から全部」の誘惑に注意する
機能を詰め込むほど完成は遠のきます。詳しくはシステム開発が失敗する5つの理由と発注側の対策でも解説しています。
pegの進め方：話しながら範囲を決める
新規事業の段階では、作りたいものを文書にまとめるのは難しいものです。pegは、発注側にエンジニアがいなくても、ヒアリングと手元の資料だけで要件を形にし、最初に作る範囲を業務の言葉で確認しながら進めます。
手元の材料から形にした事例
官公庁の予防接種に関するLINE AIチャットは、保護者の不安を軽減することを目的としたLINE上のAIチャットで、調査データとヒアリングをもとに構築しました。またドローン操縦士協会の講習・実技時間管理システムは、ヒアリングと事務規程をもとに構築した事例です。新しい取り組みを検討している中堅・中小企業の方は、中堅・中小企業向けのご案内もご覧ください。
関連するコラム：要件定義を発注側だけで抱えない進め方／システム開発の見積もりの読み方／コラム一覧
よくあるご質問
QMVPは「未完成のシステム」ということですか？
違います。MVPは機能を削った未完成品ではなく、利用者にとって価値のある体験を、最小限の範囲で実際に提供できるものです。個人情報の保護など、最初から欠かせない部分は含めて作ります。
Q最初に作る範囲は、どうやって決めればよいですか？
確かめたいことを1つに絞り、利用者の基本的な流れを1本描いたうえで、その流れが途切れてしまう機能だけを最初に作ります。手作業で代わりにできる部分は後回しにすると、範囲を小さく保てます。
Qアイディアの段階でも相談できますか？
ご相談いただけます。pegの無料相談では、事業のアイディアや困りごとを伺い、最初に作る範囲の整理までお手伝いします。手元の資料を入れると機能の一覧と概算の見積が出る見積シミュレーターもご利用いただけます（無料・メールアドレスの確認後に表示）。
Q小さく作ったあと、機能を追加していけますか？
追加していけます。最初から後で広げることを前提に作りを決めておくと、利用者の反応を見ながら必要な機能を足していけます。どこまで広がる可能性があるかも、ご相談の段階で伺います。
まずは話すところから
仕様書がなくても、社内にエンジニアがいなくても大丈夫です。実現したいことを伺い、進め方と概算をご提案します。ご相談は無料です。
