システムの開発工程（開発プロセス）というと、要件定義という工程からはじまります。この要件定義を分解して何をしているのかを解説します。
要件定義という工程は、システム化したいお客様からの要求をもとに、システム化する範囲を決める工程といえます。
大規模なシステム開発であれば、この工程を先に実施して、そのあとで見積となりますが、小規模な場合には、要件定義という工程ではなく、ヒヤリングとかいう打ち合わせだけで、できるだけ時間をかけずにすませてしまう場合も多くあります。
何をつくるのか、機能実現としてつくるだけでよいのであれば、つくりたいものが決まると作れます。
私たちは要求のなかから、システムの中で取り扱うデータや情報をひろいあげます。
お客様「顧客との取引実績を有効活用したい」
要求分析者「顧客とのやりとりには、何がありますか？」
お客様「問い合わせ、から始まり、打ち合わせ、見積もり提出、受注、開発、納品、請求書発送、入金、保守、。。。」
お客様「見積は、エクセルでつくっているが同じ案件で何度の書き換えが発生して管理が困っている」
🧩 システム要件定義の実際の進め方
① システム化範囲の明確化
- どこからどこまでをシステムで扱うかを定義する
- 既存業務との境界や他システムとの連携を整理する
- システム化しない部分（手作業・外部ツールなど）も明記しておく
🔸目的：開発スコープの曖昧さを排除し、責任範囲を明確にする
② 実現する機能・画面・UIの定義
- ユースケース（誰が何をするか）ごとに機能を一覧化
- 各機能に対応する画面を整理し、操作フローを明確にする
- ユーザー体験（UX）の観点から、画面遷移や操作性を検討する
🔸目的：ユーザーが実際に使う姿をイメージできる状態にする
③ 業務フローとルールの分析
- 現状業務（As-Is）と理想業務（To-Be）を比較して整理
- 業務ごとの独自ルール（承認フロー、権限、締め処理など）を明確化
- システムが担うべき部分と、人が判断・操作する部分を切り分ける
🔸目的：システムが“業務に合う”ではなく、“業務を支える”構造を設計する
④ データ分析と構造設計
- 扱うデータ項目を洗い出し、関係性を整理する（ER図など）
- 入力・更新・出力の流れを明確にし、整合性を確保する
- 将来的な拡張（新項目・他システム連携）も見据えた設計を行う
🔸目的：データの「流れ」「意味」「つながり」を設計段階で定義しておく
⑤ システム要件定義の成果物
| 種類 | 内容 |
|---|---|
| システム化範囲図 | 対象業務とシステムの境界を図で示す |
| 機能一覧・ユースケース定義書 | 機能・操作・画面・入力データを整理 |
| 業務フロー図 | 業務手順とシステム連携ポイントを明示 |
| データ項目一覧・ER図 | データ構造と関連性を定義 |
| 非機能要件書 | 性能・セキュリティ・運用・拡張要件を定義 |
💡 まとめ
要件定義は「システムを決める作業」ではなく、
「人の仕事とシステムの関係を見える化する作業」
です。
ここを丁寧に行うことで、使われる・育つシステムが生まれます。
そのためには、技術的な部分よりも、人間的なコミュニケーションの部分が重要な要素となります。
