DX時代、従来型企業の情シスが担うべき役割、持つべきスキルとは？：東京証券取引所は、デジタルトランスフォーメーション（DX）にどう対応しているか？

DXが進展し、各業種でITサービス開発競争が活発化している。だが最初からテクノロジの戦いに特化した新興企業とは異なり、既存業務／既存システムを持つ従来型企業が、DXに乗り出す上ではさまざまな課題があるのが現実だ。ではこうした中、「ビジネスへの寄与」が求められている情報システム部門は、どのような役割を担っていくべきなのだろうか？　東京証券取引所IT開発部 清算システム担当課長の箕輪郁雄氏と、日立製作所　JP1 エバンジェリスト 加藤恵理氏の対談に、その答えを探る。

[PR/＠IT]

PR

「止めてはならない既存システム」を持ちながら、どうDXに対応するか

　DXが進展し、IT活用の在り方が収益・ブランドを左右する状況の中で、情報システム部門（以下、情シス）の役割が大きく変わりつつある。従来のように「求められたシステムを作る」「担当システムを安定運用する」だけではなく、「いかにITを活用すれば、ビジネスの成果に寄与できるか」を自ら考え、提案する主体的なスタンスが強く求められている。だがその具体像については、いまだ情報が少ないのが現実だ。

　今回は、日本取引所グループ（以下、JPX） 東京証券取引所 IT開発部 清算システム担当課長の箕輪郁雄氏をゲストに迎え、日立製作所のJP1エバンジェリスト 加藤恵理氏の対談を実施。「既存システムを守りながら、差別化につながる新たな価値を生み出す」というミッションに、どのようなスタンスで取り組んでいるのか――両氏の対談から“ビジネスに寄与する情シス”の具体像を探った。

「求められる情シス」と「不要な情シス」の分かれ道とは

編集部　近年は仮想化、クラウドの浸透を受けて、企業のITシステムは複雑化の一途をたどり、運用管理の在り方にも抜本的な見直しが迫られています。またDXの進展を受け、「攻めのIT活用」も重視されています。こうした中で、情シスの役割はどう変わってきたと見ていますか？

箕輪郁雄氏　日本取引所グループ 東京証券取引所 IT開発部 清算システム担当課長

箕輪氏　一昔前の情シスの役割は、事業部門の要望をシステムの観点で翻訳し、ベンダーに依頼することが中心でした。ただ、この10年の間にITは大きな変革を迎え、最近ではブロックチェーンのような新しい技術も次々と登場しています。そんな中、情シスも「新しい技術をビジネスにどう生かしていくか」を主体的に考える必要が出てきました。一言で言えば、事業部門と一緒に“ビジネスを作り上げる”必要が出てきたと感じています。

加藤氏　それはお客さまと話していても感じますね。実際、企業の経営層もビジネスへの寄与を求めていることを、情シスの方々は強く感じていらっしゃると思います。また、システムを通じて全社のビジネスの仕組み、流れを俯瞰できる情シスは、本来は収益向上や業務効率化について、改善提案することもできる立場です。しかし、システムの複雑化や人員不足を受けて、日々の業務に忙殺されがちな現実があります。ベンダーとしては、今求められている情シスのミッションに注力するためには、まず目の前の運用負荷を低減することが重要だと考えています。

加藤恵理氏　日立製作所 JP1エバンジェリスト

編集部　システムの開発・運用を通じて「ビジネスの成果にどう寄与するか」が強く求められているわけですね。数年前からそうした傾向が強まる中で、「情シス不要論」も叫ばれてきたことについてはどうお考えですか？

箕輪氏　事業部門とベンダー、SIerの間に立って、ただ“翻訳”するだけの情シスはいらなくなっていくと思います。必要とされるのは、やはり「ビジネスニーズを理解して提案できる情シス」です。ビジネスの実態に基づいて「この課題にはどのようなソリューションがマッチするか」「どのようなビジネスプロセスを作れば効率的か」といったことを考えられる人材は重宝されると思います。

　実は先日、イギリス・ロンドンのFinTech企業を視察に行ったのですが、印象的だったのは、FinTech企業の多くはIT企業でありながら、ビジネスの話をしていたことです。ITは使うことは大前提なのですね。その上で「どうビジネスを行うか」を議論している。情シスもそうした流れの中にあると感じています。

「止めてはいけないシステム」と「スピードが必要なシステム」、それぞれどう開発・運用するか？

加藤氏　ただデジタルビジネスに特化した新興企業とは異なり、既存業務／既存システムの上に立脚してきた一般的な企業は、「絶対に止めてはいけないシステム」を安定運用しながら、「ITの力でいかに価値を生み出すか」というDXへの対応も求められているわけです。これにどう対応するかが1つのカギになると思うのですが。

