要件定義の例 システム種類別の要件例と、機能要件・非機能要件の悪い例から良い例への書き換え集

「要件定義の書き方は理解したが、自社のシステムだと具体的にどう書けばよいのか例が見たい」「自分が書いた要件が曖昧かどうか判断できない」という悩みは、初めて要件定義を担当する発注側の担当者やエンジニアに共通しています。要件定義は「何を書くか」を知るだけでは書けず、「どの程度具体的に書くか」の感覚が必要です。

この記事では、システムの種類別に要件定義の例を7ケース紹介したうえで、機能要件・非機能要件・業務要件の「悪い例」を「良い例」に書き換える具体例を集めました。自社の要件を書く際の見本として、また書いた要件を点検する基準として活用してください。まずは、この記事の要点を表で確認してください。

確認したいポイント	結論	詳細
良い要件の条件は？	一意に解釈でき、検証でき、根拠がある要件	主観的な表現がなく、テストや測定で判定でき、目的との対応と優先度の根拠が示され、粒度が揃っている
システム別の要件例で何がわかる？	種類ごとに押さえるべき観点と勘所	受発注・予約・EC・在庫・勤怠・AIチャットボット・SaaS導入の目的、主な機能・非機能要件、注意点を例示
曖昧な要件はどう直す？	条件と数値に置き換え、例外と判断基準を書く	「使いやすい」「自動で」「適切に」を入力・処理・出力と条件で具体化し、1要件1内容に分けてIDを付ける
自社の要件はどう点検する？	第三者がテストケースを作れるかで判定	主観語や「など」の有無、要件IDと優先度、例外時の動作、非機能の数値と測定方法、AIの精度目標を確認する

この記事でわかること

• 要件定義の例を読む前に押さえておきたい、良い要件の条件
• 業務システム・予約・EC・在庫・勤怠・AIチャットボット・SaaS導入など、システム種類別の要件例
• 機能要件の悪い例から良い例への書き換え例
• 非機能要件と業務要件の悪い例から良い例への書き換え例
• 自社の要件を点検するためのチェックの観点と、例を使う際の注意点

要件定義の例を読む前に押さえておきたい「良い要件」の条件

要件定義の例をそのまま真似ても、自社のシステムに合った要件にはなりません。例から学ぶべきなのは「書き方の型」と「具体性の水準」です。ここでは、良い要件に共通する条件を整理し、以降の例を読む視点を揃えます。

良い要件の5つの条件

• 一意に解釈できる：読む人によって意味が変わらない。「使いやすい」「速い」「適切に」といった主観的な表現がない
• 検証できる：完成後に「満たしているかどうか」をテストや測定で判定できる
• 必要性が説明できる：どの業務課題や目的のために必要なのかが明確で、優先度の根拠がある
• 実現可能性が確認されている：技術・費用・期間の制約のなかで実現できることを開発側と確認している
• 粒度が揃っている：要件ごとの大きさが極端に違わず、1つの要件に複数の内容が混ざっていない

独立行政法人情報処理推進機構（IPA）が公開している「ユーザのための要件定義ガイド 第2版」では、要件定義で発生しやすい48の問題と、解決のための128の勘どころが整理されています。要求の曖昧さ、要求の抜け漏れ、非機能要求の不足、ステークホルダー間の認識のずれといった問題は、いずれも要件の書き方と密接に関係しており、本記事の書き換え例もこうした問題を避ける観点でまとめています。

（出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」 ）

要件を書くときの基本形

機能要件は、「誰が」「どのような条件で」「何を入力すると」「システムが何をして」「何を出力するか」の形で書くと、曖昧さが減ります。非機能要件は、「項目」「要求水準（数値・条件）」「測定方法」をセットで書きます。業務要件は、「現状の業務」「課題」「システム導入後の業務」「達成する状態」を対応付けて書きます。

要件を読んだ人が、テストケースを作れるかどうかが、具体性の水準を判断する簡単な基準です。以降の例は、すべてこの基準を満たすことを意識して記述しています。

要件定義書全体の構成や記載項目については、システム要件定義書の書き方と記載項目の記事で解説しています。

システム種類別の要件定義の例

ここでは、中小・中堅企業で開発や導入の対象になりやすい7種類のシステムについて、目的・主な機能要件・非機能要件の要点を例として示します。実際の要件定義書はこれより詳細になりますが、「このシステムなら、この観点が必要」という勘所をつかむ参考にしてください。

例1：受発注管理システム（製造・卸売業）

