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

システム導入前にやるべき現状業務フローの見直し方法

高田晃太郎
システム導入前にやるべき現状業務フローの見直し方法

国内外の調査でも、プロジェクト失敗の主要因として「要件定義の不十分」や「仕様変更の頻発」が繰り返し指摘されています[1,2]。とりわけ部門横断のCRM/SFAやSCM（CRM=顧客管理、SFA=営業支援、SCM=サプライチェーン管理）の領域では、全体構造を把握できていないと要件決定が難しいことも報告されています[3]。これらは導入直前のドタバタではなく、遥か手前の“見えていない業務フロー”に原因が潜むことを示唆します。公開事例や現場観察を重ねると、要件レビューよりも前段の現状把握に手戻りが集中しがちです。エンジニアは仕様から考えがちですが、コードが走る前に人とデータがどう動いているかを掴めていなければ、システムは現場の摩擦を増幅します。だからこそ、導入前に業務フローを再定義することが、最短で最大の効果を生む近道になります。ここでは、抽象論ではなく、データで現状を掘り起こし、意思決定可能なTo-Beを描き、システム要件へ落とし込むまでの道筋を、実装者の視点で具体的に解説します。

なぜ導入前に業務フローを見直すのか

新システムは魔法の箱ではありません。業務の歪みは、UIやAPIを介してそのまま拡大再生産されます。特に例外処理の扱いと責任の所在、そして移行期の二重運用は、導入後の混乱を決定づける三点です。現場では「承認は普段すぐ」と語られても、実データでは月末前に滞留が集中することが珍しくないように、言葉とデータがずれるのが常態です[4]。見直しは現場の知見を尊重しつつ、操作ログ、発注履歴、チケット遷移、メールやチャットのタイムスタンプまでを統合して、語られた業務ではなく実際に起きている業務を可視化する営みです。

あるB2B取引の与信プロセスでは、ヒアリング上の承認フローは二段階でしたが、実データを追うと営業部長の“事前スラック承認”が実質の三段目となり、平均して待ち時間を押し上げていました。導入済みのワークフローにその非公式ステップが吸い込まれ、ダブル承認が恒常化。負債はシステムのせいではなく、見直しを飛ばしたことに起因します。見直しは責任追及ではありません。意図せぬ迂回路を地図に起こし、廃止・標準化・自動化の対象を分類する作業です。

見直しがROIに直結するロジック

ROIは機能点ではなく処理時間×件数×失敗確率の積で効くのが実態です。承認を1クリック短縮するより、例外の再処理を半減させるほうが、総時間は大きく削れます。費用側では、導入工数よりも切替期間の二重運用コストが効くことが多く、ここを短縮する設計が投資対効果を押し上げます。見直しはその二つ、すなわち平常時の処理時間の削減と、切替時の摩擦最小化の両方に効くため、導入前の最優先タスクになります。なお、大規模プロジェクトでは予算・スケジュール超過が起こりやすいことは他分野でも繰り返し指摘されており、前提の不確実性を事前に潰す観点が重要です[7]。

As-Isの可視化：データ駆動の現状把握

As-Isは会議室で作る図ではなく、ログから再構成する現象学です[5]。ここでの「イベントログ」は、ケースID（案件識別子）、アクティビティ（起こった出来事）、タイムスタンプ（時刻）、担当者の4点を持つ記録を指します。まず、SaaSや社内システムを跨ぐ場合は共通のケースキーを設計し、粒度（たとえば週次）を揃えます。データから「最頻経路」と「例外分岐」を抽出し、ヒアリングで意味づけを整えるのが着地の形です。プロセスマイニング（業務の実データからプロセスを可視化する手法）の入門でも、この構造が基本になります[4,5]。

イベントログ抽出の最小実装

リレーショナルに散らばった操作履歴から、ケース単位の時系列を得る一例です。スキーマに依存しますが、軸は一貫してケースIDと時刻です。

