業務要件定義書の書き方｜章立てとヒアリングで埋める順番

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

業務要件定義書とは？

業務要件定義書は、要件定義書の中でも業務の側を受け持つ部分なんです。会社によっては、業務要件とシステム要件を一冊の要件定義書にまとめることもあります。

業務要件定義そのものの考え方は業務要件定義とはで、要件定義全体の流れは要件定義とはで紹介しています。

要件定義書の中での位置

要件定義書に入る中身を、業務の側とシステムの側に分けてみると、次のようになります。

業務要件定義書は、この表の「業務要件」と「共通」の部分にあたります。システム要件まで含めた要件定義書の書き方は要件定義書の書き方で紹介しています。

誰が書くもの？

『業務要件定義書は、開発側のSEが書くものじゃないの？』と思う方もいますよね。実際は、契約の形や会社によって書く人が変わります。

ただ、どの場合でも中身を決めるのは業務部門です。開発側が筆をとる時も、業務部門の言葉で書き、業務部門に読んで合意してもらう形にしておきましょう。

業務要件定義書の章立て例

まずは目次から作ってみてください。章立てが決まると、何が足りていないかが見えるようになります。

よく使われる章立てを、章ごとに書く中身と合わせて並べました。様式は会社ごとに違うので、自社の様式があればそちらに合わせてください。

章が多く見えますが、全部を同じ厚さで書く必要はありません。小さな業務の見直しなら、1〜2ページで済む章もありますよ。

章立てでよくある迷い

『業務フロー図は本文に入れるの？別紙にするの？』という迷いもよく聞きます。どちらでも構いませんが、本文の業務一覧と図の作業名が一致していることが大切です。

ヒアリングで埋める順番

ここがこの記事でいちばんお伝えしたいところです。章立ての番号どおりに1章から書こうとすると、実はつまずきやすいんです。

なぜなら、「背景と目的」や「目指す業務」は、今の業務を聞いてからでないと書けないからです。利用部門へのヒアリングで埋めやすい章から順に進めてみてください。

回ごとに誰に何を聞くか

ヒアリングの回ごとに、相手と質問を決めておくと話が散らかりません。架空の題材として、社員研修の申し込みと受講の管理を見直す場合の例を作ってみました。

回数は例として置いたものです。小さな業務なら2〜3回の打ち合わせにまとめても大丈夫です。

ヒアリングの前に用意しておくもの

ヒアリングは、手ぶらで行くより、たたき台を持っていくほうが話が進みます。白紙だと、相手も何から話せばいいのか迷ってしまうんですよね。

下書きの業務フロー図は、間違っていても構いません。「ここは違う」と直してもらうほうが、ゼロから説明してもらうより早く正しい流れにたどり着けます。

今の業務を先に聞く理由

背景と目的を最初に聞くと、「効率化したい」「ミスを減らしたい」のような大きな言葉しか出てこないことが多いですよね。今の業務を一通り聞いた後なら、困りごとが具体的になっています。

開発側「さきほど、申し込みの一覧を毎週手で集計しているとおっしゃっていましたね」
利用部門「そうなんです。その集計に毎回追われていて、受講後のフォローまで手が回らないんです」

この会話から、「集計の手間を減らして、受講後のフォローに時間を回したい」という目的が見えてきます。これを1章に書けば、ぐっと読み手に伝わる背景と目的になりますよ！

章ごとの書き方と記入例

ここからは、書き方で迷いやすい章を取り上げて、社員研修の申し込み管理を題材にした記入例をお見せします。

1章 背景と目的の記入例

背景と目的は、困りごとと目指す状態を短く書くのがコツです。読んだ人が「だから業務を変えるのか」と納得できれば十分なんです。

2章 対象範囲の記入例

対象範囲では、やらないことを書くのが大事です。ここがあいまいだと、話し合いのたびに範囲が広がってしまいます。

3章と4章 今の業務と目指す業務の記入例

3章と4章は、同じ作業を左右に並べて書くと変わる部分が一目でわかります。困りごとの列を足しておくと、なぜ変えるのかも一緒に伝わるんです。

この表の「目指す業務」の列が、そのまま4章の業務フロー図と5章の業務一覧の材料になります。困りごとの列は、1章の背景を書く時にも使えますよ。

