近藤 誠司（こんどう せいじ）
1981 年生まれ。運用設計、運用コンサルティング業務に従事。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。そのノウハウを活かして企業の運用改善コンサルティングも行う。
趣味は小説を書くこと。第47 回埼玉文学賞にて正賞を受賞。
第4回は「システムの分類と運用要件」について考えてみたいと思います。
IT 調査会社のガートナーはシステムの分類として、コンピュータの特性を活かした計算や記録をメインに信頼性が求められるSystem of Record（SoR）と、顧客とのつながりを持つために柔軟性や俊敏性が求められるSystem of Engagement（SoE）の2 つがあると提唱しました。
それに加えて、IoT などで収集、蓄積したビッグデータをAI などで分析し、顧客行動心理に対する洞察を得るためのシステムであるSystem of Insight（SoI）を構築している企業も増えてきています。
この3つは特性が違うため、開発手法も違えば利用される技術も違います。そうなると運用に求められるものも変わってきます。まずはそれぞれの特徴を確認しておきましょう。
SoR（System of Record）
SoR は企業の情報を記録しておくためのシステムです。コンピュータは記録と正確な計算が得意な性質から、社内の基幹システムに導入されてきました。基幹システムは「単純な繰り返し作業」が多く、業務内容の変更が少ないのでシステム変更作業もそれほど多くありません。
作業ミスやシステム停止が業務に大きな影響を与えるため、安心、安全、確実といった高い信頼性が求められます。扱うデータは、顧客データや商品データなどの重要データが中心です。
そのためセキュリティやメンテナンスのコントロールがしづらいクラウドサービスへの移行が敬遠され、オンプレミスで運用しているシステムもまだ多くあります。また、運用に対しては厳格な運用要件が求められます。
SoE（System of Engagement）
Engagement という言葉に適切な日本語を当てるのが難しいのですが、「企業と顧客の結び付き」と理解するのが一番わかりやすいかもしれません。SoE は自社と顧客の結び付きを強めるためのシステムということになります。SoE は顧客に向けて公開されたWeb サービスが中心で、コーポレートサイトやプロモーションサイト、EC サイトなどが代表例です。
これらは他社と差別化して顧客獲得競争をしなければならないため、新しい技術を取り入れて魅力的なサイトを構築していく必要があります。季節によってWeb サイトの見た目を変えていったり、開催されるイベントに合わせて新たな機能を実装したりと更新の頻度は高くなりがちで、場合によっては1 日に何回もリリースすることもありますし、リリース内容の優先度も日々変わっていきます。SoR のように慎重に作業をするとビジネスチャンスを逃してしまうこともあるので、信頼性を犠牲にしてでもスピード重視でリリースが優先されます。
また、キャンペーンなどでアクセスが集中した際は柔軟にリソースを追加しなければならないため、SoE のシステムはスケールしやすいクラウド上に構築される場合が多いでしょう。運用に対しては高い信頼性よりも俊敏な変更が求められます。
Sol（System of Insight）
SoI は、企業活動やSoE とSoR から集まったデータを分析して、顧客行動心理に対する洞察（Insight）を得るためのシステムです。
いまや企業がどのようなサービスを提供しているかと同じぐらい、どのようなデータを持っているかが重要な時代が来ています。他社が持っていないようなユニークなデータを持ち、それを新たな目線でビジネスに活かすことができるのかが、他社との差別化になるでしょう。ビッグデータ基盤やそれを解析するBI（Business Intelligence）ツール、機械学習（Machine Learning）ツール、AI（Artificial Intelligence）ツールによるデータ分析などがSoI にあたります。
SoI はどちらかと言えばSoE 寄りのシステムですが、SoE ほどの高頻度のシステム変更はありませんし、SoR ほどの信頼性も必要ありません。システムに対する運用要件、作業スピードはSoE とSoR の中間となります。
システム分類ごとのまとめと運用改善の進め方
システム分類ごとの関連図と関係する項目をまとめてみます。
それぞれのシステムは目的が異なるので、システム基盤も違えば関連するキーワードも違います。運用改善を実施する場合も、それぞれの分類においてアプローチは大きく変わってきます。ただ、長期的視野で効率的に運用改善を進めていく場合は、一番古くからシステムを導入しているSoR 部分から始めて、SoE であってもSoIであっても一貫性のあるプロセスでシステムを扱える仕組みを作っていくべきです。そのため、運用改善の理想的な進め方は、以下のようなプロセスになります。
それぞれについて、少し補足しておきます。
① 運用プロセスの整理/合理化/可視化
いわゆる運用設計の部分です。現在の運用プロセスを合理的な形で整理して、ドキュメントに残して可視化することから改善は始まります。可視化はチーム内に共通理解をもたらし、メンバー交代などの要員の流動性に耐えることができるようになります。
② 運用業務のデジタル化、ワークフロー化、自動化
整理/合理化された業務はコンピュータに処理を任せることができるようになります。申請作業にワークフローシステム、障害対応にインシデント管理ツールを導入することで、申請業務やアラート処理を自動化することができます。処理の流れが自動化されれば付随する作業に対してLCDPやRPA、スクリプトなどを組み合わせて、運用業務をさらに自動化していくことも可能になります。
そのようになると、処理の高速化、オペレーションミスの低減と合わせて、運用業務のログが確実に集まるようになり、さまざまな運用に関わるデータが計測できるようになっていきます。データが計測できれば、指標を決めて測定ができるようになります。「測定できないと改善できない」という言葉があるぐらい、改善にとって測定は大切です。数値を可視化して、その数値を改善することが改善の本懐といっても過言ではないでしょう。
③ クラウドネイティブでセキュアな組織への変革
自動化などの対応と合わせて進めていかなければいけないのが、クラウドサービスをフルに活用した組織づくりと、それらで扱うデータを守るためのセキュアな組織への変革です。
手間のかかるIaaSの仮想マシンをマネージドなSaaS/PaaSへシフトしていく。そうするとパッチ適用などの運用業務は減りますが、どうしてもインターネット上を機密データが通信することも増えていくので、ゼロトラストをベースとしたセキュアな対策の実装、そしてインシデント発生時には素早く対応できるセキュアな体制も必要になってきます。
④ 業務のデジタル化/ビジネスデータの分析
クラウドサービスの活用とゼロトラストによるセキュアな環境整備が進むと、非IT 部門の業務も安心してデジタル化していくことができます。正直、ここから先は情報システム部門だけで進めていくことは難しいところです。
③までを情報システム部門で進めて、情報システム部門がITのスペシャリストに成長している場合は、ビジネス部門からデジタル化に対する協力を請われるようになっているでしょう。こうしたビジネス部門と運用部門と開発部門を合わせた組織をBizDevOpsと呼ぶこともあります。
⑤ デジタルプロダクトによるビジネス開発
最終段階として、自分の企業が所属している業界に対して破壊的イノベーションを起こすようなデジタルプロダクトを開発することを目指します。
①～④までがまったくできていなくても、一人の天才によって単発的なイノベーションを起こすことは可能です。ただ、組織として社会の変化に追随しながらイノベーションを起こしていくには、まずは会社全体がデジタル化しているという土台が必要となります。
まずは「③クラウドネイティブでセキュアな組織への変革」まで改善を進めることが、情報システム部門としては大切で、それ以降は改善をしていくなかで付随してくるものと考えておいてよいでしょう。
それでは、次回はクラウドサービス導入で変わる運用について説明します。
連載一覧
筆者紹介
コメント
投稿にはログインしてください