情シスのためのDX進め方完全ガイド｜BPO見直しとAs-Is／To-Beから再設計する実践プロセス

この記事の結論: Beekleは中堅企業のDX案件で、教科書通りの「ビジョン → 現状可視化 → ロードマップ」ではなく、「BPO（既存業務プロセス）の問題確認 → As-Is/To-Be可視化 → ユーザーストーリー → FM法で優先度判定 → 費用対効果で逆算」の順で進めることを推奨しています。「悪い業務を高速・正確に自動化するDX」を防ぐ入口になります。

はじめに｜「DXやれ」と降ってきた情シスへ

「経営層からDXやれと言われた」「DX推進担当に任命された」――しかし、何から手をつけるか具体的に教えてくれる人がいない。情シス1〜3名の中堅企業で、こうした状況に放り込まれる方は多いはずです。

世の中のDX解説記事を読むと「ビジョンを描いて、現状を可視化して、ロードマップを作って…」と教科書的な進め方が並びますが、いざ自社で進めようとすると「現状の何を見るのか」「どんなToBeが正解なのか」が分からないまま手が止まります。

本記事では、Beekleが受託開発の現場で実践している「BPO（既存業務プロセス）に問題がないかから始める → As-Is／To-Beを可視化する → ユーザーシナリオで動機を握る → FM法でスコープクリープを止める → エンジニアリング視点で費用対効果から逆算する」という、シンプルだが効果が出る進め方を、情シス目線で整理します。教科書通りでないのは、Beekleが実際の案件で「教科書通りでは効果が出なかった」経験から組み直した順序だからです。

DX失敗の典型｜「新しいシステムを作る」が起点になっている

多くのDXプロジェクトが失敗するパターンは、ほぼ共通しています。「経営層が新しいシステム（または生成AI）を入れたい」と言う → ベンダーに「DXのご提案」を依頼する → 機能てんこ盛りの提案書が出てくる → 予算と期間が膨らむ → 完成しても現場が使わない。詳しい5パターンの失敗構造はDX・システム開発で失敗する典型5パターンを参照してください。

この失敗の根本は、「新しいシステムを作る」ことがDXの起点になっていることです。本来は「既存の業務プロセスに問題がある／改善余地がある」が起点で、その解決策の一つとしてシステム化があるべきなのに、順番が逆転しています。

順番が逆転すると、システム化が目的になり、既存の悪い業務プロセスをそのまま自動化してしまうことになります。これが「作ったのに使われないシステム」「現場が反発するDX」「経営層が効果を説明できないDX」の正体です。

Beekleが実践するDXの起点｜BPO（既存業務プロセス）に問題がないか

Beekleが受託開発の入り口でまず行うのは、お客様のBPO（既存業務プロセス）に問題がないかの確認です。「DXのご相談」をいただいたとしても、いきなりシステムの設計に入るのではなく、業務プロセスそのものに改善余地がないかを最初に見ます。

BPOの問題を見抜くサイン

業務プロセスに構造的な問題があるとき、現場では次のようなサインが現れます。

• 同じ情報を複数のシステム（または紙）に入力する二重入力が発生している
• 例外運用（標準フローに載らない手順）が常態化していて、特定の人しか分からない
• 業務の手戻りが頻繁にあり、誰も「正しい状態」を定義できていない
• 属人化していて、その人が休むと業務が止まる
• 業務の成果を数値で測れていない（速いのか遅いのか、合っているのか間違っているのかが分からない）

これらのサインがあるBPOをそのままシステム化すると、「悪い業務プロセスを高速・正確に自動化する」ことになります。これでは現場の負担は変わらず、むしろシステムに合わせた追加作業（システム入力のための手作業）が増えるケースすらあります。

システム化より先にプロセス自体を直す選択肢

BPOに問題があると分かったとき、Beekleがまず提案するのは「業務プロセス自体を直してから、システムで支援する」順序です。具体的には、(1) 二重入力の発生源を特定して片方をなくす、(2) 例外運用を標準フローに統合するか明示的に切り出す、(3) 業務の責任範囲を再定義して属人化を解消する、(4) 業務の成果をKPIで測れる状態にする、を行います。

この段階で、システム化が必要な範囲が大幅に縮小することがあります。「全部入りで作るDX」が「一部だけ作って残りはプロセス改善で済むDX」に変わると、予算も期間も削減できます。

As-Is／To-Beの可視化が要件定義の核心

BPOの確認と並行して、Beekleが必ず行うのがAs-Is（現状の業務フロー）とTo-Be（改善後の業務フロー）の可視化です。これは要件定義の中で最も時間をかける工程で、ここの精度がプロジェクト全体の成否を決めます。

なぜAs-Is／To-Beを可視化するか

