この記事は、去る2023年5月15日に開催された Platform Engineering Meetup #2 における20分のセッション枠をいただいてお話しした件を、文字起こしがてら、セッション内では言い切れなかったことを補足するとともに、その後にいただいたコメントへの回答なども併せてまとめるものです。
YouTubeライブで生中継もなされましたが、内容を文字に起こしたものをご覧いただくと、また違った考察もできるのではないかと思います。

講演スライド

YouTube録画

1:41:48からが私のセッションになります。

内容概要(Connpass イベントページに記載)

Platform Engineering の実現にあたっては、導入する製品や運用手法の模索と選定も重要ですが、それと同等あるいはそれ以上に、 Platform Engineer としては触れたくもない、社内政治的な課題の解決が欠かせません。そういうややこしい課題をカバーし、 Platform Team が Platform の安定運営や機能改善に集中して取り組めるようにするために必要な存在である Platform Champion のあり方について、いくつかのケースを挙げて深掘りしつつ、皆さんと一緒に考えていきたいと思います。

この話の位置付け

タイトルからも分かる通り、技術を学ぶという枠でございません。
お察しの通り、マネジメントを学ぶというのが本件の主要な内容になります。
また、私もいい年なので、成功しそうなチームとお付き合いしたり、失敗の真っ只中に身を置いたり、見たくないものもいろいろ見てきました。そういった成分もほんのり織り交ぜてお話ししていこうと思います。

Platform Team を護る者

まず、これまでの皆さんのご講演におけるものよりも、ちょっと広い視野で Platform を見てみるところからのお話です。
アプリの日々の開発と運用を支えるもの、それが Platform である、という定義でお話を進めます。アプリはアプリチームが Platform を活用しながら開発と運用を行い、 Platform は Platform Team が日々開発と運用を担います。
そして、それぞれのアプリは、現場のビジネスを支えています。さらに、それらの集合によって、ひとつの企業や団体が成り立っている、と捉えます。
ここにはもちろん、企業や団体を率いる経営陣という人たちもいます。
こういった、企業や団体の全体を見渡す視野を議論の前提とし、特に、絵の右側に描かれている、人々どうしの関わり合いの部分に着目して、Platform Teamがどういう立場に置かれがちなのかを考えていきます。

まず、社内に Platform Team が結成され、 Platform が構築されました。
そして、 Platform の運用が開始されました。
さまざまなアプリチームから、また、経営陣からも、期待を一身に受けて、 Platform Team は意気揚々と仕事を始めました。
しかし、それは、 Platform Team のつらい日々の始まりでもあったのです。

アプリチームは、自分たちの生産性を上げようと、いろんな要望を Platform Team にぶつけてきます。
また、それなりのコストをかけて運営されているせっかくの Platform ですから、活用しようというアプリチームも増えてまいります。そのチームも、容赦なく Platform Team に要望をぶつけてきます。
さらには、経営陣からも、 Platform 自体や Platform Team の都合はそっちのけで、ITポリシーや Platform 運営方針の変更を、容赦なく指示してきます。
かくして Platform Team は、双方の要望や指示に忙殺され、疲弊していきます。

するとある日 Platform Team は、メンバーがひどく疲れていたからでしょうか、ある大事な運用タスクでミスをやらかしてしまいました。あらゆるアプリに運用ミスの影響が及びました。
全てのアプリチームからは、苦情が殺到しました。経営陣からも、ひどく叱られました。
かくして Platform Team は、とてもつらい立場に追い込まれてしまいました。
このようなことが、日々積み重なっていきました・・・

そして、 Platform に対する全社からの期待は失せ、あらゆるアプリチームからは見放され、経営陣も Platform の失敗に気づくのでした。
Platform Team は、結局誰からも護ってもらえませんでした。しかし、全てのアプリチームがその Platform の利用を止めるまで、 Platform の運営をやめるにやめられず、泣く泣く続けることになりました。
どうですか？皆さん、身に覚えはありませんか？ああ、忘れようとしていたのに、古傷をえぐるようなこと言いやがって、とお思いの方もいるかもしれません。申し訳ない。

