機能要件とは？非機能要件との違い・決め方4ステップと書き方

機能要件とは、業務を実現するためにシステムが「何をできるべきか」を定めた条件です。

会員登録、検索、予約、決済、帳票出力など、利用者や管理者がシステムを使って達成することを具体化します。ただし、機能だけを並べても、使われるシステムにはなりません。業務の目的、利用者の行動、性能や安全性までつなげて定義する必要があります。

この記事では、機能要件の定義、業務要件・非機能要件との違い、決め方と書き方を整理します。後半では、病院予約サービスの事例、AI時代の要件定義、ARCの取り組みまで紹介します。

① 機能要件とは

機能要件の基本をすでにご存じの方は、② 機能要件を現場の事例に置き換えるから読み進められます。

機能要件（Functional Requirement）とは、業務の実現に向けて情報システムが提供すべき機能に関する要件です。「会員がログインできる」「注文データをCSVで出力できる」のように、システムが実行する処理を定めます。

一次出典では入力・処理・出力で定義される

地方公共団体情報システム機構の調査研究資料では、機能要件を「どのような情報を入力し、どのような処理を行い、結果どのような出力がされるか」と説明しています。入力・処理・出力を一続きで書くと、単なる機能名よりも完成条件が明確になります。

業務要件・機能要件・非機能要件の違い

3つは、目的から実装へ向かう階層で整理できます。

種類	答える問い	病院予約サービスの例
業務要件	業務をどう変え、何を達成するか	電話予約を減らし、患者が診療時間外にも予約できるようにする
機能要件	システムは何をするか	診療科や日時で検索し、空き枠を予約できる
非機能要件	どの水準で動くか	検索結果を2秒以内に返し、個人情報を暗号化する

業務要件を決めずに機能を選ぶと、作ること自体が目的になります。反対に、機能要件がなければ業務目標を実装へ渡せません。非機能要件がなければ、動いても遅い、止まる、安全でないといった問題が残ります。

デジタル庁が示す機能要件の5分類

デジタル庁の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」は、機能要件として定義する領域を、機能、画面、帳票、情報・データ、外部インタフェースの5つに整理しています。

分類	定義する内容	例
機能	業務を実行する処理	予約、変更、キャンセル、通知
画面	表示・入力・操作	病院検索画面、予約確認画面
帳票	出力する書類や報告	予約一覧、月次集計
情報・データ	保持する情報と構造	患者、病院、診療枠、予約履歴
外部インタフェース	他システムとの接続	電子カルテ、メール配信、決済サービス

すべてのシステムに5領域が必要とは限りません。画面を持たない一括処理や、外部連携のないウェブサイトもあります。対象外とする領域も理由とともに記録すると、単なる検討漏れと区別できます。

機能要件は受入テストと検収の合否基準になる

機能要件は設計資料であると同時に、納品物を受け入れる基準です。「予約を変更できる」という要件があるのに変更できなければ、受入テストは不合格になります。必須機能が未実装なら、画面が整っていても業務目的を達成できません。

公共調達では契約後の仕様変更に制約が生じる場合があります。発注前に機能と合否条件を対応させ、要件番号ごとにテスト結果を追えるようにしておくと、検収時の解釈争いを減らせます。

要件定義から設計・製造・検査へ進む位置づけ

一般的な開発工程は、要件定義、設計、製造、検査の順に進みます。機能要件は要件定義で決め、設計で画面・データ・処理へ分解し、製造で実装し、検査で満たしたか確かめます。

後工程ほど変更の影響範囲は広がります。要件定義で入力、例外、権限、完了条件まで確認しておけば、設計後に業務そのものを問い直す手戻りを抑えられます。

非機能要求と非機能要件を区別する

非機能要求は「止まってほしくない」「快適に使いたい」といった期待です。非機能要件は、その期待を検証可能な条件へ翻訳したものです。たとえば「快適に」を「通常時の検索応答は95パーセンタイルで2秒以内」と定義します。

要求の言葉をそのまま仕様にせず、対象、測定条件、目標値、検証方法を加えるのが改善点です。期待を残しながら数値へ変換すると、数値だけが独り歩きするのも防げます。

機能要件は当たり前品質、非機能要件は満足度を左右する

予約サービスで「予約できる」ことは、利用者が当然期待する品質です。欠ければ強い不満になります。一方、速さ、分かりやすさ、止まりにくさは、利用の継続や満足度を大きく左右します。

ただし、機能要件を満たせば満足度が上がらない、非機能要件だけが魅力になる、と固定的に考えるのは危険です。新しい機能が魅力になる場合もあります。改善では、欠けると利用不能になる条件と、選ばれる理由になる条件を分けて評価します。

