2007年8月23日木曜日

遺産を捨てる勇気を持とう

歴史から学ぶことは多い。
しかし、過去の遺産に縛られ、自由を失ってはならない。
捨てるべき過去と持ち続けるべき過去がある。
捨てるべき過去とは、ここでは情報システムのレガシーのことである。
レガシーとは古い世代の技術で構築されたシステムのことである。レガシーは最新技術の恩恵を受けることができないため、機能や性能が低い。また、それを理解する技術者が少ないことから管理も困難である。つまり非効率なシステムである。
年金問題の原因はいつのまにかレガシーシステムの性にされている。その是非はともかくレガシーは一般的に悪だと考えられている。
しかし、それほど悪いものがなぜ使われているのか、その原因を理解しなければ本質的な対処は不可能である。
一般的に、あるシステムを構築するとき、自分でゼロからプログラムを作るより、今あるプログラムを修正した方が簡単に構築できる。このとき、今あるシステムが容易に理解できることがポイントである。レガシーではこの前提が成り立たない。
では、ゼロから作ればよいのだが、それには経費がかかる。特に人件費だ。クライアントは追加分の機能に対する対価しか支払わない。それだけでは複雑なシステムを再構築することはできない。自社製品であれば、レガシーからの脱却は自社の責任だ。しかし、日本の多くの情報システムは特注である。つまり、クライアントが本来自分で継続的に改良しなければならない。しかし、機能追加など明確な業務改善効果がなければ、システムをリファクタリングすることは無駄な投資になる。せめて性能だけでも改善されなければならない。
このような状況では、いたるところにレガシーが残ることになる。
レガシーを残さないようにするには、競争が必要だ。
複数の会社がしのぎをけずる市場ではレガシーは生き残れない。つまり、提供者が複数存在するパッケージ製品ならばよい。また、パッケージでなくともサービスでもよい。サービスでは、内部を改良すれば少ない資源で多くのクライアントにサービスを提供できる。
ここで、競争がなければ進化がないことに注意する必要がある。
社会保険庁の年金システムは、他に類がないユニークなシステムである。年金システムを開発しても他に転売することができない。つまり、市場が狭い。ここで、あえてオープンシステムとすることで複数のメーカーに参入を許し、競争を緩和したが、これはよほど将来設計がしっかりしていないと難しい。内部のI/FあるいはAPIは何年かかけて利用実績に合わせて洗練化する必要がある。導入時の開発だけでは難しい。
では、どうすれば年金システムなどユニークなシステムをレガシー化しないで済ますことができるのだろうか。一番確実な方法は毎回作り直すことだ。
もう1つの方法はビジネスモデルを変えることだ。たとえば、年金を保険と同じように扱えば、保険のパッケージをカスタマイズして使うことができる。世の中には多くの保険会社が存在する。パッケージもあるだろう。
レガシーからの脱却は方法であり目的ではないという反論も考えられる。しかし、中途半端な対策ではなかなかレガシーを退治できない。ときには大なたを振るう必要がある。

0 件のコメント: