2 情報システム部門としての苦悩の歴史
2.2 老朽化・複雑化により忍者屋敷化したシステム
システムが稼働から長期間経過したことで、OSやミドルウェア、プログラムが老朽化・複雑化していきました。
それはまるで増改築を繰り返した忍者屋敷の様で、以下のような課題が顕著になっていきました。
(1)プログラムソースを見なければ仕様が把握できない
度重なる制度変更で差分の設計書が大量に作成され、それらをすべて統合しなければ現在の仕様が把握できなくなります。
設計書からシステムの仕様を把握するのが困難な状態になりました。
仕様変更の都度、ベンダーの頭の中を手掛かりにソースコードから紐解くようになっていました。
(2)プログラムが肥大化・複雑化
度重なる制度変更で機能追加や修正が行われ、プログラムが肥大化・複雑化していました。
賦課額計算処理の中には、1本が2万行を超えるプログラムが、さらに1万行のプログラムを複数呼び出して処理を行うといったものも存在するようになっていました。
(3) OSやミドルウェア、開発環境などの技術が古いまま
機器は5～7年程度で更新をしていましたが、OSやミドルウェアなどは、既存システムへの影響を減らし更新コストを低減するため、バージョンを上げずに互換性を維持し続けることを繰り返していました。
近年の開発ツールや運用ツールなどを導入できず、これらが導入された作業環境と比べるとコーディングやテストといった作業の生産性に大きな差がある状況になっていました。
(4)システム毎に類似機能が重複して存在
認証・認可や文字変換機能などの機能が、既存機能を流用する形でシステムごとに個別に存在していました。セキュリティ対策などの共通的な仕様変更の際には、それぞれの機能を修正・テストする必要がありました。
(5)データ連携が複雑化
データ連携がデータの持ち主のシステムからではなく、システム的に取得しやすい別のシステムを経由していたり、複数のシステムを経由して取得されていました。
連携経路が複雑に絡み合い、スパゲティ化していました。
2.3 ITが業務の変化を阻害
「委託化による情報システム部門の弱体化」と「システムの老朽化・複雑化」。
この２つの要因は、相互に絡み合いながら情報システムのQCDの悪化という形で表面化していきます。（図4）
本番直前になって業務所管課から「これじゃ業務ができない」と言われ、何とか本番を迎えると「使いにくい、不具合が多い」と言われる。
そして、「ちょっと直すだけなのに高すぎる。システム経費が高くて市民サービス向上ができない」と言われてしまうことも。
制度改正による期日厳守の仕様変更は十分な工期が取れず、段階的リリースによる構成管理でのトラブルも見られるようになっていました。
業務を支援し業務改善の手段であるはずのITが、むしろそれを阻害するような状況になっていました。
もちろん、この状況をただ放っておいたわけではありません。
情報システム部門内にQCDを改善するための検討プロジェクトを立ち上げ、課題分析と施策の適用を行いました。
そして、プロジェクトで分析を進めていくと、システムを老朽化・複雑化させている要因は、システムそのものが古くなっていることの他に、私たち情報システム部門が、開発計画や進捗の管理、アーキテクチャや仕様の管理、成果物の標準化といった統制を十分に行っておらず、ベンダー依存な状況になっていたことに起因していることがわかりました。
したがって、この状況を解決するためには、システム開発から運用までの進め方や仕様そのものを発注者側が理解できるようにして、しっかり統制していく状況を確立することが必要であると思い至るようになります。
2.4 職員に開発が主導できるのか?
「情報システム部門はどのような役割を担うべきか。」
情報システムのQCDの悪化により、情報システム部門内でさまざまな意見が交わされるようになっていきます。
そのなかでも特に多かったのが「職員がプログラミング技術を取り戻すべき」というものでした。
「職員もプログラミングできなければダメだ。委託により失われた技術を取り戻そう。民間採用や専門職化が必要ではないか。」という声が上がります。
しかし、検討プロジェクトに参画していた私たちは、課題分析を議論するなかで違った考えを持つようになっていました。
それは、
「ITの利用技術はオープン系の技術の進歩により多種多様なものが存在する。日々新たなものが生まれ、その進化も著しい。
3年～5年で人事異動する自治体職員が発注者主導を長きにわたり維持していくためには、職員がベンダーと同等の技術を持ち、それを維持していくことを目指すのは困難が予想される。
したがって、職員がベンダーと同等の技術を持とうとするのではなく、異なる手法を確立し、発注者主導を維持していくべきである。」という考え方です。
しかし、ベンダーと同等の技術を持たない職員に開発が主導できるのか? という問いに自信を持って「そうだ」とは答えられませんでした。
それが基幹システムレベルで本当に実現可能なのか。
具体的にどうやったら、どのような手段を使えばそれができるのか。
さまざまな意見があるなかで、具体策を提示して確信を持った主張をするまでには至らず、検討プロジェクトを運営しながら、モヤモヤとした日々を過ごしていました。
