業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説

業務要件定義は、システムの機能を決める前に「業務そのものをどう回すか」を確定させる工程です。デジタル庁が定める標準ガイドラインDS-100は、業務要件として定義すべき事項を8区分で示しています。業務実施手順、規模、時期・時間、場所等、管理すべき指標、情報システム化の範囲、業務の継続の方針等、情報セキュリティの8つ。この記事では、8区分それぞれに何をどの粒度で書くのか、業務要件が機能要件・非機能要件の水準をどう縛るのか、業務要件定義書をAs-Is把握からTo-Be確定までどの順で作るのかを整理します。あわせて、稼働率や応答時間を業務要件から逆算する手順と、外部のベンダーに任せてよい範囲・発注側が自分で書かないと崩れる範囲の線引きまで扱います。

まとめ：業務要件定義で発注側が決め切る8項目と外注できない範囲

業務要件定義とは、システムを入れた後の業務がどんな姿になるかを、手順・数量・時間・場所・指標・範囲・継続方針・セキュリティの8側面で確定させる作業を指します。DS-100（2026年6月12日改定版）はこの8区分を業務要件として定義するよう求めており、機能要件と非機能要件は、ここで決めた業務の姿を実現する手段として後から導かれる関係にあります。順序が逆になった要件定義書は、画面数だけが積み上がって業務が回らない、という結果に着地しがちです。

実務でまず押さえるべきは3つ。第一に、規模と時期・時間を数値で確定させること。ここが空欄のままだと、非機能要件の性能・信頼性が根拠なく高止まりし、費用だけが膨らみます。第二に、情報システム化の範囲で「システムを使わずに人が行う業務」まで書き切ること。第三に、既存業務との差異を明示すること。DS-100は既存業務がある場合、定義する業務要件と現行業務の差が明確に把握できるよう留意すべきと定めています。

外注の線引きも先に述べます。ヒアリングの設計、業務フロー図の作図、要件間の整合性検証はベンダーに任せて構いません。一方、業務の目的、管理すべき指標、情報システム化の範囲の3点は発注側が決め切る必要があります。DS-100が「情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めた全体で決定することが不可欠」と書いているのは、この3点を業務の当事者以外が決められないためです。

業務要件定義の範囲と機能要件・非機能要件へ連なる要件3階層の関係

業務要件定義が扱う対象はシステムの機能ではなく業務そのものの姿

業務要件定義が記述するのは、システムの画面や帳票ではありません。誰がどの順で何をするか、月あたり何件処理するか、繁忙期はいつか、どの拠点で行うか、といった業務の実態です。DS-100 第3編第4章5は、業務要件の第1項目を「業務実施手順」とし、業務の実施に必要な体制・手順・それらを記載した業務フロー図、および入出力情報と取扱量、管理対象情報一覧を挙げています。

この段階でシステムの話を持ち込むと、現行システムの制約が業務の前提として固定されてしまいます。受注登録が2画面に分かれているのは業務上の必然か、それとも15年前のパッケージの都合か。業務要件定義は、その区別をつけるための工程です。第6項目「情報システム化の範囲」がシステムを用いる業務範囲と用いない業務範囲の両方を書かせるのも、同じ理由からと読めます。

業務要件が機能要件と非機能要件の水準を上から縛る3階層の関係

DS-100 第3編第5章は、第4章で策定した業務要件を踏まえて、これを実現するための「情報システム要件」として機能要件と非機能要件を明らかにする、という順序を明記しています。要件定義書の記載内容は、ア業務要件・イ機能要件・ウ非機能要件・エ情報システムの実現案の4区分。業務要件は他の3区分の入力データにあたります。

機能要件は a)機能 b)画面 c)帳票 d)データ e)外部インタフェース の5区分、非機能要件は a)からr)までの18区分に分かれます。機能要件と非機能要件それぞれの中身の切り分け方は機能要件と非機能要件の違いと定義する5つの事項で扱っているため、本記事では業務要件パートに絞ります。業務をスマホアプリとして実装する案件では、対応OSや端末権限といった固有の要件も加わるため、アプリ開発の要件定義で決める項目にまとめました。

