2013年2月23日土曜日

リーンスタートアップMVPと狩野モデル


「リーンスタートアップ」Eリース著今一大ムーブメントを起こしているような感じですが、この書籍は非常に実務的で面白い。


この書籍に書かれているMVPという言葉が、この考え方を実現するもっとも重要なポイント。MVPとは、minimum viable productの略で、私は、製品の仮説検証に必要最小限のものと理解しています。

製品を完成させるためには莫大な開発コストがかかります。要求が明確で、お金の支払いが確実であれば、すべて開発してもよいのですが、新製品開発のような、売れるかどうかわからないというリスクがある場合、全部完成させるのではなく、売れるかどうか検証できる最低限の機能を作り仮説検証していく。リーンスタートアップにはこの具体的なプロセスが紹介されています。

このリーンスタートアップの考え方は、リーン製品開発の「意思決定を遅らせる」という考え方と対立しているのではないか?昔はやったインキュベーション理論とだいぶ違うのではないか?といった論点がありそうですが、実務的に考えて非常に現実的だと思います。私のように開発資金が少ない小さな会社ではこのやり方をよく考えて実施しなければなりません。

今リーンスタートアップの考えを参考に開発を行っているのですが、現実には要求機能のうちどこまでをMVPとすべきかは非常に悩むところです。

要求機能は分解していますが、その中で限られた開発費の中でどれを実装すべきか結局は私の直観できめている状態です。

直観は大事ですが、直観だけだと合意形成にこまります。
私は一人で事業をしているわけでは内ので様々な人にお願いして合意形成していかなければなりません。どこまで開発するのかこれは重大な意思決定です。私の直観だけでなくある程度の合意形成できる仕組みをもっていないと「しんどい」のが現実です。

そこで今狩野モデルを使ってシステマチックにMVP要求を確認する方法があるのではないかと検討しているところです。

品質工学の狩野博士によると、品質とは「当たり前品質」「一元的品質」「魅力的品質」の3つにわけられるとしています。

・当たり前品質:あって当たり前とうけとめている特性。たとえばホテルでいえば清潔なタオルや熱いお湯。

・一元的品質:この範疇にある特性については、お客様は自分のニーズがうまく満たされないとがっかりし、うまく満たされれば満たされるほど満足度を感じる。(中略)お客様の問い合わせにノロノロと対応すれば、お客様はがっかりするが、速やかに対応すればお客様は喜ぶだろう。その中間であれば、おそらく何の反応も起きない。

・魅力的品質:この範疇にはいる特性は、お客様を良い意味で驚かせる。お客様もやってもらえると思っていなかったニーズ、誰もが期待していなかったニーズを満たすことになる。期待されていなかったので、なくてもしかたがないと思うだけで負の効果はないが、あれば正の効果を持つ。

引用「第4世代の品質経営」ブライアンジョイナー著

この3つの区分方法はアンケート調査法が確立されておりシステマチックに分類することが可能です。

ファイルを保存するとか、セキュリティが確保されているといった「当たり前品質」について仮説検証する必要はないでしょう。しかし「魅力的品質」は私が魅力的だと思っているだけで、多くの人にとっては魅力的ではないかもしれません。これをまず仮説検証しなければなりません。

こう考えると機能を洗い出したら、狩野モデルで分析し、「魅力的品質」となるものをまず検証できるようにすればよいといえるでしょう。

「第一段MVPとは、パワーポイントなどで検証できない自分が魅力的品質と思っている機能」

次の段階で検証すべきは、「ニーズがあるけど買ってくれるのか?」に対する検証です。価格を含めた検証が必要です。
ここにきたら、「もの」が必要です。そのとき「魅力的品質」をまず実装し、買って頂くのであれば「当たり前品質」もある程度実装しておかないといけないでしょう。

ここまでの結論としてわかることはMVPには「一元的品質」は含めなくてよい。と言えるのではないかという事です。何をやるべきかより、何をやらないでよいのかわかっている方が重要です。もしこの仮説が正しければシステマチックに考えなければならない事を減らすことができるでしょう。

この考え方は私の仮説であって、まだ検証できていません。傑作「アジャイルな計画と見積もりづくり」マイクコーン著に書かれている順番と異なっています。
実際にやってみて検証しようと思っています。ご意見ある方はぜひアドバイスください。


ところでリーンスタートアップを一見してよむと、MVPをまず開発すると読めてしまいます。しかしこれはよく考えないと危険です。ものをソフトウェアやハードウェアとして実装しなくても、パワーポイントやエクセルのはりぼてだけで検証できることは多々あるからです。

それに、我々がまず検証すべき事は機能の必要性でも、それによって実現するメリットでもなく、その機能で解決できる「問題の存在」です。

問題の存在は、機能がなくても十分出来ます。お客様の所に行って、「こんな問題ありますか?」と聞けば良いだけです。質問をわかりやすくするために困りごとの状況をかいたパワーポイントのスライドをもっていくだけで検証できるでしょう。
パワーポイントなどでは検証できないと思っているのは思い込みに過ぎず大部分は検証できるでしょう。

このプロセスは「ランニングリーン」アッシュ・マウリャ 著に具体的に書かれています。

上記リンクの書籍はそれぞれ傑作と思える物で別にまとめたいと思っています。

0 件のコメント:

コメントを投稿