DXが加速し、データ駆動型ビジネスへのシフトが進む中、企業情報システムの在り方が大きく変化している。今後はシステムの開発／運用プロセスにも、変化に即応できるアジリティが強く求められる。そこで威力を発揮するのがクラウドだ。クラウドを利用することで、開発業務の自由度や柔軟性が大きく高まるほか、初期コストの削減も図れるからだ。

しかし、運用の視点で見た場合は、クラウド特有の課題もある。

「例えば、開発チームが自ら、サービス開発の延長線上で場当たり的な運用を実施してしまうために、信頼性、安定性、セキュリティーの問題が起こりがちなことはその1つです。また、各開発プロジェクトは期間内でのリリース／スピードが最優先で、プロジェクト間での共通化・標準化へのインセンティブが働きにくいために、運用がサイロ化してしまうリスクもあります」と日立製作所の三井 小吾氏は指摘する。

システムの全体像の把握が難しくなることも問題だ。クラウド上のシステムは多様な外部サービス（SaaS／PaaSなど）と連携することが多いため、システム内におけるブラックボックスの要素が増加してしまう。そのため、問題が起きた際も影響範囲を特定することが困難で、運用チームがトラブル対応にかかりきりになってしまうのだ。

さらに、無視できないのがコストである。クラウドの従量課金は初期投資を抑えられる半面、課金体系を意識したサービス利用ができていない、あるいは利用したサービスを安易に放置するとコストが増大してしまう。コスト管理の仕組みがないまま利用を促進していくと、ランニングコストが際限なく膨らんでいってしまうだろう。

「オンプレミス環境を前提とした運用のプロセスやチーム構成、およびKPIを、そのままクラウド環境に適用してもうまくいきません。例えば、開発チームは『クラウドを活用してどんどんサービスを新しくしていきたい』と考えますが、運用チームは『システムを不安定化させるリスクがある新たな変化をできるだけ抑制したい』と考えます。このギャップは、アジリティ低下の要因の1つになります」（三井氏）。また、クラウドはオンプレミスに比べて技術の進歩が速いため、運用スキルのキャッチアップが難しいのも問題だ。このような状況を放置したままでは運用チームは疲弊し、システム運用がままならなくなって、将来的にはクラウド活用自体に支障をきたすようになるだろう。

悪循環を断ち切るには、運用モデル自体を変える必要がある。「DevSecOps/SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）」型のモデルに変革していくことが必要だ。

「開発／運用チームを従来の機能分業型から、SREベースの責任共有型にシフトさせていきます。これにより、システムのリリース後も両者が一体となって継続的に改善していきつつ、ビジネスの変化に柔軟に対応できる運用モデルを目指すことが重要です」と三井氏は強調する。

この取り組みの進捗を図る指標になるのが「成熟度（マチュリティ）」だ。クラウド運用の成熟度レベルには、低いほうから「Reactive（反応的）」「Managed（管理的）」「Predictive（予測的）」「Preventive（予防的）」「Cultural（文化的）」の5段階がある。これを基に、まずは自社の成熟度がどのレベルにあるかを診断し、目標とすべきレベルとのギャップを明らかにする。そして、現状と目標のギャップを埋めていくための改善施策を抽出した上で長期的なロードマップに落とし込み、それに沿って改善を積み重ねていく（図1）。「これにより、場当たり的な対処から見える化による適切な対処へ、さらには問題の未然防止や主体的な改善へと段階的に運用をステップアップできます」と三井氏は説明する。

図1

クラウドの本格利用を進める上で必要な運用モデルには、5段階の成熟度レベルがある。現状を把握したら、その後は継続的な改善を行いながらレベルを引き上げていくことが肝心だ

日立製作所は、企業・組織がクラウド運用の成熟度レベルを高めるための取り組みを伴走型で支援している。そこで活用するサービスが「Hitachi Application Reliability Centers（HARC：ハルク）」だ。

SREの方法論である「可視化／自動化」「継続的な改善」「開発と運用の連携」をベースに、クラウド運用の信頼性・安定性向上と機能改善を支援する。元々は日立グループのHitachi Digital Servicesがグローバル向けに立ち上げたサービスだが、それを日立製作所が国内に逆輸入し、国内企業向けにアセスメントサービスからマネジメントサービスまで一気通貫で提供している。プライベートクラウドからクラウドネイティブ環境まで、幅広い環境の運用に対応する点が特徴だ。

「HARCでは、『運用代行による効率化』ではなく『継続改善を通じた成熟度レベル向上』を目指します。例えば、従来の運用モデルでは、システムを早くリリースしたい開発チームと安定稼働を重視する運用チームで利害対立が生じていました。HARCでは、開発と運用のKPIを、『システムを利用するエンドユーザーの満足度／サービスレベルの維持向上』という双方に共通の視点から落とし込んでいくことで、両者が同じ方向を向いてスピードと信頼性を両立できるようにします」と三井氏は述べる（図2）。

図2　従来型の運用とHitachi Application Reliability Centers（HARC）の違い

運用代行型ではなく伴走型であること、開発／運用チームを分業型にせず、責任共有型にすることなどがHARCの特徴であり、リリース後も積極的に見直していくクラウド時代の新たな運用の在り方といえる

「SRE Pod」と呼ばれる運用改善チームを立ち上げ、伴走型で支援するのも同じ理由からだ。最終的にはユーザー企業側のメンバーにSRE Podのリーダーを務めてもらうことを目指す。改善を素早く行うためには、ユーザー企業自身がその取り組みをリードできるようにする必要があるからだ。そうすることで、ベンダーの一括引き受けによる運用のブラックボックス化を回避することも可能になる。

「さらに、課題解決に当たってはパイロットとなる特定システムを選定した上で、早期に成果を出すことを重視します。長年受け継がれてきた運用を変えるのは簡単ではありません。よく『森から木を見る』といいますが、全体方針を立ててから施策を進めるアプローチでは、結局何も進まないことが多いのです」と三井氏。そのためHARCでは、あえて「木から始める」アプローチを採用。まずはパイロットで小さな成功体験を積み、その成果を社内で積極的に共有していくことで、取り組みへの共感者を増やす。これにより、社内へ拡大展開しやすくするという。

既に現状の運用に余裕がない企業の場合は、いったん日立製作所が運用を引き受けることも可能だ。まず従来型の運用代行で“余力”をつくり、それから改善に取り組むのである。新規構築システムについては、運用プロセスの設計段階から改善を織り込むための支援を行うことも可能だという。

既に多くの企業が、HARCを採用して運用の変革を実現している。例えば、ある企業はクラウドファーストの方針のもと、400以上の既存アプリケーションをクラウドへ移行。その際、セキュリティーインシデントの増加やコスト増大などの課題が浮上したため、HARCの導入に踏み切った。

「まずは小さな成果を挙げるため、テスト環境の構築自動化に着手しました。これがうまくいったことから、アセスメントの結果も踏まえて徐々に取り組み領域を拡大。より広い部門を巻き込みつつ、高難度の改善を逐次実施していきました」と三井氏は紹介する。

開発／運用チームのサイロ化が取り組みの阻害要因になっていることが見えてきたため、経営トップに対して組織改編も提案。これにより、開発／運用チームが連携して動ける体制を実現した。ただ、日々の業務と改善を同時に実施するのは大変なため、改善専門チームであるSRE Podも併せて設置したという。一連の取り組みの結果、継続的な運用改善に向けた全社的なモメンタム（勢い）を生み出すことができている。

このように、クラウドの価値を引き出すためには、運用の在り方を抜本的に見直すことが肝心だ。HARCのようなサービスを活用することは、そのための有効な手段となるだろう。