2026.10.21 Webシステム

システム要件定義とは？業務要件・ソフトウェア要件との違いと決める項目を解説

システム要件定義は、業務要件で決めた「新しい業務の姿」を、システムが満たすべき機能と性能・運用・移行の条件に置き換える工程です。IPAの共通フレーム2013では、要件定義はひとつの工程ではなく、業務側の要件定義プロセス、システム要件定義プロセス、ソフトウェア要件定義プロセスの3層に分かれています。この記事では、3層それぞれで誰が何を決めるのか、システム要件定義書に書く機能要件と非機能要件のうち発注者が数値で決めなければならない項目はどれか、業務要件からシステム要件へ落とす手順を整理しました。あわせて、システム要件定義を自社で担う範囲と開発会社に任せてよい範囲の線引きまで扱います。

まとめ：システム要件定義で発注者が決め切る数値と開発会社へ渡す範囲

システム要件定義とは、業務要件を実現するために、システム全体が備えるべき機能・規模・性能・信頼性・運用・移行の条件を確定させる作業です。共通フレーム2013では「2.3.2 システム要件定義プロセス」として、ソフトウェア単位の要件を決める「2.4.2 ソフトウェア要件定義プロセス」とは別に置かれています。システムはソフトウェアだけでなく、サーバーやクラウド、ネットワーク、運用体制まで含むためです。

発注者が自分で決め切るべきは、規模・性能・信頼性の数値、運用時間、移行の時期の4つ。どれも業務の実態からしか導けず、開発会社に任せると安全側に倒した過大な値が置かれます。デジタル庁のDS-100も、性能と信頼性は業務要件に照らして過度にならないよう定めるよう求めています。

逆に、システム方式（構成案）と、要件が実現・運用・保守できるかの評価は開発会社の得意分野です。DS-100は実現案を事業者の創意と工夫で提案を受けられるよう配慮すべきとしており、方式まで発注側が細かく指定すると、かえって良い提案を締め出します。

システム要件定義の意味と共通フレーム2013で3層に分かれる要件の位置

要件定義プロセスとシステム要件定義プロセスで作成者が入れ替わる構造

共通フレーム2013の第3部は、テクニカルプロセスを「2.1 企画」「2.2 要件定義」「2.3 システム開発」「2.4 ソフトウェア実装」の順に並べています。システム要件定義は2.3の中の「2.3.2」にあたり、直後に続くのは「2.3.3 システム方式設計プロセス」です。IPAが公開している共通フレーム2013第3部のガイダンス抜粋で、この番号体系を目次から確認できます。

注目すべきは作成者の違いです。2.2の要件定義プロセスのガイダンスには「原理原則[9] 要件定義は発注者の責任である」が挙げられており、発注側が責任を負う工程と位置づけられています。一方、2.3.2.2はシステム要件の評価を「開発者に対し」課すと書いており、2.3以降のシステム開発プロセスは開発者が主体です。システム要件定義は、発注者が出した要件を開発者が受け取り、システムとして実現できる形に書き直す境目の工程にあたります。

業務要件・システム要件・ソフトウェア要件の3層で決める内容の違い

3層の違いは、対象の広さで見ると整理しやすくなります。

層	共通フレームの番号	決める対象	主な作成者
業務要件	2.2 要件定義	業務の手順・規模・指標	発注側の業務部門
システム要件	2.3.2	機能・性能・運用・移行	発注側と開発側
ソフトウェア要件	2.4.2	プログラムの機能と品質	開発側

業務要件の中身、たとえばDS-100が定める業務実施手順や規模など8区分の書き方は業務要件定義の8つの記載項目と定義書の作り方で扱っています。ソフトウェア要件はシステム要件の一部をプログラムに割り当てたもので、発注者が直接書くことはまずありません。共通フレームの4.3.2.3も、ソフトウェア要件がシステム要件を正確に反映しているかを検証の対象に挙げています。

システムとソフトウェアを分ける理由と国際規格の改訂後の扱い方

