DX

業務分析とは?手法と進め方の5段階、システム化の前に決める範囲と成果物

業務分析とは?手法と進め方の5段階、システム化の前に決める範囲と成果物

業務分析は、現状の業務を作業単位に分け、業務量と流れを数字で押さえたうえで、問題の真因と改善やシステム化の範囲を決める作業です。本記事では、デジタル庁の標準ガイドライン(DS-100)が挙げる把握項目、IPAの「ユーザのための要件定義ガイド」が示す業務フローの考え方、石川県のBPR推進ハンドブックにある課題抽出の手順をもとに、業務分析の手法と進め方を5段階で整理します。業務改善やBPR、要件定義との違い、システム化してよい業務の判定基準、フローを描いて終わる失敗パターンまで扱います。

まとめ:業務分析はシステム化の前に「何をやめ、何を任せるか」を決める作業

業務分析の成果は、きれいな業務フロー図ではありません。どの作業に月何時間かかっているか、問題の真因は何か、どこをやめてどこをシステムに任せるかという判断の材料です。

進め方は5段階です。目的と対象を決め、現状の業務フローを作業単位で描き、なぜなぜ分析で真因まで掘り下げます。そのうえでECRSの観点で改善案を出し、実現できる改善後の姿と効果の測り方を決めます。組み合わせる手法は、ヒアリング・既存資料の突き合わせ・業務量調査・業務フロー図の4つです。

システム化を前提に始めると、システムを作らずに済む改善案を見落としかねません。件数が少ない業務やルールが固まっていない業務は、まず手順をそろえるほうが先です。分析の結果、システムを作らないと決めることも業務分析の立派な成果です。

業務分析とは:現状の業務を分解し、問題の真因と改善の範囲を決める作業

業務分析という言葉は、業務改善やBPR、要件定義と混ざって使われがちです。まず範囲を区切ります。

業務改善・BPR・要件定義との違いと、業務分析が受け持つ範囲

業務分析は「いまどうなっているか」と「なぜそうなっているか」を明らかにする工程です。その結果を使って手順を直すのが業務改善、組織や業務プロセスを根本から組み直すのがBPRです。BPRの考え方はBPRの意味と業務改善・BPMとの違いで詳しく扱っています。

取り組み 主な問い 主な成果物
業務分析 現状と問題の真因は何か 業務一覧、現状フロー、業務量、真因
業務改善 手順をどう直すか 改善後の手順、マニュアル
BPR 業務と組織をどう組み直すか 新しい業務プロセスと体制
要件定義 システムに何をさせるか 業務要件、機能要件の一覧

要件定義は業務分析の後工程です。業務分析で決めた改善後の業務を、システムが受け持つ機能に落とします。業務要件として何を書くかは業務要件定義の8つの記載項目を参照してください。

デジタル庁DS-100が挙げる業務の把握項目は範囲・流れ・量・体制・時期・場所

何を調べれば「現状を把握した」と言えるのか。公的な目安として、デジタル庁のデジタル・ガバメント推進標準ガイドライン(DS-100、2026年6月12日改定)があります。第3編第4章「現状の把握と分析」は、利用者・業務・データ・既存の情報システム・情報システム運用・関連調査の6区分を例として挙げています。

このうち業務の把握と分析の対象は、範囲、業務フロー、業務量、実施体制、実施時期・時間、実施場所などです。政府情報システム向けの文書ですが、民間でもそのまま点検表に使えます。フロー図だけ描いて業務量や時期を調べていなければ、把握はまだ半分です。

業務分析の手法:ヒアリング・資料調査・業務量調査・業務フロー図の組み合わせ

手法は単独では使いません。定性の情報と定量の情報を突き合わせて、聞き取りの思い込みを数字で正します。

業務一覧で分析対象を洗い出し、記載の粒度は「作業単位」にそろえる

最初に作るのは業務一覧です。部署で行っている業務を大分類から順に分け、誰が何をどの順番で行っているかを1行ずつ書き出します。洗い出しの書式や範囲の決め方は業務棚卸の工程にあたります。一覧の列の作り方と回答の集め方は業務棚卸のフォーマットと進め方で解説しています。

難しいのは粒度です。石川県のBPR推進ハンドブックは、「会議関連事務」のような業務単位では粗すぎて課題を特定できず、「書類を印刷する」「印鑑を押す」のような動作単位では細かすぎて全体が見えないとし、「開催通知作成」「会場準備」といった作業単位で書くよう勧めています。粒度がそろわない一覧は、後の業務量の集計でも比べられません。

