レガシーシステムは悪か? このような問いから始まった前回のインタビューだが、話は思わぬ方向に進み出した。レガシーを捨てろ! ところが、話はそう簡単ではない。
オープン環境のシステムを導入することに一抹の不安を覚えるIT部門責任者はたくさん存在する。その理由はオープン環境基盤で構築したシステムは、おおむね運用が複雑になる傾向があり、インフラ技術領域もユーザー側の責任で対処しなければならないからだ。さらにマルチベンダー環境のマネージメントも要求される。結果的にはコストが思いのほか高くなるのである。あまり表面化していないが、オープン技術基盤のシステムは稼働後にボディブローのようなダメージをIT部門責任者に与え続けているのである。
ここでは、前回に引き続いて東京海上日動システムズ株式会社の島田洋之常務取締役にご登場いただき、複雑化するオープン環境システムを掘り下げて議論していただこう。
今回は、東京海上日動システムズ株式会社 常務取締役 島田洋之氏を訪ねて、日々、業務システムを動かす立場からの意見をうかがった。同社は、大手損害保険会社である東京海上日動火災保険株式会社における、各種業務システムの運用・開発・保守などを一手に引き受けている。島田氏は同社のシステム運用部門の統括責任者を経て現在は同社リスク全般を統括している。
オープン系のインフラ基盤管理は限界