そこで、そんなそんな悲劇を招かないために、Platform Teamを護る存在である、Platform Champion の出番となるわけです。

Platform Champion については、すでに2020年に開催された CloudNative Days Tokyo において、草間さんが講演の中で紹介されています。
曰く、『 Platform as a Product を進める際に、Platform Team を育て、守っていくための意思と権限を持っている人。』『CxOレベルの人』うんぬん、とあります。
この Platform Champion という存在のあり方について、このあとのお話で、深掘りしていきたいと思います。

Platform Team を何から護るのか

まず、このフィクションの舞台設定です。とある、オンラインゲーム運営会社を想定します。
この会社では、いろんなゲームをビジネス展開しています。それぞれのゲームのアプリは、 Platform 上で開発と運用がなされています。
各ゲームの開発運営チームは、独立採算制を採っています。それぞれが担当するゲームが儲からなければ、容赦なくお取り潰しという、厳しい掟が存在します。
Platform Team は、 Platform の開発と運用に加え、新しいチームのOnboardingや、開発運営チームに対するよろずの相談窓口を担っています。
Platform Team の人件費や共通的な設備のコストも含め、Platform に掛かるコストは、アプリの実行に掛かるCPUやメモリーの利用割合に応じて、各チームに配賦される、というルールとなっています。
なお、 Platform Team 以外の間接部門として、例えば、財務会計、経営企画、セキュリティ管理のような組織もあります。さらにはもちろん、経営陣がいます。全体としては、このような体制の会社になっています。
こういう舞台設定を踏まえて、このあと3つのシーンを採り上げ、Platform Champion という存在のあり方について具体的に考えていきます。

シーン1は、ある日、CIパイプラインにコンテナイメージの脆弱性スキャンを導入して、DevSecOpsを強化することになったときの話です。
アプリのリリースの前には、必ずセキュリティ脆弱性スキャンを通すことになりましたので、アプリの開発完了からリリースまでに掛かるリードタイムが増大し、開発運営チームから「遅い」「厳しい」などと、 Platform Team に苦情が殺到してしまいました。
さらには、CI実行にかかるコンピューティングコストが上昇し、 Platform 自体のコストも膨らんでしまいましたので、経営陣からコスト削減の圧力が、 Platform Team に対してかかるようになってしまいました。
Platform Team としては、自分たちが決めたセキュリティポリシーではないのに、なぜここまで開発運営チームと経営陣の双方からの圧力の板挟みに苦しまないといけないのか、と思うわけです。
本来は、そのようなセキュリティポリシーの導入を要望したセキュリティ管理室が、開発運営チームと経営陣の双方を説得するべきではないでしょうか。
これは、組織間の役割分担に関する問題であり、 Platform Team としては触れたくもない社内政治の領域となります。ここはぜひとも Platform Champion の力を借りたいところです。

シーン2は、ある日、特定のゲームだけやたらとインターネット通信が発生することが判明し、回線コストが上昇してしまったときの話です。回線コストの上昇も、Platform 自体のコストが膨らむ要因になります。
Platform コストの配賦を受ける他の開発運営チームからは、「Platform コストの配賦が不平等ではないか」と、Platform Team に苦情が殺到してしまいました。
そこで、経営層の指示により、回線コストをインターネット通信量の従量制でコスト配賦するポリシーに見直すことになりました。
Platform Team としては、技術的に可能な範囲である通信量のメトリクスの取得のしくみの導入は、忙しい中にあってもどうにか実施するが、コスト配賦ポリシーが変わることの説明や、実際のコストの配賦の実施までは勘弁してよ、と思うわけです。
本来は、ポリシーの見直しの中身や理由の説明は経営企画部門が、実際のコスト配賦は財務会計部門がやる仕事のはずです。 Platform Team は、あくまでも技術面の課題解決に集中するべきです。
これも、組織間の役割分担に関する問題であり、 Platform Team としては触れたくもない社内政治の領域となります。こちらもぜひとも Platform Champion の力を借りたいところです。

