初回で100%のシステムは作れない ― MVPから始めるという選択
「せっかく作るなら、最初から完璧なものを」。システム開発をご検討中のお客様から、よくいただくお気持ちです。ただ、数十のプロジェクトをご支援してきた経験から、私たちはこうお伝えしています。初回のリリースで100%のシステムを作ることはできません。
リリースして初めて見えてくるものがある
システムは、作って終わりではなく、業務の中で使われて初めて価値を生みます。そして、実際に運用が始まると、必ずと言っていいほど新しい発見があります。
- 机上の検討では想定していなかった業務課題
- 実際に触ってみて初めて分かる「本当に欲しかった機能・UI」
- 思ったより使われない機能、想定以上に使われる機能
これは要件定義の失敗ではありません。使う前には誰にも見えなかったものが、使うことで見えるようになった、という自然な変化です。
「事前に完璧」を目指すと何が起きるか
一方で、リリース前の机上検討で完璧を目指すと、次のようなことが起きがちです。
- 検討が終わらず、いつまでもリリースできない
- 「念のため」の機能が積み上がり、予算も工数も膨れ上がる
- 要望とフィードバックの往復が繰り返され、ベンダーだけでなく、確認するお客様側の工数も増え続ける
プロジェクトの期間は有限です。度重なるフィードバックや要望の提出は、開発の双方を疲弊させ、肝心の「業務を良くする」という目的から遠ざかってしまいます。
MVPという考え方
そこで私たちがおすすめしているのが、MVP（Minimum Viable Product：必要最小限のプロダクト）でまずリリースする進め方です。
業務が回るために本当に必要な機能に絞って軽量にリリースし、実際に運用しながら、本当に必要だと分かった変更を後から加えていく。遠回りに見えて、この方が理想のシステムに最短で近づきます。
- 早く使い始められるため、投資の回収も早く始まる
- 実際の運用から得た確かな根拠をもとに、次の投資判断ができる
- 「作ったのに使われない機能」への無駄な投資を避けられる
MVPを成立させる条件
ただし、「小さく出して育てる」進め方には条件があります。
第一に、後からの変更に耐えられる設計であること。第二に、リリース後も伴走する開発パートナーがいることです。作って納品して終わりの関係では、せっかくの運用からの学びをシステムに反映できません。
レザボア・コンサルティングでは、Reservoir Way という開発手法により、本物に近いプロトタイプをご確認いただきながら機能単位で開発を進め、リリース後の保守・エンハンスまで同じチームが継続してご支援します。「まず何をMVPとすべきか」の整理からお手伝いできますので、お気軽にご相談ください。