IPAは共通フレーム2013の特徴として、ベースとなる国際規格をJIS X 0160:2012に変えたこと、要件定義プロセスにISO/IEC/IEEE 29148のエッセンスを入れたこと、そして「システム開発とソフトウェア開発の明確な分離」を挙げています。システムにはハードウェアやクラウド、運用手順が含まれるため、ソフトウェアの要件だけでは性能も可用性も決まらない、という考え方です。

版の扱いにも触れておきます。IPAのライフサイクルプロセスの解説ページによれば、ISO/IEC/IEEE 12207（JIS X 0160）は2021年にかけて改訂されましたが、共通フレーム2013そのものは改訂されていません。ソフトウェアに閉じた範囲の開発であれば共通フレーム2013に従って不都合はない、というのがIPAの説明です。2026年10月時点でも、国内の受託開発の工程名は共通フレーム2013の呼び方で話が通じます。

システム要件定義で決める項目を機能要件5区分と非機能要件18区分で整理

システム要件として書く項目は、デジタル庁のDS-100（2026年6月12日決定版）の第3編第5章が細かく区分しています。政府情報システム向けのルールですが、民間の発注でも抜け漏れの検査表として使えます。

機能要件の5区分で書く機能・画面・帳票・データ・外部連携の粒度

DS-100の機能要件は、a)機能、b)画面、c)帳票、d)データ、e)外部インタフェースの5区分です。機能は処理内容と入出力の関係、画面は概要と遷移の基本的な考え方、外部インタフェースは相手先システム・送受信データ名・送受信タイミングを一覧で書きます。帳票については、業務のデジタル化を前提に最小限にすることが望ましいと明記されています。

システム要件定義の段階で画面の項目配置まで決める必要はありません。そこは基本設計で決める成果物の領域です。機能要件と非機能要件の境目で迷う場合は、機能要件と非機能要件の違いを整理した解説を先に読むと判断しやすくなります。

非機能要件18区分のうち発注者が数値で決める規模と性能と信頼性

DS-100の非機能要件は、a)ユーザビリティ及びアクセシビリティからr)保守まで18区分あります。b)システム方式、c)規模、d)性能、e)信頼性、f)拡張性、j)情報セキュリティ、n)移行などが並びますが、発注者が自分で数値を出すべきなのは規模と性能と信頼性の3つに絞られます。

規模は機器数・データ量・処理件数・利用者数を書く区分で、データ量はライフサイクル期間における将来の見込みも記載するよう定められています。性能は応答時間やバッチ処理時間、信頼性は稼働率。この2つには「業務要件の定義において検討した内容に照らし、過度にならないよう」という但し書きが付いています。平日9時から18時しか使わない業務に24時間の稼働率99.99%を置く理由はない、という意味です。共通フレーム2013も原理原則[13]で「数値化されない要件は人によって基準が異なる」と述べています。18区分を項目単位で細かく決めたい場合は、IPAの非機能要求グレードの6大項目とグレード表が使えます。

運用要件と保守要件と機能改修を分けて書く規定と見積もりへの影響

見積もりのぶれを生みやすいのが、q)運用とr)保守の書き分けです。DS-100は、運用要件を保守要件と明確に区別して記載し、さらに保守要件を情報システムの機能改修及び更改と明確に区別して記載するよう求めています。

運用は運用時間・監視・障害復旧の方針、保守が指すのはハードウェアやソフトウェア製品のサポート体制です。ここが混ざると、月額の保守費に機能追加が含まれると発注側が読み、開発側は含まないと読む、という食い違いが稼働後に起きます。システム要件定義書の段階で3つを別の節に分けておけば、見積書の内訳も同じ単位で比較できます。

共通フレームが例示する技術要件・移行要件・付帯作業の書き漏れ

共通フレーム2013の2.2.3.1は、非機能要件の例として品質要件と技術要件、運用・操作要件、移行要件、付帯作業、その他要件を挙げています。DS-100の18区分には出てこない項目も含まれており、書き漏れの点検に向きます。

付帯作業：環境設定、端末展開作業、エンドユーザ教育、運用支援
移行要件：移行対象業務、移行対象のソフトウェアとハードウェア、移行手順、移行時期
その他要件：費用と納期の目標値、電力量、作業環境、フロア面積