言葉や箇条書きで「現状はこうで、こう変えたい」と説明されても、関係者の頭の中のイメージは一致しません。経営層が思っている「現状」と、現場担当者が思っている「現状」と、情シスが思っている「現状」は、それぞれ微妙にズレています。

このズレを残したまま要件定義を進めると、開発が始まってから「想定と違う」「現場ではこうやっている」が次々に発覚し、手戻りで予算と納期が破綻します。詳しい現状分析の進め方はシステム開発の現状分析（Assessment）も参照してください。

図にすると認識のズレが見える

業務フローをスイムレーン図（縦軸＝担当者、横軸＝時系列）で描くと、関係者が「ここが違う」「これが抜けている」「実際はこの後に承認がある」と次々に指摘してくれます。図にすることで初めて、頭の中のイメージが照合可能になるのです。

Beekleでは無料の業務フロー可視化ツールでAs-Is／To-Beを並べて描けるようにしています。会員登録不要・ブラウザ完結で、現場ヒアリングと同時に図を更新できます。

ユーザーシナリオで「誰が・何を・なぜ」を握る

As-Is／To-Beの図ができたら、次に必須なのがユーザーシナリオ（ユーザーストーリー）の言語化です。図には業務の流れが描かれていても、「なぜその業務が必要なのか」「誰のために何を実現したいのか」という動機までは載りません。動機がズレたままシステム化に進むと、現場で使われない機能が量産されます。

ユーザーストーリーの3要素で動機を1行に

ユーザーシナリオは「As a〜（誰が）／I want to〜（何を）／So that〜（なぜ）」の3要素で1〜3行に書きます。日本語にすると「〜として、〜したい。なぜなら〜」です。

例: 「倉庫管理者として、在庫が閾値を下回った段階でアラートを受けたい。なぜなら、発注リードタイムを確保して欠品を防ぐため」。この3要素が揃うと、開発側は「なぜ」から技術選択肢を逆算できます（例: アラートタイミングが業務上シビアならpush通知、緩いならメールで十分）。詳しい書き方と業界別の実例はユーザーストーリー書き方完全ガイド、たたき台作りには無料のユーザーストーリー作成ツールを参照してください。

動機を握ると「作らない」判断が楽になる

ユーザーシナリオで動機を可視化すると、後段のスコープ判断が一気に楽になります。「あれば便利だから入れる」が出てきたとき、「誰の・どんな業務上の動機を満たすのか」を聞けば、動機が空っぽな機能をその場で却下できるからです。動機の言語化は、後述するFM法でのスコープ管理を機能させる前提条件でもあります。

製造業DX案件の実例｜お客様のToBeをAs-Isから書き直した

Beekleが実際に経験した製造業DXの案件で、印象的だったのは「お客様が当初考えていたToBeが微妙だったので、As-Isから書き直して再設計した」ケースです。社名や具体的な数値は守秘義務のため伏せますが、プロセスは抽象化して共有できます。

当初のToBe案の何が微妙だったか

このお客様は、すでに「DX後はこんな業務フローにしたい」というToBe案を持っていました。経営層が中心に描いた、いわば「理想形」です。しかし、Beekleがその案を見ると、いくつかの違和感がありました。

• 現場が今やっている例外運用がToBeに反映されていない（標準フローしか想定していない）
• 業務の責任範囲が曖昧で、誰がそのToBeを実行するのかが決まっていない
• システムで実現する場合の費用対効果が読みにくく、投資判断ができない構造

As-Isに戻って書き直した

そこで、いきなりToBeを実装するのではなく、一度As-Isに戻って書き直すことから始めました。現場担当者にヒアリングして、実際の業務フローを詳細に描き出し、例外運用や属人化している箇所を全部可視化しました。

すると、当初のToBeで想定されていた業務改善のいくつかは、システム化しなくてもプロセス変更だけで実現可能であること、逆にToBeに含まれていなかった業務こそシステム化の効果が大きいこと、が見えてきました。

エンジニアリング視点で費用対効果を提案した

As-Isの全体像が見えた段階で、Beekleはエンジニアリングの視点で「この業務はシステム化すると◯◯のコストがかかるが、◯◯の効果がある」「この業務はシステム化より業務改善の方が効果が大きい」と費用対効果を試算しました。

その結果、お客様のToBe案を一部採用しつつ、一部は変更し、一部は削るという再設計案で合意できました。当初想定の半分程度のシステム化範囲で、業務改善とシステム化を組み合わせた現実的なDXとして稼働しています。

このプロセスは、Beekleが受託開発の他の案件（業界は伏せます）でも繰り返し有効に機能しています。「お客様が考えたToBeをそのまま実装する」のではなく、「As-Isを正確に可視化し、エンジニアリング視点で費用対効果を逆算してToBeを再設計する」のが、効果の出るDXの順序だとBeekleは考えています。

