事例：ユーザーが使えないシステム
概要
『これ、本当に現場で使えると思ってるんですか？』。ユーザーテストの場で、事業部門の現場リーダーが口にしたその一言に、会議室の空気が一瞬で凍りつきました。システムは予定通りに動いている。画面もきれいにつくられている。致命的なバグもなく、品質としては一定の水準を満たしているにもかかわらず、現場の誰もが口を揃えて『使えない』と言ったのです。
ここで紹介するのは、著者が数多く見てきた失敗パターンをベースに構成した、ある業務システム刷新プロジェクトの事例です。実在の企業名やプロジェクト内容は伏せていますが、構成されている状況や登場人物、進行上の意思決定などは、いずれも現場で実際に起きていたことをもとに再構成しています。
本事例の舞台は、大手企業における業務システム刷新プロジェクトです。規模は数億円、期間は1年程度。PMO体制を整え、システムベンダーを選定し、IT部門が主導してプロジェクトを進行しました。形式的には計画通りに完了し、システムは問題なくリリースされました。しかし、実態は「動いてはいるが、現場で活用されない」という、まさに典型的な機能不全の誕生だったのです。
ここでは、プロジェクトの経緯を追いながら、どこで何が見落とされていたのか、なぜ、使えないという評価に至ったのかを紐解いていきます。そしてそれらの失敗の背景には、技術力の不足でも、努力不足でもなく、構造的な認識のずれや関係性の歪みが潜んでいたことを明らかにします。
ここで紹介するのは、決して特殊なプロジェクトではありません。多くの現場で「起こりかけている」「かつて経験した」ケースのように感じると思います。失敗の中にこそ、学ぶべき教訓があります。この事例が、次のプロジェクトを「使えるシステム」へと導く一助になることを願っています。
プロジェクトの背景と体制
本事例で取り上げるプロジェクトは、社内で長年使用されてきた業務システムの老朽化を背景にスタートしました。システムは複数の基幹業務を横断的に支えており、機能追加や改修が難しくなっていたことから、刷新が避けられない状況にありました。また、現場業務そのものが複雑化し、属人化が進んでいたため、単なるシステムの置き換えではなく、業務そのものを見直す好機としてプロジェクトが立ち上げられたのです。プロジェクトは社内のIT部門が主導し、以下のような体制で構成されていました。
- PMO：IT部門内の中堅社員を中心とした複数名体制で、全体の統括と調整を担う
- IT部門：プロジェクトのオーナーとして、要件整理・設計方針の策定・進捗管理を主導
- システムベンダー：開発パートナーとして設計・実装を担当。長年の付き合いがあり、信頼関係がある企業
- 事業部門：新システムの利用者。プロジェクト初期における要望ヒアリングの対象
この時点では、関係者の間に、現場の声を反映しながら刷新していこう、という前向きな空気があり、プロジェクトは順調に立ち上がりました。
要件定義でのすれ違い
プロジェクト開始時には、業務要望整理会議と題された場が複数回設けられ、各事業部門から現場の代表者が参加しました。会議では、『在庫照会のレスポンスをもっと早くしてほしい』『レポート作成を自動化できないか』といった具体的な要望が多く寄せられ、現場からも一定の期待が感じられました。
その後、実際に要件定義のドキュメントをまとめ、設計に落とし込むフェーズになると、主導権はIT部門とベンダーに移っていきました。IT部門としては、『過去のシステムを最もよく理解しているのは自分たちであり、業務理解もある程度できている』という認識のもと、効率性を優先する形で要件を整理。ベンダーに設計書の初稿作成を依頼し、それをPMOがレビューしたうえで、事業部門に確認依頼という形で展開する流れが定着していきました。
しかし、ここに大きな落とし穴がありました。作成された設計書は、システム視点で整理された成果物であり、専門用語・画面遷移・データ構造が中心に据えられた内容となっていました。それは、あくまで開発者やIT担当者には読み解けるものであっても、日々の業務を担う事業部門の担当者が本質的に理解するには難解すぎる構成だったのです。
また、ユースケースも一部作成されてはいたものの、その内容はあくまでシステムの画面操作や入力処理に限定されており、業務全体の流れや現場での実際の使われ方までは踏み込まれていませんでした。会議の中では、「確認作業には紙の帳票も併用されている」といった現場の実態が語られる場面もありましたが、そうした情報は、システムには関係ないと判断され、深掘りされることはありませんでした。
結果として、「誰が、どの業務の中で、なぜその操作を行うのか」といった文脈は記録にも残らず、ユースケースの構成は機能単位の断片的なものにとどまりました。「業務の中でその機能がどう使われるのか」「どのような前後関係や補完的作業があるのか」といった現場の運用実態は可視化されず、設計は進められていったのです。
事業部門の担当者は、設計書の説明を受けながらも全体像を掴むことができず、「なんとなくよさそう」「そこまで違和感はない」という曖昧な印象のまま、承認を出していきました。本当に業務にフィットするかどうかを十分に検討することなく、形式的な合意が次々に積み上がっていったのです。
この段階では、『要件定義が終わった』『合意も得た』という達成感がプロジェクト全体に広がっていました。しかし、その合意の中身は、現場が理解しきれていないままの「とりあえずの合意」にすぎなかったのです。現場とIT部門との間で、小さな認識のずれが静かに広がり始めていました。
設計とプロトタイプの欠如
設計フェーズに入ると、システムベンダーがUIのワイヤーフレームを作成し、各画面の操作イメージについて説明が行われました。設計書には画面遷移や入力項目が丁寧に記されており、IT部門からは『これで合意は取れる』と判断されていました。
しかし、そのワイヤーフレームは、実際の業務プロセスに基づいたものではなく、システム内部の機能構成に即した「画面中心の設計図」にとどまっていました。業務の流れ全体が可視化されているわけではなく、画面単位の操作説明が断片的に並んでいる状態だったのです。その結果、次のようないくつかの問題が見え隠れしました。
- 商品検索の導線が業務フローに対して不自然で、必要な情報にたどり着きにくい
- 在庫確認のために複数の画面を行き来する必要があり、操作が煩雑になる
- 承認フローが帳票と連携しておらず、結局紙による並行運用が必要になる
こうした課題はいずれも、業務の一連の流れを前提とせず、画面単位で設計を進めた部分最適の結果として発生したものでした。業務と設計の間にあるギャップが、この時点ですでに表面化していたのです。また、プロジェクトの進行にあたり、動くプロトタイプが提供されることはありませんでした。これは、プロジェクトスケジュールの厳しさや、リソース制約といった現実的な事情に加えて、『ワイヤーフレームで現場の合意が取れているのだから、改めてプロダクトを試作する必要はない』というIT部門の判断があったためです。
実際、現場の担当者もワイヤーフレームの説明を受けた際には、気になる点についていくつか指摘を行っており、『最低限伝えるべきことは伝えた』という感覚を持っていました。また、プロジェクト全体としても、『業務のヒアリングは一通り実施済みであり、それにもとづいて設計が進んでいるのだから、業務に沿った形になっているはずだ』という期待感が共有されていました。
一方で、関係者の間にはコストやスケジュールへの配慮もありました。現場側も、これ以上プロトタイプの開発に時間や予算をかけるのは難しいという認識を持っており、『ワイヤーフレームで大きな問題がなければ、それ以上の確認は不要だろう』という判断が取られたのです。IT部門としても、現場から特段の強い反対意見が出なかったことを受けて、合意は取れていると解釈し、プロジェクトを前に進めていきました。このように、関係者全員がそれなりに納得感を持ちながら、合意形成がなされたように見えていた一方で、実際にはそれぞれが『きっと大丈夫だろう』と思いながら、不安や不確実性を呑み込んでいたのです。認識は微妙にずれたまま蓄積され、やがて「思っていたのと違う」という反応として噴出する下地が、この時点ですでに出来上がっていました。
リリース直前の混乱
ついにユーザーテストの場が設けられました。各部門から選ばれた現場の代表者が集まり、新システムの操作を実際に体験します。操作手順を試しながら、現場の目線でフィードバックを行う重要な機会です。最初の操作説明が終わった直後、ある担当者の口から静かに発せられた一言が、空気を一変させました。
『これ、全然イメージと違います』。この一言を皮切りに、次々と不満や違和感の声があがっていきます。
- 業務の手順と、画面遷移の構造が一致していない
- 本来業務で必要とされる情報が、画面に表示されていない
- 操作ステップが以前より増えており、処理に余計な時間がかかる
その場にいた関係者の多くが、思いがけないほど多くのずれが表面化していくのを目の当たりにしました。
ベンダー側はすぐに反論します。『要件通りにすべて実装しています』『設計書は関係部門の承認を得ています』と。IT部門も「これ以上の仕様変更は現実的に不可能」と姿勢を崩さず、「設計に問題はない」という論理の正しさを貫きました。
一方、現場は「合意したはずの内容」と「実際に触れた操作体験」との間に強いギャップを感じており、それをどう説明してよいかもわからず、混乱していきました。現場が伝えようとしているのは、画面や機能そのものの問題ではなく、業務として使えるかどうかという観点での違和感だったのです。
こうして、現場が抱く「何か違う」という感覚と、開発側が持つ「仕様は正しい」という認識が激しく衝突し、対話が成立しないまま時間だけが過ぎていきました。
表面的には確認は取れていたはずなのに、いざ動かしてみると業務としては使えない。この根本的なずれが、プロジェクト後半における最大の混乱を引き起こす引き金となりました。
リリースと現場の受け止め方
最終的に、システムはそのままリリースされることになりました。理由は明確でした。すでに数億円規模の開発投資がなされており、旧システムとの契約延長や再構築の余地がなかったためです。関係者の間には、「今さら止められない」「やるしかない」という空気が広がっていました。リリース後、現場では様々な想定外の対応が生まれました。
- 一部の作業は、新システムではカバーしきれず、Excelファイルを用いた補完運用が始まった
- 紙帳票による記録が再び持ち出され、帳票を出力して、別途手入力、という手作業が常態化
- クレーム対応では、操作に不慣れなスタッフが手順に戸惑い、1件当たりの対応時間が大幅に増加
業務は止められないため、現場はなんとかして運用に乗せるという方向で動きましたが、その過程での非効率とストレスは非常に大きなものでした。
一方、プロジェクトの上層部では、計画通りにリリースできたという報告が行われていました。要件定義も設計も、合意書類は揃っている。IT部門としても、現場の声は取り入れたとの認識を持っており、プロジェクトとしては一区切りついたように見えていました。しかし、現場の実感はまったく異なっていました。操作が煩雑で、使いたい情報にたどり着くまでの道のりが長い。画面上はモダンであっても、業務に活かせる感覚が薄く、あくまで導入されたから使うものになっていたのです。
誰かが明確な責任を取ったわけでもなく、誰もが、仕方なかったと納得しきれないまま、使えないという評価を受けたシステムだけが、5年間現場に残されることになりました。
現場が主体的にできない構造的な理由
このプロジェクトでは、現場が自らの業務に最も密接に関わっていたにもかかわらず、最後まで主体的に関与することができませんでした。これは個人の姿勢や熱意の問題ではなく、現場が受け身にならざるを得ない構造が、プロジェクトの進め方そのものに組み込まれていたからです。
要件を詰める場面でも、リリース範囲を決める局面でも、あるいは開発中の仕様をすり合わせる場面でも、現場は常に相談される側であり、意思決定する側ではありませんでした。ヒアリングはされていても、それがどう設計や仕様に反映されているのかは見えず、『伝えたはずなのに違う』『現場の実情とは合っていない』と感じることが徐々に蓄積していきました。
なぜ、こうした「現場が関われないプロジェクト」となってしまったのでしょうか。背景には、次の3つの構造的な課題が存在していました。
1．現場に意思決定の役割がないこと
現場の担当者は、プロジェクトにおいて要件や課題を共有する役割は担っていても、優先順位の判断や仕様決定といった本質的な意思決定には関与できない立場にありました。発言はできても、決めることはできない。こうした構図が前提となっていたため、IT部門主導で設計や判断が進み、現場で本当に必要なことが意志決定の場で取り上げられることはほとんどありませんでした。
2．現場が自身のニーズを適切にIT部門に伝えられない構造・プロセス
現場は日々の業務には精通していても、それをIT部門が理解できる形で言語化する機会や支援が十分に整っていませんでした。伝えようとしてもうまく伝えきれない、あるいは、一度言ったから反映されているはず、という期待から、細かな点まで踏み込めないことも多くありました。また、IT部門側も、言ってくれればやる、というスタンスにとどまり、現場のニーズの背景に踏み込むことはありませんでした。伝えられない現場と、深掘りしないIT部門の間に、構造的なすれ違いが存在していたのです。
3．情報共有・関与機会の欠如
プロジェクト全体の運営は基本的にIT部門が主体で推進されており、現場の利用者は「顧客」という立場に置かれていました。進捗や仕様変更の判断もIT部門内で完結することが多く、現場に情報が届くのは開発の終盤、あるいはリリース直前になってからでした。さらに、現場担当者の多くはシステム開発に関する知識や経験を持たないため、『話しても理解されない』『どうせ技術のことはわからない』と暗黙のうちに蔑ろにされてしまう構図もありました。こうした背景から、現場はプロジェクトに当事者意識を持てず、最後まで「自分たちがつくっている」という実感を持つことができなかったのです。
