会社情報
採用情報
お問い合わせ
Article

業務プロセス可視化で始めるDX：現状分析の手法を解説

高田晃太郎
業務プロセス可視化で始めるDX：現状分析の手法を解説

大規模なデジタル変革の成功率は依然として高くありません。複数の経営コンサルティング機関の調査では、全社変革の成功はおよそ30%前後にとどまり[1]、失敗の主要因として「現状の誤認」「優先順位の錯覚」「定量的根拠の欠落」が繰り返し挙げられます。一方で、プロセスマイニングを中心とする業務プロセス可視化の市場は年率40%超で拡大していると報告され[2]、改善活動にデータの裏付けを与える実装が広がっています[3]。つまり、DXの成否は「何を作るか」以前に「現状（As-Is）をどれだけ客観的に観察・計測できるか」に強く依存します。業務プロセス可視化（プロセスマイニング、タスクマイニング、VSMなど）をDXの最初の一手として位置づけることは、投資対効果を高める現実的な選択です。

成功する変革案件では、業務の実行ログを丹念に読み解き、滞留・反復・例外のパターンを定量化する姿勢が一貫しています。可視化は魔法ではありません。しかし、ボトルネックを隠さず、仮説の優先順位を揃え、投資判断の対話を生産的にするという意味で、DXの最初のレバーです。本稿では、CTO・エンジニアリーダーの皆さまに向けて、「業務プロセス可視化」による現状分析の基礎、代表的手法、実装の勘所、そして効果測定の設計を、コードと数式が読めるレベル感で整理します。

可視化の目的を定義する：DX文脈での「現状分析」

可視化の目的は図を作ることではなく、意思決定の質を上げることに尽きます[3]。現状分析は三つの問いに応えます。どのケースがどの順序で進み、どこで滞るのか。どのバリアント（実行経路の種類）がどれだけの頻度で発生するのか。そして標準手順との差異（コンフォーマンス＝手順適合度）がどれだけコストを生んでいるのか。この三点を押さえれば、改善施策は思いつきから脱し、効果予測と事後検証が可能になります。

開発組織に引きつけて言えば、PRのリードタイム、レビューのスループット、リリースの失敗率、障害の検知から復旧までの所要時間など、SREの世界で磨かれてきた運用指標はそのまま業務プロセスにも適用できます。重要なのは、プロセスを「人の努力」ではなく「イベントの連なり」として捉えることです。イベントとは、case_id（案件ID）、activity（処理名）、タイムスタンプ、resource（人やロボット）を持つ最小単位の記録で、これが揃えばどのツールでも可視化が成り立ちます。

イベントログの最小スキーマと抽出の出発点

イベントログは最終的に case_id、activity、event_time、resource を備えます[4]。既存の業務システムにイベントが明示されていない場合でも、トランザクション履歴や状態遷移テーブルから導出可能です。例えば受注処理なら、受注作成、与信承認、在庫引当、出荷確定、請求発行がアクティビティ候補になります。以下はRDBからイベントログを整形する素朴な例です。

-- PostgreSQL: 状態遷移からイベントログを生成
SELECT 
  o.order_id     AS case_id,
  s.state_name   AS activity,
  h.changed_at   AS event_time,
  h.changed_by   AS resource
FROM order_state_history h
JOIN orders o       ON o.id = h.order_id
JOIN order_states s ON s.id = h.state_id
WHERE h.changed_at BETWEEN :from AND :to
ORDER BY case_id, event_time;

この粒度が揃えば、後段の分析はツールに依存しません。まずは過半のケースを説明できるアクティビティ集合に収束させ、残りの長い裾野は次のイテレーションで扱うと割り切る方が、実務では前進が速くなります。

可視化が変える会話：責任追及からフロー改善へ

ダッシュボードは人を裁くための鏡ではなく、フローを直すための顕微鏡です。誰のミスかではなく、どこで仕事がたまり、なぜ手戻りが生じるのかという構造に矛先を向けるために、個人名ではなく役割やキューで集約する設計が有効です。心理的安全性を守る匿名化と、改善の因果を追える十分な粒度の両立がポイントになります。実務では、個人特定を伴うデータは権限管理と閲覧ログを厳格にし、公開用ビューは役割集約にする運用がよく機能します。

