オープンシステム移行による弊害を断罪する：システム部門Q＆A（36）（3/3 ページ）

[木暮 仁，＠IT]

では、どうやって立て直せばよいのか？

　いっそのこと、ERPパッケージで統一するとかアウトソーシングしてしまえば、方法論も標準化も無用だという意見があるかもしれませんが、それはこれとは別の議論でしょうし、やや極論だとも思いますのでここでは対象にしません。

遅れているユーザー企業とその理由

　コスト重視は重要です。しかしコスト削減は見積もりの安いベンダに発注することだけではありません。IT部員の活用が不十分であったり、異なるOSのサーバがアプリケーションごとに導入されるのでは困ります。

　仮に「古き良き時代への回顧」のような標準パターンやサブルーチンが整備されているならば、開発の規模自体を小さくできるので、ベンダを買いたたくよりも有効なコスト削減策になります。

　しかも、オープン環境での方法論や標準化は、レガシー時代よりもはるかに進んだ標準的なものが提供されています。サーバ乱立の弊害も、ブレードサーバや仮想化技術などの発展により、技術的には解決できる段階になってきました。ベンダ企業では、これらの活用が競争上の重要要因ですので、かなり実践段階になっています。ところが、（超）先進企業を除いては、ユーザー企業では「分かってはいるが、実現できない」のが現実のようです。

　筆者が見聞したCIOやIT部門長の多くは、それを十分に認識しています。それなのにできない理由として、「標準化を推し進めるのに必要な能力（気力も）を持った技術者がいない」し、「それを実施するための人員や費用が認められない」だけでなく、「あまりにも技術変化が激しく、将来が見通せないので、標準化しても長続きしない危険がある」ことも指摘しています。

技術変化はそれほど激変していない

　これらの指摘のうち「技術変化」については、筆者はいい逃れだと思っています。確かに激変してはいますが、その方向性は比較的「見えて」いると思えるからです。

　ハードウェアに関しては、仮想化技術がさらに発展するので、ほかのアプリケーションに影響を与えずにサーバを共有することは容易になるでしょう。

　ソフトウェアでは、プログラム言語の仕様や開発環境ツールは大きく変化するでしょうが、レガシー系からオープン系への移行のような劇的な変化は当分は起こらないでしょう。それに、これまでの経験と反省から、それらに特定しない仕様にするとか、変更があってもほかに大きく影響させないような体系にすることを知っています。

　技術変化を理由にする人は、このような動向についても関心が低いようです。ダウンサイジングやその後の変化による打撃が大きく、無力感にとらわれているのではないでしょうか。筆者は、分からない将来のことを危惧（きぐ）するよりも、現時点で良いと思うことを行うべきだと思うのですが。

IT技術を重視せよ

　「技術者不足」と「人員・費用」は深刻な問題だと思います。1980年代に起きたSIS（Strategic Information Systems：戦略的情報システム）ブーム以降、経営的観点が重視されるようになった副作用として、IT技術の重要性が軽視されてきました。

　アウトソーシングの風潮により、そのような人材を他社あるいは他部門に放出してしまいました。当然、このような扱いを受けた技術者は、周囲から軽視されて能力向上の意欲もなくしますし、積極的に取り組む気力もなくなります。経営者への説得もしないでしょうから、経営者がこのような分野に関心を持たず、人も金も出さないのは当然です。

　この悪循環を断ち切るには、IT技術「も」重視する環境を作り出すことが必要です。単純なことでもよいから手掛けることです。

　現在の混乱状態は、コンピュータ導入時期とそれの反省時期によく似ています。日本の大企業がこぞってコンピュータを導入し始めたのは1960年代中ごろです。

　そして、「古き良き時代への回顧」での秩序が確立したのは、企業によって大きく異なりますが、平均的には1980年代初期ころでしょう。かなり雑ですが、15年程度かかったのです。しかも当時のIT部門は、業務改革の花形と見なされていたのです。

　現在の情報技術は当時とは比較にならないほど高度に複雑になっています。当時よりもはるかにIT技術者を高く評価するべきなのです。最近、システムアーキテクトが注目されていますが、これは良い傾向だと思います。ユーザー企業こそ、このような人材を育成されんことを願います。

コラム：1周遅れのランナーは先頭を走っている

1980年初頭に、端末からTSSにより汎用コンピュータを共同利用する形態が普及した。1980年代末から1990年代初にかけて、ダウンサイジングが行われた。集中から分散への流れである。その後の経緯は……

• 現場のサーバが多くなり管理ができない。それに加えて、例えば支店の経理課が情報交換したい相手は、支店内の他部門よりも本社の経理部なのだ。通信回線も安くなってきたので、場所別にサーバを設置するよりも部門別にサーバも持つべきだ。

→その結果、情報システム部門に経営部サーバ、営業部サーバ、購買部サーバなどが乱立するようになった。

• あまりにもサーバが乱立して場所をふさいでいる。管理も大変だ。コスト的にも無駄が目立つ。多くのサーバをブレードサーバにして1つの筐体に入れよう。

→何だか汎用コンピュータでの集中処理に似ているなぁ。

• セキュリティが問題だ。クライアントPCからディスクやソフトを外して、Webブラウザだけを持つシンクライアントにしよう。

→要するに端末から汎用コンピュータをTSSで使うのと同じ形態にするのと同じ？

この記事に対するご意見をお寄せください　[e-mail]

筆者プロフィール

木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」（日科技連出版社）、「もうかる情報化、会社をつぶす情報化」（リックテレコム）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している