機能要件をめぐる認識のずれは、たいてい「どこまでが機能要件か」の線引きが共有されていないことから起きます。画面のイメージは機能要件なのか、バッチの処理時間はどちらに書くのか、SaaSを使うなら機能要件は不要なのか。この記事では、デジタル庁が政府情報システムの整備・管理に関する共通ルールとして定めたデジタル社会推進標準ガイドラインDS-100（2026年6月12日デジタル社会推進会議幹事会決定）と、要求の書き方を規定した日本産業規格JIS X 0166という2つの一次情報に沿って、機能要件の範囲・書き方・合意形成の手順を整理します。要件定義そのものの進め方は要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説にまとめています。
まとめ
機能要件とは、業務要件を実現するために情報システムが備える機能を定めた要件です。デジタル庁のDS-100は、機能要件を「機能」「画面」「帳票」「データ」「外部インタフェース」の5つの事項で定義すると規定しています。画面や帳票は機能要件に含まれ、応答時間やバッチ処理時間は非機能要件の「性能に関する事項」に分類されます。
書き方の指針はJIS X 0166にあります。外せない条件は2つ。1つの文に1つの要求だけを書くこと、そして満たしたかどうかを検証できる形で書くことです。「使いやすい画面」は要求文になりません。合意形成の段階では、必要性・網羅性・具体性・定量性・整合性・中立性・役割分担の明確性という7つの観点で内容を確認し、決まっていない要件は空欄にせずリスクとして明記します。以下、各項目の判断基準を原文の記述にあたりながら見ていきます。
業務要件から機能要件・非機能要件へ分岐する順序と判断基準
3つの要件は並列ではありません。DS-100は、業務要件を先に固め、それを実現するために情報システムへ求める要件を「情報システム要件」と呼び、そこから機能要件と非機能要件に分けるという順序を定めています。機能要件は「情報システムの機能を定めた要件」、非機能要件は「情報システムが備えるべき機能要件以外の情報システム要件」という定義です。
工程としての位置も決まっています。DS-100の第3編（ITマネジメント）では、第4章「サービス・業務企画」で業務要件を検討し、第5章「要件定義」で機能要件・非機能要件を定義し、第6章の調達を経て第7章「設計・開発」へ進みます。機能要件をどこまで書くかで迷ったときは、この前後の工程のどちらの担当かで切り分けると判断がぶれません。
業務要件を起点にした分岐と、機能要件が担う範囲
業務要件は、システムを使ってどのような業務を行うかを定義します。DS-100では業務要件の検討は要件定義の前工程（第3編第4章「サービス・業務企画」）に置かれ、要件定義ではその内容と他の要件との整合性を確認して更新する扱いです。つまり業務要件が固まらないまま機能要件を書き始める進め方は、ガイドラインの想定から外れています。業務要件そのものに何をどの粒度で書くのかは、業務要件定義の8つの記載項目と定義書の作り方で整理しています。
非機能要件の定義は「機能要件以外」という消去法で与えられています。この定義が実務で効くのは、迷った項目をどちらかに寄せる判断が「機能要件の5事項に当てはまるか」だけで済むからです。当てはまらなければ非機能要件へ回します。非機能要件そのものの整理には、IPAが公開する非機能要求グレードが使えます。詳細は【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説するを参照してください。
帰属に迷う項目の判断：バッチ処理・応答時間・データマネジメント
機能要件と非機能要件の線引きでつまずきやすいのが、バッチ処理です。丸ごと機能要件として書いてしまう例が目立ちます。DS-100の非機能要件は「d) 性能に関する事項」で「応答時間、バッチ処理時間等を記載する」と定めています。バッチが何を処理するかは機能要件の「機能に関する事項」ですが、何分以内に終わらせるかは非機能要件です。この2つを1か所に混ぜて書くと、性能の合意が抜け落ちたまま調達に進むことになります。
バッチの実行方式や処理単位そのものの詳細化は、要件定義ではなく設計工程の仕事です。DS-100は設計・開発の章で、機能要件を具体化・詳細化した「画面、帳票、データ、外部インタフェース、バッチ等に関する設計」を事業者に求めると規定しています。要件定義でバッチの内部処理を書き込むほど、事業者の提案余地を先に潰すことになります。
データの扱いも分岐します。どのようなデータを持ち、どう入出力するかは機能要件の「データに関する事項」です。一方、データの品質をどう維持するかは非機能要件側の項目です。2026年6月12日決定の現行版では非機能要件が a)〜r) の18事項に整理され、「l) データマネジメントに関する事項」が並んでいます。この項目が入ったのは2025年5月27日の改定で、改定履歴にも「非機能要件定義に『l) データマネジメントに関する事項』を追加」と明記されています。それ以前の2023年3月31日改定版では a)〜q) の17事項でした。2024年以前の資料をもとにチェックリストを作っていると、この1項目が抜けます。
機能要件として定義する5つの事項
DS-100は、機能要件を次の5つの事項をもって定義すると規定しています。ここでいう「事項」は章立ての単位です。なお、該当しない事項をどう扱うかにDS-100の明文はありません。実務では、省くこと自体より「検討した結果、該当なし」と書き残すかどうかで後の説明のしやすさが変わります。
| 事項 | 記載する内容 |
|---|---|
| a) 機能 | 処理内容、入出力情報・方法、入力と出力の関係 |
| b) 画面 | 画面の概要、表示イメージ、画面遷移、入出力の考え方 |
| c) 帳票 | 帳票の概要、表示イメージ、入出力の考え方 |
| d) データ | データモデル、データ定義、利活用方法、オープンデータの範囲と方法、項目の標準化 |
| e) 外部インタフェース | 相手先システム、送受信データ名、タイミング、条件 |
「画面要件は機能要件に含まれるのか」という問いへの答えは、この一覧のb)にあります。画面は独立した要件区分ではなく、機能要件の一部です。
機能・画面・帳票：設計工程との境界と帳票最小化の方針
機能に関する事項では、処理内容と入出力の関係を書きます。DS-100は続けて、他の情報システムが類似の機能を持つ場合はその機能を活用することも検討するよう求めています。同じ機能を作り直さないという判断を、要件定義の段階で行う前提です。
画面に関する事項で書くのは、画面の概要や表示イメージ、画面の遷移や入出力の基本的な考え方です。逆にいえば、項目レベルの詳細な画面仕様はここでは書きません。それは第7章「設計・開発」で、機能要件を具体化・詳細化した設計として事業者が担う範囲だからです。もう一点、分岐を間違えやすいのが画面の使い勝手そのもの。ユーザビリティやアクセシビリティは機能要件のb)ではなく、非機能要件のa)へ回ります。画面の話だからと一括りにすると、アクセシビリティの要件が要件定義書から抜け落ちます。
帳票については、DS-100が踏み込んだ書き方をしています。「業務のデジタル化を前提に、帳票は最小限にすることが望ましい」という一文です。現行の紙帳票をそのまま一覧化して機能要件に積み上げる進め方は、この方針と正面から衝突します。既存帳票の棚卸しをするなら、残す理由を帳票ごとに説明できる状態にしてから要件へ載せてください。
データ・外部インタフェース：標準化とオープンAPIを前提にした記載
データに関する事項では、データベースや入出力ファイルを含む全データについて、データモデル・データ定義・利活用方法・オープンデータの範囲・データ項目の標準化を記載します。DS-100は、政府において標準化されたデータ名称やデータ構造を原則として採用することに加え、他システムとの連携やオープンデータとしての活用を前提に品質を維持するよう、非機能要件のデータマネジメントの項目も併せて参照するよう求めています。
外部インタフェースは「外部インタフェース一覧」という成果物の形が指定されています。記載するのは相手先の情報システム、送受信データ名、送受信タイミング、送受信の条件です。ここでも方針が明示されており、外部インタフェースは「オープンなＡＰＩとしての活用が行われることも想定して整備する」ことに留意するとされています。特定の1システムとの相対の接続としてだけ設計すると、後から公開APIへ広げる際に作り直しになります。
機能要件の書き方：JIS X 0166が定める要求文の条件
何を書くかがDS-100で決まっても、どう書くかは別の問題です。要求文そのものの品質基準は、JIS X 0166（システム及びソフトウェア技術－ライフサイクルプロセス－要求エンジニアリング）が規定しています。国際規格ISO/IEC/IEEE 29148に対応した規格で、現行版は2021年版（ISO/IEC/IEEE 29148:2018対応）です。ここで注意が要ります。以下に示す箇条番号と特性の一覧は2014年版（29148:2011対応）のもので、2021年版では特性の顔ぶれ自体が入れ替わっています。差分は次の見出しの末尾にまとめました。
一文一要求と検証可能性という2つの外せない条件
JIS X 0166:2014の箇条5.2.5は、個々の要求事項が満たすべき特性として次の9つを挙げています。
- 必要である（削除すると埋め合わせできない欠陥が生じる）
- 実装独立である（「何」を示し「いかに」実装するかを示さない）
- 曖昧性がない（単一の解釈しかできない）
- 一貫性がある（他の要求事項と競合しない）
- 完全である（測定可能で、追加の詳述を必要としない）
- 単独である（接続詞で複数の要求をつながず、一文に一要求）
- 実現可能である（システム制約内に受入れ可能なリスクで収まる）
- 追跡可能である（ニーズの源へ遡り、実装へ辿れる）
- 検証可能である（要求を満たしたと証明する方法が存在する）
9つすべてを毎回点検するのは現実的ではありません。優先順位をつけるなら「単独である」と「検証可能である」の2つです。「顧客情報を登録し、登録後に通知メールを送信し、履歴に記録する」という一文は3つの要求を接続詞でつないだもので、どれか1つだけ実装されても文面上は否定できません。分割すれば、テストケースが1対1で対応します。検証可能性も同じで、テスト手順を書けない要求文は、受入れの段階で「満たしている／いない」を争う火種になります。
要求事項の集合に対する条件も箇条5.2.6にあります。集合として完全であるとは、その集合に「決定予定（TBD），供給予定（TBS），又は解決予定（TBR）の箇条を含まない」ことだと明記されています。決まっていない項目を「TBD」と書いたまま合意する運用は、規格上は完全な要求事項集合ではありません。
版の差分も押さえておいてください。2021年版が対応するISO/IEC/IEEE 29148:2018では、個々の要求事項の特性から「実装独立である」「一貫性がある」「追跡可能である」の3つが外れ、代わりに「適切である」「正しい」「適合している」の3つが入りました。上の一覧を現行版の目次と突き合わせても一致しないのはこのためです。ただし本稿が優先順位を置いた「単独である」「検証可能である」は両版に残っているので、要求文の書き方として押さえる要点は変わりません。
使ってはいけない表現と、助動詞による拘束力の書き分け
箇条5.2.7は、要求文で避けるべき表現を具体的に列挙しています。最上級（「最高の」）、主観的語法（「ユーザフレンドリ」「使いやすい」）、曖昧な代名詞（「それ」「これ」）、曖昧な副詞・形容詞（「ほとんどいつも」「相当な」）、検証不可能な用語（「支援する」）、抜け穴表現（「可能ならば」「適宜」）、不完全な参照、否定的表現などです。
「使いやすい検索画面を提供する」は、この基準では要求文になりません。検証方法が存在しないためです。書き換えるなら「検索画面は、指定された検索条件に合致する全件を一覧として出力する」のように、何をもって満たしたと判断するかを文面に含めます。この形なら、条件を与えて出力件数を照合するテストが書けます。なお応答時間の数値そのものは非機能要件側に置きます。
拘束力の表現も規定されています。箇条5.2.4が挙げる拘束力の助動詞は3種類。「〇〇しなければならない」が必須の拘束条項、「〇〇することが望ましい」が望ましい・任意選択の条項、「〇〇してもよい」が許容の条項にあたります。規格は要求事項の識別に「〇〇しなければならない」を用いるよう推奨し、曖昧さをもたらす「〇〇すべきである」は避けるよう注記。さらに、説明文や定義といった要求事項でない記述には、これらを使わず宣言的な表現を用いるとしています。日本語の要件定義書では「〜すること」「〜が望ましい」が混在しがちです。必須と任意が区別できない文書では、見積りの前提が人によって変わってしまいます。
要求文の型を機械的に揃えたい場合は、EARS記法という選択肢があります。トリガーや状態を含む6つの型に当てはめて書く方式で、詳細はEARS記法とは？6つの型と書き方・実例をKiro連携まで解説にまとめています。
機能要件の合意形成で確認する7つの観点
合意形成は会議体の運営の話に流れがちですが、DS-100は確認すべき中身を具体的に示しています。定義した内容について「その必要性、網羅性、具体性、定量性、整合性、中立性及び役割分担の明確性の観点、さらに情報セキュリティ等の観点から、その実現可能性があることを確認する」という規定です。
7観点のうち実務で抜けやすい定量性・中立性・役割分担
7つのうち、必要性と網羅性はレビューで自然に議論されます。抜けやすいのは残りです。定量性は、件数・利用者数・データ量といった数値が要件に書かれているかどうか。中立性は、特定製品でしか実現できない書き方になっていないかどうか。役割分担の明確性は、発注側と受注側のどちらが行う作業なのかが読み取れるかどうかを指します。
中立性は特に、パッケージ選定と同時に要件を書く場面で崩れます。DS-100も、システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれがあるとして、記載の粒度への配慮を求めています。要件定義の段階で製品名に紐づく画面仕様まで書き込むなら、それはもう選定を終えたということです。中立性を装った書き方をするより、方式を先に決めた旨を明示するほうが誠実で、後の説明もつきます。
合意の当事者についても明確な規定があります。機能要件・非機能要件・実現案は「情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めたＰＪＭＯ全体で決定することが不可欠」とされています。情報システム部門が業務部門への確認を省いてまとめた要件定義書は、この時点で条件を満たしていません。
未確定要件の扱い：空欄化を認めないDS-100の規定
すべての要件が要件定義の時点で決まることはありません。DS-100はその前提に立ち、定義の時点で未確定な要件については「プロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにする」と定めています。
この規定の要点は、未確定であること自体は許容される一方、黙って空欄にすることは許容されないという点です。JIS X 0166がTBD・TBS・TBRを含む集合を不完全と扱うのと合わせて考えると、実務上の落としどころは「未確定項目を一覧として別掲し、いつまでに誰が決めるかを添える」形になります。決定期限のない未確定項目は、後の変更要求として必ず戻ってきます。
SaaS・パッケージ前提で機能要件を書くときの範囲
SaaSを使うなら機能要件は書かなくてよい、という誤解があります。DS-100の規定は逆です。「クラウドサービス（SaaS）等が提供する機能を利用する場合には、その利用する機能について記載する」と明記されています。自社で作らない機能であっても、業務で使う以上は要件として書きます。
スクラッチ開発との違いは、粒度です。SaaS前提では、内部処理の詳細ではなく「業務のどの部分を標準機能で賄い、どこを設定で調整し、どこを追加開発するか」の切り分けが機能要件の中心になります。標準機能で足りない部分だけが追加開発の対象になるため、この切り分けが曖昧なまま契約すると、追加開発の範囲が後から膨らみます。
基幹システムの刷新では、この切り分けが会計や人事の制度と直結します。既存の業務手順を変えずに製品を合わせにいくと追加開発が積み上がるため、業務側を製品の標準に寄せる判断を先に済ませておくほうが、機能要件は短く書けます。あわせて、DS-100が機能要件の留意点として挙げる「優先度の高い機能から整備する」「他システムと連携する場合は相互運用性及びデータ互換性を併せて記載する」の2点は、SaaS前提でも変わりません。連携先が増えるぶん、むしろ外部インタフェースの記載量は増えます。
要件定義書における機能要件の記載範囲と後工程との線引き
DS-100では、要件定義書に記載するのは業務要件・機能要件・非機能要件・情報システムの実現案の4つです。機能要件はこのうちの1章にあたり、5つの事項がそのまま節の構成になります。文書全体の章立てや記載項目は要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説で扱っています。
書きすぎの線引きに迷ったら、後工程の分担で判断します。要件定義で決めるのは「何を満たすか」まで、画面の項目レベルの仕様や処理の内部構造は基本設計以降の仕事です。DS-100も、要件は可能な限り詳細に検討したうえで、実現案については事業者の創意と工夫を提案として受けられるよう配慮するという書き分けをしています。要件定義と設計の関係は基本設計とは何か：システム開発の基盤を理解する、要件定義書と設計書・仕様書の役割の違いは仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説で整理しています。
よくある質問
業務要件と機能要件の違いは何ですか？
業務要件は「情報システムを活用した業務の内容」を定義し、機能要件は「情報システムの機能」を定義します。DS-100では業務要件を先に固め、それを実現するために情報システムへ求める要件として機能要件と非機能要件へ分岐させる順序が定められています。たとえば「申請の受付から承認までを2営業日以内に完了する」は業務要件、「申請データを受け付け、承認者へ通知する」は機能要件です。業務要件が決まらないまま機能要件を書き始めると、機能の必要性を説明できなくなります。
画面要件は機能要件に含まれますか？
含まれます。「画面要件」という独立した区分はなく、DS-100が定める機能要件5事項のb)「画面に関する事項」がそれにあたります。ただしアクセシビリティは非機能要件a)へ分かれる点に注意してください。DS-100はここで具体的な手当てまで指定しており、総務省が公開する「情報アクセシビリティ自己評価様式」の書式に基づいて対応状況を記載するよう応札者に求めることとしています。画面を機能要件に書いただけでは、この様式の要求は満たせません。
バッチ処理は機能要件と非機能要件のどちらに書きますか？
処理の中身は機能要件、処理時間の目標は非機能要件d)「性能に関する事項」に分かれます。迷いやすいのは時間の決め方のほうです。DS-100は性能について「業務要件の定義において検討した内容に照らし、性能が過度にならないよう適切な要件とすること」と釘を刺しています。つまり「速いほどよい」で数値を決めるのではなく、その時刻までに業務が何を終えている必要があるかから逆算します。夜間バッチなら翌朝の業務開始時刻が根拠になり、根拠のない「3時間以内」は過剰な調達費として跳ね返ります。
BRDと要件定義書は何が違いますか？
BRD（Business Requirements Document）はビジネス側の目的や達成条件をまとめた文書で、日本の実務では業務要件に相当する範囲を扱います。一方の要件定義書は、DS-100の定義では業務要件・機能要件・非機能要件・実現案の4つを含む文書です。BRDだけで開発に進むと機能要件と非機能要件が欠けるため、BRDを入力として要件定義書を作る流れになります。BRDとFRD（Functional Requirements Document）を分けて運用する場合、後者が機能要件にあたります。
SaaSを利用する場合も機能要件の定義は必要ですか？
必要です。DS-100は、クラウドサービス（SaaS）等が提供する機能を利用する場合には、その利用する機能について記載すると規定しています。実務で効いてくるのは、標準機能で要件を満たせないと判明したときの扱い。選択肢は「業務手順を製品に合わせる」「設定で吸収する」「追加開発する」の3つですが、DS-100は機能要件について優先度の高い機能から整備するよう求めています。すべてを追加開発で埋める前に、その機能が優先度の高いものかを先に判定してください。判定を飛ばした追加開発が、SaaS導入で費用が想定を超える主な経路です。