機能要件と非機能要件は文型を変えて書く

機能要件は「システムは、利用者が予約を変更できるようにする」のように、実行する動作を書きます。非機能要件は「予約変更画面は、通常時に2秒以内で表示される」のように、状態や品質水準を書きます。

主語を省かず、機能要件では動詞、非機能要件では測れる状態を中心にすると、両者が混ざりにくくなります。「使いやすい検索を提供する」は、検索機能と使いやすさの評価条件へ分けます。

機能要件を確定してから非機能要件を対応づける

非機能要件は、対象となる機能が見えなければ測定条件を置きにくいため、まず主要な機能要件を整理し、その後に性能や可用性を対応づけます。検索機能が決まってから、応答時間、同時利用者数、障害時の扱いを決める流れです。

一方、非機能要件を工程の最後まで放置してはいけません。性能や安全性は構成そのものを変えるため、主要機能を洗い出した直後に並行して検討します。

IPAの非機能要求グレードは6大項目・238メトリクス

独立行政法人情報処理推進機構（IPA）の「非機能要求グレード2018」は、システム基盤に関する非機能要求を6大項目、34中項目、116小項目、238メトリクスに体系化した資料です。発注者と開発者が要求水準を段階的に確認するために使います。

6大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーです。IPAの公開資料には利用ガイド、グレード表、項目一覧、活用シートがあり、公式サイトから取得できます。改善では、238項目をすべて最高水準にせず、事業への影響が大きい項目から決めます。

3つのモデルシステムと可用性レベルを選ぶ

非機能要求グレードでは、社会的影響がほとんどない、限定される、極めて大きい、という3つの典型的なモデルシステムから近いものを選び、推奨水準を出発点にします。各メトリクスには最大でレベル0〜5の段階があります。

可用性の運用時間も、定時内だけ使う水準から24時間無停止を求める水準まで段階化できます。数字が大きいほど常に正解なのではなく、停止時の業務影響と投資額を比べて選ぶための尺度です。

非機能要件6カテゴリを実現方法まで決める

カテゴリ	要件例	実現・検証の例
可用性	ECは原則24時間、社内基幹業務は平日9〜17時	冗長化、ホットスタンバイ、復旧訓練
性能・拡張性	データ増加後も検索2秒以内	負荷試験、容量監視、増強条件の設定
運用・保守性	障害を検知し担当者へ通知	監視、ログ、手順書、バックアップ
移行性	既存データを欠損なく移す	移行リハーサル、照合、切戻し計画
セキュリティ	権限外の患者情報を閲覧できない	認証、暗号化、脆弱性診断、監査ログ
システム環境・エコロジー	設置環境と省電力条件を満たす	温湿度管理、消費電力測定、適合確認

リリース時だけ速くても、データが増えた3か月後に遅くなれば要件不足です。将来のデータ量、責任者、増強を判断する値まで決めると、運用後の責任の所在が明確になります。

ISO/IEC 25010で製品品質を分類する

国際標準化機構と国際電気標準会議によるISO/IEC 25010:2023は、情報通信技術製品とソフトウェア製品の品質モデルを定める現行の国際規格です。製品品質を9つの特性とその副特性で整理し、要件、測定、評価、受入基準に利用できます。

IPAの非機能要求グレードは国内の受発注で水準を合意する実用的な道具、ISO/IEC 25010は製品品質を共通語で整理する国際的なモデルとして使い分けます。旧版のISO/IEC 25010:2011ではなく、現行版を参照することが改善点です。

セキュリティ要件には適用法令を含める

英国では、Product Security and Telecommunications Infrastructure Act 2022（PSTI法）と関連規則による消費者向け接続製品のセキュリティ制度が2024年4月29日に発効しました。欧州連合のRegulation (EU) 2024/2847、通称Cyber Resilience Act（サイバーレジリエンス法）は2024年12月10日に発効し、主要義務は2027年12月11日から適用されます。一部の報告義務はそれより早く始まります。

接続機器やソフトウェアを海外へ提供する場合、認証、脆弱性対応、更新期間、報告手順を非機能要件と運用要件へ落とします。法令名だけを要件書に置かず、対象製品、適用地域、開始日、担当者を確認します。

SLAは契約、SLOは運用目標として分ける

SLAはService Level Agreement、つまりサービス水準合意です。稼働率や応答時間などを契約条件にし、未達時の減額やサービスクレジットなどを定める場合があります。SLOはService Level Objective、つまりサービス水準目標で、運用チームが目指す内部目標としても使われます。

