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