公開当初から多くの方に読んでいただき、現在では 53万View、2,200件以上のストック、2,036件のいいね をいただく記事となりました。 読んでくださった皆様、ストックしてくださった皆様、本当にありがとうございます。

この記事を最初に書いた頃から、AI開発は大きく進化し、ソフトウェア開発の現場も大きく変わりました。
AIによるコード生成、仕様書作成の支援、テスト自動化、設計レビューなど、開発の進め方そのものが以前とはかなり違うものになっています。一方で、どれだけAIが進化しても、変わらず重要なものがあります。 それが、「何を作るのか」「なぜ作るのか」「どこまで作るのか」を明確にすることです。

むしろAIを活用する時代だからこそ、仕様や要件が曖昧なままだと、AIはそれっぽいものを高速に作れてしまいます。 その結果、早く作れたように見えても、後から認識のズレや手戻りが発生し、結果的に開発コストが膨らむこともあります。だからこそ、要件定義や仕様作成の重要性は以前よりも増していると感じています。
今回の更新では、これまでいただいたフィードバックや、AI時代の開発現場の変化を踏まえながら、内容をより実践的に見直しました。 特に、非機能要件、移行・引継ぎ、運用・保守といった、プロジェクトの成功を左右する部分について、現場で使いやすい形になるよう表現を整理しています。

この記事が、これからシステム開発やプロダクト開発に関わる方にとって、少しでも失敗を減らすための参考になれば幸いです。

はじめに

システム開発やプロダクト開発では、「何を作るか」を決めることが最初の大きな仕事です。 しかし実際の現場では、この「何を作るか」が曖昧なまま開発が始まってしまうことが少なくありません。そして、AIを使った開発が当たり前になりつつある今、この問題はさらに重要になっています。

AIは、曖昧な指示でもそれらしい画面、コード、仕様書をすばやく作ってくれます。 これは非常に便利な一方で、前提や目的が曖昧なままだと、間違った方向に高速で進んでしまう危険もあります。つまり、AI時代の開発では、「作れるかどうか」よりも、「何を、なぜ、どこまで作るべきか」を正しく定義することが、これまで以上に重要になっています。

その土台になるのが、要件定義です。

要件定義とは

要件定義とは、開発するシステムやプロダクトについて、必要な機能、性能、制約、業務上の前提、運用条件などを整理し、関係者の共通認識として明文化する作業です。簡単に言えば、「このプロジェクトでは、何を実現するのか」「何はやらないのか」「どの条件を満たせば完成と言えるのか」を決める工程です。

要件定義が不十分なまま開発を始めると、次のような問題が起きやすくなります。

• 作ったものが、ユーザーや依頼者の期待とズレる
• 開発途中で「やっぱりこれも必要」が増え続ける
• 見積もり、スケジュール、優先順位が崩れる
• テストや受け入れの基準が曖昧になる
• リリース後に運用・保守で困る

AIを使った開発でも、これは同じです。 むしろAIは作業スピードが速い分、要件が曖昧なままだと、ズレた成果物も速く大量に生まれてしまいます。だからこそ、要件定義は単なるドキュメント作成ではありません。 開発チーム、人間、AI、関係者全員が同じ方向に進むための「地図」のようなものです。 個人的には、要件定義とは「開発を成功させるための作業」というより、システム開発をできるだけ失敗させないための防波堤だと考えています。
この文章では、実際の開発現場で使いやすい形で、要件定義書に書いておくべき内容を整理していきます。

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

要件定義に入る前に、まずは「誰が、何を、なぜ、いつまでに、どこまで、どうやって」求めているのか、という情報を整理しましょう。

これはいわゆる 5W1H の観点で考えると非常にスムーズです。

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

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

要件定義書

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

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

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

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

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

バージョン管理の例：

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

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

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

1. 概要

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

A. システム構成図

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

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

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

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

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

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

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

B. 背景

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

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

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

C. 用語定義（Glossary）

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

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

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

2. 業務要件

業務要件とは、ある業務を適切に遂行するために必要な機能・仕様・制約などをまとめたものです。
この章では、「業務の流れ」や「処理量」「タイミング」「評価指標」などを整理し、それらがシステムにどのように反映されるべきかを明確にします。
業務要件は、業務を円滑に・効率よく進めるための「設計図」のようなものです。
これを正しく定義することで、業務の最適化はもちろん、システム導入後のトラブル防止や、将来的な改善にもつなげることができます。

A. 業務フロー

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

業務フロー図の作成手順

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

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

B. 規模（スケール）

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

規模定義の例：

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

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

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

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

書き方の例：

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

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

