入れすぎると起きること
「せっかく作るなら」という気持ちで機能が増えると、開発期間が伸び、現場が使いこなせずに終わることがあります。初回は「動く最小」を守ることが、のちの拡張につながります。
初回に盛る
納期が遅れる
現場が使わない
改善のフィードバックが遅い
最小で出す
早く現場で試せる
使われ方が見える
次の優先度が決まる
初回に入れない方がよい7つ
業種や案件によって例外はありますが、次の7つは初回MVPから外し、使われ方を見てから検討するのが安全です。
- 01
全部門への横展開
1部門で定着してから
- 02
高度なレポート・BI
基本操作が回ってから
- 03
細かいUI装飾
機能優先、見た目は後
- 04
全外部システム連携
必須連携だけ先に
- 05
完璧な自動化
手作業併用で始めてよい
- 06
多言語・多拠点対応
本社・主拠点で先に
- 07
カスタムワークフロー全網羅
典型フロー1本から
後回しにしてはいけないもの
「入れないリスト」と混同しやすいのが、セキュリティとデータの基盤です。ここは初回から入れておく必要があります。
初回に入れない
- 装飾・便利機能
- 横展開・多言語
- 完璧な自動化
初回から入れる
- 役割ごとの権限
- 操作・認証のログ
- データの置き場所と持ち主
よくある質問
MVPはどれくらい小さくすればよいですか？
「1つの業務のなかで、いちばん困っている作業」がきちんと回る範囲が目安です。全部門・全機能を初回に入れないことが大切です。
権限やログも後回しにしてよいですか？
いいえ。見た目や周辺機能は後回しにしやすいですが、権限・ログ・データの持ち主は初回から決めることをおすすめします。
「入れないリスト」をベンダーと共有すべきですか？
はい。「初回はここまで」とセットで「入れないもの」を書面で共有すると、スコープの認識ずれを防げます。