プラットフォームチームが仕事を進める方法

"プラットフォーム" ＞ 内部開発者プラットフォーム

現在、プラットフォームエンジニアリングに関する多くの話題があり、主に内部開発者プラットフォーム（IDP）に焦点を当てています。ここで「プラットフォーム」の議論ははるかに広範であり、データプラットフォーム、フロントエンドデザインシステム、または実験プラットフォームなどの他の内部製品を含んでいることを明確にしたいと考えています。

実際、私たちは主に技術的なプラットフォームを扱いますが、ここで提示されているアイデアの多くは、共有されたビジネス機能を提供する内部製品にも適用されます。フィンテック企業の送金サービス、またはeコマース企業のプロダクトカタログサービスなどです。統一的な特徴は、プラットフォームは組織内の他のチームが使用する内部製品であるということです。したがって、プラットフォームチームは、顧客が自社内の他のチームである製品を構築しています。

移行作業の例

どのような種類の変更について話しているのでしょうか？比較的簡単な移行の1つは、バージョンアップです。共有コンポーネントライブラリのアップグレード、またはサービスの基盤となる言語ランタイムのアップグレードなどです。

一般的な大規模な移行としては、サードパーティシステムの直接統合を内部ラッパーに置き換えることが挙げられます。たとえば、ログ、分析、またはオブザーバビリティのインストルメンテーションを、プラットフォームチームが管理する共有内部ライブラリを使用するように移動したり、何らかの種類の内部ゲートウェイサービスを介して支払い処理業者との直接統合を置き換えたりすることなどです。

別の種類の移行としては、廃止された内部サービスへの既存の統合をその代替サービスへの統合に置き換えることが挙げられます。たとえば、古いUserサービスから新しいAccount Profileサービスへの移動、またはcredit-pullerとcredit-reportingサービスの使用を新しい統合されたcredit-agency-gatewayサービスへの移行などです。

最後の例は、インフラストラクチャレベルのリプラットフォーミングです。プロダクトチームが所有するサービスのDocker化、サービスメッシュの導入、サービスのデータベースをMySQLからPostgresへの切り替えなどです。

プラットフォーム移行では、プロダクトチームはこれらの変更を行うことにそれほど意欲的ではないことがよくあります。新しいプラットフォームが特にエキサイティングな新しい機能を提供する場合、意欲的である場合もありますが、実際には自分自身で大きな価値を得ることなく、より広範なアーキテクチャイニシアチブの一環としてこのシフトを求められることがよくあります。

コラボレーションパターン

プラットフォーム移行作業に有効なチーム間コラボレーションパターンを見てみましょう。

作業を外注する

プラットフォームチームは、プロダクトチームのバックログにチケットを発行し、必要な変更を自分たちで行うように依頼できます。

このアプローチにはいくつかの利点があります。スケーラブルです。実装作業は、コードベースに作業が必要なすべてプロダクトチームに外注できます。また、追跡可能で管理しやすいです。チケットの発行は、プログラムマネージャーやその他のプロジェクトマネジメント担当者によって行われることがよくあります。

しかし、欠点もあります。非常に遅いです。一部のプロダクトチームが作業を開始するまでに長いリードタイムがかかります。また、優先順位の駆け引きが必要です。この作業を依頼されたチームは、多くの場合、具体的なメリットを受けないため、より緊急または影響力の大きい他のタスクよりもこの作業の優先順位を下げる傾向があります。

プラットフォームチームが作業を行う

プラットフォームチームは、3つの類似しているが異なるパターン、Tour of Duty、Trusted Outsider、またはInternal Open Sourceを使用して、プロダクトチームのコードベースに変更を加えることを選択する場合があります。

Tour of Dutyでは、プラットフォームチームのエンジニアがプロダクトチームに「埋め込まれ」、そこから作業を行います。

Trusted OutsiderとInternal Open Sourceでは、プロダクトチームは、プラットフォームチームのエンジニアからのプルリクエストをコードベースに受け入れます。

チケットを発行する方法と同様に、プラットフォームチームが作業を行うことにも、いくつかの長所と短所があります。

利点としては、作業を行う必要があるチーム（プラットフォームチーム）が作業を行うチームでもあるため、変更を行うまでのリードタイムが短縮されることがよくあります。整合性のあるインセンティブにより、プラットフォームチームは、コードベースを所有する製品チームよりも、自分の作業を優先する可能性がはるかに高くなります。

