システム開発プロジェクトにおいて、最も深刻なリスクの一つは「エンドユーザが本気になるのが遅すぎる」ことです。特にERPや業務基幹システムといった全社的な影響を持つプロジェクトにおいては、GoLive（本番稼働）直前になって初めて、エンドユーザが真剣にシステムを使い始めるという現象がしばしば見受けられます。これが、プロジェクト終盤におけるトラブルや炎上の最大の要因の一つとなっています。
本稿では、この「エンドユーザが本気になるのが遅すぎる問題」について、なぜ起こるのか、どうすれば防げるのかを、ROITが現場で培ってきた知見を交えながら解説します。
1. システム開発は後工程で炎上する
多くのシステム開発プロジェクトでは、最初の要件定義から設計、開発、テストまでは比較的スムーズに進んでいるように見えます。プロジェクトは、工程表どおりに進行し、定例会議では「順調です」と報告され、チームの空気も悪くない。しかし、本番稼働の直前、つまりユーザ受け入れテスト（UAT）や移行リハーサル、操作研修のフェーズに入った瞬間に状況が一変することがあります。
「業務と合っていない」「こんな操作は現場では無理だ」「帳票に必要な情報が出力されない」など、これまで表面化してこなかった問題が噴出し、プロジェクトチームは急な仕様変更や追加開発に追われ、炎上状態に陥るのです。
このような炎上は「後工程リスク」とも呼ばれ、開発後半の「使ってみて初めて気づく違和感」が引き金になります。つまり、開発チームがどれだけ誠実に要件を実装しても、ユーザが本気になっていなければ意味がないのです。
2. 炎上のもっとも多い原因「こんなはずじゃなかった問題」
「こんなはずじゃなかった」──。この言葉は、プロジェクトの終盤における“地雷ワード”です。
ユーザからこの言葉が出る時、たいていの場合は以下のいずれか、あるいは複数の問題が背景にあります。
- 要件定義の段階での誤認識・伝達ミス
- プロトタイプがなかったためイメージできなかった
- 想定と実際の業務環境・運用フローの乖離
- ユーザの関与が浅く、理解が不十分だった
特に大規模な業務システムでは、各部門にまたがる複雑な業務フローや例外処理が存在し、机上の議論ではカバーしきれないことが多いのです。加えて、「ユーザ自身が自分の業務を言語化できていない」というケースもあります。
3. なぜこのようなことが起こるのか？
この問題は構造的・文化的・心理的な要因が複雑に絡み合って生じます。
（1）「情報システム部門 vs 現場」という構図
多くの企業では、システム導入は情報システム部門の主導で進められ、現場はあくまで「協力者」あるいは「ヒアリング対象」という位置づけです。この関係性の中では、現場が当事者意識を持ちにくく、「自分ごと」としてプロジェクトに関わるモチベーションも上がりません。
（2）日常業務の忙しさ
エンドユーザは通常業務に追われており、新システムの検討や確認に割ける時間が限られています。「とりあえず今は余裕がないから、確認は後で」という姿勢が常態化し、結果として本番直前に初めて触ってみるという状況を生み出します。
（3）システムに対するリテラシーの差
現場ユーザの中には、ITやシステムに対する苦手意識を持つ方も多くいます。そのため、要件定義資料や設計ドキュメントを見てもピンとこない。実物を見て初めて「これが自分の仕事にどう関係するのか」が理解できるのです。
4. エンドユーザはなぜGoLive直前まで本気にならないのか？
エンドユーザがGoLive直前まで「本気にならない」ことには、以下のような人間心理が関係しています。
自分が関わる部分しか興味を持たない
全社的なプロジェクトでも、ユーザの関心は基本的に「自分の担当業務」に限られます。システム全体の整合性や他部門との連携には関心が薄く、自分が実際に使う画面や機能に触れない限り、当事者意識は芽生えません。
変化に対する無意識の抵抗
新しいシステムに移行するということは、慣れ親しんだ業務のやり方が変わるということです。人間は本能的に「変化」を嫌います。潜在的な不安やストレスが、ユーザの関与を遅らせているのです。
テストや研修を軽視してしまう
テストや研修が「形式的なもの」「やらされているもの」だと感じているユーザは多いです。しかし、そこには「このフェーズで本気を出さないと本番で困る」という理解が不足していることがほとんどです。
5. この問題の解決策
ROITでは、この「ユーザが本気になるのが遅すぎる問題」に対して、以下のようなアプローチを取っています。
（1）体験から入るプロジェクト設計
紙の要件定義書ではなく、ローコードを使ったプロトタイプや画面モックを初期段階で提示し、「まず見せる、触らせる、気づかせる」設計をします。ユーザは抽象的な議論よりも、具体的な画面を見たときに初めて「これは違う」「こうしたい」と意見を出せるのです。
（2）キーユーザの戦略的活用
現場の業務を深く理解し、かつ社内で影響力のある「キーユーザ」を早期に特定し、プロジェクトの初期から巻き込みます。単なる業務知識の提供者ではなく、「内部エバンジェリスト」として育成することで、現場全体の関心度を高めます。DXを本気で成功させたいなら社内のスタープレーヤーや戦闘力が圧倒的なエリートをプロジェクトメンバーにアサインしなければなりません。
（3）“本気のテスト”を促す仕組み
UATを単なる「テスト」ではなく、実際の業務として使ってもらう「擬似本番稼働」の場として設計します。操作ログを取ってアクティブユーザを可視化し、一定時間以上触れていない場合はアラートを出すといった工夫も有効です。
（4）フェーズ単位でのGoLive設計
全体一括でのGoLiveではなく、業務単位・部門単位での段階的なGoLiveを検討することで、ユーザの学習コスト・心理的負荷を下げ、「少しずつ慣れる」体験を設計します。
（5）経営層の関与
プロジェクトを単なるIT導入ではなく、経営課題として位置づけることで、現場の優先順位を上げます。経営層が「このシステムを使いこなすことが評価に繋がる」と明言することが、現場にとって最も強力なメッセージになります。まずこれがないとＤＸが成功するはずがありません。エンドユーザは自分のことで精一杯で会社の最適化を考えることにインセンティブがはたらきません。そのなかでシステム開発プロジェクトを会社をよくするための営みとしてゴール設定して、全社員の意識を集中させることは必要不可欠です。
6. まとめ
エンドユーザがGoLive直前まで本気にならない問題は、どのプロジェクトにも起こりうる“普遍的な課題”です。
しかし、この問題を「ユーザの責任」として片付けてしまっては、根本的な解決にはなりません。真の課題は、ユーザが“早い段階で本気になれるような設計”がなされていないことです。
ROITでは、システムの完成度だけでなく、「ユーザの体験設計」まで含めたプロジェクトデザインを追求しています。
プロジェクト成功の鍵は、コードではなく「行動」にあります。ユーザが“本気”になる瞬間を、いかに早く、いかに自然に引き出すか。
それこそが、真に価値あるDXを実現するための、新しいSIerの在り方なのです。
最近のコメント