要求定義や要件定義との呼び分けと工程上で業務要件定義が入る位置

「要求定義」「要件定義」「業務要件定義」は、指す範囲が段階的に異なります。要件定義は業務要件・機能要件・非機能要件の3種をまとめた工程全体を指し、業務要件定義はその最初のパートです。要求定義は要件定義のさらに前段で、発注側が「何を実現したいか」を出す段階を指すことが多く、責任範囲と契約形態の切り替わり方は要求定義と要件定義の違いで整理しています。工程全体の目的と進め方は要件定義とは何かを扱った解説を先に読むと位置関係がつかめます。

国際規格の側では、JIS X 0166:2021（ISO/IEC/IEEE 29148:2018 に一致）が、利害関係者要求仕様（StRS）とシステム要求仕様（SyRS）を別の文書として規定しています。業務要件定義書は前者に近い位置づけです。国内の枠組みでは、IPAが2013年3月に発行した「共通フレーム2013」がISO/IEC 12207:2008（JIS X 0160:2012）を包含する形で工程を整理しており、業務側が定義する層と開発側が定義する層を分けて扱っています。

標準ガイドラインが定める業務要件定義書の記載項目8区分と粒度の目安

DS-100 第3編第4章5が挙げる8区分を、性質ごとに3つのまとまりに分けて見ていきます。

業務実施手順・規模・時期・時間・場所を数量として確定させる4区分

1)業務実施手順、2)規模、3)時期・時間、4)場所等の4つは、業務を数量と時間軸に落とす区分です。規模は「サービスの利用者数及び情報システムの利用者数」と「単位（年、月、日、時間等）当たりの処理件数」の2点。時期・時間は「業務の実施時期、期間及び繁忙期」と「業務の実施・提供時間」を書きます。場所等は実施場所に加え、諸設備や必要な物品等の資源の種類と量まで含みます。

粒度の目安は、後工程で見積もりの根拠になるかどうか。「受注件数は多い」では見積もれません。「通常月2,400件、決算期の3月と9月は月4,000件、ピーク日は1日400件」まで書けば、機能要件のバッチ設計と非機能要件の性能要件が同じ数字を参照できます。利用者数も同様で、登録ユーザー数と同時接続ユーザー数を分けて書かないと、後でライセンス費用の前提が崩れます。

管理すべき指標と情報システム化の範囲が決める効果測定と対象外業務

5)管理すべき指標は、業務の運営上捕捉すべき指標項目と、その把握手順・手法・頻度を書く区分です。ここが空欄の要件定義書は珍しくありませんが、指標を決めないままシステムを作ると、稼働後に効果を検証できません。「受注から出荷指示までのリードタイムを平均1.5営業日以内、日次でシステムから自動集計」のように、項目・目標値・取得手段・頻度をセットで書きます。

6)情報システム化の範囲は、システムを用いて実施する業務の範囲と、用いずに実施する業務の範囲の両方を明記する区分です。後者を書き落とすと、開発側は「書かれていない業務＝システムで賄う」と読むか「対象外」と読むかで見解が割れます。紙の押印が残る承認、電話での例外受付、月末の目視突合。人が行う前提の業務を先に確定させておくと、要件の抜けが減ります。

業務継続の方針と情報セキュリティが非機能要件の上限を決める理由

7)業務の継続の方針等は、情報システムの障害や災害が発生したときに維持すべき必須の業務を特定し、その業務を継続させるための基本的な考え方を書く区分です。全業務を止めないのか、受注受付だけは紙で継続するのか、翌営業日まで停止を許容するのか。ここでの判断が、そのまま非機能要件の可用性の水準になります。

8)情報セキュリティは、業務で扱う情報の格付・取扱い制限に応じた対策の基本的な考え方を書く区分で、情報資産の特定と分析を踏まえて脅威を特定しリスク分析を実施すると定められています。個人情報等の高い対策が必要な情報資産を含む場合は、通常に増して対策を行うという条件付きの規定です。非機能要件側の項目一覧はIPAの非機能要求グレードの解説で6大項目の構造を確認できます。

業務要件定義書の作り方をAs-Is把握からTo-Be確定まで5ステップで整理

