【クラウドネイティブ会議】危機・スコープ・Quick Winから考えるPlatform Engineeringを組織全体へ広げるための変革の進め方

「クラウドネイティブ会議」で、レッドハットのシニアコンサルタントである木嶋幸子氏は「Platform Engineeringはなぜスケールしないのか――スコープ設計と責任境界の話」と題して講演した。Platform Engineeringは、技術やツールを導入するだけでは組織全体へ広がらない。共通の危機を言語化し、誰のどの課題を解決するのかを定め、やらないことを含めて活動範囲を設計する必要がある。本稿では組織変革の「8つのステップ」を手掛かりに、ビジョンと戦略、Quick Winを組織の成果へつなげるための考え方を紹介する。

技術導入では終わらない、組織変革としてのPlatform Engineering

レッドハットがPlatform Engineeringのプロジェクトで行うのは、単に開発者ポータルやゴールデンパスを構築することではない。システム思考やデザイン思考、顧客中心主義、CI/CD、XP、スクラム、リーン、エンタープライズアジャイル、エンタープライズアーキテクチャなど、複数のプラクティスを顧客自身が実践できるように定着を支援する。

Platform Engineeringには「この手順に従えば成功する」という一つの教科書があるわけではない。組織や開発体制に応じてプラクティスを組み合わせ、成果へつなげる必要がある。

木嶋氏はプラットフォームエンジニアリングの成熟度モデルを示し、ボランティア的、一時的な取り組みから、専任チームによる戦略的な活動、スケーラブルなプロダクト、さらに組織全体で最適化された状態へと発展していく姿を説明した。ただし実際には最初の段階から先へ進めず、小規模な改善活動にとどまるケースも少なくない。「カタログに載っているような、キラキラした成功はレベル3やレベル4です。しかし実際にやってみると、最初の一手に悩み、なかなかレベル1から先へ行けないことがあります」と木嶋氏は語った。

レベル1から先に進めない理由の一つは、Platform Engineeringを技術導入としてだけ捉えてしまうことにある。木嶋氏は、ある顧客がPlatform Engineeringを「文化の定着」と表現したことを紹介した。新しいツールを導入するだけでなく、技術とプラクティスを通じて仕事の進め方や組織文化を変える取り組みであり、組織変革として考える必要があるという。

そこで参考になるのが、ジョン・コッターの「変革の8つのステップ」である。危機意識を高め、変革推進チームを作り、ビジョンと戦略を生み出し、短期的成果を積み重ねながら、新しい方法を組織文化へ定着させていく。

Kotterをベースにした失敗要因分析

木嶋氏は、この8段階のうち「1. 危機意識を高める」「3. ビジョンと戦略を生み出す」「6. 短期的成果を実現する」の三つを取り上げた。変革は直線的に進むものではなく、後の段階で課題が見つかった場合には、前提となる危機意識やビジョンの設定に立ち返って見直すことも重要だという。

共通の危機を言語化し、目指す成功の姿を定める

最初のステップは「危機意識を高める」ことである。ここでの狙いは、関係者が活動を自分ごととして捉え、全員が同じ方向を向いて行動できるようにすることだ。

1. 危機意識を高める: ねらいと失敗パターン

しかし実際には「なぜPlatform Engineeringを行うのか」「このままでは何が起きるのか」が定義されていない場合が多い。その結果、経営層から予算や人員を得られず、ステークホルダーの関心も集まらない。実行メンバーの間でも、何を優先すべきかについて合意できなくなる。「共通の危機を見つけ、みんなで共有できるように言語化します。これができていないと、最終的にはスコープがばらけてしまったり、チームが空中分解したりします」と木嶋氏は警告した。

重要なのは、危機と成功が表裏一体であることだ。何を回避すべき危機とするのかを決めれば、その裏返しとして目指す成功の状態も定まる。逆に危機感が曖昧であれば、何をもって成功とするのかも決まらない。

木嶋氏は「自分たちのKubernetes基盤を使ってもらう」という例を示した。基盤が利用されない理由として、Kubernetesを理解するための学習コストや認知負荷が挙げられる。しかし「認知負荷が高い」というだけでは、活動を始める理由としては不十分である。

認知負荷が高いため、ユーザーは自分たちのシステムでKubernetesを利用できるのか判断できない。その結果、プラットフォームチームが構築した基盤は採用されず、経営者からは投資効果が見えない。継続投資が止まり、最終的には基盤やチームの存続が危ぶまれる可能性もある。

そこまで掘り下げれば「Kubernetesを知らなくても使えるプラットフォームサービスを用意し、基盤を利用してもらう」という活動の意味が明確になる。認知負荷を下げること自体ではなく、Kubernetes基盤を継続的に使ってもらえる状態が目指す成功となる。

「私はプロジェクトに入ると、なぜこの活動を始めたのか、きっかけになった問題は何だったのかを必ず訊きます。認知負荷は問題かもしれませんが、それだけでは本当の危機ではありません」と木嶋氏は説明した。