同じ数値でも契約上の義務か内部目標かで扱いが異なります。測定期間、除外する計画停止、測定元、未達時の対応まで書くと、判定可能な合意になります。

機能要件とアーキテクチャを対応させる

機能要件は、画面、処理、データの構成を扱うアプリケーションアーキテクチャを主に動かします。非機能要件は、サーバー構成、ネットワーク、冗長化、監視などの技術アーキテクチャを主に動かします。

ただし両者は独立しません。大量検索という機能と2秒以内という性能を同時に満たすには、データ設計と基盤設計の両方が必要です。要件ごとに影響する設計領域を記すと、担当間の抜けを減らせます。

パッケージ導入ではFit & Gap分析を行う

Fit & Gap分析（適合・差分分析）は、自社の機能要件とパッケージの標準機能を照合する方法です。標準で満たすFit、設定変更で満たす項目、追加開発が必要なGap、業務を変えて吸収する項目に分けます。

差分を見つけたら、すぐ追加開発を選ばないことが改善点です。標準機能へ業務を合わせる、外部サービスで補う、要件自体を削る選択肢を費用・更新性・統制の観点で比較します。

背景・目的・ゴールを最初に明確にする

機能を考える前に「なぜ作るのか」を一文にします。ECなら「利用者が商品を比較し、迷わず購入を完了できる」、病院予約なら「患者が診療時間外でも空き枠を確保できる」といった業務上のゴールです。

ゴールには対象者と達成状態を含めます。「予約システムを作る」は制作物であり、ゴールではありません。各機能がゴールへどう寄与するかを確認すれば、要望の足し算を抑えられます。

ユースケースとユーザーストーリーで要求を整理する

ユースケースは、利用者とシステムのやり取りを、開始条件から完了・例外まで記述する方法です。ユーザーストーリーは「患者として、空いている病院を日時で探したい。そうすることで、電話せず予約したい」のように、利用者、行動、価値を短く表します。

実用最小限の製品（MVP）を決めるときは、ユーザーストーリーを価値のまとまりとして優先づけます。画面単位ではなく、利用者が目的を完了できる一連の流れを初回範囲にします。

ユーザーの操作フローから機能を洗い出す

「誰が、どんな場面で、何をするか」を時系列で書きます。病院予約なら、認知、検索、比較、予約、受診前の通知、変更、再利用までを追います。正常な流れだけでなく、空きがない、入力を誤る、通信が切れる場合も加えます。

改善では、利用者だけでなく、病院の受付担当者や運用管理者の流れも別の行に置きます。利用者側では見えない枠管理や問い合わせ対応が、必要機能として現れます。

必要な機能を一覧化する

操作フローの各場面から機能を抽出し、同じ粒度で一覧にします。「予約管理」と「予約変更ボタン」が混在すると比較できないため、まず業務機能のまとまりで揃え、下位に詳細を置きます。

各機能には利用者、目的、入力、出力、関連データを付けます。似た機能を統合し、どのフローにも結びつかない機能は必要性を問い直します。

機能ごとの詳細要件と技術的制約を書く

「検索できる」で止めず、検索条件、最大件数、並び順、該当なしの表示、権限、例外時の挙動まで定義します。外部サービス、データベース、暗号化方式、対応端末など、選択済みで変更できない技術的制約も記載します。

ただし、実現方法を早く固定しすぎると代替案を狭めます。「メールを送る」という要件と「特定の配信サービスを使う」という制約を分け、制約には理由と決定者を添えます。

優先度と開発段階を決める

全機能を初回リリースへ入れると、期間と費用が膨らみます。「ないと業務が成立しない」「あると効率が上がる」「将来あればよい」に分け、MVPと後続段階へ割り当てます。

すべてが必須とされたら、その機能がないと止まる具体的な業務を尋ねます。依存関係、法令、データ移行も考慮し、価値が高くても前提機能が必要なら実装順を調整します。

予算超過時は削減案と代替運用をセットで出す

予算を超えたとき、値引き交渉だけに頼ると品質や体制へしわ寄せが出ます。利用頻度の低い画面や帳票を表計算ソフトやメールで代替する、便利機能を後続へ回す、簡易版で提供するといった選択肢を用意します。

各案には削減額だけでなく、手作業の時間、誤りのリスク、将来の作り直しを添えます。削る範囲を発注者が選べるようにすると、価格だけの交渉から優先順位の判断へ変えられます。

要件の理由を記録して代替案を作れるようにする

「稼働時間は6時から22時」と聞いたら、なぜその時間なのかを確認します。始発勤務と残業対応が理由なら、例外時だけ延長する運用など別の案を検討できます。理由がなければ、後から出た思いつきと業務上の制約を区別できません。