現行業務の棚卸しと業務フロー図をどこまで細かく描くかの粒度基準

最初の作業は現行業務（As-Is）の棚卸しです。ここで迷うのが業務フロー図の粒度で、細かく描きすぎると更新が追いつかず、粗いと要件が抜けます。判断基準はひとつ。「担当者が変わる」「システムが変わる」「判断が入る」の3つのいずれかが起きる箇所は必ずノードとして分ける。それ以外の連続作業は1ノードにまとめて構いません。

画面遷移レベルまで落とすのは機能要件の仕事です。業務フロー図では、承認者が課長か部長か、差し戻しがどこへ戻るか、例外時に誰が判断するかまで書ければ十分。工程全体の中で棚卸しがどこに入るかはシステム開発の流れと各フェーズのポイントで全体像を確認できます。

To-Be業務フローの設計と既存業務との差異を明示する書き分け方

次はTo-Be（あるべき業務）を設計する段階です。DS-100は、既存の業務がある場合、定義する業務要件と既存実施している業務との差異が明確に把握できるよう留意すべきと明記しています。つまりTo-Beを単独で書くのでは足りず、As-Isとの差分が読み取れる形にする必要があります。

実務では、業務フロー図をAs-IsとTo-Beで並べたうえで、差分だけを表にまとめる方法が扱いやすいところです。「この作業は廃止」「この承認は2段階から1段階へ」「この転記はシステム連携に置換」といった変更点を、変更理由と影響を受ける部署とセットで一覧化する形です。この差分表が、稼働後の業務移行計画と教育計画の下敷きになります。同じ差分の整理をWebサイトの制作やリニューアルで行う場合の決め方はWeb制作の要件定義で決める項目と進め方にまとめています。要件定義書全体の章立てや記載項目のサンプルは要件定義書の書き方と記載項目の解説にまとめています。

規模と時期・時間の定量化で推測値と実測値を書き分ける記載ルール

3番目の作業は数量の確定です。ここで守るべきルールは、実測値と推測値を必ず区別して書くこと。既存システムのログから取れた件数は実測、新規業務の見込み件数は推測。同じ表に並べるとしても、出典列を設けて「基幹システム受注テーブル 2025年度実績」「営業部ヒアリングによる見込み」のように分けます。

推測値には幅を持たせるのが基本です。「月3,000件」ではなく「月2,500〜3,500件（中央値3,000件）」と書けば、開発側は上限側で設計するか、可変にする設計を提案するかを判断できます。将来の伸びも同様で、DS-100は非機能要件のデータ量についてライフサイクル期間における将来の見込みも記載するよう求めています。業務要件側で3年後・5年後の件数見込みを示しておくと、後段の規模要件がぶれません。

未確定の要件をリスクとして書き残す書式と後工程での確定手順の決め方

4番目は未確定事項の扱いです。DS-100は「未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにする」と定めています。空欄で出すのでも、仮の値で埋めて既定事実にするのでもなく、未確定であること自体を書く、という指示です。

書式は3列で足ります。未確定の項目、確定させる期限、確定するまでの暫定的な扱い。たとえば「新拠点の稼働時期＝2027年上期見込み／確定期限は基本設計完了時／それまでは既存3拠点分の規模で設計し、拠点追加を構成変更で吸収できる方式とする」。この形で残すと、後で仕様変更が起きたときに、想定内の変更か想定外かを切り分けられます。

最後の5番目が確認です。DS-100は、定義した内容について必要性・網羅性・具体性・定量性・整合性・中立性・役割分担の明確性という7つの観点と、情報セキュリティ等の観点から実現可能性を確認するよう求めています。中立性は、特定製品でしか実現できない書き方になっていないかを見る観点。役割分担の明確性は、どの作業を誰が担うかが要件から読めるかを見る観点です。

業務要件の精度が非機能要件のコストを決める仕組みと過剰要求の外し方

業務要件の粒度は、そのまま非機能要件の水準と費用に跳ね返ります。

稼働率と応答時間を業務要件から逆算する手順と過剰設定が招く代償

