更新情報（2025年4月5日）

37万回以上の閲覧、1,500件を超える「いいね」、そして1,700件以上のストックをいただき、心より感謝申し上げます。
多くの方に読んでいただいたことで、現場での活用や共感の声を多数いただきました。

今回の更新では、読者の皆様から寄せられたフィードバックをもとに、より実践的な内容を追記し、一部の表現をリライトしました。
特に「非機能要件」「移行・引継ぎ」「保守体制」に関する項目については、現場で実際に起きやすい課題に対する解決視点を強化しています。

今後も内容を継続的にブラッシュアップしながら、現場で本当に役立つ要件定義ノウハウを届けていきます。
引き続きどうぞよろしくお願いいたします。

はじめに

システム開発やプロダクト開発の現場では、「何を作るか」以上に「なぜ作るのか」「どう作るか」を明確にすることが重要です。
それを形にするのが「要件定義」というプロセスです。

要件定義とは

要件定義とは、あるシステムや製品に必要な機能や性能、制約条件などを明確に定める作業のことです。
つまり、ユーザーが何を望んでいて、どのような結果を期待しているかを整理・言語化し、それに基づいて開発を進めるための出発点です。

要件定義が不十分なまま開発が始まってしまうと、次のような問題が起きやすくなります：

ユーザーの期待を満たさない成果物ができる
開発コストや期間が大幅に膨らむ
プロジェクトの途中で認識の食い違いが頻発する

つまり要件定義とは、期待に沿わないものを作ってしまうリスクや、不要なコスト・遅延のリスクを避けるために行う非常に大事な工程なのです。

「品質担保」や「成功の鍵」といった表現がされることも多いですが、個人的にはこれはシステム開発をとにかく失敗させないために必要なプロセスだと考えています。
何度も失敗を経験してきた立場から、少しでも同じ轍を踏まずに済むよう、この内容を通じて学びを共有できればと思います。

まずは「整理」から始める

要件定義に入る前に、まずは「誰が、何を、なぜ、いつまでに、どこまで、どうやって」求めているのか、という情報を整理しましょう。
これはいわゆる 5W1H の観点で考えると非常にスムーズです。

以下の表は、5W1Hを使った要件整理の例です。

5W1H	整理すること	ポイント
Who（誰が）	登場人物・関係者の整理	プロジェクトに関与する人を洗い出す。特に「誰が最終判断をするのか」は重要。意思決定者が不在だと炎上します。
What（何を）	作るものの定義	「口頭でなんとなく決めた」は危険。明文化が必要。「顧客が本当に必要だったもの」の図を参照。
When（いつまでに）	納期・スケジュール	期間が限られている場合は、優先順位付けやスコープの切り分けが必要になります。
Where（どこまで）	スコープ・対象範囲の明確化	スコープが不明瞭だと後で「ここも入れて」「これもやって」となりがち。最初に決めることが重要。
Why（なぜ）	プロジェクトの背景や目的	作ること自体が目的にならないよう、なぜこの開発が必要かを共有しましょう。
How（どうやって）	実現方法・環境・技術方針	技術的な制約、利用するツール、基本的な仕組みなどを簡単に押さえておくとスムーズです。

要件定義書

要件定義で整理した内容は、ドキュメントとして記録し、関係者で共有・合意を得ることが重要です。
この「要件定義書」が、以降の設計・開発・テストすべての基礎資料となります。

ドキュメントは次のような構成を意識すると良いでしょう：

概要（目的・背景）
ステークホルダー一覧
機能要件／非機能要件
システム構成・外部連携
スケジュールとマイルストーン
バージョン履歴

ドキュメントのバージョン管理

要件定義書は一度作って終わりではありません。
開発の過程で変更が生じることもあるため、更新履歴を明確に管理することが重要です。

バージョン管理の例：

バージョン	日付	変更内容	担当者
1.0.0	2021-07-12	○○の要件を追加、△△を追記	鈴木

バージョン管理で押さえるべきポイント

バージョン番号のルールを定める
- 例：メジャー.マイナー.パッチ（1.2.0 など）で運用。変更の規模に応じて番号を更新。
変更履歴を記録する
- どのような変更が、いつ、誰によって行われたのかを明確にすることで、問題発生時の原因追跡が容易になります。
保存場所を一元化する
- 複数のバージョンがバラバラに存在すると、誤って古い内容を参照するリスクがあります。共有ドライブやバージョン管理システムを活用しましょう。
変更には承認フローを設ける
- 無秩序な変更は混乱を招きます。変更をレビュー・承認する手順を明確に定めましょう。
定期的なバックアップを行う
- 万が一のデータ消失や誤削除に備えて、バックアップは定期的に取る習慣を持ちましょう。