ヒアリングと規程・マニュアルの突き合わせで現行業務の実態を拾う

ヒアリングは担当者に業務を説明してもらう手法です。聞き取りの内容は、本人が意識している手順に偏ります。月末だけ発生する作業や、前任者から口頭で引き継いだ例外対応は話に出てきにくいものです。

そこで、業務分掌規程や既存のマニュアル、帳票の実物と突き合わせます。IPAの要件定義ガイドにも、規程を使って現行業務を把握した事例が載っています。ただし、マニュアルが実態と一致しない会社は珍しくありません。食い違いが見つかった箇所こそ、属人化や手順のばらつきが起きている場所です。聞き取りの項目を整理するならシステム開発の発注前に準備するヒアリングシートの項目が使えます。

業務量調査は作業ごとの件数×1件あたりの処理時間で月間の工数を出す

業務量は、業務一覧の作業ごとに「月間件数×1件あたりの処理時間」で出します。処理時間は担当者の申告から調べ始めますが、主要な作業だけでも1〜2週間の実測による確認が必要です。申告は記憶に頼るため実測とずれることがあり、ずれの大きい作業ほど分析の当たりどころになります。

作業(例) 月間件数 1件の処理時間 月間工数
請求書の受付と内容確認 1,200件 4分 80時間
会計システムへの転記 1,200件 3分 60時間
差し戻しの連絡と再確認 90件 20分 30時間
月次の支払予定表の作成 1回 8時間 8時間

表は説明のための計算例です。件数の少ない差し戻しが30時間を占めるような偏りは、数字にしないと見えません。この例なら、転記の自動化より先に差し戻しの原因を潰すほうが効きます。

業務フロー図はBPMNか簡易記法か、読み手と目的で記法を選ぶ

業務フロー図は、担当者ごとのレーンに作業を並べ、分岐と書類・システムの受け渡しを描きます。標準の記法には、OMGが定めるBPMN(Business Process Model and Notation)2.0.2があります。イベント・ゲートウェイ・メッセージフローまで表せる反面、記号の数が多く、現場の担当者が読むには記号を覚える手間が必要です。業務フロー図を含め、業務の流れ・量・進捗・判断のどれを見える化するかで方法とツールを選ぶ考え方は、業務可視化とは?4つの対象と方法・ツールの選び方、見える化を続ける仕組みで整理しています。

現場と認識を合わせる段階なら、開始・終了、処理、判断、書類、システムの5種類程度の記号で足ります。石川県のハンドブックで使われているのも、この程度の種類に絞った凡例です。システム開発会社にそのまま渡す図や、ワークフロー製品に取り込む図はBPMNで描く、と使い分けると手戻りが減ります。フロー図の描き方と対象工程の選び方は業務フローのシステム化と対象工程の選び方で解説しています。

業務分析の進め方5段階:目的の設定から真因の特定、改善後の業務フローまで

石川県のハンドブックは、対象業務の選定、現状把握と可視化、課題抽出、改善策の検討、改善計画の策定、改善計画の実行という順番を示しています。ここでは業務分析が受け持つ前半を5段階に分けます。

手順1 目的と対象業務を決め、成果物を基準に分析の終わりを先に定義する

「残業を月20時間減らす」「請求処理を締め後3営業日で終える」のように、目的は数字で書きます。目的が「現状把握」のままだと、調べる範囲が際限なく広がります。

対象は全社ではなく、困りごとが大きく関係者が少ない業務から選びます。石川県のハンドブックも、困りごとを書き出して業務の負担と着手の難しさで評価し、着手しやすい業務から優先する手順を示しています。分析の終わりとして先に決めておくのは、「改善後の業務フローと効果の指標が決まった時点」です。

手順2 現状の業務フローを描き、通常処理と例外処理を分けて洗い出す

現状(As-Is)の業務フローは、通常処理から描きます。IPAのユーザのための要件定義ガイド 第2版は、月次の業務量の大半(例えば95%以上)を占める業務パターンを先に記載し、そのあとで例外処理と、キャンペーンのような不定期の特殊処理を洗い出すよう書いています。