エンジニアリングが分かる人がBPOを見て提案する重要性

Beekleが強調したいのは、業務プロセスを評価する人にエンジニアリングの知識が必要という点です。コンサルだけでも、現場担当者だけでもなく、システム化したときに何にいくらかかるかを試算できる人が、業務プロセスを見ながら費用対効果を判断する必要があります。

エンジニアリング視点がないと費用対効果が読めない

業務改善の専門家は「この業務をこう変えれば改善する」と提案できますが、システム化したときの実装コスト（画面数・データ連携・例外処理・テスト工数）を読むのは困難です。一方、エンジニアだけだと業務の意味（その業務がどんなビジネス価値を生むか）が読めません。

結果として、業務改善コンサルが描いたToBeをそのままエンジニアに渡すと「システム化すると想定の3倍の工数がかかる」と判明し、予算が破綻するパターンが起きます。逆に、エンジニアが業務を知らずに作ると「機能は動くが現場で使われない」システムができあがります。

Beekleの進め方｜エンジニアが業務を見て費用対効果を試算する

Beekleでは、要件定義フェーズからエンジニアリングの知識がある人が現場の業務プロセスを見ることを徹底しています。As-Is／To-Be の可視化に同席し、それぞれの業務をシステム化したときの実装コストと効果を即時に試算しながら、何を作って何を作らないかを決めていきます。

これは「機能の優先順位付け」とも違います。FM法（要件をビジネス価値・現場で使えるか・技術コストの3軸で評価する手法）を使うと近い判断ができますが、それよりさらに上流で「そもそもシステム化するか、業務改善で済ませるか」の判断を含めます。詳しいFM法の使い方はスコープ管理「FM法」の使い方を、無料で試せるツールはスコープ管理ツールを参照してください。

FM法で「作る／作らない」を決めてスコープクリープを防ぐ

BPO見直しとAs-Is／To-Be可視化、ユーザーシナリオの言語化が終わって、いよいよシステム化の範囲を決める段階で、Beekleが必ず通すのがFM法（ファンクショナリティ・マトリクス）でのスコープ管理です。これがないと、要件定義の終盤から開発中盤にかけて「ついでにこの機能も」「あれば便利だから」と機能が無限に膨らむスコープクリープでプロジェクトが破綻します。

スコープクリープがDX失敗の主因

DXプロジェクトでは、各部門のヒアリングで出た要望を全部RFPに入れて見積もりが当初想定の3倍に膨らむ、という典型パターンがあります。「DXはまたとない機会」と捉えられやすく、各部門が「今のうちに自部門の課題も入れておきたい」と要望を盛り込むためです。発注側に「優先順位を絞り込む役」がいないと、要件は無限に膨らみます。

結果として、(1) 予算と期間が破綻する、(2) 全部入りで作って使われない機能が大量に残る、(3) 「全部やりたいが予算は半分」で揉める、という失敗が起きます。詳しくはDX・システム開発で失敗する典型5パターンを参照してください。

FM法の3軸で要件を「作る／後回し／作らない」に振り分ける

FM法は、書籍『システムを作らせる技術』で紹介されている要件評価フレームワークで、各要件を次の3軸で評価して採否を決めます。

• ビジネス価値（★1〜3）: その機能を作ると、どれだけビジネスに貢献するか。売上が上がるか、コストが下がるか
• 現場で使えるか（★1〜3）: その機能を、現場が実際に使いこなせるか。ITリテラシー・業務環境に合うか
• 技術コスト（低／中／高）: 実装にどれくらい工数とリスクがかかるか

判定の基本: (1) どれか1軸でも最低評価なら作らない（使われないか無謀）、(2) 高評価が2つ以上あれば作る、(3) その他は後回し。「3軸とも高い」要件だけ最初に作り、それ以外を引き算します。

FM法の最大の効果は「使われない機能」「無謀な機能」を客観基準で弾けること。実調査でも開発した機能の8割は使われていないと言われており、ここを切るだけで予算と納期は大きく改善します。手法の詳細はスコープ管理「FM法」の使い方、無料で試せるのはスコープ管理ツールを参照してください。

「作らない」を経営の責任で先に決める

FM法でスコープクリープを止めるには、「今やる／後でやる／やらない」の3分類を経営の責任で先に決めるのが要点です。各部門の要望をすべて拾い続けると、現場には平等に見えますが、結果として誰の業務も中途半端にしか改善されません。情シス担当者が経営層と一緒にFM法のスコアリングを行い、「これは作らない」を明文化することが、DXを成功に導く最大のレバーです。

シンプルなデザインで小さく作って育てる