欠点としては、プラットフォームチームが移行作業を自ら行う方法は、製品チームがそれをサポートできる場合にのみ機能します。製品チームは、プラットフォームエンジニアがしばらくの間チームに参加することに満足している必要があります。または、プラットフォームエンジニアと十分な時間を費やして、コードベースへの変更を独立して行うことを信頼している必要があります。あるいは、内部オープンソースアプローチをサポートするために必要な大きな投資を行っている必要があります。

もう1つの欠点は、この自己解決戦略はスケーラブルではないことです。プラットフォームチームのエンジニアリング能力は、製品デリバリーチームと比較して常に少なくなり、製品チームにエンジニアリング作業を委任しないことで、その能力のすべてが無駄になります。

実際には、もう少し複雑です

実際には、多くの場合、これらのアプローチが組み合わされています。移行を任されたプラットフォームチームは、プログラムマネージャーが15の製品デリバリーチームにチケットを発行し、その後、ある程度の時間を費やして彼らに作業をさせるかもしれません。しばらくすると、いくつかのチームが自分で作業を終えますが、他のことに特に忙しい、または移行作業を引き受けることに特に気が進まない、遅れを取っているチームが残ります。その後、プラットフォームチームは袖をまくり、他の、それほどスケーラブルではないアプローチを使用して、自ら変更を行います。

コラボレーションパターン

多くのプラットフォームチームにとって価値のある目標は、StripeやAuth0のような、ドキュメントが充実していて使いやすい、製品エンジニアがプラットフォームチームとの直接的なサポートや連携を必要とせずにプラットフォームを使用できる完全にセルフサービスのプラットフォームを構築することです。

実際には、特に初期段階では、ほとんどの内部プラットフォームはそこまで到達していません。内部プラットフォームを使い始めた製品エンジニアは、多くの場合、ドキュメントの不足、分かりにくいエラーメッセージ、そして混乱を招くバグに遭遇します。多くの場合、これらの製品チームは手を上げて、プラットフォームチームに協力して内部プラットフォームの機能の使用を開始するよう依頼します。[1]

プラットフォームの利用者がプラットフォームの所有者に実践的なサポートを求めている場合、私たちは再びチーム間の連携に戻り、再び異なるパターンが関わってきます。

プロフェッショナルサービス

場合によっては、製品チームがプラットフォームチームにプラットフォーム消費コードの記述を依頼する場合があります。これは、製品チームがプラットフォームの使用方法を理解するのに苦労しているためかもしれません。あるいは、このアプローチの方が製品チームの労力が少なくなるためかもしれません。場合によっては、製品チームが自分自身で作業を行うべきではないと考えている誤解があるだけです。これは、製品チームがインフラニーズをセルフサービス化するDevOpsモデルに移行する際に発生する可能性があります。

このシナリオでは、プラットフォームチームは、エンジニアリング組織内で一種のプロフェッショナルサービスグループとなり、顧客のシステムに自社製品を統合します。

このプロフェッショナルサービスモデルは、連携パターンの組み合わせを使用します。まず、製品チームは通常、プラットフォームチームのサービスを要求するチケットを発行します。これは、プラットフォーム移行作業で前に見たパターンと同じですが、逆になっています。この状況では、製品チームがプラットフォームチームにチケットを発行し、ヘルプを求めています。その後、プラットフォームチームは実際には信頼できる外部者または内部オープンソースパターンを使用して作業を実行できます。

この連携モデルの一般的な例としては、製品チームがインフラストラクチャの変更を必要とする場合です。新しいサービスをスピンアップしたり、APIゲートウェイに新しい外部エンドポイントを登録したり、構成値を更新したりしたい場合、プラットフォームチームに適切な変更を行うよう依頼するチケットを発行します。

このパターンは、インフラ領域で一般的に見られます。これは、既存の習慣を永続させるためです。セルフサービスインフラが登場する前は、チケットの発行が、製品チームがインフラストラクチャの変更を行うための標準的なメカニズムでした。

ホワイトグローブオンボーディング

