総務消防委員会資料

令和２年１２月
総 合 企 画 局

大型汎用コンピュータオープン化事業の総括について
大型汎用コンピュータオープン化事業（以下「オープン化事業」という。）につきましては，市会から度重なる付帯決議，警告を受けており，改めて市民の皆様，市会の皆様に深くお詫び申し上げます。
この度，これまでの付帯決議・警告，令和元年度決算に付された意見を踏まえ，オープン化事業に係るこれまでの総括を取りまとめましたので，御報告いたします。
今後，事業の再構築に当たりましては，このような事態を起こすことがないよう，反省すべき点を真摯に反省し，教訓にしていくとともに，これまでに開発したシステムをできる限り活用するなど，市民負担の軽減を図りながら，国との緊密な連携の下，再構築に全力を挙げて取り組んでまいります。
１

事業概要
本市では，国民健康保険，介護保険，税，住民基本台帳（住基）などの基幹業務をはじめとする１７業務１０３事務（令和２年１２月現在）の電算処理を行うシス
テムについて，３０年以上，特定事業者の固有の技術で作られた大型汎用コンピュータを利用して運用してまいりました。
オープン化事業は，この機器及びシステムについて，一般に広く利用されている最新技術により刷新しようとするものです。
コンピュータのダウンサイジング化（小型化）や，生産年齢人口減少等に伴うＩＣＴ人材不足により，大型汎用コンピュータ市場が縮小の一途にあり，オープン化が避けられない社会情勢にあって，本市では平成２６年度にオープン化事業を開始しました。
他の政令指定都市では既に段階的なオープン化が進められており，本市は，後発であったこともあり，全システムをほぼ同時にオープン化する計画としました。

- 1 -

２

事業経過

平成 24～25 年度 開発手法の調査･分析，平成 26 年 3 月 実施計画策定

平成 26 年度

事

業

開 始

【稼働予定時期】福祉系
住基・税系

平成 29 年 1 月
平成 29 年 11 月

平成 27 年 8 月
一括処理システムの開発手法をマイグレーション方式に変更

平成 29 年 1 月

一括処理システム開発遅延（１回目）
大型汎用コンピュータオープン化事業検討委員会（平成 29 年 2 月設置，6 月調査報告書提出）

平成 29 年 2 月市会 付帯決議

平成 29 年 11 月

事 業 再 構 築【稼働予定時期】福祉系
住基・税系

平成 29 年 11 月市会 付帯決議

令和 2 年 1 月
令和 2 年 2 月市会

令和 2 年 9 月

令和 2 年 1 月
令和 3 年 1 月

一括処理システム開発遅延（２回目）
警告及び
付帯決議

開

発

中

断

令和 2 年 9 月市会 決算に付す意見

- 2 -

〔状況〕
・令和２年度内の全面的な稼働が見通せない・自治体システム標準化への対応の必要性↓
こうした状況を踏まえ，
一部を除き開発を中断し，・標準化を前提とした事業の再構築を図る。
・標準化の対象外で稼働が見込める 15 事務は，開発を継続し，令和２年度内の稼働を
目指す。

⑴

実施計画の策定（平成２６年３月）
平成２４～２５年度に行った開発手法等に係る調査を基に，平成２６年３月に実施計画を策定しました。
・目

的：①行政サービスの向上②業務の効率化③コストの削減・効果：①調達に競争性が働き，運用経費が削減できる。
②最新技術を活用した行政サービスの提供が早期に可能となる。
③制度改正や業務改善に迅速に対応できる。
④被災時でも早期に復旧が可能となる。

・事 業 費：９４．６億円
・事業期間：４箇年（平成２６～２９年度）
・稼働時期：福祉系システム

平成２９年

住基・税系システム

１月

平成２９年１１月

・開発手法：高速開発ツールを利用したスクラッチ開発（通常，一つ一つ手作業で行うプログラムの製造を，基本設計や詳細設計のデータから自動生成するツールを用いた開発方式）＜当初スケジュール＞
平成26年度 平成27年度 平成28年度 平成29年度 平成30年度

全体管理

工程管理支援工程管理支援

技術支援

技術支援

設計・開発

共通基盤（※１）構築

シ
ス
テ
ム
開
発

国民健康保険オン
後 期高 齢者 医療ラ
イ 福 国 民 年 金ン 祉 介 護 保 険
シ 系
児 童 手 当ス
現行システムテ
障 害 者 福 祉
分析
ム
福
祉
医
療
（
※
２
）