1. 概要

この章では、今回開発するシステムの「全体像」と「開発の背景」、そして「専門用語の定義」を記述します。
プロジェクトに関わるすべてのメンバーが、立場やスキルレベルに関係なく理解できるよう、平易かつ丁寧に書くことが大切です。

A. システム構成図

ここでは、開発対象のシステムがどのような構造を持ち、どのように動作するかを「視覚的に」示します。
構成図には、次のような要素が含まれていると理想的です：

システム全体の構造
ユーザーとの接点（UIや端末）
各モジュールの関係
データや処理の流れ
利用するクラウドサービスやネットワーク機器

クラウド構成を描く際に便利な公式アイコンリンク：

AWSのアイコン素材
https://aws.amazon.com/jp/architecture/icons/
Azureのアイコン素材
https://docs.microsoft.com/ja-jp/azure/architecture/icons/

システム構成図の作成手順（6ステップ）

概要を描く
- システム全体の構成をざっくり俯瞰します。利用者、インターフェース、中心となる処理を配置。
モジュールを定義する
- 機能単位でブロック化して整理。何をどこで担当するのか明確にします。
モジュールの関係を描く
- 各機能ブロック間のデータフローや依存関係を矢印などで表します。
ハードウェアを配置する
- サーバー、ネットワーク、端末など、物理的な構成も含めて表記します。
インタフェースを示す
- 外部サービスとの連携、APIやデータベースとのやり取りなども忘れず記載します。
図の説明文を添える
- 最後に、図に書ききれなかった前提や補足をテキストで記述します。構成図だけでは伝わらない部分を補います。

ポイント：
見る人が初めてでも「このシステムはこう動くんだな」と直感的に理解できる構成にすることを心がけましょう。

B. 背景

ここでは、「なぜこのシステムを作る必要があるのか」「その背景にはどんな課題や目的があるのか」を記述します。

開発依頼は、必ずしもユーザー自身が正確に課題を把握しているとは限りません。
表面的な要望の背後にある「真のニーズ」や「ビジネス上の意図」を汲み取り、正しく方向付けるのがプロの仕事です。

背景の書き方：4つの視点

関係者と共通理解を持つ
- まず、関係者とプロジェクトの目的・課題について対話し、誤解のない状態にしておくことが前提です。
背景を明確に記述する
- 「なぜ今この開発が必要なのか」「何が課題なのか」などを具体的に。数字や実例を交えると説得力が増します。
例：
- 問題点：既存システムでは在庫データの反映に最大48時間の遅延が発生
- 結果：売り越しや在庫不足による機会損失が月間約50万円発生している
ビジネス目標を示す
- このプロジェクトを通して、何を実現したいのか。売上向上、工数削減、ユーザー満足度の向上など、具体的な数値目標があれば明記します。
例：
- 新システム導入により、在庫反映の即時化を実現し、月間機会損失50万円 → 0円を目指す。
背景と要件の関係を明示する
- どんな課題や目的が、どの要件に結びついているのかを明確にすると、要件の正当性が伝わりやすくなります。
例：
- 在庫反映の遅延（背景） → リアルタイム連携機能（要件）

C. 用語定義（Glossary）

このプロジェクトで頻繁に登場する専門用語や略語は、必ずこのセクションで定義しておきましょう。
読む人が異なる業界や立場の場合、認識のズレを防ぐうえで非常に重要です。

用語	定義
API	Application Programming Interface の略。異なるソフトウェア同士が機能やデータをやり取りするための仕組み。
SKU	Stock Keeping Unit。商品の最小管理単位。サイズや色違いでSKUは異なる。
SLA	Service Level Agreement。サービスの提供レベルを定めた合意文書。例：稼働率99.9%以上など。
バッチ処理	一定時間ごとにまとめて行うデータ処理の方式。リアルタイム処理とは対照的。

補足： 定義に曖昧さがあると、開発・設計・テストで解釈がズレる可能性があるため、誰が読んでも理解できる表現を心がけましょう。

2. 業務要件

