なぜ地方自治体のソフトウェアプロジェクトは失敗するのか —— コードを書く前に防ぐための考え方

はじめに：失敗の原因は技術そのものではない

日本の地方自治体におけるデジタル化プロジェクトは、厳格な調達制度、縦割りの組織構造、担当者の異動、そして長年利用されてきた既存システムへの依存といった、固有の環境の中で進められています。

多くのケースで、プロジェクトが期待した成果を出せない理由は、技術が高度すぎるからではありません。実際の行政業務や運用の現実を前提に、システムが設計されていないことが最大の要因です。

予算は執行され、システムは納品されますが、結果として次のような状況が残ります。

職員は結局 Excel や紙の管理に戻る
住民は窓口での手続きを続けなければならない
部署ごとにデータが分断され、重複が発生する
システム間の連携が実質的に機能していない

見落とされがちな事実は次の点です。

多くの自治体システムは、コードを書く前の段階ですでに失敗が決まっているということです。

地方自治体のソフトウェアプロジェクトが失敗する5つの主な要因

1. 課題ではなく技術から始めてしまう

プロジェクトはしばしば次のような発想から始まります。

「スマート化が必要だ」
「住民向けアプリを作るべきだ」
「AI やクラウドを導入すべきだ」

しかし、本来問うべきなのは次の点です。

どの意思決定を改善したいのか
どの業務が重複・非効率になっているのか
どの情報が遅れて届いているのか

課題を定義しないまま技術を選定すると、期待と現実のギャップは必ず生じます。

2. 要件定義が「調達のため」に書かれている

自治体の要件定義書は

機能要件が非常に詳細である一方
実際の業務フローが十分に反映されておらず
調達手続きを満たすことが主目的になりがちです

その結果、

ベンダーは仕様書通りに開発する
現場では使いにくいシステムが出来上がる
稼働後に大量の改修要望が発生する

仕様書通りでも、業務で使われなければ失敗です。

3. 既存システムを軽視してしまう

多くの自治体にはすでに

財務会計システム
人事・給与システム
住民基本台帳関連システム
GIS や各種業務システム

が存在しています。

新規プロジェクトでは、これらが

簡単に置き換えられる
データ移行は容易である
連携を深く考えなくてもよい

と想定されがちですが、実際にはシステム連携が最も難易度の高い部分です。ここを軽視すると、失敗は避けられません。

4. 成功の基準が「納品」になっている

プロジェクトは次の段階で「成功」と判断されがちです。

システムが導入された
操作研修が実施された
検収が完了した

しかし、本来確認すべきなのは

半年後も職員が継続的に使っているか
手作業や紙の業務が減ったか
判断や対応が速くなったか

利用されないシステムは、存在しないのと同じです。

5. 稼働後の「責任者」が不明確

日本の行政組織では、人事異動や組織改編により

システムの担当者が変わる
プロジェクトチームが解散する
設計意図や知識が引き継がれない

といった状況が起こりやすくなります。

明確なオーナー、文書化、長期運用の視点がなければ、システムは徐々に形骸化していきます。

コードを書く前に失敗を防ぐための考え方

flowchart LR
  subgraph Current_State["現状（よくある状態）"]
    Citizens["住民 / 事業者"] --> Channels["窓口・電話・Web などの受付"]
    Channels --> Forms["紙・手入力による処理"]
    Forms --> DeptApps["各部門の業務システム
（財務・人事・台帳・GIS）"]
    DeptApps --> Excel["Excel や属人化した運用"]
    Excel --> Reports["遅延した報告・重複データ"]
  end

  Current_State -->|"連携設計が不十分"| Pain["職員負担の増大と定着しないシステム"]

  subgraph Target_State["目指すべき姿（現実に即した設計）"]
    Citizens2["住民 / 事業者"] --> Channels2["一貫した受付チャネル"]
    Channels2 --> Case["業務フロー／ケース管理"]
    Case --> API["連携レイヤー（API・メッセージ）"]
    API --> Core["既存の基幹システム"]
    API --> Data["共通データ定義とガバナンス"]
    Data --> Dash["即時性のある可視化・監査"]
  end

  Pain --> Principles["予防的設計の原則
（意思決定起点・業務理解・POC・長期運用）"]
  Principles --> Target_State