チームの人数が増えれば増えるほど、早期リリースが難しくなるという事象を何度か体験しました。
「早めにMVPでリリースしましょう」は成り立ちません。何が起こるのでしょうか。
「MVPで小さくリリースしましょう」から始まる
最初の時点ではここでコンセンサスは得られます。
まあそうは言っっても「MVPとは」あたりから自分が説明することが多いのですが。
80点を目指してしまうプロ達
プロは、プロですから、自分のジャンルに対して「これは最低限必要だよね」というものを幾つも持っています。
その「これは最低限必要だよね」がでかいのです。
MVPはたぶん40点くらいです。
MVPは、プロの言う最低限必要なものより小さい
例えばCRUDという言葉があります。
あるデータを、Create Read Update Deleat（作成、読み込み、更新、削除）できるという4つの基本機能のことですが、早期リリースではひょっとしたら「作成」「読み込み」だけでいいかもしれません。
でも、そのためにはプロの言う「更新、削除できないとまずくないですか！？」をPOが「大丈夫です」と言えなければなりません。
これが1箇所ならまだいいんですが、プロが入る毎にそのジャンルで「必要最低限」の提案が入りどんどん大きくなっていきます。
デザイン、バックエンド、セキュリティ、営業、運営者・・・
必要最低限が全て満たされた、αと言うよりはもうβか製品版と言ったほうがいいそれは、もうかけた工数がベンチャーと呼べないものになっているでしょう。
まさにパーキンソンの法則「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」です。
この現象を防ぐのが難しい理由
１．メリットの共有が難しい
メリットはまずリリースすることでユーザーの声が聞ける、あるいは１人もユーザーがつかないという状態が得られることですが、POは基本的に「このサービスはうまくいく」と思っているので前提が違います。リーン的な思考＝全て実験であり仮説である、などと叫ばれて入るものの、実際には皆「上手くいかなかったら」のことを考えない傾向にあります。熱量が高い人ほどそうです。（私なんかは常に冷めてますｗ）
なので、リリース後にpivotするかもとか、そのためのリソースを残しておこうみたいな発想に至りにくい気がします。
２．PO以外が「それ要らないよね」と言いづらい
プロが言う「これは流石に必要でしょ？」は、聞くと確かにそうだと頷くものばかりです。これを否定するのは、プロジェクトの当事者であり、各役割の人より権限がある必要があります。POが「必要だね」って言ったときに否定するのはなかなか難しいです。
３．POですら否定は難しい
POだけが「別にそれ要らない」と言っても、例えばメンバー５人から「無いとマズイでしょ、何考えてんの？」と言われたら厳しいのではないでしょうか。
４．外注した場合、受注者は期限が延びることで困らない
受注者は工数圧縮や、リリース日を早めることに対して何らメリットがありません。デメリットすらあります。だから彼らは基本的に品質固定で思考を走らせます。
どのくらい工数が増大するか？
経験則としては、1.5〜3倍くらいです。例えばリリース期限を1.5倍にして、1.3倍残業すれば計2倍なので、何とかなってしまうんですよね。
タスクを優先順に並べて・・ができない理由
タスクというのは割と密結合なんです。
１個「これは必要だろう」を受け入れたら、整合性を取るために他のタスクが発生したり、同じ基準に該当してしまう他のタスクが発生してしまいます。
結果的にリリース単位の境目が大きくなってしまうんです。
もしこれがリリース済みで、定期リリースしているのならもう少し楽でしょう。
リリース単位はもう少し小さくできるはずです（リリース後でもそうなってないプロジェクトを何個か体験しましたが・・・これはまた別の話）
この現象を防ぐ方法
１．人を増やさない、プロを入れない
２．絶対的なリリース日を先に決めてしまって、POがそれを厳守する
３．全員がMVPの観点を持つ（難しい）
４．サービスリリース経験がある人がPO
５．外注しない
でも究極的には「１人か２人でやる」な気がします。