手法の使い分け：プロセスマイニング、VSM、タスクマイニング

プロセスマイニングは、イベントログから自動でフローを再構成し、頻出経路と例外、ボトルネックを可視化する手法です[5]。標準フローが存在しない、あるいは現場で手順が多様化している領域ではとりわけ威力を発揮します。タスクマイニングは、デスクトップ操作の計測でクリックレベルのボトルネックを抽出します。これは手作業の反復が多いバックオフィスやBPOで有効で、RPAやAI活用のユースケース特定や正当化にも用いられます[6]。バリューストリームマッピング（VSM）は、エンドツーエンドの価値の流れを可視化し、加工時間と待ち時間を区別して全体効率を高めます。たとえば、プロセスマイニングで工程内の再作業ループを検出し、タスクマイニングでそのループの人手作業を短縮し、VSMで全体の滞留を削るという重ね方が実務では現実的です。

OSSの pm4py を用いれば、RDBから抽出したCSVを短時間でフロー図にできます。以下はインポートからコンフォーマンスチェックまでの最小例です。

# Python 3.10+
import pandas as pd
from pm4py.objects.log.util import dataframe_utils
from pm4py.algo.discovery.alpha import algorithm as alpha_miner
from pm4py.algo.conformance.tokenreplay import algorithm as token_replay
from pm4py.objects.conversion.log import converter as log_converter

# イベントログの読み込み
df = pd.read_csv("event_log.csv")  # columns: case_id, activity, event_time, resource
df = dataframe_utils.convert_timestamp_columns_in_df(df)

# EventLogへ変換
log = log_converter.apply(df, parameters={
    log_converter.Variants.TO_EVENT_LOG.value.Parameters.CASE_ID_KEY: "case_id",
    log_converter.Variants.TO_EVENT_LOG.value.Parameters.TIMESTAMP_KEY: "event_time",
    log_converter.Variants.TO_EVENT_LOG.value.Parameters.ACTIVITY_KEY: "activity"
})

# プロセスモデルの発見（Alpha Miner）
net, im, fm = alpha_miner.apply(log)

# トークンリプレイによるコンフォーマンス
replay_results = token_replay.apply(log, net, im, fm)
fitness = sum([r[3] for r in replay_results]) / len(replay_results)
print(f"Conformance fitness: {fitness:.2f}")

コンフォーマンスのフィットネスが低い場合、標準手順の設計そのものが実態に合っていないか、例外処理が過剰か、入力データの品質に揺らぎがある可能性を検討します。加えて、バリューストリームの観点から、加工時間と待ち時間を分けて眺めると投資の優先順位が見えます。プロセスサイクル効率（PCE）は Value-added time / Lead time で定義され、案件全体の流れを太くするか、特定工程の待ちを薄くするかの選択を支えます。なお実務では、Alpha MinerだけでなくHeuristics/Inductive Minerの併用も選択肢です。

リードタイム分布と再作業の定量化

単一の平均値ではボトルネックを見落とします。分布とバリアントを分けて眺め、再作業ループの回数や往復の割合を定量化すると、現場の感覚と経営の期待を接続できます。以下はBigQueryでケースごとのリードタイムと往復回数を概算する例です。

-- BigQuery: ケースのリードタイムと往復（例: 承認→差戻し→再申請）
WITH seq AS (
  SELECT 
    case_id,
    activity,
    event_time,
    LEAD(activity) OVER (PARTITION BY case_id ORDER BY event_time) AS next_act
  FROM `project.dataset.event_log`
), loops AS (
  SELECT case_id, COUNTIF(activity = '承認' AND next_act = '差戻し') AS rework
  FROM seq GROUP BY case_id
), span AS (
  SELECT case_id,
         TIMESTAMP_DIFF(MAX(event_time), MIN(event_time), MINUTE) AS lead_time_min
  FROM `project.dataset.event_log`
  GROUP BY case_id)
SELECT s.case_id, s.lead_time_min, l.rework
FROM span s JOIN loops l USING(case_id);