例外処理を記載する際に書き添える項目は、発生頻度と影響度です。同じガイドは、例外処理の洗い出しの精度が以降のシステム開発の品質に大きく響くとしています。現状と理想の比べ方はAs Is / To Beの分析手順にまとめています。

手順3 なぜなぜ分析で問題から真因まで、事実に基づき3〜5回掘り下げる

石川県のハンドブックは、理想と現状の差を「問題」、その理由を「要因」、根本の原因を「真因」と呼び分けています。例えば「毎日2時間の残業」が問題なら、要因は業務量の偏りや突発作業で、真因は「業務プロセスと役割分担が標準化されていない」ことです。

掘り下げは「なぜ」を3〜5回が目安とされています。ハンドブックが挙げる真因の観点は、自分たちで制御できる要因か、推測でなく事実に基づくか、再発を生む構造か、流れ全体を止める原因か、の4つです。手順2の業務量の数字がここで効きます。手順の詳細はなぜなぜ分析の進め方と記入例を参照してください。

手順4 ECRSで改善案を出し、実現できるCan-Beに絞り込む

改善案は、なくせないか(Eliminate)、一緒にできないか(Combine)、順序を変えられないか(Rearrange)、簡単にできないか(Simplify)の順に考えます。システム化はSimplifyの手段の一つで、なくせる作業を先に消すのが順序です。

絞り込みでは、石川県のハンドブックが挙げる改善効果・影響範囲・初期費用・継続費用・実現可能性・改善までの期間で案を比べます。同じ資料は、制約を無視した理想(To-Be)より、実現可能な姿(Can-Be)を目指すよう勧めています。最初から全面の電子化を狙わず、業務の1割でも電子化・自動化する案から始める考え方です。

手順5 改善後の業務フローと効果の測り方を決め、要件定義に渡す

最後に、改善策を反映した改善後の業務フローを描き、効果をどの指標で測るかを決めます。石川県のハンドブックが例示する指標は、平均処理時間とその中央値、差戻し件数と再対応率、平均待ち時間、削減額と削減率、5段階の満足度です。手順1で書いた目的と同じ指標を選びます。

改善前の値は手順2の業務量調査で取れています。業務一覧・現状と改善後のフロー・業務量・真因・効果の指標の5点がそろえば、要件定義の入力として渡せます。

業務分析をシステム化につなげる判断基準と、システム化を見送る場面

ここからは本稿の判断です。業務分析をシステム化の準備と位置づける会社は多いのですが、分析の結果としてシステムを作らない判断も同じ重みで扱うべきです。

システム化してよい業務は件数・ルールの固さ・例外率の3条件で判定

手順2〜3の結果を使い、次の3条件がそろう業務をシステム化の候補にします。月間の件数が多く工数の合計が大きいこと。判断のルールが文書にでき、担当者によって結果が変わらないこと。例外処理の割合が低く、通常処理で業務量の大半を占めること。3条件がそろった業務は、目的・対象範囲・費用・期間を決めるシステム企画に進みます。構想と計画の立て方はシステム企画とは?構想と計画の2段階で決める範囲、企画書の項目と要件定義への渡し方で解説しています。

逆に、月に数件しか発生しない業務や、判断が担当者の経験に依存している業務は見送ります。前者は開発と保守の費用が削減工数に見合わず、後者はルールを決めないまま作ると、例外対応の分岐が増えて仕様が固まりません。見送った業務は、まずマニュアルとチェックリストで手順をそろえます。属人化した業務のほどき方は脱属人化を進める仕組み化と標準化で扱っています。

失敗パターン:現状のフローを清書して、今の業務の電子化で終わる

多い失敗は、現状の業務フローを丁寧に描き上げた時点で分析を終えてしまう形です。IPAの要件定義ガイドも、現状業務を中心に業務フローを作成したが、作成が終わったときには現状とそう変わりのないフローになっていたプロジェクトは少なくないと指摘しています。紙の申請書がPDFのフォームに変わっただけ、という結果になります。

防ぎ方は2つあります。フロー図の横に問題点・課題の欄を設け、作業ごとに対応づけながら描くこと。もう1つは、フローを描いた担当者以外も含めて読み合わせることです。同じガイドは、分析した当人以外が内容を把握できない状態を問題として挙げ、関係者全員でのウォークスルーを勧めています。システム部門や外部の開発会社だけで描くと現行システム前提の図になりやすいため、利用部門が主体になるべきだとも書いています。