• 目的：電話・FAX・メールで受けている注文をシステムで一元管理し、受注入力の二重作業をなくす。受注から出荷指示までの時間を1営業日から2時間以内に短縮する
• 機能要件の例：営業担当者が顧客・商品・数量・納期を入力すると、在庫を確認して引当を行い、受注番号を採番する（F-001、必須）。受注確定時に出荷指示データを作成し、倉庫担当者の画面に表示する（F-002、必須）。顧客ごとの単価と値引き条件をマスタで管理し、受注時に自動適用する（F-003、必須）
• 非機能要件の例：受注入力画面の応答時間は2秒以内。稼働時間は平日7時〜20時。受注データは10年間保持する。既存の会計システムへ日次で売上データを連携する
• このシステムの勘所：例外的な受注（分納、返品、単価の個別交渉）の扱いを要件に含めること。既存システムとの連携仕様を早期に確認すること

例2：予約管理システム（店舗・サービス業）

• 目的：電話予約の対応時間を削減し、営業時間外の予約を取りこぼさない。Web予約の比率を30％から70％に引き上げる
• 機能要件の例：顧客がWebサイトから日時・メニュー・担当者を選択して予約でき、空き状況は10分間隔で表示する（F-001、必須）。予約確定時に顧客と店舗の双方に確認メールを送信し、前日にリマインドを送信する（F-002、必須）。店舗スタッフが電話予約を手動で登録し、Web予約と同じ枠で管理できる（F-003、必須）。キャンセル待ちの受付と、空きが出た際の自動通知（F-004、あれば望ましい）
• 非機能要件の例：同時アクセス50件で予約完了までの操作が5秒以内。予約データは個人情報として暗号化して保存し、退会後1年で削除する。スマートフォンのブラウザでの操作を主とする
• このシステムの勘所：予約の重複防止（同一枠への同時予約）の扱いと、キャンセル・変更のルールを業務要件として明確にすること

例3：ECサイト（小売業）

• 目的：実店舗の顧客にオンラインでも購入してもらい、EC売上を年間3,000万円にする。注文から出荷までの処理を自動化する
• 機能要件の例：商品の一覧・検索・詳細表示、カート、決済（クレジットカード・コンビニ払い）、注文確認メールの送信（F-001〜F-005、必須）。会員登録と購入履歴の表示（F-006、必須）。在庫数を実店舗と共有し、在庫切れ商品は購入不可にする（F-007、必須）。クーポンとポイントの付与・利用（F-008、重要）
• 非機能要件の例：商品一覧の表示は3秒以内。セール時の同時アクセス500件に耐える。決済情報はカード情報を自社で保持しない方式とする。年間稼働率99.5％以上
• このシステムの勘所：決済・配送・在庫の外部連携の要件と、法令（特定商取引法の表示、個人情報保護）への対応を要件に含めること

例4：在庫管理システム（製造・物流業）

• 目的：手作業の棚卸しと、Excelでの在庫管理をやめ、リアルタイムに在庫数を把握する。棚卸しの工数を月40時間から10時間に削減し、欠品による機会損失を減らす
• 機能要件の例：入荷・出荷・移動・廃棄の各処理を、ハンディ端末のバーコード読み取りで登録する（F-001、必須）。倉庫・棚・ロット単位で在庫数を照会できる（F-002、必須）。安全在庫を下回った商品を一覧表示し、担当者に通知する（F-003、必須）。棚卸し用の帳票出力と、実棚数の入力による差異の記録（F-004、必須）
• 非機能要件の例：バーコード読み取りから登録完了まで1秒以内。倉庫内の無線LAN環境で動作する。入出荷の履歴は5年間保持する。既存の受発注システムと在庫数を1時間ごとに同期する
• このシステムの勘所：在庫の単位（個・箱・ロット）と換算のルール、先入れ先出しなど出庫の優先順位を業務要件として明確にすること

例5：勤怠管理システム（全業種）

• 目的：紙のタイムカードと手集計をやめ、勤怠の集計から給与計算への連携までを自動化する。月次の勤怠集計にかかる工数を20時間から2時間に削減する
• 機能要件の例：社員がスマートフォン・PC・ICカードで出退勤を打刻できる（F-001、必須）。残業・休暇・出張の申請と上長の承認をシステム上で行う（F-002、必須）。就業規則に基づく勤務区分ごとに労働時間・残業時間・深夜時間を自動計算する（F-003、必須）。月次の勤怠データを給与システムの取込形式で出力する（F-004、必須）。残業時間が上限に近づいた社員と上長に通知する（F-005、重要）
• 非機能要件の例：打刻は3秒以内に完了する。打刻データは改ざん防止のため修正履歴を残す。勤怠データは法定の保存期間に従い保持する。労働時間の集計ルールは法改正時に設定変更で対応できる
• このシステムの勘所：自社の就業規則の勤務区分・休暇制度・締め日をすべて洗い出し、例外（変形労働時間、裁量労働、短時間勤務）の扱いを要件に含めること

例6：AIチャットボット（問い合わせ対応・社内ヘルプデスク）

• 目的：顧客または社員からの定型的な問い合わせをAIが一次対応し、担当者の対応件数を50％削減する。営業時間外の問い合わせにも即時に回答する
• 機能要件の例：利用者が自由入力した質問に対し、登録したFAQと社内文書を参照して回答を生成し、参照した情報源を表示する（F-001、必須）。回答できない場合は有人の問い合わせ窓口へ誘導する（F-002、必須）。管理者がFAQと参照文書を登録・更新できる（F-003、必須）。質問と回答のログを記録し、回答の評価（役に立った・立たなかった）を収集する（F-004、必須）
• AI特有の要件の例：回答の正答率を評価用の質問100件で80％以上とする。料金・契約条件など誤りが許されない質問は、回答を生成せず案内文と担当窓口を表示する。利用するAIサービスは、入力データがサービス提供者側の学習に利用されない契約とする。個人情報を含む質問は、AIサービスへ送信する前に該当箇所を除去する。PoCで2週間の検証を行い、正答率と利用者の評価をもとに本開発の要件を確定する
• 非機能要件の例：回答の表示は10秒以内。同時利用者数50名。ログは1年間保持する
• このシステムの勘所：AIが誤った場合の業務上の対応、精度の目標と測定方法、参照データの整備の責任分担、運用開始後の精度管理を要件に含めること

AIを組み込んだシステムの要件定義の考え方や開発の進め方については、AI受託開発の費用相場と開発会社の選び方の記事でも解説しています。

例7：SaaS導入（顧客管理ツールの導入）

• 目的：営業担当者ごとにExcelで管理している顧客情報と商談状況を一元化し、営業会議の資料作成時間を週5時間から1時間に削減する
• 業務要件の例：顧客・商談・活動履歴を登録し、担当者・ステージ・確度で絞り込んで一覧表示する。商談ステージの定義と確度の基準を全社で統一する。週次の商談一覧と月次の受注予測を自動集計する
• 適合確認の例：業務要件ごとに「標準機能で対応可」「設定で対応可」「対応不可」を判定する。自社独自の商談ステージは設定で対応可。既存の会計システムとの連携は標準機能では対応不可のため、CSVの手動取込で運用する
• 非機能・移行要件の例：既存のExcelから顧客データ約3,000件を移行し、重複を統合する。営業担当者20名にアカウントを発行し、2時間の操作研修を実施する。個人情報の保管場所とサービス提供者のセキュリティ認証を確認する
• この導入の勘所：システムを業務に合わせるのではなく、業務をシステムに合わせる判断を含めること。「対応不可」の項目にどう対処するかを決めること

【無料資料のご案内】 要件定義から開発・運用までを一貫して支援するサービスの内容や、要件定義の進め方をまとめた資料を無料でご用意しています。まずは概要を確認したい方は、以下から資料をご請求ください。 ▶ 資料請求はこちら（https://nextscale.co.jp/service-document/）

機能要件の悪い例から良い例への書き換え

ここからは、実際の要件定義書でよく見かける曖昧な機能要件を「悪い例」として挙げ、一意に解釈でき、検証できる「良い例」に書き換えます。自社の要件を点検する際の基準として活用してください。

書き換え例1：主観的な表現を条件と数値に置き換える

• 悪い例：検索機能を使いやすくする
• 良い例：商品名・商品コード・カテゴリのいずれかを入力欄に入力すると、部分一致で該当商品を一覧表示する。検索結果は50件ごとに表示し、価格・登録日で並べ替えができる。検索結果の表示は2秒以内とする

「使いやすく」は人によって意味が異なります。何を入力すると、何がどう表示されるかまで書くことで、設計とテストが可能になります。

書き換え例2：1つの要件に複数の内容を混ぜない

• 悪い例：顧客情報を登録・編集・削除でき、CSVで出力でき、権限のない人は見られないようにする
• 良い例：F-010 顧客情報の登録・編集（担当者が顧客名・住所・連絡先・担当者名を登録・編集できる）。F-011 顧客情報の削除（管理者のみが削除でき、削除時は確認ダイアログを表示し、削除履歴を記録する）。F-012 顧客情報のCSV出力（一覧画面の絞り込み結果をCSV形式で出力する）。F-013 閲覧権限（一般利用者は自部門の顧客のみ、管理者は全顧客を閲覧できる）