仕様書
作成，
調達準
備

運用

設計・開発

運用

設計・開発

運用

設計・開発

運用

設計・開発

運用

設計・開発

運用

設計・開発

運用
運用

設計・開発

住民基本台帳

（※３）

設計・開発

設計・開発

税

一括処理
システム

運用

運用

設計・開発

福祉系

設計・開発

住基・税系

運用

運用

（※１）共通基盤…各業務システムで共通する必須の機能であり，オープン系サーバ機器とその上に構築されたソフトウェア群。例えば，職員認証や文字コードなどを，各
業務システムが共通で利用できるようにするもの（※２）オンラインシステム…区役所の窓口等において，端末機から入力した各種申請等の内容を即時に処理するためのシステム（※３）一括処理システム…国民健康保険の被保険者証を作成するなど，特定日に一定の要件に合致するデータを一つの塊として大量にデータ処理するものであり，定期のデータ更新や納付書の一括処理を行うためのシステム

- 3 -

⑵

開発手法の変更（平成２７年８月）
実施計画においては，オンラインシステム，一括処理システムとも，開発手法
は，高速開発ツールを利用したスクラッチ開発としておりました。
しかし，一括処理システムの開発について，この開発手法では，① 期待する処理性能（処理時間）に達しないおそれがあったこと。
② 工期に間に合わないおそれがあったこと。
から，平成２７年８月，当時の情報化推進室長の判断により，現行システムのプ
ログラムを新システムのプログラムに機械的に変換する「マイグレーション方式」に開発手法を変更しました。（検証について P.18 参照）⑶

事業者選定，システム開発着手（平成２７年８月～）
全体管理（工程管理支援，技術支援），共通基盤構築並びに各業務のオンラインシステム開発及び一括処理システム開発について，順次，事業者を選定のうえ，
システム開発に着手しました。
システム開発の調達に当たっては，事業効果の一つである「調達の競争性」を最大化するため，できる限り分割して調達を行った結果，オンライン，一括処理の各システム開発に計７事業者が参画するマルチベンダー開発となり，複数の市
内中小企業にも受託いただくことができました。
＜全体管理について＞

・ 工程管理支援は，京都市が発注者として行う事業全体の進捗管理に対し，専門的な見地から，課題の指摘や対応策の助言等の支援を行う業務です。
・

技術支援は，複数の業務システムで共通利用する部品の開発や，横断活動（複数事業者が参画する開発工程や作業における事業者間調整等）を行う業務です。（検証について P.18 参照）＜システム開発の調達単位について＞・ 高速開発ツールによるスクラッチ開発を行うオンラインシステムと，マイグ
レーション開発を行う一括処理システムでは，開発手法が異なるため，別々に調達を行いました。
・ オンラインシステムは，できる限り業務ごとに細分化しました。
・ 一方で，一括処理システムは，プログラムを変換するツールを一つ作成すれば，全ての業務で汎用的に利用できるため，効率性の観点から，業務ごとではなく全業務をまとめて調達しました。

- 4 -＜受託事業者一覧＞
全体管理
共通基盤
構築
オンライン
システム
開発

委託業務
工程管理支援受託事業者
ピースミール・テクノロジー株式会社

技術支援
ハード基盤

公益財団法人京都高度技術研究所
セコムトラストシステムズ株式会社

ソフト基盤
福祉系

国民健康保険

日本電気株式会社
公益財団法人京都高度技術研究所

後期高齢者医療
国民年金

株式会社ＤＴＳ ＷＥＳＴ
システムプロデュース株式会社

介護保険
児童手当

公益財団法人京都高度技術研究所
株式会社ケーケーシー情報システム

障害者福祉
福祉医療
税
住民基本台帳
全業務

公益財団法人京都高度技術研究所
株式会社アルバス
株式会社ＤＴＳ
株式会社アルバス
株式会社システムズ（平成 29 年 10 月契約解除）↓
キヤノンＩＴソリューションズ株式会社（平成 30 年 3 月契約締結）

住基・税系
一括処理
システム
開発

福祉系
住基・税系

＜開発作業の流れ＞
個別システムの開発

一括処理
システム

プログラム設計･製造業務ごとに一括処理システムとオンラインシステムの連携等を確認する。

システム全体の業務間のデータ連携等を
確認する。

発注者が
動作や品
質を確認
する。

テスト
総合

