「現状の業務をそのままシステム化しようとしたり、安易に『運用でカバー』とした結果、現場が混乱しないか不安です。」
ITシステムの導入やDX（デジタルトランスフォーメーション）推進の現場において、「システムを作ったものの、現場で全く使われない」「思っていた業務の流れと違って現場が大混乱した」というトラブルは後を絶ちません。
このような失敗が起きる最大の原因は、要件定義の第2フェーズである「業務要件定義（業務プロセス要件定義）」が曖昧なまま、いきなりシステムの画面や機能の設計に進んでしまうことにあります。
業務要件定義とは、事業要件で定めた目的を達成するために、「現場の業務プロセスをどのように見直し、どこまでをシステムが担い、どこからを人が担うのか」という境界線を明確にして合意形成する工程です。現状（As-Is）の作業をただ真似てシステム化するのではなく、業務そのものをシンプルに再設計（To-Be）することが求められます。
本記事では、業務要件定義の全体像から、業務の目的を明確にする「XYZ分析」「CATWOE分析」、As-Is/To-Be業務フロー図の作成手法、業務改善の4原則（ECRS）、安易な「運用でカバー」を回避する設計ポイント、そして「機能一覧」「システム全体像」への落とし込みまで、実践的な手順を分かりやすく解説します。
- 業務要件定義の定義：事業目的を現場プロセスへ落とし込み「人とシステムの分担」を決める重要性
- 窓口担当者だけでなく「実利用者の現場」を巻き込むべき理由
- 業務要件定義の全体プロセスと作成すべき3大成果物（業務フロー図・機能一覧・システム全体像）
- 業務の目的と関係者を浮き彫りにする「XYZ分析」と「CATWOE分析」の進め方・セルフチェック
- 現状（As-Is）フロー分析の重要性と、業務フロー図を描く3つの鉄則（スイムレーン・吹き出し・入出力）
- 新業務（To-Be）設計の勘所：ECRS原則（排除・結合・交換・簡素化）と「運用でカバー」の回避策
- 業務フローから「機能一覧」を抽出し「システム全体像（1枚絵）」で構築範囲を合意する手順
業務要件定義とは？人とシステムの役割分担を明確にする重要性
要件定義は大きく「事業要件定義」「業務要件定義」「システム要件定義」の3段階に分かれます。前工程である「事業要件定義」で定めたIT投資の目的や利益創出シナリオを受け、現場の業務プロセスへ具体的に落とし込んで人とシステムの役割分担を決めるのが「業務要件定義」です。ビジネスの目的とITシステムの実装を繋ぐ重要な結節点となります。
業務要件定義の定義と目的
業務要件定義を一言で表すと、「構築範囲（システム化範囲）を明確化する工程」です。
システム開発のプロジェクトにおいて、「何でもかんでもシステムで自動化する」ことは予算・納期の面からも現実的ではありません。対象となる一連の業務プロセスを詳細に整理し、「どこまではシステムが自動で処理し、どこからは人間が手作業や判断で行うのか」という明確な線引きを行います。
構築対象となる機能を一覧化し、「このプロジェクトではここを作ります」という合意を発注側と受注側（あるいは事業部門と情シス部門）の間でしっかりと交わすことが、業務要件定義の主たる目的です。
窓口担当者だけでなく実利用者（現場）を巻き込む必要性
業務要件定義を進める上で、プロジェクトが陥りがちな大きな落とし穴があります。それは、「プロジェクトの窓口担当者（発注側の窓口）だけと話して業務フローを決めてしまうこと」です。
多くの場合、窓口担当者や企画推進者は、日々のルーティンワークを直接行っている現場の実ユーザー（現場担当者）ではありません。現場のリアルな作業手順、イレギュラーな例外処理、Excel等で行われている暗黙知の工夫などを窓口担当者がすべて把握していることは稀です。
そのため、業務要件定義では実際にシステムを使う現場の関係者（実利用者）を積極的にヒアリングやワークショップに巻き込み、一次情報（現場の生の声と実態）を直接吸い上げることが不可欠となります。
業務要件定義の全体像と進め方
業務要件定義はどのようなステップで進められ、どのような成果物を作成するのでしょうか。まずはその全体像を確認します。
インプットから成果物への一連の流れ
業務要件定義は、前工程である「事業要件定義」のアウトプット（RFP、業務一覧、要求一覧など）をインプットとしてスタートします。
- 対象業務の目的・関係者の具体化（XYZ分析・CATWOE分析）：対象となる業務が「何のために行われ、誰が関わっているのか」を明確にします。
- 業務フロー分析（As-Is / To-Be）：現状の業務の流れを可視化し、無駄やボトルネックを解消した新しい業務プロセスを設計します。
- 成果物の作成と合意形成：新業務フローをもとに「機能一覧」「業務フロー図」「システム全体像（構成図）」を落とし込み、関係者全員で合意します。
業務要件定義で作成する3大成果物
業務要件定義で作成される主要な成果物は以下の3点です。これらは後続のシステム要件定義や開発工程における設計の根拠（エビデンス）となります。
| 成果物 | 概要・目的 | 主な活用先 |
|---|---|---|
| 業務フロー図 （As-Is / To-Be） |
業務の作業手順、担当者（スイムレーン）、データの入出力、システム操作のタイミングを時系列で視覚化した図。 | 現場との業務合意、マニュアル作成、機能抽出の元ネタ |
| 機能一覧 | システム化する機能（画面・バッチ・帳票・外部連携など）を網羅的にリスト化し、開発範囲を明文化した一覧表。 | システム要件定義、工数見積もり、スコープ管理、検収基準 |
| システム全体像 （構成図） |
主要なデータ（活動情報、見積、顧客情報など）の流れと、各システム（SFA, CRM, ERP等）との関係を1枚絵で俯瞰した図。 | ステークホルダー間の全体像把握、構築範囲（赤枠）の合意 |
対象業務の目的と関係者を浮き彫りにする「XYZ分析・CATWOE分析」
業務要件定義でいきなり業務フローを描き始める前に、まず行うべき重要なステップが「対象業務の目的と関係者の具体化」です。
作業の羅列だけでは事業目的と乖離するリスク
「どんな業務をやっているか（タスク内容）」だけに着目して要件定義を進めてしまうと、大きなリスクが生じます。現場の細かな作業手順だけをなぞってシステム化しようとすると、「そもそも何のためにやっているのか分からない無駄な作業」まで忠実にシステム化してしまったり、本来の事業目標から乖離したシステムが出来上がってしまうからです。
後からの大幅な仕様変更や「ちゃぶ台返し」を防ぐためにも、業務一覧の1業務ごとに「その業務が目指す目的」と「関わるステークホルダー」を定義する手法が有効です。
XYZ分析：業務の実行・手段・目的の因果関係を整える
XYZ分析とは、対象となる業務が最終的な目的にどう繋がっているかを論理的に確認する穴埋め形式の分析手法です。
XYZ分析では、業務を以下の3つの要素に分解して1つの文章にまとめます。
- X（実行・業務）：システム化対象となる業務や振る舞い（何を行うか）
- Y（手段）：業務を実行するための前提条件、インプット情報、ルールなど（どのように行うか）
- Z（目的）：その業務を通じて達成したい成果、得たい状態（なぜ行うのか）
これらを、「Z（目的）を達成するために、Y（手段）によって、X（業務）を行う」という構文に当てはめて検証します。
例えば、営業部門におけるパイプライン管理であれば、「期末の売上予想を高精度に行うために（Z: 目的）、統一ルールに則って（Y: 手段）、パイプラインを報告する（X: 業務）」という形で整理できます。
CATWOE分析：関係者と前提条件・価値観を浮き彫りにする
XYZ分析とセットで用いることで、業務を取り巻くステークホルダーや前提制約を多角的に把握できるフレームワークが「CATWOE（キャトゥ）分析」です。
CATWOE分析は、以下の6つの頭文字から構成されています。
- C（Customer: 受益者・影響者）：その業務によって恩恵を受ける人、あるいは損害・影響を受けるステークホルダー（例: 営業マネージャー、営業担当者）
- A（Actor: 実行者）：その業務に主体的に関わり実行する人（例: 営業担当者）
- T（Transformation: 変換プロセス）：分析対象のビジネス活動そのもの。XYZの「X（業務）」と一致（例: パイプライン報告）
- W（World View / Weltanschauung: 価値観）：その業務を実行する上での責任者の価値観・目指す姿。XYZの「Z（目的）」と一致（例: 高精度な売上予想をタイムリーに把握したい）
- O（Owner: 責任者）：実行者の上位に位置し、業務プロセスに責任を持つステークホルダー（例: 営業部長、組織長）
- E（Environment: 環境制約）：業務を実行する上での外部制約や前提条件（例: 報告ルールの統一基準、集計ロジックの存在）
3つのセルフチェック観点で矛盾と手戻りを防ぐ
XYZ分析とCATWOE分析を作成したら、関係者への確認前に以下の3つのセルフチェック観点で論理的な破綻がないかを検証します。
| チェック観点 | 検証内容 | 確認ポイント |
|---|---|---|
| ① 目的・価値観の整合 | 目的（Z）と価値観（W）に矛盾がないか。 価値観は「実行前の好ましくない状態」を否定し、「実行後の好ましい状態」を肯定しているか。 |
「売上予測がバラバラで不明（Before）」を否定し、「共通ルールで高精度に予測（After）」を肯定できているか |
| ② 実行業務の妥当性 | その業務（X/T）は目的（Z）の達成に本当に寄与しているか。 実行者（A）はその業務を無理なく実行可能か。 |
入力負荷が過大でないか、必要な前提データ（E）は揃っているか |
| ③ ステークホルダー価値 | 受益者（C）や責任者（O）にとって、この目的が達成されることは本当に喜ばしいことなのか。 | 一部の部門だけが得をして他部門の負担が増大していないか |
現状（As-Is）から新業務（To-Be）を描く「業務フロー分析」の手順
業務の目的と関係者が明確になったら、具体的な作業の流れを可視化する「業務フロー分析」へと進みます。
現状分析（As-Is）：隠れた業務ルールやボトルネックを可視化する
「新システムを導入するのだから、古い業務フロー（As-Is）を分析する時間は無駄ではないか。新しい業務フロー（To-Be）だけを考えればよいのではないか」という意見が聞かれることがあります。
しかし、現状分析を省略して新業務フローを設計すると、ほぼ確実に現場の運用で破綻します。現場には「実はこの取引先だけ手作業で特殊な承認を取っている」「月末にExcelマクロでデータを補正している」といった、ドキュメントに現れない隠れた業務ルールや例外処理が必ず存在するからです。
現状の業務フローを可視化することで、「人によって入力基準がバラバラ」「外出先から入力できず帰社後にまとめて入力しているため残業が増加している」といった現状の真のボトルネックや課題が浮き彫りになります。
業務フロー図を作成する3つの鉄則
業務フロー図を作成する際には、誰が見ても直感的に理解できるように以下の3つの鉄則を守ることが推奨されます。
- スイムレーンで登場人物・ツールを縦軸に配置する：営業担当、チームマネージャー、利用システム（Excel, SFAなど）を縦軸に並べ、左から右へ時系列で作業内容を配置します。
- 特記事項や注目ポイントは「吹き出し」で強調する：「通常木曜日までに入力」「人により基準が曖昧」など、注意点や課題は吹き出しを使って視覚的に目立たせます。
- 入出力（トリガーと成果物）を意識して組み立てる：業務フローは「入力（きっかけ・トリガー）」と「出力（成果物・次のアクション）」を繋ぐ一連の作業です。前後のつながりを明確に記述します。
目的達成シナリオと業務改善の4原則（ECRS）
現状の業務フロー（As-Is）が整理できたら、いよいよ新業務フロー（To-Be）の設計に入ります。ここで重要なのは、「現在の非効率な手作業をそのままデジタル化するのではない」ということです。
業務そのものをシンプルで合理的な姿に生まれ変わらせるために、業務改善の基本原則である「ECRS（イクルス）の4原則」を適用します。
| 原則 | 着眼点 | システム導入時の具体例 |
|---|---|---|
| Eliminate （排除） |
その業務や作業を完全になくせないか？ | 手動での二重入力の廃止、形式的な押印作業の撤廃、帰社してからの報告作業の排除（モバイル入力化） |
| Combine （結合） |
別々に行っている業務を1つにまとめられないか？ | 日々の活動報告とパイプライン（案件）進捗報告を1つの入力画面に統合 |
| Rearrange （交換・組み換え） |
順序や場所、担当者を入れ替えられないか？ | 案件確度の判定を「営業担当者の主観入力」から「システムによる活動実績スコアの自動計算」に入れ替え |
| Simplify （簡素化） |
作業手順をもっと単純・シンプルにできないか？ | 選択肢のプルダウン化、取引先情報の自動補完、入力必須項目の厳選 |
安易な「運用でカバー」の回避と代替オプション提示
要件定義の終盤で開発コストや納期が厳しくなった際、開発側や推進側から頻繁に出てくる言葉が「今回はシステム化を見送り、運用でカバーしましょう」という提案です。
もちろん、マスタデータの初期登録など最低限の手作業は存在しますが、コア業務に関わる処理を安易に「運用でカバー」とすることは極力回避すべきです。
定期的な手動タスクは想像以上に現場の負荷となり、担当者が異動すると手順が忘れ去られて形骸化したり、誰も使わなくなってシステム投資そのものが失敗に終わるリスクが非常に高いためです。
どうしても予算や工数が合わない場合は、「運用でカバー」の1択を押し付けるのではなく、「要件をこのように簡素化すればシステム化できます」「フェーズ2に分割して後から自動化しましょう」といった複数の代替オプションを提示することが誠実な進め方です。
新業務フロー（To-Be）の設計：手作業の排除と業務統合
ECRSの原則と運用カバー回避の視点を盛り込んで設計した、改善後の新業務フロー（To-Be）の例が以下です。
この新業務フローでは、従来のExcel管理からクラウドSFAへと移行し、以下の改善が組み込まれています。
- 外出先からのダイレクト入力：顧客訪問が終わった直後にスマートフォン等から活動情報を登録可能にし、帰社する無駄なプロセスを排除。
- 成約確度の自動計算：「課長職との面談」「提案書の提出」といった活動実績フラグと、CRM上のWeb接点データを連携させ、客観的なロジックで確度を自動判定（営業の標準化）。
- 業務の統合：活動報告と案件報告を1つの画面にまとめ、営業担当者の二重入力負担を大幅に削減。
業務フローから落とし込む「機能一覧」と「システム全体像」の作成
新業務フロー（To-Be）が完成したら、次はそのフローを実現するために必要な「機能一覧」と「システム全体像（構成図）」を作成します。
業務フローのシステム列から機能を漏れなく洗い出す
機能一覧をゼロから頭で考えて作ろうとすると、必ず機能の抜け漏れが発生します。最も確実な方法は、新業務フロー図の「システム列（スイムレーン）」に配置された処理を1つずつ抽出していくことです。
新業務フロー図のシステム列を見渡すと、「活動情報の入力画面」「成約確度の自動計算バッチ」「外部CRMからのデータ連携インターフェース」「報告内容の検索・承認画面」といった具体的な機能が自然と浮かび上がってきます。
機能一覧の必須項目と開発根拠としての合意形成
抽出した機能は、以下のような「機能一覧」のフォーマットにまとめて関係者と合意を形成します。
機能一覧を作成する際の主要な記載項目とポイントは以下の通りです。
- 対象業務：その機能がどの業務プロセスに対応しているかを明記（業務フローとの紐付け）。
- 機能種別：画面、バッチ（自動処理）、帳票、外部連携（I/F）などに分類。
- 機能名・概要：何を行う機能かを明確に記述。
- 備考・制限事項：「所属組織のデータのみ参照可能」「承認権限はマネージャー以上」など、セキュリティや制限事項をあらかじめ記載。
機能一覧は、プロジェクトにおける「開発対象の根拠（契約・スコープの基準）」となります。「言った・言わない」のトラブルを防ぐためにも、必ず発注側と受注側の双方で入念に確認・合意することが不可欠です。
システム全体像（構成図）の作成：1枚絵で他システム連携と構築範囲を合意する
業務フローや機能一覧は詳細な仕様を詰めるために不可欠ですが、細かすぎるドキュメントだけではプロジェクトの全体像が見えにくくなります。そこで作成するのが「システム全体像（1枚絵の構成図）」です。
システム全体像では、以下の要素を1枚の図に整理します。
- 主要データの流れ：活動情報、見積データ、Web接点ログ、売上実績データなどがどのシステム間を移動するか。
- 関連システムの関係性：SFA、CRM、ERP（基幹システム）、BI（レポーティングツール）などの接続構成。
- 構築対象範囲の明示（赤枠での囲い込み）：「今回のプロジェクトで新規構築・改修する範囲」を赤枠などで明確に囲み、どこまでが今回のスコープでどこからが既存・他社担当かを一目で合意できるようにします。
まとめ：業務要件定義で「現場が本当に動くシステム」を実現する
業務要件定義は、事業の目的を現場の実務プロセスへと翻訳し、「人とシステムの境界線（役割分担）」を明確にする極めて重要な工程です。
現状の作業をそのままデジタル化するのではなく、業務そのものをシンプルに磨き上げ、現場と開発側が「この範囲で進める」という合意を形成することが成功の鍵となります。
- 目的の明確化：タスクの洗い出しだけでなく、XYZ分析・CATWOE分析で「何のための業務か」「誰のための価値か」を定義する
- 現状の直視と新業務の設計：As-Isフローで現場の暗黙知を捉え、ECRS原則（排除・結合・交換・簡素化）でTo-Beフローをシンプルに再構築する
- 安易な運用カバーの回避：現場の形骸化を招く手作業の押し付けを避け、要件見直しを含む複数の選択肢を提示する
- 成果物の合意：業務フローのシステム列から機能一覧を抽出し、1枚のシステム全体像で構築範囲を全員で合意する
- 実利用者の巻き込み：窓口担当者だけでなく現場の一次情報を吸い上げ、現場が迷わず使える業務ルールを作り込む
まずは、現場の担当者と一緒に現在の業務フロー（As-Is）を1枚書き出し、どこに無駄やボトルネックがあるかを見つけることから、業務要件定義をスタートさせてみましょう。
要件定義の全体像や、失敗を防ぐ思考法、前後の重要フェーズ（事業要件定義・システム要件定義）については以下の記事で詳しく解説しています。
【DX人材育成・学習ロードマップ】
全社的な教育設計やご自身の学習計画の参考として、本サイトでは3つの役割に応じた学習ロードマップを公開しています。
経営層・管理職向け
DXの定義や必要性、組織変革を支えるスポンサーシップを最短で学びます。
一般社員向け（DXリテラシー標準 DSS-L準拠）
DXリテラシー標準(DSS-L)に準拠し、デジタル技術の基礎知識や変革マインドを身につけ、身近な業務改善や自社課題の発見へ主体的に関わる土台を作ります。
ビジネスアーキテクト・推進リーダー向け
既存事業の効率化から新規事業の開拓までをリードするため、プロジェクト推進法やチェンジマネジメント手法などを体得します。
コメント