2007年問題：上

　今回から、2007年問題について、私の意見を書く。まずは、議論の前提として、考え方のベースを書いておく。言葉足らずな部分があるかもしれないし、そもそも前提に反論したい人もいるだろう。ぜひコメントください。

　前提条件は、「業務システムはコスト削減装置である」という考え方に置く。IT全体ではなく、業務システム。利益を生むための仕組みをITで作ることは可能になったが、ルールを作ってそのルールどおりに動かせばそれで済む部分は、“人手を省くために”システム化する。その、せっかく人手を省いた部分が、結局は人手によって支えられていて、しかもブラックボックス化していることが2007年問題の本質ととらえたい。「ITは企業文化そのものだ」と言う人もいるが、それは自分の所属する情報システム部門の雰囲気を指しているだけ。企業内ユーザーである業務部門からそういう声を聞いたことがない。

　では、2007年問題は、システムを作り直すチャンスととらえたらいいのだろうか。

　ツギハギに次ぐツギハギで膨れ上がったシステムに、企業はいくらのコストを注ぎ込んでいるのか。それは考えてみるべきだ。これから引退するベテランは、失礼ながら非常に高コストな存在だ。彼らが一気にいなくなる。そのコストをシステムの新規開発に転用する。もちろん、システムがすぐに出来上がるわけではないため、ベテランの中で必要な人材には、嘱託として（給料を下げて）残ってもらい、システムの保守を任せればいいではないか。こう考えてもいい。

　しかし、システムを新しくするだけで問題が解決するのだろうか。2つにわけて考えてみたい。

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

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

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

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

　ITベンダーの売り文句だけではなく、新しいシステムに入れ替えたいという思いが顧客サイドにもあるように感じる。若手にとってはワクワクする仕事になるだろうし、そろそろツギハギにも限界が見えてきている。

　一方のベテランはどうか。こちらは少し感傷的なようだ。ソースコードのコメントアウトに自分の名前が入っているシステムが消えるのが寂しい。しかも、それは長年お守りしてきたシステムである。私も仕事で仕方なくプログラムを作ったことがあるので、自分の書いたソースコードが動く感動を知っている。

　希望的観測は、ベテランが引退間近になって積極的に知識を残そうとすること。作って動いているシステムよりも、作るための業務知識の方に価値がある。この事実を、ベテランに理解してもらう必要があるだろう。これがうまくいかなければ、すべてが水泡に帰す。

　今回は結論まで至らなかった。とりあえずは、現行システムを残すという選択肢を提示しておく。次回は、1と2の×を消す作業によって、どちらがより良いのか考えてみたい。

＃長く更新できなくてすみませんでした。
　すでに週末に書いているので、次回は明日アップできます。