実務で漏れやすいのは付帯作業です。端末の配布や利用者教育を誰が担うかが書かれていないと、開発費とは別の作業が稼働直前に発生します。費用と納期の目標値を要件として書く点も、民間の要件定義書では省かれがちな項目です。

システム要件定義書の作り方と業務要件から要件へ落とす4つの手順

システム要件定義書は、ゼロから書く文書ではありません。業務要件を入力にして、次の順で組み立てます。

業務要件の数値をシステム要件の各区分へ写し、出典を対応づける
システム方式の案を複数並べ、パッケージやSaaSを前提にするか決める
未確定の要件を期限と暫定の扱いつきで書き残す
実現・運用・保守ができるかを開発側に評価させ、合意する

要件定義書全体の章立てや表紙からの構成サンプルは要件定義書の書き方と章立てサンプルにまとめているので、ここでは各手順の判断基準だけを扱います。

業務要件の数値をシステム要件へ写し取るときの出典付き対応表の残し方

最初の手順で作るのは、業務要件とシステム要件の対応表です。「月の受注件数2,400件、ピーク日400件」という業務要件があれば、規模要件の処理件数と性能要件のバッチ処理時間がこの数字を参照します。対応表には、システム要件の番号、参照した業務要件の番号、数値の出典（実績ログか、ヒアリングによる見込みか）の3列を持たせます。

対応表がないシステム要件は、後で「なぜこの値なのか」を説明できません。共通フレーム2013の原理原則[14]は「『今と同じ』という要件定義はありえない」と述べています。現行システムの性能値をそのまま写すのではなく、業務要件から数字を引き直すのが原則です。

パッケージやSaaSを前提にシステム方式を先に決める場合の指定の粒度

DS-100の要件定義書は、ア業務要件・イ機能要件・ウ非機能要件に続く「エシステム方式の決定」で実現案を定めます。実現案は複数検討するものとされ、導入するクラウドサービスやパッケージ製品を先にシステム方式として定めてから他の要件を検討してもよい、と書かれています。

ただし同じ箇所に、システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれがある、という注意も付いています。指定してよいのは「SaaSのCRMを前提とする」「既存のAWS環境に載せる」といった方式の枠まで。製品のエディションやサーバーの台数まで発注側が書くと、相見積もりで比較する余地がなくなります。

未確定要件の書き残し方と開発側に評価させる実現性と運用と保守

DS-100は、定義の時点で未確定な要件について、プロジェクトのリスク要因になり得ることに厳に留意し、その旨を要件定義書で明らかにするよう定めています。空欄でも仮置きでもなく、未確定であること自体を書く。確定の期限と、それまでの暫定の扱いを並べて書けば足ります。

書き終えたら評価です。共通フレーム2013の2.3.2.2は、システム要件の評価として、次のシステム方式設計で実現できるか、運用が可能か、保守を可能とする内容か、の3点を見極めるよう開発者に課しています。必要に応じたプロトタイピングやシミュレーションの実施も、その評価に含まれる作業です。発注側はこの評価結果を受け取り、DS-100の7観点（必要性・網羅性・具体性・定量性・整合性・中立性・役割分担の明確性）で読み合わせてから合意します。

システム要件定義で発注者が担う範囲と開発会社へ任せる範囲の判断

要件定義は発注者の責任という原則とシステム要件の書き手が移る理由

「要件定義は発注者の責任」と「システム要件定義は開発者のプロセス」は矛盾しません。共通フレーム2013は、要件定義プロセスで機能要件や非機能要件を定義するとき、必要に応じて2.3.2のシステム要件定義や2.3.3のシステム方式設計を使ってもよいとしています。発注側が責任を持つのは「何を満たせば合格か」という基準で、それを実現できる形に書き下す作業は開発側に移ってよい、という分担です。

線引きの判断はひとつで足ります。その値が業務の実態から決まるなら発注側、技術の選び方から決まるなら開発側。稼働率、運用時間、データ量の見込み、移行時期は前者です。構成案、冗長化の方式、ミドルウェアの選定は後者にあたります。要求定義と要件定義の境目で契約形態をどう切り替えるかは、要求定義と要件定義の責任範囲と契約の分界点で整理しています。