箕輪氏　そうした二軸の取り組みが必要なのは当社も同じですね。例えば、証券取引を支える「絶対に止めてはいけないシステム」については、確実な開発・運用が最重要ミッションとなります。開発標準にのっとって品質を担保し、ベンダーと膝を突き合わせてしっかりと作る。一方、私が担当しているシステムは、世界中にある証券取引所との差別化を行う必要のあるシステムです。顧客ニーズにスピーディに対応し、いち早く競争力につなげるために、事業部門と一緒に考えながら作り上げていきます。

加藤氏　 つまり、高度な信頼性・安定性が求められるSoR（System of Record）領域のシステムと、スピードや変化対応力が求められるSoE（System of Engagement）領域のシステム、それぞれの目的・特性に応じて、開発・運用のアプローチやチームを分けて取り組んでいるのですね。

箕輪氏　おっしゃる通りです。SoR領域の「止めてはいけないシステム」は、事業部門のニーズに沿って要件定義し、JPXのウォーターフォール型の開発標準に沿ってシステムを開発しています。基本的に5年スパンの開発としており、工程ごとに課題やリスクを把握して、関係者の合意を取りながら作り上げていく。一方、SoE領域の「スピード重視のシステム」ではアジャイル開発を採用しています。事業部門と開発部門が一体となり、要件を聞きながらその場で作っていく。

編集部　それぞれの運用体制はどう整備しているのでしょうか？

箕輪氏　「止めてはいけないシステム」は、想定し得る全障害に対し、全て復旧できるように運用を手順化・ジョブ化して、問題があった際は、運用担当者が手順書を基に復旧するスタイルを採っています。例えば、99.999％の可用性を確保するため処理サーバーの3重化やイベントコリレーション（類似メッセージの集約機能）、自動リカバリを備えた障害監視機能を備えるなど、高信頼性を支える運用の仕組みがあります。

　一方、SoE領域の「スピード重視のシステム」では、開発・改善のスピードが重要ですから、「インシデントが発生した際は、開発部門が能動的に対応する」ことにしています。運用担当者にはシステム監視、週次・月次での定例作業などを、できるだけシンプルにし、各種作業もジョブ化して、ワンクリックで実行できるよう工夫しています。管理対象のシステムが増えても、標準的な運用手順は共通なので、ツール上で少し手順をカスタマイズすればいいだけです。

　実はこうしたSoR、SoEともに、日立製作所（以下、日立）の運用管理製品である「JP1」を使って運用の仕組みを構築しています。前述のように、SoR領域のシステムは開発標準・運用標準に沿って、運用部門および日立を含むベンダーとともに、しっかりと開発・運用しています。一方、SoE領域はスピード重視のシステムですから、開発部門が機能改善と並行してインシデント対応も行うことでスピードを担保しているのです。

ビジネス視点で、運用の仕組みを考える、ツールの適用を工夫する

編集部　お話をうかがっていると、SoR、SoEともに「定型的な作業の標準化・自動化」が、運用の効率化やスピードアップ、人的ミスを抑えた確実な安定運用のカギとなっているようですね。

箕輪氏　そうですね。SoRとSoE、それぞれのビジネス目的に応じた運用品質・効率を担保するためには、人とツールがそれぞれ何を担うか、切り分けることも大切なポイントになってきます。

加藤氏　運用管理の全てを人力だけで行うのは無理ですから、システムに任せられる部分を任せていくことが効率化・確実化の前提となります。何より箕輪さんがおっしゃるように、運用設計もビジネス起点で考えることが、「ビジネスに寄与する」上で大きなポイントになるのだと思います。

「システムに任せられる部分を任せていくことが効率化・確実化の前提。また目的・特性の異なる複数のシステムを一元的に管理できることも重要」（加藤氏）

編集部　ただSoRとSoE、それぞれに適した運用管理が必要としても、管理体制の分断は非効率の原因になると思うのですが。

箕輪氏　そこでSoR、SoEともに、全システムをJP1で一元的に管理しています。各システムからの情報をJP1に集約し、オペレータが同じ管理画面を見て統合管理しているのです。前述のように、何か問題が起これば、SoRシステムなら運用部門、内容によっては担当ベンダーに連絡し、SoEシステムなら私のチームに連絡するという形にしています。

　実はJP1はアジャイル開発でも役立てています。というのも、SoE領域のシステムはスピードが必要とはいえ、当社が提供しているシステムは業務上重要なシステムですから、リリース後に問題が生じることは許されない。

