コンテナ導入後に求められる、運用を変革するノウハウ
このように、コンテナは従来のプロセスのまま導入しても効果は発揮できない。「コンテナの特性を生かしたツールの活用やレガシーアーキテクチャを刷新するなど技術・ツールの改善はもちろんですが、プロダクション品質のコンテナとクラウド環境を維持、運用するための組織体制の構築、そして忘れてはならないのが、ルールやプロセスの改善です」と北山氏は力強く語る。
冒頭でも話した通り、業務効率が企業価値となる時代は終わり、今はビジネス変化が企業価値となる時代へとシフトしつつある。そこで大事になるのが、変化に対応させながらシステムを運用していくこと。つまり構築・開発のフェーズにおいては、導入後に柔軟に変更できる仕組みを検討し、運用フェーズでは作業そのもののやり方を変えていくこと。これができなければ、コンテナ導入のメリットは得られない。
こうした中で、クライアントから「ベストプラクティスはないか」とよく聞かれるという。そこで「アジリティの高い柔軟な開発」「リリース頻度向上」「非同期による効率的なシステム」「ハードウェア稼働効率の最適化」「自律運用に伴う人件費削減」などのベストプラクティスを提示するが、「求めているものとは少し違う」と言われることも多い。ビジネス変化が企業価値となる時代では、運用そのものがビジネス価値に繋がる。つまりビジネス変化に柔軟に対応して改善し続けられるよう、運用のやり方を変えるノウハウが今、求められているベストプラクティスだと北山氏は言うのである。
運用のやり方を変えるといっても、ビジネス変更の要求→要件定義/設計→リソース調達→実装→導入というプロセスそのものを変更するわけではない。たとえば作業そのものの範囲や内容が不明確だったり、責任範囲や担当者がわからなかったり、運用プロセスが可視化されていなかったり、作業単位が大きくて内部で何が起こっているのかわからないなど、各作業の負荷が見えていないことが多いのだ。そのため「作業ごとに起きる調整作業が肥大化している。これらの問題を放置したままコンテナに置き換えても解消しない。そこで調整作業（コミュニケーションパス）を改善することが重要になる」と北山氏は指摘する。
そのためにはまず作業ごとに発生しているコミュニケーションパスを特定し、ムダをなくしていくことだ。ビジネスロジックとデータ処理の分離（作りすぎのムダ）、データそのものの分離（加工のムダ）、既存のデータ処理に伴う不要な転送（運搬のムダ）、機能依存に伴う待ち時間の削減（手持ちのムダ）、不明確な機能要求（不良、手直しのムダ）、プロセス間通信の監視（動作のムダ）、既存ツールのコンテナ化（在庫のムダ）などがその例だ。それから責務を分担していくのである。「アプリケーションをマイクロサービス化するとともに、責務を正しく定義することでコンテナ化のメリットが得られるようになる」（北山氏）
アプリケーションの改善ステップは次の4段階で示すことができる。第1ステップで既存アプリケーション運用の洗い出しを行い、第2ステップでコンテナ化（疎結合化）に伴うアプリケーション設計を行う。第3段階でサービス関連系の実装方針と権限分離をし、第4段階でマイクロサービスの運用方針を決定するのである。「一つ一つのステップを改善して進めていくことがキモになる」と北山氏は言う。
運用のやり方を変えれば、ビジネスメリットが得られることはわかったが、実際にやり方を変えるための調整や継続的改善は難しい。そこでレッドハットが提供するのが、「Container Adoption Journey」である。同ソリューションは、企業がアプリケーション開発にコンテナやマイクロサービスを活用し、クライアント環境に適した形で、継続的にサービスを改善し続ける運用や体制に気づいてもらうことを目的としたプログラムだ。Container Adoption Journeyはアプリケーション開発担当者、アプリケーション運用担当者、インフラストラクチャ運用担当者、各担当者向けのコンテンツを用意。クライアントごとに異なる課題をまず洗い出し、ビジネス価値が提供できているか、各プロジェクトのエンゲージメント管理を徹底し、各チームへの訴求活動に繋げていくことを支援するという。
Container Adoption Journeyが提供するコンテンツのロードマップ
「最終的にビジネス効果が得られる体制を作っていただく。既存の運用プロセスを変えたいと考えている企業は、Container Adoption Journeyを使って欲しい」
北山氏は最後にこう語り、セッションを締めた。