-- 例: 受注案件のイベントログ抽出（PostgreSQL）
SELECT 
  o.order_id     AS case_id,
  e.event_name   AS activity,
  e.occurred_at  AS ts,
  u.display_name AS actor
FROM order_events e
JOIN orders o      ON o.id = e.order_id
LEFT JOIN users u  ON u.id = e.user_id
WHERE e.occurred_at BETWEEN date_trunc('month', now()) - interval '3 months'
                        AND now()
ORDER BY case_id, ts;

抽出後は、変種フロー（Variants: ケースごとの経路の違い）と滞留箇所を見ます。Pandasでボトルネックの粗粒度を掴む最小コードは次の通りです。

# 例: 変種フローと滞留分析（Python / pandas）
import pandas as pd

df = pd.read_csv('event_log.csv', parse_dates=['ts'])
seq = df.sort_values(['case_id','ts']).groupby('case_id')['activity'].apply(lambda s: ' > '.join(s))
variants = seq.value_counts().head(10)

lead = df.groupby('case_id')['ts'].agg(['min','max'])
lead['lead_hours'] = (lead['max'] - lead['min']).dt.total_seconds() / 3600

wait = df.sort_values(['case_id','ts'])
wait['next_ts'] = wait.groupby('case_id')['ts'].shift(-1)
wait['gap_h'] = (wait['next_ts'] - wait['ts']).dt.total_seconds() / 3600
bottleneck = wait.groupby('activity')['gap_h'].median().sort_values(ascending=False).head(5)

print(variants)
print(bottleneck)

チケット駆動の組織なら、JiraやLinearの遷移ログが実質の業務フローになります。JiraならJQLで一定期間のライフサイクルを素早く切り出せます。

// 例: JQLで遷移イベントを対象期間に絞る
project = OPS AND status CHANGED DURING (startOfMonth(-2), endOfMonth())

イベントログだけでは責任の所在が曖昧な場合は、RACIを薄く書いておきます（R=Responsible、A=Accountable、C=Consulted、I=Informed）。実務で使えるのは“ほどほどの明確さ”で、過度な網羅性は導入の遅延リスクになります。

# 例: RACIのミニマム（YAML）
approve_credit:
  SalesLead: R
  CreditTeam: A
  SalesOps: C
  Legal: I

この粒度でも、誰が最終責任者か、誰が相談先かが明確になり、例外処理の遅延がどこで生まれるかが見えてきます。現場ヒアリングはログと突き合わせます。語られたフローにログで裏付けが取れない場合、非公式なショートカットや三角承認が潜んでいる可能性が高いからです。

ケーススタディ：バックオフィスの与信審査

あるSaaS企業の与信では、営業、審査、法務の三者が絡み、月末に審査が集中していました。ログ分析で法務レビューに中央値で十数時間のギャップがあると判明し、実は資料の抜け漏れ補完依頼がスラック上で非構造に行われていたことが原因でした。資料リストをフォーム化し、提出不備をサーバサイドで同期検証するTo-Beへ置き換えると、審査リードタイムは明確に短縮し、月末の滞留も目に見えて減りました。ここで重要なのは、法務の稼働を増やさずに済んだという点です。業務フローの見直しは人を増やす前にできる最も堅実な投資です。

To-Be設計とギャップ分析：削る・任せる・自動化

To-Beの原則は、まず削る、次に任せる、最後に自動化です。削るとは、存在理由の薄いチェックを廃止することです。任せるとは、責任を明確に一手に集約すること、またはユーザーセルフサービス化で“待ち”を減らすことです。自動化とは、合意済みルールをシステムに埋め込むことです。この順序を逆にすると、無意味なチェックを高速自動化するという逆効果に陥ります。