初期段階でドキュメントが不足しているプラットフォームの場合、プラットフォームチームは、「ホワイトグローブ」アプローチを使用して新しい製品チームのオンボーディングを選択し、これらの初期採用者と協力して開始する可能性があります。これにより、最初に導入する製品チームにとって負担を軽減することで、新しいプラットフォームの採用を促進できます。また、プラットフォームチームは、最初の顧客がプラットフォームの機能をどのように実際に使用しているかについての貴重な洞察を得ることができます。

このホワイトグローブモデルは、通常、ツアーオブデューティ連携パターンを使用して実現されます。1人以上のプラットフォームエンジニアが消費チームに埋め込まれ、そのチーム内で必要なプラットフォーム統合作業を行います。

コミュニティオブプラクティス

プラットフォームが成熟し、使いやすくなると、プラットフォームチームは実践的な統合作業から離れ、よりコンサルティング的な役割に移行できます。

このコンサルティングモードには、「オフィスアワー」を開催して、消費チームが質問に来ることができるようにすることや、プラットフォームの代表者が消費チームの計画および設計セッションに焦点を当てたアドバイスとガイダンスを提供することが含まれます。チームトポロジの言葉で言えば、これはプラットフォームチームが促進インタラクションモードで動作していることになります。

大規模で豊富なプラットフォームの場合、最終的にはピアサポートモデルに移行します。プラットフォームチームは、プラットフォームのユーザー向けのコミュニティオブプラクティスを立ち上げるために時間を投資します。これには、コミュニティのスラックチャンネルやメーリングリスト、ヘルプを求めたり興味深いアイデアを紹介したりするための定期的なコミュニティオブプラクティスミーティング、さらには年次実務者オフサイトなどが含まれる場合があります。

ハンズオンはスケールしない

プラットフォームチームがコンシューマーに提供する必要がある実践的なサポートのレベルは、プラットフォームの開発者エクスペリエンス（ドキュメントの充実度、統合と操作の容易さ）の成熟度によって大きく異なることがわかります。

プラットフォームの初期段階では、プラットフォーム消費にプラットフォームチーム自体から多くのエネルギーを必要とすることは理にかなっています。開発者エクスペリエンスはまだ少し不安定で、プラットフォームの機能はまだ構築中であり、消費チームはモルモットとして自分の時間を投資することに少し懐疑的かもしれません。さらに、製品チームと協力することは、プラットフォームチームが顧客とそのニーズを理解するための素晴らしい方法です。

しかし、実践的なサポートはスケールしません。広範なプラットフォームの採用が目標である場合、プラットフォームチームは、実装作業に溺れないように、プラットフォームの開発者エクスペリエンスに投資する必要があります。

また、プラットフォームユーザーにどのようなサポートモデルを期待すべきかを明確に伝えることも重要です。プラットフォーム導入の初期段階でホワイトグローブサポートを受けている製品チームは、別途指示されない限り、将来もそのエクスペリエンスを再び享受することを期待します。

チケットを発行する

製品チームは、プラットフォームチームにチケットを発行して、プラットフォームに必要な変更を行うよう依頼できます。これは非常にフラストレーションのたまるアプローチになりがちです。多くの場合、製品チームは、プラットフォームに何かが不足していることに、必要になった瞬間に初めて気づき、プラットフォームチームが作業の優先順位を付けて実行するまでのターンアラウンドタイムが長すぎる可能性があります。プラットフォームチームは通常、受信リクエストで過負荷状態にあります。これにより、プラットフォームチームがボトルネックとなり、製品デリバリーチームの進捗が妨げられます。

エンジニアを業務に配置する

十分な警告があれば、チームは、必要なプラットフォームの機能強化に取り組むためにエンジニアを一時的に再配置することで、プラットフォームの機能のギャップを埋める計画を立てることができます。製品エンジニアは、プラットフォームチームでツアーオブデューティを行うか、あるいはプラットフォームエンジニアが埋め込み型エキスパートとしてしばらくの間製品チームに参加することができます。

チーム間でエンジニアを移動すると、生産性に短期的な影響が出るのは避けられませんが、埋め込み型のエンジニアを配置することで、製品チームとプラットフォームチーム間のクロスチームコミュニケーションの量を減らすことで、長期的には効率を向上させることができます。埋め込み型エンジニアはアンバサダーとして機能し、コミュニケーション経路をスムーズにし、伝言ゲームを減らします。

この初期費用と継続的な利益の式は、エンジニアの再配置は、大規模なプラットフォームの改善に最適なオプションであることを意味します。数週間エンジニアを別のチームに移動することは、有益なことよりも混乱を招きます。