DS-100の非機能要件のうち、d)性能とe)信頼性には同じ趣旨の但し書きが付いています。いずれも「第4章5. 業務要件の定義において検討した内容に照らし、過度にならないよう適切な要件とすること」。つまり性能と信頼性は、業務要件から逆算して決めるものであり、上から数値を置くものではない、という規定です。

逆算の手順は単純です。業務要件の3)時期・時間で「業務の実施・提供時間は平日8時30分から19時」と決まっているなら、可用性の対象時間はその範囲になります。24時間365日の稼働率99.99%を要求する理由は、業務要件の側に存在しません。応答時間も同様で、1日400件のピーク処理を8時間で捌く業務なら、必要なスループットは毎分1件程度。ここに「全画面1秒以内」を機械的に置くと、キャッシュ層と冗長構成が要件に積まれ、初期費用と月額運用費の両方が上がります。

過剰設定の代償は費用だけではありません。稼働率の要件を上げると、保守時間帯の確保が難しくなり、パッチ適用や機能改修の頻度が落ちます。業務要件で「毎週日曜0時から6時は停止してよい」と決めておくほうが、稼働後の改善速度は上がります。

業務継続の方針が未定のまま冗長構成を積み増す失敗と回避の判断基準

業務要件の7)業務の継続の方針等が空欄のまま設計に進むと、開発側は判断材料がないため安全側に倒します。結果として、待機系サーバー、データセンター冗長、バックアップの多重化が一律に積み上がる。ところが稼働後に障害が起きたとき、業務側には手順書がなく、結局は電話と紙で凌ぐことになります。冗長化に投じた費用が業務継続に結びつかないパターンです。

判断基準として使えるのは、業務単位で停止許容時間を書き出す方法です。受注受付は4時間、出荷指示は2時間、月次締めは翌営業日まで、といった具合に業務ごとに区切る。全業務に同じ復旧目標を置かないことが、費用を抑えつつ実効性を持たせる条件になります。そのうえで、停止中に人が行う代替手順を業務要件側に書けば、非機能要件の可用性は必要な範囲に収まります。

業務要件定義を外部委託してよい範囲と発注側が書かないと崩れる範囲

「業務要件定義を外注できますか」という問いには、範囲を分けて答える必要があります。全部任せるのは無理、全部自社で抱えるのも非効率。線はもっと具体的な位置に引けます。

ベンダーに任せてよい作業はヒアリング設計と図式化と整合性の検証

外部に任せて効果が出るのは、進め方の設計と成果物への落とし込みです。誰にどの順でヒアリングするかの設計、聞き取った内容を業務フロー図と一覧表に整形する作業、8区分の間に矛盾がないかの検証。この3つは経験の差が出やすく、社内に上流工程の経験者がいない場合は外部を入れたほうが早く終わります。

整合性の検証は特に効きます。規模の処理件数と、時期・時間の提供時間と、管理すべき指標のリードタイム目標が互いに矛盾していないか。管理対象情報一覧に載っている情報が、情報セキュリティの格付と対応しているか。こうした横断チェックは、書いた本人には見えにくいものです。

発注側が自分で決め切る3点は業務の目的と管理指標とシステム化範囲

一方、次の3点は外部に決めさせてはいけません。業務の目的（何のために業務を変えるのか）、管理すべき指標（何をもって成功とするか）、情報システム化の範囲（どこまでをシステムに任せるか）。この3つは業務の当事者にしか決められず、外部が決めた場合は必ず後で覆ります。

DS-100が「機能要件、非機能要件及び情報システムの実現案についても、情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めた全体で決定することが不可欠」と書いているのは、業務要件よりさらに下流の機能要件・非機能要件についてすら、業務側の関与を外せないという趣旨です。上流の業務要件であればなおさら当てはまります。

業務要件の丸投げが破綻する条件と外部支援を入れる体制と期間の目安

丸投げが破綻する条件は明確です。業務側の専任担当が置けない場合、外注しても成果物は完成しません。ヒアリングに応じる時間が取れず、レビューが押印だけになり、稼働直前に「この業務が抜けている」と発覚する。この形が最も費用を失います。専任が置けないなら、対象業務を絞ってスコープを小さくするほうが確実です。

