「前の業者はどうにもならなかった」「今度こそ現場で使われるシステムにしたい」─ システム刷新の相談を受けるとき、発注側の第一声はほぼこの 2 つに集約されます。動かない・使われない・追加費用が積み上がる、といった痛みは、業者を替えたところで再現することがあります。失敗の芽は業者の腕前より前、発注体制のほうに現れる兆候として先に出ているからです。
本記事は、AI 駆動開発のクリエイティブスタジオとして乗り換え相談やセカンドオピニオンの窓口で見てきた不満・SOS を 12 の兆候にカテゴリ整理し、次の刷新で同じ轍を踏まないためのチェックリストにまとめた実務ガイドです。「システム導入失敗」の原因を、業者だけのせいにせず、発注側で握れる部分から言語化していきます。
結論: 失敗は「業者選び」ではなく「発注体制の兆候」から始まる
先に結論を書きます。システム導入の失敗は、悪徳な業者を引いた一発の事故というより、発注体制側の兆候が積み重なった結果として現れます。だからこそ、業者だけを替えても同じ失敗が繰り返され、「乗り換えた先でもバグばかり」「話が通じない担当者にまた当たった」といった声が続きます。
現場では、失敗の原因が要件定義・契約条項・UAT・運用体制のどこかに元をたどれるケースがほとんどです。この記事では、原因を業者相性・費用膨張・引き継ぎ不備・稼働後トラブル・発注リテラシー不足の 5 カテゴリに分け、それぞれから代表的な 2〜3 個ずつ、合計 12 の兆候 を挙げます。1 つでも当てはまるなら、乗り換えかセカンドオピニオンの検討を始める価値があります。
注意
12 兆候のうちどれか 1 つでも当てはまれば、次の刷新でも同じ失敗を繰り返す可能性があります。業者を替える前に、まず発注体制の側で握れる部分を先に整えるのが結果的な近道です。
兆候カテゴリ 1: 業者との相性の失敗 (連絡が遅い・話が通じない)
最初のカテゴリは、業者との日常的なやり取りに出てくる不満です。「システム会社連絡遅い」「連絡こない」「業者に無視される」「放置されている」といった声から、「開発話が通じない」「言ったことをやらない」「対応が悪い」「態度が悪い」まで、コミュニケーション面の SOS がここに入ります。バグや品質の話に見えて、実は上流工程の設計不在が原因、というケースが多い領域です。
「連絡が遅い」「対応が悪い」は上流工程スキップの兆候
連絡の遅さや打ち合わせが噛み合わない感触は、多くの場合、要件定義や設計の合意プロセスが工程として組まれていないことのサインです。合意ドキュメントがないと、業者側は「何をいつまでに返せばゴールか」を握れず、担当者ベースの場当たり対応になります。結果として、担当が変わるたびに話が振り出しに戻り、「システム会社の打ち合わせが意味ない」「担当者が使えない」「下請けに丸投げされている」といった不満が出てきます。
手元で乗り換え相談を受けると、この段階で「そもそも要件定義の議事録がない」「決定事項がチャットの断片にしか残っていない」ケースが目立ちます。運用に乗せるなら、決定と保留を書面に残す運用ルールを、発注側から先に提示します。
「言われた通りにならない」「話が通じない」は要件定義プロセス不在
「言われた通りにならない」「要望が伝わらない」「言い訳ばかり」といった不満は、要件を言葉で渡すだけで完結させている場合に起きがちです。画面イメージ・データの受け渡し・例外時の挙動を、絵と表と実データの 3 点で握らないと、業者側は自分の解釈で埋めるしかありません。専門用語の羅列に発注者が押し切られ、「開発の打ち合わせが苦痛」「専門用語だらけで分からない」となる状況もここに含まれます。
「バグばかり」「動作がおかしい」はテスト設計の欠如
「システム バグばかり」「開発 バグだらけ」「納品されたシステム 動かない」「システム エラー 直らない」「動作 おかしい」「画面 固まる」といった品質面の SOS は、業者のスキル不足だけの話ではありません。テスト設計と受入基準が契約に組み込まれていないと、業者側は「動くように見えたら納品」以上のことを担保できず、稼働後にバグの発生を繰り返します。「システム会社 技術力ない」「業者 スキル不足」と感じる根っこは、テスト工程を発注側が可視化しないまま任せていることが多いです。
FIXITバグばかり出るのって、結局は業者の腕が悪いってこと？
そう見えますが、現場では受入テストの合格条件を発注側が握れていない場合が多いです。
Kaname「動くように見える」で検収してしまうと、稼働後に不具合が積み上がりやすくなります。
FIXIT実業務で 1 週間止まらず回ることを合格条件にする、といった業務目線の基準を先に置きます。
Kaname兆候カテゴリ 2: 費用の膨張 (追加請求・見積もりの不透明)
2 つ目のカテゴリは、費用に関する不信です。「システム開発見積もりが高い」「システム高すぎる」「開発費用ぼったくり」「見積もりがおかしい」といった相場感の悩みから、「追加費用ばかり」「追加請求された」「費用が膨らむ」「予算オーバー」といった稼働途中の膨張、さらには「保守料が高い」「運用費が高すぎる」「保守契約を解約したい」といった継続コストの不満まで含みます。
「見積もりがおかしい」「相場がわからない」は前提条件の不記載が原因
「システム見積書見方わからない」「システム開発人月とは」「システム開発相場わからない」といった状態で受け取った見積もりは、金額の妥当性が判断できません。健全な見積もりには、対象範囲・連携先の数・想定データ量・非機能要件・運用範囲といった前提条件が明記されているはずですが、「一式」だけで金額が組まれた見積書には、そもそも比較の物差しがありません。「システム相見積もりやり方」で悩む場合も、前提条件を発注側から先に固定して各社に投げる方法が、比較の精度を上げる近道になります。詳しい読み解き方は別記事「システム開発の見積もり書を読み解く」にまとめる予定です。
「追加費用ばかり」「予算オーバー」は要件定義曖昧のサイン
追加請求が繰り返し発生する背景には、多くの場合、契約時の要件定義が曖昧なまま「一式」で発注してしまった構造があります。要件が固まっていないと、途中で判明した仕様は原則すべて「追加」扱いになり、金額が積み上がります。回避策は、契約を要件定義フェーズと開発フェーズに分け、要件が固まってから本見積もりを取り直す二段構えにすることです。運用に乗せるなら、変更管理表を発注側で運用し、いつ・誰が・何を追加要求したかを書面で残しておくと、後の押し問答を防げます。
FIXIT追加費用が膨らむのって、業者が最初から狙ってやってるってこと？
整理すると、悪意の話というより、契約の作り方の問題が大きいです。
Shiori要件定義を「一式」で契約に含めると、後から出た仕様は全部追加扱いになります。
FIXIT要件定義フェーズと開発フェーズを分けて、要件が固まってから本見積もりを取り直します。
Shiori分かれ目は、いつの時点の情報で金額を確定させるかを合意することです。
兆候カテゴリ 3: 引き継ぎ・仕様書なしの失敗
3 つ目は、乗り換えや保守移管のときに立ちはだかる「引き継ぎ不能」の問題です。「システム会社 変えたい」「開発会社 乗り換えたい」と思っても、「仕様書ない 引き継ぎ」「仕様書ない 改修」「システム ブラックボックス」「作った人しかわからない」「システム会社 ソースコードくれない」といった状態だと、乗り換え候補すら評価を出せません。
「仕様書がない」「ソースコードをくれない」= 契約時の権利定義不備
引き継ぎ不能の大半は、契約時に「知的財産権 (ソースコード・仕様書・データ) の帰属」を発注者側に明記していなかったことに起因します。ここが業者側の所有と書かれていると、乗り換え時に情報を渡してもらえず、「開発会社倒産引き継ぎ」のような事態では復元不能になります。「システム保守別の会社」に頼みたくても、渡せる資産がなければ他社は見積もりを出せません。契約の権利条項を発注時点で握るだけで、後年の乗り換えコストが大きく変わります。
補足
契約時に「ソースコード・仕様書・データの帰属」「保守契約の解約予告期間」「中途解約時の資産引き渡し義務」を発注者側に有利な形で明記できているかを確認してください。この 3 点を握れているだけで、将来の乗り換え可否と費用が大きく変わります。
「業者と連絡がとれない」「作った人しかわからない」= ブラックボックス化
現行業者と連絡がとれない、担当者がすでに退職している、といった状態も引き継ぎの実務では頻出します。「システム業者乗り換え」を検討する前に、まず現行業者の反応があるうちに、ドキュメント・アカウント・データベースの現物を回収しておくことが大事です。ドキュメントが皆無でも、動いているコード・データベース・現場のオペレーションの 3 点から復元する手はあり、AI 駆動開発でコードベースの読み解きを加速すれば、従来より短い期間で全体像を掴めます。手順の詳細は別記事「システム引き継ぎの実践ガイド」に整理する予定です。
兆候カテゴリ 4: 稼働後のトラブル (現場が使わない・マニュアルがない)
4 つ目は、稼働後に現場から上がる SOS です。「作ったシステムが使いにくい」「システム 現場 使わない」「新システム 不評」「システム 導入 意味ない」「エクセル手作業に戻った」といった声から、「システム マニュアルない」「使い方がわからない」「サポートがない」といった運用不備、さらには「情シスがいない」「システム 誰もわからない」「担当者退職」「社内システムわかる人いない」といった運用体制の欠如まで、幅広い症状がここに含まれます。
「現場が使わない」「マニュアルがない」は UAT スキップ
現場で使われないシステムのほとんどは、UAT (ユーザー受入テスト) を工程から外していることが原因です。開発工程だけで検収し、現場に渡した瞬間に「画面が見づらい」「動きが遅い」「スマホに対応していない」「操作の流れが業務手順と合わない」といった不満が噴出します。使う人の言葉に翻訳したマニュアルもないと、質問を投げる先がなく、現場は自衛のためにエクセル手作業に戻ります。運用に乗せるなら、1〜2 部門で先行運用してもらい、実データで日次入力・月次締めまで一巡させてから全社展開する段取りが安全です。
「エクセル手作業に戻った」「システム導入意味ない」は業務プロセス設計不足
現場で使われないの一段深いところにあるのが、業務プロセス自体の設計不足です。既存のエクセル運用を機能一覧に写して発注すると、システムはできても業務は変わらず、二重入力の負担が増えて元に戻る、という結果を招きます。「システム費用回収できない」「システム開発始末書」といった状況は、費用が高かったからではなく、業務改善の設計を業者に丸投げしていたことに原因があります。既存業務のうち何をなくす・何を減らす・何を残すかを、発注側が先に決めてから設計に入ることが、費用回収の前提です。
「情シスがいない」「システムを誰もわからない」は運用体制の未定義
稼働後の運用体制が定義されていないケースも頻出します。「情シスがいない」「システムを誰もわからない」「担当者が退職した」「システム 放置されている」といった状態では、「サーバーが落ちる」「ログインできない」「システム 復旧 遅い」「トラブル業者に繋がらない」といった障害時対応の道筋がありません。運用範囲を契約に明記し、月次のヘルスチェック・障害時の連絡フロー・アカウント権限の棚卸しを工程として組み込む必要があります。あわせて、「情報漏洩」「セキュリティ 不安」「システム データが消えた」といった情報保護の観点も、運用体制の一部として設計するのが現場では現実的です。
FIXIT現場では、機能はあっても業務手順と噛み合わずエクセル手作業に戻る、というのが典型です。
Kaname「使いにくい」「見づらい」の裏に、UAT を工程から外している構造が隠れていることが多いです。
FIXITまず 1〜2 部門で実データを流し、月次の締めまで通してから全社展開に移します。
Kaname運用に乗せるなら、マニュアルと問い合わせ窓口も同時に整えます。
兆候カテゴリ 5: 発注リテラシー不足の失敗
5 つ目は、発注側の準備不足に起因する失敗です。「システム直すどこに頼む」「システム相談どこに」「システム開発何から」「アプリ作りたいわからない」「システム化丸投げ」「業務効率化どこに頼む」「IT 化丸投げ」「DX 丸投げ」といった、そもそも発注の入口で立ち止まっている状態も、失敗の温床になります。悪気なく丸投げに近い形で発注してしまい、結果として業者と目線が合わない、という構図です。
「要件定義がわからない」「用語がわからない」担当者への処方箋
「システム要件定義わからない」「要件定義何をすればいい」「システム用語わからない」「開発専門用語だらけ」「システム会社コミュニケーションとれない」「文系システム担当」「システム担当押し付けられた」「素人システム開発依頼」といった状態で発注を任された担当者は少なくありません。この場合、いきなり RFP (提案依頼書) を書こうとせず、まず現状業務を「入力・処理・出力」の 3 段で棚卸しするところから始めるのが現場では現実的です。用語より、業務の言葉で書いた業務フロー図があれば、業者側が要件定義を伴走してくれます。丸投げに見えない発注の形を、発注側の 1 枚のフロー図で作れます。
「システム 相談 どこに」「業者の探し方」= セカンドオピニオンの選び方
「システム 業者 探し方」「良いシステム会社の特徴」「優良開発会社の見分け方」「失敗しないシステム会社」「システム開発 口コミ」「悪徳システム会社 見分け方」「システム 業者選び わからない」といった悩みには、いきなり本発注ではなく、セカンドオピニオンや診断窓口を挟むのが安全策です。「システム 相談 無料」「システム 見積もり 診断」「システム開発 セカンドオピニオン」「システム 評価 第三者」「システム会社 監査」「IT 相談 窓口 企業」「システム アドバイザー」「システム 顧問 欲しい」といった検索意図は、まさに「発注する前に第三者の目を通したい」という発注側の防衛策です。相見積もり自体が難しいなら、まず 1 社に既存の見積もりを診てもらう形から入ると、判断の物差しが増えます。
FIXIT担当を押し付けられた文系の人でも、要件定義ってできるの？
整理すると、いきなり RFP を書こうとせず、現状業務の棚卸しから始めるのが近道です。
Shiori入力・処理・出力の 3 段で書いた業務フロー図があれば、業者は要件定義に伴走できます。
FIXITでも、その業者選びから間違えたら意味なくない？
優先順位で言うと、いきなり本発注より、セカンドオピニオン窓口で判断軸を作る方が先です。
Shiori見積もりだけ第三者に診てもらう形なら、契約リスクを負わずに始められます。
FIXIT のセカンドオピニオン窓口として使えるとき
ここまで挙げた 12 兆候のうち、業者を替える前に第三者の目を通したい、既存の見積もりと乗り換え候補を並べて判断軸を作りたい、といった場面では、FIXIT の見積もり診断・乗り換え相談を使っていただけます。AI 駆動開発のクリエイティブスタジオとして、既存コードとデータベースからの引き継ぎ可否、要件定義の再整理、リプレイスの現実的なスコープと期間の見立てまで、初回相談で概観をお返しする流れです。
すぐに乗り換えを決めなくても構いません。現状把握と選択肢の整理だけの利用でも受けています。詳しくはシステム刷新・リプレイスのサービスページをご覧ください。
失敗を避けるチェックリスト (12 兆候の再掲)
最後に、ここまでの 5 カテゴリを 12 の兆候にまとめ直します。次の刷新の着手前・既存業者の見直し時に、そのままチェックリストとして使えます。
| # | カテゴリ | 兆候 |
|---|---|---|
| 1 | 業者相性 | 連絡が遅い / 無視される / 打ち合わせが噛み合わない |
| 2 | 業者相性 | 話が通じない / 言われた通りにならない / 担当者が使えない・下請け丸投げ |
| 3 | 業者相性 | バグばかり / 納品後も動かない / エラーが直らない |
| 4 | 費用膨張 | 見積もりが「一式」で前提条件がない / 相場が判断できない |
| 5 | 費用膨張 | 追加費用ばかり / 予算オーバー / 保守料が上がる |
| 6 | 引き継ぎ | ソースコード・仕様書・データが業者所有で渡ってこない |
| 7 | 引き継ぎ | 作った人しかわからない / 現行業者と連絡がとれない |
| 8 | 稼働後トラブル | 現場が使わない / マニュアルがない / エクセル手作業に戻った |
| 9 | 稼働後トラブル | 費用が回収できない / 業務プロセス自体が設計されていない |
| 10 | 稼働後トラブル | 情シスがいない / 誰もわからない / 障害時の連絡フローがない |
| 11 | 発注リテラシー | 要件定義がわからないまま「一式」で発注してしまう |
| 12 | 発注リテラシー | セカンドオピニオン・第三者評価を通していない |
このうち 1 つでも当てはまるなら、業者を替える前に、まず該当カテゴリを発注側で握り直すことをおすすめします。それでも解けない部分が残ったときに、乗り換えかセカンドオピニオンの窓口を活用してください。次のシステム導入で、同じ痛みを繰り返さないための入口として、本記事を使っていただければと思います。