「小さく作る」に込められる、2つの意味
仮にこの先リーンスタートアップという言葉がなくなったとしても、「MVP」（Minimum Viable Product）という概念は残り続けるだろうと思う。
あらためてMVPとは何か？ それは学習戦略であり、合意形成の手段だ。前者が本来の意味。ムダ、ムリ、ムラのあるプロダクト作りを避けて、学びを中心に据えたプロダクトマネジメントに不可欠な概念だ。
多くの観点でいまだ仮説が多いプロダクトの構想について、想定ユーザーにとって価値がある（役に立つあるいは意味がある）範囲を特定し、いち早く試してもらい、その反応を得る、診る。
初期段階はプロダクトの構想仮説で成り立たせている部分が多いため、作りすぎないように範囲を徹底して絞る。こうした目的で作るのだから、ホールプロダクトということにはならない。
MVPとホールプロダクトの背景、狙いの差を押さえられていれば、MVPによる学習戦略は極めて効果的と言える。早く試せるということは次の意思決定が早くできるということだ。
もう一つ、この概念には重要な役割がある。それが、合意形成のための手段。依頼されて作る開発では勿論のこと、自社で提供するプロダクトの開発においても、開発を取り巻くステークホルダーとの「期待合わせ」は丁寧に行う必要がある。今回の予算、時間軸でどこまで作り込むのか、開発の「着地」に対する経営や事業観点での期待のことだ。
資源（カネ、時間）を費やす以上、全くの手ぶらではじめて適当に終了できるというのは、どのような形態の仕事でも存在しないだろう。それが実験的なプロジェクトだとしても、目的があり個々の期待へと繋がっている。
ソフトウェア開発が厄介なのは、どこまでできるかという「着地」をあらかじめ精緻に予測し、コミットメントすることが難しいところだ。依頼されて作る開発の場合は、このコミットメント自体が取引の対象だから、とくに制約が強くなる。強くなりすぎて、本来の目的を捻じ曲げてしまうこともある。
ソフトウェア開発である以上、経営と現場という2つの立ち位置がある以上、オーダーする側と作り手という役割がある以上、プロダクト開発でも適切な期待マネジメントを必要とする。組織形態が伝統的で、大規模であるほど、この観点が問われる。
MVPが果たす役割は、ここにもある。MVPで、実行可能な最小限の範囲のコミットメントラインを置いて、それ以上の範囲、部分については状況に委ねる。MVPが構築できるということは所与の目的を果たせていることになるし、それ以上の範囲、部分については作り進める中での余力と必要性でもって判断する。
MVPの概念は、当然依頼型の開発でも契約形態と連動させて取り入れるべきだし、行政方面のような厳格な予算設定と入札に基づく開発（より事前コミットメントが求められる）でも、有効と考えている。
ただし、一つ、大事な前提をまだ語っていない。MVPという概念が成り立つためにはその範囲特定をどのように行うかが極めて重要になる。そこで、「仮説検証」による共通の理解、共通の判断軸を作り出して...ということになる。続きは、勿論書籍をどうぞ。
そもそも「小さく作れ」という考え方は、イニシエより延々と伝わる教えである。新しい概念ではない。「UNIXという考え方」の目次をペラペラみるだけでも伺い知れることだ。
「小さく作る」というのは、奥深く、価値がある。