シーン3は、ある日、ある開発運営チームの要望に応じた Platform 機能を優先して実装することが、全社内に露呈してしまったときの話です。
要望に応じきれていない他の開発運営チームから「えこひいき」「説明しろ」と、 Platform Team に苦情が殺到してしまいました。
それって、Platform Teamの一存で、優先順位を決めたのでしょうか？それとも、経営陣からの指示によって、むりやり差し込まれた優先タスクなのでしょうか？
もし、 Platform Team の誰かが、要望元のチームから特別な便宜を図ってもらうから、などといった不純な理由であれば、「あ、バレました？テヘペロ」と、謝らなければなりません。
一方、それが、経営陣からの指示が理由だとしたら、 Platform Team には、そのタスクが優先されたことに対する説明責任はありません。
本来は、 Platform チームに何らかのタスクを優先的にさせる際には、経営陣なり経営企画部門が説明すべきです。これはまさに経営の問題であり、 Platform Champion の存在が必要となるところです。
以上、3つのシーンを踏まえて、Platform Champion が、 Platform Team を何から護るべきか、ざっくり次の2点にまとめられると思います。

まず、 Platform Team の便利屋化から護りたい。
Platform Team には、社内においても、技術的スキルはもちろん、そもそも事務処理能力の高い人たちが集まりがちであり、他のチームから頼りにされがちです。これが極まると、 Platform Team 外の皆が、 Platform Team のことを便利屋だと勘違いしがちになってしまいます。
次に、 Platform Team の強権化から護りたい。
Platform Team はアプリチームではできないような、特別なタスクを担います。そのために、大きな権限も与えられます。これを悪用することによって、Platform Team 自体が強権を発動できると勘違いしがちになってしまいます。

Platform Champion に何を求める？

Platform Champion に求められるものは、本当はたくさんあるはずかもしれません。しかしここでは、ギュッと3点ほどにまとめたいと思います。
1つ目は、CxOクラスに物申せる政治力が欲しい。
具体的には、Platform Team だけに難題の解決を頼らず、他の間接部門との適切な役割分担を図ってください。また、 Platform のためだけの Platform とするのではなく、あくまでも現場のビジネスを支える姿勢を明確に打ち出してください。さらには、 Platform の存在理由、利用価値、将来へのロードマップを全社で共有するようにしていただくと、素晴らしいと思います。
2つ目は、プロダクトとしての Platform と Platform Team の成長と成熟を見守る親心が欲しい。
具体的には、お忙しいでしょうが、週一回くらいは Platform Team メンバーの顔色を見に行ってあげてください。社内各所からの要望や苦情が集まって困っているかもしれませんから。また、一年や二年でいなくならないでください。経営者に近い方は入れ替わりも頻繁に発生するかもしれませんが、 Platform Team がある限り、どなたかは Platform Champion として Platform Team に寄り添ってあげてください。さらには、小さな失敗から真摯に学び、小さな成功を大袈裟に喜び、大きな成功を皆で勝ち取る、という精神を持って Platform Team を見守っていただくと、Platform の現場の人間は元気が出ると思いますよ。
3つ目は、 Platform Team に強権を持たせないバランス感覚が欲しい。
具体的には、強い権限が与えられる Platform Team と現場のビジネスとの間のパワーバランスを、適切に保つようにしてください。チーム間でリスペクトし合える関係性を保ちたいものです。また、社内政治が好きな人間を、 Platform Team に配置しないようにするとよいです。強い権限が悪用されるリスクを減らせるのではないでしょうか。さらには、 Platform Team のタスクリストを透明化し、他のチームが Platform Team がいま何に取り組んでいるのか、それはなぜかをいつでも確認できるようにしておくと素晴らしいと思います。
以上3点、いずれも、一般論として、これからの経営者に求められる資質に近いものがあるのかもしれません。
この3点でも多すぎるとお感じになる方には、ひとことだけ、ぜひ肝に銘じておいていただきたいことがあります。