システム単体で不具合を見つけ出し，設計・製造を繰り返して，品質を高めていく。

各ｵﾝﾗｲﾝ
システム

テスト

全体
システム
テスト

受入

データ

テスト

移行

プログラム設計･製造
テスト

- 5 -

各テストで不具合が発生し，個別システムに起因する場合，
個別システムを修正する。

稼働

⑷共通基盤の稼働（平成２８年１０月）
各業務システムで共通利用するシステムを集約した共通基盤については，当初予定どおり構築を終え，平成２８年１０月に本番稼働しており，この共通基盤を利用して，マイナンバー連携システムなどのオープン系システムが稼働しています。

⑸

一括処理システム開発の遅延（１回目）（平成２９年１月）
福祉系の各業務システムについては，平成２９年１月の稼働を予定していましたが，平成２８年１０月，一括処理システム開発の当時の受託事業者（以下「前事業者」という。）から，開発が稼働予定日に間に合わない旨の申出がありました。一括処理システムの開発遅延によって，オンラインシステムとの連携ができなくなることから，オンラインシステムも含めた福祉系システム全体について稼働を延期せざるを得ない状況となりました。

＜１回目の遅延時の開発進捗状況＞（▼印まで進捗）
システム単体の開発の初期段階で遅延が発生

福祉系
一括処理
システム

▼
プログラム設計･製造
テスト

各ｵﾝﾗｲﾝシステム▼
プログラム設計･製造

全体
システム
テスト テスト
総合

受入

データ

テスト 移行稼働テスト⑹

大型汎用コンピュータオープン化事業検討委員会の設置（平成２９年２月）
本市は，新システムの早期稼働に向け，前事業者と開発作業を継続しつつ協議を進めましたが，遅延の原因について見解の相違があったため，第三者の専門家に遅延の原因究明と最良の方策の検討を行っていただくこととしました。
そのため，平成２９年２月，「京都市大型汎用コンピュータオープン化事業検討委員会」（以下「検討委員会」という。）を設置し，「遅延に係る原因の究明に関すること」及び「今後の最良の方策に関すること」を諮問いたしました。

- 6 -

⑺

平成２９年２月市会付帯決議（平成２９年３月）
平成２９年度当初予算については，編成時点において，新システムの稼働時期，所要経費等，事業の見通しを確定させられていない状況であったため，福祉系シ
ステムの稼働を平成３０年１月と想定し，平成２９年２月市会に提案いたしました。
この予算に対しまして，・ 検討委員会の議論を経て本市が方向性を定めた際には速やかに議会に報告を行い，徹底的に議論し，必要があれば予算の修正を行うこと。
・ 一括処理システムに係るオープン化の開発手法をマイグレーション方式に変更した経過について，早期に解明し議会に報告すること。
・ 現状想定外の支出が続いていることを鑑み，猛省のうえ事業の推進に当たること。
との内容の付帯決議が付されました。
⑻

検討委員会から調査報告書の提出（平成２９年６月）
検討委員会では，平成２９年２月から６月の間に計７回の委員会が開催され，遅延原因や今後の開発の進め方について検討が行われ，同年６月，本市に対し「調査報告書」が提出されました。
調査報告書では，遅延原因として，前事業者の初期作業品質の低さに起因するテスト計画書の修正・レビューの繰り返しや，前事業者の契約上の義務についての認識の甘さ，プロジェクト・マネジメント義務を負う開発受託事業者としてプロジェクトを進捗させるために契約上なすべき各種説明や調整といったコミュ
ニケーションの不十分さ，早期に課題を洗い出し解決しようとする姿勢の欠如が指摘されました。
また，今後の最良の方策として，新規事業者の下で現在の開発スキームを継続するか，又は，いったん現行の一括処理システムを新規のオンラインシステムに接続し，その運用を行いつつ，改めてオープン化を進める選択肢が現実的であるとの結論が示されました。
あわせて，新規事業者の調達に際しては，単なるマイグレーション開発の経験だけではなく，プロジェクト・マネジメントや保守運用段階への視点を含めたシ
ステムインテグレータ（※）的業務の受託実績や，自治体との取引経験を加味した選定を行うことも考慮に値するとされました。
（※）システムインテグレータ…複数の情報システムを統合し，一体のシステムとして企画・立案から完成後の保守・管理までを一括して総合的に請け負う事業者のこと。

- 7 -

⑼