社内で進める範囲と外部に頼む範囲、発注前にそろえておく成果物

業務一覧、業務量調査、現状の業務フローの作成は、業務を知る社内の担当者が進めるほうが速く、正確です。外部の力が要るのは、真因が部署をまたぐ場合や、改善後の業務をどのシステムでどう実現するかを決める段階です。パッケージで足りるか、個別開発が要るか、既存システムとどう連携するかは、費用の見積もりと一緒に判断します。

発注前に業務一覧・業務量・現状フロー・真因の4点がそろっていれば、開発会社との打ち合わせで最初から要件の議論に入れる状態です。現状業務の分析からシステム化の範囲と要件の整理までを外部と詰めたい場合は、一創のDXコンサルティングでご相談いただけます。効率化の手法全体を見渡したい場合は業務効率化の進め方と手法も参考になります。

業務分析の手法と進め方、システム化との関係に関するよくある質問

業務分析の進め方やツール選びについて、よく寄せられる疑問に答えます。

業務分析にはどのくらいの期間がかかりますか?

1部署の1業務に絞れば、業務一覧とヒアリングに1〜2週間、業務量の実測に1〜2週間、真因の特定と改善案の整理に1〜2週間が目安です。これらを合わせた全体の所要期間の目安は、1〜2か月です。月末や四半期末にだけ発生する作業がある業務は、その時期を調査期間に含めないと例外処理を取りこぼします。全社を一度に分析しようとすると半年を超えやすく、その間に業務そのものが変わってしまいます。

業務分析に使えるフレームワークは何がありますか?

工程ごとに使い分けます。洗い出しにはMECE(漏れなくダブりなく)とロジックツリー、流れの記述にはBPMNなどの業務フロー記法、真因の特定にはなぜなぜ分析、改善案の発想にはECRS、現状と理想の差の整理にはAs-Is/To-Beが合います。フレームワークを並べて全部使う必要はありません。業務一覧、業務フロー、なぜなぜ分析、ECRSの4つで、本記事の5段階はひととおり回せます。

業務分析とプロセスマイニングはどう使い分けますか?

プロセスマイニングは、システムの操作ログから実際の業務の流れと所要時間を自動で描く手法です。ERPやワークフローなど、業務がシステム上で完結している範囲では、ヒアリングより正確な実態が取れます。一方、紙や電話、メールで進む作業はログに残りません。システム化前の業務分析ではヒアリングと業務量調査が主で、システム導入後の改善段階でプロセスマイニングを足す順序が現実的です。詳しくはプロセスマイニングの仕組みと導入判断で解説しています。

業務分析は外部のコンサルタントに任せるべきですか?

全部を任せる必要はありません。業務一覧や業務量の調査は、業務を知る社内の担当者が行うほうが正確で、費用もかかりません。外部に頼む価値があるのは、部署をまたぐ問題で社内の利害を調整しにくい場合と、改善後の業務をどのシステムで実現するかを判断する段階です。社内で作った成果物を外部に見てもらう形にすると、費用を抑えながら見落としを減らせます。

業務分析の結果は要件定義でどう使いますか?

業務分析で決めた改善後の業務フローが、要件定義の出発点になります。フロー上の作業のうち、システムが受け持つものが機能要件の候補です。業務量調査の件数は性能や容量の要件に、例外処理の一覧は画面や処理の分岐の要件につながります。IPAの要件定義ガイドが業務の現状把握をビジネス要求定義の章で扱っているのも、この順序だからです。ガイドの読み方はIPA要件定義ガイドの要点で紹介しています。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.05 テックブログ Linuxカーネルの脆弱性CVE-2026-98432:修正版の見分け方とnftablesの緩和策
  2. 2026.11.05 テックブログ SMBCコンシューマーファイナンスの情報漏洩:最大32万人の対象確認と保証会社に集まる情報
  3. 2026.11.03 テックブログ クラブツーリズム不正アクセス:約432万件の対象確認と偽メールの見分け方・流出検知の設計
  4. 2026.10.29 テックブログ ソニー生命の情報漏洩38.5万件|ログインできない理由、再開状況と窓口の電話番号
  5. 2026.11.05 コラム 給与支払報告書とは?令和8年分の提出期限・書き方と源泉徴収票みなし提出への対応

RELATED POSTS 関連記事

目次