IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→法人化済)

早期リリースが何故難しいか、MVPが小さくならない事情

チームの人数が増えれば増えるほど、早期リリースが難しくなるという事象を何度か体験しました。
「早めにMVPでリリースしましょう」は成り立ちません。何が起こるのでしょうか。

 

「MVPで小さくリリースしましょう」から始まる

最初の時点ではここでコンセンサスは得られます。
まあそうは言っっても「MVPとは」あたりから自分が説明することが多いのですが。

80点を目指してしまうプロ達

プロは、プロですから、自分のジャンルに対して「これは最低限必要だよね」というものを幾つも持っています。
その「これは最低限必要だよね」がでかいのです。
MVPはたぶん40点くらいです。

 

MVPは、プロの言う最低限必要なものより小さい

例えばCRUDという言葉があります。
あるデータを、Create Read Update Deleat(作成、読み込み、更新、削除)できるという4つの基本機能のことですが、早期リリースではひょっとしたら「作成」「読み込み」だけでいいかもしれません。
でも、そのためにはプロの言う「更新、削除できないとまずくないですか!?」をPOが「大丈夫です」と言えなければなりません

これが1箇所ならまだいいんですが、プロが入る毎にそのジャンルで「必要最低限」の提案が入りどんどん大きくなっていきます。
デザイン、バックエンド、セキュリティ、営業、運営者・・・
必要最低限が全て満たされた、αと言うよりはもうβか製品版と言ったほうがいいそれは、もうかけた工数ベンチャーと呼べないものになっているでしょう。
まさにパーキンソンの法則仕事の量は、完成のために与えられた時間をすべて満たすまで膨張するです。

 

この現象を防ぐのが難しい理由

1.メリットの共有が難しい

メリットはまずリリースすることでユーザーの声が聞ける、あるいは1人もユーザーがつかないという状態が得られることですが、POは基本的に「このサービスはうまくいく」と思っているので前提が違います。リーン的な思考=全て実験であり仮説である、などと叫ばれて入るものの、実際には皆「上手くいかなかったら」のことを考えない傾向にあります。熱量が高い人ほどそうです。(私なんかは常に冷めてますw)

なので、リリース後にpivotするかもとか、そのためのリソースを残しておこうみたいな発想に至りにくい気がします。

 

2.PO以外が「それ要らないよね」と言いづらい

プロが言う「これは流石に必要でしょ?」は、聞くと確かにそうだと頷くものばかりです。これを否定するのは、プロジェクトの当事者であり、各役割の人より権限がある必要があります。POが「必要だね」って言ったときに否定するのはなかなか難しいです。

 

3.POですら否定は難しい

POだけが「別にそれ要らない」と言っても、例えばメンバー5人から「無いとマズイでしょ、何考えてんの?」と言われたら厳しいのではないでしょうか。

 

4.外注した場合、受注者は期限が延びることで困らない

受注者は工数圧縮や、リリース日を早めることに対して何らメリットがありません。デメリットすらあります。だから彼らは基本的に品質固定で思考を走らせます。

 

どのくらい工数が増大するか?

経験則としては、1.5〜3倍くらいです。例えばリリース期限を1.5倍にして、1.3倍残業すれば計2倍なので、何とかなってしまうんですよね。

 

タスクを優先順に並べて・・ができない理由

タスクというのは割と密結合なんです。
1個「これは必要だろう」を受け入れたら、整合性を取るために他のタスクが発生したり、同じ基準に該当してしまう他のタスクが発生してしまいます。
結果的にリリース単位の境目が大きくなってしまうんです。

もしこれがリリース済みで、定期リリースしているのならもう少し楽でしょう。
リリース単位はもう少し小さくできるはずです(リリース後でもそうなってないプロジェクトを何個か体験しましたが・・・これはまた別の話)

 

この現象を防ぐ方法

1.人を増やさない、プロを入れない

2.絶対的なリリース日を先に決めてしまって、POがそれを厳守する

3.全員がMVPの観点を持つ(難しい)

4.サービスリリース経験がある人がPO

5.外注しない

 

でも究極的には「1人か2人でやる」な気がします。