情シスがDX案件で最初にやるBPO（業務プロセス）見直しの進め方

この記事の結論: BeekleがDX案件で最初にやるのはシステム選定ではなくBPO（既存業務プロセス）に問題がないかの確認です。二重入力／例外運用／手戻り／属人化／KPI欠如の5サインで業務の構造的問題を洗い出し、「悪い業務をシステムで高速・正確に自動化する」事故を防ぎます。

システム化より先にBPOを疑う

「DXのご相談をいただきました。生成AIで業務効率化したいのですが」――Beekleが受託開発でこういった相談を受けたとき、まず最初にやるのはシステムの設計ではなくBPO（既存業務プロセス）の確認です。情シス担当者の方も、経営層から「DXやれ」と降りてきたときに、システム選定や見積もり依頼に走る前に、業務プロセスそのものに改善余地がないかを見直すことを強くおすすめします。

本記事は、情シス向けDXシリーズのうち、BPO見直しに特化した実践記事です。全体像は情シスのためのDX進め方完全ガイドを先に読むと位置づけが分かりやすくなります。

なぜシステム化より先に業務プロセスを見るのか

業務プロセスに構造的な問題があるまま、それをシステム化すると何が起きるか。シンプルに言うと「悪い業務プロセスを高速・正確に自動化する」ことになります。

悪い業務をシステム化する事故の典型例

たとえば、ある業務で「同じ情報を3つのシステムに二重入力している」状態があったとします。これをそのままシステム化すると、3つのシステムへ自動連携するインターフェースを作ることになります。一見、入力作業は減って効率化したように見えますが、根本問題（なぜ3つのシステムに同じ情報が必要なのか）は解消されていません。むしろ、システム連携の保守コストが新しく発生し、トータルコストが増えるケースすらあります。

本来は「3つのシステムのうちどれかをやめる」「マスタを一本化する」という業務プロセス自体の見直しが先にあるべきで、その後にシステム化が続きます。順序が逆転すると、現場の負担は変わらず、むしろシステムに合わせた追加作業（システム入力のための手作業）が増えることもあります。

「現場が反発するDX」の正体

DX導入後に現場から「使いにくい」「前のやり方の方が良かった」という声が上がるケースの多くは、BPOに問題がある状態でシステム化を進めたことが原因です。現場担当者は無意識に「悪い業務だから手作業で例外対応していた」のに、それを正確に自動化されると例外対応の余地が消え、業務が回らなくなります。詳しい失敗構造はDX・システム開発で失敗する典型5パターンと「作ったのに使われないシステム」を防ぐ要件絞り込み術を参照してください。

BPOの問題を見抜く5つのサイン

業務プロセスに構造的な問題があるとき、現場では次のようなサインが現れます。情シス担当者が現場ヒアリングを行うときのチェックリストとして使えます。

サイン1: 二重入力

同じ情報を複数のシステム（または紙）に入力している状態です。Excel から基幹システムへ、基幹システムから別の管理ツールへ、と同じデータが何度も転記されているケース。情シスの目で見ると「マスタが分散していて統合されていない」ことが背景にあります。

システム化を考える前に、まずマスタの一本化を検討します。これだけで二重入力の半分以上が消えることもあります。

サイン2: 例外運用が常態化

標準フローに載らない手順が頻繁に発生し、特定の人しか分からない状態です。「Aさんが休みのときはBさんがこうやる」「月末だけ手順が違う」のような暗黙運用が増えていれば、業務プロセス自体が複雑化しすぎているサインです。

システム化する前に、例外運用を標準フローに統合するか、明示的に切り出す判断が必要です。例外をすべて自動化しようとすると、システムが複雑化して保守不能になります。

サイン3: 業務の手戻りが頻繁

誰も「正しい状態」を定義できておらず、後工程で「これじゃない」と差し戻しが起きている状態です。業務の責任範囲と完了条件が曖昧なときに発生します。

システム化する前に業務の責任範囲と完了条件を再定義する必要があります。これが曖昧なままシステム化すると、システム上は「処理完了」になっているのに後工程で差し戻しが続く、という事態になります。

サイン4: 属人化

その人が休むと業務が止まる状態です。手順書がない、あっても更新されていない、特定のExcelマクロが秘伝になっている、などのパターン。情シスの目で見ると「業務知識がドキュメント化されていない」ことが背景にあります。

システム化と並行して業務知識のドキュメント化が必要です。属人化したままシステム化すると、その人がプロジェクトから抜けた途端に要件が分からなくなり、開発が止まります。

サイン5: 業務の成果を数値で測れない