設計では“仕様”の前に“ポリシー”を確定させます。ポリシーは「この条件なら人手を介さず承認」「この閾値を超えたらエスカレーション」「この例外は廃止」のような判断原理です。ポリシーが固まると、要件は自然に絞れます。例えば、与信スコアが一定以上かつ未払い履歴がない場合に自動承認、一定以下なら審査に回す。曖昧なままIF文をコードに落とすとデグレが続きますが、ポリシーとして合意されていれば、ルールエンジン（条件を設定で管理できる仕組み）でもワークフローでも、表現形式は後から選べます。

データ駆動の閾値設計

過去データから損益への寄与を推定し、閾値を決めます。Pythonで与信スコアと不払率の関係をざっくり確認し、誤拒否と誤許容の損失を比較すれば、合理的な境界が見えてきます。ここではコードではなく手続きが大切です。既存の被害額、代替獲得コスト、顧客生涯価値をテーブル化し、ポリシーの利益関数を合意します。

並行して、移行期の設計を前倒しで行います。ブルーグリーン（本番を2系統用意して切り替える方式）ではなく“段階的切替”になる現場が多い以上、二重運用のガイドとリスク受容方針がTo-Beの一部になります。メールテンプレート一枚、SOP一枚でも早く用意し、現場と“新旧が混在する日の仕事”をシミュレーションすることが、切替の混乱を最小化します。

サービス・ブループリントで接点を揃える

顧客や他部門とのインターフェースが多いプロセスでは、フロントとバックの断絶がボトルネックを生みます。サービス・ブループリント（顧客接点と裏側の動きを同一時間軸に並べる図）を軽量に用意し、顧客行動、フロントの行為、バックの処理、支援システムを同一時間軸に並べれば、手戻りの原因が視覚化されます。図がなければ、CSVでも十分です。顧客の到着イベントとバックエンドの処理着手の差分が、待ち時間の源泉であると一目で分かるからです[6]。

システム要件への落とし込みとROI算定

As-IsとTo-Beが見えたら、要件に落とし込みます。ここでのコツは、ユースケースの前に成果指標を先に書くことです。承認の中央値をX時間へ、例外の再処理率をY%へ、二重運用期間をZ週間へというふうに、導入後に反証可能なKPIを最初に合意します。ユースケースは、そのKPIに効くものだけに絞ります。さらに、手作業の引き継ぎ点を要件書の一等地に置きます。自動化の外側に残る仕事こそ、性能ボトルネックになりやすいからです。

実装上は、ルールの可変域を設定ファイルや管理UIに逃がし、永続スキーマの破壊的変更を避ける構造にします。ローンチ後の微調整を“開発なし”で回せるかどうかが、現場の体感価値を左右します。シンプルな条件なら、環境変数やコンフィグで十分です。もう一歩進めて、ルールをYAMLで宣言し、テスト可能にしておくと、運用の柔軟性が高まります。

# 例: ルールの宣言（YAML）
auto_approve:
  credit_score_min: 720
  max_outstanding: 0
  region_whitelist: ["JP","US"]
manual_review:
  credit_score_max: 719
  attach_required: ["id_doc","company_registry"]

ROIは導入前に近似でよいので算出します。稼働削減、リードタイム短縮、エラー再処理削減、機会損失回復を金額化し、初期費用と運用費用に対してネットで評価します。簡易な関数で計算できる形にしておくと、要件の優先順位づけが一気にクリアになります。

# 例: ROIの簡易計算（Python）
def roi(leadtime_hours_saved, hourly_cost, cases_per_month, rework_drop_rate, rework_cost_per_case, init_cost, monthly_run_cost, horizon_months=12):
    gain_time = leadtime_hours_saved * hourly_cost * cases_per_month * horizon_months
    gain_rework = rework_drop_rate * rework_cost_per_case * cases_per_month * horizon_months
    gain_total = gain_time + gain_rework
    cost_total = init_cost + monthly_run_cost * horizon_months
    return (gain_total - cost_total) / cost_total

