プラットフォームについて私が語るもの

そもそも「プラットフォーム」とは何か？

言葉は難しいようです。「プラットフォーム」は、大規模なデリバリー速度と効率を向上させるために非常に重要なアプローチを表すために使用できる、最も曖昧な用語の1つです。この記事のタイトルにあるように、最近私が最も多く話してきたことです。

ソフトウェアとハードウェアのプラットフォームの定義は数多く存在し、一般的に、アプリケーションが実行できる動作環境であり、ファイルシステムやセキュリティなどの再利用可能な機能を提供するものとして記述されています。

組織レベルで拡大すると、「デジタルプラットフォーム」は同様の特性を持っています。チームが再利用可能な機能によってサポートされ、顧客への製品機能のデリバリーを迅速に行うことができる動作環境です。

デジタルプラットフォームとは、魅力的な内部製品として配置された、セルフサービスAPI、ツール、サービス、ナレッジ、サポートの基盤です。自律的なデリバリーチームは、プラットフォームを利用して、より高いペースで、調整を減らして製品機能を提供できます。

Thoughtworksでは、プラットフォーム機能の5つの主要な柱を持つモデルを開発しました。これらの機能には、デリバリーインフラストラクチャ、APIとアーキテクチャの修復、セルフサービスデータ、実験的インフラストラクチャ、顧客接点テクノロジーが含まれます。グローバルな経験を通して、これらがデジタル企業になるための能力を解き放つために投資する最も重要な共有機能であることを学びました。

この記事は、クラウドホスティングやDevOpsツールを含む、デリバリーインフラストラクチャとして分類するプラットフォーム機能に焦点を当てています。ただし、同じ定義特性は他のプラットフォーム機能にも当てはまります。

まず、非プラットフォームから

数年前、私はオーストラリアの大手金融サービス組織（BigCoと呼びましょう）でコンサルティングに従事していました。現場に到着した私の最初の目標は、アプリケーションインフラストラクチャ、ホスティング、運用分野で何が起こっているかを理解することでした。課題がどこにあるかを本当に理解するために、システムのワークフローを通じて実際の変更をたどり、物事がどのように行われているかを確認することにしました。

クラウドと自動化への大きな投資にもかかわらず、BigCoはインフラストラクチャと運用分野のチームを従来の構成で維持していました。チームは技術的な能力に従って分割されていました。私たちはいくつかの典型的な変更を追跡しましたが、それらのそれぞれにはこれらのチームの数が含まれていました。アプリケーションサーバーの構成に変更がある場合、これは「ミドルウェア」チームが所有しています。しかし、ミドルウェアチームは基盤となるオペレーティングシステムの構成にはアクセスできません。それは「ミッドレンジ」チームの責任です。データベースの変更はDBAチームが行う必要があります。ネットワークの変更はネットワークチームを経由する必要があります。ロードバランサーの変更はマネージドサービスプロバイダーが行う必要があり、ファイアウォールの変更は別のプロバイダーが行います。また、主にオーケストレーションに限定された自動化機能を所有する、別の自動化チームもありました。もちろん、個別のエンタープライズモニタリング、セキュリティ、変更、リリース管理チームもありました。

図1：高度に専門化された個別のインフラおよび運用チーム

これらのBigCoチームのそれぞれは独自の管理構造の下にあり、独自の働き方をしていました。各チームは、独自の技術ドメインにおける高い効率性を目指し、専門性を集中化し、非差別化能力を外注し、ガバナンスを適用し、コストを削減していました。しかし、BigCoの誰もが顧客への機能のエンドツーエンドデリバリーの有効性で評価されていませんでした。

インフラストラクチャに関連する小さな変更には、数週間から数ヶ月かかり、顧客への対応に大きな影響を与えました。これは大きな影響を与えますが、それだけではありません。変更が困難で遅いと、変更プロセスでの障害がさらに遅延を引き起こすことに気付きます。これは、エンジニアとマネージャーに、可能な限り変更の数を最小限に抑え、アプリケーションとインフラストラクチャに絶対に必要な変更のみを行うという行動を促します。

図2：アプリケーションデリバリーチームが必要とする変更には数週間または数ヶ月かかる

BigCoでは、これによりアプリケーションとインフラストラクチャの内部品質が徐々に低下し、あらゆる場所に多くの小さな環境と構成設定の矛盾が生じていました。チームは、品質と一貫性を維持または向上させる小さな改善とリファクタリングを行うのをやめました。これは実際には自己強化です。品質が予測可能性に影響を与え、変更のリスクを高めるため、チームはより慎重になり、改善が困難になります。

要約すると、BigCoでのインフラストラクチャとホスティングの処理は遅く、困難でした。

「バックログカップリング」の影響

