当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『業務要件定義とシステム要件定義って、同じものを言い方を変えているだけ？』と、資料を見比べて首をかしげている方も多いはずです。
結論から言うと、業務要件定義は「仕事のやり方」を決め、システム要件定義は「それを支えるシステムの条件」を決めるもので、主語が違います。この記事では、同じ業務を例に2つを1対1で並べて、違いが一目でわかるようにお見せします。
業務要件定義とシステム要件定義の違いは？
業務要件の主語は「人や部署」、システム要件の主語は「システム」です。業務要件で決めた仕事のやり方を、システム要件でシステムの機能と品質に置き換えていきます。
要件定義の業務要件とシステム要件は、別々の作業というより、前後につながった2つの段階なんです。要件定義そのものの全体像は要件定義とはで紹介しています。
違いを5つの観点で並べると、次のようになります。
| 観点 | 業務要件定義 | システム要件定義 |
|---|---|---|
| 主語 | 人や部署（誰が、いつ、何をするか） | システム（システムが何をするか） |
| 目的 | 業務をどう変えるかを決める | 業務を支えるシステムの条件を決める |
| 中心になる人 | 発注側の業務部門 | 開発側のSEと発注側の情報システム部門 |
| 主な成果物 | 業務フロー図、業務一覧、業務ルール | 機能一覧、画面と帳票の一覧、非機能要件一覧 |
| 確かめる場面 | 新しい業務が回るかの確認 | 受入テストでの機能と品質の確認 |
順番は「業務要件が先」
業務要件定義とシステム要件定義は、業務要件を先に決めるのが基本です。仕事のやり方が決まっていないと、システムに何を任せるかも決められませんよね。
IPAの「共通フレーム2013」でも、利用者側の要件を決める要件定義プロセスの後に、開発側の技術的な要件に落とすシステム要件定義が続く流れで説明されています。
例えば「受注をシステムで管理したい」という話が出た時も、いきなり画面の話から始めないのがコツです。まずは誰が注文を受けて、誰が承認し、誰が出荷するのかを決めておきましょう。
開発側「承認は、どの注文でも必要ですか」
利用部門「金額が大きい注文だけで十分です。基準は課長と相談して決めます」
こうした業務の決めごとが、そのまま次のシステム要件の材料になります。
同じ業務で並べると違いがわかる：1対1の変換表
ここが、この記事でいちばん伝えたいところです。言葉で説明されるより、同じ業務の要件を左右に並べたほうが、違いはずっとわかりやすいんです。
架空の題材として、注文を受けてから出荷するまでの受注業務をシステム化する場合の例を作ってみました。
| 業務要件（人や部署が主語） | システム要件（システムが主語） |
|---|---|
| 営業担当は注文を受けたら当日中に受注を登録する | 受注の登録画面から取引先、商品、数量を入力できる |
| 在庫が足りない時は、営業担当が取引先に納期を連絡する | 登録時に在庫が足りなければ画面に知らせる |
| 一定額を超える注文は営業課長が承認する | 設定した金額を超える受注は承認待ちにし、課長に通知する |
| 倉庫担当は承認済みの注文だけを出荷する | 承認済みの受注だけを出荷指示の一覧に表示する |
| 月末に営業部長へ受注の実績を報告する | 担当者別、商品別の受注実績を表計算ソフト形式で出力できる |
| 取引先ごとの値引き条件は営業担当以外に見せない | 値引き条件は営業部の権限を持つ人だけが見られる |
左の列を読むと、誰が何をするかという「仕事の流れ」が見えますよね。右の列を読むと、その仕事を助けるためにシステムが何をするかが見えてきます。
変換表を作る時のコツ
『左右の書き分けがうまくいかない』という方は、主語をはっきり書くことから始めてみてください。
- 左の列は「営業担当は」「倉庫担当は」のように人や部署で始まっている
- 右の列は「システムは」を頭につけても読める文になっている
- 左の1行に対して、右に1行以上の対応がある
- 右の列に、左のどの行ともつながらない行が残っていない
- 人が判断する部分と、システムに任せる部分がはっきりしている
よくある書き間違い
業務要件の欄に「受注登録画面を作る」のような、システムの話を書いてしまうことです。業務要件に画面の話が混ざると、そもそも画面が必要なのかを考える前に作るものが決まってしまいます。
業務要件の欄には、システムを使わない場合でも成り立つ書き方をしてみてください。「紙でやっても同じことを言える文」になっていれば、業務要件として書けています。
非機能要件も業務要件から生まれる
変換表の最後の行を見てみてください。「値引き条件は営業担当以外に見せない」という業務のルールが、「権限を持つ人だけが見られる」というセキュリティの要件になっていますよね。
実は、性能や安全性などの非機能要件も、業務の事情から生まれることが多いんです。
| 業務の事情 | 生まれる非機能要件の例 |
|---|---|
| 月末に受注が集中する | 月末の登録が集中しても画面の応答が遅くならない |
| 出荷は平日の朝から始まる | 平日の朝の時間帯は止めない |
| 取引先の情報を扱う | 担当者ごとに見られる範囲を分け、操作の記録を残す |
非機能要件を決める時は、IPAの「非機能要求グレード」の6つの大項目を手がかりにしながら、業務の事情を聞き取ると漏れが減ります。
進め方と担い手はどう違う？
業務要件定義とシステム要件定義は、進め方や、誰が中心になるかも違います。それぞれの流れを見ておきましょう。
- 今の業務（As-Is）を業務フロー図で描き、困りごとを出す
- 目指す業務（To-Be）を描き、何を変えるかを決める
- 業務のルールや判断の基準を業務要件として書く
- 業務の中でシステムに任せる部分を選ぶ
- 任せる部分を、機能要件と非機能要件に書き直す
- 業務要件とシステム要件のつながりを関係者で確かめる
1から3が業務要件定義、4から6がシステム要件定義にあたります。今の業務と目指す業務の比べ方は要件定義の業務分析（As-Is/To-Be）で詳しく紹介しています。
成果物の違いを一覧で見る
2つの段階では、作る資料も違います。どちらの資料なのかを意識しておくと、レビューの時に「この資料で何を確かめればいいか」がわかりやすくなります。
| 段階 | 主な成果物の例 | レビューで見ること |
|---|---|---|
| 業務要件定義 | 業務フロー図、業務一覧、業務ルールの一覧 | 新しい仕事の流れで現場が回るか |
| システム要件定義 | 機能一覧、画面一覧、帳票一覧、データ項目一覧、非機能要件一覧 | 業務要件をすべて支えられるか |
発注側と開発側の関わり方
業務要件定義は、業務を一番知っている発注側が中心になります。開発側は聞き取りや図にする手伝いをしながら、システムで実現できそうかの見通しを伝えます。
システム要件定義になると、開発側のSEが中心になって書き進めます。ただ、発注側が抜けてしまうと、業務要件とのずれに気づけません。
利用部門「承認の金額は、季節によって変えたいんです」
開発側「では、金額を画面から変えられるようにする要件を足しておきますね」
このように、システム要件を書く段階でも業務の担当者と話し続けるのがポイントです。業務要件定義書の書き方そのものは、業務要件定義書の書き方で紹介しています。
片方だけで進めると何が起きる？
業務要件定義とシステム要件定義は、どちらか一方だけでは足りません。片方が欠けた時によく起きることを並べてみました。
| 欠けているもの | 起きやすいこと | 防ぎ方 |
|---|---|---|
| 業務要件がない | 機能はそろっているのに、現場の仕事の流れに合わない | 先に業務フローで仕事の流れを合意する |
| システム要件がない | 業務の希望はあるが、開発側が何を作ればよいか判断できない | 業務要件を1行ずつシステムの言葉に書き直す |
| 両者のつながりがない | 使われない機能ができる、必要な機能が抜ける | 変換表で左右の対応を確かめる |
『システムを入れれば業務は自然と良くなる』と考えたくなりますよね。でも、業務のやり方を決めないままシステムだけ入れ替えても、困りごとはそのまま残ることが多いんです。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
システム化しないと決めるのも業務要件定義の役目
業務要件を決めていくと、「この作業はシステムにしなくても、ルールを変えるだけで解決する」と気づくことがあります。それも立派な成果なんです。
例えば「承認が遅れる」という困りごとは、承認者の代わりを決めるだけで解決する場合もあります。業務要件定義で仕事のやり方から見直すことで、作らなくてよい機能を減らせますよ。
システム要件の決め方をもっと詳しく知りたい方はシステム要件定義とはを、業務要件側は業務要件定義とはを読んでみてください。
よくある相談に答えます
業務要件定義とシステム要件定義について、よく寄せられる相談を要約してお答えします。
システム要件定義と業務要件定義は、好みで使い分けているだけ？
「2つは同じことで、人によって呼び方が違うだけではないか」という相談があります。結論から言うと、指しているものは別で、主語が違います。
業務要件定義は仕事のやり方を決めるもの、システム要件定義はそれを支えるシステムの条件を決めるものです。ただ、会社によっては2つをまとめて一冊の要件定義書にすることもあるので、呼び方が混ざって見えるのは自然なことです。
「要件定義プロセス」と「システム要件定義」はどう違う？
「要件定義プロセスとシステム要件定義の違いを分かりやすく知りたい」という相談も多いです。共通フレーム2013の考え方では、要件定義プロセスは利用者側の要件、つまり業務要件を決める工程です。
一方、システム要件定義は、その業務要件を開発側の技術的な要件に落とす工程です。名前が似ていて混乱しやすいのですが、「利用者の言葉で決める」か「システムの言葉で決める」かで区別すると覚えやすいですよ。
やったことのない業務の要件定義は、どう進めればいい？
「自分が経験したことのない業務を要件定義する時は、どうしているのか」という相談もあります。まずは業務の担当者に、今の仕事の流れを一つずつ教えてもらうところから始めましょう。
聞いた内容をその場で業務フロー図に描いて見せると、「そこは違う」「その前にこの作業がある」と相手から補ってもらえます。描き方は業務フロー図の書き方で紹介しています。
「どんな時に困りますか」「例外はどんな時に起きますか」と、困りごとと例外から聞くと、業務要件の大事な部分が出てきやすくなります。
よくある質問
業務要件定義とシステム要件定義の違いを簡単に言うと？
業務要件定義は人や部署が主語で仕事のやり方を決め、システム要件定義はシステムが主語で機能と品質の条件を決めます。業務要件を先に決め、それをシステム要件に置き換えます。
業務要件定義は発注側だけで行うものですか？
中心は発注側の業務部門ですが、開発側も聞き取りや図にする作業を手伝うのが一般的です。システムで実現できそうかの見通しを早めに共有できます。
業務要件とシステム要件は別の文書にするべきですか？
決まりはなく、一冊にまとめる会社も分ける会社もあります。どちらの場合も、業務要件とシステム要件のつながりがたどれるようにしておきましょう。
業務要件定義を飛ばしてシステム要件定義から始めてもよいですか？
おすすめしません。仕事のやり方が決まっていないと、システムに何を任せるかの判断がぶれてしまいます。
パッケージ製品を入れる場合も業務要件定義は必要ですか？
必要です。製品の機能に業務を合わせるのか、製品に手を加えるのかを判断するために、まず自社の仕事のやり方を決めておく必要があります。
まとめ
- 業務要件の主語は人や部署、システム要件の主語はシステム
- 業務要件で仕事のやり方を決め、それをシステム要件で機能と品質の条件に置き換える
- 同じ業務を左右に並べた変換表を作ると、違いとつながりが一目でわかる
- 業務要件は発注側、システム要件は開発側が中心だが、どちらも両者で確かめる
- 片方だけでは、現場に合わない機能や作るものが決まらない状態になりやすい
コメント