2007年問題：下

　前回の×を消す作業を始めよう。前回は、企業が2007年問題に立ち向かうため、新しいシステムを作ることと、現行システムを運用し続けることの2つの選択肢を提示した。引用する。

1．新しいシステムを作る場合

○　新しい世代によって適切に運用される
×　これから作る世代もいずれは引退する
×　ノウハウの積み重ねのある基幹部分を若手やアウトソーサーがきちんと作れるかどうか不安
○　運用・維持コストが下がる
×　初期コストが莫大
○　アーキテクチャが新しくなれば、ニーズの変化に対応しやすい
×　標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる

2．現行システムをそのまま運用する場合

○　初期コストが不要
×　高額な運用・維持コストはそのまま
○　引退したベテランを安く雇える
×　人間には寿命がある
○　これから仕様書を整理すれば業務ノウハウも引き継げる
×　ツギハギだらけで拡張性に乏しいシステムのままでは、ニーズの変化に迅速に対応できない

それぞれについて見ていこう。

1．新しいシステムを作る場合

×　これから作る世代もいずれは引退する

→スタッフ個人のノウハウに依存しないシステムを開発しなければならない

×　ノウハウの積み重ねのある基幹部分を若手やアウトソーサーがきちんと作れるかどうか不安

→パッケージを使えば問題はクリアされるかもしれない
　→パッケージベンダーが倒産したり、買収される可能性は排除できない
　　→パッケージベンダーに出資することの検討
→「あなたがたにできたことは、若手にもできます」。信じましょう

×　初期コストが莫大

→上記と同様、パッケージの検討
→運用する期間を考え、トータルコストで比較する

×　標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる

→上記と同様、パッケージの検討
　→できる限りノンカスタマイズで導入し、バージョンアップをスムーズにする努力が必要
　　→パッケージに求めるレベルは相当高くなる
→はやりのSOAを使ってすべてを開発する
　→ベンダーによってSOAの定義が違うため、単純にSOAと言っても古くなるかもしれない（潮流に取り残されるかもしれない）

2．現行システムをそのまま運用する場合

×　高額な運用・維持コストはそのまま

→サーバコンソリデーションなど、ハードウェア面でコストを抑える努力は可能

×　人間には寿命がある

→回避不可能。担当者が生きているうちにドキュメント化しておかなければ、最終的には大変なことになる

×　ツギハギだらけで拡張性に乏しいシステムのままでは、ニーズの変化に迅速に対応できない

→拡張性を上げるために、BPM機能を含むインテグレーション基盤を構築する
　→インテグレーション基盤から現行システムへのつなぎ込みに業務ノウハウが必要

　ここまで、1と2の×を消す作業を行ってきた。この中で決して消えない×は2の「人間には寿命がある」である。同じ人が永遠にお守りをしてくれるわけではない。1の「標準的なアーキテクチャは移り変わるため、作ってもどうせまた古くなる」も消えそうにないが、いまより良くなるのなら、新しくした方がいい。あとはコストの問題だ。システムを新しくした方が運用・維持コストが下がるのだから、何年使うつもりなのかを考えて、コスト計算をする。これは企業によってまちまちであり、一概に新システムに移行する方がいいとは言えなくなってくる。いまより良くなるメリットと良くするコストが釣り合わなければならない。

　ともあれ、これまで頼りになったベテランは一線を退く。知識の伝承は必要だ。ここまで見てきたように、当面やるべきことは、「きちんとした現行システムの仕様書を作ること」である。2の○に「これから仕様書を整理すれば業務ノウハウも引き継げる」と書いた。じつはシステムに縛られていたために変えたくても変えられなかった業務プロセスがあるかもしれない。そういうものも洗い出す必要がある。

　これができれば、おそらく新たなシステムを作るという決断を下す企業の方が多くなるのではないだろうか。

　谷島さんからいただいたメールを引用しておく。ニヤリとできるはずだ。

--
谷島の考えは、引用していただいたように、現行の基幹系システムは全面的に見直す必要がある、にもかかわらずそれは並大抵のことではできない、というものです。ではどうするのかと言われると、自分で考えてください、というのが答えですがこう書くと殴られそうです。
--

　そのときがくるまで、まだ1年以上の時間が残っている。

　なお、私のざっくりとした考えは、以下のとおり。

フェーズ1：現行システムの正しい仕様書を作る（3～4カ月）
フェーズ2：RFPをばらまき、パッケージ選定（2～4カ月）
フェーズ3_1.a：システム導入（基幹業務系）（6～12カ月）→合うパッケージがあった場合、もしくはパッケージに合わせる場合
フェーズ3_1.b：システム導入（基幹業務系）（24カ月）→パッケージを使わず、自社開発する場合
フェーズ3_1.b：システム導入（BPM系）（12カ月）→まっさらな状態で導入する

　やはり新しいシステムは必要なのではないだろうか。しかし、単純に私がパッケージ至上主義者と見なされるのもどうかと思うので、なぜ自社開発もしくはオーダーメイドでなく、パッケージを選ぶべきなのかを次回に書きたい。