業務要件とは、ある業務を適切に遂行するために必要な機能・仕様・制約などをまとめたものです。
この章では、「業務の流れ」や「処理量」「タイミング」「評価指標」などを整理し、それらがシステムにどのように反映されるべきかを明確にします。

業務要件は、業務を円滑に・効率よく進めるための「設計図」のようなものです。
これを正しく定義することで、業務の最適化はもちろん、システム導入後のトラブル防止や、将来的な改善にもつなげることができます。

A. 業務フロー

ここでは、業務の「流れ」を一枚の図（業務フロー図）として表現します。
誰が、いつ、どのような作業を、どの順序で行うのかを視覚的に示すことで、関係者全員の共通理解が得られます。

業務フロー図の作成手順

業務の範囲を定義する
- どこからどこまでを対象とするかを明確にします。例：注文受付〜出荷処理まで。
業務ステップを列挙し、順序を整理する
- 作業手順を洗い出し、それらがどの順で行われるかを決定します。
シンボルを選択して図式化する
- 開始・終了（丸）、処理（四角）、判断（ひし形）、矢印（流れ）などの基本記号を用いて整理します。
担当者ごとにレーン（スイムレーン）を設ける
- 業務担当者をグループ化し、誰が何をするかが一目でわかるようにします。
ループや条件分岐を反映する
- 繰り返し処理や分岐のあるプロセスは、矢印やひし形で表現します。
必要に応じて説明文を添える
- 特殊な処理や注意点がある場合は、注釈や補足を記載しておきましょう。

ポイント： 図は「初見の人でも業務の全体像が把握できる」ことが目的です。複雑な業務ほど、図解が効果的です。

B. 規模（スケール）

業務の規模は、システム設計の重要な指標になります。
過小評価すると処理能力が足りなくなり、過大評価するとコストが無駄になります。

規模定義の例：

月間処理件数：50,000件
同時ログインユーザー数：最大500人
対象商品数：10,000SKU
平均業務時間：1日8時間×営業日

備考： 規模情報は業務フロー図の中に記載しても構いません。図内でステップごとの処理件数や頻度を示すことで、開発者にも直感的に伝わります。

C. 時期・時間（スケジュール）

業務は「いつ」「どのくらいの時間をかけて」行われるかによってシステム設計が変わります。
ピーク時間帯、処理のタイミング、バッチ処理の頻度などをここで整理します。

書き方の例：

業務フロー図内に時間軸を設ける
- ステップごとに「所要時間」「発生タイミング」などを記載します。
補足説明として文章で記載する
- 例：「〇〇処理は午前9時〜10時に集中する」「締切時間は毎営業日15:00」など。
スケジュール表を作成する
- 日次、週次、月次で発生する業務などを表にまとめておくと、定期処理の把握に便利です。

D. 指標（KPI / 評価基準）

業務プロセスの効果や品質を測るための指標をここに定義します。
指標を設定することで、業務の改善ポイントを明確にし、PDCAサイクルの起点とすることができます。

よく使われる指標例：

指標名	説明
サイクルタイム	各業務ステップにかかる平均処理時間。短いほど効率的。
リードタイム	開始から完了までにかかる総時間。待ち時間を含む。
処理能力	単位時間あたりの処理件数（例：1時間で処理できる申請数）。
エラー率	処理全体に対する不備・エラーの発生率。品質管理に有効。
待機時間	次の処理に移るまでの待ち時間。業務のボトルネックになりやすい。

備考： これらの指標は、システム化により自動集計されるように設計することで、運用後の改善にも活用できます。

E. 範囲（スコープ）

ここでは、業務要件として対象とする範囲（＝スコープ）を定義します。
何が対象で、何が対象外かを明示することで、開発チームとの認識ズレや追加要望によるトラブルを防げます。

書き方のポイント：

対象範囲の明示：
例：「発注〜入荷までを本システムの対象とし、仕入契約は対象外とする」
対象外の明示：
例：「○○部門のワークフローは別システムにて対応済みのため、本プロジェクトでは対象外」
インターフェースの整理：
どの外部システムと連携が必要か、どこからどこまでを自システムで対応するのかを明確にしましょう。

備考： 範囲の明確化は、スケジュール・コスト・役割分担にも大きく関係します。あいまいな表現は避け、具体的な記述を心がけましょう。

3. 機能要件

この章では、開発対象のシステムが持つべき機能について、明確かつ体系的に整理します。
「どんな機能が必要か」「どのように利用されるか」「その情報はどう扱われるか」などを具体的に定義することで、設計・実装・テスト工程をスムーズに進める土台を築きます。