1つの要件に複数の内容が混ざっていると、優先度の判断や進捗の管理ができません。1要件1内容に分け、IDを付けることが基本です。

書き換え例3：例外時とエラー時の動作を書く

• 悪い例：注文を登録すると在庫が引き当てられる
• 良い例：注文の登録時に、商品ごとに在庫数を確認して引き当てる。在庫が不足している場合は、不足数を表示したうえで「取り寄せ注文として登録する」「数量を変更する」「登録を中止する」のいずれかを担当者が選択できる。同一商品への同時注文で在庫が競合した場合は、先に登録処理を開始した注文を優先する

正常な流れだけの要件は、運用開始後の「この場合はどうなるのか」という問題を生みます。うまくいかない場合の動作を要件に含めましょう。

書き換え例4：「自動で」「適切に」の中身を書く

• 悪い例：問い合わせを自動で適切な担当者に振り分ける
• 良い例：問い合わせの本文に含まれるキーワードと、あらかじめ管理者が設定した「キーワードと担当部門の対応表」に基づいて担当部門を判定し、部門内で担当中の件数が最少の担当者に割り当てる。いずれのキーワードにも該当しない場合は「未分類」として管理者に通知する。対応表は管理者が画面から変更できる

「自動で」「適切に」は、判断基準が書かれていない証拠です。何を根拠に、どのルールで判断するかを書くことで、実装と検証が可能になります。AIを使う場合も、判断の根拠となるデータと、判断できない場合の扱いを書く点は同じです。

書き換え例5：入力・処理・出力を分けて書く

• 悪い例：月次レポートを作成する機能
• 良い例：入力：対象年月、対象部門（複数選択可）。処理：対象期間の問い合わせ件数を分類別・担当者別に集計し、平均回答時間を算出する。出力：集計結果を画面に表示し、PDFとCSVで出力できる。出力は毎月1日にバッチで自動生成し、管理者に通知する

非機能要件と業務要件の悪い例から良い例への書き換え

非機能要件と業務要件は、機能要件以上に曖昧になりやすい領域です。ここでは、代表的な悪い例と良い例を示します。

性能要件の書き換え

• 悪い例：レスポンスが速いこと
• 良い例：通常時（同時利用者20名）の画面表示は2秒以内、ピーク時（同時利用者100名、月末の3営業日）でも3秒以内とする。検索処理は対象データ10万件で3秒以内。測定は本番相当の環境で、代表的な10画面について行う

可用性の書き換え

• 悪い例：安定して稼働すること
• 良い例：稼働時間は平日7時〜22時および土曜9時〜18時。計画停止は月1回まで、日曜深夜0時〜4時に実施し、3営業日前に利用者へ通知する。年間稼働率は稼働時間ベースで99.5％以上。障害発生時は4時間以内に復旧する。日次でフルバックアップを取得し、30日分を保持する

セキュリティ要件の書き換え

• 悪い例：セキュリティに配慮すること
• 良い例：ログインはIDとパスワードに加えて多要素認証を必須とする。パスワードは8文字以上で英数字記号を含み、90日ごとに変更を求める。権限は「一般」「管理者」「閲覧のみ」の3区分とし、画面と操作ごとに設定する。操作ログ（操作者・日時・操作内容・対象データ）を1年間保存する。通信はすべて暗号化する。個人情報は保存時に暗号化し、外部サービスへ送信する場合は氏名・連絡先を除去する

運用・保守要件の書き換え

• 悪い例：運用しやすいこと
• 良い例：管理者が画面から、利用者の追加・削除、権限の変更、マスタデータの更新、通知メールの文面変更を行える。サーバーの稼働状況とバッチの実行結果を監視し、異常時は情報システム部門へメールで通知する。障害時の連絡先と対応時間（平日9時〜18時）を運用手順書に定める。運用開始後1年間は開発会社が保守を行い、月次で稼働状況を報告する

業務要件の書き換え

• 悪い例：業務を効率化する
• 良い例：現状：受注入力は営業事務3名が、電話・FAX・メールで受けた注文を基幹システムに手入力しており、1件あたり平均8分、月間2,000件で約270時間を要している。課題：転記ミスが月10件程度発生し、納期遅延の原因になっている。導入後：顧客がWeb注文画面から直接注文を登録し、営業事務は内容確認と承認のみを行う。達成する状態：受注入力の工数を月100時間以下に削減し、転記ミスをゼロにする。効果測定は導入3か月後に月間の入力時間と誤入力件数で行う

