システム開発の要件定義チェックリスト｜外注前に決める10項目

要件定義は、作りたい画面と機能を発注者が完成させてから開発会社へ渡す作業ではありません。誰が、どの業務を、どの条件で完了できれば投資の目的を達成するかを、発注者と開発側が合意する工程です。

機能一覧だけを先に作ると、現在の業務に合わない、例外処理が抜ける、権限やデータ移行を後から追加する、といった手戻りが起きます。一方、細部をすべて決めるまで見積もりを取れないわけでもありません。未決事項と決定者を残せば、調査・設計を含む発注として比較できます。

この記事では、外注前に発注者が整理したい10項目と、要件定義書へ残す内容、完成を判断する基準を説明します。既製サービスへ業務を合わせるか、独自部分を開発するかで迷う場合は、フルスクラッチ開発とSaaS・パッケージの判断表から開発方式を絞ってください。

要件定義は発注者と開発会社の共通の判断基準

IPAは要件定義を、ユーザー企業とベンダー企業の認識を合わせるために重要な工程と説明しています。業務部門を含む利害関係者を識別し、要件を抽出・評価・合意し、記録と追跡可能性を保つことが必要です。

要件定義書の形式より、次の三つがそろっているかを見ます。

1. 事業・業務の目的から各要件を説明できる
2. 発注者、利用者、開発会社が同じ言葉で確認できる
3. 完成時に満たしたか判定できる

「使いやすくする」「高速にする」「柔軟に対応する」だけでは判定できません。対象利用者、操作、時間、件数、例外、責任者を具体化します。

外注前の要件定義チェックリスト10項目

1. 解決する業務課題と投資判断

システム名ではなく、現在起きている問題を書きます。

• 誰が、どの作業に、何時間かけているか
• 入力ミス、二重作業、待ち時間はどこで起きるか
• 何が変われば開発費をかける意味があるか
• 開発しない場合、代替手段と損失は何か

「顧客管理システムを作る」では目的が分かりません。「営業20名が別々の表へ記録しており、案件引き継ぎに毎週10時間かかる。顧客と商談の記録を一か所へ集め、引き継ぎ時間を半分にする」まで書くと、後の機能判断につながります。

2. 対象業務の開始から完了まで

現在の業務を、入力、作業、判断、出力へ分けます。正常な流れだけでなく、差し戻し、取消、担当者不在、重複、締め後の修正も確認してください。

新しいシステムで業務手順も変えるなら、現状と変更後を分けます。今の作業をそのまま画面へ移すことが最善とは限りません。

3. 利用者、権限、責任者

「社員が使う」では足りません。役割ごとに、閲覧、作成、編集、承認、削除、出力の権限を決めます。

• 一般担当者、管理者、承認者、監査担当者
• 顧客、取引先など社外利用者
• 退職・異動・休職時の停止と引き継ぎ
• 代理操作と緊急時の権限
• 権限を申請・承認・棚卸しする人

組織や顧客ごとにデータを分離する場合は、見えてはいけない組み合わせを具体例で示します。

4. 機能要件と優先順位

機能は「必須」「初回後」「対象外」に分けます。すべてを必須にすると、予算と期限が変わったときに判断できません。

各機能へ、利用者、入力、処理、出力、エラー時の挙動を書きます。画面名だけでなく、何を完了する機能かを残してください。

5. データの項目、品質、移行

データ移行は、開発後半に「既存の表も取り込みたい」と追加されやすい項目です。先に次を確認します。

• 元データの保管場所、形式、件数、容量
• 必須項目、重複、欠損、表記揺れ
• 過去何年分を移すか
• 移行前に誰が整理・修正するか
• 試験移行、本番移行、差分移行の回数
• 移行結果を誰が何件確認するか
• 保存期間、削除、バックアップ、出力の要件

データが揃っていなければ、移行プログラムだけでは直りません。発注者が判断するルールと、人が直す範囲を見積もりへ含めます。

6. 外部システムと連携条件

会計、決済、顧客管理、認証、メール、生成AIなどと連携する場合、サービス名だけでは見積もれません。

• APIやファイル連携が利用できる契約プランか
• 連携するデータと方向、頻度、時刻
• 呼び出し回数、容量、利用料金の上限
• 認証情報を誰が発行・更新するか
• 失敗時の再実行、重複防止、通知
• 外部仕様が変わったときの保守範囲