9章 用語集の記入例

用語集は軽く見られがちですが、実は話のすれ違いを防ぐ大事な章です。同じ言葉でも、部署によって指すものが違うことは珍しくありません。

『受講済みの意味なんて、みんな同じだと思っていた』という声は、読み合わせの場でよく出ます。用語集に載せておけば、後で集計の数字が合わないといった行き違いを防げます！

6章 業務ルールの記入例

業務ルールは、「誰が読んでも同じ判断ができるか」を基準に書いてみてください。業務要件は「誰が・いつ・何を・どの基準で」の4項目で書くと抜けが見えやすくなります。

数字は例として置いたものです。実際の期限や基準は、業務部門と相談して決めてください。

7章 業務で扱う書類とデータの記入例

書類とデータの章では、「どの作業で作られて、誰に渡るか」を書いておきます。後でシステム要件を考える時に、データ項目を洗い出す土台になるんです。

8章 前提と制約の記入例

前提と制約には、この見直しでは変えられない条件だけを書きます。変えられることまで書くと、新しい業務の選択肢を自分たちで狭めてしまうんです。

• 研修の受講の記録は、社内規程で決められた期間保管する（例）
• 新しい業務の流れは、次の年度の研修計画から使い始める（例）
• 各部署の取りまとめ役は、今いる人員の中から決める（例）

10章 未決事項の書き方

未決事項は、決まっていないことを隠さずに集める章です。「何が決まっていないか」「誰がいつまでに決めるか」を1行ずつ書きます。

書き上げた後のレビューと合意

業務要件定義書は、書き上げた後のレビューで本当の完成になります。業務部門の責任者に読んでもらい、承認を取るところまでが書き方の一部だと考えてみてください。

ISO/IEC/IEEE 29148では、良い要件の性質として「あいまいでない」「検証できる」「矛盾しない」などが挙げられています。レビューでは、この3つを意識して読んでもらうと指摘が具体的になります。

読み合わせのコツ

レビューは、資料を送って「確認してください」と頼むだけだと、読まれないまま承認されることもありますよね。可能なら、関係者を集めて読み合わせの時間を取りましょう。

合意の残し方

合意は、承認欄に責任者の名前と日付を入れて残すのが一般的です。後で中身を変える時は、版を上げて変更の履歴を残しておきましょう。

業務フロー図の描き方は要件定義の業務フロー図の書き方で、今の業務と目指す業務の比べ方は要件定義の業務分析（As-Is/To-Be）で詳しく紹介しています。

よくある相談に答えます

業務要件定義書について、よく寄せられる相談を要約してお答えします。

要件定義書を読んでも、全くわからない

「改正に向けた案件の要件定義書を渡されたが、読んでも意味がわからない」という若手の方からの相談があります。結論から言うと、最初からすべてを理解しようとしなくて大丈夫です。

まずは背景と目的、対象範囲の章だけを読んで、何を変える案件なのかをつかんでみてください。次に業務フロー図を見ながら、知らない用語を用語集で調べると、全体が少しずつつながってきます。

要件定義書や画面遷移図は、どんな形式で出すもの？

「要件定義書や画面遷移図は、文書ソフトや表計算ソフトなど、どの形式で提出するのが普通か」という相談もあります。実は、形式に決まりはなく、会社や発注側の決まりに合わせることがほとんどです。

業務要件定義書なら、文章の章は文書ソフト、業務一覧や業務ルールは表計算ソフトという組み合わせもよく見かけます。どの形式でも、版の管理と、本文と別紙のつながりがたどれることが大事です。

現場の課題を聞き出してシステム化する方法を学びたい

「現場から課題を聞き出してシステムにする方法を学べる本を知りたい」という相談も見かけます。個別の本は挙げませんが、公的な資料としてIPAの「ユーザのための要件定義ガイド 第2版」があります。

この資料は、業務に責任を持つユーザーの立場から、要件定義の問題と解決のコツをペアで説明しています。読み物として眺めた後、この記事の章立てで小さな業務を1つ書いてみると、理解が一気に進みますよ。

よくある質問

まとめ

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

業務要件定義とは？誰が・いつ・何をで書く記入例つき解説

要件定義書の書き方を手順で解説｜NG文の直し方と章ごとの記入例