これは「使われないシステム」の死因を解剖する記事だ。そしてAIが実装速度を劇的に変えた今、その死因への「答え」自体が根本から変わりつつある。
読了時間：約10分
システム開発に携わっていると、ある光景を繰り返し目にする。数ヶ月、ときに数年をかけて作り上げたシステムが、リリースから半年後には誰も開かなくなっている。サーバーだけが静かに動き続け、ライセンス費用だけが毎月引き落とされている。
なぜそうなるのか。我々はこれまで数十のシステム開発に携わる中で、この問いと向き合い続けてきた。社内業務の効率化ツール、顧客向けWebアプリ、AIを活用した新規事業のプロトタイプ。死んでいったシステムを間近で見てきたし、自分たちが手がけたシステムが死んでいくのも経験した。
この記事では、そこから見えてきた「使われないシステムの死因」を具体的に書く。データ管理の失敗、現場との乖離、そして多くの現場が陥る「二択の罠」。さらにAIによって実装速度が変わった今、その罠からの出口がどこにあるかまで踏み込む。
死因①：データが乱立し、入力が二重になる
使われなくなるシステムの、最も多い死因がこれだ。
新しいシステムを導入しても、既存のツールが完全には置き換わらない。営業担当者は顧客情報をAシステムに入れ、進捗管理はBシステム、日報はExcel。気づけば同じデータを3箇所に入力している。誰もそれを「仕様です」とは言わない。ただ気づいたらそうなっていた、という状態だ。
人間は合理的だ。「このシステム、手間が増えただけじゃないか」と気づいた瞬間、静かに使わなくなる。声を上げることすらしない。ただそっと、使うのをやめる。そしてある日、誰もログインしていないことに誰かが気づく。
データソースの乱立は、システムの品質の問題ではない。「導入順序」と「移行設計」の問題だ。既存の運用を無視して新システムを被せると、必ずデータの二重管理が生まれる。
死因②：「作る人」と「使う人」が別世界にいる
要件を決めるのは経営層や情報システム部門。実際に使うのは現場の担当者。この二者が一度も同じテーブルに座らないまま、開発が数ヶ月進む。
完成したシステムは、承認は通る。しかし現場では使えない。入力項目が多すぎる、画面遷移が複雑すぎる、自分たちの仕事の流れと合っていない。現場が「使いにくい」と声を上げると「慣れの問題だ」と片付けられる。慣れない人間はそっとExcelに戻る。
これは現場の怠慢ではない。最初から現場がいない場所で設計されたシステムが、現場に受け入れられなかっただけだ。承認を通すための要件定義と、使われるための要件定義は、まったく別物だ。
死因③：リリースが「終わり」として設計されている
開発プロジェクトは「リリース」をゴールとして動く。要件定義、設計、開発、テスト、リリース。このフローが完了した瞬間、チームは解散し、予算は消化され、次のプロジェクトへ移る。関係者全員が「完成した」と感じる。
だが現場では、リリースの翌日から「使い方がわからない」「ここが不便だ」という声が上がり始める。それを受け取る窓口はない。改善する予算もない。フィードバックは宙に浮き、システムはリリースされた日から劣化し始める。
使われ続けることを、誰も設計していなかった。それだけの話だ。システムにとって、リリースは終わりではなくスタートだ。その認識が最初からなければ、どれだけ丁寧に作っても死に向かって歩き始めることになる。
死因④：「機能追加か、全面リプレイスか」の二択に縛られる
死因①〜③に気づいた組織は、なんとかしようとする。そのとき、たいてい二つの選択肢が浮かぶ。これは「死因」というより、詰んだシステムが陥る末期症状だ。
一つ目は、既存システムに機能を追加して改善する。二つ目は、全面的にリプレイスして作り直す。一見すると合理的な二択に見える。だがどちらも、深刻な罠を抱えている。
機能追加を続けると、機能同士が複雑に依存し合い、既存の動作が壊れるようになる。「この機能を直すと、あの機能が壊れる」という状態が常態化する。壊れないように慎重に実装しようとすると、開発コストが跳ね上がる。改善しようとするたびに、システムは重くなっていく。
では全面リプレイスか。こちらはこちらで、数千万規模の予算と数年単位の時間がかかる。承認を取るだけで半年かかることもある。そうこうしているうちに、現場は「また変わるのか」と白けていく。そして承認が下りた頃には、要件がすでに古くなっている。
機能追加すれば複雑性が爆発する。全面リプレイスはコストが高すぎてGoが出ない。この二択の罠にはまったシステムは、中途半端なまま放置され、そのまま死んでいく。
そこにAIが来た。第三の選択肢が生まれた。
AIの登場で、実装サイクルは劇的に速くなった。以前なら3ヶ月かかっていた開発が、今は数週間で動くものができる。これは単に「速くなった」という話ではない。開発の「コスト構造」が根本から変わったということだ。
コストが下がると、失敗の代償も下がる。1本のシステムに数千万を賭けなくてよくなった分、「うまくいかなければ次を作る」という判断が現実的になる。試行回数を増やせる環境が生まれた。これが、第三の選択肢を可能にした本質だ。
その第三の道とは「新しく作る」だ。既存システムに手を入れるのではなく、新しいシステムとして別に立ち上げる。
データソースの乱立は、初期段階では意図的に許容する。完璧な統合を最初から目指さない。まず小さく作り、現場に触れてもらい、「使いにくい」「この項目はいらない」「この順番が逆の方がいい」というフィードバックをPDCAで拾い続ける。現場の声は不満ではなく、システムを育てるための情報だ。それを積み重ねて、現場の業務フローに本当にフィットした形に近づけていく。
うまく回り始めた段階で初めて、既存システムとのデータ連携を実装する。使われることが確認できてから、初めて統合に投資する。この順序が重要だ。使われるかどうかもわからない段階で統合コストを払う必要はない。
我々自身も、この考え方に切り替えてから社内システムを順番に立て直してきた。勤怠管理、プロジェクト工数管理、キャッシュフロー管理、評価システム、タスク管理。最初はすべて独立して立ち上げた。統合は考えなかった。まず使われるかどうかだけを見た。使われると確認できたものから、順番に連携を実装していった。今では複数のシステムがデータをつないで動いている。その順序が正しかったと思っている。
まとめ
死因 01 データ乱立による二重入力。導入順序と移行設計の問題だ。新しいシステムを被せる前に、既存の運用をどう扱うかを先に決める。
死因 02 現場不在の設計。要件定義の段階から、実際に使う人間を巻き込む。承認を通すための設計ではなく、使われるための設計をする。
死因 03 リリース後の放置。改善の予算と窓口をプロジェクト設計に最初から含める。リリースはゴールではなく、スタートだ。
死因 04 二択の末期症状。機能追加は複雑性を爆発させ、全面リプレイスはコストが高すぎてGoが出ない。この二択しか見えていない時点で、システムはすでに詰んでいる。
AI時代 実装コストが下がり、失敗の代償も下がった。小さく別で作り、PDCAを回して現場にフィットさせ、使われたら育てる。使われなければ学びにする。
「完成させること」がゴールではない。「使われ続けること」がゴールだ。
この二つは似ているようで、まったく違う。完成を目指すと、リリースした瞬間にプロジェクトは終わる。使われ続けることを目指すと、リリースした瞬間にプロジェクトが始まる。その認識の違いが、半年後のシステムの運命を分ける。
そしてAI時代において、「使われ続けること」を目指すための手段は大きく変わった。以前は「作り直すコスト」が高すぎて、動かないシステムにしがみつくしかなかった。今は違う。動かないと判断したら、次を作れる。その身軽さが、システムの生存率を上げる。
数千万かけて使われないシステムを1本作るより、少ないコストで複数試して、使われたものを育てる。その発想が今の正解だ。重く作ることが誠実さの証明だった時代は、終わりつつある。
このシステムの話、他人事ではないと感じた方へ
使われないシステムに悩んでいる、あるいはこれから開発を考えていて同じ轍を踏みたくない。そういった相談を受け付けています。
まずは話を聞かせてください。