A. 機能一覧と分類（機能ブレイクダウン）

システムに必要な機能は、業務ごとに大分類・中分類・小分類のように階層的に整理しましょう。
こうすることで、関係者全員が全体像を把握しやすくなり、抜け漏れのリスクも減少します。

機能分類の例：

大分類	中分類	小分類	説明
顧客管理	顧客情報登録	新規顧客登録	顧客の基本情報（氏名、住所など）を登録する機能
顧客管理	顧客情報更新	編集・削除	既存の顧客情報を更新・削除する機能
受注管理	受注入力	注文登録	オペレーターが注文情報を登録する機能
受注管理	ステータス管理	出荷済み反映	出荷が完了した注文のステータスを更新する機能

機能要件を書く手順

階層的なブレイクダウンを決める
- 業務や画面単位などで、大→中→小へ整理。各機能の関係性が見えるようにする。
各機能の説明を書く
- その機能が「何をするのか」「なぜ必要なのか」を簡潔かつ明確に記述する。
利用シナリオを書く（可能なら）
- 機能の使用例やユーザーストーリーを記述することで、背景や重要性がより伝わりやすくなります。

例：利用シナリオ（注文登録）

ユーザーは「注文一覧」画面から「新規注文」ボタンをクリックする。
「注文登録」画面が表示され、商品や数量を入力後「登録」ボタンを押すと、注文が保存される。
登録完了後、自動的に在庫が引き落とされ、ステータスが「受注済み」になる。

B. 画面仕様（画面一覧と遷移）

ユーザーが操作する画面の構成と、その役割やつながりを整理します。
この情報は外部設計書でさらに詳細に定義する場合もありますが、要件定義時点では**「何のためにどんな画面が必要か」を明らかにしておくことが大切**です。

画面要件の書き方

画面一覧を書く
- 画面ID、画面名、概要を含めた一覧表を作成します。

画面ID	画面名	目的・役割
SCR001	顧客一覧	顧客情報の検索・一覧表示
SCR002	顧客登録	新規顧客の登録
SCR003	注文登録	商品と数量を指定して注文を登録

画面の役割を説明する
- 各画面が「どの機能を提供するか」「ユーザーにどんな価値を提供するか」を明記します。
画面遷移図を書く（任意）
- 画面間の遷移関係を図で示すことで、操作フローが明確になります。外部設計書の付録にしてもOKです。

C. 情報・データ・ログ

どのような情報を扱い、どう保存・処理・追跡するかを定義します。
システム開発では、データ構造やデータの流れが非常に重要です。

書き方と例：

データモデルを書く（ER図など）
- 主要なデータの構造、属性、制約を定義します。

テーブル名	項目名	型	制約
顧客マスタ	顧客ID	INT	主キー、連番
顧客マスタ	氏名	TEXT	必須
顧客マスタ	メールアドレス	TEXT	一意制約

データフローを示す
- どの処理がどのデータを参照・更新・削除するかを整理します。図示すると尚良い。
ログの要件を書く
- ログの種類（アクセスログ、操作ログ、エラーログなど）
- 保存する情報（ユーザーID、処理内容、タイムスタンプなど）
- 保持期間やセキュリティ要件

D. 外部インターフェース

他システムとの連携やデータ連携の仕様を定義します。
APIや外部DBとの接続、バッチ連携など、外部とのやり取りに関する全ての仕様をここにまとめます。

書き方と構成例：

インターフェース一覧を作成する

インターフェース名	接続先	目的	備考
顧客連携API	CRMシステム	顧客情報の取得	REST API、JSON形式
出荷通知CSV	倉庫業者FTP	出荷情報連携	CSVファイルを定時アップロード

連携仕様を詳細に記述する

データ項目名・型・必須性
送信形式（JSON/XML/CSVなど）
通信方法（HTTPS/FTPなど）
認証方式（OAuth2、Basic認証など）

エラーハンドリングを明記する

外部連携エラー時の再送処理の有無
ログへの記録ルール
ユーザーへの通知方法（ポップアップ、アラートなど）

補足

この機能要件は、以降の詳細設計（外部設計・内部設計）に引き継がれる重要な文書です。
できるだけ早い段階で、開発者・テスト担当・ユーザーとレビューを行い、合意形成を図ることが推奨されます。

4. 非機能要件

