「動いてるなら使わせて」の危うさ — モック・MVP・作り込みの使い分け

「動いてるんだから使わせて」

あるシステム開発で、方向性を確認するために動くものを作った。モックだ。捨てる前提で、とにかく早く形にした。ローカル環境でしか動かせないレベルで、本番に出せるものではなかった。

ところが、相手に見せたら「動いてるんだから、早く使わせて」と言われた。

こちらはモックのつもりだった。方向性を確認したら作り直す前提だ。でも相手から見れば、動いているものは動いているものだ。なぜすぐに使えないのか、理解されなかった。本番で使うには例外処理が足りないことなどを説明して、ようやく納得してもらえた。

MVPという考え方

エリック・リースが提唱したリーンスタートアップでは、「MVP（実用最小限の製品）」という考え方がある。完璧に作り込んでから出すのではなく、最小限の機能で早く出して、フィードバックをもらって改善する。

この考え方自体は正しい。BI画面の開発でMVPのアプローチを取ったとき、方向性の違いに早い段階で気づけて修正できた。完璧に作り込んでから「実は方向性が違いました」となるよりも、はるかに効率がいい。

ただ、MVPがうまくいくものと、そうでないものがある。基幹システムのように、最初から一定の完成度が必要なものもある。データの整合性が必要だったり、部分的に動いても意味がなかったりする。

モック・MVP・作り込み

整理すると、作り方には3段階ある。

モック は捨てる前提だ。方向性を確認するためだけに作る。動くが、本番で使えるものではない。本番に必要な考慮事項は省いている。確認が終わったら作り直す。

MVP は捨てない。本番の土台になる。ただし機能は最小限で、後から追加していく。最初のリリースでは足りない部分があるが、継ぎ足しで育てていける。

作り込み は最初から必要な機能を揃えて作る。基幹システムのように、一度に作り切る必要があるものはこちらだ。

どの段階で作るかによって、コスト、スピード、品質のバランスが変わる。

これはシステム開発に限った話ではない。企画書にも同じ構造がある。方向性を確認するためのラフ案、内容は入っているが詰めきっていないドラフト、そして最終版。ラフ案を見せたら「これで決まりですね」と言われた経験がある人は多いのではないか。新しい業務プロセスも同じだ。一部のチームで試しているだけなのに「全社で使えるんですよね」と言われる。

問題は、作る側と受け取る側でこの認識がずれることだ。

認識がずれると何が起きるか

自分がモックのつもりで作ったものを、相手が本番だと思う。「動いている＝使える」と判断される。でも、モックは本番に必要な考慮が入っていない。そのまま本番に出たら事故になる。

逆のパターンもある。作り込みが必要な場面で「まずはMVPで」と進めると、後から根本的な作り直しが必要になる。継ぎ足しでいけると思ったら、土台から作り直しだった、ということもある。

どちらも、最初に「これは何段階目のものか」を合意していないから起きる。

全員が同じ意識を持つ

大事なのは、今作っているものが3段階のどれなのかを、関係者全員が理解していることだ。

モックなら「これは方向性を確認するためのもので、このまま使えるものではない」と伝える。MVPなら「最小限の機能で出すが、後から機能を追加していく前提だ」と伝える。作り込みなら「最初からこの機能が必要で、段階的なリリースは難しい」と伝える。

当たり前のことのようだが、これを明示しないと認識がずれる。特にモックは危ない。動いているものを見せると、受け取る側はそれが完成品だと思いやすい。

実際、「モックです」と伝えたのに伝わらなかったことがある。モックという言葉の意味が、相手にはピンと来なかったのだと思う。「本番で使うには例外処理が抜けている」「このケースでは動かない」と具体的に説明して、ようやく理解してもらえた。

専門用語で「まだモックです」と言うだけでは足りない。何が足りなくて、そのまま使うと何が起きるかを、具体的に見せる必要がある。動いているものの説得力は強い。それを上回る説明をしなければ、認識はずれたままだ。

BI画面のようなものはMVPで進めやすい。方向性が違えばすぐ修正できるし、機能を継ぎ足していける。基幹システムのようなものは作り込みが必要だ。一度に作り切らないといけない。この見極めを最初にやることで、進め方の認識がずれにくくなる。

今作っているものは、モック・MVP・作り込みのどれだろうか。

そしてそれは、関係者全員が同じ認識を持っているだろうか。

もう少し深く知りたい人へ

MVP（Minimum Viable Product）は、エリック・リースが2011年の著書『リーン・スタートアップ』で広めた概念だ。リースはスタートアップの最大のリスクは「誰も欲しがらないものを作ること」だと指摘し、最小限の機能で早く市場に出してフィードバックを得ることを提唱した。

ただし、MVPという言葉は誤解されやすい。「最小限」が「低品質でいい」と解釈されることがある。リース自身は、MVPは「学びを最大化するために必要な最小限の製品」と定義しており、品質を犠牲にすることは意図していない。本文で整理したモックとMVPの区別は、この誤解を防ぐために重要だ。モックは学びのために品質を犠牲にしてもいい。MVPは品質は保つが機能を絞る。

本文で触れた「動いているものを見せると本番だと思われる」問題は、ソフトウェア開発では古くから認識されていた。フレデリック・ブルックスは『人月の神話』で、プロトタイプを作ると「なぜこのまま出せないのか」と言われる問題を指摘している。UIデザインの世界では、あえて手書きのワイヤーフレーム（低忠実度プロトタイプ）を使うことで「これは完成品ではない」と伝える手法がある。きれいに作りすぎると、受け取る側が完成品だと認識してしまうからだ。

また、本文で触れた「継ぎ足しでOKなもの」と「一度に作り切るもの」の区別は、ソフトウェアアーキテクチャの観点でも重要だ。モジュール性が高く、コンポーネントを独立して追加・変更できるシステムはMVPアプローチに向いている。一方、コンポーネント間の依存関係が強いシステムでは、部分的な変更が全体に波及するため、最初から全体を設計する必要がある。

参考文献

• エリック・リース 『リーン・スタートアップ』
• フレデリック・ブルックス 『人月の神話』