要件は、通常の流れの中にはあまりありません。本当の要件は、例外の中に隠れています。取消、差し戻し、担当者不在、期限超過。「いつもと違うとき、どうするか」を決めることが、要件整理の山場です。
システム化したいことはあっても、いざ話すと何から決めればよいか分からなくなる。これは、機能名から考えようとするときに起きがちです。要件とは、その業務で守りたい条件のこと。画面、ボタン、通知の前に、誰が、何を見て、どこで判断し、どの記録を残すかを決めます。
(想定例)受発注をシステム化したいと相談に来た会社も、最初は機能の話で止まりました。一覧画面、検索、通知。決まりそうで決まりません。流れが変わったのは、「返品が出たら」「担当者が抜けたら」と例外を一つずつ並べてから。守りたい条件が言葉になると、必要な画面は後から付いてきました。
目的は、一つに絞る
最初の目的は、できるだけ一つに絞ります。二重入力を減らす、承認漏れを減らす、最新版を一つにする、対応状況を見えるようにする。目的が絞れると、作る範囲もおのずと決まります。
- 何を減らしたいか
- 何を早く知りたいか
- 誰の確認負担を下げたいか
- どのミスを防ぎたいか
例外を、先に書き出す
冒頭のとおり、要件は例外に宿ります。通常の流れだけでなく、取消、差し戻し、再発行、担当変更、期限超過を先に書き出す。例外を後回しにすると、運用開始後に画面や権限の作り直しが起きます。
- 取り消すときに記録を残すか
- 差し戻し理由を誰が見られるか
- 期限を過ぎたとき誰に知らせるか
- 古いデータを消すのか、保管だけにするのか
運用後の直し方も、要件に入れる
システムは、作ってからが本番です。使い始めると、項目名、入力順、一覧の見方、通知の頻度など、直したい点が必ず出ます。最初から改善のサイクルを見込んでおくと、現場に残る仕組みになります。
要件は例外に宿る
要件整理では、画面の細かい見た目より先に、目的、使う人、判断ルール、例外、改善方法を決めます。小さく始めても、この5点がそろっていれば運用に乗せられます。手が止まったら、通常の流れではなく、例外から書き出してみてください。