「運用は未定です」——この一言を聞いた瞬間、私はそのプロジェクトの行方が見える。
要件がぶれる。手戻りが連鎖する。納期が延びる。最終的に「とりあえず動くもの」が納品されて、誰も使わずに終わる。
システム導入で利益を上げるはずが、なぜこうなるのか。原因は技術でも予算でもない。「決めない」という経営判断の失敗だ。
この記事では、複数プロジェクトの実体験をもとに、仕組みが崩壊する3つのパターンと、それを防ぐ「ITコーチング」という処方箋を解説する。
仕組みで利益を上げるとはどういうことか
「仕組み化」とは何か。一言でいえば、属人化の排除だ。
誰がやっても同じ結果が出る。ベテランがいなくても業務が回る。新人でも3日で戦力になれる。この状態を作ることが、仕組み化の本質だ。
仕組みが機能すれば、利益は安定する。売上の波を作るのは人の能力のばらつきだ。属人化している限り、優秀な担当者が辞めた瞬間に売上は落ちる。システムが仕組みを「固める」ことで、属人化に依存しない利益構造になる。
しかし現実はどうか。中小企業の74%が「業務が特定の人に依存している」と認識している（SMB調査）。認識しているのに、解消できていない。それはなぜか。仕組み化を目的として導入したシステムが、結局「デジタル化した属人化」に終わっているからだ。
システムは仕組みを強制するツールだ。だが「既存の混乱をデジタル化するだけ」では、混乱がシステムの中に移植されるだけだ。仕組みを先に決め、システムでそれを固める。この順番が、全ての出発点だ。
「決めない」が最大のコストになる
プロジェクトにおいて最大のコストは何か。私の答えは「意思決定しないこと」だ。
「運用はまだ未定」「要件が変わるかもしれない」——この言葉が出るたびに、要件がぶれ、設計が崩れ、開発工数が積み上がる。見えないコストが、静かに膨らみ続ける。
実際に経験した案件がある。あるSaaS開発プロジェクトで、私はRFPに2025年3月に回答した。しかし発注が来たのは2026年2月。約1年待った。 その間、設計は変わり続けた。発注が来た後も設計は確定せず、納期は5月に設定されている。着手時点で、設計はまだ固まっていない。
この間に起きたことは何か。要件定義の手戻りが3回。会議のたびに「やっぱりこうしたい」が出て、その都度設計をやり直した。発注から着手まで短期間でも、設計未確定のまま進めばコストはさらに膨らむ。
世界規模でも同じ構造が見える。グローバルIT支出は2005年の1.7兆ドルから2024年には5.6兆ドルに拡大した（IEEE Spectrum）。しかしプロジェクト成功率は改善していない。Standish GroupはITプロジェクトの83.9%が一部〜完全失敗と報告している。投資額が増えても、成功しない。原因は予算や技術力の不足ではない。意思決定の構造の問題だ。
決めないことのコストは見えない。しかしそれは確実に、プロジェクトを殺す。
仕組みが崩壊する3つのパターン
パターン1：目的が浸透していない
「なぜこのシステムを入れるのか」を理解せずに実装が始まる。
「運用が変わるかもしれない」という発言が象徴的だ。仕組み化の目的が標準化の実現であるなら、運用を変える余地は最初から存在しない。この発言が出る時点で、そのプロジェクトの参加者は仕組み化の目的を理解していない。
経産省が推進するモデル契約書の普及率はわずか4割にとどまる。要件定義の重要性を啓発しても、現場では「形式的な承認」が続いている。なぜか。目的を理解していないから、何を決めるべきかがわからないのだ。
パターン2：運用を人に合わせてしまう
現場に行けで書いた物流倉庫のWMS開発の話に戻る。
管理部署が半年かけて設計したフローには、同じ商品に対して10回以上のピッキング作業が組み込まれていた。管理者の「完璧な把握」という要望に、運用を合わせた結果だ。私が倉庫の現場に行き、作業者と話してわかったのは、問題は現場の作業ではなく「管理側が状況を把握できないこと」だったということだ。
現場の動作を観察せずに机上で設計した結果、1人の担当者の思考が運用に埋め込まれた。 これが「運用の属人化」だ。その後、フロー全体をやり直し、管理部署の設計の1/3以下のシンプルな設計に落とし込んだ。
仕組み化とは「人の思考をシステムに移す」ことではなく、「誰もが同じ動作をできる最小フローを設計する」ことだ。人に合わせた瞬間、仕組みは人に依存し始める。
パターン3：決裁者が決めない
別の物流DX案件での経験だ。
システムの改修作業中、担当開発者が2/5以前の旧コードファイルを使用していた。Gitによるバージョン管理がなく、「最新のファイル」が何かを誰も把握していなかった。チェックリストはあったが、リグレッション（既存機能への影響確認）の項目がなかった。
確定プロセスに最終責任を持つ人間が不在だった。 これが根本原因だ。
要件定義の最終責任は発注者側にある。現行踏襲という呪いでも書いたが、要件定義をベンダーに丸投げする企業が多い。しかし、自社の業務を自社で定義できなければ、決裁者不在のプロジェクトが量産される。
仕組みに人を合わせろ
これがこの記事の核心だ。
仕組みに人を合わせる。 人に仕組みを合わせるのではない。
「この部署はこのやり方が好き」「あの担当者にはこの手順が向いている」——こうした理由でシステムをカスタマイズするたびに、仕組みは属人化に逆戻りする。個人の好みを反映したシステムは、個人が去った瞬間に崩壊する。
売上が先、システムは後で紹介したマレーシアのボクシングジムの例が、この原則を逆から証明している。クライアントは「まずシステムを作りたい」と言った。私は「売上が先、システムは後」と提案した。
結果、オープン初日から30名以上の会員を獲得し、現在は100名超に成長した。仕組みを正しい順序で構築したから成功した。 システムを先に作っていたら、何を標準化すべきかが見えていない段階で、特定の人間の思考をシステムに埋め込んでいただろう。
仕組みの正しい順番はこうだ。
- ①目的を決める — この仕組みで何を標準化し、何を排除するか
- ②運用を決める — 誰が何をどう回すか、例外なし
- ③システムで固める — 決まった運用をコードで実装する
③から始めると、①と②が未確定のまま実装が進む。「運用は未定です」はその証拠だ。
経営者こそ「エンジニアリング思考」を — ITコーチングという処方箋
「決めない組織」は、技術の問題ではない。組織の問題だ。
どんな優秀なエンジニアを連れてきても、決めない組織ではシステムは崩壊する。処方箋は技術ソリューションではなく、「決められる組織」を作ることだ。これが、私が「ITコーチング」と呼ぶ伴走支援の本質だ。
ITコーチングは4フェーズで構成される。
| フェーズ | 内容 |
|---|---|
| Phase 1: 目的の言語化 | なぜこの仕組みが必要か。何を標準化するのかを言語化する |
| Phase 2: 運用の決定 | 誰が何をどう回すか。例外なしで決定する |
| Phase 3: システム実装 | 決まった仕組みをコードで固める |
| Phase 4: 定着支援 | 仕組みに人が慣れるまで伴走する |
Phase 1と2を省略して Phase 3 から始めるから、プロジェクトは崩壊する。
2026年から「デジタル化・AI導入補助金」では伴走支援も補助対象になった。システム導入コストだけでなく、組織変革の伴走支援に対して補助が受けられる。これは「技術を入れるだけでは不十分」という政策上の認識の反映だ。
Panda OfficeのFDE（Forward Deployed Engineer）型支援は、このフレームワークを現場で実践するものだ。現場に入り込み、決めるべきことを決め、仕組みを実装し、定着するまで伴走する。PMBOK-AIフレームワークは、このプロセスをPMの視点から体系化したものだ。
まとめ：決めることは、責任だ
この記事の要点を3行にまとめる。
- 仕組み化の目的は属人化の排除。 誰がやっても同じ結果が出る状態を作ることだ
- 「運用は未定」は、目的が未定であることと同義。 決めない組織はシステムで解決できない
- 仕組みに人を合わせる。 人に仕組みを合わせた瞬間、属人化が再生産される
「運用は未定です」——これは技術的な問題ではない。責任の放棄だ。
要件定義の責任は発注者にある。運用を決める責任は経営者にある。仕組みに人を合わせる決断をする責任も、経営者にある。
システムは、決めた組織だけが活用できる道具だ。仕組みに人を合わせる。これがシステム導入成功の唯一の原則だ。
属人化と現行踏襲の構造については現行踏襲という呪いで詳しく解説しています。現場観察の重要性は現場に行け、仕組みより売上を先に作る考え方は売上が先、システムは後をご覧ください。
AI失敗事例の教訓についてはAI活用の失敗と教訓も参考にどうぞ。
システム導入・仕組み化についてのご相談はお問い合わせからお気軽にどうぞ。