Platform Engineeringは、農業のごとし。

いい農地といい機械を用意し、いいタネを撒きさえすれば、あとは放っておくだけで、大きな実りが必ず得られる、ということはありえません。天災、人災、あらゆることが、時々刻々と、容赦なくふりかかってきます。その成長と成熟に、常に目をかけなければなりません。さらには、一年や二年で終わる取り組みにはなりえません。五年、十年、二十年、中長期的な視野をもって取り組んでいただくのが、農業のごとき、 Platform Engineering というものであります。

【おわりに】Platform Team メンバーのみなさんへ

ここまでは Platform Champion が現れてほしい、という話でしたが、 Platform Team メンバー自身がかくあるべし、という話はありませんでした。
お話のおわりに、ここでは、いままさに Platform Team メンバーであるという皆さん、あるいは今後 Platform Team のメンバーになるぞという皆さんに対し、お伝えしたいメッセージがありますので、これをもって締めたいと思います。

1つ目、『難題を抱え込むな。』
それが技術的な難題なら、上の人に相談して外の力を借りましょう。ヒト・モノ・カネの追加投入を考えなければならないからです。
そうでないなら、キミたちが解くべき難題ではありません。そもそも役割分担が間違っているのです。
2つ目、『天狗になるな。』
精力善用です。キミたちのスキルは会社全体の未来のために、そこに置かれているのです。
その admin 権限は、政治力の源泉ではありません。その権限は、社内みんなの負託なのです。決して悪用してはなりません。

その後のフィードバックやコメントとリプライなど

セッション終了後の懇親会では、多くの方に「面白かった！」「共感した！」などと直接高い評価をいただきました。ありがとうございました。現場でフィードバックをいただけるのは、とても励みになりますねえ。
また、懇親会でご質問もいただきました。ビールも多少いただいていましたし、セッション直後でハイになってたので、どういうやりとりをしたか忘れてしまいましたが、好感触を持っていただいた様子だったので、とてもよかったです。

それから帰宅の途に着いたわけですが、Twitter上でいくつかコメントをいただきましたので、回答させていただきました。

コメントその1

コメントありがとうございます。
ただ、140字以内だと、なんか私の答えを伝えきれてないかもしれないですねえ。絵で描くと以下のような感じです。

コメントその2

コメントありがとうございます。
コミュニケーションをどのようにとっていけばいいのか、コミュニケーション負荷を高めないような組織設計をどのようにやっていけばいいのか、的な課題に近づいてきて、まさに Team Topology が採り上げている領域な感じがしてまいります。 Platform Engineering を考える上では不可分なんですね。

コメントその3

こういう、こちらが勝手に意識してあえて行った表現を、誰かに見つけてもらうのって、とてもうれしいことですよね。よい気づきをコメントいただき、ありがとうございます。アーティストって、こういう心持ちなんでしょうかね。

コメントその4

こちらも、140字以内で補足しようとすると、何言ってんだこいつって感じですねえ。絵で表現するなら、次のような感じですかねえ。

コメントその5

Platform 導入当初にがんばって旗を振ってくださっていた CxO クラスの方が、さらに出世されて Platform の面倒を見切れなくなったとか、あるいは何らかの理由でそのポストを離れられたとか、そういうのがきっかけで、せっかくの Platform が廃れていく、というのは、本当にあるあるな話だと思います。
Platform の導入とはまさに経営判断であり、その後は誰がどのポストにいようとも、全社の経営方針として Platform の維持・展開・改善を図っていなかければならないということは、ぜひともご理解いただきたいところです。

おしまい。