京都市・システムズ訴訟の問題とは?老朽化システムの刷新失敗とITベンダーの苦悩

動いているだけでも奇跡のような老朽化システムの刷新には、多くの官庁・大企業等、規模が大きく歴史が古い組織が頭を抱えている。京都市がITベンダーのシステムズ社(東京・品川)に対する訴えを起こすことが明らかとなった事例からITベンダーの苦悩を言語化し、システム発注者がおさえておくべきポイントを解説した。

京都市・システムズ訴訟の問題とは?老朽化システムの刷新失敗とITベンダーの苦悩

京都市がシステムズを訴訟、基幹系システム刷新失敗で

2017年12月8日、京都市議会は基幹系システム刷新プロジェクトが失敗した事案の訴訟について、提起を全会一致で可決した。これは京都市が2014年から81億円を投じて進めていたもので、バッチ処理のマイグレーション(開発言語と業務ロジックを引き継ぐ移行)開発プロジェクトであった。これを受託したITベンダーのシステムズ社(東京・品川)に対する訴えである。

京都市とシステムズとの間に何が起こったのか

もともと京都市は30年前からNEC製メインフレーム上で基幹系システムを稼働してきた。

それは主にCOBOLプログラムで開発されてきたものだった。これに利用している大型汎用コンピュータは、特定事業者の固有の技術で作られた機器であるうえ、これに改修を繰り返しながら30年近く運用されてきたため、いくつかの課題が生じている。

課題として挙げられたのは以下の4点だ。

  • 市内中小企業等、他の事業者の参入が困難
  • 競争性が働かないことによる運用経費の高止まり
  • 最新技術を利用した行政サービスへの対応が困難
  • 機器は特注品となるため、被災時の早期調達が困難

大雑把に言ってしまえば、システムを改修したいとなった場合に、NEC社以外にそれを依頼するベンダーが存在せず、また、その都度言い値でそのコストを支払わされ続けていて、その負担が重い、という話である。

このような構図はいまや多くの官庁・大企業等、規模が大きく歴史が古い組織で典型的な話となっている。JAVAだ、PHPだと騒がれたことすら今は昔、Rubyだ、GOだ、PYTHONだと、プログラミング言語の日進月歩はすさまじい。COBOLなんて生きた化石のような言語、誰も勉強しない。

しかしその一方で、COBOLだって、30年前はまごうかたなき最先端技術であり、またそれによって数多くのシステムが開発されてきたのだった。いまだにそれは現役選手として稼働している、ということも珍しくない。

現代にピラミッドを建設するノウハウが喪われてしまっているのと同じで、いまやこうした古きシステムは稼働させるのだけでも精一杯。

経営側から見ると、エンジニアの高齢化、希少化が組織上のボトルネックになってしまっているのだ。扱える人が希少なCOBOLはやめて、JAVAに移行しようというのが主流の考え方となっている。

今回の刷新事業に対し、システムズは2016年1月15日にバッチ処理のマイグレーションを予定価格13億9719万6000円の約79%に当たる11億376万円で落札した。しかし残念ながら遅延したということで、訴訟という結末を迎えたのだった。

訴訟額は約8億円で、内訳は次のとおりだ。

  • すでにシステムズに支払っていて返還を求める額が約5億円
  • 稼働遅延に伴う既存システムの延長稼働などの損害賠償金が約2億円
  • 弁護士費用が約7000万円

失敗の原因はいずこに

本件は報告書が公開されている。これを読むと、このプロジェクトが「発注者の見識の不足による無為無策が、プロジェクトを達成不可能にした」というプロジェクトの典型例であると筆者は感じた。

その根本は「手法の選定のあり方」「システム刷新目的の齟齬」にある。

京都市および技術支援事業者は、今回のプロジェクトにおいて当初は、OSP(OutSystemsPlatform)と呼ばれる開発プラットフォームを採用することとしていた。

その理由は、報告書P4によると次のとおりだ。

  • オンラインシステムで使用する画面を簡単に作成・修正することでき,所管課からの修正要望を即座に画面に反映させることができる。
  • 特定事業者が独自開発用に作成したツールではなく,当該ツールに習熟している事業者であれば,どの事業者でも調達に参加できる(地元企業の参入が可能)。
  • 広く一般的に使われている言語(JAVA)でプログラムが作成されるため,OSPがなくてもシステムを動かすことができる。(OSPが廃止されても対応できる。)
  • 設計情報をOSPに登録するので詳細な設計書を別途作成する必要がなく,かつプログラムと設計情報の内容が異なるという事態が生じない。
  • プログラム改修時の影響箇所が簡単に分かるので,これまで多くの労力を要していた影響範囲調査が大幅に効率化できる。

これが2014年10月のこと。

報告書の字面だけでは読み取りにくいかもしれないが、いまの京都市のシステム担当者の苦労する様がしのばれる。

「ユーザーからシステムに対する修正要望があったら、即座に対応してあげたい」
「でも、いざ改修しようとしたときに、どこからどこまでを直せばいいのか、それを調査するだけでも大変」
「さあ直そうとしてプログラムを読むと、設計書違うことを書いていて、どっちが正しいかわからない」

このような悩みは、あらゆるITシステムの保守運用における課題と共通のものではないだろうか。エンドユーザの要望は雨あられ、それを実現したい気持ちは山々だが、それを不可能にするのはドキュメントの不備と積み重なった改修履歴。

OSPは、その製品ページに書かれたことを読む限りにおいては、UI側の自由自在なカスタマイズ、バックエンド側の自動処理といったフィーチャーを備えた開発プラットフォームだということだ。ユーザーがユーザー自身でシステムを理解し、機動的に改善を重ね、ビジネスを加速させる。あるべき話だし、最近ではこうした考え方はむしろ当たり前、というものだ。

しかし、報告書P5によると、その後2015年4月には、OSPではパフォーマンスが十分でない可能性があるとのことで、マイグレーション方式(プログラム内容を機械的に変換し移行する手法)に変更するとした、との記載があった。プログラム内容を機械的に翻訳する方法をとることにしたのである。

これは、大きな路線変更である。理屈上、改修遍歴をそのまま引き継ぐものであり、上記に掲げた根本的な課題は解決されない方法なのだ。

そもそも、一般的にはマイグレーション方式を選択しても、パフォーマンスが担保されるわけではない。この変更理由には「取ってつけた感」があるように思える。

この検討の流れから強く推測されるのは、発注者は、自身が欲しいシステムの要件を、自ら責任を持って決めることを諦めたということだ。その根底にあるのは「とりあえずJAVAで動くのであれば、それで良し」という発想である。