システム開発を検討しているものの、
「要件定義は何から始めればよいのか分からない」
「どこまで決めてから開発会社へ依頼すればよいのか」
「必要な機能を伝えれば要件定義は終わりなのか」
と悩む方は少なくありません。
要件定義は、システム開発の方向性を決める重要な工程です。
ここが曖昧なまま開発を始めると、
- 必要な機能が抜ける
- 想定していた業務フローと合わない
- 開発途中で仕様変更が増える
- 追加費用が発生する
- 納期が遅れる
- 完成したのに現場で使われない
といった問題につながります。
IPA（情報処理推進機構）でも、要件定義はシステム開発の上流工程の一つとされており、企画・要件定義・基本設計といった上流工程の取り組みが完成するシステムの品質に大きく影響すると説明されています。
しかし、要件定義というと難しい専門用語に感じるかもしれません。
実際には、
なぜシステムを作るのか
↓
現在どのような業務をしているのか
↓
何に困っているのか
↓
どういう業務に変えたいのか
↓
そのためにシステムへ何が必要なのか
という順番で整理していけば、考えやすくなります。
この記事では、システム開発における要件定義の進め方を7つの手順に分け、必要な成果物や失敗を防ぐポイントまで解説します。
要件定義とは
要件定義とは、
「どのようなシステムを作るのか」を開発前に明確にする工程
です。
例えば在庫管理システムを開発するとします。
単に、
在庫管理システムを作りたい
だけでは、開発は始められません。
少なくとも、
誰が使うのか
何の商品を管理するのか
在庫をどの単位で管理するのか
入庫・出庫をどう登録するのか
拠点は複数あるのか
CSV出力は必要か
スマートフォンから使うのか
何人が同時に利用するのか
どのような権限が必要か
などを決める必要があります。
これらを整理し、発注者と開発者の認識を合わせるのが要件定義です。
要件定義は「機能を決めるだけ」ではない
要件定義というと、
ログイン機能
検索機能
登録機能
CSV出力
など、画面や機能だけを決めるものと思われがちです。
実際にはそれだけではありません。
大きく分けると、
業務要件
機能要件
非機能要件
データ要件
外部連携要件
運用要件
移行要件
などを整理します。
システムインテグレータ社の解説でも、要件定義では開発背景、課題・解決策、業務要件、機能要件、非機能要件、実行計画などを整理すると説明されています。
要件定義と要求定義の違い
混同されやすい言葉に、
要求
と、
要件
があります。
厳密な使い方は組織や開発方法によって異なりますが、実務では次のように考えると分かりやすいでしょう。
要求
利用者・発注者が、
こうしたい
と考えていることです。
例えば、
スマートフォンから在庫を確認したい
在庫切れを減らしたい
Excel集計をなくしたい
月末の棚卸し作業を短くしたい
などです。
要件
要求を実現するために、
システムとして何を実現するのか
まで整理したものです。
例えば、
在庫一覧画面をスマートフォン対応する
在庫が10個以下になった場合に通知する
全拠点の在庫情報を一つのDBへ保存する
棚卸し結果をCSVで出力できるようにする
などです。
つまり、
要求
=
やりたいこと
要件
=
実現するために必要な条件
と考えると理解しやすくなります。
システム開発の要件定義の進め方【7ステップ】
要件定義は、いきなり機能一覧を作るのではなく、順番に整理することが重要です。
おすすめは次の7ステップです。
STEP1
目的・ゴールを整理する
↓
STEP2
現状業務を整理する
↓
STEP3
課題・要求を洗い出す
↓
STEP4
新しい業務フローを決める
↓
STEP5
システム要件を定義する
↓
STEP6
優先順位・対象範囲を決める
↓
STEP7
要件定義書として合意する
それぞれ解説します。
STEP1｜システム開発の目的・ゴールを整理する
最初に決めるべきなのは、
何を作るか
ではありません。
先に、
なぜ作るのか
を整理します。
例えば、
在庫管理システムが欲しい
だけでは目的が分かりません。
背景を確認すると、
現在は拠点ごとにExcel管理
↓
毎週、本社担当者がExcelを統合
↓
集計に毎週3時間かかる
↓
ファイルによって数字が違う
↓
全社在庫をリアルタイムで把握したい
という課題があるかもしれません。
この場合、目的は、
在庫管理システムを作る
ではなく、
複数拠点の在庫情報を一元化し、
手作業によるExcel集計をなくす
です。
この違いは非常に重要です。
ゴールは可能なら数字にする
例えば、
業務を効率化したい
だけでは、システム導入後に成功したのか判断できません。
可能なら、
毎週3時間かかっている集計を30分以内にする
在庫確認のための電話・メールを80％削減する
月末棚卸しを2日から1日に短縮する
など、目標を具体化します。
これが後の機能優先順位にも影響します。
STEP2｜現状業務を整理する
次に、
現在どのように仕事をしているか
を整理します。
これを「As-Is」と呼ぶ場合があります。
例えば在庫管理なら、
商品入荷
↓
担当者がExcelへ入力
↓
各拠点がそれぞれファイル管理
↓
毎週金曜日に本社へ送信
↓
本社担当者がExcelを統合
↓
管理職へ報告
という業務かもしれません。
これを図や表にして整理します。
現場担当者へのヒアリングが重要
経営者や管理職だけに聞くと、
想定している業務
と、
実際の現場業務
が違う場合があります。
例えば管理職は、
担当者が毎日Excelを更新している
と思っていても、実際には、
忙しいので週末にまとめて入力している
かもしれません。
そのため、
業務責任者
実際の利用者
管理者
システム担当者
など、複数の関係者からヒアリングします。
現状業務では例外処理まで確認する
要件定義で抜けやすいのが、
通常業務ではないケース
です。
例えば注文管理なら、
通常注文
だけでなく、
キャンセル
返品
一部返品
注文内容変更
二重注文
支払い失敗
などがあります。
現場へ、
通常と違うケースでは、
どのような処理をしていますか？
と確認すると要件漏れを減らせます。
STEP3｜課題・要求を洗い出す
現状業務が整理できたら、課題を洗い出します。
例えば、
| 現状 | 課題 |
|---|---|
| Excelを拠点別管理 | 最新データが分からない |
| メールでファイル送付 | バージョン管理が難しい |
| 手作業で集計 | 毎週3時間必要 |
| 担当者しか操作できない | 属人化 |
| 在庫確認を電話で実施 | 対応に時間がかかる |
この段階では、いきなり、
○○機能を作る
と決めないことがポイントです。
まず、
何に困っているのか
を明確にします。
「要望」と「課題」を分ける
ヒアリングすると、
AIを入れたい
スマホアプリが欲しい
ダッシュボードが欲しい
という要望が出ることがあります。
しかし、その裏にある課題を確認します。
例えば、
ダッシュボードが欲しい
↓
なぜ？
↓
管理職が売上をすぐ確認できない
↓
なぜ？
↓
担当者が毎週Excel集計している
という可能性があります。
重要なのは、
ダッシュボードを作ること
ではなく、
必要な売上情報を
管理職がすぐ確認できること
です。
解決方法はその後で考えます。
STEP4｜新しい業務フローを決める
現状を整理したら、
システム導入後に
どういう業務にしたいか
を決めます。
これを「To-Be」と呼ぶ場合があります。
例えば現在、
各拠点でExcel入力
↓
本社へメール
↓
本社で集計
なら、導入後は、
各拠点
↓
Webシステムへ直接入力
↓
共通DB
↓
本社がリアルタイム確認
とします。
この段階で重要なのは、
システムの画面より先に業務全体を考えること
です。
システム化しない業務も決める
すべてをシステム化する必要はありません。
例えば、
顧客から返品依頼
↓
担当者が内容確認
↓
返品可否を判断
↓
承認された場合だけ
システムへ登録
とすることもできます。
つまり、
人がやること
システムがやること
を分けます。
ここが曖昧だと、開発途中で、
これはシステムが自動判断すると思っていた
という認識違いが発生します。
STEP5｜システム要件を定義する
業務フローが決まったら、具体的なシステム要件へ落とします。
主に整理するのは、
機能要件
非機能要件
データ要件
外部連携要件
運用要件
移行要件
です。
機能要件とは
機能要件とは、
システムで何ができるのか
です。
例えば在庫管理システムなら、
ログイン
ユーザー管理
商品管理
在庫一覧
入庫登録
出庫登録
在庫調整
拠点管理
CSV出力
在庫アラート
などです。
機能一覧を作成すると整理しやすくなります。
| ID | 機能 | 内容 | 優先度 |
|---|---|---|---|
| F01 | ログイン | ID・パスワード認証 | 必須 |
| F02 | 商品管理 | 商品登録・編集 | 必須 |
| F03 | 在庫一覧 | 拠点別在庫表示 | 必須 |
| F04 | CSV出力 | 在庫一覧をCSV化 | 高 |
| F05 | アラート | 在庫不足通知 | 中 |
画面要件も整理する
例えば、
ログイン
ダッシュボード
商品一覧
商品詳細
在庫一覧
入庫登録
出庫登録
ユーザー管理
などの画面一覧を作成します。
詳細なデザインまで完成させる必要はありませんが、
誰が
どの画面から
何を操作するか
が分かる状態にします。
ワイヤーフレームを作ると認識を合わせやすくなります。
データ要件を整理する
システムでは、
何を保存するか
も重要です。
商品なら、
商品コード
商品名
カテゴリ
単価
在庫数
などです。
顧客なら、
顧客ID
会社名
担当者
メール
電話番号
などです。
データの保存期間についても必要に応じて確認します。
権限要件を整理する
例えば、
一般社員
拠点管理者
本社管理者
システム管理者
で操作可能範囲が違うかもしれません。
例：
| 操作 | 一般社員 | 拠点管理者 | 本社管理者 |
|---|---|---|---|
| 在庫閲覧 | ○ | ○ | ○ |
| 入出庫登録 | ○ | ○ | ○ |
| 在庫修正 | × | ○ | ○ |
| 他拠点閲覧 | × | × | ○ |
| ユーザー管理 | × | × | ○ |
個人情報や重要データを扱う場合、要件定義時点で権限設計を整理することが重要です。
非機能要件とは
非機能要件とは、
どの機能があるか
ではなく、
どの程度の品質・性能で
システムを提供するか
に関する要件です。
例えば、
性能
可用性
セキュリティ
バックアップ
運用
監視
拡張性
などです。
IPAの「非機能要求グレード」も、発注者と開発者の認識の行き違いを防ぐため、非機能要求を網羅的に整理し、要求レベルを段階的に確認する考え方を示しています。
非機能要件は数字で決める
例えば、
高速に表示する
では曖昧です。
可能なら、
通常画面は3秒以内
CSV10万件を60秒以内
同時接続100ユーザー
バックアップ1日1回
のように確認可能な基準へします。
ただし、必要以上に厳しくすると開発・インフラ費用が増えるため、業務上必要なレベルを設定します。
外部システムとの連携を整理する
例えば、
会計システム
販売管理
Google Workspace
Slack
決済サービス
メール配信
外部API
などです。
確認する内容には、
何のデータを連携するか
どちらからどちらへ送るか
いつ連携するか
APIがあるか
エラー時どうするか
などがあります。
外部連携は後から追加すると影響範囲が大きくなりやすいため、早い段階で整理します。
データ移行要件を忘れない
既存システムから移行する場合、
現在の顧客データ
商品データ
過去注文
Excel
CSV
などを新システムへ移す必要があります。
例えば、
顧客：
10,000件
商品：
5,000件
注文履歴：
5年分
なら、それ自体が大きな作業です。
要件定義では、
何を移すか
何年分移すか
データ形式
誰がデータを整理するか
移行後どう検証するか
まで確認します。
運用要件を整理する
システム完成後に、
誰が管理するのか
も重要です。
例えば、
ユーザー追加
→ 自社管理者
商品登録
→ 商品担当者
障害
→ 開発会社
問い合わせ
→ 社内情シス
バックアップ
→ 自動
とします。
開発だけでなく、
リリース後にどう使い続けるか
まで要件定義で考えます。
STEP6｜優先順位と開発範囲を決める
ヒアリングをすると、ほぼ必ず、
これも欲しい
あれも欲しい
となります。
しかし、
予算
納期
開発人数
には限界があります。
そこで優先順位を付けます。
例えば、
Must
必須
Should
できれば必要
Could
余裕があれば
Won't
今回は対象外
のように分類します。
「今回は作らないもの」も決める
要件定義では、
何を作るか
だけではなく、
何を作らないか
も重要です。
例えば、
初回リリース
○ 在庫管理
○ 入出庫
○ CSV
× AI需要予測
× スマホアプリ
× 会計システム連携
とします。
そして第二フェーズで、
会計連携
AI需要予測
を追加します。
このように段階的に開発すると、予算・納期を管理しやすくなります。
優先順位は「欲しい順」ではなく目的から決める
例えば目的が、
Excelでの在庫集計をなくす
なのであれば、
商品管理
入出庫
在庫一覧
拠点管理
は重要です。
一方、
AIによる需要予測
は魅力的でも、最初の目的には必須ではない可能性があります。
機能の優先順位は、
この機能が
開発目的へどの程度貢献するか
で判断します。
STEP7｜要件定義書として合意する
最後に、これまで決めた内容を要件定義書としてまとめます。
要件定義書に決まった一つのフォーマットがあるわけではなく、プロジェクトの規模や特性に応じて必要な資料を選びます。
例えば、
1．システム概要
2．開発背景
3．目的・ゴール
4．現状業務
5．課題
6．新業務フロー
7．システム対象範囲
8．機能要件
9．画面要件
10．データ要件
11．権限要件
12．非機能要件
13．外部連携
14．移行要件
15．運用要件
16．制約条件
17．対象外
18．スケジュール
19．未決事項
などです。
要件定義の主な成果物
プロジェクトによって異なりますが、代表的な成果物は次のとおりです。
| 成果物 | 内容 |
|---|---|
| 要件定義書 | 要件全体 |
| 要求一覧 | 利用者・関係者の要求 |
| 業務フロー | 現在・導入後の業務 |
| 機能一覧 | 必要なシステム機能 |
| 画面一覧 | 必要な画面 |
| ワイヤーフレーム | 画面イメージ |
| 帳票一覧 | PDF・CSV等 |
| データ項目一覧 | 管理するデータ |
| 権限一覧 | ユーザー別操作範囲 |
| 外部連携一覧 | API等の接続対象 |
| 非機能要件 | 性能・セキュリティ等 |
| 課題・未決事項一覧 | 今後決める事項 |
すべて作ればよいわけではありません。
小規模システムなら、必要なものへ絞ります。
小規模システムなら要件定義を簡略化してよい
例えば予算50万円程度の小規模システムで、
100ページの要件定義書
を作る必要はありません。
例えば、
目的
業務フロー
機能一覧
画面一覧
ワイヤーフレーム
データ項目
権限
非機能の主要項目
対象外
未決事項
程度でも十分な場合があります。
重要なのは、
資料の量
ではありません。
発注者と開発者が
同じ完成イメージを持てているか
です。
要件定義で特に確認したいヒアリング項目
実務では、次のような質問をすると整理しやすくなります。
開発目的
なぜシステム化したいですか？
現在一番困っていることは何ですか？
導入後に何が改善すれば成功ですか？
利用者
誰が利用しますか？
何人利用しますか？
社外の人も利用しますか？
スマートフォンから使いますか？
現在の業務
現在はどのような手順ですか？
Excel・紙・既存システムはありますか？
誰がどこで入力していますか？
機能
登録したい情報は何ですか？
検索条件は何が必要ですか？
CSV・PDFは必要ですか？
メール通知は必要ですか？
権限
全員が同じ情報を見られますか？
管理者だけができる操作はありますか？
部署・拠点ごとの制限はありますか？
非機能
何人が同時に使いますか？
停止するとどの程度業務へ影響しますか？
個人情報を扱いますか？
バックアップはどの程度必要ですか？
移行
既存データはありますか？
Excelは何ファイルありますか？
何年分移行しますか？
このような質問を繰り返しながら要件を具体化します。
要件定義でよくある失敗
失敗1｜いきなり機能一覧から作る
例えば、
ログイン
検索
登録
CSV
ダッシュボード
から始めるケースです。
これでは、
なぜその機能が必要なのか
が分かりません。
先に、
目的
↓
業務
↓
課題
↓
解決方法
↓
機能
の順番で考えます。
失敗2｜発注者が「全部ベンダーに決めてもらう」
要件定義は開発会社だけで完結する仕事ではありません。
IPAも、要件定義ではユーザー企業自身が主体となり、「どのようなシステムを作りたいか」を明確にする必要があると説明しています。
開発会社は、
技術的な実現方法
機能整理
抜け漏れ確認
選択肢提示
を支援できます。
しかし、
どの業務が重要なのか
どのルールで運用するのか
何を優先するのか
は業務を知っている発注者側の参加が必要です。
失敗3｜管理職だけで要件を決める
現場を利用するシステムなら、実際の利用者にも確認します。
管理職が考える業務と、現場で実際に行われている業務が違う可能性があるためです。
失敗4｜例外処理を確認しない
通常ケースだけを考えて、
キャンセル
返品
削除
修正
エラー
再申請
などが抜けるケースです。
要件定義では、
通常と違うケースはありますか？
という質問が重要です。
失敗5｜非機能要件を後回しにする
例えば完成直前になって、
実は同時に1,000人利用します
と分かった場合、インフラ・設計から見直す可能性があります。
IPAの非機能要求グレードも、非機能要求について発注者と開発者の認識差を減らすことを目的としています。
主要な非機能要件は要件定義時点で確認します。
失敗6｜すべてを初回リリースへ入れる
機能を追加すればするほど、
開発費
納期
テスト量
障害リスク
も増えます。
まず、
業務を成立させるために
最低限必要な機能
を決めます。
失敗7｜曖昧な言葉をそのまま残す
例えば、
使いやすくする
高速にする
柔軟に検索できる
十分なセキュリティ
では、人によって解釈が違います。
できるだけ、
商品名・商品コードで検索できる
主要画面は3秒以内を目標とする
管理者のみ削除可能
のように具体化します。
失敗8｜未決事項を無理に決めたことにする
要件定義期間中にすべて決まるとは限りません。
その場合、
未決事項
担当者
決定期限
影響範囲
を管理します。
例えば、
| 未決事項 | 担当 | 期限 |
|---|---|---|
| 決済サービス | 営業部 | 8/10 |
| CSV形式 | 業務担当 | 8/15 |
| データ移行範囲 | PM | 8/20 |
とします。
「決まっていない」ということを明確にすることも要件管理の一部です。
要件定義を成功させる5つのポイント
1．目的から逆算する
機能ありきにしません。
目的
↓
課題
↓
業務
↓
機能
の順に考えます。
2．文章だけでなく図を使う
おすすめは、
業務フロー
ワイヤーフレーム
画面遷移図
ER図
などです。
文章だけより認識を合わせやすくなります。
3．実際のデータを見る
例えば、
現在使っているExcel
申請書
帳票
CSV
紙の伝票
を確認します。
実物を見ると、ヒアリングだけでは見つからなかった要件が分かることがあります。
4．対象外を明記する
例えば、
対象
○ 顧客管理
○ 案件管理
○ CSV出力
対象外
× 請求書発行
× 会計連携
× スマホアプリ
とします。
開発範囲の認識違いを防げます。
5．要件に優先順位を付ける
予算や納期に問題が発生したとき、
どの機能を残すか
判断しやすくなります。
要件定義は発注前にどこまでやればよい？
システム開発を初めて依頼する企業の場合、
要件定義書を完璧に作ってから
開発会社へ相談しなければならない
わけではありません。
少なくとも、
現在の業務
困っていること
システム化したい理由
利用する人
現在使っているExcel・システム
希望予算
希望時期
が分かれば相談は可能です。
むしろ、
何を作ればよいか分からない
段階から要件整理を支援してもらう方法もあります。
要件定義から開発会社へ依頼するメリット
要件定義から依頼すると、
現状業務のヒアリング
↓
課題整理
↓
業務フロー作成
↓
必要機能の整理
↓
技術的な実現方法検討
↓
概算見積
↓
開発
まで一貫して進められます。
特に、
Excelで複雑な管理をしている
紙の業務をWeb化したい
現在の業務をどうシステム化すればよいか分からない
という場合は、最初から機能一覧を作るより、業務整理から進める方が適しています。
要件定義に必要な期間は？
システム規模によって大きく変わります。
目安としては、
| 規模 | 要件定義期間のイメージ |
|---|---|
| 小規模 | 1〜3週間 |
| 中規模 | 1〜2か月 |
| 大規模 | 2〜6か月以上 |
ただし、
関係部署数
機能数
外部連携
データ移行
意思決定速度
既存業務の複雑さ
によって変わります。
単純に期間を長くすれば精度が上がるわけではありません。
意思決定者・現場担当者が打ち合わせへ参加できるかも重要です。
要件定義が終わったら次は基本設計
一般的な流れは、
企画
↓
要件定義
↓
基本設計
↓
詳細設計
↓
開発
↓
テスト
↓
リリース
です。
IPAでも、要件定義は企画の後、基本設計の前に位置する上流工程として説明されています。
要件定義では、
何を実現するか
を決めます。
基本設計では、それを、
どのような画面・データ・システム構成で
実現するか
へ具体化していきます。
要件定義に関するよくある質問
要件定義は誰がやるのですか？
発注者と開発会社が一緒に進めるケースが一般的です。
業務ルール・目的・優先順位は発注者側が説明し、開発会社はヒアリング、システム化範囲の整理、技術面からの提案などを行います。
要件定義と基本設計の違いは？
簡単に言えば、
要件定義
=
何を実現するか
基本設計
=
どのように実現するか
です。
ただし、実際の成果物の境界は開発会社・プロジェクトによって異なります。
要件定義書に決まったテンプレートはありますか？
絶対的なフォーマットはありません。
システム規模・開発方法・対象業務に合わせて必要な資料を作成します。
小規模なシステムでも要件定義は必要ですか？
必要です。
ただし、大規模プロジェクトと同じ量の資料は必要ありません。
小規模なら、
目的
業務フロー
機能一覧
画面イメージ
データ
権限
対象外
などに絞って整理する方法があります。
要件定義の途中で要望が増えたらどうしますか？
要求一覧へ追加し、
必要性
費用
スケジュール
優先順位
を確認します。
すべてを追加するのではなく、今回対応するか次フェーズへ回すか判断します。
要件定義を開発会社へ依頼できますか？
対応している開発会社であれば可能です。
業務ヒアリングから課題・機能・業務フローを整理してもらう方法があります。
hiro-dev-labの要件定義・システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく要件整理から対応しています。
例えば、
- 現状業務のヒアリング
- 業務フロー整理
- 課題整理
- システム化範囲の整理
- 機能一覧作成
- 画面構成・ワイヤーフレーム整理
- データ項目整理
- 権限設計
- 非機能要件整理
- 既存Excel・業務システムのWeb化
- 外部システム・API連携の検討
- Java・Python・TypeScriptを利用したWebシステム開発
などを検討できます。
例えば現在、
Excel
↓
担当者による手作業
↓
メール
↓
別のExcelへ転記
という業務であれば、いきなりシステムを開発するのではなく、
現状業務を確認
↓
課題を整理
↓
不要な作業を見直す
↓
新しい業務フローを設計
↓
必要なシステム機能を定義
↓
開発
という順番で進めます。
要件定義で最も重要なのは「何を作るか」より「なぜ作るか」
要件定義を進めると、
画面
機能
データベース
API
などの話へ意識が向きがちです。
しかし、最初に明確にすべきなのは、
なぜこのシステムが必要なのか
です。
例えば、
在庫管理システムを作る
ことそのものには価値がありません。
本来の目的が、
在庫をリアルタイムで把握する
Excel集計をなくす
入力ミスを減らす
担当者への属人化を解消する
なのであれば、それを実現できることが重要です。
そのため要件定義は、
1．目的・ゴールを決める
2．現状業務を整理する
3．課題・要求を洗い出す
4．新しい業務フローを決める
5．機能・非機能要件へ落とす
6．優先順位・対象外を決める
7．要件定義書として合意する
という順番で進めると整理しやすくなります。
「何をシステム化すればよいのか、まだ整理できていない」
「Excel業務をWebシステムへ移行したい」
「開発会社へ相談する前に要件を整理したい」
「要件定義から開発までまとめて相談したい」
といった段階でも、要件整理から進めることができます。
システム開発・要件定義について相談する