一括処理システム開発事業者との契約解除（平成２９年１０月）
調査報告書の内容も踏まえ，本市は，客観的にも前事業者の債務不履行が認められると判断し，その判断を基に前事業者と問題解決に向けた協議を重ねましたが，解決には至りませんでした。
福祉系システムがいまだ完成していない状態であっただけでなく，住基・税系システムについても，開発作業の初期段階の作業の完了の報告がなく，納期が遵守される見込みは全くなかったことから，全体として社会通念上履行不能であると判断し，前事業者との契約を平成２９年１０月に解除いたしました。
なお，これに伴い，本市から前事業者に対し，本市が支払った契約代金の返還と，遅延により本市が被った損害に係る賠償等を求め，平成２９年１１月市会の議決を経て，平成３０年２月に訴えを提起しております。
一方，前事業者から本市に対しては，平成２９年１１月に平成２９年度第１期分の作業代金の支払を求める訴えが提起されています。
⑽

事業の再構築（平成２９年１１月）
前事業者との契約解除に伴い，新システムの早期かつ確実な稼働の実現に向けて事業の再構築を行いました。調査報告書では，新規事業者の下で開発スキーム（マイグレーション開発）を継続するか，又は，現行の一括処理システムを新規のオンラインシステムに接続し，その運用を行いつつ，改めてオープン化を進める選択肢が現実的であると示されました。そこで，①品質，②コスト，③開発期間や，開発が進んでいるオンラインシステムの開発成果を可能な限り利用する等の観点から検討を行った結果，新規事業者の下でマイグレーション開発を行うことが期間及び費用等の面で最も適していると判断し，福祉系システムは令和２年１月，住基・税系システムは令和３年１月の稼働を目指すこととして，再構築に必要となる補正予算を平成２９年１１月市会において提案いたしました。
⑾

平成２９年１１月市会付帯決議（平成２９年１２月）
事業の再構築に係る平成２９年度補正予算及び前事業者に対する訴えの提起
に対し，・ 事業の再構築に当たっては，更なる猛省のうえ，市民負担が生じないよう事業を推進し，福祉系システムの令和２年 1 月稼働及び住基・税系システムの令
和３年 1 月稼働を確実に実現するとともに，追加費用の発生や追付き作業の状況をはじめとする事業の進捗状況を適宜議会に報告すること。
・ 同事業に係る損害賠償請求訴訟については，訴訟体制に万全を期し，市民負担を避けること。
との内容の付帯決議が付されました。
- 8 -

⑿

一括処理システム開発事業者の再選定（平成３０年３月）
一括処理システム開発事業者の再選定に当たっては，調査報告書の内容や議会からの御指摘を踏まえ，総合評価方式を採用し，評価項目として，システムイン
テグレータ的業務の受託実績や，自治体との取引経験などを加味しました。
総合評価方式による一般競争入札の結果，平成３０年３月に，新たな一括処理システム開発事業者を選定しました。
⒀

再構築後の開発状況（平成３０年４月～令和元年１２月）
平成３０年度から再開した一括処理システムの開発については，事業者との隔週で進捗会議を行うことに加えて，1 回目の遅延を踏まえて四半期に一度は経営層を含めた報告会を実施して事業者との意思疎通に労力を払いながら，システム開発の進捗を図りました。また，オンラインシステムについては，単体としては完成していたことから開発期間中の制度改正によるシステム修正を新システムに反映する「追い付き作業」に加えて，改元作業に取り組んでおりました。
一括処理システムの開発が単体レベルで一定の進捗が見られた令和元年度からはオンラインシステムとの業務連携を確認する総合テスト，システム全体での連携を確認する全体システムテストへ工程を進めました。しかし，そこで不具合が発生し，事業者はその収束のために人員を多数投入しましたが，稼働時期が迫っても収束することができませんでした。

＜令和元年１２月時点における開発進捗状況＞（▼印まで進捗）
全体システムテストで，一括処理システム起因の不具合が発生。一括処理システムの修正を繰り返しているが，不具合が収束できない。

福祉系
一括処理
システム

プログラム設計･製造

▼

テスト

全体
システム
テスト テスト
総合

各ｵﾝﾗｲﾝシステム

プログラム設計･製造
テスト

- 9 -

受入

データ

テスト 移行稼働

