あえて要件定義しない選択肢：MVPリリース後に育てる
要件定義を完璧に固めてから開発する——それが理想ですが、現実には難しいケースも多くあります。「あえて要件定義しない」という選択肢も、正しい文脈で使えば有効なアプローチです。
完璧な要件定義を目指すことの弊害
「漏れのない要件定義を作ってから開発しよう」という姿勢は正しいのですが、それを追い求めすぎると別の問題が起きることがあります。
要件定義が終わらない：「完璧にしなければ」という意識が強すぎると、ヒアリングと修正を繰り返すだけで、いつまでも開発に入れません。実際に使ってみないとわからないことは、使う前にいくら議論しても答えが出ません。
要件定義の段階で方向性が固まりすぎる：市場や業務の変化に対応しにくくなります。「あのとき決めた仕様に縛られて、変えたくても変えられない」という状況が生まれます。
現場が「想像で」要件を出さなければならない：まだ存在しないシステムについて、現場担当者に「どんな機能が欲しいですか」と聞いても、経験がない分だけ答えにくいものです。実際に触ってみて初めて「こういう機能が欲しかった」に気づくことは多くあります。
MVPとは何か
MVP（Minimum Viable Product）とは、「最小限の機能でリリースする製品」のことです。
「完璧なシステムを作ってからリリース」ではなく、「動く最低限のシステムをまず出す」という考え方です。完璧でなくても、現場で実際に使える状態にすることを優先します。
たとえば、在庫管理システムを作るとして、MVPでは「入庫・出庫の記録」「現在の在庫数の確認」だけを実装してリリースします。発注アラートや帳票出力は、まず使ってみてから必要性を確認して追加する、という進め方です。
アジャイルで育てる
MVPを出した後は、現場からのフィードバックを受けながら機能を積み上げていきます。これがアジャイル的な進め方です。
「最初から全部決めて一気に作る」のではなく、「小さく出してフィードバックを受けながら育てる」サイクルを回します。
このアプローチでは、要件定義の段階で完全な仕様を固める必要はありません。「最初に作る最低限の機能」だけを合意して開発をスタートし、その後の追加機能は実際の使用感を見ながら決めていきます。
このアプローチが向いているケース
すべての開発にこのアプローチが適しているわけではありません。向いているケースと向いていないケースがあります。
向いているケース
- 「使ってみないとわからない」要素が多い新しい業務システム
- ユーザーの反応を見ながら機能を磨きたいサービス
- 予算・スケジュールに柔軟性があり、段階的に投資を増やせる
- 現場担当者のITリテラシーが低く、実際に触ってもらわないと要望が出ない
向いていないケース
- 止められない業務の基幹システム（経理・給与など、不完全だと業務が回らない）
- 法規制や外部との連携要件が細かく決まっており、仕様変更の余地がない
- プロジェクト開始時点で予算・機能・納期が厳格に決まっている
「あえて要件定義しない」は無計画とは違う
「MVPリリース後に育てる」と聞くと、「何も決めないまま進める」ように聞こえるかもしれませんが、そうではありません。
以下の点は事前に決めておく必要があります。
- 目的：このシステムで何を達成したいのか
- MVPの範囲：最初にリリースする最低限の機能は何か
- 対象ユーザー：誰が使うシステムか
- 成功の基準：どうなったら「うまくいった」と判断するか
- 改善のサイクル：どのくらいの頻度でフィードバックを受けて機能追加するか
この枠組みを共有した上で、詳細な仕様の決定を「開発しながら」「使いながら」行っていきます。
要件定義とMVPの組み合わせ方
実際には、「完全に要件定義する」か「まったく要件定義しない」の二択ではありません。
最も現実的なアプローチは、コア機能の要件はしっかり定義し、周辺機能はMVP後のフィードバックで決めるというハイブリッドです。
- 業務に必須で変更が難しい部分（データの構造、認証・権限まわりなど）は最初にしっかり固める
- 使い勝手や補助的な機能は、実際に使ってから決める
この組み合わせが、多くの中小企業向けシステム開発において現実的なバランスです。
まとめ
要件定義を完璧に固めることが難しいケースでは、「まず動かしてみて、育てる」アプローチが有効です。ただしこれは「何も決めない」ではなく、「何を最初に決めて、何を後で決めるか」を意識的に選択することです。
自社の状況（予算・業務の性質・現場のITリテラシー）に合わせて、要件定義の深度と開発アプローチを選ぶことが重要です。