orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

京都市基幹系システム刷新失敗の考察

f:id:orangeitems:20191228084302j:plain

 

京都市の件

京都市の基幹システム刷新が、またもや暗礁に乗り上げているようです。

 

tech.nikkeibp.co.jp

京都市はNEC製メインフレーム上で約30年稼働する基幹系システムのバッチ処理をオープンシステムに刷新するプロジェクトにおいて、サブシステムの1つである新福祉系システムの稼働を当初予定の2020年1月から延期する。再稼働の日程は確定していない。京都市総合企画局が2019年12月23日の京都市会で明らかにした。

 

現行がNECなのに、刷新にはNECが絡んでいないところが最近のNECの調子の良さが現れているなあと思います。案件の選択こそSIerの肝ですから。「おお世の腕自慢の諸君、このパズルを解いたら15億円を差し上げよう」という王様の号令に引き寄せられた夢多きベンダーや技術者が、今頃セピア色の世界で心晴れぬまま年越しをしている状況が手に取るようにわかります。

もはやこの件、SIerの間ではネタと化しつつあるような気がします。反面教師として。

 

経緯

経緯をまとめます。日経xTECHと契約すると、こういう時にありがたい。

 

2017/11/17

tech.nikkeibp.co.jp

 2014年から81億円を投じ進めている京都市の基幹系システム刷新プロジェクトは、稼働遅延を経て、ついに訴訟に発展した。バッチ処理のマイグレーションを請け負ったITベンダーのシステムズ(東京・品川)が、未払いの作業費の支払いを求めて2017年11月8日、京都市を提訴した。京都市は反訴も辞さない姿勢を見せる。

 

2017/12/12

tech.nikkeibp.co.jp

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

 

2018/03/27

tech.nikkeibp.co.jp

 京都市は2018年3月27日、NEC製メインフレーム上で約30年稼働する基幹系システムのバッチ処理をオープンシステムに刷新するプロジェクトについて、入札結果をWebサイトで公表した。総合評価方式でキヤノンITソリューションズが落札した。両者は2020年1月からの本稼働を目指す。

 

 

2019/12/27

tech.nikkeibp.co.jp

 京都市はNEC製メインフレーム上で約30年稼働する基幹系システムのバッチ処理をオープンシステムに刷新するプロジェクトにおいて、サブシステムの1つである新福祉系システムの稼働を当初予定の2020年1月から延期する。再稼働の日程は確定していない。京都市総合企画局が2019年12月23日の京都市会で明らかにした。

 

何が起こっているかを推察

まぁ問題はバッチ処理です。

 

「ほとんどの評価項目に残課題があり、2020年1月の本番稼働の品質に満たないため、品質確認のためのテストが必要」

 

ぎりぎりまで関係者はがんばったんでしょうが、白旗を上げたということでしょう。

基礎データがあって、それを新しいシステムにてバッチ処理したら、なぜか現行システムでバッチ処理したときの結果と違う。違うから「不具合」と言われている。

メインフレーム上ではCOBOLで動いているとあります。おそらく難読化という言葉が当てはまるぐらいにソースコードがスパゲッティーになっているのは想像に難くありません。ロジックがソースコードから読み取れるのなら、そのままJavaなどモダンな言語で書き換えられそうなものです。

それならということで、京都市の職員にヒアリングをして、そもそもの要件定義からやりなおしてみる。この場合はこんな計算、という具合に要件を整理していく。そして要件が整理できたら、設計を行いコーディングする。きれいなバッチシステムが出来上がる、はずです。しかしこれでも、現行システムでバッチ処理した結果と違う結果が出るに違いありません。この場合は、京都市の職員自体が要件を把握できていないということにほかなりません。

・ベンダー側に現行システムの中身を把握している人がいない。
・ユーザー側に業務の中身を把握している人がいない。

この2点が重なった案件に、絶対に手を出してはいけないということだと思います。

 

どうすべきか

べき論で言います。

まずは京都市側が要件を整理すべきでしょう。

その要件に基づいてベンダーが粛々と実装をする。

その結果が京都市の意にそわないものだとしても、それは要件を把握していない京都市が悪いのですから一旦は検収すべきだと思います。テストで揉めるのはきっとそういうことです。

ベンダーは、京都市側から出てきた要件を、全て実装していることを根拠に納品すべきでしょう。

納品後、使えないものだとしたら、それに対する追加の要件を京都市側が整理し、二次フェーズとして再コンペして追加実装していけばよいのだと思います。

と、本来はSIの普通のプロセスに則ってシステム構築・改修してばいいはずなのに、どうしてこうも揉めるのか。揉めれば揉めるほど問題が長期化していき、さらに運用費用が膨らんでいく。

 

私は、こういうトラブルに巻き込まれないために、技術者ではありますが営業段階で関わるようにしています。商談段階でだいたいユーザー側の文化はわかります。提案が欲しいと言う段階でじゃあ見積もるから要件をください、とユーザーに伝えたとします。そこでまとまっていない資料が送り付けられて、これではどうにも・・と伝えると修正版が届く。このプロセスに非協力的なユーザーとは商談も打ち切る方向にしています。そもそも担当者が要件に対して理解が乏しいのに、その刷新をベンダーに丸投げし要件定義までやってほしいとか何言ってるんだろうこの人、と思って相手にしないことが多いです。

一番怖いのが、受注した後、追加の要件がどんどん出てきたにも関わらず、金額はもう決まっているのでその中でやらなければいけない、なんてケース。それが怖いので、もはや商談段階で要件定義的な話はほとんど終わってしまうのです。その場合、商談ですから契約もないし一円ももらっていないので、「もうやめます」が通じます。

まぁ、こんな攻略法も、案件規模が小さいから許されるけど、一件15億円ではできないだろうなあとは思います。よく15億円って見積もれたなぁ、大手SIerは違うなぁという感想です。大手には大手の、ヤバい案件を引かない技術というのがあるんだろうなと思います。

 

ということで、年も暮れていきますが、来年はいい案件に恵まれるといいなあ、なんてことを反面教師を見ながらしみじみ反省しているところです。