3.1今やるべきだと言い切るために

今やるべきだと言い切るためには、原点に立ち戻って、「先送りすると、これだけの加重投資になりかねない」ということを、根拠をもって説明できるようにすることが重要です。

これによって自治体のシステム企画では必ずといっていいほど発生する検討の先送りを防ぐことができます。

稼働から一定期間経過したシステムは、維持していくために一定のタイミングでメンテナンスの費用が必要です。
また、システムが対象とする業務がシステムの根幹に関わるような大きな制度変更を予定している場合も、対応のために大きな費用がかかります。

このような費用を現行システムの維持に必要な費用として算出します(図4)。

この費用の算出により、どのタイミングでやるのが費用の側面からみて最適かということを整理することができます。

今やるべきなのか、何年後にやるのが良いのかといったことを、根拠をもって説明できるようになるのです。

「現行システムを維持するためにかかる費用を知る」

システム再構築を検討しているのであれば、現在使用しているシステムは稼働から一定期間が経過し、老朽化が起こっていることが多いと想定されます。

プログラムソースがつぎはぎで複雑化している、データベースにゴミデータが蓄積し肥大化している、導入しているミドルウェアが古いままになっている、といったことが考えられます。

これらの状況があると、たとえシステム再構築をしなくても、近いうちにメンテナンスのために大きな費用が必要となるタイミングが見えてくるのです。

札幌市では、これらの調査を現行システムベンダーと共に実施し、今後10年間にわたり現行システムを使い続けた場合の費用とシステム再構築した場合の費用として算出しました。

また、調査によって、費用をかけてメンテナンスをしたとしても限界があり、近いうちにシステムが停止しかねない事態が見えてきました。

「現行システムの根幹に影響する制度変更を知る」

システムが対象とする業務は近いうちに大きな制度改正などを予定していませんか？

制度改正の内容によっては、システムの根幹に手を入れる大規模な改修が必要となり、改修するより再構築した方が安くなるタイミングがあります。

このタイミングを狙うことで、現行システムに多大な費用をかけるよりはシステム再構築の方が良いということが起こります。

札幌市の場合は、平成24年に予定されていた住基法の改正にシステムを対応させようとするとシステム全体へ影響が広がり莫大な改修費用となることがわかりました。
そこで、法改正のタイミングにシステムの再構築を間に合わせるスケジュールで開発を行うことにしました。

3.2.実現可能だと言い切るために

実現可能だと言い切るためには、原点に立ち戻って、システム企画で作成する計画を、プロジェクトを実施していく担当者として、計画に従って実際にプロジェクトが進んでいくイメージを具体的に持つことができるまでに練り上げていくことが重要です。

そこまで自分ごととして捉えた計画ができると、プロジェクト開始後にどんな事が起こったとしても乗り越えられると思えるようになります。すると、どんな問いに対しても「この場合はこうするから大丈夫」と自信をもって説明できるようになります。

私たちのこれまでの経験からも、プロジェクトが上手くいくかどうかは、計画段階でどれだけ具体的なイメージを持つことができたかにかかっていること、プロジェクトが厳しいときに必要になる「前に進む力」は、具体的なイメージを持ったことにより「どんな事が起こったとしても乗り越えられる」と思えているかにかかっていると実感します。

「あとで不要になるのに規模が大きくなる連携機能」

計画を作る際には、実現可能性をより高めるために、開発プロジェクトの規模をできるだけ小さくすることに越したことはありません。

基幹系システムを全面再構築するような場合は段階的な稼働が必要となるため、現行システムと新システムの間でデータ連携機能が必要となります。
データ連携機能は新システムが稼働してしまえば不要なものであるにも関わらず、機能が複雑化しやすく、開発規模も大きくなります。

そこで、計画を立てる際には、現行システムのデータ連携の状況から、新システムと現行システムの開発規模を全体からみて最小となるように再構築の順序を考慮した計画を立てることが重要になります。

これまでのシステムのデータ連携は、さまざまな背景によって業務視点とは異なる形でシステムが実装されている場合があります。
例えば、住民税情報なのに税システムから直接連携されず、他システムを経由して連携されているようなケースです。これらは注意が必要です。

札幌市では、再構築対象のシステムについて「データ移行・並行稼働調査」という調査を行いました。
その結果、国民健康保険システム、介護保険システム、後期高齢システムの3つのシステムを段階的に再構築することは膨大な連携費用が必要となることがわかりました。

