早くつくりたいけれどMVPが避けられるのはなぜか

こんにちは、
今日はMVP（Minimum Variable Product)についての内容です。

• クイックにリリースしたい

• 無駄を省きたい

• 細かいことは走りながら決めたい

とみんな言うけれど、実際にはなかなかスコープは分割されずにリスクの大きなプロジェクトになりがちです

MVP、PoC、アジャイルだとかそんな言葉はよく飛び交っているのに実際には小さく試すということになりにくい
こんな悶々とした声を聞くことも多いのでいくつか思いつく理由をかんがえてみます

理由1:不安だから

MVPに組みまれなかったスコープが、忘れ去られてしまったりすることに不安を感じるひとがいます。
そのアイディアを生み出したひとや、その人から指示を受けているひとには特に強く働く心理です。
「最優先でなくてもいいけど、全部つくれるのはいつ？」
という言葉がその兆候です。

こういう場合にはMVPの目的や前提を確認しましょう。
もしかするとMVPは
「間に合わせることができないので諦めた妥協した姿」
「消極的目標の表れ」
だとか誤解されているかもしれません

MVPはそうではなく考えたスコープや方向性が正しいのかを検証するものです。先の見えない戦場で本隊を守りリスクを軽減するために派遣する身軽な斥候とか先遣隊みたいなものなので、そのような未来の不安を解消するための手法であることを伝えましょう。

理由2： 計画と予測可能性を重視している

大きい組織になるほど計画というものが重視されるようになります。
予算計画などでは、次の年には何を作り、どれだけの予算やリソースが必要であるか？ということを提出しなければなりません。
そのような計画を管理する立場の視点で考えれば、できるかぎり未来のことを”計画”として出してもらいそれがより固定的で約束されることを望みます。
これはMVPの考え方とは根本的に相性の悪いものです。

この場合にできることはそのような管理側の基準としている計画を開発チームのプランニングとは切り離してコントロールをする必要があります。
ただし、関連付けは維持されるようにしておく必要があります。

予算計画上に記載される計画と実行段階での計画はコンテキストが異なるものです。前者はできうるかぎり柔軟性をもたせたものにしておくことが必要です。
そしてそのような視点を実行段階のプロダクトプランニングに過度に介入させないようにしましょう。
コンテキストの異なる状態でおなじ「プロジェクト」や「計画」という言葉を用いてコミュニケーションすることは混乱を招く結果につながります

理由３：計画ができる人と説明する人が別である

なにかモノづくりをする時に実際に現実的な計画を立てることができるひとと、それを説明するひとが分かれているということも珍しくはありません。

このような場合も、MVPが避けられスコープが肥大しやすい要因となります。プロダクト開発で寄せられる要求というのはいわば関係者の期待と不安を煮詰めたものです。

関係者の数が多くなり、開発チームとの距離が離れていくほどに「やらないこと」を決め、要求の前提となっている仮説を客観的に検証していくことに合意形成をとっていことはタフなものになります。
　この役割を担う人がMVPを作る理由やその合理性を説明できない場合には、MVPが採用されることは難しくなります。

このため、職位や所属を問わず、説明責任を担えるひとが説明を実施できるよう適切な役割分担をすることが大切です。
　要件定義やプランニングというのは、ステークホルダーの意向や指示をただ代弁するのではなくて、それを評価して厳しく取捨選択をしていく行為です。

理由4：野心・プライドが高すぎる

「大きなことを成し遂げたい」という欲求は誰もが抱くものです。
MVPという名のもとに自分の掲げた構想やアイディアが小さく、インクリメンタルなものにされてしまうことに拒否感を覚えるひともいることを覚えておきましょう。
またこれは、「すでに誰に約束してしまっているか？」によっても大きく変わってくることです。

えらい人や自分の将来を左右するような人にすでに約束をしてしまっている場合、当面のゴールが挑戦的でないものに変換されてしまうことや、「不確実である」と断定をされることはメンツを重んじるひとの心を揺さぶるものにもなり得ます。

誰もがこの罠にはまる可能性はあります。
多くの場合プロダクト開発はチームで行うもので一人でできるものではありません。
　前述したように誰からのものであっても、要求やアイディアを批判的に検証し、現実的な計画を立案し最後まで実行することができる専門性をもっているということでないのならば、誰かに大きな約束をする前に信頼できる専門家からアドバイスを得ることがたいせつです。

重要なのは、誰かのアイディアを実現させるのではなく、成果を最大化することです。　

理由5：背景、前提、制約、そして最小価値の齟齬

MVPを考える上ために必要なことは、
前提と制約がなにか？
取りうる選択肢がなにか？
意味のある価値というものがなにか？
を判断することです

言い換えればこの感覚が一致していないかぎり、MVPの姿の合意形成をすることは難しなり、なぜスコープを絞らなければいけないのか？ということも理解しにくいものになります。

最小単位の価値とは、仮説を検証しうる価値です。
まず要求も検証されるべき仮説にすぎないことであるということに認識がそろっていないとこの話は前に進みません。

何をわかっていて、わかっていないことはなにか？どのようなリスクがありどう極小化していけるのか？
を主要な関係者とすり合わせておく必要があります。

すでに事実として確認できていることと、確認できていないことを明確にわけましょう。
実装する前にさらに確認することはなにか？
それができるのか？

またなによりも、
自分の信じたいものを信じてしまう追認バイアスが起きていないのか？
適切な要件を決めるということがこのメンバーでできるのか？
と自分たちがやりたいとおもっていることに誰よりも厳しい目を向けることが必要です。

まとめ

誰もが、無駄なことで忙しくなることは望んでいないですし、最小の苦労で最短のルートで価値を生み出したいと思っています。
そして、自分の欲しいものを伝えたりアイディアを言うことはできても、そのために何かを選ぶということは苦手な人は多いです。

選ぶということは別の何かを選ばないということの宣言であり、
これは本質的に誰かのストレスになりえることであると理解する必要があります。

小さなスコープ、小さなチーム、少数精鋭という言葉がポジティブな文脈で捉えられる一方でそれは、選ばれないその他を多く生み出すということと表裏です

交渉や説明は避けられないとしても、関係者から寄せられるアイディアや自分たちのプライドやメンツよりも、プロダクトが解くべき問題と、価値を提供する相手にフォーカスをしましょう。
そうなれば、MVPが後ろ向きで臆病な計画のようには誤解されないようになると思います。

おわり