非機能要件とは、システムの「見えにくいが非常に重要な品質面」に関する要件です。
具体的には、性能（スピード）・信頼性（壊れにくさ）・拡張性（成長への備え）・使いやすさなどが含まれます。

これらはシステムの成功を裏から支えるものであり、たとえ機能が豊富でも、非機能要件を疎かにするとユーザー離れや障害の原因になります。

特に、開発初期段階で非機能要件を明文化しておくことで：

品質基準が明確になる
見積もりの精度が向上する
プロジェクト全体のリスクが減少する

といった大きなメリットがあります。
なお、運用開始後は環境やニーズの変化に応じて、非機能要件を定期的に見直すことも推奨されます。

A. ユーザビリティおよびアクセシビリティ

誰が、どのように使うのか。ユーザーが「迷わず」「スムーズに」操作できることを保証するための要件です。

記述のポイント：

目標と基準を設定する
- 例：「トップページから3クリック以内に注文確定画面へ遷移できる」
- 操作の直感性、ミス防止、入力支援なども含める
対象ユーザーを定義する
- 年齢層、専門性の有無、視覚や身体の制約を持つユーザーなどを想定
- アクセシビリティ対応（キーボード操作、音声読み上げなど）もここに含める
テスト計画を立てる
- アクセシビリティチェックツールによる検証や、実ユーザーによる使用感テストの実施予定を記述

B. システム方式（アーキテクチャ）

システム全体の構造と技術的な設計方針に関する要件です。

記述のポイント：

アーキテクチャの概要
- Webアプリケーションか、モバイルアプリか、オンプレミスかクラウドかなど
- 採用するフレームワーク、ミドルウェア、データベースなども記載
冗長性・耐障害性
- サーバーのクラスタ構成、負荷分散（ロードバランサ）、フェイルオーバー戦略などを定義
- 例：「Webサーバーは2台構成とし、片方が落ちてもサービスを継続可能とする」

C. 規模（スケーラビリティの基礎）

どれくらいのユーザー・データ量・処理件数を想定して設計するかを定量的に記述します。

例：

項目	数値
同時接続ユーザー数	最大5,000人
1日あたりのトランザクション数	約200,000件
保持データ件数	約1億レコード

※あくまで想定値でも良いですが、初期構成に影響する重要情報です。

D. 性能（パフォーマンス）

システムが「どのくらい速く」「どの程度まで耐えられるか」といった性能面を定めます。

記述のポイント：

応答時間の目標
- 例：「ユーザー操作後、画面が3秒以内に表示されること」
- バッチ処理については「1万件を30分以内に処理」など
閾値（許容上限）を設定する
- トラフィックのピーク時でも性能を維持できるよう、設計上の最大許容量を明示

E. 信頼性（安定稼働・可用性）

システムが「落ちない」「壊れない」ための要件です。
一度でも停止すれば信頼を失うケースもあるため、極めて重要です。

記述のポイント：

稼働率（可用性）
- 例：「月間稼働率99.9%以上（＝月の停止時間約43分未満）」
- SLA（サービスレベル合意）として明記する場合も
バックアップとリカバリ方針
- 例：「1日1回のフルバックアップ＋30分ごとの増分バックアップ」
- 復旧目標時間（RTO）とデータ損失許容時間（RPO）も設定すると良い

F. 拡張性

将来的な機能追加やユーザー増加に柔軟に対応できるよう、拡張しやすい設計を求める要件です。

記述のポイント：

マイクロサービス、コンテナ技術（Kubernetesなど）の活用可否
機能追加時に影響範囲が局所化できる構造か
データベースのスケールアップ・アウト方針

✅ 補足： 将来的な「負荷の増加」「機能追加」に備えておくことで、作り直しのコストを回避できます。

G. 上位互換性（後方互換性含む）

新しいバージョンで「古いデータが読めない」「旧仕様のAPIが使えない」といった問題を回避するための要件です。

記述のポイント：

データの互換性
- 旧バージョンで作成されたデータを、新バージョンでも正しく処理できること
APIの変更対応
- 旧バージョンとのAPI互換性維持 or バージョニング対応（例：/api/v1 → /api/v2）
マイグレーション手順の提供
- バージョンアップ時の移行ツール、通知方法など

H. 継続性（ディザスタリカバリ・BCP）

地震・停電・障害などの災害時でも、サービスを継続または速やかに復旧できるようにするための要件です。