アジャイルソフトウェアデリバリーの簡単な方法は、常にデジタルチャネルにあり、ビジネスリーダーと緊密に協力する小さな自律型チームが顧客ニーズを特定し、それらのニーズを満たす機能を構築します。しかし、デジタル製品チームがより迅速かつ柔軟になるほど、それに適用される外部の制約はより増幅されます。

デジタルチームは、一般的に、3つの主要な分野で制約されています。それは、ゆっくりと変化するコアトランザクションシステム、高品質なデータと分析へのアクセス、そして共有インフラストラクチャと運用です。

私は、バックログがアジャイルデリバリーチームによって頻繁に使用される計画ツールであるため、「バックログカップリング」という用語を使用します。

図3：複数のチームのバックログ（作業キュー）間で変更に依存関係がある場合に、バックログカップリングが発生します。

これは単純な概念です。デジタル製品チームのバックログ内の多くのアイテムが、別のチームで対応するバックログアイテムを発生させる必要がある場合、生産性と応答性は非常に低下します。バックログは組織全体に連鎖し、それぞれ異なるシステムに従って優先順位付けられます。タスクはカンバンに大きな赤い「ブロック」ステッカーが貼られ、利害関係者は怒り、共有サービスプロバイダーはできる限り対応します。通常は最も大きな声に反応します。

バックログカップリングはどの程度深刻ですか？オーストラリアの電気通信会社では、同僚がデリバリーセンターを通過する数百個の作業またはタスクを調査しました。特に、別のチームのメンバーによる作業をスケジュールすることなく、一部のタスクは依存関係なしに単一のチームによって完了できます。別のチームを待たなければならなかったタスクは、経過時間において10〜12倍遅かったです。したがって、依存関係は実際には大きな影響を与えます。

これは多くの点で私たちを苦しめます。顧客ニーズへの純粋なスループットと対応性に悪影響を与え、依存関係をより効率的に管理するために、より長期的な計画を推進します。また、成果に対するチーム自身の責任を損ない、私が観察してきた多くのチームにとって、これはモチベーションを低下させます。チームは責任を転嫁し、独自の継続的な改善を求めるのをやめることが簡単になります。

多くの騒々しい内部顧客にサービスを提供する過負荷のチームの1つにいるのは、あまり楽しくありません。

最近の「アジャイルのスケーリング」の伝統は、複数のチーム間の優先順位を調整しようとする計画セレモニーを導入することで、この問題を1つの方法で解決しようとします。これは、全体的な自律性、応答性、変化への対応能力の低下と引き換えに、明確な整合性の向上を目指しています。これが唯一の方法ではありません。

したがって、優れたプラットフォームの特性は、バックログカップリングの量を削減することであることは明らかです。プラットフォームは、チケットを発生させたり、作業を割り当てたりする必要のないサービスを提供する必要があります。セルフサービスは、優れたプラットフォームの重要な定義特性です。

プラットフォームは、チームにセルフサービスアクセスを提供する必要があります。具体的には、プラットフォームの機能と資産のセルフサービスプロビジョニング、セルフサービス構成、そしてセルフサービス管理と運用を可能にする必要があります。

この中途半端な表面的なプライベートクラウド

BigCoはセルフサービスの必要性を認識していましたが、レガシーインフラストラクチャと思考に根付いた大規模なインフラストラクチャと運用組織でこれをどのように達成するかを想像するのに苦労していました。中央集権化された自動化ツールへの投資は既にありました。そのため、最初の取り組みは、アプリケーションデリバリーチームがインフラストラクチャをセルフプロビジョニングするためのセルフサービス機能を作成することでした。

非常に固定されたテンプレートに従って、デリバリーチームがコンピューティングインスタンスを要求できるように、セルフサービスツールが構築されました。プロビジョニングされた仮想マシンインスタンスは構成が固定されており、セキュアにロックダウンされていたため、フリートのコントロールは中央ミッドレンジチームに残ることができました。インスタンスで何か役に立つことを行うには（たとえば、パッケージのインストール、ネットワークへの接続、ストレージの接続、ロードバランサーのプロビジョニング、監視ツールの構成、その他何でも）、デリバリーチームはチケットを発生させる必要がありました。

図4：BigCoは、アプリケーションとインフラストラクチャの運用方法の基本を変更せずに、簡素なセルフサービスAPIを構築しました。その結果、デリバリーのペースは大幅には変わりませんでした。

これは最初のイテレーションに過ぎないと主張することもできますが、実際そうでした。しかし、意図は明確でした。BigCoのインフラストラクチャと運用グループは、その時点では独自の組織的なサイロを打破し、デリバリーチームに大きな責任（そしてアクセス権）を移譲する準備ができていませんでした。そして、意図が良かったとしても、そのAPIを必要なレベルまで段階的に構築するために必要な膨大な労力は、現実的ではありませんでした。

