第42回 分かれる2007年問題への評価（その2）
| 日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました。全国の書店でお求めいただけます。 |
 |
前回の「動かないコンピュータ・フォーラム」では、大問題と思える西暦2007年問題に対して、否定的な評価だけでなく肯定的な評価もあることをご紹介しました。今回は、残りのご意見をご紹介したいと思います。
まず、11月20日に頂いたご意見を紹介します。2007年問題に本当に悩んでいらっしゃる方からのご意見です。痛切な現場からの叫びと言ってもよいのではないでしょうか。
現実にこの問題で悩んでおります。私自身もほぼ該当して会社を去る運命だと思います。解決策を見出そうと苦労していますが、妙案はいまだありません。わずかでもドキュメントやツールなどで努力していますが、とてもとてもです。しかしながら、このような2007年問題の記事が連載されることにより、意欲がわくとともに、ぼんやりしているものがわずかでもはっきりしてくる気がします。できる限りの皆さんのご意見を拝見したいです。
肯定的な評価もある2007年問題ですが、このようなご意見に触れると改めてこの問題の深刻さを感じます。現場で奮闘されている皆さんに、当フォーラムが、わずかでも役に立つことがあれば幸いです。
ただ動かすだけのSEが増えている
11月20日には対照的な、別のご意見も頂きています。業務に通じたエンジニアを育成すれば2007年問題自体は恐れるに足りず、というご意見です。
私自身が退職組に属するが、言われている程の混乱は発生しないと思っています。今までにもシステムは変更やスクラップビルドを繰り返してきており、作業効率は別にして、それなりの対応が可能でしょう。
本当の問題は別のところにあるのでは？最近の若い人はIT技術オリエンティッドの傾向が非常に強く、何の為にこうしているか、業務面での考慮が不足していると感じます。つまり、本来のSEではなく、パソコンやネットワークに興味を持つ、ただのIT屋かパソコン少年になっていることに問題があるのではないでしょうか？
今からでも遅くないので、業務改革・改善に取り組めるSEとして教育を検討すれば2～3年もあれば充分教育可能です（但し新人からの教育は、もう少し年数が必要）。恐ろしいのは、何か問題が発生した時にそのシステムの本来の目的を理解せずに「システムが動けばいいんだ」という感覚でアンチョコにシステム改修し、その場逃れをし、後になって問題が発生したケースです。
ご意見の中にある、「『システムが動けばいいんだ』という感覚」というご指摘は、まさにその通りだと思います。「動かないコンピュータ」が問題なのはいうまでもありませんが、システムとしては稼働していても、とりあえず動いているだけのコンピュータは、実質的には動かないコンピュータとほとんど変わらないと思います。
記者が取材していても、数年の期間と多額の費用を当時ながら、結局以前のシステムと何ら変わらなかった。いやむしろ不便になったのではないか、という例を聞くことが少なくありません。そして、こういったケースは往々にして、仕様のまとめ方に問題があります。業務の分かるSE不在による影響の大きさを感じます。
プラットフォーム論争もありました
11月21日には、メインフレームからの決別を提案されるご意見を頂きました。既存システムを動かすハードをなくすことで、一気に2007年問題の解決を図ろうというものです。このご意見は、ある種の荒療治の勧めといえるのではないでしょうか。
2007Q対応はただひとつ。ホストの利用を止め、サーバ環境にシステム変更することだ。IBM以外のコンピュータメーカーは全てOEM以外の汎用機製造中止を発表しているではないか。なのに未だホストにしがみついているユーザ自身が2007Qを生み出しているといっても過言ではない。環境(ホストからサーバへ)が変われば、2007は問題にならない。
11月24日には、このご意見に対する反対意見がありました。
読者コメントに対するコメントですが、原因を「ホストにしがみついている」として解決策を「サーバ環境にシステム変更することだ。」に限定されているコンサルタントがいることに驚きです。何をコンサルタントされている方なのか存じませんが。まだプログラマの方ならば、技術の狭い分野しか見えなくても、ある程度は仕方ないかとあきらめもつきますけども。
5～6年前に大流行したクライアント・サーバーシステムの老朽化に伴う代替え・再構築にどれだけ苦労しているか？をご存知ない様ですね。これが20年後だとしたらメインフレーム以上にゾッとします。こんな様子だから、システム・インテグレーターのコンサルタントの肩書きは信頼しかねるのです。
実は記者は今、システムのライフサイクルを考える企画の取材を進めているのですが、ある取材先の方から面白い話を聞きました。「メインフレームでシステムを構築していた時代は、ハードの性能に制約が大きかったこともあり、プログラムを開発するかどうか慎重だった。最近では、安価なハードを使ってシステムをつくるいことができるようになったので、簡単にシステムをつくり散らかす傾向がみられる」というものです。
一方で、オープン化を進めてもメインフレームから完全には脱却できないため、システムの運用コストがかさむ。このことがコストだけではなく、運用部門の人員不足の問題につながり、人員不足が進むうちにベンダー依存が深まるという例も聞きます。また米国などと比較して、日本のメインフレームの利用率が高いのも事実です。
単純にメインフレームをなくしただけで2007年問題を解決するのは難しいでしょうが、ご意見にもあるようにメーカー自体がメインフレームの開発に以前ほど積極的な姿勢を見せなくなっているのは事実です。この事実がある以上、2007年問題の対応という理由ではないにしても、ユーザー側でもポスト・メインフレームを見据えた何らかのの指針を持つことは必要かもしれません。
システム部門をなくした企業が笑う？
11月25日には、いち早く2007年問題に対応された企業からのご意見がありました。
当社は2000年問題対応の段階で既存システムの保守ができる人材の減少問題を同時に捉え、ERP化の目的を2000年対応とノウハウの維持の外注化、2本に据えた。ERP化を「標準プロセスの導入」と謳っているケースをよく見かけるが当社では「システムを知っている人を社内で育てなくても買ってこられる」点のほうが重視されていたと思う。これは一歩間違うと「システム部門の分社化」につながるためモラルの低下と紙一重なのだが。
結果として、西暦2000年問題と同時に、2007年問題を解決していらっしゃったケースとでもというのでしょうか。最近、ERPパッケージを導入した企業で、業務改革という当初の目的はあまり進まなかったものの、2007年問題の解決には役立ったという声を取材で聞くことがありました。
何というのでしょうか、ある意味で「システム部門外し」につながる可能性のあるERPパッケージが、正にシステム部門外しとして機能したが故に2007年問題の解決につながる。短期的にはこれでよかったのかもしれませんが、こういった企業では現状のシステムをどう評価するのか、長期的なシステム戦略をいかに描くか、といったまた別の問題がある気がします。
経験だけでなく思想の継承という大問題
最後のご意見は、11月28日に頂きました。
私の職場にも、2007年に退職を迎えるベテランが多数おります。彼らの経験、知識の豊かさ、モラルの高さどれをとっても見習うものばかりです。次の世代は我々なのですが、彼らリタイア後のことを考えると心配なことばかりです。システムの継承は「人間の意思、思想の継承」ではないかと最近考えています。
技術的なノウハウは、技術の世代交代とともに色あせてゆきますが、システム根幹を貫く思想「何故こんな処理までするのか？（Know-Why）」というものは、システムが存続する限り継承されてゆかなくてはなりません。今後、彼らがリタイアするまで少しでもこの様なものを伝え残してゆきたい（できればドキュメントで）と考えていますが、作業工数には上がらない情報をどの様に残してゆくか悩みが多いところです。
意志や思想を継承する。非常に難しいことだと思います。こういった知識や経験の差は、何もないところからシステムを創ってきた世代と、最初からシステムがある中で、開発に携わってきた世代の差なのかもしれません。
こういったご意見をお伺いすると、バブル崩壊後の地盤沈下による新規開発の縮小と、インターネットの到来を再浮上のキッカケとして活用しきれなかった多くのシステム部門の現実が頭をよぎります。創造の機会を十分に得ることができなかったことが、ベテランと若手技術者の違いの根本原因ではないでしょうか。
今振り返ってみると、西暦2000年問題は、ITベンダーへの対応特需やERPパッケージの導入ブームをもたらしました。果たして、2007年問題は、企業情報システムの世界に何をもたらすのでしょうか。この点についても2004年の取材の課題としたいと思います。