システム要件定義に外部支援を入れるべき条件と入れるべきでない場面

外部支援が効くのは、社内に上流工程の経験者がおらず、業務要件はあるのにシステム要件へ落とせない場合です。対応表の作成、非機能要件18区分の数値の詰め、複数の方式案の比較は、経験の差が出る作業です。開発会社を選ぶ前の段階で支援を入れれば、RFPと見積もりの比較軸もそろいます。当社の要件定義・RFP作成・PMO支援では、業務要件の整理からシステム要件定義書の作成、開発会社の選定までを発注側の立場で支援しています。

外部支援を入れるべきでない場面もはっきりしています。業務要件、つまり業務をどう変えるかが社内で決まっていない段階です。この状態でシステム要件から書き始めると、現行システムの仕様が要件として固定され、共通フレームが戒める「今と同じ」要件定義になります。先に業務側の合意を取り、要件定義全体の進め方は要件定義の目的と進め方の解説で確認してから着手するのが順序です。

よくある質問

システム要件定義について、発注側から寄せられることの多い質問を5つ取り上げます。

システム要件定義と要件定義は同じ意味ですか？

日常的には同じ意味で使われることが多いものの、共通フレーム2013では別のプロセスです。「2.2 要件定義プロセス」は発注側が業務要件・機能要件・非機能要件を定義する工程で、「2.3.2 システム要件定義プロセス」は開発側がそれを受けてシステム全体の要件に書き直す工程にあたります。契約や見積もりの場で「要件定義」と言うときは、どちらを指しているのかを最初に確認しておくと、作業範囲の食い違いを防げます。

システム要件定義書には何を書けばよいですか？

DS-100の構成に沿うなら、業務要件、機能要件、非機能要件、システム方式（実現案）の4つです。機能要件は機能・画面・帳票・データ・外部インタフェースの5区分、非機能要件はユーザビリティから保守までの18区分に分けて書きます。これに加えて、業務要件との対応表と、未確定の要件の一覧を添えることが、後工程で値の根拠を説明するための備えです。共通フレーム2013が挙げる付帯作業や費用・納期の目標値も、書き漏れやすい項目として点検しておきます。

システム要件とソフトウェア要件はどう違いますか？

システム要件は、ソフトウェアに加えてサーバーやクラウド、ネットワーク、運用手順まで含めたシステム全体の要件です。ソフトウェア要件は、そのうちプログラムが受け持つ部分を切り出した要件で、共通フレーム2013では「2.4.2 ソフトウェア要件定義プロセス」として別に定義されています。稼働率や運用時間はシステム要件で決まり、ソフトウェア要件はそれを満たすようにプログラムの機能と品質を決める、という上下関係になります。ソフトウェア要件を文書にまとめる際の章立てと要件文の書き方は、ソフトウェア要件定義書とは？SRSの構成とISO/IEC/IEEE 29148の記載項目を解説で整理しています。

システム要件定義は発注者と開発会社のどちらが作りますか？

共通フレーム2013の上では開発者のプロセスですが、中身の数値は発注者が出します。規模、性能、信頼性、運用時間、移行時期は業務の実態からしか決まらないため、発注側が値を示し、開発側がそれを実現できる形に書き下す分担が現実的です。構成案や冗長化の方式は開発側が提案し、発注側は業務要件と照らして過剰になっていないかを確認します。全部を開発会社に任せると、安全側に倒した値が積み上がり費用が膨らみます。

システム要件定義にはどれくらいの期間がかかりますか？

期間は対象範囲と業務要件の完成度で大きく変わります。業務要件が固まっていて既存のSaaSやパッケージを前提にする場合は短く済み、方式案を複数比較したりプロトタイピングで実現性を確かめたりする場合は長くなります。期間を延ばす最大の要因は、業務要件の未確定事項です。システム要件定義に入る前に、未確定の要件とその確定期限を一覧にしておくと、手戻りによる延長を抑えられます。