業務プロセスの効果や品質を測るための指標をここに定義します。
指標を設定することで、業務の改善ポイントを明確にし、PDCAサイクルの起点とすることができます。
そしてもう一つ重要な役割があります。それは、「このシステムが成功したかどうか」を後から客観的に判断できるようにすることです。
指標がないと、リリース後に「なんとなく良くなった気がする」で終わってしまい、投資対効果（ROI）を説明できません。要件定義の段階で「何をもって成功とするか」を数値で決めておくことが、プロジェクト全体の評価軸になります。

なぜ要件定義でKPIを決めるのか

• 成功の定義が共有できる … 発注者・開発者・利用部門が「どうなれば完成・成功か」を同じ数字で認識できます。
• 優先順位の判断基準になる … 「その機能はどのKPIを動かすのか」で機能の要否を議論できます。
• 改善のスタート地点になる … 現状値（Baseline）を測っておくことで、導入後にどれだけ改善したかを比較できます。

✅ ポイント： KPIは「現状値」とセットで決めるのが鉄則です。目標値だけを掲げても、現状が分からなければ達成度を測れません。

よく使われる指標例：

指標名	説明	計算・測定のしかた
サイクルタイム	各業務ステップにかかる平均処理時間。短いほど効率的。	1件あたりの処理時間の平均
リードタイム	開始から完了までにかかる総時間。待ち時間を含む。	完了時刻 − 受付時刻
処理能力（スループット）	単位時間あたりの処理件数。	一定時間内に処理した件数
エラー率	処理全体に対する不備・エラーの発生率。品質管理に有効。	エラー件数 ÷ 全処理件数
待機時間	次の処理に移るまでの待ち時間。ボトルネックになりやすい。	各工程の滞留時間の合計
手戻り率	やり直しが発生した割合。要件の曖昧さや品質を映す。	差し戻し件数 ÷ 全処理件数
自動化率	人手を介さず処理できた割合。省力化の効果指標。	自動処理件数 ÷ 全処理件数
稼働率	業務時間に対して実際に稼働できた割合。	稼働時間 ÷ 対象時間

KPIの設定手順

1. 業務のゴールを言語化する … 「処理を速くしたい」「ミスを減らしたい」など、まず目的をはっきりさせます。
2. 目的に合う指標を選ぶ … 速度ならリードタイム、品質ならエラー率、といったように目的と指標を対応させます。指標が多すぎると管理しきれないため、まずは3〜5個に絞るのが現実的です。
3. 現状値（Baseline）を測る … 導入前の数字を記録します。ここが比較の基準になります。
4. 目標値と期限を決める … 「いつまでに、どの数字にするか」を明記します。
5. 測定方法・データの取得元を決める … その数字を「どこから」「どうやって」取るのかを決めておかないと、後で測れません。

目標設定の例（現状 → 目標）

指標名	現状値	目標値	期限	測定方法
注文処理リードタイム	平均48時間	平均2時間以内	稼働3か月後	受注〜出荷完了の時刻差を自動集計
入力エラー率	5.0%	1.0%以下	稼働6か月後	エラーログ件数 ÷ 全登録件数
手作業による処理割合	70%	20%以下	稼働6か月後	自動処理件数の比率をダッシュボード表示

良い例／悪い例：

• 悪い例：「業務を効率化する」… 何が、どれだけ良くなれば成功か判断できません。
• 良い例：「注文処理のリードタイムを平均48時間から2時間以内に短縮する」… 現状・目標・対象が明確で、達成可否を判定できます。

指標は「測れる設計」にしておく

どれだけ良いKPIを決めても、データが取れなければ絵に描いた餅です。
要件定義の段階で、各指標が自動で集計・可視化される仕組み（ログ出力、集計バッチ、ダッシュボードなど）を機能要件・非機能要件側にも織り込んでおきましょう。運用開始後の改善（PDCA）が一気に回しやすくなります。

備考： これらの指標は、システム化により自動集計されるように設計することで、運用後の改善にも活用できます。近年はBIツールやダッシュボード（例：Grafana、Looker Studio、Power BIなど）で可視化するのが一般的です。

E. 範囲（スコープ）

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

書き方のポイント：

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

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

3. 機能要件

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

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

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

機能分類の例：

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

機能要件を書く手順

1. 階層的なブレイクダウンを決める
   • 業務や画面単位などで、大→中→小へ整理。各機能の関係性が見えるようにする。
2. 各機能の説明を書く
   • その機能が「何をするのか」「なぜ必要なのか」を簡潔かつ明確に記述する。
3. 利用シナリオを書く（可能なら）
   • 機能の使用例やユーザーストーリーを記述することで、背景や重要性がより伝わりやすくなります。