業務要件は、現状・課題・導入後・達成する状態・測定方法をセットで書くことで、システムの目的が明確になり、機能要件の優先順位を判断する基準になります。

これらの要件を1つのプロジェクトとして通しで記述した例は、要件定義書のサンプル・記入例の記事で紹介しています。

【無料相談のご案内】 「自社の要件がこの水準で書けているか確認してほしい」「AIを含むシステムの要件をどう定めるべきか」といった具体的なご相談は、無料の相談予約からお気軽にお問い合わせください。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

自社の要件を点検するチェックの観点

例を参考に要件を書いたら、次の観点で点検します。1つでも該当する要件があれば、書き換えの対象です。

表現のチェック

• 「使いやすい」「速い」「安全な」「適切に」「自動で」「柔軟に」「十分な」など、人によって解釈が変わる言葉が含まれていないか
• 「など」「等」で内容が省略されていないか（省略された部分が対象かどうかで争いになる）
• 「できるようにする」で終わり、条件や制約が書かれていないか

構造のチェック

• 1つの要件に複数の機能や条件が混ざっていないか
• 要件IDと優先度が付いているか
• どの業務課題や目的に対応する要件か、根拠が示されているか
• 対象外の範囲が明記されているか

検証可能性のチェック

• その要件から、テストケース（入力と期待する結果）を作れるか
• 非機能要件に数値・条件・測定方法が書かれているか
• 例外時・エラー時の動作が書かれているか
• AIを含む場合、精度の目標と測定方法、誤った場合の対応が書かれているか

「この要件を読んだ第三者が、テストケースを作れるか」を最終確認の基準にすると、曖昧な要件を見つけやすくなります。

要件定義の例を使う際の注意点

例は書き方の水準を学ぶために有効ですが、使い方を誤ると自社に合わない要件が紛れ込みます。ここでは、例を活用する際に注意したい3つのポイントを解説します。

数値や条件をそのまま流用しない

例に示した応答時間や稼働率、保持期間などの数値は、あくまで説明のためのものです。自社の業務への影響、利用者数、データ量、予算から、自社に必要な水準を決めてください。「なぜその数値なのか」を説明できる要件が、自社の要件です。

例にない要件こそ自社で考える

例は代表的な観点を示すものであり、自社の業務特有の例外や、業界の規制、既存システムとの関係は含まれていません。例を埋めて満足するのではなく、現場へのヒアリングから自社特有の要件を見つけることが、要件定義の本質です。

書き方の水準は保ちつつ、分量は規模に合わせる

良い例の水準ですべての要件を書くと、大規模なシステムでは分量が膨大になります。優先度の高い要件、判断が分かれやすい要件、業務への影響が大きい要件から重点的に具体化し、そのほかは一覧と概要にとどめる、といった配分が現実的です。具体性の水準は落とさず、書く深さを要件の重要度で調整することがポイントです。社内に要件を点検できる人がいない場合は、要件定義の段階から発注側に立って伴走してくれる会社に相談するのも一つの方法です。

システム開発やAI活用の進め方については、NextScaleのコラム一覧でも関連記事を公開しています。

【無料相談のご案内】 要件定義書の作成や点検に不安がある方、AIを組み込んだシステム開発を検討している方は、以下から無料の相談予約をご利用ください。自社の課題整理から要件定義、開発・運用までを一貫してご支援します。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

まとめ

良い要件とは、一意に解釈でき、検証でき、必要性が説明でき、実現可能性が確認され、粒度が揃っている要件です。本記事では、受発注管理・予約管理・EC・在庫管理・勤怠管理・AIチャットボット・SaaS導入の7種類について要件の例を示し、機能要件・非機能要件・業務要件の悪い例を良い例に書き換える具体例を紹介しました。

書き換えの共通点は、主観的な表現を条件と数値に置き換える、1要件1内容に分けてIDを付ける、例外時とエラー時の動作を書く、「自動で」「適切に」の判断基準を書く、入力・処理・出力を分けることです。非機能要件は項目・水準・測定方法を、業務要件は現状・課題・導入後・達成する状態・測定方法をセットで書きます。

例の数値や条件をそのまま流用せず、自社の業務から必要な水準を決め、例にない自社特有の要件をヒアリングで見つけてください。「この要件からテストケースを作れるか」を点検の基準にして、設計・開発・検収の土台になる要件定義書を仕上げていきましょう。