システム開発の相談では、「まず要件定義をしましょう」という話になりがちです。もちろん要件定義は必要ですが、その前に発注者側で決めておくべきことがあります。
目的、対象範囲、優先順位、成功条件が曖昧なまま要件定義に入ると、機能一覧は増えても、何のためのシステムなのかが見えにくくなります。
機能より先に、目的を決める

「顧客管理を作りたい」「予約管理を作りたい」という言い方は、まだ目的ではありません。目的は、その仕組みによって何を改善したいのかを表すものです。
同じ予約管理でも、目的が「電話対応を減らす」なのか「空き枠の見落としを防ぐ」なのか「営業状況を可視化する」なのかで、必要な機能は変わります。
- 何に一番時間がかかっているのか
- どのミスを減らしたいのか
- 誰の判断を速くしたいのか
- どの状態になれば改善したと言えるのか
対象業務と対象外業務を分ける

システム化の範囲を広げすぎると、最初の開発が重くなります。逆に範囲が狭すぎると、現場の流れと合わず、結局二重入力が残ります。
大切なのは、最初に扱う業務と、今回は扱わない業務を明確に分けることです。対象外を決めることで、見積もりやスケジュールの精度も上がります。
- 今回必ず扱う業務
- 連携だけ考える業務
- 当面は既存運用のまま残す業務
- 将来的に追加を検討する業務
優先順位を決めておく

要件定義では、欲しい機能が次々に出てきます。そのときに優先順位がないと、すべてが必須に見えてしまいます。
限られた予算と期間で成果を出すには、最初のリリースで必要なもの、後から追加できるもの、そもそも不要かもしれないものを分ける必要があります。
- 初回リリースに必要な機能
- 運用しながら追加する機能
- 効果が不明なので試して判断する機能
- 現時点では作らない機能
成功条件を、確認できる形にする

要件定義の前に、完成をどう判断するかも考えておきたい点です。画面ができていることと、業務が改善していることは同じではありません。
受入時に確認する観点を先に持っておくと、開発中の議論も具体的になります。
- 現場担当者が迷わず入力できる
- 必要な一覧や集計が確認できる
- 二重入力が減っている
- 権限ごとに見える情報が分かれている
- 運用担当者が更新方法を理解している
まとめ
- 要件定義の前に目的を決める
- 対象業務と対象外業務を分ける
- すべてを必須にしない
- 成功条件を確認できる形にする
- 機能一覧ではなく業務改善を基準にする