4. 受け入れ条件（Acceptance Criteria）を明記する
   • 「何ができること」で終わらせず、「どの入力に対して、どう振る舞えば正しいのか」を検証可能な形で書きます。
   • これは特にAIを使った開発で重要になります。曖昧な機能説明でもAIはそれらしい実装をすばやく作ってしまうため、合否を判定できる基準がないと、ズレた成果物が高速に量産されてしまいます。
   • 「ユーザー、AI、テスト担当の誰が読んでも合否が一致する」水準を目指しましょう。

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

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

例：受け入れ条件（注文登録）

• 悪い例： 「注文を登録できること」
• 良い例：
  • 必須項目（商品・数量）が未入力の場合は登録できず、エラーメッセージを表示すること
  • 在庫数を超える数量が入力された場合は登録を拒否し、理由を表示すること
  • 登録成功時は在庫が入力数量分だけ減算され、ステータスが「受注済み」になること
  • 登録処理が失敗した場合は在庫を変更しないこと（整合性を保つこと）

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

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

画面要件の書き方

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

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

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

C. 情報・データ・ログ

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

書き方と例：

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

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

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

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

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

書き方と構成例：

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

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

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

• データ項目名・型・必須性
• 送信形式（JSON/XML/CSVなど）
• 通信方法（HTTPS/FTPなど）
• 認証方式（OAuth2、Basic認証など）
  3.エラーハンドリングを明記する
• 外部連携エラー時の再送処理の有無
• ログへの記録ルール
• ユーザーへの通知方法（ポップアップ、アラートなど）

補足

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

4.非機能要件

非機能要件とは、システムの「見えにくいが非常に重要な品質面」に関する要件です。
具体的には、性能（スピード）・信頼性（壊れにくさ）・拡張性（成長への備え）・使いやすさなどが含まれます。
これらはシステムの成功を裏から支えるものであり、たとえ機能が豊富でも、非機能要件を疎かにするとユーザー離れや障害の原因になります。
特に、開発初期段階で非機能要件を明文化しておくことで：

• 品質基準が明確になる
• 見積もりの精度が向上する
• プロジェクト全体のリスクが減少する
  といった大きなメリットがあります。
  なお、運用開始後は環境やニーズの変化に応じて、非機能要件を定期的に見直すことも推奨されます。

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

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

記述のポイント：

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

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

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

記述のポイント：

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

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

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

例：

項目	数値
同時接続ユーザー数	最大5,000人
1日あたりのトランザクション数	約200,000件
保持データ件数	約1億レコード
※あくまで想定値でも良いですが、初期構成に影響する重要情報です。

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

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

記述のポイント：

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

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

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

記述のポイント：

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

F. 拡張性

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

記述のポイント：

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

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

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

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

記述のポイント：

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

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

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

記述のポイント：

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

I. AI・LLMを組み込む場合の考慮点

システム自体がAI（特にLLM API）を利用する場合、従来の非機能要件の枠に収まらない要素が出てきます。
外部のAIサービスに処理を委ねる以上、性能・コスト・品質のいずれもが「自分たちだけでは制御しきれない」前提で設計する必要があります。

記述のポイント：

1. 応答時間（レイテンシ）
   • AIの推論には数秒かかることがあり、従来の「3秒以内」といった基準をそのまま適用できない場合があります。
   • 例：「AI生成部分は初回応答までに最大10秒を許容し、その間はローディング表示を出す」「ストリーミング表示で体感速度を担保する」など。
2. コスト（トークン課金）
   • LLM APIは処理量（トークン数）に応じて課金されるため、利用が増えるほどコストが積み上がります。
   • 想定利用回数、1回あたりの平均トークン数、月間コスト上限、超過時の挙動（制限するか課金を続けるか）を定義しておきます。
3. 出力の非決定性（揺らぎ）
   • 同じ入力でも出力が毎回同じとは限りません。厳密な再現性が必要な処理にAIを使うべきかは要検討です。
   • 再現性が必要な箇所は温度（temperature）を下げる、あるいはAIを使わずルールベースにする、といった方針を明記します。
4. ハルシネーション（誤生成）への対応
   • AIは事実と異なる内容をもっともらしく出力することがあります。
   • 誤りが許容されない領域（金額、法務、医療など）では、人間の確認を必須にする、出典を提示させる、といった歯止めを要件化します。
   • 「どこまでの誤りを許容するのか」「誤った場合に誰が責任を持つのか」を関係者で合意しておくことが重要です。
5. 可用性・フォールバック
   • 外部AIサービスは障害やレート制限で応答しないことがあります。
   • AIが使えないときの代替動作（機能を一時停止する／キャッシュを返す／エラーを明示する）を定義しておきます。

備考： これらはセキュリティ要件（プロンプトインジェクションや情報流出）とも密接に関わります。あわせて「5. セキュリティー要件」の該当項目も参照してください。