⒁一括処理システム開発の遅延（２回目）（令和２年１月）
令和元年１２月，一括処理システムの開発事業者から，開発工程の最終段階において生じている不具合を収束させることができず，令和２年１月に福祉系を本番稼働できる品質確保は困難で，品質確認のためのテストが必要と判断する，との報告がありました。このため，オンラインシステムも含めた福祉系システム全体について稼働時期を延期せざるを得ない状況となりました。

⒂

令和２年２月市会警告及び付帯決議（令和２年２月～３月）
令和２年２月市会には，遅延に伴い新システム開発費を翌年度に繰り越す令和
元年度補正予算，及び新システムの開発を継続する令和２年度当初予算を提案いたしました。
この令和元年度補正予算に対しまして，

・ 平成２９年３月の付帯決議では，猛省のうえ事業推進に当たること，平成２９年１２月の付帯決議では，更なる猛省のうえ，市民負担増や計画遅延がない
よう指摘し，進捗状況の議会への報告を求めた。しかしながら，令和元年末の総務消防委員会において初めて福祉系システムの遅延が報告されるなど，付帯決議の内容が守られていない。また，福祉系システム稼働日程が示せないなど，
市民理解を得るには程遠い内容である。
・ 稼働日が示されない中での補正予算提案は遺憾である。よって，三度猛省を促すとともに，早急に体制を整え，課題への対応策を見極めたうえで，責任の所在を明確にし，十分な総括を行い，市民に理解が得られる内容を議会に速やかに報告することを求める。
との内容の警告を受けております。
さらに，令和２年度当初予算に対しまして，・ 令和元年度予算への警告を受け，体制の強化は早急に行われたものの，依然として稼働時期は示されておらず，これを示す時期すらも明確とはなっていな
い現状では，本予算の執行に当たっての市民への説明として不十分である。
・ 市民の十分な理解が得られるよう警告で指摘した内容を速やかに実行することを強く求める。
との内容の付帯決議が付されました。

- 10 -

⒃体制整備による課題の整理と対応策の見極め（令和２年３月～９月）
市会からの警告を踏まえ，令和２年３月１日付けで職員を増員して体制を整え，一括処理システムの不具合の解消に努めるなど，引き続き開発作業を進めると同時に，課題の整理と対応策の見極めを行いました。
開発作業については，令和２年３月末までに一括処理システムの不具合が一定収束し，同年７～８月に，福祉系の全ての業務システムの開発事業者が参画し，業務間の連携や，一括処理システムとオンラインシステムのデータ連携などの確認を行う全体システムテストを改めて実施しました。
当初，一括処理システムの不具合収束後速やかに全体システムテストを開始する予定でしたが，福祉系と住基・税系システムの開発作業が輻輳し，事業者間の調整に時間を要するとともに，令和２年４月に新型コロナウイルス感染症緊急事態宣言が発出され，感染防止対策のため一時的な開発体制の縮小を余儀なくされたことなどから，テストの開始までに期間を要することとなりました。

- 11 -

⒄

開発中断（令和２年９月）

ア 令和２年９月時点における開発の状況
福祉系システムについては，オンラインシステム，一括処理システムともに，
システム単体としてはおおむね完成していましたが，７～８月に実施した，各業務の開発事業者が参画して本番と同じ環境で行った全体システムテストで，システム単体の動作検証は出来たものの，複数の業務を同時に実行する場合などに課題が発生しました。
住基・税系システムについては，システム単体としては福祉系と同様におおむね完成しているものの，全体システムテストの実施は，福祉系の稼働を前提としていたため，その着手に遅れが生じました。
＜開発中断時の開発進捗状況＞（▼印まで進捗）
全体システムテストで
課題が発生

福祉系
一括処理
システム

プログラム設計･製造▼

テスト

各ｵﾝﾗｲﾝシステム

プログラム設計･製造

全体
総合
システム
テスト テスト

受入

データ

テスト 移行

稼働

テスト

住基・税系
一括処理
システム

全体システムテストの着手に遅れプログラム設計･製造

▼

テスト

全体
システム
テスト テスト
総合

各ｵﾝﾗｲﾝシステム

プログラム設計･製造
テスト- 12 -

受入データ

テスト 移行稼働

イ 国における自治体システム標準化の加速を受けての開発中断
コロナ禍を受けて，国においては，１７の行政分野※１を対象に，これまで各自治体がバラバラに構築してきたシステムの仕様の統一を図る自治体システ
ム標準化（以下「標準化」という。）の動きを加速させ，令和２年７月に閣議決定された「骨太の方針２０２０」では，標準化を早急に推進するため，・法制上の措置を講じたうえで，財源面を含め国が主導的な支援を行う。

