チームの頭の中までMVPにしない

　プロダクトマネジメントでは「とにかくMVPを見つけて、早く作って試せ」ということに尽きていくわけだが、メンタリングしていると奇妙なことに出くわすことがある。

　何を解くべきかという課題の仮説について、現時点での本命とそれに準ずるB案、C案といった別の選択肢があるものだし、一つの仮説に振り切る理由もない。MVPを構想しているチームに、B案、C案の可能性を言及すると奇妙な回答が得られた。

「我々はMVPをもう決めているので、他のことを考えることはしません。」

　二の句が継げないくらいには、驚いた。確かに手元のプロダクト作りはMVPに振り切って進めるべきだ。冒頭のとおり、MVPはつくることより検証してナンボ。いち早く形にすることに力を注がなければならない。

　しかし、ろくに検証結果が出ていない状況で、可能性として考えるべき仮説を1つだけに絞るのは危険だ。そこには何の根拠もない。なぜ、プロダクト作りをMinimum Viableにするだけではなく、チームの頭までMinimum Viableにしてしまっているのか？

　実際のところ、MVP開発の着手が早すぎるとこういうことが起こる。課題仮説の検証が十分でないところで、最初はプロトタイプのつもりだったものがだんだん本気になってきていつのまにかMVP開発が始まっていたパターン。

　チームと話していると、なるほどと気づいた。2つ以上のことを追っていく、という考え方に慣れていない。「今やろうとしていること以外をするには、リソースがない」という言葉で現れてくる。そして、これがリーンの考え方だという人もいる。

　リーンの原則って、知っている？　どこにも思考を止めよなんてことは書いてないんですよ。

原則1：ムダをなくす
原則2：品質を作り込む
原則3：知識を作り出す
原則4：決定を遅らせる
原則5：速く提供する
原則6：人を尊重する
原則7：全体を最適化する

　ムダをなくすを指して言っているとしたら、いつから、本命以外がムダだと錯覚していた？　だよ。いつ、その検証が終わったのよ、と。これからでしょう。むしろ、原則3「知識を作り出す」、原則4「決定を遅らせる」、このあたりから、1案に頭を支配されることの違和感を感じてほしい。

　しかし、気持ちは分かる。別々のことを考えることの集中のつかなさ、気持ち悪さ。一つの思考に絞れたほうが仕事がシンプルで済む。ましてやチームで取り組んでいるのだ。それぞれがバラバラの思考と指向だと動いていくのに相応の労力がかかる。

　いやでもね。チームだからこそ、複数の案を追っていけるようにしましょうよ、と。1人で考えたら、脳が分裂を起こさないといけないだろうけども、チームなら最初から分裂しているわけじゃない。

　その上で、チームとしてのまとまりある動きをつくるためにはどうやってつくるのか？　そこでアジャイルですよ。今日はここまで。