初回リリースで100%を目指さず、MVPから始める理由

「せっかく作るなら、最初からきちんとしたものを」。ご相談の初回で、よく伺う言葉です。お気持ちはよく分かります。予算を取って、社内で稟議を通して、ようやく始まるプロジェクトですから。

ただ、これまで数十件の開発をご一緒してきて、正直に申し上げると、初回のリリースで「これで完成」と言えるシステムになったことは一度もありません。

使い始めてから出てくる話のほうが多い

リリースして2〜3週間もすると、現場の方から「この画面、実はこっちの順番で入力したい」「この項目、誰も使ってないです」といった声が届き始めます。逆に、おまけのつもりで付けた検索機能が一番使われていた、ということもよくあります。

設計に誤りはなく、受入テスト（UAT）の段階でもお客様にご納得いただいていた。それでも、実際の業務で使い始めると「この作業のために画面を何回も行き来しないといけない」「同じ情報を何か所にも入力している」といった声が出てくることがあります。

受入テストでも実際の業務をイメージしながら操作していただきますが、確認の中心はどうしても数件のテストデータや主要なパターンになります。毎日何十件も処理する中で感じる手間は、その場ではなかなか見えてきません。

ある人事系サービスの案件では、運用が始まってから、日程情報を複数の箇所で扱うために入力の手間が大きいことが分かりました。そこで、システムの土台となるデータの持ち方はそのままに、日程を自動で同期する機能を追加して、入力が一度で済むようにしました。ほかにも、内部の仕組みは変えずに、よく使う操作をシンプルな画面部品にまとめ直すといった改善を重ねています。

どれも、現場で実際に使っていただいたからこそ拾えた声です。

要件定義の段階でどれだけ丁寧にヒアリングしても、画面を触る前の想像には限界があります。これはお客様の側も、私たちの側も同じです。

最初に全部決めようとすると、なかなか終わらない

リリース前に全部を固めようとすると、打ち合わせのたびに「念のためこれも」「やっぱりここも」と要望が増えていきます。そのたびに見積もりを出し直し、仕様を確認し直し、気づけば予定していたリリース日を過ぎている。そんな状況になると、開発側だけでなく、確認を担当されるお客様側のご担当者も疲れてしまいます。

本来の目的は業務を良くすることのはずなのに、いつの間にか「仕様を決めきること」が目的になってしまうわけです。

まずは最小構成で出して、使いながら育てる

そこで私たちは、まず業務が回るのに必要な機能だけでリリースすることをおすすめしています。この最小構成をMVP（Minimum Viable Product）と呼び、あとは使いながら手を入れていきます。

早く使い始められれば、その分だけ早く効果が出ます。次に何を作るかも、実際の使われ方を見てから決められるので、「作ったけど誰も使わない機能」にお金をかけずに済みます。

	最初に全部決める	MVPから始める
仕様を決める時期	リリース前にすべて	必要な機能だけ決め、残りは使いながら
使い始められる時期	すべての機能ができてから	最小構成ができた時点
次に作る機能の決め方	事前の想像と要望をもとに	実際の使われ方を見てから
起きやすい問題	要望が増え続け、リリースが延びる	直しやすい作りと継続体制がないと成り立たない

ただし、条件があります

この進め方は、どの会社とでもうまくいくわけではありません。後から機能を足したり直したりしやすい作りになっていること、そしてリリース後も同じ開発チームが付き合い続けられることが前提になります。納品して終わりの関係では、せっかく現場から出てきた声を拾えません。

レザボア・コンサルティングの「Reservoir Way」では、本物に近いプロトタイプを触っていただきながら、機能ごとに開発を進めます。リリース後の保守・改善も、同じチームが担当します。「最初にどこまで作るか」を決めるところからご相談いただけますので、お気軽にお声がけください。