print(roi(leadtime_hours_saved=1.2, hourly_cost=4000, cases_per_month=800,
          rework_drop_rate=0.12, rework_cost_per_case=6000,
          init_cost=12000000, monthly_run_cost=600000))

テスト計画も、要件確定と同時にドラフトします。パス/フェイルの条件をKPIに結びつけることで、現場が“成功”を具体的にイメージできるようになります。例えば「承認の中央値を48時間から30時間へ」というKPIなら、デプロイ後2週間のイベントログから中央値を算出し、差分を検証する手順を用意します。テレメトリや監査ログに必要なフィールドを先に決めておけば、観測不能というよくある失敗も避けられます。

移行と立ち上げ：二重運用を設計する

移行はプロジェクト最大のリスクです。二重運用は悪ではなく必要な緩衝材ですが、いつ何を止めるかが決まっていない二重運用は、終わりのないコストになります。フラグで新旧を切り替えられる設計にして、段階ごとに測る指標を定めます。問い合わせ件数、例外件数、承認リードタイム、ユーザーの操作ミス率など、選ぶ指標は現場の痛みに直結するものにします。これらはダッシュボードに可視化して、意思決定のタイミングを逃さないようにします。

よくある落とし穴と回避策

最も多い落とし穴は、ワークショップで描いた理想図をそのままシステムに焼き付けることです。現場は複線的に動きます。例外をルールに吸収できるのか、例外として残すのか、判断を先送りにしない仕組みが必要です。もう一つは、監査や法令遵守の文言をそのまま仕様に直訳することです。“保存”はどこに、どの粒度で、どの期間か、誰がアクセスできるのか、実装可能な形にまで分解しないと、運用で破綻します。最後に、ステークホルダーの期待管理を怠ることも致命的です。人は新しいシステムに自分の不便の解消を投影しがちです。To-Beと非対応範囲を早めに公開し、意図的に期待を調整するのが、プロジェクトを救います。

まとめ：導入は“地図”を描いてから歩く

システム導入は、新しい道具を持つことではなく、新しい動き方に組織を合わせることです。現状のAs-Isをデータで掘り起こし、削る・任せる・自動化の順でTo-Beを固め、KPIに沿って要件へ落とし込み、二重運用の出口まで先に決めておく。この一連の見直しができれば、導入は恐れる対象ではなく、効果を確実に取りにいく投資へと変わります。あなたの現場では、どの待ち時間が最も痛いでしょうか。今すぐ直せる“削る”はどれで、判断原理として合意すべき“ポリシー”は何でしょう。最初の一歩は、過去3カ月のイベントログを一つにまとめるところから始まります。手元のデータで十分です。地図が描ければ、正しい道順は自然と見えてきます。

参考文献

  1. 日経ビジネス電子版「プロジェクト失敗の理由、15年前から変わらず」2018年調査の紹介. https://business.nikkei.com/atcl/opinion/15/100753/030700005/
  2. 日経xTECH「スケジュールの遅延が発生した理由、『システムの仕様変更が相次いだ』が最多」. https://xtech.nikkei.com/atcl/nxt/column/18/00177/022100002/
  3. 日経ビジネス電子版「CRM/SFAやSCMは全体構造の把握なしに要件が決めづらい」. https://business.nikkei.com/atcl/opinion/15/100753/030700005/
  4. SMART STAGE「プロセスマイニングとは」. https://smart-stage.jp/blog/p50/
  5. プロセスマイニング・ジャパン「イベントログとは（案件ID・アクティビティ・タイムスタンプの要件）」. https://www.process-mining.jp/2020/07/20/intro-to-pm-7-eventlog/
  6. SEEDATA「サービス・ブループリントとは」. https://seedata.jp/blog-service-design-143/
  7. ITmedia オルタナティブ・ブログ「ITプロジェクトの予算超過に関する考察」. https://blogs.itmedia.co.jp/magic/2025/06/it_6.html