・

関係府省庁は内閣官房の下この１年間で集中的に取組を進める。

・

年内に標準を設ける対象事務の特定と工程化を行う。

とされました。
令和２年９月には，菅首相が，令和７年度末までを目標期限に設定し作業を加速することを表明され，これを受けて同月，総務省から「自治体業務システ
ム統一・標準化加速策」が公表され，自治体に対し標準化への対応を義務付ける方向性が明確にされました。
このため，本市のオープン化事業が完成し稼働したとしても，近い将来，時を置かずに標準化に対応するため，再度のシステム改変が必要となることが見込まれました。
また，このまま開発を継続するにも時間と経費が必要であり，加えて，稼働に当たっては，日々の保守運用体制のほか，法改正や制度改正等に対応する大規模改修が実施できる体制を構築する必要がありますが，幅広い業務分野にまたがる一括処理システムの改修全てに対応できる事業者の確保の見通しが立っていない状況にありました。
こうした開発の状況や稼働の見通し，コロナ禍における標準化の急加速といった情勢の変化について，市長は総合的に勘案し，立ち止まるなら今しかないと決断を下し，標準化の対象外で令和２年度内の稼働が見込める一部システム（全 103 事務のうち 15 事務※２）を除き，独自システムの開発は中断し，標準化を前提とした事業の再構築を図ることといたしました。
（※１）標準化対象の１７行政分野
行政分野

標準仕様書の策定時期

住民基本台帳令和２年９月

介護保険，障害者福祉，就学，固定資産税，
個人住民税，法人住民税，軽自動車税

令和３年夏（予定）

選挙人名簿管理，国民年金，後期高齢者医療， 令和４年夏（予定）
生活保護，健康管理，児童手当，児童扶養手当，
子ども・子育て支援
国民健康保険別途検討- 13 -

（※２）稼働可能と見込む 15 事務
予防接種，緊急通報システム，特別障害者手当，老人ホーム，
生活貸付，心身扶養共済，高校進学・修学支援金，
避難行動要支援者名簿，土地利用・許可申請台帳，
有料指定ごみ袋，道路占用料，民間給与実態調査，職員給与実態調査，採用試験，職員健診⒅

令和元年度決算に付す意見（令和２年１０月）
令和２年９月市会におきまして，令和元年度決算に対し，・ 決算の審議でも，市長は自ら責任を認めたが，事業断念の背景として，１度目の遅延は受託者の責任，２度目の遅延はより高いレベルを求めた結果や新型
コロナウイルスによる影響であるとの説明など，行政の反省になっているとは言えない状況である。
・ さらに，現在の損失額も算定できないなど，市民に理解が得られる状況とはなっていない。
・ ついては，事業の総括を行い，損失額も含めて市民に説明できる内容を，早急に議会に報告することを求める。
との内容の意見を付されました。

- 14 -

３

財政的な損失について
この度の事業中断，再構築に伴う財政的な損失につきましては，今後の進め方によって増減するものですが，事業の総括に当たって一旦清算すべきとの認識から，一定の仮定をおいて最大の損失額を積算しました。
今後の事業再構築に当たりましては，国の財源確保はもとより，これまでに開発したシステムをできる限り活用するなど，再構築に係る経費を低減することによって，全体として市民負担を少しでも軽減できるよう全力で取り組んでまいります。
⑴

実際の支出経費のうちの損失額の考え方
オープン化事業には新システム開発経費９５．２億円のほか，開発期間中の制度改正等に対応するための追付き改修経費，事業の計画段階における調査費なども合わせ，平成２４年度から令和２年度までの累計で１１６．７億円の支出を見込んでいます。
全てが無駄になるわけではなく，既に稼働しているシステム，令和２年度内に稼働予定のシステム，また，将来的に活用の可能性があるシステムもあります。
しかし，効用が発揮できているのは，平成２８年度に完成し稼働している共通基盤システムなど１６．８億円相当であり，これを差し引いた９９．９億円が最大の損失額と考えております。
（単位
項

目

億円）

支出額

新システム開発経費

９５．２

オンラインシステムや一括処理システムの開発等

７１．６

共通基盤など稼働しているシステムの構築・保守☆

８．５

機器購入・保守☆

８．３

開発環境の整備等

６．８

開発期間中の制度改正等に対応するための新システムの改修経費（追付き対応）１４．２