要件書には要望者の言葉だけでなく、背景、判断根拠、影響する業務を残します。理由が変わったときに、要件を安全に見直せるようになります。

非機能要件は水準とコストを松・竹・梅で比べる

24時間無停止、即時復旧、最大負荷への常時対応は、冗長構成、監視、当番体制を増やします。高い水準ほどよいのではなく、停止損失と実現費用の均衡が必要です。

たとえば松を24時間運用と短時間復旧、竹を営業時間外の計画停止あり、梅を平日日中のみとし、費用と業務影響を並べます。段階案を示すと、形容詞ではなく投資判断として合意できます。

一意の番号・名称・根拠で追跡可能にする

各要件に「FR-予約-001」のような一意の番号、短い名称、本文、根拠（rationale）を付けます。業務要件、設計、実装課題、テストケースとの対応も記録します。

この追跡可能性があれば、変更時に影響範囲を検索できます。未確定事項は消さず、仮置き要件として期限、決定者、未確定理由を記し、確定済みと混同しないようにします。

レビューと変更管理を反復する

要件は一度で完成しません。操作試作、設計、開発、テストで得た情報を反映し、変更履歴を残します。変更内容、理由、影響、承認者、適用版を記録し、口頭合意だけで進めないようにします。

定例レビューでは、新しい要望だけでなく、古くなった前提と不要になった要件も確認します。追加するたびに費用・納期・品質のどれを調整するかを同時に決めます。

運用テストで日常業務まで検証する

運用テストは、監視で異常を検知できるか、ログから原因を追えるか、バックアップから復元できるか、担当交代でも手順を実行できるかを確かめます。利用者向け画面が動くだけでは、運用可能とはいえません。

本番に近い権限とデータ量で、障害連絡、復旧、切戻しまで通します。テスト後は、見つかった手作業や判断の曖昧さを運用要件と手順書へ戻します。

第三者・専門家のレビューを入れる

発注側と開発側が合意していても、共通の思い込みは残ります。セキュリティ、性能、アクセシビリティ、法務などの専門家や、実装に直接関わらない第三者が要件を確認すると、見落としを発見しやすくなります。

レビュー依頼では「全体を見てください」ではなく、個人情報の流れ、最大負荷、障害復旧、受入条件など観点を指定します。指摘の採否と理由も記録し、レビューを形式的な承認にしないことが改善点です。

② 機能要件を現場の事例に置き換える

病院を検索し、空き枠を予約できるサービスを題材にします。目的は、患者が診療時間外でも自分に合う病院を探し、予約を完了できることです。

人間中心設計で体験全体を見る

人間中心設計（Human-Centred Design、HCD）は、利用状況を理解し、利用者と組織の要求を明らかにし、解決策を作り、評価する反復的な設計方法です。画面だけでなく、利用前から利用後までの体験を対象にします。

体験の時間軸から行動を洗い出す

体験は、利用前に期待を持つ予期的UX、利用中の一時的UX、利用後に振り返るエピソード的UX、複数回の経験が積み重なる累積的UXとして捉えられます。

病院予約なら、記事でサービスを知る、条件で病院を検索する、口コミを比較する、お気に入りへ保存する、予約する、履歴から再予約する、ポイントや通知で継続利用する、という行動が並びます。改善では、予約完了だけで終わらず、受診後と再利用まで範囲を広げます。

縦の流れと横の選択肢から機能を抽出する

縦の流れでは、病院一覧、検索、検索結果、詳細、予約という前後関係を並べます。横の選択肢では、地域、診療科、症状、日時など、各行動の方法を広げます。

行動と機能を対応づけると、利用者が何のために使う機能かを説明できます。

表に見える機能と裏側の機能を分ける

検索、比較、予約は利用者から見える機能です。認証、エラー処理、監査ログ、通知の再送、データ同期は裏側で必要になります。見える画面だけから洗い出すと、障害時や運用時の機能が抜けます。

機能の役割も、画面を移る、状態を変える、情報を表示する、に分けて確認できます。電卓なら計算は状態を変え、計算結果は情報を表示します。更新ボタンは画面が同じでも、内部の状態を更新します。

受入条件まで書いて事例を完成させる

「患者は日時と診療科で病院を検索できる」だけでは、完成を判定できません。検索条件が未入力の場合、該当がない場合、同じ時刻に別の患者が予約した場合まで定義します。

たとえば受入条件を「検索結果には予約可能な枠だけを表示する」「予約確定後に患者と病院へ通知する」「二重予約を防止する」と書きます。操作の成功だけでなく、競合や失敗から回復できることまで含めると、現場で使える要件になります。

