昨今、多くの企業で「DX」や「AI活用」が叫ばれています。しかし、その導入プロジェクトの中で、自信を持って順調に進んでいると言えるケースはどれくらいあるでしょうか。 現場からは、「最新のAIツールを導入したのに、なぜか現場が以前より混乱している気がする」といった声や「高価なSaaSを導入したものの、CSVを手作業で加工して取り込む運用が残っている」という声が聞こえてきます。
私は普段、「業務設計士」として企業の業務改善やシステム導入の支援をしていますが、DX推進やAI活用を進める企業の方々が非常に疲弊しているように感じます。 生成AIなどのテクノロジーの進化によって、エンジニアの皆さんの開発効率そのものは劇的に向上しています。しかし、いくら速くコードが書けるようになったり、バイブコーディングができるようになっても、肝心の「業務システム導入プロジェクト」の成功率が上がっているわけではありません。むしろ、相変わらず炎上したり、リリース後に誰も使わないシステムになってしまうというケースは後を絶ちません。
なぜ、これほどテクノロジーが進化しても、プロジェクトの成功率は上がらないのでしょうか。 その根本原因は、エンジニアリングの「外側」に潜んでいます。コードを書く以前の段階、すなわち「業務そのものの構造」に致命的なバグを抱えたまま、無理やりシステム化しようとしている時点で間違っているのです。
本連載では、2025年12月25日発売の拙著『業務設計の教科書』のエッセンスを交えながら、エンジニアが知っておくべき「業務設計」の世界を全2回にわたって紐解いていきます。第1回となる今回は、多くのDXプロジェクトが陥る「失敗の構造」について、業務設計のプロの視点からお伝えします。
1. なぜ、銀の弾丸は機能しないのか
ソフトウェアエンジニアの世界には、「銀の弾丸などない（No Silver Bullet）」という有名な格言があります。 これは、フレデリック・ブルックスが1986年に提唱したもので、「ソフトウェア開発の本質的な難しさを、一撃で解決する魔法のようなツールや手法は存在しない」という意味です。どんなに優れたプログラミング言語や開発手法が登場しても、私たちが扱う問題（業務や要求）そのものの複雑さが消えるわけではないからです。しかし、ビジネスの現場は相変わらず、この「銀の弾丸」を追い求めているように感じます。
ここ数年のDXブーム、そして生成AIの登場によるAIブームの到来により、「新しいシステムさえ導入すれば業務課題は解決する」という誤った期待値がかつてないほど高まっています。経営層からは「AIを使って業務負担を半分にしろ」といった号令が飛び、現場では急ピッチでPoC（概念実証）が繰り返されています。しかし、現場の実感としてはどうでしょうか。「魔法のように業務が自動化された」という話はほとんど聞きません。 むしろ、「導入したAIが使いものにならないから、結局前のやり方にもどった」「自動化した作業の不備が多くて、内容のチェック負担が増えた」といった、失望の声が多く聞かれます。
なぜ、こうしたボタンの掛け違いが起きてしまうのでしょうか。その原因を探るために、プロジェクトの出発点まで時間を戻してみましょう。業務部門で活用するシステムの開発や導入で、最初にぶつかるのが「要件定義」という壁です。現場から出てくるのは「今のやっていることを実現できるようして欲しい」という要件とも呼べない曖昧な要求のみ。マニュアルやフロー図も形骸化していて、全体のプロセスを把握している人が誰もいないこともよくあります。そこにあるのは、論理的なアルゴリズムではなく、例外処理と暗黙知で構成された「秘伝のタレ」のような業務プロセスです。 仕様が決まらない、担当者によって言うことが違う、例外が多すぎてif文が無限に増えるといった状況です。これらに振り回され、「技術的な課題」にたどり着く前に疲弊してしまっているのが、多くのプロジェクトの現状ではないでしょうか。
個別のソフトウェアは進化しているのに、なぜ業務プロセス全体としての効率化が実現できないのか。それは、システムを導入するプロジェクト全体として「問題の解き方」を間違えているからです。多くの企業では、「どのシステムを導入するか」ばかりが議論されます。しかし、真の問題はそこにありません。「現状の業務設計プロセスがどうなっているか（現状把握）」が不十分であるため、誰も「解決すべき課題」を言語化できていないことが諸悪の根源です。
整理されていないグチャグチャな業務フローに対して、どれだけ高機能なソフトウェアを導入しても、それは「混乱を自動化」したり「間違ったプロセスを高速化」したりするだけに終わります。 これはプログラミングに例えるなら、スパゲッティコードで書かれたレガシーシステムのリファクタリングをせずに、上から最新のUIフレームワークだけを被せようとしているようなものです。見かけは良くなるかもしれませんが、中身の技術負債はそのまま、あるいは複雑さが増すだけです。
2. 業務の複雑性という技術的負債
なぜ、企業の業務プロセスはここまで複雑で理解不能な状態になってしまうのでしょうか。その原因を紐解くと、ソフトウェア開発における「技術的負債（Technical Debt）」や「コンウェイの法則」と共通する構造的な病理が見えてきます。
まず、業務プロセスが複雑化する最大の要因は、それを実行しているのが厳密なプログラムではなく「人間」である点にあります。プログラムであれば、定義されていない変数を参照しようとすれば即座にエラーを吐いて停止します。しかし、人間は曖昧な指示でもなんとなく動けてしまいます。エラーを吐かずに、その場で「よしなに」解釈して処理を進めてしまうのです。 長年同じ業務をやっているベテランの中には、頭で考える前に手が動いて処理している方もたくさんいらっしゃいます。もちろん、マニュアルもいちいち参照しながら業務をやりません。こうした現場ではいたるところに「暗黙の了解」が存在し、マニュアルには書かれていない極めて属人的な判断と処理で回っているのです。これが積み重なり、業務の実態は外部から観測不能なブラックボックスと化します。この現象は、みずほ銀行のシステム統合における苦闘の記録でも指摘されていました。『みずほ銀行システム統合、苦闘の19年史』では次のように述べられています。
勘定系システムの開発から時間がたつにつれて、内部を詳しく知る人が社内から少なくなり、現役で働く技術者や業務担当者にとって勘定系システムが「ブラックボックス」と化していた。
長年運用されている業務プロセスほど、当初の設計思想が失われ、運用に関わる担当者も入れ替わることで、しだいに「なぜこの仕様になっているのか」が分からなくるのです。また、システム設計において「組織の構造がシステム構造に反映される」というコンウェイの法則が働くように、業務プロセスにも組織の歪みが反映されます。 営業部門と経理部門の連携が取れていない企業では、業務プロセスも必ず分断されています。「営業が入力したデータを、経理がわざわざExcelに出力して加工し、別のシステムに入力し直す」といった非効率なプロセスは、まさに組織間のコミュニケーション不全が業務フローという形をとって現れたものです。こうした組織的な歪みや、現場判断での局所最適化が積み重なった状態。これは、エンジニアリングの世界で言う「技術的負債」そのものです。
ソフトウェア開発における技術的負債とは、「短期的なリリース速度を優先するために、理想的な設計やコード品質を犠牲にした結果、将来的に発生する追加の修正コスト」を指します。業務プロセスにおいても、同様です。業務において何かトラブルが発生した際、根本的なプロセス（コード）を修正するのではなく、「とりあえず今回の件は手動で対応しよう」「再発防止のためにダブルチェックの担当者を増やそう」といった、いわゆる「運用でカバー」する対応が取られがちです。この対応は、その瞬間はコストがかからず、すぐに問題を解決できたように見えます。しかし、それは未来に対して「借金」をしたに過ぎません。
その場しのぎの例外ルールや、意味のわからない確認工程が層のように積み重なり、誰も全体像を把握できない巨大で非効率な業務プロセスが出来上がるのです。技術的負債が恐ろしいのは、放置すればするほど「利子」を払わされ続けることです。 業務における利子とは、単なる手間の増加だけではありません。 業務側の負債は、巡り巡ってシステム側の技術的負債となり、保守不可能なシステムを生み出すのです。
多くのDXプロジェクトが失敗するのは、過去数年、数十年とかけて積み上げられてきたこの巨大な「業務の技術的負債」を返済（リファクタリング）することなく、その上に新しいシステムを建てようとするからです。 おそらくAI導入プロジェクトにおいても、このままでは同じことが繰り返されるでしょう。基礎をおろそかにして家を建てようとしても、傾いてしまうのは自明の理です。システム開発・導入を成功させるためには、まずこの負債と向き合い、業務を可能な限り「借金のないきれいな状態」に戻す必要があるのです。
3. 業務設計なしのAI導入は事故のもと
では、こうした「業務のバグ」を放置したまま、最新のAIを導入するとどうなるのでしょうか。答えはシンプルです。「間違ったプロセスが高速で実行されるようになる」か、あるいは「AIが使い物にならず、誰も使わなくなる」かのどちらかです。コンピュータサイエンスには「Garbage In, Garbage Out（ゴミを入れれば、ゴミが出てくる）」という原則があります。これはAI時代においても不変の真理です。
例えば、社内の問い合わせ対応を効率化するために、既存の社内マニュアルやナレッジベースを読み込ませて、RAG（検索拡張生成）を用いたチャットボットを導入するプロジェクトが立ち上がったとしましょう。
多くの会社では、「どのAIエンジンを使うか」「どのようなUIにするか」の議論には膨大な時間を使います。そしていざ開発フェーズになって、RAGに格納するマニュアルの内容を確認し始めます。 そこで判明するのは、マニュアルの内容が古くて実際の業務とズレていたり、例外的な処理が担当者の頭の中にしかなかったりする現実です。 業務プロセスの現状を分析し、かつ、AI導入を機によりよいものにブラッシュアップしようという動きをする会社はほとんどありません。
これが、多くのAI導入プロジェクトが成果を出せない要因です。既存の業務プロセスは長年リファクタリングが行われていないレガシーコードのようなものです。この状態でどれだけプロンプトエンジニアリングを駆使しても、根本解決にはなりません。必要なのは、プロンプトをいじることではなく、その前段にある業務プロセスから整備することだからです。ここで必要になるのが、「業務設計」という概念です。 業務設計とは、単に業務フロー図を書くことではありません。業務を一つのシステムと見なし、その「アーキテクチャ」を設計することを指します。
具体的には、「関数の定義」や「APIのインターフェース設計」と同様に、業務を構成する要素を明確に定義し、構造化することです。例えば、フロー図を書き始める前に、以下の5つだけでも明確にしておくことで、業務の構造化が非常にやりやすくなることはエンジニアの皆さんならお分かりでしょう。
- Trigger（きっかけ）：その業務は何をトリガーに開始されるのか
- Input（入力）：開始時に必要な情報は何か（データ型やフォーマット）
- Process（処理）：入力情報を元に、どのような判断・加工を行うか
- Output（出力）：処理の結果、何が生成されるか
- Role（役割）：誰が（どのシステムが）その処理に責任を持つか
業務設計とは、曖昧な「業務」という塊を、入力と出力が明確な「機能（Function）」の単位まで分解し、依存関係を整理して、再利用可能なモジュールとして再構築する作業に他なりません。 業務部門がうまく要件定義ができないのは、業務を構造化して整理するための「フレームワーク（思考の枠組み）」を持っていないからです。「どのシステムを導入するか」「どうやって自動化するか」を議論する前に、「この業務はどういう構造を持っているか」を言語化し、関係者ですり合わせていくことが欠かせません。
SaaSにしろ、AIにしろ、それらが稼働するのは既存の業務プロセスの上である以上は、まずはその部分の整理が最優先事項です。複数の人間が関わり、曖昧な情報を処理しながら前に進めている「業務」というものは、プログラムよりもよほど取り扱いが難しいのです。
業務部門は「業務設計をしなければいけない」という意識は希薄です。これまでは「業務は人がよしなに対応するもの」だったのでそれで回っていたのですが、生成AIが登場し、AIワークフローやAIエージェントがあらゆる業務に組み込まれていく中で、業務設計がきちんとできていないことが致命的欠陥になってきています。
私はAI時代こそ業務設計の重要性が高まると考えています。そして、業務を構造化する際には、エンジニアの皆さんの知識、経験が非常に優位に働きます。 コーディングそのものはAIによって大幅に効率化が進みつつあります。だからこそ、この機会に上流の「業務設計」スキルを身につけ、ビジネスとシステムの両方のアーキテクチャを描ける人材になることが、これからのキャリアにおいて大きな武器になるはずです。
4. まとめ・書籍紹介
第1回では、DXやAI導入が失敗する原因を「業務の構造的欠陥（業務設計不足）」という観点から解説しました。 AIを含めた新しいシステム開発・導入の成否の8割は、コードを書く前の「準備」で決まります。重要なのは開発のための要件定義書を完璧に作ることよりも、まずは上流にある業務を構造化し、「業務のバグ」を取り除き、きれいな構造に整地することこそが、プロジェクト成功の鍵を握っています。
2025年12月25日に発売となる拙著『業務設計の教科書』では、より業務側の観点でDX推進プロジェクトを成功に導くための業務設計の進め方を解説しておりますので、ぜひ手に取ってみていただけると嬉しいです。
次回は、この「業務設計」の手法を、エンジニアの皆さんにとって馴染み深い「ドメイン駆動設計（DDD）」の考え方と照らし合わせながら解説します。実は、優れた業務設計は、優れたドメインモデリングと驚くほど似ているのです。
