「運用こそDXの要」　年間9,000時間の工数削減を実現した好循環を作り出すには

「システムは変化しない」　開発段階で運用視点を

　DXというと、新しい革新的なシステムやサービスを構築することに目が向きがちだが、フィックスポイント 代表取締役 三角正樹氏は「運用こそDXの要」と断言する。

　運用とDXの接点を語る前に、簡単にDXについて確認しておこう。総務省「令和3年度版情報通信白書」によると、DXは新しい製品、サービス、ビジネスモデルを通じてネットとリアルの両面で顧客エクスペリエンスの変革を図り、競争上の優位性を確立するなどとある。

　顧客エクスペリエンスの変革について、三角氏は自動車を例に挙げて説明する。DX以前の概念に照らし合わせると、自動車は数年おきにモデルチェンジして新機能を提供するため、自動車の価値は購入時が最高となり、時間が経つにつれて落ちていく。一方、DX後の概念だと、自動車のハードウェアにソフトウェアをサブスクリプションで提供する。ソフトウェアのアップデートで機能が進化していくため、購入後も自動車の価値は向上していく。こうして顧客エクスペリエンスはDX前後で異なるものになるという。

　新しい顧客エクスペリエンスを実現しようとすると、顧客視点で必要なユーザー体験は何か、どのようなビジネスモデルがいいかを徹底的に研究する。顧客のフィードバックを得ながら常に改善のループを回していくことになるはずだ。もちろんサービスはデジタルをフル活用したものとなるだろう。

　そうなると自ずとDevOpsへと流れ着く。開発サイドは計画から始まり、開発、検証、パッケージ化やリリースするころから運用サイドとなり、設定、モニターして、次の計画へとループを回すことで改善を繰り返していく。

　ここでこれまでの運用の視点を思い返してみよう。システム運用はメインフレーム時代から「システムは変化しないこと」が前提となっている。ひたすら定型業務を維持することがミッションとなる。人力に頼り、依頼があれば動くという形なので、自ら新しいことを進んで行うことはあまりない。これではDevOpsのループは回らない。「ここがDXを進める上で最大のボトルネックになる」と三角氏は言う。

　従来のシステム導入の流れも見てみよう。システム要求、要件定義、設計、開発、テスト……と流れていくなかで、運用を考え始めるのはテストのあたりからだった。そのころになるとシステムはほぼ形ができているので、運用視点の要望は入りにくい。開発都合でインフラ要素が構成され、運用側はただ渡されるものを運用せざるをえない。構成要素はバラバラで個別に運用していくことになる。さらに言えば、リリースに間に合わなかった機能は「運用でカバー」という妥協も起こり、運用の負荷はますます高まる。

　そうなると運用はたまったものではない。複雑な個別運用をしているのに、何も問題が起きなくて「当たり前」。何か起きれば叱責される。週末や深夜の対応もあると心身共につらいので人が定着しなくなる。運用がこうした旧態依然とした状態ではDevOpsのループが成立せず、サービスの改善や成長を阻んでしまう。

　こうした運用の課題を解決するポイントとして三角氏は「開発と同じタイミングで運用も進めていく」と指摘する。要件定義では運用の要件も定義し、設計でも運用しやすさも考慮して設計するなど、運用も同時並行で進めていく。運用を加味して開発を進めていけば、運用の負荷は大きく変わっていくだろう。

　同時にSRE（Site Reliability Engineering）も考えていきたい。SREとはGoogleが提唱、実践しているシステム管理とサービス運用の方法論だ。エンジニアリングもできる運用チームがいれば、DevOpsを推進していく上で大きな後押しとなるだろう。たとえばDevOpsのモニターの部分で、顧客に提供している価値もモニターするようになれば顧客エクスペリエンスの改善もより強力に進む。