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

レガシーマイグレーションに取り掛かる企業はいまでも多い。しかし、オープンシステムへ移行したものの、サーバ台数やシステム要員の増加、業務別に縦割り組織になってしまうなどの弊害も目立っている。この問題にどのように対処すればよいのだろうか？

[木暮 仁，＠IT]

質問

オープンシステム移行による弊害はどうすればいいのでしょうか？

当社では、レガシーシステムからオープンシステムへの移行をしてから5年がたちました。システムは安定稼働しているのですが、あまりにもサーバ台数が多くなったことや、システム要員が以前にも増して、業務別に縦割りになってしまったことなどの副作用が目立ちます。これは一般的な現象なのでしょうか。どうしたら解決できるのでしょうか。

意見

　ご質問のような副作用については、1980年代末からのダウンサイジングブームのときも懸念されていたことなのですが、それが現実のものになり、多くの企業が同じような悩みを抱えています。しかも、その後のIT部門の弱体化により、抜本的な解決手段が取られていないのが現実です。その解決には、月並みですが「IT技術を重視せよ」というのが筆者の意見です。

古き良き時代への回顧た

　1980年代のレガシーが全盛だったころを振り返ってみましょう。当時は、ハードウェアが特定メーカーの寡占状態であっただけでなく、システム開発も特定ベンダに発注するのが一般的でした。また、現在と比較してIT部門の要員も多く、長年の経験を持ったベテラン技術者もいました。技術進歩は急激だったとはいえ、現在から見れば安定したものでした。

　そのような環境では、システム開発の方法論や標準化がかなり確立されていました。ハードウェアメーカーや特定ベンダも、それらをベースにして自社のものにすることができましたし、ある程度成熟度の高いレベルの企業は、自社で作成した開発基準を持っているのがむしろ一般的な状況でした。そして、長年付き合っているベンダは、これらの標準を十分に理解して順守してきました。その例をいくつか挙げましょう。

• 業務処理をマスタファイル作成、入力のチェック、更新処理などの機能に分解して、それぞれの機能での標準パターンを定めている。これらの標準パターンを組み合わせることにより、システム設計ができる。
• プログラムレベルでも、更新処理、マスタファイルとの結合処理、集計処理などの標準パターンがあり、それに従ってプログラミングすれば、ロジックの展開が明確になる。
• 体系的なサブルーチン群が用意されており、それをつなぎ合わせることにより、短期間に品質の良いプログラムが構築できる。
• プログラムやデータの命名基準が統一されているので、他人が作成したプログラムを解読するのが容易である。

　すなわち、現在騒がれているコンポーネント化やSOAなどの考え方（完成度は別として）は、むしろ当時の方が広く実践されていたのです。

　それが、その後の急激な環境変化によって、その秩序が崩壊してしまったのです。それに代わる新しい秩序も示されてはいますが、一部の先進的な企業を除いて、それを実践できているユーザー企業はいまだに少ないのが実情です。