このアプローチを「表面的なプライベートクラウド」と呼んでいます。既存の仮想化プラットフォームにラベルを貼り替え、デリバリーチームが非常に制限された方法で使用できるようにしますが、中央管理を削減する真の意図はありません。

一方、BigCoでは並行して、デリバリーチームが本番システムにAmazon Web Services（AWS）を直接使用できるようになりました。前例ができた途端、デリバリーチームはAWSの使用に殺到しました。

AWSは、デリバリーチームが直接利用するのに魅力的なプラットフォームです。完全にセルフサービスであり、責任の境界が明確です。「あなたが構築し、あなたが運用する」というマントラになります。AmazonはAPIまでのプラットフォームを構築および運用し、高可用性を確保します。そして、あなたのアプリケーションデリバリーチームは、その上に配置されるアプリケーションを構築、構成、および運用します。

それが物語の終わりでしょうか？

自律性により市場投入時間が短縮され、イノベーションが増加する

私が会うほとんどの組織は、「再利用のために構築する」というデフォルト設定を持っています。リスク回避とコスト削減の組み合わせによって推進される能力の中央集権化です。

図5：ほとんどの組織は、コスト効率を高めるために、テクノロジーの選択を中央で強制的に決定しています。

ここ数年、私は大規模なオーストラリア（およびグローバル）テクノロジー企業、WebBiz（仮称）でテクノロジーリーダーシップチームの一員として働く幸運に恵まれました。WebBizはオンラインプレゼンスが非常に大きく、数百名ものエンジニアを抱える巨大企業であり、BigCoと同様の多くの課題に直面していますが、迅速な変化と改善を実現できるほど規模が小さい企業です。

私がWebBizに在籍していた間、リースされたデータセンター内の仮想化プラットフォームへのほとんどのアプリケーションの展開から、AWSへの新しいデフォルト展開ターゲットへの複数年にわたる移行を開始しました。また、アプリケーションと（ほとんどの）インフラストラクチャの構築と運用の責任を製品チームに移譲し、従来の中央集権型運用からDevOpsへの最も完全な移行を実現しました。「あなたが構築し、あなたが運用する」という考え方で小規模な組織を立ち上げることはそれほど難しくないと思いますが、移行には勇気と一貫したビジョンが必要です。WebBizはその点で非常にうまくやってきました。

移行の一環として、WebBizの製品チームは、スタックのあらゆる部分を構成および運用する方法について完全な自律性を付与されました。このアプローチは「チーム管理インフラストラクチャ」と呼ばれていましたが、初期にいくつかのデフォルトが設定されたものの、各チームは中央からの指示がほとんどなく、スタックのあらゆる部分について独自の決定を下すことができました。

WebBizは、組織の典型的なデフォルトの偏見を成功裏に逆転させました。テクノロジーの多様化と発明を優先しました。これはスタッフのエンゲージメントレベルを高め、エンジニアはより深いスタックのテクノロジーの経験を得て、発明を促進し、展開されたものに対する責任のレベルを迅速に確立し、チーム間の依存関係の大部分を排除しました。また、自分が運用するものに責任を負うことに関心があり、自律性にうまく対応し、困難なビジネスおよび技術的な問題を解決することに関心のあるエンジニアをWebBizに引き寄せました。

技術の多様化は抵抗を増大させる

しかし、すべての利点がある一方で、完全な自律性への移行には明確なコストがかかります。AWSをプラットフォームとして採用することで、WebBizは中央のインフラストラクチャチームへのバックログカップリングを解消しました。しかし、WebBizのすべてのチームは、インフラストラクチャの構築と運用に関するあらゆる側面について、一連の決定を下さなければなりません。

図6：クラウドネイティブランドスケープ（出典：www.cncf.io)

上記は、クラウドネイティブランドスケープの最新バージョンです。クラウドネイティブアーキテクチャの構築における懸念事項別にグループ化された一般的なオープンソースと製品の提供を捉えようとする試みです。混雑したマップであり、最も確立されたオファリングのみです。これらの領域やその他の領域について、チームはオプションを評価し、ニーズに合ったオファリングを選択し、そのオファリングの統合と運用方法を学ぶ必要があります。

複製されたインフラストラクチャのメンテナンスの遅れに加えて、各チームがインフラストラクチャの選択肢を継続的に調査および評価するための継続的なオーバーヘッドがあります。また、スキルやスタッフのチーム間の転送に反する摩擦も生じます。異なるスタックを実行しているチームです。

WebBizは現在、より明確に定義されたデリバリーインフラストラクチャプラットフォーム、つまり製品チームが利用してドラッグを減らし、生産性を向上させることができる魅力的なデフォルトセットの確立を開始しています。

しかし、自律性によって得られた利点を失うリスクはありませんか？

プラットフォームを内部製品として