記述のポイント：

冗長性設計
- データセンターの地理的分散、クラウドリージョンのマルチ構成など
BCP（事業継続計画）の方針
- 災害時の運用体制、代替手段、復旧手順など
自動監視・通知システムの導入
- 異常を即時検知し、通知→復旧までを自動で実行する構成か

最後に

非機能要件は、「あって当たり前」と思われがちな領域ですが、実は最も失敗しやすく、かつ影響が大きい要素でもあります。

丁寧に定義し、ステークホルダーとの合意を経てから進めることが、安定したシステム開発・運用につながります。

5. セキュリティー要件

セキュリティー要件は、システムの安全性・信頼性を担保するための「守るべきルールと設計方針」を示すものです。
データ漏洩や不正アクセスなどのリスクからシステムを保護するためには、技術面・運用面の両方から明確な対策を定義しておく必要があります。

適切なセキュリティ要件を定義することで：

情報漏洩リスクの軽減
ユーザー・取引先からの信頼の確保
システムトラブルの防止
セキュリティ監査対応の簡略化

など、多くのメリットを得ることができます。

A. 情報セキュリティ

ここでは、情報を守るために必要なセキュリティレベルや、運用における取り扱いのルールを定義します。

記述のポイント：

セキュリティーレベルの定義
- 「一般」「機密」「極秘」など、情報の重要度による分類
- 例：「顧客の個人情報は“機密”レベルとして、暗号化とアクセス制限を徹底する」
アクセス制御の設計
- どのユーザーが、どの機能・データにアクセスできるかをロールベースで定義
- 例：「管理者のみが注文キャンセル機能にアクセス可能」
認証方法の指定
- ログイン時のパスワードポリシー（文字数・記号含むなど）
- 二要素認証（2FA）、SSO（シングルサインオン）などの採用有無
データ暗号化の方針
- 通信経路の暗号化（HTTPS、TLS）
- 保管データの暗号化（AES256など）、鍵管理ポリシーの記載
ウイルス対策とパッチ管理
- サーバ・端末におけるアンチウイルスソフトの導入
- OSやミドルウェアのセキュリティパッチの適用タイミング
攻撃対策（DDoS、SQLインジェクションなど）
- WAF（Web Application Firewall）の導入
- 入力チェック、セキュアコーディングルールの採用
外部媒体・不正接続対策
- USBの使用制限
- VPNや社内ネットワーク外からのアクセスポリシー

備考： 必要に応じて「ISMS」「Pマーク」などの準拠基準や、業界ガイドラインへの対応も明記すると良いです。

B. 稼働環境（対応プラットフォームと要件）

稼働環境とは、システムが動作する前提条件を示すものです。
セキュリティ面からも、安全に動作するOSやブラウザ、ネットワーク構成を定義する必要があります。

記述のポイント：

対応ブラウザ・OS一覧
- 例：
  - Windows 10/11、macOS Ventura 以降
  - Google Chrome 最新版、Microsoft Edge 最新版
セキュリティポリシーに基づく制限
- クッキー設定、JavaScript有効／無効の前提
- OS・ブラウザのセキュリティアップデートが自動で適用されること
動作保証環境と非推奨環境の区分
- 動作保証（サポート対象）と、利用可だが非推奨の環境を明記しておくとトラブル防止に役立ちます。

C. テスト（セキュリティテストと品質保証）

テストは「守られているか」を確認するための最重要プロセスです。
セキュリティ対策が“機能しているか”を検証するため、明確なテスト計画と予算配分が必要です。

セキュリティテストに関する記述のポイント：

テストの種類を明確にする
- 例：
  - 機能テスト：基本操作が想定通りに動作するか
  - 脆弱性診断：XSS・SQLインジェクションの有無を確認
  - 負荷テスト：DDoS攻撃への耐性確認
テスト範囲を定義する
- 対象画面／API／機能、及び境界条件
- 例：「ログイン・ユーザー登録・決済処理に重点」
テスト環境・実施体制
- 本番相当のデータでテストできるか（マスキングが必要か）
- 外部業者に依頼するか、内部QAチームが担当するか
評価基準の明示
- 「主要機能の成功率が98%以上で合格」など、合否判定基準を数値で記述
使用ツールの選定
- OWASP ZAP、Burp Suite、Postmanなど、使用するツールと理由を明記
テストデータの準備方針
- 個人情報を含まないダミーデータの利用／生成方法
- テスト中のログ取得方針（監査証跡としても活用）

