システムが完成した日、開発チームも経営者も「これで業務が変わる」と確信していた。しかし3ヶ月後、現場を訪れると画面には埃が積もり、スタッフは見慣れたExcelのファイルを開いていた。誰も責めていない。ただ、現場は「こっちのほうが早い」と言った。
このシナリオは珍しくない。むしろ、システム開発プロジェクトの失敗事例の中で最も多いパターンのひとつだ。完成させることに集中するあまり、「使われ続けること」の設計を忘れてしまう。費用が数百万円かかっていても、現場が使わなければ投資の回収はゼロに終わる。
この問題は技術力の問題ではない。仕様通りに動いているシステムが使われない、という現象だ。原因は構造的なところにある。
なぜ完成したシステムが使われなくなるのか
使われないシステムには、共通した構造的原因がある。技術的な問題ではない。むしろ、技術的には正しく動いているにもかかわらず使われない、というケースがほとんどだ。
原因① 現場が要件定義に参加していなかった
要件定義の場に集まるのは、経営者・管理職・IT担当者が多い。現場のスタッフが呼ばれることは少なく、「現場の声」は管理職経由でフィルターされて届く。
管理職が語る「現場の課題」と、スタッフが日々感じている「実際の困りごと」は、しばしば異なる。管理職は「入力ミスを減らしたい」と言うが、現場スタッフが本当に困っているのは「承認待ちで次の作業に進めない時間」だったりする。管理職が「月次レポートの集計を自動化したい」と求めているとき、スタッフは「日々の入力作業が煩雑すぎる」と感じている。この視点のズレは、要件定義の段階で埋めなければならない。
要件定義が管理層の視点で固まると、完成したシステムは管理のための道具になる。現場にとっては「入力する手間が増えただけ」と映る。使われなくなるのは当然の結果だ。
さらに、現場スタッフが要件定義に参加していないと、「このシステムは自分たちのために作られたものではない」という感覚が生まれる。人は自分が関与していないものを受け入れにくい。参加した側には当事者意識が生まれるが、押し付けられた側には抵抗感が残る。
原因② 操作が既存の業務フローと合っていない
人は長年の習慣を変えることを本能的に避ける。これは怠慢ではなく、効率を守るための合理的な判断だ。新しいシステムの操作順序が、それまでの業務の流れと少しでもずれていると、「わざわざ覚え直す価値があるか」という判断が無意識に行われる。
たとえば、受注後に「顧客情報を入力してから案件を登録する」という順序で長年業務をしてきたスタッフに、「まず案件を作成し、後から顧客を紐付ける」システムを渡しても、違和感が先に来る。機能的には同じ結果でも、順序のズレが「使いにくい」という感覚を生む。
画面のレイアウトも影響する。これまでExcelで左から右に視線を動かして確認していた情報が、新しいシステムでは縦に並んでいたり、別タブに分かれていたりすると、「探す時間が増えた」という体験になる。情報の場所が変わることは、思った以上にストレスになる。
システムが現場の業務フローに合わせるのではなく、現場が新しいシステムの操作順序を覚えなければならない設計は、定着を妨げる大きな要因になる。業務フローの分析を要件定義の前に行い、現在の流れをできる限り変えない設計を目指すことが重要だ。
原因③ 「使わなくていい逃げ道」が残されている
移行期間中、多くの現場では新旧システムが並走する。「慣れるまでの間、Excelも使っていい」という配慮が、結果として逃げ道になる。
新しいシステムに詰まったとき、Excelという逃げ道があれば人はそちらに流れる。一度Excelに戻ったデータは、再度システムに入力する手間を生む。その手間が積み重なると、「最初からExcelでいい」という結論になる。
切り替えには締め切りが必要だ。「この日以降、旧方式は使わない」という線引きがなければ、現場は新システムを「使ってもいいもの」ではなく「使わなくていいもの」と認識し続ける。
ただし、逃げ道を閉めることを強制だけで行うと反発を生む。「新システムを使わなければならない」という義務化と同時に、「困ったときに相談できる場所がある」という安心感をセットで提供することが、スムーズな移行につながる。移行直後の数週間は、質問や問題への即応体制を整えておくことが必要だ。
使われるシステムを作るための設計
失敗の構造がわかれば、防ぎ方も見えてくる。それぞれの原因に対して、具体的な対策がある。
要件定義に現場の担当者を巻き込む
要件定義には、実際にシステムを使う現場スタッフを必ず参加させる。管理職の代弁ではなく、本人の言葉で「困っていること」「時間がかかっていること」「ここだけは変えてほしくないこと」を聞く。
現場参加のハードルは、「業務を止めてミーティングに呼ぶ」ことへの抵抗感だ。これを下げるには、1時間以内の短いセッションを複数回設定する方法が有効だ。一度にすべてを聞こうとせず、「今日はこの業務だけ」と範囲を絞る。現場スタッフにとって、「自分の声が反映されている」という実感が、後の定着率に大きく影響する。
また、ヒアリングだけでなく、要件定義書の確認作業にも現場スタッフを参加させることが望ましい。「この記述は実際の業務と合っているか」を現場の目でチェックすることで、管理職フィルターで失われた情報を拾い上げることができる。
プロトタイプで感覚を確認する
言葉で要件を固めても、実際に画面を触るまで「思っていたのと違う」は防げない。開発の早い段階で、動くプロトタイプを現場スタッフに触ってもらう機会を設ける。
この段階でのフィードバックは安い。完成後の修正に比べ、コストも時間も桁違いに少なくて済む。「使いにくい」という感覚を早期に拾い上げることが、定着率を大きく左右する。
プロトタイプを触ってもらう際には、「ここがわかりにくかった」「この操作の順序が違和感ある」という感想を言語化してもらうことが重要だ。「なんか使いにくい」という漠然とした感想を、どの操作のどの場面で違和感が生まれたかまで掘り下げることで、修正の方向性が見えてくる。
段階的移行と「逃げ道の閉め方」を設計する
移行は一気に行う必要はない。業務の中でリスクの低い部分から始め、習熟度が上がったら範囲を広げる。ただし、各段階に「旧方式を使うのはここまで」という明確な期日を設ける。
逃げ道を閉める際は、現場への説明と支援をセットにする。「もうExcelは使えません」だけでは反発を招く。「困ったときの相談窓口」「詰まった時のマニュアル」が揃っていると、心理的な安心感が移行をスムーズにする。
段階的移行のスケジュールを事前に全員に共有することも重要だ。「いつまでに何ができるようになる必要があるか」が見えていると、現場スタッフは自発的に準備を始める。スケジュールが見えないまま「いつの間にか切り替わっていた」という状況は、不信感と混乱を生む。
システムは完成した日が始まりではない
開発プロジェクトは「リリース」を終点として設計されがちだ。しかし現場にとって、リリースは「慣れるための始まり」に過ぎない。
稼働後の3ヶ月が定着の正念場だ。この期間に現場から上がってくる「使いにくい」「ここが困る」という声を拾い上げ、小さな改善を重ねることが、システムを根付かせる。この声を「クレーム」ではなく「改善のための情報」として受け取る姿勢が、開発側にも発注者側にも必要だ。
稼働後に定期的な「振り返り会」を設けることで、溜まっている不満や提案を構造的に収集できる。問題が個人の我慢の中に埋もれている状態を防ぎ、改善のサイクルを回し続けることがシステムの価値を高める。
完成させることと、使われ続けることは別の問題だ。この二つを同時に設計できたとき、はじめてシステム開発は成果を生む。「誰も使わないシステム」を作るために費やした費用と時間の損失は、回収できない。使われるシステムを最初から意図して設計することが、投資を生きたものにする唯一の方法だ。