この記事の要点
- 【結論】業務分析は「聞く→描く→比べる→決める」の4局面を、SIPOC・BPMN・ECRSという3つの型で回すのが合理的なルートです。属人的な「勘の可視化」ではなく、標準的な記法と検証プロセスを踏むことで、AI導入・BPR・システム刷新の設計品質が2〜3倍変わることが期待できます。
- 【重要ポイント1】現場ヒアリングは「Input/Process/Output/例外/数値」の5点セットで聞く。1業務あたり60〜90分、事前準備30分、書き起こし60分が実務標準です。
- 【重要ポイント2】業務フロー化はBPMN 2.0を第一候補にする。フローチャートは初動用、BPMNは業務プロセスの正本用、UMLアクティビティ図はシステム設計連携用と役割を分けます。
- 【重要ポイント3】As-Is/To-Beは「乖離の大きい上位20%の業務」に絞る。ECRS(Eliminate/Combine/Rearrange/Simplify)の順で改善案を組み立てるとムダな作業を最小化できます。
- 【対象読者】業務改革・DX推進・システム刷新・AI導入・BPO化を担当する実務担当者、業務コンサルタント、育成責任者。
目次
- 業務分析とは何か?全体像はどう捉えるべきか?
- 現場ヒアリングの型はどう組み立てるか?
- 業務フロー化のツールと使い分けはどうすべきか?
- As-Is/To-Beの整理はどう進めるか?
- 業務分析でよくある失敗5パターンと回避策は?
- 業務分析を成功させる実践チェックリストは?
- FAQ(よくある質問)
業務分析とは何か?全体像はどう捉えるべきか?
結論:業務分析とは「業務を要素に分解し、Input・Process・Output・関係者・数値の観点で構造化して、意思決定に耐えるレベルで可視化する行為」です。全体像は「調査計画→ヒアリング→フロー化→As-Is/To-Be→打ち手決定」の5局面で回します。
業務分析の定義と目的
業務分析(Business Analysis)は、経済産業省「デジタルスキル標準(DSS)」(2024年改訂版)のビジネスアーキテクト領域で定義される中核スキルの1つで、「業務の目的・構造・情報・関係者を明らかにし、変革の起点となる知識を作る行為」と位置付けられています。BPR(Business Process Reengineering)、DX、SaaS導入、AI・RPA適用、BPO化、M&A後のPMI、いずれの局面でも業務分析が起点になります。
McKinsey・BCG・ベインといった戦略ファームでは、これを「業務のデコンストラクション(分解と再構成)」と呼び、変革プロジェクトの最初の2〜4週間をここに投下します。IPA「DX白書」(2026年版)の調査でも、DX成功企業の78%が「業務分析にプロジェクト工数の15〜25%を投下している」と回答している一方、失敗企業は5%未満に留まります。
全体像を掴む5局面のフレーム
業務分析は以下の5局面で構成されます。
| 局面 | 目的 | 標準工数 | 主な成果物 |
|---|---|---|---|
| 1. 調査計画 | スコープと粒度の合意 | 3〜5営業日 | 業務一覧、ヒアリング計画書 |
| 2. 現場ヒアリング | 実態把握とギャップ検出 | 10〜20営業日 | ヒアリング議事録、業務カタログ |
| 3. 業務フロー化 | 標準記法での可視化 | 5〜10営業日 | BPMN図、SIPOC表 |
| 4. As-Is/To-Be整理 | 現状と目標状態の対比 | 5〜10営業日 | ギャップ分析表、改善マップ |
| 5. 打ち手決定 | 変革施策の合意形成 | 3〜5営業日 | 改善施策一覧、ロードマップ |
Ballistaが支援したコンサル業界・IT企業の育成プロジェクトでは、この5局面をおよそ6〜8週間で回す設計を標準にしています。局面をショートカットすると、後工程で「そもそもこの業務は何のためにあるのか」という原理原則の再検討が発生し、プロジェクトが停滞するのが構造的な失敗パターンです。
現場ヒアリングの型はどう組み立てるか?
結論:現場ヒアリングは「事前準備30分/実施60〜90分/書き起こし60分」を1セットとし、Input・Process・Output・例外・数値の5点セットで聞き切ります。属人的な「業務の勘」を、他者が再現できる知識に変換するのが目的です。
ステップ1:ヒアリング前の準備
ヒアリング成功の70%は準備で決まります。以下を用意します。
- 業務一覧(マスタ):組織図・職務分掌規程・システム画面・帳票類から一次情報として洗い出す。1部門あたり30〜80業務が標準的な粒度です。
- 仮説フロー:ヒアリング前に「たぶんこう動いているだろう」という仮説を作る。仮説がないヒアリングは「教えてください」の連発になり、時間と信頼を消費します。
- 質問リスト:業務ごとにInput/Process/Output/例外/数値の5観点で20〜30問を用意する。
- 記録役の準備:話者(インタビュアー)1名+記録役1名の2名体制が標準。1人で回すと質問の深掘りが浅くなります。
ステップ2:ヒアリング実施の5点セット
現場担当者に対して、以下の5観点を1業務ずつ聞き切ります。
- Input(入力):この業務は何が来たら始まるか?誰から?どんな形式で?頻度は?
- Process(処理):何をどの順で行うか?判断分岐は?システム操作は?
- Output(出力):完了時に何が出るか?誰に渡すか?どんな品質基準か?
- 例外(イレギュラー):正常フロー外のケースは何%あるか?何が起こると止まるか?
- 数値:件数/時間/エラー率/繰り返し頻度は?年間何時間かかっているか?
コンサル業界では、この5点セットを「SIPOC(Supplier/Input/Process/Output/Customer)」に例外と数値を加えた拡張版として使います。1業務あたり15〜20分、1セッション60〜90分で3〜5業務を扱うのが標準ペースです。
ステップ3:書き起こしと構造化
ヒアリング終了後、24時間以内に議事録を構造化します。フォーマットは以下です。
| 項目 | 記載内容 |
|---|---|
| 業務名 | 「見積書作成」など動詞+目的語で統一 |
| 頻度・件数 | 月30件/年360件など具体数値 |
| 所要時間 | 1件あたり30分、月合計15時間 |
| 使用システム | Salesforce、Excel、Outlookなど |
| 関係者 | 起票者、承認者、受領者を明記 |
| 判断ルール | 「金額100万円以上は部長承認」等の明文化 |
| 例外パターン | 出現頻度と対応方法 |
| 課題・不満 | 現場が感じている痛点 |
このフォーマットを守ることで、複数の分析者が並列でヒアリングしても、成果物の粒度と品質が揃います。
業務フロー化のツールと使い分けはどうすべきか?
結論:業務フロー化は「初動=フローチャート/正本=BPMN 2.0/システム連携=UMLアクティビティ図」の3層で使い分けます。目的とレビュー相手によって記法を選ばないと、後工程での翻訳コストが発生します。
3つの主要記法の使い分け
業務フロー化に使われる記法は数十種類ありますが、実務で押さえるべきは以下の3つです。
| 記法 | 適した用途 | 学習コスト | レビュー対象者 |
|---|---|---|---|
| フローチャート | 初動、現場レビュー | 低 | 業務担当者、現場管理職 |
| BPMN 2.0 | 業務プロセスの正本 | 中 | 業務・IT・経営層 |
| UMLアクティビティ図 | システム設計連携 | 中〜高 | エンジニア、SIer |
BPMN 2.0(Business Process Model and Notation) は、OMG(Object Management Group)が標準化した業務プロセス記法で、開始イベント・タスク・ゲートウェイ・終了イベント・レーン(担当者)・プール(組織)の要素で業務を表現します。ISO/IEC 19510として国際標準化されており、多くの業務系ツール(Signavio、Bizagi、Camunda、Miroなど)が対応しています。
ステップ4:フロー化の実務プロセス
- 粒度の定義(1〜2日):レベル1(部門横断・年数回)/レベル2(部門内・月次)/レベル3(担当者・日次)/レベル4(操作手順)の4段階を決めます。実務ではレベル2〜3を主軸にすると管理可能な粒度になります。
- ドラフト作成(1業務あたり2〜4時間):ヒアリング議事録をもとに、まずは手書きまたは付箋でドラフトします。いきなりツールに描くと、微修正の心理的負担で「描き直しの躊躇」が生まれるためです。
- 標準記法への清書(1業務あたり1〜2時間):ドラフトが安定したら、BPMN対応ツールで清書します。Ballistaの実務では、初期はMiro/Lucidchartで速度重視、正本化フェーズでBizagi ModelerまたはSignavioに移行する運用が定着しています。
- 現場レビュー(1業務あたり30〜60分):担当者・上長・関係部門の3層でレビューします。ここで「実はこの分岐がある」「例外時は違う人が承認する」といった補正情報が5〜10%出るのが通常です。
- 正本化と版管理(継続):レビュー後の版をv1.0として社内Wikiに格納し、以後の変更は差分管理します。
テンプレート例:見積書作成業務のBPMN構成
以下は業務フロー化の骨格例です。
[開始イベント:営業から見積依頼受領]
↓
[タスク:仕様確認](営業部)
↓
[ゲートウェイ:金額100万円以上か?]
├─Yes→[タスク:部長承認取得]
└─No→[タスク:課長承認取得]
↓
[タスク:見積書PDF生成](Salesforce)
↓
[タスク:クライアント送付](Outlook)
↓
[終了イベント:見積書送付完了]
このレベルで50〜200業務が可視化されると、AI・RPA・SaaS導入・BPO化の設計が具体化できます。PMBOK Guide(Project Management Body of Knowledge、第7版)でも、業務プロセスの可視化を「変革プロジェクトの前提知識層」として位置付けています。
As-Is/To-Beの整理はどう進めるか?
結論:As-Is(現状)とTo-Be(理想)は「乖離の大きい上位20%の業務」に絞り、ECRS(Eliminate/Combine/Rearrange/Simplify)の順で改善案を組み立てます。全業務を平等に扱うと分析工数が発散し、意思決定が遅延します。
ステップ5:As-Isの整理
As-Is整理では、業務フロー図に以下の付加情報を重ねます。
- 数値の重ね書き:所要時間、件数、エラー率、担当者数を各タスクに紐付ける。
- ペインポイントの可視化:「ここで待ちが発生」「ここでミスが多い」「ここで属人化」の3種類を色分けする。
- システム依存の明示:どのタスクがどのシステムに依存しているかを注記。
- KPI連結:業務のOutputが最終的にどの経営KPI(売上・利益・顧客満足・リードタイム)に紐付くかを線でつなぐ。
ステップ6:To-Beの設計と改善優先度づけ
To-Beは、ECRSの4手法を順番に適用します。
| 手法 | 内容 | 期待効果 |
|---|---|---|
| Eliminate(排除) | そもそもやめられないか? | 工数40〜100%削減 |
| Combine(結合) | 複数業務を1つにまとめられないか? | 工数20〜40%削減 |
| Rearrange(順序変更) | 並列化・順序入替できないか? | リードタイム20〜50%短縮 |
| Simplify(簡素化) | 判断ルールや帳票を単純化できないか? | 工数10〜30%削減 |
Eliminateから検討する理由は、後段のCombine・Rearrange・Simplifyに投じた工数が、排除できる業務では丸ごと無駄になるためです。McKinsey Operations Practice の推奨手順でも、「まずやめる。次に減らす。最後に直す」の順序が徹底されています。
改善優先度マトリクスの活用
改善候補が20〜50個出た段階で、以下の2軸マトリクスで優先度を決めます。
- 縦軸:インパクト(削減時間・エラー減少・顧客満足向上)
- 横軸:実行難易度(システム改修・組織変更・投資額)
インパクト大×難易度低の象限(Quick Win)から着手し、90日以内に3〜5件のクイックウィンを可視化するのが、変革プロジェクトを止めない鉄則です。
業務分析でよくある失敗5パターンと回避策は?
結論:業務分析の失敗は「粒度」「主観」「合意」「工数」「継続」の5領域に集中します。事前に失敗パターンを知っておくだけで、プロジェクト成功率が体感で2倍以上変わることが期待できます。
失敗1:粒度が揃わない
- 症状:ある業務は5行、別の業務は50行のフローが並存する。
- 原因:粒度定義を最初に決めていない。
- 回避策:「レベル2〜3を標準粒度」と初日に文書で合意する。逸脱した成果物はレビューで差し戻す運用を敷きます。
失敗2:担当者の主観が入り込む
- 症状:「本来はこうあるべき」という理想論と、実際の運用が混ざる。
- 原因:As-IsとTo-Beを分離せずにヒアリングしている。
- 回避策:ヒアリング冒頭で「今回は今の実態のみを聞く。改善案は後日別セッションで扱う」と宣言します。
失敗3:関係者の合意が取れない
- 症状:レビュー段階で「うちの部門はそんな流れではない」と反発される。
- 原因:1部門1人ヒアリングで済ませている。
- 回避策:同一業務について、実務担当者・管理職・関連部門の3層でヒアリングする。3層の証言が食い違う箇所こそ「業務が壊れているサイン」です。
失敗4:分析工数が予算を超過する
- 症状:全業務を平等に深掘りして、8週間の予定が16週間になる。
- 原因:優先度なく全業務を扱っている。
- 回避策:業務一覧を作った段階で「経営インパクト×変革対象」の2軸でスクリーニングし、対象業務を全体の20〜30%に絞ります。
失敗5:分析結果が使われずに死蔵する
- 症状:立派な業務フロー図が完成したが、半年後に誰も見ていない。
- 原因:成果物のオーナーと更新プロセスが定義されていない。
- 回避策:業務ごとに「プロセスオーナー(責任者)」を任命し、四半期ごとの棚卸しを制度化します。BPM(Business Process Management)の考え方では、業務フローは「作って終わり」ではなく「常に生きている資産」として運用されるべきです。
業務分析を成功させる実践チェックリストは?
結論:業務分析の成功可否は、開始前・実施中・完了後の3局面それぞれのチェック項目で決まります。以下のチェックリストを開始前に配布し、週次レビューで進捗確認するのが実務標準です。
開始前チェックリスト
- [ ] スコープ(対象部門・対象業務範囲)が文書で合意されている
- [ ] 粒度定義(レベル2〜3が標準など)が明記されている
- [ ] プロジェクトオーナー(意思決定者)が任命されている
- [ ] ヒアリング対象者(30〜50名程度)のリストと日程が確定している
- [ ] 使用する記法(BPMN 2.0など)とツール(Miro、Bizagi等)が決まっている
- [ ] 業務一覧マスタが一次情報から作成されている
実施中チェックリスト
- [ ] ヒアリング1件あたり議事録が24時間以内に構造化されている
- [ ] 週次で「進捗・課題・気づき」の3点報告が回っている
- [ ] 3層レビュー(担当・管理職・関連部門)が実施されている
- [ ] 数値(件数・所要時間・エラー率)が全業務に付与されている
- [ ] 例外パターンが業務ごとに1つ以上抽出されている
完了後チェックリスト
- [ ] As-Is/To-Beが分離して整理されている
- [ ] 改善候補が優先度マトリクスで序列化されている
- [ ] クイックウィン(Quick Win)が3〜5件明確になっている
- [ ] プロセスオーナーが業務ごとに任命されている
- [ ] 成果物が社内Wikiまたは業務管理ツールに格納されている
- [ ] 90日後・180日後の見直しタイミングがカレンダー登録されている
このチェックリストを開始前に配布し、週次1回・完了時1回の合計3回の点検を回すことで、業務分析の品質が体系的に担保されます。
FAQ(よくある質問)
Q1:業務分析にかかる期間はどの程度か?
A1:部門規模と目的で変わりますが、実務標準では1部門50〜80業務で6〜8週間、全社300業務規模で3〜4か月が目安です。Ballistaの支援実績でも、全社BPRで最短10週間、標準14週間の設計が多く採用されています。短期化する最大レバーは「対象業務の絞り込み」で、全業務ではなく上位20〜30%に集中させると期間短縮が期待できます。
Q2:BPMNとフローチャートの違いは何か?
A2:BPMN 2.0は業務プロセス専用の国際標準記法(ISO/IEC 19510)で、担当者を示す「レーン」、判断分岐を示す「ゲートウェイ」、外部システム連携を示す「メッセージフロー」など、業務特有の要素を厳密に表現できます。フローチャートは汎用的で学習コストが低い反面、業務プロセスの正本としては表現力不足です。初動はフローチャート、正本化はBPMNという2段階運用が実務的です。
Q3:現場担当者の抵抗にどう対処すべきか?
A3:抵抗の8割は「監視・評価される不安」と「余計な仕事が増える懸念」に由来します。対処法は3つ。第一に、ヒアリング冒頭で「目的は個人評価ではなく業務改善」と明言する。第二に、経営層からの正式なキックオフメッセージを事前配布する。第三に、ヒアリング結果を担当者本人に返し「あなたの業務が可視化されて楽になる」体験を早期に作ることです。Ballistaの現場では、キックオフの丁寧さでヒアリング品質が2倍変わります。
Q4:業務分析に必要なスキルは何か?
A4:DSSではビジネスアーキテクト領域の必須スキルとして「業務プロセス設計」「ステークホルダーマネジメント」「構造化思考」「ドキュメンテーション」の4つが定義されています。実務で追加すべきは、BPMN 2.0の記法知識、ヒアリング設計力、Excel/SQLでの数値集計、そしてMiro/Lucidchart/Bizagi等のツール操作です。研修としては40〜80時間のカリキュラムで基礎力が身につきます。
Q5:業務分析の成果物例は何か?
A5:標準的な成果物は以下5点セットです。第一に業務一覧マスタ(Excel、50〜300行)、第二にBPMN業務フロー図(対象業務分)、第三にSIPOC表(Input・Process・Output・Supplier・Customerの整理)、第四にAs-Is/To-Beギャップ分析表、第五に改善施策優先度マトリクス。これに90日ロードマップと投資対効果試算を加えたものが、経営会議に提出できる完成形です。
参考文献・出典
- 経済産業省「デジタルスキル標準(DSS)」(2024年改訂版)https://www.meti.go.jp/policy/it_policy/jinzai/dss/
- IPA「DX白書」(2026年版)
- OMG「Business Process Model and Notation(BPMN)2.0 Specification」ISO/IEC 19510
- PMI「PMBOK Guide 第7版」
- McKinsey Operations Practice「Business Process Redesign」
- BCG「The Digital Path to Business Consulting」
- Ballista Inc.「コンサル業界BPR支援 実務ナレッジ」(2024-2026)
関連記事
この記事を書いた著者
Ballista Inc. 編集部
監修:中川貴登(Ballista代表取締役)
コンサルティングファーム・IT企業の業務分析/育成体系構築の実務経験を元に執筆。BPR・DX・PMI・AI導入プロジェクトで100件以上の業務分析支援実績。
ConStepについて
ConStepは、AI時代の上流人材育成プラットフォームです。コンサル業界の上流スキル(業務分析・課題解決・クライアントワーク)を、DSS準拠の体系でIT企業・事業会社の人材育成に転用します。業務分析の実践スキルを、講義+演習+現場適用の3段階カリキュラムで習得できます。
個別相談のご案内:貴社の業務分析・BPR体制構築について、無料相談を承っています。
個別相談予約 | ConStep講座の詳細を見る