自律的な多様化と強制的な統合の適切なバランスを見つけることは実際には困難であり、事前に予測することはさらに困難です。このバランスを見つけるための成功の重要な要素は、プラットフォームが使いやすいものでなければならないということです。単なる指示では成り立ちません。既存の共有インフラストラクチャ機能は独占権を持ち、デリバリーチームには実行可能な代替手段がありません。少しの競争は、すべてのプラットフォーム機能が制約とカップリングを作成するのではなく、価値を追加することを保証する製品思考を推進するための必要な要素です。

プラットフォームの魅力を高めるものとは？いくつかアイデアをご紹介します。

• プラットフォームは、圧倒的多数のユースケースでセルフサービスです。
• プラットフォームは構成可能であり、独立して使用できる個別のサービスが含まれています。
• プラットフォームは、デリバリーチームに柔軟性のない作業方法を強制しません。
• プラットフォームは、すぐに安価に使用を開始でき、容易なオンランプがあります（例：クイックスタートガイド、ドキュメント、コードサンプル）。
• プラットフォームには、共有のための豊富な内部ユーザーコミュニティがあります。
• プラットフォームは、デフォルトで安全でコンプライアントです。
• プラットフォームは最新です。

最終的に、デリバリーインフラストラクチャプラットフォームは、独自のものを構築および維持するよりもプラットフォーム機能を利用する方が簡単である場合に魅力的です。Netflixは、中央集権化されたツールを「舗装された道路」と表現しています。チームはツールを使用する必要はありませんが、独自の代替手段を維持するすべてのコストを負う責任があります。

プラットフォームは、ソフトウェアやAPIだけではありません。ドキュメント、コンサルティング、サポート、啓蒙、テンプレート、ガイドラインでもあります。

ちょっと待って… これは「DevOpsチーム」じゃないの？

うまくいかなかった場合？はい、そうかもしれません。

私たちは「DevOpsは役割/チーム/ツールではない」という戦いを完全に失いましたね？私たちはこれらの戦いを繰り返し失っています。次回は新しい戦略でしょうか？

-- Phil Calçado

（DevOpsについてはまだ敗北を認める準備ができていません。念のためですが、「DevOps」というチームがある場合、その言葉はあなたが思っている意味ではありません。）

デリバリーインフラストラクチャプラットフォームを構築および運用するためのチームを構築することを選択できます。ほとんどの場合、それが開始するための最良の方法だと思います。その場合、プラットフォームチームとその顧客（明確にするためにアプリケーションチームと呼びます）の責任範囲を明確にする必要があります。

アプリケーションチームは、プラットフォーム上でプロビジョニングおよび展開するアプリケーションコンポーネントとアプリケーションインフラストラクチャの構築、展開、監視、およびオンコールを担当します。プラットフォームチームは、プラットフォームコンポーネントと基盤となるプラットフォームインフラストラクチャの構築、展開、監視、およびオンコールを担当します。

理想的には、プラットフォームチームはプラットフォーム上で実行されているアプリケーションについてさえ知りません。プラットフォームサービス自体の可用性のみを担当します。

このように、アプリケーションチームとプラットフォームチームの両方が、独自の製品の構築と運用について責任を負います。「あなたが構築し、あなたが運用する」は依然として適用されます。

どこから始めれば良いのか？

デリバリープラットフォームの確立には、いくつかの前提条件があります。まず、テクノロジーのデリバリーの資金調達と人員配置の主要なメカニズムとして「プロジェクト」から離れるという取り組みを既に進めている可能性があります。プラットフォームは製品であり、構築と運用の両方に携わる長期的かつ安定した製品チームが必要です。

第二に、アプリケーションの運用責任の一部またはすべてをアプリケーションチームに移し、中央集権化された運用とサポートから遠ざける意思が必要です。プラットフォームは、アプリケーションチームが構築したものを責任を持つことができるようにするツールとサービスを提供します。サポートが中央集権化されている限り、これは起こりません。

第三に、厳格な実装の一貫性を、自律的なアプリケーションチームに付与する自由と責任と交換する意思が必要です。

いくつかの注意点があります。

• あなたのプラットフォームは、インストールできるインフラストラクチャ、ツール、APIだけではありません。効果的にするために、デリバリーチームが新しい機能をどのように迅速に採用するか、どのような選択肢を独立して行うか、または適切なデフォルトを使用するか、そして機能を継続的に維持する方法を回答する必要があります。これには、内部コンサルティングスキル、トレーニング、啓蒙が必要です。
• 必要なプラットフォーム機能はわかりません。そのため、真に証明されたニーズに基づいて小さく始めてください。アプリケーションチームから既に実証済みのソリューションを活用し、それらを使用するチームと共同で機能を作成およびテストするジョイントベンチャーを試みてください。
• 既に持っている限定的な仮想化ホスティングとロックダウンされた中央管理ツールに、プラットフォームラベルを適用しないように注意してください。