同じ部署で業務を実施していることにより、ワンストップサービス提供のためにシステム相互のリアルタイム照会・更新などの機能が多く行われていました。
また、開発効率化のために、介護システムの構築に国保システムの設計を、後期高齢システムの構築には介護システムのプログラムを流用して開発を行ったため、共通機能や共通情報、データ連携が多いこともわかります。
これらの状況から、前述した住基法の改正に間に合わせつつ、データ連携の密度が濃いシステムをセットで再構築する4段階の再構築を行う計画としました(図5)。

3.3.最善の方法だと言い切るために

最善の方法だと言い切るためには、原点に立ち戻って、何を狙って再構築を行うかを明確にすることが重要です。

私たちがさまざまな先進自治体の取り組みを調査したところ、再構築に着手していた自治体は、それぞれ再構築の目的や効果といったものが明確に存在していました。

大幅な人員削減を伴う行政改革を実現するため、合併に伴うサービス統一化のため、専用端末による機器費用の高止まりを解決するため、といったものです。
どの自治体の取り組みも、目的をひとことで語れるほど明確なもので、そこにはそれぞれの自治体の歴史や置かれている状況が深く関係していました。

システム企画にあたって他自治体の事例等を調査する際、その自治体が狙っているところや背景に目を向けず、ついつい手法の調査にばかり目が行ってしまいがちです。

まずは原点に立ち戻り、自らの自治体の課題やその背景から特徴を洗い出し、目的を明確にしていきましょう。
欲張ってあれもこれも目的にしてしまうと、目的も効果も中途半端で曖昧なものになってしまうので注意が必要です。目的を明確にしたら、他の自治体の事例で目的が類似しているものをみつけ、最適な手段は何かということを整理していきます。

目的を明確にすることで比較の観点が明確になり手段が選択しやすくなるものです。

札幌市は他の自治体の手法や目的を調査したあと、あまりの多くの方法があることがわかり、調査や比較に苦慮しました。
そこで原点に立ち返り、自らの自治体の課題やその背景から目的を明確にする活動を行いました。

そして、地元に多く存在するIT企業に着目し、現行システムの稼動限界前に地元企業の直接受注拡大に目的を据えたシステム再構築を行うことになったのです。

3.4議論を尽くしたと言い切るために

議論を尽くしたと言い切れるためには、原点に立ち戻り、現行システムの「課題」や再構築によって生じるかもしれない、「心配ごと」を洗い出して議論し、方向性や検討のタイミングを整理することが重要です。

ここでは、課題だけでなく「心配ごと」を洗い出して議論しておくということがとても重要です。
システム管理部門の人たちの不安、疑問や意見は先に述べたとおり、維持管理の要素への考慮を漏らさないために重要な内容が含まれています。

それらが洗い出され、議論によってこのタイミングで検討されるということがわかると、出した人たちは安心し、次第にどうやったら上手くできるかという意見を出してくれるようになります。
札幌市でも、基幹系システム再構築の検討が本格化してきたときに、システム管理部門からさまざまな不安が出ました。

そこで、「心配事リスト」というものを作成し、心配ごとを洗い出してどこで検討するかを整理することにしました（図6）。

「課題や心配ごとの議論は深追いしない」

課題や心配ごとの議論はついつい解決策を決めるまで行いたくなります。
しかし、ここでは課題の分類と構造化を行い、開発のどのタイミングで解決するのが望ましいかということを計画化することまでにとどめることが重要です。

細かいことは開発のやりかたで変わる面も多いですし、議論は際限なく時間を要し貴重な検討の時間を奪うことになるからです。
安心してもらうためには、確実に検討するという計画までにとどめるところまでで十分なことが多いのです。

「課題」は現行システムで実際に起きていることが中心となるため、具体的なものや表層的な事象が多くリストアップされます。
私たちは、出された課題を「真に解決したいことは何か」というのがわかる程度まで議論し、分類するところまでを行いました。

分類は
(1)個別の業務システムに起因
(2)開発プロセスや運用プロセスに起因
(3)アーキテクチャに起因
(4)発注者や受託者の統制に起因
(5)役所の制度や契約に起因
(6)制約となる外部環境に起因
などです。

課題は開発着手時点までに80件がリストアップされました。
「心配事」は、発生するかどうか不明なものや、新システムの全体像が見えないことによるもの、抽象的なものが多くリストアップされます。

私たちは、出された心配ごとを「解決の方向性」が決まる程度まで議論し、分類するところまでを行いました。
分類は
(1)運用（維持管理）に関すること
(2)契約に関すること
(3)予算に関すること
(4)技術的なこと
などです。

心配ごとは開発着手時点までに47件がリストアップされました。