③ この先——AI時代の要件定義

生成AIは、議事録から候補要件を抽出し、ユーザーストーリーやテスト条件の草案を作れます。既存資料の表現揺れを探し、要件番号とテストの対応漏れを示す用途にも向きます。

一方、AIが整った文章を出しても、その要件が必要だとは限りません。誰の発言か、事実か仮説か、法令や契約に適合するか、費用に見合うかは、人が根拠を確認して決めます。

AIそのものの振る舞いを要件にする

AI機能では、同じ入力でも出力が変わり得ます。そのため「正しい回答をする」ではなく、対象業務、許容する誤り、参照情報、禁止事項、人への引継ぎ条件、記録、評価用データを定義します。

改善の中心は、AIの出力だけでなく、人が確認して訂正できる経路を要件に含めることです。自動化率を上げるより、誤りが業務事故へ進まない境界を先に設計します。

要件書を固定文書から検証可能な資産へ変える

要件、画面試作、評価データ、テスト、運用監視を同じ識別子で結ぶと、変更の影響を機械的に確認しやすくなります。AIは差分の候補を示せますが、変更を承認する責任は残ります。

これからの要件定義では、完成した文書の厚さより、根拠が追え、検証でき、変更時に更新されることが重要です。未確定事項を隠さず、検証待ちの仮説として管理します。

④ ARCの事例——体験からAIプロダクトの要件をつくる

ARCでは、事業の目的から利用者の行動を描き、表に見える機能、裏側の処理、AIの判断境界、運用時の確認経路までを一続きで設計します。

画面案から機能を逆算するだけでは、AIが回答できないときの引継ぎや、誤りを訂正する管理機能が後回しになります。先に利用場面と失敗時の影響を置き、最小の体験を成立させる機能から試作します。その結果を要件へ戻し、精度だけでなく業務完了率や確認負荷も見直します。

構想、体験設計、試作、実装、評価をつなげたい場合は、AIプロダクト開発で支援内容を確認できます。

⑤ 一緒に覚えたい概念

• 業務要件： システム導入後の業務、対象範囲、達成状態を定める上位の要件
• 非機能要件： 性能、可用性、運用、移行、セキュリティなど、機能の品質水準を定める要件
• ユースケース： 利用者とシステムのやり取りを、開始から完了・例外まで記述する方法
• ユーザーストーリー： 利用者、したいこと、得たい価値を短い文で表す方法
• MVP： 中心となる価値を検証できる最小限の製品
• 受入テスト： 納品物が業務要件・機能要件を満たすか、利用者側の観点で確認するテスト
• Fit & Gap分析： 業務・機能要件とパッケージ標準機能の適合と差分を調べる方法
• トレーサビリティ： 要件の根拠から設計、実装、テストまで追跡できる状態
• 人間中心設計： 利用状況と利用者の要求を基に、設計と評価を反復する考え方

よくある質問

機能要件とは何ですか？

業務の実現に向けて、情報システムが何をするかを定めた条件です。入力、処理、出力、利用者、例外、完了条件まで具体化します。

機能要件と業務要件の違いは何ですか？

業務要件は、業務をどう変え、何を達成するかを定めます。機能要件は、その業務要件を実現するためにシステムが提供する処理を定めます。

機能要件と非機能要件の違いは何ですか？

機能要件が「何をするか」を定めるのに対し、非機能要件は性能、可用性、セキュリティなど「どの水準で行うか」を定めます。

機能要件はどうやって決めますか？

背景・目的を明確にし、利用者の操作フローを描き、必要機能を一覧化し、詳細と例外を定義し、優先度と開発段階を決めます。その後、レビューと変更管理を反復します。

非機能要求グレードとは何ですか？

IPAが公開する、発注者と開発者が非機能要求の水準を合意するための資料群です。6大項目、34中項目、116小項目、238メトリクスで構成されます。

機能要件を書くときの注意点はありますか？

主語と動作を明確にし、入力・出力・例外・受入条件を書きます。一意の番号、要件の理由、関連する業務要件とテストも記録すると変更に強くなります。

機能要件が曖昧なまま発注するとどうなりますか？

見積もりの前提と検収基準が揃わず、提案比較が難しくなります。開発後半で業務に合わないと判明し、追加費用や納期遅延につながる可能性があります。

AIで機能要件書を作れますか？

候補抽出、表現の統一、ユーザーストーリーやテスト条件の草案作成には使えます。ただし、必要性、法令適合、費用、受入可否の判断と承認は、根拠を持つ担当者が行う必要があります。