　そこで当社では性能問題もテストフェーズで確実に拾っています。具体的には、JP1でメモリ不足やCPU負荷を計測し、その情報から「このエンジンのヒープを上げてみよう」とか「このエンジンの影響も考慮しよう」といった判断をしています。つまり、性能テストの段階からJP1で監視することで、リリース後に発生し得る問題を潰し込んでいるわけです。SoRシステム、SoEシステムそれぞれのビジネス目的を達成する上では、どう運用管理ツールを適用するかも重要なポイントになると思います。

加藤氏　おっしゃる通り、JP1では監視情報を1つの画面に集約するとともに、システムごとに管理ルールを設定したり、イベントの対応方法を変えたりすることができます。変化する稼働状況に対し、シナリオに沿って管理内容を自動的に変化させることも可能です。

　また、従来、JP1はSoRシステムで使われてきましたが、今ではSoEシステムでも多く使われており、当社でも特性の異なるシステムを一元管理するニーズは今後ますます伸びていくと見ています。ただ監視設計は開発の後回しになりやすい部分ですから、JP1をテストフェーズで役立てるという使い方は、製品開発に携わっている立場から見ても目からうろこですね（笑）。

運用管理は、事後対応から機械学習による予測に基づく自律運用へ

箕輪氏　実はそうした使い方をして、リリース前にあらゆる障害リスクを分析しておくと、万一、本番環境でトラブルが発生しても「これはあのテストで起きたものに似ている」といった具合に、原因特定と対応を迅速化できるというメリットもあるのです。

加藤氏　その意味では、将来的にはツールがノウハウを学習して、次の運用シナリオを予測、自動実行する自律運用の世界になっていくのかなと考えています。

「ビジネス目的に応じて、どうツールを適用するかを考えたり、実現したい機能についてベンダーと議論したりするのは、非常にエキサイティングで楽しいこと。今後の進展や可能性はとても楽しみ」（箕輪氏）

箕輪氏　JP1にそうした運用自律化の機能が入ってくるとおもしろいですね。例えば「インスタンスの起動や停止も、利用しているホストやライブラリの動きを見て自動的に判断する」とか、実運用をAIが学習して「こういう運用設計をした方がいい」と提案してくれたりするとか。こうなると運用管理はかなり楽になりますね。

加藤氏　そうですね。特に自律的な障害対応にはとても大きなニーズがあります。実は現在、取り組みを進めており、各種障害データをナレッジとして溜め込んでどこまで自律対応できるのか、研究を始めているところです。JP1の機能にどう取り込まれるかは未定ですが、よりレベルアップした自動化につなげていこうとしています。

これからの情シスの在り方とは？　運用管理担当者の役割とは？

編集部　いろいろなお話が出ましたが、あらためて、これからの情シスに求められるスキルはどのようなものだと思いますか？

箕輪氏　やはりビジネスを理解した上で、「ITでどう課題を解決するか」をその場で考えられる力だと思います。具体的に何をすべきなのか、期間、規模、コストなどのバランスを取りながら、より良い提案ができる知見があれば非常に頼りにされると思います。いちいちベンダーに聞いて、見積もりを待って、といったやり方では、ビジネス展開のスピードに追従できません。

「作ること、速くリリースすることばかりが注目されがちだが、ビジネスへの影響が大きいのはリリース後の運用の方。運用の視点から、ビジネスをもっと元気にしていってほしいと思います」（加藤氏）「今後、運用管理担当者は、新しい運用の仕組みを考える力や、“技術を見る目”が一層重要になっていくと思います」（箕輪氏）

加藤氏　先ほどの箕輪さんのお話のように、目的に応じたツールの使い方、適用法を考える力も重要になっていると思います。JP1もデビューして20年ですが、IT環境が変化する中で、使われ方が多様化してきました。ベンダー自身も、ツールの使い方や可能性を広げていく姿勢が求められていると感じています。JP1も同じ使い勝手を担保しながら、さまざまな運用ニーズにフレキシブルに対応させていくつもりです。

　DXが進む中で、ともすれば「作ること」ばかりが注目されがちですが、実際にはリリース後の運用の方がビジネスへの影響が大きい。運用という視点から、ビジネスをもっと元気にしていってほしいと思いますね。

箕輪氏　そうですね。自動化が進むと仕事がなくなるのでは、といった声もありますが、新しい潮流に乗っていく上で、運用管理担当者の役割は一層重要になっていくと思います。開発部門と一緒になって未来を見据えることで、運用管理は非常に面白い世界になっていくのではないでしょうか。