苦労が絶えないシステム再構築
こうした状況を改善しようと、金融機関はシステムを再構築することがある。再構築により、スパゲティ化したプログラムを綺麗に作り直し、使えなくなる古い技術（サポートが終了するソフトウェアなど）を新しいものに交換することができる。古いプログラミング言語を人気のものに替えれば、プログラマーなどの人材を集めやすくなるかもしれない。また、伊勢神宮の式年遷宮のように、自社の社員に再構築プロジェクトを経験させることにより、次世代の人材を育成することもできる。システムの再構築プロジェクトは、さまざまな期待や思惑を乗せて動き始める。
ただし、システムの再構築は、口で言うほど簡単ではない。そもそも、作り直す元となる現行システムがどのようなものか十分に理解されていないことがある。システムの新規開発時には「仕様書」というシステムの設計図を作成する。仕様書を見ればシステムの中身が理解できるはずだが、完成後のシステム改修に合わせて仕様書がメンテナンスされているとは限らず、現行システムと齟齬が生じていることがある。また、古いプログラムの場合、仕様書そのものが失われていたり、そもそも最初から作られていなかったりする。その場合、ソースコードを読むことになるが、アセンブラのような古いプログラミング言語は、理解できる人材が限られ解読に時間がかかる。また、スパゲッティ化したコードは、書いた本人にしか分からない。より酷いケースでは、ソースコードすら存在せず、オブジェクトファイルからリバースエンジニアリングを行うことになる。
現行システムの現状把握だけで大仕事だが、新システムの開発中も、現行システムは変化する。金融機関の基幹システムは巨大であり、ステップ数が数百万から数千万のプログラムを何年もかけて開発する。その間も業務の改善を止めるわけにはいかないため、現行システムは変化し続け、開発中の新システムも対応を要する。ウォーターフォールモデルという開発手法において、開発工程の「手戻り」は最小限にするべきとされるが、実際には設計変更の発生は避けられない。その度に、新システムの設計上どのような影響があるのか確認し、仕様書やプログラムを修正することになる。
設計変更が頻繁に発生するプロジェクトを管理するのは容易ではなく、プロジェクトマネジメントに失敗し、頓挫するプロジェクトも珍しくはない。開発要員は、何日もかけて作成した仕様書やプログラムが設計変更で作り直しになり、やるせなさとストレスを抱えることになる。人手はいくらあっても足りないが、そうしたプロジェクトは得てして見積もりにも失敗しており、デスマーチ化して心身を病む者が出てくる。システム再構築の現場には、そこで働いたことが無い人間には想像もつかないような苦労が満ちあふれている。
何とかシステムを完成させても、それが当初の期待通りに再構築されたものとは限らない。スパゲティコードを直すため、不要なロジックを削除しようとしても、万が一必要だった場合を恐れ、結局はそれを温存することがある。ネットベンチャーがテクノロジに合わせて業務やシステムを最適化するのに対し、大手企業はそこまで割り切れず、現在の業務プロセスに合わせてシステムを構築しがちである。プログラミング言語やサポート期限切れのソフトウェアは新しいものに置き換えられたかもしれないが、ビジネス面での費用対効果が乏しい開発プロジェクトも少なくないと推測される。
金融機関の基幹システム再構築は、外注に頼り、多くのシステムエンジニアやプログラマーをかき集めるだけでは、もはや成し得ないものになってしまったのかもしれない。一方、GoogleやFacebookと言った巨大なネットサービスが、何億人ものユーザーを抱えながら、大きなトラブルもなく運営し続けていることから金融機関が見習うべき部分は数多くあるように思われる。それらに共通するのは、システム開発を内製化しており、極めて優秀なエンジニアを何人も採用し、彼らが力を発揮できる環境を提供している点である。そこに金融機関の情報システム部門の将来があると考える。