「やらないこと」を決め、活動のスコープと責任を絞る

次の「ビジョンと戦略を生み出す」では、変化を起こすべき領域と、その変化を生むために解消すべき困りごとを特定する。

3. ビジョンと戦略を生み出す: ねらいと失敗パターン

ここで重要なのが、何を行い、何を行わないかを決めることである。Platform Engineeringでは、ポータルや自動化機能の開発だけでなく、CI/CDの構築、トラブルシューティング、アーキテクチャ設計、標準ドキュメントの作成など、幅広い課題が持ち込まれやすい。

またDevOps、SRE、Platform Engineeringは重なる領域が多く、明確な境界線があるわけではない。そのため、依頼された課題を次々に引き受ければ、プラットフォームチームの活動範囲は際限なく広がり、本来取り組むべき対象が見えなくなる。「何をやるかを決めるのも大切ですが、何をやらないかを決めることも非常に重要です。Platform Engineeringは継続的な活動なので、先に選択基準を持っておかないと、どこまでもやれてしまいます」と木嶋氏は語った。

木嶋氏は戦略を具体化するうえで、顧客となるペルソナ、顧客が必要とする価値、活動のスコープ、提供する資産を整理する必要があると説明した。Platform as a Productを実現するには、誰の、どのような困りごとを解決するのかを明確にしなければならない。

特に利用者を安易に「開発者」と決めつけないことが重要である。紹介された事例では、システム開発を社外パートナーへ委託しており、社内にいるのはプロジェクトマネージャーだった。実際に開発するパートナーには、社内の開発者ポータルへアクセスする権限がなかったという。

この場合、ポータルの直接的な利用者は開発者ではなく、必要な情報をパートナーへ伝えるプロジェクトマネージャーとなる。そこで、会社のルールに沿ってアプリケーションの設計からデプロイまで進められるように、実施事項や調整事項をプロジェクトマネージャーの視点で整理し、ワンストップで確認できる形にする必要がある。「どれだけ丁寧なドキュメントやきれいなものを作っても、実際の利用者がアクセスできなければ使われません。まずは誰が使うのかを調査してください」と木嶋氏は強調した。

さらに組織内のプロジェクトを分類し、どのパターンでプラットフォームサービスが繰り返し使われるのかを分析する。バグ修正とクラウド移行では、必要な判断や困りごとは異なる。年間で10回、20回、30回と発生するジャーニーを見極め、利用頻度の高いものに対象を絞ることが重要である。

思いついたサービスを片端から作れば、ポータルに多数の選択肢が並び、利用者は何を選べばよいかわからなくなる。繰り返し利用されるサービスを厳選し、提供範囲と責任の境界を明確にすることが、プラットフォームを組織の資産として残すことにつながる。

Quick Winを認知させ、継続的な変革へつなげる

最後に取り上げたのが、「短期的成果を実現する」である。Quick Winには、外向きには活動への期待を高め、内向きにはチームのモチベーションを高める役割がある。ただし、小さな成果を作るだけでは十分ではない。成果を周囲へ伝えなければ認知されず、利用や追加支援にはつながらないからだ。「Quick Winは、作れば終わりではありません。外に対して期待値を上げ、内側に対してはチームのモチベーションを上げるために、きちんと活用しなければなりません」と木嶋氏は語った。

6. 短期的成果を実現する: ねらいと失敗パターン

そこで必要になるのが、ユーザーの「認知の階段」を設計することだ。相手が現在どの段階にいるのかを把握し、Quick Winによってどの段階まで進んでもらうのかを決める。

伝え方も、実装した機能を列挙するだけでは不十分である。「Kubernetes環境を用意した」と説明するのではなく、それによって利用者の作業や判断がどう変わり、どの認知負荷が下がるのかを、相手の視点から伝える必要がある。

木嶋氏は、約30人のPlatform Engineeringチームのうち、3分の1をイネーブリングや広報へ充てている事例も紹介した。技術を実装する人だけでなく、利用を支援し、価値を組織へ伝える人材にも相応のリソースを割いている。「作るだけではなく、広報やイネーブリングも非常に大事です。相手にとって何がうれしいのか、どの認知負荷を下げられるのかにフォーカスして説明する必要があります」と木嶋氏は語った。

完成した開発者ポータルや自動化されたゴールデンパスは華やかに見える。しかしその裏側にあるのは、現状を調査し、対象者と課題を特定し、活動の範囲を絞り、小さな機能を継続的に届ける地道な取り組みである。「Platform Engineeringはキラキラして見えますが、実態はものすごく泥臭く、ものすごく戦略的です。一歩ずつ小さなものを積み重ね、1年後、3年後に振り返ったとき、遠くまで来たとわかるのが成果です」このように語って、木嶋氏は講演を締めくくった。