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

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

発注者がやるべきことを一切怠り、ベンダー側に無理だけを押し付ける愚策

実はこの種のシステムにおける最大の課題は「COBOL技術者がいない」ということではない。もちろんそれはそれで現実的な問題であるが、クリティカルなのは、30年間、都度都度の改修を重ねられたシステムが、わけのわからないことになっているということなのである。

普通に考えれば、業務の流れ、データの流れを整理整頓して仕様書を作成すればいいだけの話に思える。だがしかし、そんなに簡単にはいかない。

それはなぜか。京都市の職員と計算機が営む業務を、誰も俯瞰し語ることができないのだ。ドキュメントを読んでも、プログラムを読んでも、担当者にヒアリングしても、その内実にたどり着くことはできない。

開発者もユーザーも、「なぜそうしているのか」という質問に対して「前からそうだったから」としか答えられない。業務要件の暗黙知化。それは足を踏み入れるのも恐ろしいブラックホールのようなものである。

たとえて言うならば、鰻が絶滅危惧種に指定されたので、30年間、継ぎ足し続けられた鰻屋の秘伝のタレと同じ味を、新品の酒と味醂と醤油で再現せよ、といっているようなものだ。

独特の風味を再現することを諦めれば、似たようなものを作ることはできる。しかしシステム発注者とは残酷なもので、「これまでできていたことの劣化は許さない」のである。

確かに、素人からすると、「どうして古い言語のCOBOLの方が処理速度が早くて、新しい言語のJAVAにしたら遅くなるんですか」という話である。システム発注は面倒だ。一事が万事、これである。

報告書の端々に記載されているのは、ベンダー側の説明不足や対応不足だが、発注側の論理として書かれている。その論理の内側だけで考えると、それはその通りなのだが、「内側の論理だけで考えること」こそが最大の問題なのである。

つくる方法が違うということは、前提条件が違うということだ。

製造知識がないからといって、それに甘えて何でもかんでもベンダーに丸投げし、要望だけを並べて、それが実現されないことに文句を言う。これはシステム刷新プロジェクトが失敗する典型的な進め方であり、すべてのシステム刷新担当者はここに気をつける必要がある。

システム発注者がおさえておくべき、3つのポイント

ポイントは、「新品の酒と味醂と醤油でも、そこそこ美味しい丼のタレ」を作るのはできるということだ。

コスト構造的な部分での改善も含めた、システム保守運用のあり方を改善したい、一社だけに依存して好き放題改修コストを請求されたくない、というのが、このプロジェクトの唯一のテーマである。それを実現する方法とは、「システム発注者が製造知識と業務要件に精通する」以外にない。

これにあたって守るべき原則は3点ある。
(1)「要望」と「要求」をまぜないこと
(2)「欲しいものは何か」と「制約条件は何か」の違いをはっきりさせること
(3)開発者側と同等の「思考負荷」を負うことを覚悟する

製造方法が変われば、実現できるものも変わる。

それによってデメリットも生まれる。大切なのは、いかにしてそのデメリットをエンドユーザに受け入れさせるのか、というコミュニケーションなのである。

とにかくエンドユーザが要望するものはベンダーにそのまま横流すということは、何の解決にもならない。
ITプロジェクトにおいては、一般的には、ユーザー側には協力義務が、ベンダー側にはプロジェクト管理義務がある。

今回の案件においても、ユーザー側はベンダーに対して、「報告・説明などのコミュニケーション不備」「作業品質の低さ」「プロジェクト管理能力の不足」を指摘している。もしかしたら、そのような一面があったかもしれないが、筆者にはユーザー側の「協力義務」不足の面も大きいと感じられた。

少子化問題ともあいまって、IT人材の不足が叫ばれて久しいが、システム刷新プロジェクトは、要件次第で難易度も工数も全然違うものになる。

今後、老朽化システムの刷新プロジェクトはますます増加する。それを限られたリソースで次々こなしていかない限り、未来はない。それを解決するのはSEでもなければプログラマーでもない。システム刷新プロジェクトのプロジェクトマネージャである。

それは必ずしも理系である必要もないし、開発経験が必要というわけでもない。そのコンピテンシーとは、ただひたすらに、コミュニケーション能力と誠実さ、これにつきる。

老朽化システム刷新の「PM適任者」は営業部にいる?

「謙虚に製造方法についての知識を獲得し、できることできないことをはっきりと理解し、受け入れる。そのうえで、これだけは実現したいこと、ここまでは妥協でき、かつステークホルダーに対してもそれが説明できる」

情報システム部門というと、どうしてもコストセンターというイメージがあるかもしれないが、実はこれは営業スキルとかなり近い面がある。

システムの老朽化を課題として抱える大組織には、是非営業部門のエース人材を投下してみてはいかがだろうか。もちろん突撃型、無茶振り型のアウトバウンド特化営業パーソンでは逆効果だが、調整型、段取り型のルートセールス系営業パーソンであれば、かなり人材要件としては近いものがある。

彼または彼女が営業部門で稼ぐ利益よりも、実は大きなインパクトがあるのがシステム部門である。ここに優秀な人材を張って、会社の長期成長を狙うのは、極めて合理的な経営判断であると、筆者には思えるのだ。