業務定義書とは？書く内容・要件定義書との違い・作り方

業務定義書とは、対象業務の目的、範囲、流れ、関係者、ルールを文書としてまとめたものです。業務要件をまとめた文書という意味で「業務要件定義書」と呼ばれることもあります。

要件定義書がシステムに何を作るかを定める文書だとすれば、業務定義書はその前提となる業務そのものを定義する文書です。

決まった法定様式はなく、会社・案件によって呼び方や範囲が揺れますが、含めるべき内容には共通の型があります。

本記事では、記載項目、要件定義書・業務フロー図との違いと使い分け、システム発注の前に自社で作る価値と手順を解説します。

業務定義書に書く内容。共通の型

業務定義書の様式に統一の標準はありませんが、実務で一般に含まれる項目は次の通りです。

項目	書く内容	ポイント
業務の目的	この業務が何のために存在するか	「昔からやっている」を言語化し直す機会
範囲	どこから始まり、どこで終わるか。対象外は何か	対象外の明記が後の誤解を防ぐ
業務の流れ	手順と担当。例外時の扱い	詳細はフロー図に任せ、文書は要点と例外条件
関係者と役割	部署・担当・承認者・社外の相手	判断する人と作業する人を区別
入出力	使う情報・帳票と、作る情報・帳票	データの発生元と行き先を明記
ルール・制約	判断基準、期限、法令・社内規程	「担当者の頭の中」のルールを文字にする
用語集	業務で使う言葉の定義	社内用語・略語は必ず定義する

項目は全部を均等に書く必要はありません。読み手が判断を誤ると影響が大きい項目(範囲・ルール・用語)に厚く、誰が読んでも同じ理解になる項目は簡潔に、と濃淡をつけます。

このうち、外部へ発注する場面で最も価値が出るのは「ルール・制約」と「用語集」です。業務の判断基準と言葉の意味は、社内では自明でも社外には伝わらず、ここの欠落が要件の誤解や見積もりのぶれの主因になるためです。

書き方の例。1業務ぶんの記入イメージ

説明用の例として、「見積書の作成業務」の記入イメージを示します(実在の事例ではありません)。

目的の欄には「顧客の要望に対し、承認済みの条件で見積書を発行する」。範囲は「営業が要望を受けてから、顧客へ見積書を送るまで。受注後の契約手続きは対象外」。流れの要点は「営業が起案→単価と値引きは課長承認→経理が原価を確認→送付」。ルールの欄には「値引きは◯%まで課長決裁、超える場合は部長決裁」「有効期限は発行から30日」(数値は各社の実際の規程を記入します)。用語集には「『特価』は期間限定の承認済み値引き価格を指す」のように、社内でしか通じない言葉を並べます。

この分量でも、システム化の相談では「承認の分岐がある」「原価情報との連携が要る」といった要件の種が読み取れます。完璧な文書より、この密度の情報が業務ごとにそろっていることが重要です。

要件定義書・業務フロー図との違いと使い分け

業務定義書と要件定義書は、対象が異なります。業務定義書は「業務がどうあるか(またはどうあるべきか)」を定義し、システムの存在を前提にしません。要件定義書は、その業務を支えるために「システムに何を求めるか」を定義します。順序としては、業務の定義が先、システム要件が後です。要件定義工程の全体像は要件定義の進め方と書き方とシステム開発の要件定義マニュアルで解説しています。

業務フロー図との関係は、図と文書の分担です。流れの全体像と分岐は図の方が伝わり、判断基準・ルール・用語の定義は文書の方が正確に残せます。両方を作り、相互に参照させる形が実務的です。図の描き方はAs-Is/To-Be業務フローの書き方を参照してください。

発注前に自社で作る価値

業務定義書は、開発会社に作ってもらう文書と考えられがちですが、初版は発注前に自社で作ることを勧めます。理由は3つあります。

第一に、見積もりの精度が上がります。業務の範囲とルールが文書で示されると、開発会社は前提を推測せずに済み、「聞いていなかった業務ルール」による後からの増額を減らせます。第二に、提案の比較ができます。同じ業務定義を各社に渡せば、提案の違いが会社の力量の違いとして見えます。第三に、社内の合意が先に取れます。文書化の過程で「部署によって業務のやり方が違う」「誰も根拠を知らないルールがある」といった事実が見つかり、システム化の前に整理すべきことが分かります。

作成した業務定義書は、システム発注以外にも使い回せます。新任担当者への引き継ぎ・教育、業務の標準化の議論、監査対応時の説明資料など、業務の構造を示す文書はいずれの場面でも土台になります。

完成度は高くなくて構いません。空欄や「不明」の残る業務定義書でも、何が決まっていて何が不明かが見えること自体に価値があります。

作り方の手順とコツ

第1に、対象業務を1つ選び、範囲(開始と終了)を決めます。第2に、現場の担当者にヒアリングし、流れ・例外・判断基準を集めます。このときの進め方は業務フローのAs-Is作成と同じで、実際の画面・帳票を見せてもらいながら聞くのがコツです。第3に、前掲の型に沿って文書化し、必ず現場に読んでもらって「実態と合っているか」を確認します。第4に、版と日付を管理します。業務は変わるため、「いつ時点の定義か」が分からない文書は、かえって誤解の元になります。

既存の資料(業務マニュアル・規程・帳票)がある場合は、ゼロから書かずに流用してください。ただし、マニュアルの記載と実態がずれていることは多いため、「文書がこう言っている」ではなく「現場がこうしている」を正として確認します。

書く分量の目安は、読み手(開発会社・新しい担当者)が業務を誤解なく理解できる最小限です。分厚い文書を目指すより、用語集とルールの精度に時間を使ってください。

業務定義書に関するFAQ

業務定義書と業務マニュアルは何が違いますか？

目的が違います。業務マニュアルは担当者が作業を実行するための手順書で、操作レベルまで書きます。業務定義書は業務の構造(目的・範囲・流れ・ルール)を関係者で合意するための文書で、操作手順までは書きません。マニュアルがあるなら、業務定義書の材料として活用できます。

決まったテンプレートはありますか？

法定・統一の標準様式はありません。本記事の型(目的・範囲・流れ・関係者・入出力・ルール・用語集)を出発点に、自社の案件に必要な項目へ調整してください。他所のテンプレートを使う場合も、項目を鵜呑みにせず、自社に不要な項目は削る判断が必要です。

どこまで書けたら発注に進めますか？

完璧である必要はありません。範囲・主要な流れ・分かっているルール・用語集がそろい、不明点が「不明」と明示されていれば、発注先との会話の土台として機能します。不明点を埋める作業自体を、開発会社との要件定義で行うのが通常の進め方です。

業務の言語化から要件定義まで一緒に進められます

ノーコード総研では、ノーコードやAIを活用した業務システムの受託開発をご相談いただけます。「業務定義書を書き始めたが、これで足りているか分からない」という段階でも、文書のレビューと不足の洗い出しから一緒に進められます。

発注先の検討はシステム開発会社のタイプ別比較も参考に、まずは対象業務を1つ決めて、ノーコード総研に相談することから始めてみてください。