このような集計から、例えば「P95のリードタイムを20%短縮する」といった分位点ベースの目標を置き、再作業が多いサブフローに絞って施策を当てると、投資の効率が上がります。

データ基盤と実装：スキーマ、鮮度、品質の勘所

プロセス分析はETLの質で決まります。最初の一歩は、ケースIDの定義を曖昧にしないことです。案件、注文、申請、インシデントなど、価値の単位に沿ってユニークに決めます。次に、アクティビティの命名規約を整え、同義語を集約します。最後に、タイムスタンプのタイムゾーンと一意性を確保し、イベントの順序性が壊れないようにします。実装は既存のデータウェアハウスと相性が良く、dbtなどの変換レイヤを用いると、スキーマのバージョニングとテストが容易になります。

以下はdbtでイベントログをマテリアライズする例です。ローグレードの生データを正規化し、列名と型を強制します。

-- models/event_log.sql
{{ config(materialized='incremental', unique_key='event_id') }}
SELECT 
  CAST(event_id AS STRING)  AS event_id,
  CAST(order_id AS STRING)  AS case_id,
  CAST(activity AS STRING)  AS activity,
  TIMESTAMP(event_time)     AS event_time,
  CAST(actor AS STRING)     AS resource
FROM {{ source('raw', 'order_events') }}
{% if is_incremental() %}
WHERE event_time > (SELECT MAX(event_time) FROM {{ this }})
{% endif %}

品質保証には、鮮度（新しいレコードがいつまでに到着するべきか）、完全性（イベントの欠落率）、一貫性（順序の逆転や重複）の3点が効きます。テストをSQLで自動化しておくと、ダッシュボードが静かに劣化する事態を防げます。

-- 重複イベントの検出（dbt testとして）
SELECT event_id, COUNT(*)
FROM {{ ref('event_log') }}
GROUP BY event_id
HAVING COUNT(*) > 1;

アプリケーション側の計測も、可視化の質を左右します。OpenTelemetryのログ/トレースを流用するのも手ですが、業務文脈では「ケースIDの継承」を厳密にすることが肝心です。以下は業務イベントの最小JSON例です。

{
  "event_id": "evt_20250301_000123",
  "case_id": "ORDER_98765",
  "activity": "与信承認",
  "event_time": "2025-03-01T10:15:00Z",
  "resource": "user:finance_03",
  "attrs": {"channel": "web", "amount": 128000}
}

このフォーマットをキューに積み、ストリーム処理でスキーマ検証とPIIマスキングを施してからDWHへ着地させると、後段の集計が安定します。開発チームの定例では、計測イベントの追加・変更を必ずレビュー対象にし、スキーマの差分を可視化する運用を習慣化すると、長期にわたり分析資産が腐りません（スキーマドリフトの抑制）。

パフォーマンスとコスト：更新間隔とストレージ設計

更新間隔は意思決定のリズムに合わせます。日次の業務なら日次バッチで十分ですが、フルフィルメントやカスタマーサポートでは15分間隔の増分更新が有効です。ストレージはコールドとホットを分け、詳細イベントはコールドに、直近の要約テーブルはホットに置くと、クエリコストと応答速度のバランスが取れます。実務では、直近90日のイベントをホットに、残りをパーティション化したコールドに追いやり、クエリは要約テーブルを既定とする設計が扱いやすいと感じます。

効果測定とROI：経営と現場をつなぐ指標設計

可視化の価値は、指標が意思決定に寄与したかで測ります。プロセスのKPIは、フロー効率、スループット、再作業率、例外比率、SLA遵守率などが核になります。ここで重要なのは、平均値ではなく分位点と割合を併用すること、そして「改善の対象集団と対照集団を分ける実験設計」をできる範囲で取り入れることです。たとえば、特定の部署だけに新しいチェックリストを導入し、その前後でP95リードタイムと再作業率の差分を測る差分の差分が役に立ちます。

次のSQLは、施策導入前後と対象/対照で指標を並べる素朴な例です。