本番環境の権限を開発会社へ渡す前に、検証用環境と最小権限を用意します。

7. 非機能要件

非機能要件は、機能以外の品質と運用条件です。「安全で速いシステム」とせず、利用状況から必要な水準を決めます。

高い水準ほど費用が増える場合があります。すべてを最高水準にせず、障害時の事業影響から優先します。

8. 受け入れ条件とテスト

発注者が完成を判断する条件を、実装前に決めます。

承認者が差し戻した申請は、申請者へ理由付きで通知され、修正後に同じ履歴へ再申請できる。

条件、操作、期待結果を一つにします。正常系だけでなく、権限不足、入力誤り、連携失敗、重複操作も対象です。

テストデータを誰が用意するか、個人情報を含む実データを使うか、受け入れ期間と不具合修正の扱いも契約・計画へ残します。

9. 運用、保守、引き渡し

公開日は運用の開始日です。次を決めます。

• 利用者からの問い合わせ窓口
• 障害と通常質問の切り分け
• 監視、バックアップ、アップデートの担当
• 不具合修正と追加開発の境界
• ソースコード、設計資料、クラウド、ドメインの所有者
• 保守契約を終えるときのデータ・環境の引き渡し

運用担当者が決まっていない要件は、公開後に止まりやすくなります。操作手順だけでなく、例外時の判断手順を残します。

10. 予算、期限、変更の決め方

予算と希望日は、機能一覧と同じ要件です。絶対に動かせない期限があるなら、理由と遅れた場合の影響を共有します。

未確定事項が残る場合は、調査・要件定義と実装を分けて契約する方法があります。変更要求について、影響調査、見積もり、承認者、追加費用、期限変更の手順を決めます。口頭の依頼で範囲が増え続けないよう、要件と変更履歴を同じ場所で管理してください。

要件定義書は一冊の文書でなくてもよい

成果物は、プロジェクトの規模と変更頻度に合わせます。

一つの巨大な文書へ固定する必要はありません。表、図、試作品、課題管理を組み合わせても、相互の用語と版が一致し、決定理由を追えることが大切です。

要件定義が終わったと判断する基準

細部がすべて確定することを、完了条件にはしません。次の状態を目安にします。

• 開発の目的と対象外を関係者が説明できる
• 最初の利用者と主要業務が決まっている
• 必須機能、データ、連携、非機能要件を見積もれる
• 受け入れ条件からテスト方法を考えられる
• 未決事項に決定者と期限がある
• 予算・期限を超える場合の優先順位がある
• 運用責任者と引き渡し範囲が決まっている

要件が途中で変わること自体は失敗ではありません。変更がどの目的に必要で、費用・期限・品質へどう影響し、誰が承認したかを追えない状態が問題です。

見積もり依頼へ渡す最小セット

初回相談では、10項目を完全に埋めなくても構いません。少なくとも次の6点を共有すると、開発会社が不足調査を提案しやすくなります。

1. 解決したい業務課題と現在の負担
2. 最初に使う人と業務フロー
3. 必須・初回後・対象外に分けた機能候補
4. 既存データと外部連携の一覧
5. 希望時期、予算上限、社内の決定者
6. 分からないこと、現地確認が必要なこと

費用を比較するときは、要件定義、設計、実装、移行、テスト、公開、保守のどこまで含むかをそろえます。システム開発の見積もりの取り方とシステム開発を外注する手順も併せて確認してください。

発注者が決めるべきことを手放さない

開発会社は、要件を整理し、実現方法を提案できます。しかし、どの業務を変え、誰の判断を優先し、どのリスクを受け入れるかは発注者の事業判断です。

最初に目的と業務を確認し、利用者、機能、データ、品質、受け入れ、運用へ進みます。最後に予算と期限へ戻し、対象外と変更手順を決めます。この順番なら、機能一覧を増やす前に、作る理由と完成の基準をそろえられます。

参考にした一次情報

• IPA DX SQUARE「要件定義とは？」
• IPA「ユーザのための要件定義ガイド 第2版」
• IPA「共通フレーム2013」

この記事は一般的な要件整理の方法を示すものです。契約形態、規制、セキュリティ水準、必要な成果物は開発対象によって異なります。個別案件では、法務・情報セキュリティ・業務の各担当者と確認してください。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る