補足：関連ドキュメント（セキュリティテスト関連）

プロジェクトの進行に応じて、以下のドキュメント群が登場します：

テスト戦略書（要件定義とセットで定義推奨）
テスト計画書（要件定義段階ではドラフト／別途予算化）
テスト設計書・テストケース・テストデータ仕様
テスト実行報告書・不具合報告書
セキュリティ診断レポート（外部診断ベンダーが発行）

備考： テストは「開発工程のコストの谷間」に入りがちな領域です。最初から要件として定義し、予算化しておくことが品質保証の第一歩です。

6. 移行要件

移行要件とは、既存システムから新システムへ、データや業務、運用体制をスムーズに移し替えるための計画と実行に関する要件です。
移行作業はプロジェクトの終盤で実施されることが多いですが、その影響範囲は非常に大きく、計画の曖昧さがトラブルの引き金になることも少なくありません。

このセクションでは、「何を」「どのように」「いつ」「誰が」移行するかを明確に定義し、ダウンタイムの最小化と業務への影響の軽減を図ります。

A. 移行（データ・システムの切替）

ここでは、システムやデータを移行するための戦略、手順、責任体制、リスク対策を定義します。

記述のポイント：

目的と範囲を定義する
- 何を移行するのか（データ、アプリケーション、設定情報など）
- どこからどこへ移行するのか（例：オンプレミス→クラウド）
- 移行のゴール（例：業務の中断なく新システムへ完全移行）
移行戦略を策定する
- 一括移行（Big Bang）
- 段階的移行（フェーズ分割・部門別）
- 並行運用（旧システムと新システムを一定期間並行稼働）
それぞれのメリット・デメリットと、今回選定した理由を明記します。
スケジュールとタイミングの設定
- 実施日、予備日、業務の空き時間（深夜・休日）を考慮
- ダウンタイムを最小限にするための時間帯設定
リスク管理と対策
- 想定されるリスク（データ欠損、移行失敗、スケジュール遅延など）
- 各リスクに対する対処方針（例：リハーサル実施、ロールバック手段の確保）
バックアップとリカバリプラン
- 移行前に実施するフルバックアップの方法と格納場所
- 失敗時の復旧方法（ロールバック手順）、復旧までの許容時間
移行手順の詳細
- ステップバイステップで具体的に記述
- 例：①現行データ抽出 → ②変換スクリプト適用 → ③新DBに登録 → ④検証
移行時の責任者・体制の明記
- 作業実施者、レビュー担当、最終承認者
- 外部業者を含む場合は、責任分界点を明確に
移行後の検証手順（バリデーション）
- データ件数や整合性の確認方法
- 機能テスト、パフォーマンステスト、ユーザーチェック（UAT）など

B. 引継ぎ（知識・運用ノウハウの移管）

新システムへの移行後も業務が滞りなく継続できるよう、関係者への運用ノウハウ・手順の引継ぎが不可欠です。

記述のポイント：

引継ぎの対象範囲を明確化する
- 業務ルールや設定情報、操作マニュアル、障害対応手順など
- 例：「ユーザー管理手順、ログ調査方法、バックアップ確認方法を含む」
引継ぎ対象者の明示
- 社内運用担当、カスタマーサポート、外部ベンダーなど
- 引継ぎを受ける側の理解度を考慮して設計
引継ぎ手段・形式の決定
- ドキュメントの配布（操作手順書、設計書）
- 対面説明（ミーティング・ハンズオン）
- eラーニングや録画済み動画の活用
引継ぎスケジュールの作成
- 複数回に分ける場合は、内容とタイミングを整理
- 例：「初回：概要説明」「2回目：操作手順」「最終回：障害対応訓練」
トレーニング計画の策定
- 受講対象、内容、所要時間、形式（オンライン・対面）
- トレーニング資料の配布や、理解度チェックの実施も検討
引継ぎ後のサポート体制を定義する
- 問い合わせ窓口、受付時間、FAQ・ナレッジベースの提供
- サポート期限（例：1ヶ月間の並走対応）を明記すると親切

備考： 引継ぎが曖昧だと、運用開始後の混乱や問い合わせ増加に直結します。
ドキュメントとトレーニングの両面から、**「業務が自走できる状態」**を目指しましょう。

7. 運用要件