体制の目安として、業務要件定義の期間中は業務部門から意思決定できる担当を1名、実務に精通した担当を業務領域ごとに1名ずつ確保します。期間は対象業務の広さ次第ですが、単一業務なら1〜2か月、基幹業務を横断する場合は3〜6か月を見込むのが現実的な線です。この体制を社内だけで組めない場合は、上流工程から入る開発会社に相談する選択肢があります。当社では基幹システム開発で、業務要件の整理からスクラッチ開発とパッケージ導入の比較検討までを一貫して支援しています。

逆に、外部支援を入れるべきでない場面もあります。業務を変える意思決定がまだ社内で固まっていない段階です。この状態で外部を入れると、決められない論点を抱えたまま時間だけが過ぎます。目的と対象範囲を社内で合意してから声をかけるほうが、結果として費用は下がります。

よくある質問

業務要件定義をめぐって発注側から寄せられることの多い質問を5つ取り上げます。

業務要件定義と要件定義は何が違いますか？

要件定義は業務要件・機能要件・非機能要件の3種をまとめて確定させる工程全体を指し、業務要件定義はその最初のパートにあたります。DS-100では、要件定義書の記載内容がア業務要件・イ機能要件・ウ非機能要件・エ情報システムの実現案の4区分と定められており、業務要件はその一番上の区分です。業務要件定義だけを切り出して先に進める場合もありますが、その場合も後続の機能要件・非機能要件と整合性を取り直す作業が必要になります。

業務要件定義書には何を書けばよいですか？

DS-100 第3編第4章5に沿うなら、1)業務実施手順、2)規模、3)時期・時間、4)場所等、5)管理すべき指標、6)情報システム化の範囲、7)業務の継続の方針等、8)情報セキュリティの8区分です。1)の内訳は、体制・手順・業務フロー図と入出力情報および取扱量、管理対象情報一覧です。既存業務がある場合は、これらに加えて現行業務との差異が読み取れる形にすることが求められています。民間企業の案件でも、この8区分は抜け漏れの検査項目としてそのまま使えます。

業務要件定義は誰が担当しますか？

業務を実際に行う部門と、その業務のルールを所管する部門が主体になります。情報システム部門だけで決める形は、DS-100が明確に否定しているところです。外部のベンダーやコンサルタントは、ヒアリングの設計、図式化、整合性の検証といった進め方の部分で入るのが適した関わり方になります。業務の目的、管理すべき指標、システム化の範囲の3点は、発注側が決め切る必要があります。

業務フロー図はどこまで細かく描く必要がありますか？

担当者が変わる箇所、システムが変わる箇所、人の判断が入る箇所の3つを分けるところまでで十分です。画面遷移や入力項目の単位まで落とすのは機能要件の作業なので、業務要件定義の段階では踏み込みません。逆に、承認者の役職、差し戻し先、例外発生時の判断者は業務要件の側に書く必要があります。粒度を揃える基準を先に決めてから作図に入ると、部署ごとに詳しさがばらつく問題を避けられます。

業務要件が固まらないまま開発に進むとどうなりますか？

非機能要件が根拠のない高い水準で置かれ、費用が膨らみます。DS-100が性能と信頼性の両方に「業務要件の定義において検討した内容に照らし、過度にならないよう」という但し書きを付けているのは、この逆流を防ぐためです。加えて、システム化の範囲が曖昧なまま進むと、人が行う前提の業務が誰の担当としても定義されず、稼働直前に発覚します。未確定のまま進めざるを得ない場合は、未確定であること・確定期限・暫定の扱いを要件定義書に明記しておきます。

関連記事

• 要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説：業務要件の前段にあたる要求定義との境界と契約形態を扱っています。
• 仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説：要件定義より下流の文書との違いを整理しています。
• Webシステム開発とは？仕組み・種類・開発の流れと外注判断をわかりやすく解説：業務要件を実現する開発方式の選び方をまとめています。
• 【非機能要求グレードとは何か？】IPAが提唱するフレームワークの概要と非機能要求定義の目的を詳しく解説する：業務要件から導く非機能要件の項目体系を解説しています。
• 要件定義はAIでどこまで自動化できるか？生成AI・Claude Codeの実装手順と限界：要件定義の作業を生成AIで補う際の限界を扱っています。