なぜ「全部決まってから」は危ないか
「要件が全部固まってから発注したい」は自然な気持ちです。ただ、現場の業務は使ってみないと見えない例外が多く、机上で全部決めきるとスタートが遅れたり、作ってから「違う」となりやすいです。
大切なのは、曖昧さをゼロにすることではなく、「何を先に決めて、どこまでを初回にするか」を共有することです。
全部決まってから
小さく決めて検証
発注前に決める最小セット
画面の色や細かい項目名まで決まっていなくても構いません。次の4層が言語化できていれば、ベンダーと同じ前提で話せます。
目的
何のためのシステムか（例: 転記ミスを減らす）
対象業務
初回で扱う業務を1つに絞る
成功の定義
いつ・誰が・何ができれば成功か
権限とデータ
誰が見てよいか／置いてよい情報か
上から順に言葉にできると、見積と設計の土台になる
- このシステムで「困っていること」を一文で言える
- 初回の対象業務が1つに絞れている
- 成功の定義が「現場の言葉」で書ける
- 管理者・現場・外部で見える範囲の違いが説明できる
ヒアリングの順番
画面の見た目より、「誰が・いつ・何に困るか」を先に聞きます。順番を守ると、機能の要望が飛び交っても優先順位を戻しやすくなります。
目的 → いまの業務 → 例外・手作業 → 誰が使うか → 成功条件
MVPの切り方
MVP（Minimum Viable Product）は、簡単に言うと「現場が使える最小の仕組み」です。最初から全部門・全機能を作らず、「いちばん困っている作業」だけがきちんと回る範囲に絞ります。
- 01
1業務に絞る
例: 見積作成だけ。請求や在庫は次フェーズ
- 02
困っている作業を選ぶ
転記・二重入力・探し物など、負荷の高い所
- 03
権限は最初から
見た目より先に「誰が見られるか」を決める
- 04
成功条件を測る
例: 作成時間が半分、ミス報告が減る
後回しにしてよいこと／いけないこと
初回を小さくするために「後回し」は必要です。ただし、権限・本番アクセス・データの持ち主は後回しにすると、事故と手戻りの元になります。
後回ししやすい
- 装飾や細かい見た目
- 周辺の便利機能
- 全部門への横展開
後回しにしない
- 役割ごとの権限
- 本番・検証の分け方
- データの置き場所と持ち主
次の一歩
要件が曖昧なままでも、次の3つができれば会話が前に進みます。SHINJIDAIでは、ヒアリングからMVPの切り出しまで、設計段階で一緒に整理します。
- 01
社内1枚メモ
目的・対象業務・成功条件を短く書く
- 02
範囲を合意
ベンダーと「初回はここまで」を共有
- 03
小さく作って見る
現場で使い、次の優先度を決める
よくある質問
要件が固まっていなくても見積は取れますか？
画面一覧や細かい仕様が全部決まっていなくても、目的・対象業務・成功条件があれば概算の土台になります。先に全部を固めるより、範囲を決めて小さく始める方が見積の精度も上がりやすいです。
MVPはどれくらい小さくすればよいですか？
「1つの業務のなかで、いちばん困っている作業」がきちんと回る範囲が目安です。全部門・全機能を初回に入れず、現場が「これなら使える」と感じる最小の流れに絞ります。
権限やログは後からでよいですか？
見た目や周辺機能より先に決めることをおすすめします。後付けは手戻りと事故のもとになりやすいです。発注前の確認項目は、外注前セキュリティのコラムもあわせてご覧ください。