システム開発の要望が増えすぎる。初回に作る機能と後回しにする機能の分け方

初回に機能を増やしすぎると、現場で試す時期が遅れる

「せっかく作るなら」という気持ちで機能が増えると、開発期間が伸び、現場が使いこなせずに終わることがあります。初回は「動く最小」を守ることが、のちの拡張につながります。

機能を盛る / 最小で出す

初回に盛る

納期が遅れる

現場が使わない

改善のフィードバックが遅い

最小で出す

早く現場で試せる

使われ方が見える

次の優先度が決まる

業種や案件によって例外はありますが、次の7つは初回MVPから外し、使われ方を見てから検討するのが安全です。

入れない方がよいもの（7つ）

「入れないリスト」と混同しやすいのが、セキュリティとデータの基盤です。ここは初回から入れておく必要があります。

入れない vs 入れる

初回に入れない

初回から入れる

業務の課題整理から、設計・開発・導入まで

課題の整理から伴走

要望を対象業務と利用者の判断に結びつけ、初回に必要な機能と後の追加を整理します。権限・記録・連携など外せない条件も含めて範囲を提案。合意した設計・実装と試行から次の判断へつなげます。

初回は、困っている業務と現在の状況の概要で構いません。調査・設計・開発の範囲と費用は、着手前に合意します。

ID・パスワードや顧客データは、フォームに記載しないでください。

MVPはどれくらい小さくすればよいですか？

「1つの業務のなかで、いちばん困っている作業」がきちんと回る範囲が目安です。全部門・全機能を初回に入れないことが大切です。

権限やログも後回しにしてよいですか？

いいえ。見た目や周辺機能は後回しにしやすいですが、権限・ログ・データの持ち主は初回から決めることをおすすめします。

「入れないリスト」をベンダーと共有すべきですか？

はい。「初回はここまで」とセットで「入れないもの」を書面で共有すると、スコープの認識ずれを防げます。