最後に

非機能要件は、「あって当たり前」と思われがちな領域ですが、実は最も失敗しやすく、かつ影響が大きい要素でもあります。
丁寧に定義し、ステークホルダーとの合意を経てから進めることが、安定したシステム開発・運用につながります。

5. セキュリティー要件

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

• 情報漏洩リスクの軽減
• ユーザー・取引先からの信頼の確保
• システムトラブルの防止
• セキュリティ監査対応の簡略化
  など、多くのメリットを得ることができます。

A. 情報セキュリティ

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

記述のポイント：

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

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

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

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

記述のポイント：

1. 対応ブラウザ・OS一覧
   • バージョンを固定で書くとすぐ陳腐化するため、「最新版を含む直近◯バージョンをサポート対象とする」といった相対的な書き方を推奨します。
   • 例：
     • Windows：サポート継続中の最新バージョン（メーカーのサポート終了済みOSは対象外とする）
     • macOS：最新版を含む直近2バージョン
     • Google Chrome / Microsoft Edge：最新版（自動更新前提）
   • 備考：OSやブラウザには提供元のサポート終了（EOL）時期があります。EOLを迎えた環境はセキュリティ更新が止まるため、対象外とする方針を明記しておくと安全です。
2. セキュリティポリシーに基づく制限
   • クッキー設定、JavaScript有効／無効の前提
   • OS・ブラウザのセキュリティアップデートが自動で適用されること
3. 動作保証環境と非推奨環境の区分
   • 動作保証（サポート対象）と、利用可だが非推奨の環境を明記しておくとトラブル防止に役立ちます。

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

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

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

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

D. AI・LLM利用時のセキュリティ

システムがAI（LLM APIなど）を利用する場合、従来のセキュリティ対策だけでは防げない、AI固有のリスクが生まれます。
これらは新しい領域で見落とされがちですが、情報漏洩や不正操作に直結するため、要件段階で明文化しておくべきです。

記述のポイント：

1. プロンプトインジェクション対策
   • ユーザー入力や外部から取り込んだデータに、AIへの指示を上書きする悪意ある文字列が混入する攻撃です。
   • 「システム指示とユーザー入力を分離する」「AIの出力をそのまま実行・表示しない（検証を挟む）」といった方針を定めます。
2. 機密情報の外部送信リスク
   • 外部のLLM APIにデータを送る場合、そのデータが第三者のサーバーに渡ることを意味します。
   • 個人情報や機密情報を送信してよいか、送るならマスキング・匿名化するか、送信先が学習に利用しない契約になっているか（オプトアウト）を確認・明記します。
3. 生成コード・生成物の安全性
   • AIが生成したコードには脆弱性や非推奨な実装が含まれることがあります。
   • 「AI生成コードも必ず人間のレビューとセキュリティチェックを通す」ことをルール化します。
4. 権利・ライセンスの確認
   • AIが生成した文章・画像・コードの権利関係やライセンスが不明確な場合があります。
   • 商用利用の可否、既存著作物との類似リスク、利用するAIサービスの利用規約を確認しておきます。
5. 出力に対するアクセス制御・監査
   • AIが権限を超えた情報を出力しないよう、AIに渡すデータの範囲を利用者の権限に応じて制限します。
   • 誰がどんな入力をし、AIがどんな出力をしたかをログとして記録・追跡できるようにしておくと、問題発生時の調査に役立ちます。

備考： AI関連のセキュリティは発展途上の領域です。最新のガイドライン（例：OWASP の LLM 向けリスク一覧など）も参照しながら、継続的に見直すことをおすすめします。

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

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

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

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

6. 移行要件

移行要件とは、既存システムから新システムへ、データや業務、運用体制をスムーズに移し替えるための計画と実行に関する要件です。
移行作業はプロジェクトの終盤で実施されることが多いですが、その影響範囲は非常に大きく、計画の曖昧さがトラブルの引き金になることも少なくありません。
このセクションでは、「何を」「どのように」「いつ」「誰が」移行するかを明確に定義し、ダウンタイムの最小化と業務への影響の軽減を図ります。

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

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

記述のポイント：

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

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

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

記述のポイント：

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

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

7. 運用要件

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

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

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

教育要件の書き方

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

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

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

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

運用要件の書き方

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

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

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

保守要件の書き方

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

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

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

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

最後に

運用要件は、単なる「導入後の運用ルール」ではなく、
ユーザーが安心して使い続けられる“仕組みの品質保証”そのものです。
教育 → 運用 → 保守という流れを計画的に整備することで、
「良いシステムを作ったのに使われない」「運用が回らない」という事態を未然に防ぐことができます。