「速いのか遅いのか」「合っているのか間違っているのか」が分からない状態です。KPIがない、あっても測定されていない、結果が共有されていない、などのパターン。これがあると、DX後の効果測定もできません。

システム化の前に業務のKPIを定義することが必要です。KPIなしでDXすると、リリース後に「効果があったのか」を経営層に説明できず、追加投資の判断もできなくなります。

BPO見直しでシステム化の範囲が縮小する

5つのサインに該当する業務を見直すと、結果としてシステム化が必要な範囲が縮小することがよくあります。「全部入りで作るDX」が「一部だけ作って残りはプロセス改善で済むDX」に変わると、予算も期間も削減できます。

業務改善で解消できる範囲を切り分ける

BPO見直しを行いながら、各業務について次の3区分に振り分けます。

• 業務プロセス自体を直せば解消する: マスタ統合・手順統一・責任範囲再定義など、システム化なしで解決
• 業務プロセス改善＋簡単なシステム支援で解消する: 既存ツール（Google Sheets・Notion等）の活用や、ノーコードで解消
• 本格的なシステム化が必要: スクラッチ開発／既製パッケージ導入で対応

3つ目の「本格的なシステム化」だけが、実際に開発会社へ発注すべき範囲です。最初にここを切り分けると、見積もりの噛み合いやすさが大きく変わります。

「やらない」の決断が情シスの仕事

BPO見直しの過程で、各部門から「ついでにこの業務もシステム化してほしい」という要望が次々に出てきます。これをすべて拾うと、後段でスコープクリープが起きてプロジェクトが破綻します。情シス担当者は経営層と一緒に「今やる／後でやる／やらない」の3分類を先に決める必要があります。優先順位付けの手法はスコープ管理「FM法」の使い方を参照してください。

情シスが現場と一緒にやるBPO棚卸しの進め方

BPO見直しは、情シスが机上で完結する作業ではなく、現場と一緒に進めるプロセスです。Beekleが受託開発の入り口で実践している進め方を、情シス担当者が自社で動かせる形に翻訳します。

ステップ1: 主要業務プロセスのリストアップ

まず自社の主要業務プロセスをリストアップします。経理・営業・受発注・在庫・人事・カスタマーサポートなど、業務領域ごとにプロセス単位で書き出します。各プロセスについて「どのシステムを使っているか」「誰が責任者か」「月にどれくらい時間がかかるか」を3列で記入します。

ステップ2: 5つのサインでスクリーニング

リストアップしたプロセスについて、本記事で挙げた5つのサイン（二重入力／例外運用／手戻り／属人化／KPI欠如）でスクリーニングします。サインに該当する数が多いほど、BPO見直しの優先度が高い業務です。

ステップ3: 現場担当者へのヒアリング

優先度の高い業務について、現場担当者にヒアリングします。「実際にどう動いているか」「想定と違う点はあるか」「困っていることは何か」を聞き、サインの裏付けを取ります。マニュアル通りに動いていることはほとんどないのが実態なので、ヒアリングなしには本当の業務プロセスは分かりません。

ステップ4: As-Is（現状）の業務フロー可視化

ヒアリング結果を業務フロー図（スイムレーン図）に落とし込みます。図にすることで関係者の頭の中のイメージが照合可能になり、「ここが違う」「これが抜けている」が次々に出てきます。Beekleでは無料の業務フロー可視化ツールを提供していて、現場ヒアリングと同時に図を更新できます。

ステップ5: 業務改善の優先度を経営と握る

As-Is が見えたら、経営層と一緒に「業務プロセス自体を直す範囲」「システム化する範囲」「やらない範囲」を決めます。ここで決まったスコープが、ベンダー選定・発注の前提条件になります。

まとめ｜BPO見直しはDXの起点

本記事の主張をまとめます。

• システム化より先にBPO（業務プロセス）に問題がないかを確認するのが、DXの正しい起点
• 業務プロセスに問題があるままシステム化すると「悪い業務を高速・正確に自動化する」事故になる
• BPOの問題を見抜くサインは5つ: 二重入力／例外運用常態化／手戻り頻発／属人化／KPI欠如
• BPO見直しでシステム化の範囲が縮小することが多い。業務改善で解消できる範囲を先に切り分ける
• 「やらない」の決断は情シスと経営層の責任。FM法で「今やる／後でやる／やらない」を握る
• BPO棚卸しは机上ではなく現場ヒアリングと業務フロー可視化を伴う。業務フロー可視化ツールが使える

BPO見直しが終わったら、次のステップは「ToBe（改善後の業務フロー）の再設計」です。お客様が当初描いていたToBeが微妙だったときに、As-Isから書き直す判断軸については、姉妹記事で詳しく解説します。