「それ本当にMVP？」 AI時代にプロダクトが巨大化する理由をふりかえる
📄 Summarized by Claude Sonnet 4.6
2026-05-29
どんなもの？
AI 活用が進む開発現場において、「小さく作るつもりが結果的に大きくなってしまう」現象がカミナシ社内で連続して発生した。その原因を振り返り、MVP（Minimum Viable Product）定義のあり方を再考した実践的考察。 アジャイル開発において重要な「スコープを守る」行為が、AI時代においていかに難しくなっているかを具体的事例で解説している。 先行研究と比べてどこがすごい？
本稿は「AIがコードを大量生成できる時代」という新しい前提のもとでMVP概念を問い直す点が新しい。 Three.jsの開発者 @mrdoob によるAI時代の開発フロー図（AIに全部作らせてから削るモデル）を引用し、その実践的な難しさを論じた点も実務視点として価値がある。 技術や手法のキモはどこ？
AIによるコード生成が増えると「スコープ肥大化」が起きる構造的メカニズムを3点に整理：
1. 認知コストの問題：AIの出力を人間がすべてレビューするには時間がかかり、アジリティが低下する。AIの認知能力と人間の認知能力の非対称性が人間をボトルネックにする 2. 検証コストの増大：機能が増えるほど検証項目が増え、リリースサイクルが遅延する
3. サンクコストバイアス：「AIが作ったとはいえ時間やトークンを使った」という心理が不要機能の削除を妨げる 対策として「スコープを守ること＝タイムボックスを設けること」という考え方を提案。制約を設けないとAIはどこまでも機能を生成し続けるため、人間が意図的に制約を課す必要がある。 どうやって有効だと検証した？
カミナシ社内における「カミナシ 教育」「カミナシ 従業員」2プロダクトの実際のMVP開発事例を根拠として使用。
社内データとして「AIによるコード貢献量が2026年に入って格段に増加している」グラフを提示（定量的傍証）。
エンジニアとのふりかえりセッションで「開発前に戻れるなら何をするか？」という問いかけによる定性的検証も実施。
議論はある？
「AIに全部作らせてから削ればいい」という対案（mrdoob図のAIモデル）は直感的に魅力的だが、著者はレビューコスト・検証コスト・サンクコストバイアスの3点から否定的に評価している。ただし反証は社内事例に限られており、チーム規模やプロダクト特性によって結論が変わりうる余地がある。 「まだ今はインクリメンタル開発のほうがいい」という表現に「まだ」という留保があり、将来的にはAI主導の開発スタイルが逆転する可能性も示唆している。 MVPの定義そのものの再設計（AI前提での再定式化）については本稿では踏み込んでおらず、今後の課題として残されている。