当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『業務要件定義をやってと言われたけど、何を書けば終わりなのか見えない』と困っている方も多いはずです。
結論から言うと、業務要件定義は「新しい仕事のやり方」を、誰が読んでも同じ動きができるところまで決める作業です。この記事では、業務要件を4つの項目で書く記入例を使って、何をどこまで決めればいいのかがわかるようにお伝えします。
業務要件定義とは？まずは一言で
業務要件定義とは、システムを入れた後の仕事を「誰が・いつ・何を・どの基準で」行うのかを決めて、関係者で合意することです。主語は人や部署で、システムの画面や機能の話はこの段階ではまだしません。
要件定義という言葉は広く使われますよね。その中で、業務の側から決めていく部分を「業務要件定義」と呼ぶことが多いんです。
要件定義全体の意味や流れは要件定義とはで紹介しています。ここでは、業務要件定義とはどんな作業なのかに絞ってお話しします。
業務要件と要求の違い
似た言葉に「要求」があります。要求は、利用者や発注者の「こうしたい、こうなってほしい」という希望のことです。
要件は、その希望のうち、予算や期間、技術を踏まえて「実現すると合意したこと」を指します。業務要件は、その合意を仕事のやり方の言葉で書いたものだと考えてみてください。
要件定義の中での位置
IPAの「共通フレーム2013」では、利用者側の要件を決める工程を「要件定義プロセス」と呼んでいます。業務要件定義は、ちょうどこの工程にあたる作業です。
その後に、業務要件を開発側の技術的な要件に落とす「システム要件定義」が続きます。
| 段階 | 主に決めること | 主語 |
|---|---|---|
| 業務要件定義 | 仕事の流れ、担当、判断の基準、業務のルール | 人や部署 |
| システム要件定義 | 機能、画面、帳票、データ、性能などの条件 | システム |
| 設計 | どう作るか | 開発側の作り方 |
例えば「請求書を受け取ったら、その日のうちに担当部署へ回す」は業務要件です。一方で「請求書の受付画面で担当部署を選べる」はシステム要件になります。
2つの違いをもっと詳しく知りたい方は業務要件定義とシステム要件定義の違いを読んでみてください。
業務要件定義で決めること
業務要件定義で決めることは、大きく分けると4つです。どれも、新しい仕事の流れを現場で回すために欠かせないものなんです。
- どの業務を対象にし、どこからどこまでを変えるか
- 新しい仕事の流れと、それぞれの作業の担当
- 作業の判断の基準や、例外の時の扱い
- 業務で扱う書類やデータと、その受け渡し
- 変えた結果、何がどう良くなれば成功とするか
中でも見落とされやすいのが、最後の「何が良くなれば成功か」です。ここが決まっていないと、新しい仕事のやり方が良かったのかを後で誰も判断できません。
例えば請求書の業務なら「支払いの遅れをなくす」「確認の手間を減らす」のように、変えたい理由をそのまま成功の目安にしておきましょう。ここが決まると、話し合いで迷った時の判断の拠り所にもなりますよ！
成果物はどんなものを作る？
業務要件定義で作る資料は、会社によって呼び方も様式も違います。よく作られるものを並べると、次のようになります。
| 成果物の例 | 中身 | 誰が主に確かめるか |
|---|---|---|
| 業務フロー図 | 部署ごとのレーンに分けた作業の順番 | 業務部門の担当者 |
| 業務一覧 | 対象の業務と担当、頻度の一覧 | 業務部門の責任者 |
| 業務ルールの一覧 | 判断の基準や例外の扱い | 業務部門の責任者 |
| 課題一覧 | まだ決まっていないことと期限 | 発注側と開発側の両方 |
業務フロー図の描き方は要件定義の業務フロー図の書き方で紹介しています。
「システムで何をするか」はまだ書かない
『でも、結局システムを作るんだから、画面の話もしておいたほうが早いのでは』と思いますよね。気持ちはよくわかります。
ただ、業務要件の段階で画面の話を始めると、仕事のやり方を見直す前に作るものが決まってしまいます。紙でやっても同じことを言える文になっているかを、一度確かめてみてください。
業務要件を「誰が・いつ・何を・どの基準で」で書く記入例
ここがこの記事でいちばんお伝えしたいところです。業務要件は、1行ごとに4つの項目を埋めるだけで、ぐっと読みやすくなります。
架空の題材として、取引先から届いた請求書を受け取ってから支払うまでの業務を、新しいやり方に変える場合の例を作ってみました。
| 誰が（例） | いつ（例） | 何を（例） | どの基準で（例） |
|---|---|---|---|
| 総務担当 | 請求書が届いた日のうちに | 受け取った請求書を登録し、発注した部署に回す | 取引先名と金額が読み取れるものだけ受け付ける |
| 発注した部署の担当 | 回ってきてから2営業日以内に | 請求の中身が発注どおりかを確かめる | 品目と数量が発注書と合っていること |
| 発注した部署の課長 | 担当の確認が終わった時点で | 支払ってよいかを承認する | 部署の予算の残りを超えていないこと |
| 経理担当 | 毎月の支払日の前日までに | 承認済みの請求をまとめて支払いの準備をする | 承認が済み、振込先が登録済みであること |
| 経理担当 | 金額の違いが見つかった時 | 発注した部署と取引先に確認を依頼する | 請求額と発注額が合わないこと |
左から順に読むと、仕事の流れがそのまま浮かんできますよね。数字は例として置いたもので、実際は業務部門と相談して決めてください。
4項目で書くと何がいいのか
『毎回4つも埋めるのは手間がかかりそう』と感じるかもしれませんね。でも、この手間が後の手戻りを減らしてくれます。
4つの項目を埋めようとすると、決まっていないことが空欄として見えてきます。例えば「いつ」が空いていれば、期限を誰も決めていないということなんです。
埋まらない欄は、無理に埋めずに課題一覧に移しておきましょう。「誰が・いつまでに決めるか」を書き添えると、話し合いが止まりにくくなります。
書く時に迷いやすいところ
「どの基準で」の欄は、最初は空きがちです。現場では担当者の頭の中で判断していて、言葉になっていないことが多いからです。
開発側「金額が合わない時は、どうしていますか」
利用部門「そのつど、担当が取引先に電話しています。少しの違いなら、そのまま払うこともありますね」
こうした会話から、「少しの違い」とはどこまでかを決める必要があるとわかります。この基準が決まらないと、後でシステムにどう判断させるかも決められません。
「何を」の欄に「請求書をシステムに登録する」と書いてしまうことです。この段階ではシステムを使うかどうかもまだ決まっていないので、「請求書を登録する」のように道具を書かずに書いておきましょう。
業務要件定義の進め方
業務要件定義は、いきなり新しい仕事のやり方を考えるより、今の仕事を知るところから始めるとスムーズです。
- 対象の業務と、変えたい理由を関係者で確かめる
- 今の仕事の流れを業務フロー図に描く
- 困っていることと、その原因を聞き取る
- 目指す仕事の流れを描き、何を変えるかを決める
- 新しい流れの1行ずつを4項目の表に書く
- 業務部門の責任者に読んでもらい、合意を取る
2から4は、今の業務（As-Is）と目指す業務（To-Be）を比べる作業です。比べ方のコツは要件定義の業務分析（As-Is/To-Be）で詳しく紹介しています。
聞き取りでは「困った時」から聞く
今の仕事の流れを聞く時、「普段どうしていますか」だけだと、うまくいっている時の話しか出てきません。業務要件で大事なのは、むしろ例外の時の動きなんです。
開発側「請求書が届いたのに、どこの部署が発注したかわからない時はありますか」
利用部門「月に何回かあります！その時は、総務が社内に聞いて回っています」
この一言から、「発注した部署がわからない請求書を誰がどう扱うか」という業務要件が1行増えます。例外の聞き取りは、次のような問いかけが使いやすいですよ。
- いつもと違う対応をするのは、どんな時ですか
- 担当の方が休みの日は、誰が代わりにやっていますか
- 締め切りに間に合わない時は、どうしていますか
- 判断に迷った時は、誰に相談していますか
書き上がった業務要件を確かめる
4項目の表ができたら、関係者に読んでもらう前に自分で一度見直しておきましょう。見るところは多くありません。
| 確かめること | 見直しのポイント |
|---|---|
| 主語 | 「誰が」の欄に人か部署が入っていて、システムが主語になっていない |
| 期限 | 「いつ」が「速やかに」のようなあいまいな言葉になっていない |
| 判断の基準 | 「どの基準で」を読めば、別の人でも同じ判断ができる |
| 例外 | うまくいかない時の行が、いつもの行と同じくらい書かれている |
| つながり | ある行の作業の結果を、次の行の担当が受け取れる |
「速やかに」「適切に」のような言葉は、人によって受け取り方が変わります。ISO/IEC/IEEE 29148でも、良い要件の性質として「あいまいでない」「検証できる」が挙げられています。
誰が中心になる？
業務要件定義は、業務を一番よく知っている発注側の業務部門が中心です。IPAの「ユーザのための要件定義ガイド 第2版」も、業務に責任を持つユーザーが主体的に関わることの大切さを伝えています。
開発側のSEは、聞き取りや図にする作業を手伝う役です。システムで実現できそうかの見通しを早めに伝えると、後の手戻りが減ります。
| 立場 | 業務要件定義での主な役割 |
|---|---|
| 業務部門の担当者 | 今の仕事の流れと困りごとを伝える |
| 業務部門の責任者 | 新しい仕事のやり方を決め、承認する |
| 社内SEや情報システム部門 | 業務部門と開発側の橋渡しをする |
| 開発側のSE | 聞き取りを進め、図や表にまとめる |
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
よくある相談に答えます
業務要件定義について、よく寄せられる相談を要約してお答えします。
要件定義で「これで良い」と決めたら署名するもの？
「要件定義を終えた時に、署名やはんこで合意を残すことはあるのか」という相談があります。結論から言うと、承認欄を設けて責任者のサインや承認の記録を残す会社は多いです。
業務要件は、後から「そんな話は聞いていない」となりやすい部分です。誰がいつ承認したかを残しておくと、変更が出た時にも落ち着いて話し合えます。
要件定義の業務は入社何年目から任される？
「何年目くらいから要件定義を任されることが多いのか」という相談も多く見かけます。実は、年数で決まるわけではなく、会社や案件の大きさによってかなり違います。
最初は議事録を書いたり、業務フロー図の清書をしたりする形で関わることが多いです。そこで業務の聞き方に慣れておくと、任された時に慌てずに済みますよ。
文系出身だと要件定義で力を活かせる？
「文系出身の人は要件定義で能力が活かせるのか」という相談もあります。要件定義では、相手の話を聞く力や、文章で正確に書く力がとても大切です。
ただ、出身で向き不向きが決まるわけではありません。ITの基礎知識と合わせて身につけていけば、どなたでも力を発揮できる仕事です。
よくある質問
業務要件定義とは何ですか？
システムを入れた後の仕事を、誰が、いつ、何を、どの基準で行うのかを決めて、関係者で合意することです。主語は人や部署になります。
業務要件定義とシステム要件定義はどちらを先に行いますか？
業務要件定義が先です。仕事のやり方が決まっていないと、システムに何を任せるかを決められないからです。
業務要件定義は発注側と開発側のどちらが担当しますか？
中心は発注側の業務部門です。開発側のSEは聞き取りや図にする作業を手伝い、実現できそうかの見通しを伝えます。
要件定義の業務要件は、どのくらい細かく書けばよいですか？
読んだ人が同じ動きをできるところまでが目安です。担当、期限、判断の基準、例外の扱いが書けていれば、次のシステム要件定義に進めます。
業務要件定義書の様式に決まりはありますか？
決まった様式はなく、会社ごとに違います。4項目の表や業務フロー図を中心に、読んだ人が同じ動きをできる形にまとめましょう。
業務要件定義書の章立てや書き方は業務要件定義書の書き方にまとめています。
まとめ
- 業務要件定義とは、新しい仕事のやり方を決めて合意すること
- 主語は人や部署で、画面や機能の話はまだしない
- 業務要件は「誰が・いつ・何を・どの基準で」の4項目で書くと抜けが見える
- 埋まらない欄は課題一覧に移し、決める人と期限を書き添える
- 中心は業務部門で、開発側は聞き取りと図にする作業を手伝う
コメント