「新しいシステムを入れます。ただし、今の業務フローは変えないでください。」
あるプロジェクトのキックオフで聞いたこの言葉を、私は今でも覚えている。数億円をかけて新しいシステムを導入するのに、旧システムの業務フローをそのまま再現しろという。矛盾している。声を上げた。却下された。案の定、プロジェクトは低ROI（投資対効果）で終わった。
これは特殊な事例ではない。日本中の現場で、今日も同じことが起きている。
数字が語る「システム刷新」の惨状
まず数字を見てほしい。
| 指標 | 数値 | 出典 |
|---|---|---|
| 500人月超のQCD（品質・コスト・納期）達成率 | 20%未満 | BCG |
| IT PJ一部〜完全失敗率 | 83.9% | Standish Group |
| ERP（統合基幹業務システム）目標未達率 | 55-75% | Gartner |
| 大規模PJ追加投資額 | 200-450億円 | BCG事例 |
500人月を超える大規模プロジェクトでは、QCDを3つとも達成できるのは5件に1件もない。ERPに限ると、導入目標を達成できていないプロジェクトが半数以上だ。
なぜこうなるのか。原因は技術力の不足ではない。「現行踏襲」という意思決定の構造にある。
「現行踏襲」の正体
現場が変化を拒否する構造
現行踏襲は、個人の怠慢ではなく組織の構造的な問題だ。悪循環はこう回っている。
属人化の壁。 中小企業の74〜79%が「業務が特定の人に依存している」と認識している（SMB調査）。にもかかわらず、その状態を解消するために動いている企業は少数派だ。なぜなら「属人化している」と認識することと、「属人化を解消する」と決断することの間には巨大な溝がある。
「うちは特殊」症候群。 業務の8割は他社と同じなのに、残り2割の例外処理を根拠に「うちは特殊だから標準パッケージでは対応できない」と主張する。この2割の死守が、カスタマイズ費用を膨張させる。
丸投げの問題。 経産省が2025年5月のレポートで指摘した通り、要件定義をベンダーに丸投げする企業が多い。自社の業務を自社で定義できていない。だから「今と同じにして」以外の要件が出てこない。
この3つが合わさって、「現行踏襲」がデフォルトの要件になる。そして新システムでも属人化が再生産され、5〜10年後の次期プロジェクトで同じことが繰り返される。
人間がシステムに融合する現象
「田中さんがいないと業務が回らない」——この状態は、田中さんがシステムの一部になっているということだ。
システムの本質は「誰がボタンを押しても同じ結果が出る」ことにある。しかし属人化が進むと、特定の個人の判断・記憶・経験がシステムの動作に不可欠になる。人間がシステムに融合してしまう。
これが組織全体で起きている証拠がある。
- 人手不足倒産: 2025年、過去最多の427件。人が抜けたら事業が止まる企業がこれだけある
- レガシーシステム20年超: 約60%の企業が20年以上前のシステムを使い続けている
- 経産省「2025年の崖」: この状態が続くと、最大年間12兆円の経済損失が生じると試算された
属人化は「あの人が優秀だから」で片付く話ではない。経営リスクだ。
私が経験した「現行踏襲」プロジェクト
変換ツールという名の延命装置
あるプロジェクトで、私は「変換ツール」の開発に関わった。旧システムの独自ルール——長年かけて積み上がった例外処理、暗黙の判断ロジック、誰も全体像を把握していない業務フロー——を、新システムに移植するための中間層だ。
本末転倒だった。新しいシステムを入れる目的は業務を改善することなのに、旧システムの動きを完璧に再現することが目標になっていた。変換ツールは「延命装置」だった。旧業務の属人的なルールを、新しい技術基盤の上で延命させる装置。
「このままでは失敗する」と言った
私はプロジェクトの初期段階で声を上げた。
「業務フローを先に見直すべきだ。旧ルールをそのまま移植したら、コストだけが膨らんで本来の目的を達成できない。」
却下された。理由は「現場が混乱する」「移行リスクが大きい」「スケジュールに間に合わない」。どれも短期的には正しい。しかし中長期的には全て間違っていた。
結果はどうなったか。予想通りだ。変換ツールの開発に膨大な工数がかかり、テストケースは旧システムの動作を基準に作られ、本番稼働後も「前のシステムと動きが違う」という問い合わせが殺到した。ROIは計画を大幅に下回った。
「猫がボタンを押しても同じ結果が出る」のがシステムだ
この経験から、私は一つの哲学を確立した。
「猫がボタンを押しても同じ結果が出る」——それがシステムの本質だ。
誰が操作しても、いつ操作しても、同じ入力に対して同じ出力が返る。これがシステムの価値であり、存在意義だ。属人化とは、この原則が壊れている状態のことを指す。
「田中さんが判断しないと次に進めない」「このExcelは鈴木さんしかメンテできない」「例外処理のルールは佐藤さんの頭の中にある」——これらは全て、システムが不完全であることの証拠だ。
現行踏襲が生む3つのコスト
1. カスタマイズ費用の膨張
BCGの事例では、大規模プロジェクトで200〜450億円の追加投資が発生している。その大部分は「現行業務の再現」のためのカスタマイズだ。標準パッケージをそのまま使えば不要だった費用が、「うちは特殊だから」の一言で積み上がる。
2. 教育コストの固定化
属人的なルールが新システムに移植されると、新入社員はそのルールを一から学ばなければならない。マニュアルには書かれていない暗黙知が大量にある。OJT（実務を通じた教育訓練）に依存する教育が続き、「一人前になるまで3年」という状態が固定化する。
3. 次の刷新でも同じ問題が再発
最も深刻なのはこれだ。現行踏襲で導入したシステムは、5〜10年後に「レガシー」になる。そのとき、また「現行踏襲で」と言い出す。負のスパイラルが永久に回り続ける。
この3つのコストは複利で膨張する。先送りするほど、次の改革のハードルが上がる。
現行踏襲を断ち切る処方箋
1. 業務棚卸しを「先に」やる
システムの要件定義の前に、業務そのものを棚卸しする。現場に行き、実際にどんな業務が行われているかを観察する。ヒアリングだけでは足りない。人は自分の業務を正確に説明できないからだ。
現場に行けで書いた通り、現場観察は全てのプロジェクトの出発点だ。
2. 標準化の判断をトップダウンで
業務棚卸しの結果をもとに、経営層が「何を残し、何を廃止するか」を決める。これはボトムアップでは決まらない。 現場は自分の業務を守ろうとする。それは自然なことだ。だからこそ経営が判断する。
| 判断基準 | 標準化する | 残す |
|---|---|---|
| 法規制で必須 | — | ✅ |
| 業界標準と同じ | ✅ | — |
| 担当者しか説明できない | ✅（ルール化） | — |
| 顧客価値に直結 | — | ✅（差別化） |
| 月1回以下の例外処理 | ✅（簡素化） | — |
3. 「猫テスト」を設計基準にする
全ての業務プロセスに対して問う——「猫がボタンを押しても同じ結果が出るか？」
答えがNoなら、そこには属人的な判断が潜んでいる。その判断をルール化し、システムに実装する。ルール化できない判断は、人間が行う領域として明確に分離する。
- ✅ 猫テストOK: 入力→処理→出力が一意に決まる
- ⚠️ 要改善: 判断基準はあるがマニュアル化されていない
- ❌ 猫テストNG: 特定の人の経験と勘に依存している
4. AIとシステムで属人化を解消
判断ロジックをシステムに実装し、AIで補完する。PMBOK-AIフレームワークでは、AIを「判断支援ツール」として位置づけている。人間が最終判断を行い、AIがその判断に必要な情報を整理・提示する。
属人化の解消は「人を排除する」ことではない。「人に依存しなくても回る仕組み」を作った上で、人がより高度な判断に集中することだ。
まとめ — システムは経営の武器だ
- 現行踏襲は構造的な問題。 個人の怠慢ではなく、属人化・「うちは特殊」・丸投げの悪循環が原因
- 「猫がボタンを押しても同じ結果が出る」がシステムの本質。 この基準で全業務を見直す
- 業務標準化が先、システム導入が後。 順番を間違えると数百億円の投資が無駄になる
システムは経営の武器だ。しかし「現行踏襲」という呪いにかかったまま導入すれば、武器ではなく足枷になる。
呪いを解くのはシンプルだ。業務を先に変える。 それだけで、システムは本来の力を発揮する。
関連記事:
- 現場に行け — 業務棚卸しと現場主義
- シンプル・イズ・スピード — 複雑さを排除する思考法
- システムが先、営業が後
- Vibe Codingの先へ — 品質ゲート付きAI開発
- AI導入プロジェクトの失敗から学んだ3つの教訓
PMBOK-AIフレームワークの詳細はこちら: PMBOK-AI
プロジェクトのご相談: お問い合わせ