■ この資料でわかること
多額の投資をして刷新した基幹システムが、稼働から数日で使われなくなる。この現象が「担当者の抵抗」ではなく「設計プロセスの構造的な欠落」から生まれる理由を、現場の具体的な場面に沿って解き明かします。
あわせて、AI時代において、システム構築における要件定義の前提がどう変わったのか、AIへの丸投げが生む新しい落とし穴の回避法、投資判断でパートナーに何を問うべきかを整理します。
■ このような方におすすめ
- 基幹システムやWMS・TMSの刷新を行ったが、現場定着しなかった過去がある
- 現場から「前のやり方のほうが早い」と言われ、元の運用が復活したことがある
- システム機能対応のための追加開発がかさんでおり、止められない状況になっている
いずれも機能不足ではなく、「現場の実態が要件に入りきらなかった」ことに起因する症状です。
はじめに
多額の投資を経て新しい基幹システムが稼働した。ところが現場では、ほどなくして担当者の手元に見慣れたExcelが再び開かれ、新システムの外側で手作業の運用に戻っていく。背景にあるのは、現場で日々発生する例外処理や物理的制約が、要件として十分に取り込まれていないという問題です。
この光景は特定の企業の失敗談ではありません。原因は「現場が新しいものを嫌がった」という意識の問題にされがちですが、実際に起きているのは構造的なことです。現場を回すために不可欠な例外処理と物理的制約が、要件定義の過程で静かに抜け落ちている。稼働直後の現場拒絶は、その欠落が可視化された瞬間にすぎません。
稼働直後の現場拒絶は、偶然ではなく必然である
「旧運用の復活」は反抗ではなく、現場の防衛反応である
この現象には共通のパターンがあります。システムに入らない情報を管理するExcelや手作業が生まれ、やがて正式な運用とは別の「裏運用」として定着していきます。結果として、システムは現場の実態を十分に支えられず、実績を後追いで入力するだけの存在になりかねません。
現場は悪意でこうしているのではありません。今日の出荷を止めないために、使えない道具の隙間を人の手で埋めているのです。シャドーITや属人化は原因ではなく症状であり、叱っても消えません。
標準SOPの下に沈む「暗黙知の氷山」
では、その隙間はどこから生まれるのか。業務を氷山に見立てると、水面の上に出ているのはマニュアル化された基本フローと標準SOPだけです。
水面下にあるのは、VIP顧客だけの独自の梱包や特殊ラベル、EC向けと卸売向けで全く異なる検品ルールなどの現場に精通したベテランの経験則が多く存在します。どれも「わざわざ言うほどではない」とみなされることもありますが、現場の一日はこの無数の判断の積み重ねで成立しています。
人間のヒアリングという、避けがたいボトルネック
従来の要件定義は、この氷山を人間の対話だけで引き上げようとしてきました。数回のヒアリングで議事録を起こし、業務フロー図と要件一覧に落とし込む。この工程には三つの漏れが生じます。
第一に、聞かれなければ答えられない。当たり前の手順は質問されない限り言語化されません。
第二に、聞ける人数と時間に限りがある。
第三に、構造化の作業量が膨大すぎる。
断片的な発言、手書きの帳票、個人のExcelを横断して矛盾なく整理するコストが、従来は「そこまでやる価値はない」と判断され、標準業務の外として要件から落とされてきました。結果として要件書にはいつも発生するプロセスの一部のみが載り、発生頻度は低い必要な業務は漏れる。その欠落は稼働まで誰も気づきません。
要件が埋まらないまま進むと、二つの妥協しか残らない
カスタマイズの泥沼化――終わらない手戻り
要件が固まらないまま走り出すと、企業は二つの道のどちらかに追い込まれます。一つ目は、走りながら現場の要望を作り込んでいく道です。
テスト段階で「これでは運用できない」という声が上がり、仕様変更が別の機能に影響してまた手戻りが起きる。認識のズレを埋める会議が増え、追加予算の稟議が繰り返され、やがて経営の側に「このプロジェクトは制御できていない」という不信が生まれます。
パッケージへの迎合――予算内で終わり、運用で払う
二つ目は、「世の中の標準だから」という説明のもと、パッケージの標準機能に業務を強制的に当てはめる道です。開発は形式上、予定通りに進み、導入費用も収まる。報告資料の上では成功したプロジェクトに見えます。
しかし現場では、自社では絶対に発生しない業務のボタンが画面に並び、入力必須項目が作業時間を圧迫し、例外処理は手作業でカバーされる。「一件ごとに二画面またぐようになって、前より遅くなりました」という声が、生産性の数字にじわじわ表れます。
どちらを選んでも、現場の課題は解決しない
| 観点 | カスタマイズの泥沼化 | パッケージへの迎合 |
| 開発プロセス | 終わらない手戻りと仕様変更 | 形式上は予定通りに進行 |
| コスト | 予算の致命的な超過、頓挫 | 導入費は収まるが運用コストが継続発生 |
| 現場への影響 | 疲弊とベンダーへの不信感 | 業務の歪みと使い勝手の悪化 |
※ 正反対に見えて、行き着く先は同じです。現場の課題が要件に入っていない、という一点が変わらないためです。
AIが崩したのは「例外を扱うコストの壁」である
例外は、排除すべきエラーではなくなった
複雑な現場業務と独自の例外処理をシステムに組み込むことは、長らくコストと期間の面で不可能とされてきました。この前提が、生成AI(LLM)の実用化で変わりつつあります。
LLMが得意とするのは、まさに従来ボトルネックだった作業です。音声記録、断片的な手書きメモ、旧システムの画面キャプチャ、書式の異なるエクセル――こうした非定型情報を横断して読み解き、業務の文脈を推論しながら構造化する。人の役割は、ゼロから起こすことではなく、出てきた結果の妥当性を確認し判断を下すことに移ります。
当社の案件でも、画面・帳票・キャプチャを一括投入し、関係性の整理から項目抽出、機能推論までを一気通貫で処理し、現状把握の時間を大幅に短縮し、把握する領域を広げることもできています。
分厚い仕様書ではなく、「動く画面」で合意する
もう一つの理由は、確認の手段にあります。IT に不慣れな現場担当者に分厚い設計書を渡して「問題がないか確認してください」と依頼しても、文書だけでは操作イメージや要件の抜け漏れを十分に確認しきれないことがあります。形式的な承認だけでは、必ずしも現場との合意形成につながりません。
そこで有効なのが、業務要件からモックアップ画面を先に生成し、動く画面を見ながら意見をもらう進め方です。「この項目は本当に必須ですか」「このボタンでは何が起きるのか分からない」――文書では出てこない指摘が自然に出てきます。
プロジェクトの進め方そのものが組み替わる
影響は要件定義だけにとどまりません。従来はユーザーが画面に初めて触れるのが終盤で、「イメージが違う」と気づいてももう戻る時間がありませんでした。
| 工程 | 従来の進め方 | AIを前提とした進め方 |
| 要件確認の手段 | 分厚いドキュメントで読み合わせ | リアルに近い画面を見ながら確認 |
| 画面を見る時期 | 終盤のユーザーテスト | 要件定義の段階から |
| ユーザー確認 | 期間が短く、修正余地がない | 期間を長く取れ、修正に余裕が生まれる |
※ 前工程が短縮され、イメージを早期確認できることで、品質向上にリソースを振り向けられる点が本質です。
刷新を先送りしてきた企業にこそ、跳躍の余地がある
ここで一つ、逆説的なことを申し上げます。旧来システムやExcel・手作業で運用を続けてきた企業は「遅れている」と評価されてきましたが、現在の局面ではその位置がむしろ有利に働きます。
先行企業はパッケージ主体のIT導入フェーズで多額の投資を済ませ、業務を標準機能に合わせた歪みが資産として固定化されています。一方、まだ大きな投資をしていない企業は、この妥協のフェーズを飛び越え、AI主導の最適化フェーズから始められます。
AI時代の新しい落とし穴と、パートナーの見極め方
「現行踏襲」×「AI」は、負債の高速な移し替えにすぎない
AI活用により、処理量が増えたこと自体は朗報ですが、この処理能力の高さが新しい落とし穴を生みます。
最悪の組み合わせは、ブラックボックス化した現行仕様とAIの併用です。なぜそうしているのか誰も答えられないルールをそのままAIに読み込ませて次期システムへ移すのは、解決されない負債をそのまま高速量産する行為につながり、問題は解決しません。従来は人が精査する役割を担っていましたが、それがなくなったと考えるべきです。
AI単体では完結しない――必要なのは「翻訳者」
AIは複雑な処理を低コストで行うことができますが、「それが自社に本当に必要か」までは判断できません。競争力として設計に組み込み、勇気を持って捨てるのはどこなのか。この取捨選択は、経営の意図と現場の実態を両方理解した人間の仕事です。
求められるのは、AIツールを操作できるだけではなく、経営戦略の狙いを理解し、泥臭い現場業務の勘所も分かったうえで、例外を業務要件として再定義できる「翻訳者」です。
投資判断の場で問うべき、二つの基準
パートナー選定の場面で、経営層が提案書に対して確認すべき論点は二つに絞られます。
| 基準 | 提案書で確認すべきこと | |
| 基準1 | 例外要件を業務要件として落とし込めるか | 例外を排除せず、業務を理解した上で現実的な設計に落とし込む判断基準と具体的な手順が示されているか |
| 基準2 | 統合推進力による取捨選択ができるか | 要件を丸呑みせず、経営と現場のハブとなり、必要な業務を取捨選択したうえで、方向性を定めるための考え方が明確に示されているか |
両者の違いはゴール設定に表れます。「与えられた要件をシステム実装すること」を目指すのか、「ロジスティクスが競争力の源泉に転換すること」を目指すのか。提案の場で対等に議論できる関係を築けるかどうかが、数年後の成否を左右します。
自社チェックリスト
以下に当てはまる項目がないか確認してください。
□ システムに入らない情報を管理する業務用エクセルが、各部署に存在している
□ 正式なマニュアルとは別に、現場で受け継がれている手順がある
□ 「なぜこの業務ルールがあるのか」を説明できる人が社内にいない
□ 前回のシステム刷新で、パッケージ標準に合わせるために諦めた業務要件がある
□ システム化の目的が「老朽化対応」以上の言葉で語られていない
三つ以上当てはまる場合、次の刷新でも稼働後の現場拒絶が再現しかねません。
結びに代えて
基幹業務システムの刷新は、ITインフラの更新作業ではありません。自社の業務のどこに価値があり、どこを手放すのかを決める経営の意思決定であり、その質は現場の実態がどれだけ正確に設計の土台に載っているかで決まります。
「システムに業務を合わせる」から「業務をシステム化する」へ。次の投資判断の前に、自社の例外がどこにどれだけ眠っているのかを棚卸ししてみてください。その作業自体が、現場で使われるシステム構築への最初の一歩になります。
シーオス株式会社 について
シーオスは、ロジスティクス分野に25年以上特化してきたソリューションカンパニーです。「ロジスティクス」を単なる物の移動ではなく、企業価値に直結する重要領域と捉え事業を展開してまいりました。創業以来、ロジスティクス領域に特化した専門チームを擁し、現場理解と戦略立案の双方に強みを持つパートナーとして、製造・小売・ECなど数多くの企業様の課題解決に伴走しております。
戦略コンサルティングからシステム開発、WMS（倉庫管理システム）やTMS（輸配送管理システム）、RFP作成支援や第三者レビューに至るまで、システム刷新プロジェクトの上流工程を支えるフルラインアップのサービスを提供しています。さらに、自動搬送ロボットのソフトウェア開発・提供や、建設（コンストラクションマネジメント）まで、ロジスティクス領域を幅広く支援しています。