-- 差分の差分：対象(1)/対照(0) × 導入前後
WITH base AS (
  SELECT case_id, dept_group AS treated, event_time, activity
  FROM proc.event_log
), period AS (
  SELECT *, CASE WHEN event_time < TIMESTAMP('2025-04-01') THEN 0 ELSE 1 END AS after
  FROM base
), agg AS (
  SELECT 
    treated,
    after,
    APPROX_QUANTILES(TIMESTAMP_DIFF(MAX(event_time), MIN(event_time), MINUTE), 100)[OFFSET(95)] AS p95_lead_min,
    AVG(CASE WHEN activity = '再申請' THEN 1 ELSE 0 END) AS rework_rate
  FROM period
  GROUP BY treated, after
)
SELECT * FROM agg;

ROIの算定は、短縮できた時間を原価と機会利益に変換し、導入・運用コストと比較します。具体例として、対象ケースのP95が120分から96分に縮み、月間2万件に効いたと仮定し、時間価値を1分あたり100円と置くと、月次で約4,800万円相当の効果が見積もれます。ここにライセンス・開発・運用の総費用を差し引き、回収期間や内部収益率を算出すると、経営会議の対話がスムーズになります。重要なのは、見積もりの前提（分位点、件数、時間価値）をダッシュボード上に明示し、前提が変われば効果も変わると透明に示すことです[3]。

最後に、メトリクスの乱立を防ぐために、北極星指標と健康指標を分けておくと運用が楽になります。前者はP95リードタイムのように一貫して改善を追う指標、後者はデータの鮮度や欠落率のように分析基盤そのものの健全性を見張る指標です。両者を同じ画面で監視できれば、可視化による行動変容が継続的に回り続けます。

ケーススタディの型：スコープを絞り、反復で広げる

最初から全社横断で完璧を狙うと、計測と調整に終始して成果が遠のきます。成功している組織は、まず一つの価値流（例えば受注から入金まで）にスコープを絞り、代表的なアクティビティで過半のケースを覆い、分位点で改善を確認してから周辺に広げています。スコープ外の要求はバックログに集め、四半期ごとの見直しで順番に拾う。この地味な運用が、結果的に最短距離になります。

まとめ：観察から始め、小さく速く回す

DXの第一歩は、派手な新機能ではなく、観察の制度設計です。case_id、activity、タイムスタンプという最小構成のイベントログに業務の現実を落とし、頻出の実行経路と例外、再作業ループを定量で掴む。そこにプロセスマイニング、タスクマイニング、VSMを状況に応じて重ね、P95や割合で指標を設計し、対象と対照を分けて効果を確かめる。こうした地道な流れが、投資と成果の対話を健全にし、現場の負担を減らしながら変革を前進させます。

まずは一つの価値流を選び、イベントログの抽出と最小の可視化から始めませんか。翌月の経営会議でP95の変化を一緒に見られるところまでを最小のマイルストーンに置けば、チームは動きやすくなります。観察は、次の一手を静かに教えてくれます。そこから先は、皆さんの組織に最適な反復の設計です。着手時の負担を下げるために、スキーマとダッシュボードの雛形（テンプレート）から始める方法も有効です。次の四半期、どのフローを軽くしましょうか。

参考文献

  1. Boston Consulting Group. Companies Can Flip the Odds of Success in Digital Transformations from 30% to 80% (2020-10-29). https://www.bcg.com/press/29october2020-companies-can-flip-the-odds-of-success-in-digital-transformations-from-30-to-80
  2. Global Market Insights. Process Mining Market Size Report. https://www.gminsights.com/ja/industry-analysis/process-mining-market
  3. TechTarget SearchERP. Benefits of using process mining. https://www.techtarget.com/searchERP/feature/Benefits-of-using-process-mining
  4. KPMG Japan. プロセスマイニングにおけるイベントログの基礎（取引ID・処理ステップ・処理順序）. https://kpmg.com/jp/ja/home/insights/2019/07/eventlog-process-mining.html
  5. 情報処理学会 デジタルプラクティス. プロセスマイニングによる改善の流れ（収集・可視化・分析・改善）. https://www.ipsj.or.jp/dp/contents/publication/52/S1304-U01.html
  6. Gartner. Task mining is a technique… (Doc ID: 4995631). https://www.gartner.com/en/documents/4995631