東京海上日動システムズ株式会社 島田洋之常務取締役
――つい最近全日空の搭乗システムで、ソフトのバージョンアップを忘れていたため、ライセンスが切れシステムが起動しなくなった。結果半日飛行機を飛ばせなくなった事故が起きました。このあたりから入りましょうか?
島田 最近のシステムでは、特にオープン系のシステムは管理しなくてはいけないことが桁違いに多くなってきている感じがします。あのケースもおそらく構成管理の複雑さからか管理が十分にしきれずに想定外のトラブルと言うことになったのではないかと思います。原因が小さなことでも大きな事故に繋がってしまう、これがオープン系の怖さなのかもしれません。
――情報システム部門側にいる人はみんなよくわかっていて理解してくれますが。世間の人は“何でそんなことを起こしてしまうんだ!”みたいな話になりますね。
島田 今日的なシステム運用の世界はメインフレームの時代から比べると格段に複雑になって来ていると思います。各構成要素を含めて全体像を明確に捉え、どこで何が起こりそうなのかを予測しながら、常に発生状況を感知・認知できることや、何か不具合が生じた場合の対応、不具合を生じさせないようなきちっとしたプロセスを作るなど、マネージメントポイントを明確にし、継続的に確実に確認をしていかないと安全、安心は得られません。管理・考慮すべき点が、ホストの時から比べると2桁ぐらい増えているんじゃないかと思います。
――そうですね、管理しなきゃいけないものが必要以上に増えすぎて……末端のPCまで含めるとね、えらいことになりそうですね。
島田 そうそう。システムを構成している要素、ハードウェアやソフトウェアの構成が圧倒的に多くなっているし複雑化している感じがしますし、それを使う側が自ら意識しなくちゃいけない。そういうことが結構ストレスになる……。
――寝れなくなる度合いも2桁増えて……。
島田 こう言う状況になってしまったことに、メーカーサイドの責任もあるのではないかと、ユーザーサイドとしては言いたいですね。オープン系デビュー当時はアジャイルの開発とかユーザービリティがいいとか、オープン形の良さだけがアピールされるようなセールストークだった。たしかに開発時のスピード感や、見た目のきれいさ、便利さなど、当時は目を見張るものがありました。
しかしながら、その後に問題が噴出。稼働した後からさまざまな問題がどんどん起きて来た。システムの脆弱性が一気に顕在化して行った。当時は開発フェーズにほとんどの視点が置かれて、こう言う状況を招いたんだと思います。
システムのライフサイクルを意識しないままにいろいろな技術を世に送り出してしまった。作ることは考えても、安定的に動かし続けることまでには思いが及んでいなかった。そこにベンダー、メーカーサイドの責任があるのではと思う。むろんユーザーサイドにも責任があることは十分認識しています。
そもそも、あのオープン系という言葉が良くなかったのかもしれない
――確かに、オープン系と言う言葉はものすごく中途半端ですね。いろいろな技術の総称として使われている。それらの技術が全て互換性のあるように聞こえる。
島田 オープンという言葉の響きには、当時は「なんでも出来る、早く出来る、きれいに出来る、安く出来る」と言った夢のあるような言葉として受け止めてしまいました。ま、作る時点ではいろいろな良さを享受出来たわけでしょうが、システム稼動後まで含めるといろいろ課題が出てきた……。
――運用の世界になったら全然オープンではないと。
島田 そうですね。システムの監視でも、「統合監視」って言葉が必要になったのはオープン系が増えてきてからじゃないかと思います。以前はメインフレーム中心で、しかもバッチ中心の監視でした。キャパシティプランニングだってそれほど意識する必要ない状況だった。単一の環境を特定のメーカーさんが見てくれていて、そろそろ機器の増強をとか、最新機器への入れ替えをなどとアドバイスとも売り込みともつかないサジェスチョンをもらい、それに乗っていたような感じだったのではないでしょうか。
今はいろいろな基盤環境があって、それらが特定のメーカーに依存しているわけではありませんから、自分たちでやらなくちゃいけない。性能管理や、構成管理をはじめ、いろいろな管理が必要となってきた。ユーザーサイドに管理技術が求められるようになってきた。
一方で、情報技術も進化し続ける。それにも追いついていかないといけない。十分理解しないまま最新の技術を導入すると、新しい技術と従来の技術の整合性が確保できずに安定稼動を損ねる事態を生じてしまう。技術進化が著しいため開発したばかりのシステムでさえサポート切れと言うことで継続的安定稼動に支障を来たすケースすら生じる。常にブラッシュアップし続けなければ、すぐにレガシー化してしまう恐れがあるということですよ。
――うかつにメインフレームだけをレガシーとか言えませんね
島田 そう、レガシー=メインフレームだと思ったら大間違いで、オープン系の世界にもレガシーがあり、そちらのレガシー化のスピードが早いし、深刻だと私は思いますね。
――その辺は今回しっかりと世の中に訴えたほうがいいですね。それから最近のシステム化対象の業務が変化していることもIT部門の負担を大きくしている?
島田 感覚的になってしまいますが、2000年頃を境にしてシステム化の対象案件が変わっていった気がします。以前は、定型的な事務処理を対象としたシステム化案件が多かった。
大量反復事務処理があって、それをシステム化していった。既存処理を対象とする機械化・合理化プロジェクトで要件も分かり易かった。運用もバッチ中心のシステムが多くやり易かった。オンラインシステムであっても操作ケースや通常、ピーク時の処理件数など想定し易かった。それが、ガラッと変わった。既存の事務処理を対象とした機械化ではなく、ITを前提とする新しい業務プロセスの構築を求められるようになった。要件も、××を見られるようにしてくれ、○○を使えるようにしてくれ、△△とコミュニケーションができるようにしてくれ……とか曖昧なものが多くなってきた。
こういったシステムは苦労して作った後も、新たな苦労が生じることになる。操作ケースや利用パターン、利用件数の想定が難しく、やってみないと分からないケースが多くなっていった。使われないものもあったが、すぐに活用されビジネスの依存度が一気に高まるものもあった。活用度合いの高まるシステムは安定稼動を強く求められるようになった。まず作って、何かあったら作り直せばいい……ナンテ悠長なことは言っていられない事態に突入していったような気がします。IT部門に求められるものも大きく変わっていきました。
――新しい事業を始めることになったから、それにフィットするシステムをすぐ作ってくれとかですね。今、情報システム部門っていうのは、スピード性とか安定性とか、さらには先見性までを維持していかなきゃいかんのですよね。
次ページに続く

この連載の記事
-
第12回
ビジネス
下部構造から脱却する人材育成を──ITSSの狙い -
第11回
ビジネス
なぜITSSの導入は失敗してしまうのか? -
第10回
ビジネス
エンジニアのスキルを共通の「ものさし」で計るITSS -
第8回
ビジネス
「メインフレーム終焉」のウソ -
第7回
ビジネス
自分たちで決めた自分たちのサービスを出す楽しさ -
第5回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(後編) -
第4回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(前編) -
第4回
ビジネス
ビジネスの発想を身につければ研究者は即戦力になる -
第3回
ビジネス
目的がハッキリしていれば産学公連携は成功する -
第2回
ビジネス
コンテンツ消費の縮図「とらのあな」が考えていること - この連載の一覧へ