開発期間後の制度改正等に対応するための新システムの改修経費

１．７

開発手法の調査・分析

０．２

前回の一括処理システム開発事業者への既払い金

５．１

訴訟等に要した経費（裁判所手数料等）

０．３

合

計

１１６．７

うち

効用が発揮できているもの（☆印）

１６．８

うち

最大の損失額（☆印を除いたもの）

９９．９- 15 -

⑵

想定上の逸失利益の考え方
新システムでは，一般に広く使用されている技術を用いることから，特定事業者固有の技術に基づく現行システムと比較して，システムの経常的な保守や機器賃借等に係る保守運用費や，毎年度のように実施されている制度改正等に対応するための改修費の削減が見込まれます。
この削減効果が発揮できないことによる逸失利益を損失額として，一定の仮定の下で積算しました。
現行システムを国が示す標準化システムへの移行期限である令和７年度末まで活用すると想定すれば，平成２９年１月（当初の新システム稼働予定時期）から令和７年度末までの期間の逸失利益は，累計で３８億円となります。
逸失利益は，いつまでに標準化に対応したシステムに移行するかによって大きく変動する不確定な想定額であり，できるだけ早く移行することによって，損失を減らしてまいります。
（単位
現行システム

新システム

（①）

（②）

保守運用費
改

修

費

差

億円）
額

（①－②）

１３１

９７

３４

８６

８２

４

計

３８

＜積算に当たっての仮定＞○保守運用費現行システムは，令和２年度までは決算（見込み）額。令和３年度から令和７年度まで
は，システムの規模や機器構成が令和２年度と同程度であると仮定して算出した額新システムは，平成２９年度当初予算編成作業時に用いた新システムの保守運用単価等を基に算出した額（約９．７億円／年）。
○改修費
現行システムは，令和２年度までは決算（見込み）額。令和３年度から令和７年度まで
は令和２年度と同額と仮定（約８．８億円／年）。
新システムの改修経費は，直近の基幹業務のオープン系システム（オープン化事業外のシステム）の改修におけるＳＥ単価と，現行システムの改修におけるＳＥ単価の比率が95:100 であるため，現行システムの改修費×０．９５で算出した額- 16 -

４

事業遅延の要因と反省点についてオープン化事業については，平成２９年１月に最初の遅延が生じた後，検討委員
会の調査報告を踏まえ，再度マイグレーション方式による開発を行うことが最良と判断し，再構築を行いました。当時のこの判断は最善の方策であったと考えております。しかし，令和２年１月に２回目の遅延を起こし，令和２年度に入ってからは新型コロナウイルス感染症対策の影響もあったとはいえ，同年度内の全面的な稼働が見通せない状況となりました。
これまでから度重なる付帯決議，警告を受けてきたにも関わらず，このような事態を招くとともに，事業の進捗状況に係る市会への的確な報告も欠き，深く反省しております。
最初の遅延と２回目で状況は異なりますが，いずれも一括処理システムの開発が遅延したことによって，システム全体の進捗に影響が生じたものです。開発を請け負った事業者が期限内にシステムの不具合を収束できなかったことが要因でありますが，事業を計画・実行し，全体の進捗管理を行う発注者である本市としても反省すべきことが多々あると認識しております。
とりわけ，①進捗管理に係る反省点のほか，②開発手法の変更，③一括処理シス
テム開発遅延への対応，④組織的な対応についての反省点は，特に猛省のうえ教訓
としてまいります。
①

進捗管理について多数の事業者が参画するマルチベンダー開発では，一つのシステム開発の遅延が，他のシステムに連鎖的に波及し，事業全体の進捗に影響を及ぼすため，個々のシステム開発及び事業全体の両面にわたって進捗管理が特に重要であると認識し，また，最初の遅延時の反省を踏まえ進捗管理の強化を図ってきたにも関わらず，再度の遅延を生じ，市会への報告も直前となりました。第一に猛省すべき点と認識しております。
最初の遅延の際には，一括処理システムの開発事業者自身の進捗管理に課題があったため，事業者の再選定に当たり，低価格入札方式からプロジェクト・マネ
ジメント能力等を考慮に入れた総合評価方式に手法を変更し調達を行うとともに，開発の再開後には，事業者と隔週で進捗会議を行うことに加えて，四半期に一度は経営層を含めた進捗報告会を新たに実施して発注者である本市と事業者との意思疎通に意を用いながら，進捗管理を行うこととしました。
強化した進捗管理体制の下，進捗に遅れが生じたときには，対策を講じて遅れを回復する，あるいは状況に応じてスケジュールを組み直す等の繰り返しにより，開発を一定進捗させてきました。