運用要件は、システム導入後の安定稼働と継続的な活用を実現するために必要な体制・仕組みを定義するものです。
この章では、利用者の教育、日常運用、長期的な保守に分けて、「誰が」「いつ」「どうやって」運用していくかを具体的に示します。

A. 教育（トレーニング・活用支援）

システム導入後、利用者が円滑にシステムを操作し、最大限活用できるようにするための教育計画を策定します。

教育要件の書き方

教育の目的を明確にする
- 例：「新システムの基本操作を習得させる」「セキュリティポリシーへの理解を深める」
- 教育のゴールを明記することで、内容の選定や評価にも役立ちます。
対象者を定義する
- 一般ユーザー、運用担当者、管理者など、ロール（役割）ごとに分類
- 各対象者に求められる知識・スキルレベルを把握しておく
教育内容を設計する
- 基本操作、応用機能、トラブル対応、FAQなど
- セキュリティ意識向上や業務ルールとの整合性にも配慮
教育の方法・ツールを決める
- 形式：対面講習、オンライン研修、動画マニュアル、eラーニング
- 資料：操作マニュアル、スライド、チェックリスト、実習課題など
スケジュール・実施方法を決定する
- 実施日、所要時間、参加方法（会議室・Zoom等）
- 部署ごとに日程を分けることも検討

備考： 教育内容は「資料化」しておくことで、新人教育や制度定着にも再利用できます。

B. 運用（日常業務と体制）

導入されたシステムが日々の業務の中で安定して運用されるよう、組織体制と運用ルールを明文化します。

運用要件の書き方

運用体制の構築
- チーム構成と役割分担（例：オペレーター／監視担当／障害対応チーム）
- 必要なスキルと対応時間（常駐／オンコールなど）
運用業務の定義
- 定常業務：バックアップ、ログ確認、サーバ監視
- 非定常業務：アラート対応、ユーザー管理、障害復旧
運用ポリシーの策定
- 例：アクセス権限の付与・削除ルール、パスワード更新基準、データ保持方針
- 組織のセキュリティガイドラインとの整合も確認
運用スケジュールの計画
- 日次／週次／月次で行う定期作業の一覧
- メンテナンスのタイミング、予告方法（例：月1回の定期停止）
ユーザーサポート体制の整備
- 問い合わせ窓口、対応可能時間、エスカレーションルール
- ナレッジベースやFAQの整備も有効

C. 保守（安定稼働と長期運用のために）

システムを長期にわたって安全かつ高品質で提供し続けるための維持・改良活動に関する要件です。

保守要件の書き方

保守の目的と対象範囲を明確にする
- 目的：安定稼働、障害復旧、セキュリティ維持
- 範囲：ソフトウェア、ハードウェア、ネットワーク、外部サービス
保守の主な領域を定義する

保守領域	内容
ソフトウェア更新	セキュリティパッチ、機能追加、バグ修正
ハードウェア点検	障害予防のための定期診断
セキュリティ監視	攻撃兆候のモニタリング、WAFログ分析
障害対応	インシデント対応手順と連絡体制
データバックアップ	バックアップ頻度、保存期間、検証手順
DR対策	災害復旧計画（DR：Disaster Recovery）

担当者と責任の割り当て
- 保守ベンダー、社内IT部門の役割分担
- SLAに基づく対応レベルと時間（例：P1は2時間以内対応）
保守ツール・リソースの整備
- 監視：Zabbix、Datadog、Nagios
- バックアップ：Veeam、Acronis
- セキュリティ：Wazuh、FortiGate、脆弱性診断ツール
モニタリングとレポーティングの体制
- 障害レポート、月次報告書、変更履歴の管理
- ログ収集・分析の自動化や可視化（例：Grafanaなどの導入）
ステークホルダーとの情報共有・連携手順
- 保守スケジュールの共有、バージョンアップの事前通知
- 緊急時の連絡網（例：メール・電話・Slack）を定義

参考： 保守に関するSLA要件は以下も参照：
SLAの書き方（Qiita）

最後に

運用要件は、単なる「導入後の運用ルール」ではなく、
ユーザーが安心して使い続けられる“仕組みの品質保証”そのものです。

教育 → 運用 → 保守という流れを計画的に整備することで、
「良いシステムを作ったのに使われない」「運用が回らない」という事態を未然に防ぐことができます。

テンプレート

ここにワード版のテンプレートが置いてありますので自由にお使いください。　このテンプレートに沿って埋めていけば、要件定義は完成です。