FM法で絞り込んだ「作る」要件で最初のリリースを作り、現場で使われ始めてから周辺機能を追加していきます。多機能なシステムほど現場のITリテラシーの限界を超えて使われなくなる傾向があるので、最初のリリースは「サービスが成立する最小限の機能」に絞るのが原則です。詳しくは「作ったのに使われないシステム」を防ぐ要件絞り込み術とシステム開発を段階的に進める方法を参照してください。

AI時代こそ要件定義の重要度が上がる

2024〜2026年にかけて、生成AI（ChatGPT、Claude、GitHub Copilot、Cursor、Claude Codeなど）がコードを機能単位で書けるようになり、エンジニアの役割は「AIが書いたコードをレビューして仕上げる」に変わりつつあります。詳しくは生成AI駆動開発（AIファースト開発）とはを参照してください。

コードが速く書けても、間違った要件なら間違ったシステムが速く出来上がるだけ

「AIで開発が速くなるなら、要件定義は短くていい」と考える方もいますが、Beekleの実感は逆です。AIでコード生成が速くなったからこそ、要件定義の精度がそのまま結果を決めます。間違った要件で速く書けば、間違ったシステムが超高速で出来上がるだけです。

AIが速く書ける分、上流（誰が・何のために・何をするのか）が崩れていると、使われない機能が量産されるリスクが高まります。AI時代の開発の進め方の詳細は生成AI開発の進め方｜PoCからプロトタイプ・本番までの全工程を参照してください。

情シスの役割が変わる

AIがコードを書く時代の情シスの役割は、ベンダー管理・要件レビューの精度がより重要になります。「コードを書ける人を雇う」よりも「業務を理解して要件を整理し、AI生成コードのレビューができる人を確保する」方向にシフトします。

情シスが今すぐやれる6ステップ

ここまでの内容を、情シス担当者が明日から動けるアクションに落とし込みます。

1. BPOの棚卸し: 自社の主要業務プロセスをリストアップし、二重入力・例外運用・属人化・手戻り・KPI欠如のサインがないかをチェックする
2. 現場ヒアリングとAs-Isの可視化: 各業務の担当者に「実際にどう動いているか」を聞き、業務フローをスイムレーン図で描いて関係者で照合する。無料の業務フロー可視化ツールを使うと早い
3. ユーザーシナリオで動機を握る: 「誰が・何を・なぜ」の3要素で各業務の動機を1〜3行に書き出す。動機が空っぽな機能は後段でFM法で却下できる。ユーザーストーリー作成ツールでフォーマット悩みを省ける
4. ToBeの再設計（または書き直し）: 経営層が当初描いたToBeがあれば、現場のAs-Isとユーザーシナリオに突き合わせて違和感を洗う。必要ならAs-Isから再設計する
5. FM法で「作る／後回し／作らない」を決める: 各要件をビジネス価値・現場で使えるか・技術コストの3軸で評価し、スコープクリープを止める。スコープ管理ツールで半自動化できる
6. エンジニアリング視点で費用対効果を試算してベンダー選定: 「作る」と決めた要件についてシステム化コストと業務効果を試算し、ベンダー選定・発注に進む

ここまでやってからベンダー選定・発注に進むと、見積もりが噛み合いやすく、開発後の手戻りも大幅に減ります。逆に、これを飛ばしていきなりベンダーに「DXのご提案」を依頼すると、各社が推測で前提を置くため、提案が比較不能になり、結局価格の安さで選ぶ失敗パターンに戻ります。

まとめ｜情シスのDXは「BPO起点・As-Is正確・シナリオで動機・FMで引き算」

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

• DXの起点は「新しいシステムを作る」ではなく「BPO（既存業務プロセス）に問題がないか」
• 業務プロセスに問題があれば、システム化より先にプロセス自体を直す選択肢がある
• As-Is／To-Beの可視化が要件定義の核心。図にすることで初めて関係者の認識ズレが見える
• ユーザーシナリオで「誰が・何を・なぜ」を握ると、後段の「作らない」判断が楽になる
• お客様のToBe案が微妙なら、As-Isから書き直して再設計する判断もある（製造業DX案件で実践）
• FM法で要件を「作る／後回し／作らない」に振り分け、スコープクリープを経営の責任で止める
• エンジニアリングが分かる人がBPOを見て、費用対効果から逆算してToBeを決める
• シンプルなデザインで小さくDXする。多機能は使われない
• AI時代こそ要件定義の重要度が上がる。間違った要件で速く書けば、間違ったシステムが速くできるだけ

情シス担当者が「経営からDXやれと言われた」状態から、現実的な一歩を踏み出すための全体像をご紹介しました。具体的なBPO見直し方・ToBe再設計の判断軸・AI時代の要件定義の進め方は、それぞれ別記事でも掘り下げる予定です。