naisei.dev › 補助金で作ったシステムが使われていない
補助金で作ったシステムが
使われていない
補助金を使ってシステムを導入した。納品も検収も終わっている。 でも現場では結局Excelに戻っていて、誰も開いていない。 珍しい話ではありません。 なぜそうなるのかを整理したうえで、ここから取れる選択肢を書きます。
この記事は、補助金制度そのものを否定するものではありません。 制度を使って業務が実際に改善した例はたくさんあります。
ただ、補助金という仕組みには、システムが使われなくなりやすい構造的な理由がいくつかあります。 それを知っておくと、いまの状況の整理も、次に何かを作るときの判断もしやすくなります。
使われなくなる4つのパターン
1. 補助金の要件に合わせて作ってしまった
補助金には「この要件を満たすこと」という条件が付きます。 採択されるために、本来の業務課題より、要件を満たすことが目的になっていくことがあります。
結果として、現場がまったく必要としていない機能が仕様書の中心に入り、 一番困っていた作業は「補助対象外だから」と後回しにされる。 納品されたものは要件を満たしているけれど、業務は1ミリも楽になっていない、という状態です。
2. 要件定義に現場が参加していない
申請の準備は、多くの場合事務方と支援事業者だけで進みます。 期限があり、書類の量も多いので、現場を巻き込む余裕がありません。
そして現場が初めてそのシステムを見るのは、納品されたときです。 そこで「いや、うちの手順はこうじゃない」となっても、もう直せません。 予算は使い切っており、変更には追加費用がかかります。
これが一番多い原因だと思います。 システムが失敗する理由は技術ではなく、たいてい「誰が仕様を決めたか」にあります。
3. 運用費が続かなかった
補助金でまかなえるのは、多くの場合導入費用までです。 その後の保守費・ライセンス費・サーバー費は自己負担になります。
初期費用が補助されたことで「安く導入できた」という感覚になりますが、 ランニングコストは補助前提の金額ではありません。 2年目、3年目に予算が付かなくなり、保守契約を切る。 すると障害が起きても直せなくなり、自然に使われなくなります。
4. 分かる人がいなくなった
導入を推進した担当者が異動・退職して、 そのシステムの中身を説明できる人が誰もいない状態です。
操作マニュアルはあっても、「なぜこの項目が必要なのか」「この数字はどこから来るのか」が分からない。 分からないものは触れないので、結局手作業に戻ります。
捨てる前に確認すべきこと
使っていないので廃止したい、と考える前に確認が必要な点があります。
補助金で取得した財産（ソフトウェアが含まれる場合があります）には、 一定期間、自由に処分できないという制限が設けられていることがあります。 いわゆる処分制限です。廃棄・譲渡・目的外での使用をする際に、 交付元の承認が必要になったり、補助金の一部返還を求められたりする場合があります。
制度によって扱いが大きく異なります。 金額の基準や期間、そもそもソフトウェアが対象に含まれるかどうかも、補助金ごとに違います。 自己判断で処理せず、必ず交付元（事務局・自治体の担当課）に確認してください。 この記事は一般的な注意喚起であり、個別の制度の解釈を示すものではありません。
なお、多くの場合「使っていない」こと自体は直ちに問題にはなりません。 問題になりやすいのは、無断で処分したり、報告した用途と違う使い方をしたりした場合です。 手続きの順番さえ踏めば、整理は進められます。
ここから取れる選択肢
A. 使われている部分だけ残して、残りは捨てる
全部が使われていないケースは、実はあまりありません。 「この画面だけは使っている」が1つか2つはあるのが普通です。
まずそれを特定してください。そこがそのシステムの本当の価値です。 残りは「使っていない」と割り切って、無理に活用しようとしないことです。 使わせようとする研修に予算を使うのが、一番もったいない選択です。
B. 現場の手順に合わせて作り直す
いまなら、作り直しの費用は以前より下がっています。 AI開発ツールが実用になったことで、小さく作って、使いながら直すという進め方が現実的になりました。
重要なのは、今度は補助金ありきで考えないことです。 補助金に合わせて仕様を決めた結果が今の状態なら、同じ轍を踏みます。 まず自費で回る規模まで削ってから、その後で使える制度があるかを探す順番が安全です。
C. 既製のサービスに乗り換える
業務が標準的なら、これが一番です。 月数万円のサービスで済むことは珍しくありません。
補助金で作ったシステムがうまくいかなかったからといって、 次も作らなければならないわけではありません。 「作らない」という選択肢を最初に検討してください。
次に作るときに、同じことを繰り返さないために
- 実際に毎日その作業をしている人を、仕様を決める場に入れる。ここを外すと、ほぼ確実に同じ結果になります
- 「今いちばん時間を食っている作業」を1つだけ決めて、そこから作る。網羅的な設計は、使われない機能を量産します
- 5年分のランニングコストを先に計算する。保守費・ライセンス費・サーバー費を足して、その予算が毎年取れるかを確認します。取れないなら、その構成は選べません
- ソースコードと設計情報を自社に残す。契約書で権利の所在を確認してください。これが無いと、業者を変えた瞬間に何もできなくなります
- 「なぜこう作ったか」を文書で残す。操作マニュアルより重要です。担当者が代わったときに生き残るかどうかが、ここで決まります
使われていないシステムがあること自体は、失敗ではありません。 何が必要で何が不要だったかという、かなり具体的な情報が手元に残っています。
それは次に何かを作るとき、あるいは既製サービスを選ぶときに、 そのまま判断材料として使えます。整理する価値のある資産です。
いまある状態を、一度整理してみませんか
何が使われていて、何が使われていないのか。作り直すべきか、既製品に移るべきか。
「いまのシステムを使い続けるのが一番いい」という結論でも構いません。
初回30分の相談は無料で、営業目的の折り返しは一切ありません。