昨今、ITサービスのように変化対応力が重要な領域をSoE(Systems of Engagement)、基幹システムのように安定性が重要な領域をSoR(Systems of Record)と分けて扱う考え方が浸透してきたが、具体的に、両領域をどのように連携、改善させればいいのだろうか。
昨今、ITサービスのように変化対応力が重要な領域をSoE(Systems of Engagement)、基幹システムのように安定性が重要な領域をSoR(Systems of Record)と分けて扱う考え方が浸透してきたが、“価値あるサービス”を提供し続けるためには、SoE、SoRがそれぞれ単独で機能を果たすのではなく、耐えず連動しながらイノベーションを生み出すことが求められる。その実現においては、アプリケーションの開発と同時に、そのパフォーマンスを支える“ITインフラの在り方”が肝となり、ITサービス競争を勝ち抜く切り札となるのだ。では具体的に、両領域をどのように連携、改善させればいいのか。
オープンソースソフトウェア(以下、OSS)とクラウド技術を軸にしたインテグレーションに定評のあるクリエーションラインで、取締役 CSO(Chief Strategy Officer)を務める鈴木逸平氏に話を聞いた。
鈴木氏は長年、日本の大手ITメーカーで技術者としてメインフレーム、オフコン、UNIX、PCの時代の変遷を経験し、古くはCAD/CAMシステムでアセンブリやFORTRANのプログラミングもしていた。現在は、クリエーションラインで、ビッグデータ分析、マイクロサービス/コンテナ、DevOps/自動化といった技術を、先進的な米国市場から日本へ導入することに注力。Chef、Docker、Mesosphere、Hashicorp、MongoDB、Neo4jなどのクラウドネイティブなベンダーとの渉外責任者も務め、日本での次世代IT化、OSSの本格導入、業務改善、IoTソリューション導入など、多くの案件で実績を積んでいる。
――いま、企業ITに寄せられている「期待」と「現実」について、あらためてどう見ていますか?
企業のIT戦略には、「攻めのIT」と「守りのIT」の大きく2つがあります。攻めのITは、積極的に先進テクノロジーを導入してビジネス改革を推進する戦略。守りのITは、既存の基幹システムを堅実に運用・保守して現状業務を継続していく戦略になります。そして、いま企業ITに期待されているのは、攻めのITへの投資を増やし、守りのITにかかるコストを削減することです。
しかし、その期待に応えるのは簡単ではありません。特に、「守りのITにおいて、現状業務を維持しつつ、基幹システムの運用コストをどう削減すればよいのか」という課題に直面している企業は多いと思います。攻めのITに投資したくても、守りのITのコストが削減できない。そのジレンマに悩まされているのが現実といえます。
――なぜ、多くの企業が守りのITコストを削減できずにいるのでしょうか?
守りのITのコスト削減を阻む要因としては、メインフレームを中心としたSoR領域のシステムの存在が挙げられます。例えば、自社でデータセンターを運用している企業であれば、メインフレームのハードウェアに関する保守費用から、人件費、電源、空調、設置スペースまで、さまざまなコストがかかります。これらのコストを削減するためには、メインフレームにあるシステムをマイグレーションすることがポイントになりますが、ここが大きなハードルになっています。
まず、メインフレームからのシステムマイグレーションには、多大な工数と導入コストがかかります。この時点で多くの企業が二の足を踏んでしまいますが、これは運用コストとのトレードオフになると考えています。経営層は、「マイグレーションをすることで、将来的にどれだけの運用コストの削減効果が見込めるのか」を長期ビジョンでシミュレーションすることが重要です。たとえ導入コストがかかっても、数年後に運用コストで回収できるのであれば、マイグレーションに挑戦する価値はあると思います。
ただ、ここで問題になるのが、日本企業は、メインフレームの運用をSIerやベンダーに依存し過ぎている点です。守りのITコスト削減に向けた解決策を自社で考えることなく、保守を担当しているSIerやベンダーに求めると、期待しているようなコスト削減効果が得られない可能性もあります。SIerやベンダーは、メインフレームの保守業務から一定の利益を確保しているため、メインフレームからのシステムマイグレーションを提案することは、言ってみれば自分の首を自分で締めるようなものです。従って企業側が主体的に考えない限り、守りのITコストを削減するのは難しいと言わざるを得ません。
守りのITのコストを削減するために、メインフレームにある既存のシステムをマイグレーションすべきかどうか。IT戦略の方向性を決めるのは、SIerやベンダーではなく、その企業自身が考え、決断すべき時代になってきていると思います。
――クリエーションラインでは、IT戦略に悩む企業に対して、どのようにアプローチしているのでしょうか?
当社では、従来のシステムインテグレーションを行う「SI(System Integration)」ではなく、ITを通じて企業にスピードとイノベーションを提供する次世代の「SI」(Speed&Innovation)を推進しています。具体的には、スピードとイノベーションを実現するために、「業務資産」「データ資産」「IT資産」の3つの入り口からアプローチしています。
「業務資産」では、DevOpsの導入によって、開発から運用、保守までソフトウェア関連業務のライフサイクルを大幅に効率化します。「データ資産」では、オンプレミスにあるデータ資産をクラウド化し、Apache SparkやHadoop、CassandraなどのNoSQLを使って、分析、解析を行います。「IT資産」では、ITインフラにコンテナ技術を導入し、ソフトウェア開発、運用のさらなる高速化を実現します。
企業が抱えるIT課題に応じて、この3つの入り口のいずれかから入り、最終的に、「企業全体のビジネススピードが速くなり、生産性が高まり、イノベーションが実現された」と定量的に評価されるのがゴールと考えています。当社には大手SIerのような組織力はないので、まずは小さなIT課題に対してスピード&イノベーションを実現し、それが成功事例となってじわじわと企業全体のIT戦略に広がっていくアプローチをとっています。
――メインフレームからシステムをマイグレーションする流れがある一方で、メインフレームにある基幹系システムで使うような重要データ(以下、基幹系データ)は、移行できるものは移行して、メインフレームに残さなければいけないと判断したデータは“塩漬け”にするしかないという意見もあるようですが。
メインフレームから基幹系データを移行できない要因としては、セキュリティの問題が大きいと思います。「マイグレーション先の新しい環境で、情報流出やハッキングなどの事件が起きていないかどうか」「セキュアであることを担保するためにどんなアーキテクチャを採用しているのか」を確認することが重要です。この2つの条件については、事前にしっかり調査、検証すればクリアできるものです。
しかし、もう1つ難しいのがIT責任者の先入観です。たとえ情報流出事件が一度も起きていないとしても、セキュアなアーキテクチャを採用していたとしても、「新しい技術だから、完全には信頼できない。事故が起きない保証はない」と思ってしまったら仕方ありません。この点については、各企業の経営ポリシーに基づき、万が一の事態も想定して、最終的にはIT責任者が腹をくくることが必要です。
それと同時に、リスクとベネフィットのバランスを見ることも大切です。メインフレームにあるシステムやデータを新しい環境にマイグレーションする際には、セキュリティの他にも、見えないリスクがたくさんあります。そのリスクと、マイグレーションを行うことでのベネフィットを比べて、はるかにベネフィットが大きければ、(リスクへの対処を考慮することは前提として)マイグレーションに踏み切る決断をしてもよいと思います。
いずれにしても、メインフレームにある基幹系データを、単に“塩漬け”にしたままにしておくのは、デジタル変革の時代に向けてベストな判断とはいえないと考えています。
――基幹系データはデジタル変革の時代において、どう活用していけばよいのでしょうか?
デジタル変革に基幹系データを活用する目的は、スピードとイノベーションの2つに尽きます。つまり、スピードが求められる業務や、イノベーションが要求されるSoE領域のサービスに、基幹系データを生かしていくことがポイントです。そして、そのためには、メインフレームのマイグレーションが必要不可欠になります。
例えば、個人向けサービスのアプリでは、消費者からの多様なニーズに対応しつつ、常に新しいコンテンツを打ち出していかなければ競争に負けてしまいます。こうしたサービスのプラットフォームは、最優先でクラウド化する必要があり、個人向けサービスから収集したデータもメインフレームに“塩漬け”にしたままというわけにはいきません。
また、既存のメインフレームの課題として、「エンドオブライフ」が近づいていることも忘れてはいけません。私は過去に、FORTRANのプログラムを、C言語で書き換えてUNIXワークステーションに移行するプロジェクトに携わりましたが、これには莫大なコストと労力がかかりました。それでも移行に踏み切ったのは、OSやハードウェアなどシステム全体がエンドオブライフを迎えていたからです。そのまま使い続けていると、業務自体がストップしてしまうリスクがありました。
現在のCOBOLもそうした状況に陥りつつあると感じています。実際に、COBOLのメンテナンスができる技術者は世界的に少なくなっており、それを引き継ぐ人も減ってきています。その中で、メインフレームを使い続けるのは、運用コストの増大を招くとともに、マイグレーションにかかるコストも確実に肥大化していきます。経営層は、メインフレームを維持するコストと、オープン系システムにマイグレーションするコストをてんびんに掛けながら、最適なタイミングを計ることが大切です。
その上で、「マイグレーションのタイミングはもう少し先」と判断した場合には、当面はメインフレームを維持しながら、クラウドサービスと連携させることによって基幹系データを活用するという選択肢もあると思います。
――メインフレームとクラウドサービスを連携させるには、どのような仕組みが必要になるのでしょうか?
当社ではメインフレームとクラウドサービスの中間に、アグリゲーションエンジンを置いて、データ連携する手法を推奨しています。その際、アグリゲーションエンジンの重要な役割となるのがリアルタイム処理です。
具体的には、アグリゲーションエンジンを運用するためのデータベースフレームワークを作り、その上でさまざまなアプリケーションを開発できる環境を構築します。これによって、例えば、メインフレームに格納されている基幹系データを1時間に1回自動抽出し、リアルタイム分析に活用することが可能になります。
また、アグリゲーションエンジンのDBにはNoSQLを使うことで、クラウドのデータなどと柔軟に連携し、より高度なデータ分析、判断ができるようになります。
――最後に、デジタルトランスフォーメーションに向けて、現在メインフレームを運用している企業に向けてアドバイスを。
繰り返しにはなりますが、メインフレームからシステムをマイグレーションするのか、クラウドサービスと連携させるように手を加えるのか、それとも現状を維持し続けるだけなのかという判断は、経営層が納得した上で決めることが重要です。SIerやベンダーに任せ切りにすることなく、3年先、5年先の自社のビジネス環境を想定して、ベストと思える選択をしてほしいと思います。
もし、自社だけで判断するのが難しければ、マイグレーションを前提にして、クラウドベンダーに相談するのも1つの手です。クラウドベンダーの周辺にはパートナー企業がいて、マイグレーションする際の工数や見積もりを出してくれるので、最終決断のための参考になるはずです。また、OSS系のミートアップやイベントなどに積極的に参加して、最先端の情報を集めることも、マイグレーションのタイミングを見極めるのに役立つと思います。
昨今、ITサービスのように変化対応力が重要な領域をSoE(Systems of Engagement)、基幹システムのように安定性が重要な領域をSoR(Systems of Record)と分けて扱う考え方が浸透してきたが、“価値あるサービス”を提供し続けるためには、SoE、SoRがそれぞれ単独で機能を果たすのではなく、耐えず連動しながらイノベーションを生み出すことが求められる。その実現に向けては、アプリケーションの開発と同時に、そのパフォーマンスを支える“ITインフラの在り方”が肝となり、ITサービス競争を勝ち抜く切り札となるのだ。では具体的に、両領域をどのように連携・改善させればいいのか――本テーマサイトでは、先進事例や動向とともに、全業種に通じる“デジタル変革の確実な進め方”を紹介する。
Copyright © ITmedia, Inc. All Rights Reserved.