- 17 -しかし，徐々にスケジュールを組み直す余裕がなくなっていき，令和元年１２月，稼働予定の直前になってもなお不具合が収束しないため，再度の稼働延期を余儀なくされました。
工程管理支援事業者については，本市が開発事業者と行う進捗会議に参加し，事業スケジュールに照らして開発の進捗状況を確認するとともに，事業者から状況を聴取して，必要な助言を行っておりました。
本来，こうした助言を基に，より早い段階で課題解消時期を見極め，事業スケ
ジュールを再検討するなど，本市が発注者としての役割を果たすべきであったと
ころ，直前まで延期の判断を成し得ず，市会への的確な報告も欠くこととなりました。進捗管理ができておらず猛省しております。
また，進捗管理に当たって重要となる横断活動（複数事業者が参画する開発工
程や作業における事業者間調整等）を担う技術支援事業者についても，ＩＴ業界全体の人材不足により高いスキルの人材確保が困難であったこともあり，体制確保に時間を要し，一時，スケジュールどおりに実施できない状況がありました。
また，自らのスケジュール管理に関して精密さを欠くこともあり，本市及び工程管理支援事業者から厳しい指摘を受けるなど，支援事業者としての課題があったと認識しております。
②

開発手法変更（マイグレーション方式への変更）時の課題の検証について一括処理システムの開発手法は，当初，高速開発ツールによるスクラッチ開発を予定しておりましたが，平成２９年４月の総務消防委員会で報告申し上げたと
おり，平成２７年８月，マイグレーション方式に変更しました（前記２⑵参照）。
この際，マイグレーション方式に変更することによって生じる課題とそれを克服するための対策の検証が十分でなかったと猛省しております。
システムを稼働させるためには，システム開発を完了することは当然のこと，稼働後の日々の保守運用のほか，毎年度のように行われる法改正や制度改正等に対応する大規模改修の実施体制が構築できるのか見通しが立たなくてはなりま
せん。
マイグレーション方式は，機械的にプログラムを変換する方式であるため，現
行システムの複雑性が新システムにも引き継がれます。また，一括処理システム
は，福祉系及び住基・税系の全業務を対象としていることから，改修等に対応するためには幅広い業務知見が必要となります。これらのことが，一括処理システ
ムの改修全てに対応できる事業者の確保を困難なものとし，全面的な稼働に踏み切れない一因となりました。

- 18 -

③

一括処理システム開発の遅延について事業再構築後の一括処理システムの開発において，開発工程の最終段階で生じている不具合を収束させることができず，遅延が発生しました。
１回目の遅延による影響もあって，テストの作業量や作業時間が事業者の見込みを大きく超え，本市も事業者と一緒に体制を強化して，全力で解決に取り組んだものの，不具合の収束に時間を要したと認識しています。
これは作業量の見通しが十分でなかったことなど事業者側の問題に加え，・ １回目の遅延により，更に高い品質を求めてシステム検証に慎重を期したことで作業量が増加したこと
・ 開発工程の最終段階である全体システムテストにおいて発見された不具合を収束させるためのテスト環境の充実に十分対応することができず，事業者の作業効率が上がらなかったことなど，本市としての対応にも一因があったと猛省しております。
④

組織的な対応について
オープン化事業を所管する総合企画局は，その開発を最重要課題として取り組
んでまいりましたが，専門性の高い業務であるからこそ，情報共有や進捗管理，体制整備，市会への報告など，局としてのチェックや統制機能を求められるにもかかわらず，十分に果たすことができておりませんでした。猛省すべきと認識しております。

５

国が進める標準化に歩調を合わせた事業の再構築について
オープン化事業につきましては，国が最重要政策の一つとして進めるデジタル化，
自治体システムの標準化・共通化に歩調を合わせて抜本的に計画を見直し，再構築を図ってまいりますが，できるだけ早急にかつ的確に標準化に対応することによって，市民サービスの向上と行政の効率化を推進するとともに，逸失利益を少しでも低減させ市民負担を抑制することができると考えております。
二度と同じ轍を踏むことがないよう，これまでの反省を教訓にし，市民の皆様，
そして市会の御理解をいただきながら，標準化を前提とした事業の再構築をしっかりと進めてまいります。

- 19 -