システムの要望を整理したい非エンジニアの担当者
開発会社へ『こんな画面がほしい』と伝える前に、整理したいことがあります。誰が、どの仕事で使い、何ができたら完成なのか。この三つを決めるだけでも、認識のずれを減らせます。
- 01目的と利用者
- 02通常・例外の手順
- 03権限と品質
- 04完成の確認方法
矢印の順に、自社の状況へ置き換えて確認しましょう。
1. 目的と対象範囲を言語化する
目的を『便利にする』で終えず、誰のどの負担を減らすかを書きます。今回は作らない仕事も決めると、計画が広がりすぎるのを防げます。
業務の開始条件と終了条件を決めると、範囲が見えます。たとえば受注管理なら、案件登録から受注までか、請求や入金まで含むかで必要な設計が変わります。関係部署と外部サービスを確認し、途中で渡す情報を整理します。
2. 情報と業務フローを揃える
通常の仕事の始まりから終わりまでを並べます。使うデータと、承認する人も書きます。取消、差し戻し、入力漏れの扱いを忘れないでください。
例外として取り消し、差し戻し、重複、担当者不在、期限超過を確認します。業務担当者が普段は暗黙に処理している部分ほど、システムでは判断条件が必要です。複雑な図を作るより、実際の一件を最初から最後まで追う方法が役立ちます。

3. 権限と品質を機能と一緒に決める
社員と管理者が同じ操作をできてよいとは限りません。見られる情報と変更できる情報を決めます。速度やバックアップも、画面と一緒に相談しましょう。
利用端末、件数、応答時間、バックアップ、停止時の対応を業務の重要度に合わせて決めます。IPAの上流工程に関する資料は、発注側と開発側の合意形成を考える参考になります。『使いやすい』『速い』といった言葉を、確認可能な条件へ変えることが重要です。
参考:IPA:企画・要件定義
4. 受け入れ条件と変更管理を決める
『正しく動いた』と判断する具体例を作ります。途中で要望が増えた場合の、費用と日程の確認手順も合意します。
要件は検討中に変わることがあります。変更を禁止するのではなく、追加理由、費用、期限、影響を記録し、責任者が判断する手順を設けます。議事録と未決事項の一覧を共有し、誰がいつまでに決めるかを明確にします。
判断に使う比較表
| 項目 | 書く内容 | 例 |
|---|---|---|
| 目的 | 解決する負担 | 受注の二重入力を減らす |
| 利用者 | 役割と権限 | 担当者・承認者・管理者 |
| 情報 | 入力と正本 | 顧客ID・案件状態 |
| 合格条件 | 試験シナリオ | 差し戻し後に再申請できる |
相談前のチェックリスト
- 対象と対象外を決めた
- 通常と例外のフローを整理した
- 閲覧・編集・承認の権限がある
- 品質条件を具体化した
- 受け入れ試験と変更判断の担当がいる
よくある質問
仕様書がなくても相談できますか?
できます。現行の業務フローや帳票、困りごとから整理できます。最初から詳細な画面仕様を用意する必要はありません。
要件定義中に機能を変えられますか?
変更の理由と影響を確認して判断します。費用や期限に影響するため、未記録の口頭変更は避けます。
NEXT STEP / 次の一歩
自社の場合を、
一緒に整理する。
作りたい画面より、現在の一件の仕事がどう流れるかを教えてください。必要な入力、判断、例外、完成条件を一緒に整理します。
