価値提案駆動 -- TDDとの類似点

概要

Lean Startupで知られるようになってきたMVP(Minimum Viable Product: 最小限の実用可能な製品)と、Running Leanで提唱されている独自の価値提案(Unique Value Proposition: UVP)について、ソリューション(どう実現するか)よりも先にUVPを先に考えMVPによって早期から検証を繰り返しながらプロダクトを構築していくプロセスが、ソフトウェア開発におけるTDD(Test Driven Development : テスト駆動開発)におけるテストを先に書いて、実装して、リファクタリングするというプロセスに似ているのではないかと考えた。

本文

最近、Running Leanのワークショップを@kdmsnrさんと一緒に開催したり、実際に自分でリーンキャンバスを書く機会が増えたため、ソリューションより先に独自の価値提案(UVP)を先に考えることに慣れてきた。これまでにも「プロダクトのビジョン、コンセプト」を先に考えるということはしてきたが、今考えてみると、ソリューションを先に思いつき、それに合わせて価値提案を作っていたのでは？という気がしてならない。

先にUVPを考えるということは ，はじめにゴールを達成した後の状態である「誰にどのような素晴しい未来が待っているのか」を考えることだ。 UVPを考えその後にUVPを満たすソリューションを作りあげていくプロセスは、TDDと同様に，ゴールを設定してからそこに向う道を進んでいくという点で似ている。逆に言うと「はじめにソリューションありきのプロダクトづくり」はプロダクトコードありきのテストと同じということだ。

またゴール設定という意味で考えても、仕様的ゴール(=XXX という機能があって、このような条件を満たしている)ではなく、プロダクトを受け取った人がどのように感じ、どのように利益を得るのかという、ユーザー体験的ゴールという点が重要だ。

UVPとTDDと比較して異なる点は、あくまでもUVPそのものが仮説であるという点だ。いくらUVPを満たすソリューションをもつ製品を作ったとしても、それが顧客にとって正しいプロダクトかどうかは作る段階ではわからない。もちろんTDDが満たそうとするゴール(=テスト)もその後のプロダクトへのフィードバックの結果によって変わりうる。結局ある時点でのゴールと考えるものは、どれもこれも「いずれ変更される可能性はある当面のゴール」でしかないということに気づく。

ここで「Validation(正しく製品を作っているか）」と「Verification(正しい製品を作っているか)」の違いについて思い出した。(参考:validation and verification: 確認と検証) UVPを検証するという行為は、「正しい製品」を探索することに等しい。「「正しい製品」が正しいか」を最初から定義することはできない。だから、早くUVP(を含めたビジネスモデル)が対象顧客にとって正しいものか(=価値のあるものか)という仮説を、MVPを使って検証しないといけない。そのためUVPが価値があるものらしいという手応えを感じるまでは、作り込んではいけない。なぜならUVPが正しくなければ作ったものがムダになるためだ。TDDにおいても、まずはテストを満たすシンプルなコードを書き、テストをパスさせた上でリファクタリングする。テストを満たす最小限のコード(仮にMinimum Viable Codeと呼ぶ)は、最初にUVPを実現し検証するMVPに類似しているのではないか。

MVPについて考えた時には狩野モデルにおける当たり前品質(あっても魅力にはならないが、なければ困る機能)はどうなるのか、という疑問が生じる。言い換えると「MVPに当たり前品質のフィーチャが必要か？」という疑問である。これはMVPの種類にもよるが、できるだけ「作らないようにする」のがよいだろう。MVPで検証したいのは、魅力品質を満たす(であろうという未踏の仮説)フィーチャであるからだ。MVPを構築する上で、当たり前品質の機能を作らないといけない、という状況もあるかもしれない。その場合は「できるだけ作らないで検証できるMVPはどのようなものか？」という問いに変えたほうがよい。

TDDにおいても、コードの当たり前品質をプログラマーにとっての当たり前品質として考えるとクリーンコード(リーダブル、DRY、etc)やカバレッジのようなものになるのではないか。TDDでまず検証したいのはクリーンコードではなくテストを満たしているかどうかだ。(これをプログラマー的な魅力的品質と呼ぶのはちょっと抵抗があるが,…)

まとめると、まず最優先で検証したい事柄(仮説)を設定し、それを検証するために最低限の実現方法を用いて実現し、その成果の結果を測定して、実現内容をブラッシュアップしていくか、次の仮説検証に取り組むかの判断を行うという仮説検証プロセスモデルは、コードレベルからプロダクト/サービスレベルにまで通じるプロセスモデルである、という話でした。