「システムは変化しない」 開発段階で運用視点を
DXというと、新しい革新的なシステムやサービスを構築することに目が向きがちだが、フィックスポイント 代表取締役 三角正樹氏は「運用こそDXの要」と断言する。
運用とDXの接点を語る前に、簡単にDXについて確認しておこう。総務省「令和3年度版情報通信白書」によると、DXは新しい製品、サービス、ビジネスモデルを通じてネットとリアルの両面で顧客エクスペリエンスの変革を図り、競争上の優位性を確立するなどとある。
顧客エクスペリエンスの変革について、三角氏は自動車を例に挙げて説明する。DX以前の概念に照らし合わせると、自動車は数年おきにモデルチェンジして新機能を提供するため、自動車の価値は購入時が最高となり、時間が経つにつれて落ちていく。一方、DX後の概念だと、自動車のハードウェアにソフトウェアをサブスクリプションで提供する。ソフトウェアのアップデートで機能が進化していくため、購入後も自動車の価値は向上していく。こうして顧客エクスペリエンスはDX前後で異なるものになるという。
新しい顧客エクスペリエンスを実現しようとすると、顧客視点で必要なユーザー体験は何か、どのようなビジネスモデルがいいかを徹底的に研究する。顧客のフィードバックを得ながら常に改善のループを回していくことになるはずだ。もちろんサービスはデジタルをフル活用したものとなるだろう。
そうなると自ずとDevOpsへと流れ着く。開発サイドは計画から始まり、開発、検証、パッケージ化やリリースするころから運用サイドとなり、設定、モニターして、次の計画へとループを回すことで改善を繰り返していく。
ここでこれまでの運用の視点を思い返してみよう。システム運用はメインフレーム時代から「システムは変化しないこと」が前提となっている。ひたすら定型業務を維持することがミッションとなる。人力に頼り、依頼があれば動くという形なので、自ら新しいことを進んで行うことはあまりない。これではDevOpsのループは回らない。「ここがDXを進める上で最大のボトルネックになる」と三角氏は言う。
従来のシステム導入の流れも見てみよう。システム要求、要件定義、設計、開発、テスト……と流れていくなかで、運用を考え始めるのはテストのあたりからだった。そのころになるとシステムはほぼ形ができているので、運用視点の要望は入りにくい。開発都合でインフラ要素が構成され、運用側はただ渡されるものを運用せざるをえない。構成要素はバラバラで個別に運用していくことになる。さらに言えば、リリースに間に合わなかった機能は「運用でカバー」という妥協も起こり、運用の負荷はますます高まる。
そうなると運用はたまったものではない。複雑な個別運用をしているのに、何も問題が起きなくて「当たり前」。何か起きれば叱責される。週末や深夜の対応もあると心身共につらいので人が定着しなくなる。運用がこうした旧態依然とした状態ではDevOpsのループが成立せず、サービスの改善や成長を阻んでしまう。
こうした運用の課題を解決するポイントとして三角氏は「開発と同じタイミングで運用も進めていく」と指摘する。要件定義では運用の要件も定義し、設計でも運用しやすさも考慮して設計するなど、運用も同時並行で進めていく。運用を加味して開発を進めていけば、運用の負荷は大きく変わっていくだろう。
同時にSRE（Site Reliability Engineering）も考えていきたい。SREとはGoogleが提唱、実践しているシステム管理とサービス運用の方法論だ。エンジニアリングもできる運用チームがいれば、DevOpsを推進していく上で大きな後押しとなるだろう。たとえばDevOpsのモニターの部分で、顧客に提供している価値もモニターするようになれば顧客エクスペリエンスの改善もより強力に進む。
年間9,000時間の工数を削減した「好循環」になる第一歩とは
DXを進めていくには運用を変えていく必要がある。しかし、従来のやり方しかしていないと「運用でエンジニアリングとか、うちの現場では未経験だからできないのでは」と考えてしまいがちだ。三角氏は「サポートすれば前進できる人を探すことが重要」と提案する。
これは三角氏の現場との関わりから得た確信でもある。企業の上層部は「うちのメンバーでは無理」と考えがちだが、実際に現場と話をすると「こういう風に改善したい」とアイデアを持っていたり、「自分もフルスタックエンジニアになりたい」などの声を聞くという。とはいえ自ら発信する運用担当者は多くないので、信頼関係を築けるような環境を整えて、本人の意向を引き出していく必要はあるだろう。
ただし、もしいたとしても「じゃあ、よろしく」と丸投げはよくない。自力でできずに潰れてしまうかもしれないからだ。
「きちんとサポートして、前進させていくこと」と三角氏は念を押す。従来型の運用ではなかなか声を上げにくい体質があることも考慮しておくべきだろう。運用はミスしたら叱責されるので、冒険しにくい。
小さな改良の積み重ねからやっていくのがよさそうだ。小さな自動化を実践してみて、成果が出たら評価し、共有していく。たとえば監視のアラートが発報されたら、障害対応を自動通知するなど。実際にうまくいくことがわかると、周囲でも「じゃあ私も」と新しい一歩を踏み出す人が増えてくる。誰かが動けば周囲も徐々に動き出して、改革が加速していく。三角氏は「最初に動く人、サポートすれば前進できる人を探す。これが大きな鍵となります」と言う。
参考として三角氏はアメリカの心理学者エドワード・デシ氏の研究を簡単に紹介した。人間が内的なモチベーションを高めるには3つの欲求があるという。まずは「自律性の欲求」。自分の意思で自由に決めた結果で効果が得られると、自由に選択するようになる。次に「有能性の欲求」。結果が出ると自分の有能性に気づき、その自信からさらなるステップアップをしようと考える。そして「関係性の欲求」。顧客や同僚など誰かのために何かをしたいということも動機となりうる。これらの3つを理解した上で、うまく回していける組織の形を考えていくのもいいだろう。
運用の自動化を進められている成功事例を見ていこう。オージス総研では、運用オペレーターの定型業務をフィックスポイントのKompiraで次々と自動化している。現在では年間9,000時間の工数削減を実現し、空いた時間はオペレーターが自動化エンジニアになるための教育に費やし、自動化や効率化の好循環ができている。
NTTコミュニケーションズでも同様に現場の熱意で自動化が進み、運用効率向上だけではなくカルチャーの変化としても、大きな効果を得ている。
運用自動化を強力に進める「Kompiraシリーズ」の活用
フィックスポイントが提供している運用自動化のためのKompiraシリーズには5つのソリューションがある。うち4つはSaaSで提供している。
まずはKompira AlertHub。アラート判断業務自動化サービスとなる。顧客環境にある監視装置、たとえばオンプレならZabbixやJP1、クラウドならDatadogやNew Relicなどから発報されたアラートの判断を自動化する。
アラートから対応が必要となると、エンジニアにエスカレーションする必要が出てくる。このための電話連絡を自動化するのがKompira Pigeon。電話発信と音声合成で、対応の候補となるエンジニアに自動で電話をかけ、アラートの内容を音声合成で伝えるなどの電話連絡業務を自動化する。
またKompira Sonarは構成管理自動化サービスとなる。障害発生時に担当者がシステム構成をドキュメントから確認する時、構成が更新されていてドキュメントと乖離していることがある。そうならないように最新の構成を把握できるようにする。
Kompiraシリーズのなかで唯一、SaaSではなくソフトウェアでインストールして使うのがKompira Enterprise。企業や方針により「システム運用をクラウドからSSHでアクセスされたくない」とSaaSが使えない場合もあるためだ。Kompira Enterpriseは企業内のネットワークで、自動化を進めていくことができる。
ここまでが自動化のためのツールで、残る1つのKompira GreacはリモートアクセスのためのSaaSとなる。まだ自動化されていない運用業務をこのKompira Greacを経由してリモートアクセスする。これで運用チームは現場に出向かなくても、自宅などからセキュアに操作できるようになっている。リモートアクセスに加えて、特権IDと証跡管理もセットになっており、安全かつ監査にも役立つ。
さらにKompira Greacは（自動化できてない作業のためのものだが）運用自動化への足がかりにもなる。一定期間の作業履歴を見ることで、繰り返しがあれば自動化したり、プロセス改善につなげたりできる。
「こうして運用をどんどん改善し、SREチームがより効率的な運用プロセスを構築していくことができます。さらに顧客満足度につながるようなモニターをすることで、開発チームにフィードバックしてDXを推進していくことにもつながります。そうした体制を構築していくとDXが加速化していくと思います」（三角氏）