このような一時的な割り当ては、埋め込みエンジニアが孤立感を抱かないよう、比較的成熟した管理体制も必要です。埋め込みエキスパート（製品チームに再配置されたプラットフォームエンジニア）の場合、プラットフォームの利用作業を行うだけの一般的な「余剰人員」になり、製品チームが必要とするプラットフォームの改善に積極的に取り組まなくなるリスクもあります。

遠隔でプラットフォームに取り組む

プラットフォームチームが内部オープンソースのアプローチを採用している場合、製品チームは必要なプラットフォームの変更を直接実装することができます。プラットフォームチームの役割は主にコンサルティングとなり、設計に関する推奨事項を提供し、製品チームのPR（プルリクエスト）をレビューします。いくつかのPRの後、製品エンジニアはプラットフォームチームからの信頼を得て、コミット権限が付与され、信頼できる外部者になることさえあります。

多くのプラットフォームチームはこの状況を目指しています。顧客が独自の改善を実装し、自分たちが作業を行う必要がなくなるのは素晴らしいことです！しかし、内部オープンソースの現実は、一般的なオープンソースと同様です。外部からの貢献をサポートするには驚くほどの投資が必要であり、消費者の大部分は意味のある貢献者にはなりません。

プラットフォームチームは、これらの貢献をサポートするための十分な投資を行わずに、コードベースを外部からの貢献に開放しないように注意する必要があります。プラットフォームチームが全社説明会でコードベースを共有リソースであると誇らしげに宣言しておきながら、「いや、いや、そんなやり方ではありません！」と他のチームからの貢献者に繰り返し伝える羽目になる場合、双方に大きな不満が生じる可能性があります。

協調的であること、しかし少しの間だけ

チームトポロジーでは、2つのチーム間の適切な境界を設計する最適な方法は、当初は集中した非常に協調的なモードで協力することだと指摘しています。 埋め込みエキスパートやツアー・オブ・デューティなどのパターンを考えましょう。この期間は、システム間およびチーム間で作成する最適な境界とインターフェースを探るために使用できます（コンウェイの法則は、これらが不可分であることを教えてくれます）。しかし、「チームトポロジー」の著者は、この協調的なモードに長く留まりすぎないことが重要だと警告しています。プラットフォームチームは、インターフェースを定義することに尽力し、チケットを発行するや内部オープンソースなどのパターンを使用して、「サービスとしての」モードに迅速に移行することを目指すべきです。プラットフォームの利用セクションで説明したように、より協調的なインタラクションモデルは、プラットフォームチームに関しては単純にスケールしません。さらに、協調的なモードは、利用するチームにはるかに大きな認知的負荷を与えます。よりハンズオフなインタラクションスタイルに移行することで、製品デリバリーチームは、自身の成果に集中する時間を増やすことができます。「チームトポロジー」では、この認知的負荷の軽減をプラットフォームチームの定義目的と考えており、私もこの考えに強く賛成します。

私の意見では、高度な協調からサービスとしての移行をナビゲートすることは、若いプラットフォームチームが直面する最大の課題の一つです。お客様は、ハイトゥッチなエクスペリエンスに慣れてしまいます。優れたドキュメントの作成は困難です。「ノー」と言うことは困難です。

協調的なモードで運用されているプラットフォームチームは、スケーラビリティの課題に常に目を光らせておく必要があります。よりスケーラブルでハンズオフなアプローチへの移行の必要性が視野に入ってきたら、プラットフォームチームはその移行を顧客に知らせ始めるべきです。インタラクションモデルがどのように変化し、なぜ変化するのかを早期に警告することで、製品チームは準備を行い、プラットフォームに対するメンタルモデルをより自立的なものへとシフトし始めることができます。

移行は困難な場合がありますが、ためらうと事態は悪化します。製品デリバリーチームは、プラットフォームプロバイダーがどのようにサポートするかについての、明確に伝えられたエンゲージメントルールを高く評価するでしょう。さらに、ハンズオンな協力という支えを取り除くことで、セルフサービスインターフェース、ドキュメントなどを改善するための強力な動機が生まれます。ここでもコンウェイの法則が有効です。チームの統合方法を再定義することで、チームのシステムの統合方法にも圧力がかかります。