情シスが客先のToBeを見直す判断軸｜製造業DX案件のAs-Is書き直し再設計プロセス

この記事の結論: Beekleが製造業DX案件で実践したように、お客様の当初のToBe案が微妙ならAs-Isから書き直して再設計する判断が現実的です。違和感3点以上ならAs-Is戻し、エンジニアリング視点で費用対効果を試算してToBeを再構成します。

「経営層が描いたToBe」をそのまま実装する前に

DXプロジェクトでよくあるパターンは、経営層やコンサルが「DX後はこういう業務フローにしたい」というToBe（改善後の業務フロー）案を持って情シスに降ろしてくる構造です。情シスはそれを受けて、システム化の見積もりやベンダー選定に入っていきます。

しかし、Beekleが受託開発の現場で実感しているのは、「経営層が描いたToBe案がそのまま実装に値するケースは多くない」ということです。ToBe案がよく出来ていないわけではなく、現場のAs-Is（実際の業務）と照合すると違和感が出てくる、という構造的な問題です。

本記事は、情シス向けDXシリーズのうちToBe再設計に特化した実践記事です。全体像は情シスのためのDX進め方完全ガイドを、BPO見直しの詳細は情シスがDX案件で最初にやるBPO見直しの進め方を参照してください。

ToBeが微妙になる典型パターン

当初のToBe案がそのままでは実装できないケースには、共通するパターンがあります。情シスがToBe案を受け取ったときに、最初にチェックすべき観点です。

パターン1: 経営層の思いつきで描かれている

「最近他社がやっているから」「展示会でこんなシステムを見たから」という起点でToBeが描かれているケース。自社の業務との接点が検証されていないため、現場で動かない可能性が高いToBeです。

パターン2: コンサルがテンプレで書いた

外部コンサルが他業界の成功事例をベースに、自社向けにテンプレ調整して描いたToBe。一見洗練されていますが、自社固有の例外運用や業界特有の規制が反映されていないケースが多いです。

パターン3: 現場の声が入っていない

経営層と情シス、または経営層とコンサルだけでToBeが固まり、現場担当者が完成間際に初めて見るケース。現場が知っている例外運用や暗黙の業務ルールが反映されていないため、リリース後に「使えない」が頻発します。

パターン4: システム化コストが読まれていない

ToBeに含まれる各業務をシステム化したときの実装コスト・例外処理・テスト工数が試算されていないケース。一見シンプルに見えるToBeでも、外部システム連携や非機能要件で工数が3倍に膨らむことは珍しくありません。

パターン5: 業務責任が曖昧

ToBeに描かれた業務を、誰が実行するのかが決まっていないケース。「自動化される」と書かれていても、自動化できない例外時の対応者が決まっていなかったり、新しい業務責任が誰にも割り当てられていなかったりします。

製造業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再設計の成功条件です。

合意プロセス: ToBe案を一部採用・一部変更・一部削る

費用対効果が試算できた段階で、お客様と一緒にToBe案の再設計を行いました。当初案を一部採用しつつ、一部は変更し、一部は削るという形で合意しました。優先順位の判定にはFM法（要件をビジネス価値・現場で使えるか・技術コストの3軸で評価する手法）を使うと、客観基準で「作る／後回し／作らない」が決まります。詳しくはスコープ管理「FM法」の使い方、無料で試せるのはスコープ管理ツールです。

結果として、当初想定の半分程度のシステム化範囲で、業務改善とシステム化を組み合わせた現実的なDXとして稼働しています。お客様が「無理して全部システム化しなくてよかった」と言ってくれたことが印象的でした。

情シスが当初ToBe案をチェックする5観点

製造業DX案件の経験から、ToBe案をチェックするときに使える5観点を整理しました。情シスが経営層やコンサルから受け取ったToBe案を評価するときに、このリストで違和感を洗い出せます。

観点1: 例外運用が反映されているか

標準フローだけが描かれていて、例外時の挙動が空白になっていないかを確認します。「月末だけ違う」「Aさん休みのときは別ルート」のような暗黙の例外運用が、ToBeに反映されているかが分かれ目です。例外運用の洗い出しはBPO見直しの進め方と業務フロー可視化ツールでAs-Isを正確に描くと拾えます。

観点2: 業務の責任範囲が明確か

各業務について「誰が実行するか」「誰が承認するか」「失敗時に誰が対応するか」が明示されているかを確認します。「自動化される」とだけ書かれて、自動化できない例外時の責任者が決まっていないToBeは、リリース後に必ず詰まります。

観点3: 現場担当者がレビューしているか

ToBe案を、現場担当者が事前に見て指摘を入れているかを確認します。経営層・情シス・コンサルだけで固めたToBeは、現場知識が抜けています。リリース直前に現場が初めて見る構造は、典型的な失敗パターンです。

観点4: システム化コストが試算されているか

各業務をシステム化したときの工数・コスト・期間が試算されているかを確認します。「DXのご提案」がToBeとセットで来ていても、コスト試算が抽象的（一式◯千万円のような）なら、後で予算が膨らむリスクが高いです。

観点5: KPIが定義されているか

ToBeで実現される業務改善を、どんなKPIで測るかが決まっているかを確認します。「業務時間が短縮される」「ミスが減る」のような定性的記述だけでは、リリース後の効果説明ができません。

As-Isに戻して書き直す判断基準

5観点でチェックして違和感が多かった場合、ToBe案を部分修正するか、それともAs-Isに戻して書き直すかの判断が必要になります。Beekleが現場で使っている判断基準を共有します。

部分修正で済むケース

• 違和感が1〜2点に限定されている
• 例外運用や責任範囲の追記で解消できる
• システム化コストの試算を後付けで補える

As-Isから書き直すべきケース

• 違和感が3点以上ある（特に観点1, 3, 4のいずれかが空白）
• 現場担当者がToBe案に強い違和感を持っている
• システム化コストが当初想定の3倍以上になりそうな兆候がある
• ToBe案の前提となる業務理解そのものに齟齬がある

As-Isから書き直す決断は、プロジェクト期間が伸びるように見えますが、実装に進んでから手戻りで詰まるよりトータルでは早く終わります。「最初の数週間で決まる」というのが、Beekleの実感です。

まとめ｜ToBeを鵜呑みにしないのが情シスの仕事

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

• 経営層が描いたToBe案をそのまま実装すると、現場で使われないシステムになるリスクが高い
• ToBeが微妙になる典型は5パターン: 経営層の思いつき／コンサルテンプレ／現場声不在／コスト未試算／責任曖昧
• 5観点でToBe案をチェックする: 例外運用反映／責任明確／現場レビュー／コスト試算／KPI定義
• 違和感が3点以上ならAs-Isに戻して書き直す（製造業DX案件で実践）
• 業務改善視点とエンジニアリング視点の両方を持つ人がToBe再設計を主導する
• 「ToBe案を一部採用・一部変更・一部削る」の合意で、当初想定より小さいシステム化範囲に収まることが多い

ToBe再設計が終わったら、次は「FM法でスコープを決めて、AI時代の要件定義を進める」フェーズです。AI時代こそ要件定義の重要度が上がる理由については、姉妹記事AI時代こそ要件定義｜情シスが押さえるべき発注術で解説しています。