我に似せる者は生き、我を象る者は死す(本質を理解して創造的に学ぶ者は発展し、表面的な模倣に留まる者は衰退する)。
はじめに
「Platform Engineering: A Guide for Technical, Product, and People Leaders」は、現場での実践知を出発点として、プラットフォームエンジニアリングの本質に迫る実践的なガイドとして、技術リーダーから上級管理職まで向けた幅広い読者層に向けて書かれています。個人的にはもう少しだけ広げて開発者やプラットフォームを実際に使う側も読んでも学びのある本だと思いました。著者のCamilleとIanの豊富な経験が凝縮された本書は、単なる表面的な手法の模倣ではなく、実際の現場での試行錯誤から導き出されたプラクティス、そしてその背後にある根本的な原理と思想を探求し、それが現代のソフトウェア開発組織においていかに革新的な価値を生み出すかを浮き彫りにしています。
本書の真価は、プラットフォームエンジニアリングを単なる技術的な手法の集合としてではなく、日々の実践から得られた知見を体系化し、組織の進化と持続的な成長を促す戦略的な思考基盤として捉えている点にあります。技術的な実装の詳細よりも、組織が現場の文脈に根ざした実践を重ね、そこからプラクティスを抽出し、最終的にプラットフォームエンジニアリングの本質的な原則を理解して創造的に応用していく方法論に重点が置かれています。これは、現代のソフトウェア開発組織が直面する複雑性の管理と開発者体験の向上という課題に対する、本質的かつ持続可能な解決の道筋を示すものとなっています。
プラットフォームエンジニアリングの重要性
プラットフォームエンジニアリングは、複雑なソフトウェア環境でのイノベーションを促進する開発者体験の向上に不可欠な鍵となり、クラウドへの移行だけでは解決できない問題に対処するための重要な基盤を提供しています。さらに、組織の成長に伴うスケーラビリティの要求とセキュリティニーズの両方に対応する重要な役割を果たすことで、現代のソフトウェア開発組織にとって極めて重要な存在となっています。
本書が組織的・戦略的側面に焦点を当てているのに対し、より技術的な側面、特にCloud Nativeな実装に興味がある方には、「Platform Engineering on Kubernetes」がおすすめです。こちらの書籍では、Kubernetesを基盤としたプラットフォームエンジニアリングの実践的なアプローチが詳細に解説されています。
両書を併読することで、プラットフォームエンジニアリングの組織的側面と技術的側面の両方を深く理解することができ、より包括的な知識を得ることができるでしょう。
本書の構成と特徴
本書は現場での実践を起点としながら、プラットフォームエンジニアリングを組織的、戦略的に展開するためのガイドとして構成されており、著者たちが数々の現場で直面した課題と、そこから得られた具体的で実行可能な知見を提供しています。特筆すべきは、個々の技術的解決策にとどまらず、チーム構成や製品管理、ステークホルダーマネジメントなど、現場で真に重要となる組織的側面にも焦点を当てている点で、日々の実践に携わる技術リーダーからCTOやSVPなどの組織の舵取りを担う上級管理職までを想定した実践的な内容となっています。
最後に、これら3つのパートは、現場での実践から抽出された原則（Part I）、その原則に基づく具体的なプラクティス（Part II）、そしてそれらの効果を測定・評価する方法（Part III）という、現場起点の論理的な流れを形成しています。特に、第3部で提示される成功の定義は、第1部で説明される現場から導き出された原則と、第2部で示される実践的なアプローチを有機的に結びつける重要な役割を果たしています。
本書は、プラットフォームエンジニアリングの現場で直面する本質的な難しさを率直に語っています。具体的には、「技術的に面白いから作る」のではなく現場で真に必要とされるものを見極めて提供するという価値提供の本質、計画の難しさを認識しつつも現場の文脈に応じて適切に実行するという実践知、そして組織の重要なシステムを支える責任を全うするための運用の成熟という現場力の醸成といった課題を挙げています。これらの課題に対して、本書は原則に基づきながらも現場の実態に即した解決の道筋を示しています。
Part I. Platform Engineeringの本質と意義
第1部は、Platform Engineeringの根本的な「なぜ」と「何を」に焦点を当てています。Simon Sinekの「イノベーションは夢からではなく、苦闘から生まれる」という言葉に象徴されるように、本章では現代のソフトウェア開発が直面する複雑性と変化の課題に対して、Platform Engineeringがなぜ適切なアプローチなのかを解説しています。
特に印象的なのは、Platform Engineeringの4つの柱（製品思考、ソフトウェアエンジニアリング、包括的アプローチ、運用効率）について、単なる理論的な枠組みではなく、実践的な基盤として提示している点です。私の経験でも、これらの要素のバランスを取ることが、プラットフォームチームの成功への鍵となっています。
また、国内の参考資料として、jacopenさんの『「共通基盤」を超えよ！ 今、Platform Engineeringに取り組むべき理由』がおすすめです。この記事を読むことで、本書の全体像がより明確に理解できるので一読してもらいたいです。
Chapter 1. Why Platform Engineering Is Becoming Essential
第1章「Why Platform Engineering Is Becoming Essential」は、プラットフォームエンジニアリングが現代のソフトウェア開発組織において不可欠となっている背景と理由について、包括的な視点から解説しています。著者は、過去25年間のソフトウェア組織が直面してきた共通の課題から説き起こし、クラウドコンピューティングとオープンソースソフトウェア（OSS）の台頭がもたらした複雑性の増大、そしてそれに対するプラットフォームエンジニアリングの解決アプローチを詳細に論じています。
プラットフォームエンジニアリングの本質と定義
著者は、プラットフォームを「自己サービス型のAPI、ツール、サービス、知識、サポートを、魅力的な内部プロダクトとして組み合わせた基盤」と定義しています。この定義は、単なる技術的な基盤以上のものを示唆しており、プラットフォームが組織全体に提供する価値を包括的に捉えています。
他にもCNCFが公開している「CNCF Platforms White Paper」では、Platformsについて「クラウドネイティブコンピューティングのためのプラットフォームは、プラットフォームのユーザーのニーズに応じて定義・提示される統合された機能のコレクションです。幅広いアプリケーションやユースケースに対して、一般的な機能やサービスを取得・統合するための一貫した体験を確保するクロスカッティングなレイヤーです。優れたプラットフォームは、Webポータル、プロジェクトテンプレート、セルフサービスAPIなど、その機能やサービスの利用と管理に一貫したユーザー体験を提供します」と定義しています。
また、プラットフォームエンジニアリングの成熟度を評価するための「Platform Engineering Maturity Model」も公開されていますので、ぜひ参考にしてください。
[Figure 1.1]では、「Over-General Swamp」の状態を示しており、多数のアプリケーションが個別のプリミティブと直接統合され、それらの間を大量のglueコードが繋いでいる様子が描かれています。この図は、プラットフォームが存在しない状態での複雑性の増大を視覚的に表現しています。
あるプログラムで、異なるシステムやコンポーネントを連携させるために書かれる仲介的なコードのことです。このコードは、システムの本来の機能には直接関係しませんが、互換性のない部品同士をスムーズに連携させるために必要な「接着剤」のような役割を果たします。これを『グルーコード』と言います。
特に印象的なのは、著者がプラットフォームエンジニアリングを複雑性を管理しながらビジネスへのレバレッジを提供するという明確な目的を持った規律として位置づけている点です。私の経験でも、単なる技術的な基盤提供を超えて、開発者の生産性向上とビジネス価値の創出を同時に実現することが、プラットフォームエンジニアリングの成功の鍵となっています。
現代のソフトウェア開発における「Over-General Swamp」の問題
[Figure 1.2]は、プラットフォームエンジニアリングによる解決後の状態を示しています。この図では、プラットフォームが複数のプリミティブを抽象化し、アプリケーションとの間にクリーンなインターフェースを提供している様子が描かれています。glueコードが大幅に削減され、システム全体の見通しが改善されていることが分かります。
著者は現代のソフトウェア開発環境を「Over-General Swamp（過度に一般化された沼）」と表現し、この比喩を通じて複雑性の罠を見事に描き出しています。クラウドとOSSの普及により、開発者は豊富な選択肢を手に入れましたが、それは同時に「接着剤（glue）」と呼ばれる統合コードやカスタム自動化の増加をもたらしました。
プラットフォームエンジニアリングによる解決アプローチ
著者が提示するプラットフォームエンジニアリングの解決策は、製品としてのアプローチを重視しています。これは、ユーザー中心の視点を持ちながら、機能の取捨選択を慎重に行い、全体としての一貫性と使いやすさを追求することを意味します。Appleの製品開発アプローチを例に挙げながら、著者は機能の追加だけでなく、むしろ何を含めないかの判断の重要性を強調しています。
技術的な側面では、プラットフォームエンジニアリングは複雑性を管理可能なレベルに抑えることを目指します。例えば、インフラストラクチャの分野では、Terraformの例を用いて、個々のチームが独自にインフラストラクチャを管理する場合の問題点と、プラットフォームによる抽象化がもたらす利点が説明されています。
プラットフォームチームの役割とイノベーション
著者は、プラットフォームチームの役割について、従来のインフラストラクチャ、DevTools、DevOps、SREの各アプローチとの違いを明確に示しています。これらの従来のアプローチは、それぞれの専門分野に特化していますが、プラットフォームエンジニアリングはこれらの境界を越えて、より包括的な価値を提供することを目指します。
特筆すべきは、著者がイノベーションとプラットフォームの関係について、現実的な見解を示している点です。プラットフォームは既存の技術スタック内でのビジネスイノベーションを促進する一方で、プラットフォームの範囲を超えた革新的な取り組みも必要だと認めています。例えば、データ領域での新しい技術の採用など、プラットフォームの制約を一時的に超えることが必要な場合もあると指摘しています。
章全体からの学び
第1章は、プラットフォームエンジニアリングが現代のソフトウェア開発組織にとって不可欠な理由を説得力のある形で提示しています。複雑性の増大、運用負荷の増加、イノベーションの必要性といった課題に対して、プラットフォームエンジニアリングは包括的な解決策を提供します。
著者は、プラットフォームエンジニアリングが単なる技術的な取り組みではなく、組織全体の成功に関わる戦略的な施策であることを強調しています。これは、私の実務経験とも強く共鳴する見解です。プラットフォームエンジニアリングの成功には、技術的な卓越性だけでなく、組織的な変革とイノベーションのバランスを取ることが求められます。
今後のソフトウェア開発組織にとって、プラットフォームエンジニアリングの導入は避けて通れない課題となるでしょう。本章は、その理由と意義を深く理解するための優れた導入を提供しています。特に、プラットフォームエンジニアリングが組織にもたらす具体的な価値と、その実現に向けた実践的なアプローチについての示唆は、多くの組織にとって有用な指針となるはずです。
特に注目すべきは、プラットフォームを「製品」として扱うアプローチや、ステークホルダーマネジメントの重要性など、技術面だけでなく組織的な側面にも焦点を当てている点です。これらの知見は、プラットフォームエンジニアリングの実践において大きな価値をもたらすと考えられます。
プラットフォームエンジニアリングリーダーとして、本書から学んだ知識を自身のチームや組織に適用し、より効果的なプラットフォーム戦略を構築していくことが重要です。また、本書が提起する課題や解決策について、同僚や業界のピアとのディスカッションを通じて、さらなる洞察を得ることができるでしょう。このような実践と対話を通じて、プラットフォームエンジニアリングの分野がさらに発展していくことが期待されます。
「翻訳記事 -「インフラ基盤部門は本当に必要か」に関する議論」なんかもとても良い記事なので読んでほしいです。
Chapter 2. The Pillars of Platform Engineering
第2章「The Pillars of Platform Engineering」は、プラットフォームエンジニアリングの4つの重要な柱について詳細に解説しています。著者は、Product（製品としてのアプローチ）、Development（ソフトウェアベースの抽象化）、Breadth（幅広い開発者への対応）、Operations（基盤としての運用）という4つの柱を通じて、効果的なプラットフォームエンジニアリングの実践方法を示しています。これらの柱は相互に補完し合い、成功するプラットフォームエンジニアリングの基礎を形成しています。
キュレートされた製品アプローチの重要性
プラットフォームエンジニアリングにおける最初の柱は、キュレートされた製品アプローチです。このアプローチは、単なる技術的な実装を超えて、ユーザーのニーズを中心に据えた戦略的な製品開発を意味します。著者は、これを「paved paths（舗装された道）」と「railways（鉄道）」という2つの異なるタイプのプラットフォーム製品として説明しています。
Paved Pathsは、複数のオファリングを統合した使いやすいワークフローを提供し、アプリケーションチームから複雑性を隠蔽しながら、パレート原理に基づいて20%のユースケースで80%のニーズをカバーすることを目指す標準的なアプローチを提供します。
[Figure 2.1]は「paved path」の概念を視覚的に表現しており、複数のオファリングを使いやすいワークフローとして統合し、アプリケーションチームから複雑性を隠蔽する方法を示しています。これは共通のニーズに対応するための標準的なアプローチを提供することを目的としており、著者が提唱する製品としてのプラットフォームの本質を端的に表現しています。
Railwaysは、既存製品では対応できない特定ニーズに応え、組織全体に特定の機能を提供するための重要なインフラストラクチャ投資を伴い、プロトタイプから進化してスケーラブルなソリューションを提供する新しい形態のプラットフォームです。
[Figure 2.2]は「railway」型プラットフォームを示しており、既存の製品では対応できない特定のニーズに応える新しい形態のプラットフォームを表現しています。具体例として、バッチジョブプラットフォーム、通知システム、グローバルアプリケーション設定プラットフォーム、データ処理パイプライン、監視・モニタリングプラットフォームなどが挙げられます。
プラットフォームを製品として捉えることは、単なる技術的な選択以上の意味を持ちます。ユーザー中心のデザインを通じて一貫性のある使いやすいインターフェースを提供し、明確なドキュメンテーションと効果的なオンボーディング体験を実現することが重要です。また、必要な機能の追加と不要機能の大胆な削除を行いながら、機能の優先順位付けを適切に管理し、継続的な改善サイクルを通じてユーザーフィードバックを収集・分析し、パフォーマンス指標の測定と定期的な機能の見直しを行うことが求められます。
ソフトウェアベースの抽象化の実現
著者は、「ソフトウェアを構築していないなら、それはプラットフォームエンジニアリングではない」と明確に述べています。この主張は、プラットフォームエンジニアリングの本質を理解する上で極めて重要です。効果的な抽象化を実現するためには、適切な粒度での機能分割、一貫性のあるインターフェース、バージョニング戦略、エラーハンドリングなどのAPI設計の原則に加えて、スケーラビリティ、パフォーマンス、セキュリティ、監視可能性などの実装上の考慮事項も重要となります。
幅広い開発者ベースへのサービス提供
プラットフォームの対象は幅広い開発者ベースであり、セルフサービス機能、ユーザー観測性、ガードレール、マルチテナンシーが重要な要素となります。これらは直感的なユーザーインターフェースとAPI駆動の自動化による効率的なワークフロー、詳細なログ記録とパフォーマンスメトリクス、セキュリティ制御とリソース制限、そしてリソースの分離とアクセス制御を実現します。
GenerativeAIの影響と展望
著者は、GenerativeAIがプラットフォームエンジニアリングに与える影響について、MLOpsの進化、ツールチェーンの整備、インフラストラクチャの効率化、データガバナンス、LLMエコシステムの観点から包括的な分析を提供しています。これには、モデル開発ライフサイクル管理とデプロイメント自動化、研究者向けインターフェースと非技術者向け操作性、コンピュートリソースとストレージの最適化、プライバシー保護とコンプライアンス対応、そしてモデル選択と統合が含まれます。
基盤としての運用
プラットフォームが組織の基盤として機能するためには、プラットフォームへの責任、プラットフォームのサポート、運用規律という3つの要素が不可欠です。これらは、エンドツーエンドの管理と問題解決の主導、ユーザーサポート体制とドキュメンテーションの充実、そして標準化されたプロセスと品質管理を通じて実現されます。
章全体からの学び
第2章は、プラットフォームエンジニアリングの4つの柱を通じて、成功するプラットフォームの要件を明確に示しています。技術的な卓越性、組織的な変革、イノベーション、継続的な進化が、プラットフォームエンジニアリングの成功には不可欠です。これらは最新技術の適用とパフォーマンスの最適化、チーム構造の最適化とスキル開発、新技術の評価と導入、そしてフィードバックの収集と反映を通じて実現されます。これらの要素は相互に関連し、バランスの取れた実装が必要となります。プラットフォームエンジニアリングは継続的な取り組みであり、技術的な側面だけでなく、組織的な支援と文化の醸成を通じて常に進化し続ける必要があります。
Part II. Platform Engineering Practices
第2部は、C.S.Lewisの「卵が鳥になるのは難しいかもしれないが、卵のままで飛ぶ方がよほど難しい」という言葉から始まり、プラットフォームエンジニアリングの実践的な側面に焦点を当てています。著者は8つの主要な失敗パターンを特定し、それぞれに対する具体的な解決策を提示しています。
特に重要なのは、プラットフォームエンジニアリングが単なるインフラストラクチャエンジニアリングやDevOpsの再ブランディングではないという指摘です。私のチームでも、適切なタイミングでの開始、適切な人材ミックス、製品思考の導入、効果的な運用という要素が、成功への重要な要因となっています。
Chapter 3. How and When to Get Started
第3章「How and When to Get Started」は、プラットフォームエンジニアリングの導入時期と方法について、組織の成熟度や規模に応じた具体的なアプローチを提供しています。著者は、三つの主要な状況に焦点を当て、各シナリオにおける成功への道筋を示しています。
小規模組織でのプラットフォーム協力の育成
著者は小規模スタートアップにおけるプラットフォームエンジニアリングのアプローチを、成熟度モデルを用いて説明しています。特に注目すべきは、アドホック段階とやや管理された段階という2つのフェーズの定義です。この文脈で参考になるのが、CNCF Platform Engineering Maturity Modelです。このフレームワークは、組織の成熟度を評価し、次のステップを計画する際の指針となります。
アドホック段階では、シンプルな自動化と基本的なプロセスの確立に焦点を当てることが推奨されています。著者は、この段階で重要なのはソースコントロール、自動化された継続的デプロイメント、そして軽量なプロセスの3つの要素だと強調しています。これは私の経験とも一致しており、特に小規模チームにおいては、過度に複雑なプロセスや高度な技術スタックを避け、シンプルさを保つことが重要です。
やや管理された段階では、チームの成長に伴い、より構造化されたアプローチが必要となります。著者はローカル開発環境の自動化、ステージング環境の整備、観測可能性の向上などの要素を重視しています。この段階での重要な洞察は、技術選択の社会化と意思決定プロセスの確立の必要性です。
協力を代替するプラットフォームチームの創設
組織の成長に伴い、アドホックな協力体制から正式なプラットフォームチームへの移行が必要となります。著者は、この移行のタイミングとしてダンバー数（50-250人）を参考指標として挙げています。これは、組織内の協力関係が自然に維持できる限界を示す重要な指標です。この移行のプロセスについては、DevOps Topologiesが有用な参考資料となります。
著者は、プラットフォームチームの設立において、所有権の中央集権化がもたらす利点とコストのバランスを慎重に検討する必要性を強調しています。特に注目すべきは、新しい技術やアーキテクチャではなく、問題解決に焦点を当てるという原則です。これは、プラットフォームチームが陥りがちな、技術的な理想主義による過度な複雑化を避けるための重要な指針となります。
伝統的なインフラストラクチャ組織の変革
既存のインフラストラクチャ組織をプラットフォームエンジニアリング組織へと変革する過程について、著者は包括的なガイダンスを提供しています。特に重要なのは、エンジニアリング文化全体の変革の必要性です。従来のコスト管理やベンダー交渉中心の文化から、ユーザー中心の製品開発文化への転換が求められます。この変革プロセスを支援するフレームワークとして、Thoughtworks Technology Radarが有用です。
特に重要なのは、エンジニアリング文化全体の変革の必要性です。従来のコスト管理やベンダー交渉中心の文化から、ユーザー中心の製品開発文化への転換が求められます。 本を紹介します。伝統的な組織からプロダクト中心の組織への移行について詳しく解説しています。
変革のプロセスにおいて、著者は段階的なアプローチの重要性を強調しています。最も有望な領域から始め、成功事例を積み重ねていくことで、組織全体の変革を推進することが推奨されています。また、プロダクトマネージャーの役割についても現実的な視点が示されており、単にプロダクトマネージャーを採用するだけでは不十分で、エンジニアリングチームの協力が不可欠であることが指摘されています。
章全体からの学び
第3章は、プラットフォームエンジニアリングの導入と発展に関する実践的なガイドを提供しています。とりわけ重要なのは、組織の規模や成熟度に応じて適切なアプローチを選択する必要性です。私自身も組織のプラットフォームエンジニアリングを主導している立場から、小規模スタートアップでは軽量なプロセスと基本的な自動化から始め、成長に伴って段階的に発展させていく著者の提案に強く共感します。
特に印象的なのは、著者がプラットフォームエンジニアリングを単なる技術的な取り組みではなく、組織文化の変革として捉えている点です。これは私の実務経験とも一致しており、多くの組織が陥りがちな技術偏重のアプローチを避けるための重要な示唆となっています。例えば、私のチームでは新しい技術の導入よりも、まず既存の問題解決と開発者体験の向上に焦点を当てることで、より持続可能な変革を実現できています。
また、チーム編成に関する著者の洞察も非常に実践的です。特に、大企業出身のエンジニアの採用に関する警告は、私自身の経験からも非常に的確だと感じています。優れた技術力を持っていても、規模の異なる組織での経験をそのまま適用しようとする傾向は、しばしば新たな問題を引き起こす原因となりうるからです。
この章の知見は、今後のプラットフォームエンジニアリングの実践において重要な指針となるでしょう。組織の成熟度に応じた段階的なアプローチ、ユーザー中心の文化醸成、そして適切なチーム構築は、成功への鍵となる要素です。私たちプラットフォームエンジニアリングリーダーは、これらの知見を活かしながら、各組織の状況に適した変革を推進していく必要があります。
Chapter 4. Building Great Platform Teams
第4章「Building Great Platform Teams」は、プラットフォームエンジニアリングチームの構築と育成に焦点を当てています。この章では、効果的なプラットフォームチームの構築に必要な多様な役割と、それらの役割間のバランスの取り方について、実践的な知見が提供されています。特に、ソフトウェアエンジニアとシステムエンジニアの異なる視点をどのように融合させ、顧客中心のプラットフォームを構築するかという課題に深く切り込んでいます。
シングルフォーカスチームの課題
単一の視点に偏ったチーム構成は、長期的に見て大きな課題を生み出します。システムエンジニアに偏重したチームは運用面では優れているものの、プラットフォームの抽象化や設計面で課題を抱えがちです。一方、ソフトウェアエンジニアに偏重したチームは新機能の開発には長けていますが、運用安定性や既存システムの改善に対する意識が低くなりがちです。
私の経験からも、この両極端な状況を目にすることが多々あります。過去のプロジェクトでは、システムエンジニアの視点が強すぎるあまり、新機能開発に対して過度に慎重になり、結果として顧客ニーズへの対応が遅れるという課題がありました。一方で、開発速度を重視するあまり、運用の視点が欠如し、本番環境での深刻な問題を引き起こすケースも見てきました。
[Figure 4-1]で示されているように、プラットフォームエンジニアリングチームにおける主要なエンジニアリング役割の分類は、このバランスの重要性を明確に表しています。
プラットフォームエンジニアの多様な役割
プラットフォームエンジニアリングチームにおける主要な役割について、著者は4つの異なる専門性を持つエンジニアの重要性を強調しています。Software Engineerはソフトウェア開発に特化しながらもシステムへの深い理解と運用への関心を持ち、ビジネスクリティカルなシステムのオンコール対応ができ、慎重なペースでの開発に納得できる人材です。Systems EngineerはDevOpsエンジニアやSREに近い立場ながら、より広範な視点を持ち、インフラストラクチャの統合からプラットフォームのコードベースに関わる深いシステムの問題解決まで、幅広い業務を担当します。Reliability Engineerは信頼性に特化し、インシデント管理、SLOのコンサルティング、カオスエンジニアリング、ゲームデイの実施など、システム全体の信頼性向上に注力します。そしてSystems Specialistは、ネットワーキング、カーネル、パフォーマンス、ストレージなど、特定の技術領域に深い専門性を持つエンジニアですが、著者はこの役割については組織の規模と必要性が明確になってから採用することを推奨しています。
特に印象的なのは、各役割の採用と評価についての具体的なアドバイスです。例えば、システムエンジニアの採用において、コーディング面接の柔軟な運用を提案しています。私のチームでもこのアプローチを採用し、結果として運用経験が豊富で、かつ適度なコーディングスキルを持つエンジニアの採用に成功しています。また、クラウドネイティブプラットフォームの構築において、これら4つの役割が相互に補完し合い、それぞれの専門性を活かしながら協働することで、より堅牢なプラットフォームの実現が可能になることを日々の実務で実感しています。
プラットフォームエンジニアリングマネージャーの重要性
プラットフォームエンジニアリングマネージャーには、プラットフォームの運用経験、長期プロジェクトの経験、そして細部への注意力が不可欠です。私の経験上、特に運用経験の重要性は強調してもしすぎることはありません。複雑なシステムの運用経験がないマネージャーが、技術的な課題の深刻さを過小評価し、結果として重大なサービス障害を引き起こすケースを何度も目にしてきました。
チーム文化の構築と維持
チーム文化の構築は、技術的な課題と同じくらい重要です。著者が示す開発チームとSREチームの統合事例は、私自身のチーム統合経験とも共鳴する部分が多くあります。特に、異なる文化を持つチームを統合する際の段階的なアプローチは、非常に実践的です。
私のチームでは、定期的な技術共有セッションとクロスファンクショナルなプロジェクト編成を通じて、異なる背景を持つエンジニア間の相互理解を促進しています。これにより、「システムチーム」vs「開発チーム」という対立構造を避け、より協調的な文化を醸成することができています。
章全体からの学び
プラットフォームエンジニアリングチームの成功には、技術的なスキルと組織文化の両面でのバランスが不可欠です。著者の提案する4つの役割分類と、それぞれの役割に対する適切な評価・育成方法は、実践的で価値のある指針となっています。
特に重要なのは顧客エンパシーです。これは単なるスキルではなく、チーム全体の文化として根付かせる必要があります。プラットフォームエンジニアリングチームが提供する価値は、単なる技術的な解決策ではなく、顧客の課題を深く理解し、それに対する適切な解決策を提供することにあるからです。
今後のプラットフォームエンジニアリングには、技術の進化に加えて、組織のデジタルトランスフォーメーションへの対応も求められます。この章で学んだチーム構築の原則は、そうした変化に対応する上で重要な指針となるでしょう。個人的な経験からも、技術と人、そして文化のバランスを取ることが、持続可能なプラットフォーム組織の構築には不可欠だと確信しています。
Chapter 5. Platform as a Product
第5章「Platform as a Product」は、プラットフォームエンジニアリングにおいて、プラットフォームを製品として捉えるアプローチの重要性と実践方法について深く掘り下げています。著者は、組織内プラットフォームの構築において、プロダクト思考を採用することの意義と、その実現に向けた具体的な戦略を提示しています。
顧客中心のプロダクトカルチャーの確立
著者は、内部顧客の特性として、小規模な顧客基盤、囚われの観客、利害の対立、顧客満足度の変動、そして時として競合者となり得る顧客の存在を挙げています。私の経験でも、特に囚われの観客という特性は重要で、単にプラットフォームの使用を強制するのではなく、真に価値のある製品として受け入れられる必要があります。
著者が提唱する「顧客エンパシー」の文化は、面接プロセスからの組み込み、顧客中心の目標設定、ユーザーフィードバックの定期的な収集など、具体的な施策を通じて醸成されます。私のチームでも、エンジニアのサポート輪番制を導入し、顧客の課題を直接理解する機会を設けることで、より顧客志向の製品開発が実現できています。
プロダクトディスカバリーとマーケット分析
新しいプラットフォーム製品の発見と検証について、著者は他チームが構築した成功事例を基に広範な用途に適用可能な製品として発展させること、特定のチームと協力して具体的な課題解決から始めて一般化可能な製品を作り出すこと、そして導入障壁が低く明確な価値提案を持つ製品から着手することという三つのアプローチを提示しています。
プロダクトロードマップの重要性
著者は、プロダクトロードマップの構築において、プラットフォームが目指す理想的な状態を示す長期的なビジョン、ビジョン実現のための具体的なアプローチを示す中期的な戦略、定量的な成功指標となる年間目標とメトリクス、そして具体的な実装計画となる四半期ごとのマイルストーンという段階的なアプローチを提案しています。
この考え方は、「プロダクトマネージャーのしごと 第２版」でも強調されており、同書ではプロダクトマネージャーの重要な役割として、ビジョンとロードマップの策定、顧客ニーズの深い理解、データ駆動の意思決定、そしてステークホルダーとの効果的なコミュニケーションを挙げています。特に、プロダクトロードマップは単なる実装計画ではなく、製品の戦略的な方向性を示す重要なツールとして位置づけられています。
失敗のパターンと対策
著者は主要な失敗パターンとして、移行コストの過小評価、ユーザーの変更予算の過大評価、安定性が低い状況での新機能価値の過大評価、そしてエンジニアリングチームの規模に対する製品マネージャーの過剰な配置を指摘しています。私の経験からも、特に移行コストの過小評価は深刻な問題となりがちで、新機能の魅力に目を奪われ、既存システムからの移行に伴う実務的な課題を軽視してしまうケースを何度も目にしてきました。
章全体からの学び
プラットフォームを製品として扱うアプローチの成功には、文化、製品市場適合性、実行の3つの要素が不可欠です。著者が強調するように、単なる技術的な優位性ではなく、顧客価値の創出と組織全体への影響を考慮した包括的なアプローチが求められます。プラットフォームエンジニアリングリーダーとして、この章から学んだ最も重要な教訓は、技術的な卓越性と顧客価値のバランスを取ることの重要性です。プラットフォームは技術的に優れているだけでなく、実際のユーザーにとって価値のある、使いやすい製品でなければなりません。また、私はプロダクトマネジメントについて学んできてなかったので主張としてなんとなくしか理解できない事柄もいくつかあった。
Chapter 6. Operating Platforms
第6章「Operating Platforms」は、プラットフォームエンジニアリングにおける運用の本質と、その実践的なアプローチについて深く掘り下げています。この章では、プラットフォームの運用が単なる技術的な課題ではなく、組織全体の成功に直結する戦略的な要素であることを強調しています。著者は、「レアなことは規模が大きくなると一般的になる」という Jason Cohen の言葉を引用しながら、プラットフォームの規模拡大に伴う運用上の課題とその対処方法について詳細に論じています。
オンコール体制の重要性と実践
著者は、オンコール体制について非常に現実的な視点を提供しています。特に印象的だったのは、24x7のオンコール体制の必要性についての議論です。私自身、過去に「重要ではない」と思われる開発者ツールのプラットフォームでさえ、予想外のタイミングで重要になる経験をしてきました。例えば、深夜のクリティカルなバグ修正時にデプロイメントプラットフォームが機能しないという状況は、まさに著者が指摘する通りの事例です。
著者が提案する「週に5件以下のビジネスインパクトのある問題」という基準は、理想的ではありますが、現実的な目標として受け入れられます。これは私の経験とも一致しており、このレベルを超えると組織の持続可能性が急速に低下することを実感してきました。特に、この数字を超えると、チームのバーンアウトや離職率の上昇といった深刻な問題につながることを、実際のプロジェクトで何度も目の当たりにしてきました。
また、マージされたDevOpsアプローチの重要性について、著者は説得力のある議論を展開しています。プラットフォームチームの規模が限られている場合、開発とオペレーションを分離することは現実的ではないという指摘は、多くの組織にとって重要な示唆となります。私の経験では、小規模なプラットフォームチームでDevとOpsを分離しようとした結果、コミュニケーションの断絶や責任の所在の不明確化といった問題が発生したケースを数多く見てきました。
サポート実践の段階的アプローチ
サポート体制については、著者が提案する4段階のアプローチが非常に実践的です。特に、サポートレベルの形式化から始まり、最終的にはエンジニアリングサポート組織（ESO）の確立に至るまでの発展プロセスは、多くの組織が参考にできるモデルとなっています。
第1段階のサポートレベルの形式化では、支援要請の分類と対応の優先順位付けが重要です。私のチームでも、この分類作業を通じて、実際には多くの問題が共通のパターンを持っていることが分かり、効率的な対応方法を確立することができました。
第2段階のクリティカルでないサポートのオンコールからの分離は、チームの持続可能性を確保する上で重要なステップです。私の経験では、この分離を実施することで、開発者が本来の開発業務に集中できる時間が増え、結果としてプラットフォームの品質向上にもつながりました。
第3段階のサポートスペシャリストの採用については、著者が指摘する「ユニコーン」の必要性に強く共感します。T1とT2の両方をこなせる人材を見つけることは確かに難しいですが、非伝統的な背景を持つ人材の育成という提案は、現実的かつ効果的なアプローチだと考えています。
最後の第4段階である大規模なエンジニアリングサポート組織の確立については、著者が提供するFAANG企業での実例が非常に参考になります。特に、アプリケーションの階層化とそれに応じたSLAの設定、顧客のオンコール要件、システムエンジニアの採用といった具体的な施策は、大規模組織での運用の複雑さと、その解決策を理解する上で重要な示唆を提供しています。
運用フィードバックの実践
運用フィードバックの実践については、著者がSLO、SLA、エラーバジェットについて興味深い見解を示しています。特に、エラーバジェットが必ずしも万能な解決策ではないという指摘は、現実の組織運営において非常に重要な視点です。私の経験では、エラーバジェットの導入が却ってチーム間の対立を生む結果となったケースもありました。
著者が提案する合成モニタリングの重要性は、現代のプラットフォーム運用において極めて重要です。開発時間の25%、リソースコストの10%という投資推奨は、一見高額に感じるかもしれませんが、問題の早期発見と対応によって得られる価値を考えると、十分に正当化できる投資だと考えています。私のチームでも、合成モニタリングの導入により、ユーザーからの報告前に問題を検知し、対応できるケースが大幅に増加しました。
変更管理の現実的アプローチ
変更管理に関する著者の見解は、現代のDevOps実践との関連で特に興味深いものでした。完全な自動化を目指しつつも、その過程での適切な変更管理の重要性を説いている点は、多くのプラットフォームチームにとって重要な示唆となります。
著者が指摘する通り、プラットフォームの変更は複雑で状態を持つことが多く、単純なCI/CDの適用が難しい場合が多いです。私の経験でも、キャッシュクリアやデータベースマイグレーションなど、慎重な制御が必要な操作が多く存在し、これらの管理には明確なプロセスと慎重なアプローチが必要でした。
運用レビューの実践
運用レビューについての議論は、特にリーダーシップの観点から重要です。チームレベルでのシンプルかつ厳格なレビュー、そして組織レベルでの本質的なレビューの必要性は、プラットフォーム運用の成功に不可欠な要素として描かれています。
私の経験では、週次の運用レビューを通じて、潜在的な問題を早期に発見し、対応することができました。特に、ページング頻度、サポートチケットの傾向、インシデントの根本原因分析などを定期的にレビューすることで、システムの健全性を維持し、改善の機会を見出すことができました。
また、著者が強調するリーダーシップの関与の重要性は、非常に重要な指摘です。運用レビューに経営層が積極的に参加することで、運用上の課題が適切に理解され、必要なリソースの確保や優先順位付けがスムーズに行われるようになった経験があります。
章全体からの学び
この章は、プラットフォーム運用の複雑さと、それを成功に導くための実践的なアプローチを包括的に示しています。特に、運用の規律がプラットフォームの成功にとって不可欠であることを強調している点は、現代のソフトウェア開発環境において極めて重要な示唆となっています。
読者として強く感じたのは、プラットフォーム運用が単なる技術的な課題ではなく、組織的な取り組みとして捉える必要があるという点です。特に、チームの持続可能性とユーザー満足度の両立という観点から、著者の提案する実践的なアプローチは非常に価値があります。
この章で提示されている運用プラクティスは、理想的ではありますが現実的な目標として設定されており、段階的な改善のためのロードマップとしても機能します。私自身、これらのプラクティスの多くを実践してきましたが、特に重要なのは、組織の規模や成熟度に応じて適切なアプローチを選択し、継続的に改善を進めていく姿勢だと考えています。
最後に、この章の内容は、プラットフォームエンジニアリングリーダーが直面する現実的な課題と、その解決のための具体的なアプローチを提供しており、現代のソフトウェア開発組織にとって重要な指針となっています。特に、運用の持続可能性とビジネス価値の創出のバランスを取りながら、組織を成長させていくための実践的な知見は、非常に価値のあるものだと言えます。
Chapter 7. Planning and Delivery
第7章「Planning and Delivery」は、プラットフォームエンジニアリングにおける計画立案と実行の重要性について深く掘り下げています。この章では、長期的なプロジェクトの計画から日々の実行管理、そして成果の可視化に至るまで、プラットフォームチームのリーダーが直面する実践的な課題と、その解決のためのアプローチについて詳細に解説しています。
長期プロジェクトの計画立案
プラットフォームエンジニアリングの特徴的な側面の一つは、長期的なプロジェクトの存在です。私の経験でも、新しいインフラストラクチャの構築や大規模なマイグレーションプロジェクトは、しばしば数ヶ月から数年の期間を要します。著者が提案するプロポーザルドキュメントの作成から実行計画への移行というアプローチは、このような長期プロジェクトを成功に導くための実践的な方法論として非常に重要です。
特に印象的だったのは、プロジェクトの目的と要件をプロポーザルドキュメントで明確化する部分です。私自身、過去に大規模なマイグレーションプロジェクトをリードした際、初期段階でのプロポーザルドキュメントの重要性を痛感しました。背景、テネット、ガイドライン、問題の詳細、解決策の概要、実行計画という構造化されたアプローチは、関係者間の合意形成と期待値の調整に非常に効果的でした。
ボトムアップなロードマップ計画
著者が提案するボトムアップなロードマップ計画は、プラットフォームチームが直面する現実的な課題に対する実践的な解決策を提供しています。特に、KTLO（Keep the Lights On）作業、マンデート、システム改善という3つの主要な作業カテゴリの区分は、リソース配分と優先順位付けの明確な枠組みを提供します。
私のチームでも、KTLOワークの見積もりから始めて、段階的にプランニングの精度を上げていく手法を採用しています。特に、全体の40%をKTLOに、残りを70/20/10の比率で新機能開発、アーキテクチャ改善、イノベーションに配分するというガイドラインは、バランスの取れたリソース配分の指針として有用でした。
隔週での成果と課題の共有
著者が提案する「Wins and Challenges」という取り組みは、プラットフォームチームの成果を可視化し、組織全体との信頼関係を構築するための効果的な方法です。私のチームでも、この手法を導入してから、ステークホルダーとのコミュニケーションが大幅に改善されました。
特に重要なのは、チャレンジを適切に共有することの価値です。私の経験では、問題を隠すのではなく、適切に共有し、解決に向けた支援を得られる関係性を構築することが、長期的な信頼関係の構築に不可欠でした。
このような定期的な成果共有の重要性は、「SREsのためのSRE定着ガイド」でも定点観測会として紹介されており、インフラストラクチャーの価値を他のチームに継続的に伝えていく機会として非常に有効です。
プロジェクト管理の実践的アプローチ
著者が警告する「長期的な停滞」に陥るリスクは、多くのプラットフォームチームにとって現実的な課題です。私も過去に、過度に野心的な目標設定や不明確な問題設定により、プロジェクトが停滞する経験をしました。これを避けるために、プロジェクトの範囲を適切に設定し、段階的な価値提供を重視するアプローチを採用しています。
章全体からの学び
この章で提示されている計画立案と実行管理のフレームワークは、プラットフォームエンジニアリングの成功に不可欠な要素を網羅しています。特に、長期的なビジョンと短期的な成果のバランス、透明性の高いコミュニケーション、そして継続的な価値提供の重要性は、現代のプラットフォームエンジニアリングにおいて極めて重要です。
私の経験からも、これらの実践は組織の規模や成熟度に関わらず、適用可能で効果的なアプローチだと確信しています。ただし、各組織の状況に応じて適切にカスタマイズすることが重要です。特に、チームの規模が小さい段階では、過度に形式的なプロセスを避け、エッセンシャルな実践に焦点を当てることを推奨します。
この章の内容は、プラットフォームエンジニアリングチームが直面する計画立案と実行管理の課題に対する実践的なガイドとして、非常に価値のあるものだと評価しています。
Chapter 8. Rearchitecting Platforms
第8章「Rearchitecting Platforms」は、プラットフォームの再アーキテクチャリングという重要なテーマについて、その必要性、アプローチ、実践方法を包括的に解説しています。著者は、プラットフォームの進化が不可避であるという現実を踏まえ、どのようにして既存のシステムを運用しながら進化させていくかという実践的な知見を提供しています。
特に印象的なのは、冒頭のRandy Schoupによる「If you don't end up regretting your early technology decisions, you probably overengineered.」（初期の技術選定を後悔しないのであれば、おそらく過剰設計だった）という引用です。この言葉は、プラットフォームエンジニアリングにおける現実的なアプローチの重要性を端的に表現しています。
また、日本の伊勢神宮で実践される式年遷宮のように、定期的にシステムを刷新しながら価値を維持・向上させていく「式年遷宮アーキテクチャ」の考え方も、この文脈で参考になる概念といえます。
v2開発とリアーキテクチャリングの選択
[Figure 8-1]は、プラットフォームの進化とリアーキテクチャリングの関係を時系列で示した重要な図です。この図は、プラットフォームが「Scrappy Platform」から「Scalable Platform」を経て「Robust Platform」へと進化していく過程を表しています。著者は、新システムを一から作り直すv2アプローチと、既存システムを進化させるリアーキテクチャリングアプローチを比較し、後者を推奨しています。私自身の経験からも、v2アプローチの失敗を何度も目にしてきました。特に印象的だったのは、セカンドシステム効果による過剰な機能の盛り込みと、移行コストの過小評価という2つの典型的な失敗パターンです。
たとえば、あるプロジェクトでは、既存システムの問題点を全て解決しようとするあまり、新システムの設計が複雑化し、開発期間が当初の見積もりの3倍以上に膨れ上がってしまいました。結果として、ビジネスニーズの変化に追いつけず、プロジェクトは中止を余儀なくされました。
著者が提案する3つの異なるエンジニアリングマインドセット（パイオニア、セトラー、タウンプランナー）の分類は、非常に示唆に富んでいます。私のチームでも、このフレームワークを参考に、フェーズに応じた適切な人材配置を行うことで、より効果的なリアーキテクチャリングを実現できています。
パイオニアマインドセットは、新しい可能性を探索し、革新的なソリューションを生み出すのに長けています。一方で、セトラーマインドセットは、実験的なアイデアを実用的なプロダクトへと昇華させる能力に優れています。そして、タウンプランナーマインドセットは、システムの効率化と産業化を得意としています。
セキュリティアーキテクチャの重要性
特に注目すべきは、セキュリティをアーキテクチャレベルで考える必要性についての指摘です。著者は、プラットフォームのセキュリティは後付けではなく、設計段階から組み込まれるべきだと主張しています。これは、私が過去に経験した大規模なセキュリティインシデントからも、極めて重要な教訓だと感じています。
例えば、あるプロジェクトでは、セキュリティを後付けで考えたために、重要なアーキテクチャ上の変更が必要となり、多大なコストと時間を要しました。特に、マルチテナント環境におけるデータの分離や、認証・認可の仕組みは、後からの変更が極めて困難でした。
「サイバー犯罪を完全に防ぐことはできないが、システムをよりスマートに設計することで被害を最小限に抑えることは可能」という著者の指摘は、現代のセキュリティアプローチの本質を突いています。特に重要なのは、以下の実践的なアプローチです：
- 標準化された認証・認可の仕組みの提供
- セキュアなデフォルト設定の重要性
- アクセス制御の宣言的な定義
- テナント分離アーキテクチャの採用
ガードレールの設計と実装
リアーキテクチャリングの実践において、著者はガードレールの重要性を強調しています。これは、変更を安全に実施するための枠組みとして機能します。特に、以下の4つの側面からのアプローチが重要です：
- 後方互換性の維持: APIの互換性を保ち、既存のクライアントへの影響を最小限に抑える
- 包括的なテスト戦略: 単体テストから統合テスト、合成モニタリングまでの総合的なアプローチ
- 環境管理の重要性: 開発、テスト、本番環境の適切な分離と管理
- 段階的なロールアウト: カナリアリリースやトランチ方式による慎重なデプロイメント
私の経験では、特に後方互換性の維持が重要です。一度失った顧客の信頼を取り戻すのは極めて困難であり、互換性の破壊は避けるべき最大のリスクの一つです。たとえば、あるプロジェクトでは、APIの下位互換性を破壊する変更を行ったことで、顧客のシステムに深刻な影響を与え、その修復に数ヶ月を要しました。
リアーキテクチャリングの計画立案
著者が提案する4段階の計画立案プロセスは、実践的で効果的なアプローチです：
- 最終目標の設定: 3-5年の長期的なビジョンを明確にする
- 移行コストの見積もり: 現実的なコストと時間の評価
- 12ヶ月での主要な成果の設定: 短期的な価値提供の確保
- リーダーシップの支持獲得: 組織的なサポートの確保
特に印象的なのは、12ヶ月での具体的な成果達成を重視している点です。私のチームでも、長期的なビジョンと短期的な成果のバランスを取ることで、ステークホルダーの信頼を維持しながら、大規模なリアーキテクチャリングを成功させることができました。
具体的には、以下のような3つの目標設定が効果的でした：
章全体からの学び
この章から学んだ最も重要な教訓は、リアーキテクチャリングは技術的な課題である以上に、組織的な取り組みであるという点です。技術的な優位性だけでなく、ビジネス価値の創出と組織の継続的な発展を両立させる必要があります。
私の経験からも、リアーキテクチャリングの成功には、技術的な卓越性、組織的な支援、そして段階的な実行アプローチが不可欠です。特に、早期の価値提供と段階的な移行を重視することで、リスクを最小限に抑えながら、必要な変革を実現することができます。
また、著者が警告する新入社員主導のリアーキテクチャリングの危険性も重要な指摘です。過去の経験や他社での成功体験に基づく性急な変更は、往々にして組織の文化や既存システムの複雑さを考慮できず、失敗に終わることが多いです。
最後に、この章は現代のプラットフォームエンジニアリングが直面する重要な課題に対する実践的なガイドを提供しており、多くのプラットフォームリーダーにとって貴重な参考資料となるでしょう。特に、継続的な進化の必要性と実践的なアプローチの重要性は、今後のプラットフォーム戦略を考える上で極めて重要な示唆を提供しています。
Chapter 9. Migrations and Sunsetting of Platforms
第9章「Migrations and Sunsetting of Platforms」は、プラットフォームエンジニアリングにおける最も困難な課題の一つである、マイグレーションとプラットフォームのサンセットについて詳細に解説しています。著者は、C. Scott Andreasの「プラットフォームは、土台のように、その上に構築するための安定した表面を提供するべきものである」という言葉を引用しながら、変更を管理しつつ安定性を提供するというプラットフォームエンジニアリングの本質的な課題に切り込んでいます。
こちらも参考になるかと思います。
マイグレーションのアンチパターン
著者が指摘するマイグレーションの主要なアンチパターンは、私の経験とも強く共鳴します。特に、コンテキストのない締め切り、曖昧な要件、不十分なテスト、そしてクリップボード持ちの説教者という4つのパターンは、多くのプラットフォームチームが陥りがちな罠です。
私自身、ある大規模なマイグレーションプロジェクトで、経営陣から突然の期限を課された経験があります。その時の教訓は、マイグレーションは技術的な課題である以上に、コミュニケーションと計画の課題であるということでした。具体的には、チームメンバーや関係者との丁寧なコミュニケーション、段階的なマイグレーション計画の策定、そして明確な成功基準の設定が重要でした。
また、曖昧な要件の問題は特に深刻です。「Product X version Y以前を使用している場合は...」といった通知を送っても、多くのユーザーはProduct Xが何を指すのかすら理解できていないことがあります。これは単なるコミュニケーションの問題ではなく、プラットフォームの可視性と理解可能性の問題でもあります。
より簡単なマイグレーションのためのエンジニアリング
著者は、マイグレーションを容易にするための技術的なアプローチとして、製品抽象化、透過的なマイグレーション、メタデータ追跡、自動化の重要性を説いています。これらは、現代のクラウドネイティブ環境において特に重要です。
私の経験では、グルーコードの最小化とバリエーションの制限が特に重要でした。あるプロジェクトでは、各チームが独自のグルーコードを持っていたために、システムの更新が極めて困難になっていました。この教訓を活かし、次のプロジェクトでは標準化されたインターフェースと限定的なカスタマイズオプションを提供することで、マイグレーションの複雑さを大幅に削減することができました。
また、使用状況メタデータの追跡も極めて重要です。過去のプロジェクトで、依存関係の把握が不十分だったために、マイグレーション中に予期せぬ問題が発生し、スケジュールが大幅に遅延した経験があります。この経験から、プラットフォームの使用状況、依存関係、所有者情報を常に追跡するシステムを構築することが、効果的なマイグレーション管理の基盤となることを学びました。
スムーズなマイグレーションの調整
マイグレーションの成功には、早期のコミュニケーションと公開性が不可欠です。著者が提案する、12ヶ月以上先の期限に対する慎重なアプローチは、私の経験からも非常に賢明です。
特に印象的なのは、最後の20%をプッシュするという考え方です。実際のプロジェクトでは、最初の80%は比較的スムーズに進むことが多いものの、残りの20%で予想外の課題に直面することがよくあります。この段階での成功には、古いシステムの適切な維持管理、予期せぬ技術的課題への柔軟な対応、そして責任の所在の明確化が重要です。
私の経験では、この最後の20%で重要なのは、チームのモチベーション維持です。古いシステムの維持に割り当てられたチームメンバーが、キャリアの行き詰まりを感じて離職するケースも少なくありません。これを防ぐために、新旧システムの作業をバランスよく配分し、全員が新しい技術にも触れる機会を提供することが重要です。
プラットフォームのサンセット
プラットフォームのサンセットは、マイグレーション以上に難しい判断を必要とします。著者は、サンセットを検討すべき状況として、ユーザー数の少なさ、高いサポートコスト、他の優先事項への注力必要性という3つの条件を挙げています。
私の経験では、特に構築者の抵抗が大きな課題となることがあります。開発者は自分たちが構築したシステムに愛着を持ちがちで、そのサンセットには強い感情的な抵抗を示すことがあります。あるプロジェクトでは, 新システムへの移行が技術的には可能であったにもかかわらず、開発チームの強い愛着により、不必要に長期間両方のシステムを維持することになりました。
このような状況を避けるためには、客観的な評価基準と透明性の高い意思決定プロセスが重要です。具体的には、使用状況メトリクス、維持コスト、技術的負債の状況など、定量的なデータに基づく判断を行うことで、感情的な議論を避けることができます。
また、サンセット計画の策定においては、段階的なアプローチが効果的です。まず使用制限を設けてから完全な廃止へと移行する方法や、特定の機能のみを段階的に廃止していく方法など、状況に応じた柔軟なアプローチを取ることが重要です。
章全体からの学び
この章から得られる最も重要な教訓は、マイグレーションとサンセットは避けられない現実であり、それらを効果的に管理することがプラットフォームチームの価値を証明する機会となるということです。
著者が述べているように、マイグレーションは「税金」のようなものかもしれませんが、それは避けられない更新のコストです。プラットフォームエンジニアリングの真価は、より良い自動化、コミュニケーション、実行を通じて、この変更のコストを組織全体で最小化できるという点にあります。
私の経験からも、成功するマイグレーションには、技術的な準備、組織的なサポート、そして効果的なコミュニケーションが不可欠です。特に重要なのは、ユーザー体験を最優先し、できる限り多くの作業を事前に準備することです。
さらに、マイグレーションやサンセットの経験は、将来のプラットフォーム設計にも活かすべき重要な学びとなります。特に、変更のしやすさを初期の設計段階から考慮することで、将来のマイグレーションコストを低減することができます。
最後に、この章は、プラットフォームエンジニアリングにおけるマイグレーションとサンセットの重要性を再認識させ、その実践的なアプローチを提供する貴重な指針となっています。その教訓は、現代のクラウドネイティブ環境において、ますます重要性を増していくことでしょう。
Chapter 10. Managing Stakeholder Relationships
第10章「Managing Stakeholder Relationships」は、プラットフォームエンジニアリングにおけるステークホルダー管理の重要性と実践的なアプローチについて詳細に解説しています。著者は、プロダクトマネジメントとステークホルダーマネジメントの違いを明確にし、後者がプラットフォームチームの成功にとって極めて重要であることを強調しています。
ステークホルダーマッピング：パワー・インタレストグリッド
[Figure 10-1]は、ステークホルダーのマッピングを「パワー」と「関心」の2軸で表現した重要な図です。この図は、ステークホルダーを4つの象限に分類し、それぞれに対する適切なアプローチを示しています。私の経験でも、このような体系的なマッピングは、限られたリソースを効果的に配分する上で非常に有用でした。
[Figure 10-2]では、架空の例としてJuanというVPのステークホルダーマップが示されています。この例は、現実のプラットフォームチームが直面する複雑なステークホルダー関係を見事に表現しています。特に重要なのは、パワーと関心の高いステークホルダー（CPOや主要エンジニアリングチームのリーダー）に対する戦略的なアプローチの必要性です。
適切な透明性でのコミュニケーション
著者は、ステークホルダーとのコミュニケーションにおいて、過度な詳細の共有を避けることの重要性を強調しています。これは、私のチームでも痛感した教訓です。以前、技術的な詳細を過度に共有したことで、かえってステークホルダーの不信感を招いた経験があります。
特に重要なのは、1:1ミーティングの戦略的な活用です。初期段階での関係構築には有効ですが、組織の成長とともにその限界も見えてきます。私の経験では、四半期ごとのKeep Satisfied/Keep Informedステークホルダーとの1:1、そして月次でのManage Closelyステークホルダーとの1:1というリズムが効果的でした。
受け入れ可能な妥協点の見出し方
ステークホルダーとの関係において、妥協は避けられない現実です。特に印象的なのは、「yes, with compromises」というアプローチです。これは、完全な拒否でも無条件の受け入れでもない、現実的な解決策を提供します。
シャドウプラットフォームの問題は、多くのプラットフォームチームが直面する課題です。私のチームでも、ある部門が独自のプラットフォームを構築し始めた際、最初は抵抗を感じました。しかし、著者が提案するように、パートナーシップのアプローチを取ることで、最終的には組織全体にとって価値のある結果を生み出すことができました。
予算管理とコストの課題
経済的な逆風時における予算管理は、プラットフォームチームにとって特に難しい課題です。著者が提案する3段階のアプローチ（明日の受益者の特定、チーム単位での作業のグループ化、カットすべき箇所と維持すべき箇所の明確化）は、実践的で効果的です。
私の経験では、ビジネスへの直接的な価値の提示が特に重要でした。例えば、効率化プロジェクトの場合、具体的なコスト削減額を示すことで、予算の正当性を説得力を持って説明することができました。
章全体からの学び
この章から得られる最も重要な教訓は、ステークホルダー管理がプラットフォームチームの成功にとって決定的に重要であるという点です。これは単なるコミュニケーションの問題ではなく、組織の戦略的な成功要因です。
私の経験からも、良好なステークホルダー関係は、困難な時期を乗り越えるための重要な資産となります。特に、予算削減や組織変更といった厳しい局面では、日頃からの信頼関係が決定的な違いを生みます。
最後に、この章が提供する実践的なフレームワークと具体例は、現代のプラットフォームエンジニアリングリーダーにとって、極めて価値のある指針となるでしょう。
Part III. What Does Success Look Like?
第3部は、プラットフォームエンジニアリングの成功をホリスティックに評価するアプローチを提示しています。Alice in Wonderlandからの引用が示唆するように、プラットフォームチームは常に走り続けているにもかかわらず、その進捗が見えにくいという現実に直面します。
著者は、単純なメトリクスやモデルだけでは不十分だとし、アライメント、信頼、複雑性管理、愛される存在という4つの評価領域を提案しています。これは私の実務経験とも強く共鳴します。特に、CNCFのプラットフォームエンジニアリング成熟度モデルを参考にしつつも、より包括的な評価アプローチを取ることの重要性は、多くのプラットフォームリーダーにとって価値のある指針となるでしょう。
Chapter 11. Your Platforms Are Aligned
第11章「Your Platforms Are Aligned」は、プラットフォームエンジニアリングチームの成功を評価する最初の基準として「アライメント（整合性）」を深く掘り下げています。この章を通じて、著者はプラットフォームチーム間のアライメントがいかに重要か、そしてミスアライメントがどのような問題を引き起こすかを具体的に示しています。特に印象的なのは、冒頭のTom DeMarcoとTim Listerの「チームの目的は目標の達成ではなく、目標の整合性である」という言葉です。この視点は、現代のプラットフォームエンジニアリングにおいて極めて重要な示唆を提供しています。
目的のアライメント
著者は目的のアライメントの重要性を、継続的インテグレーション（CI）プラットフォームと運用システムプラットフォームの対立という具体例を通じて説明しています。この事例は、私自身が経験したプラットフォームチーム間の対立を思い起こさせます。特に印象的なのは、OSプラットフォームチームがインフラストラクチャマインドセットを保持し、顧客体験よりも技術的完璧さを優先してしまうという状況です。
著者は、プラットフォームチームの共通目的として、製品（キュレートされた製品アプローチ）、開発（ソフトウェアベースの抽象化）、幅広さ（広範な開発者基盤へのサービス提供）、運用（ビジネスの基盤としての運用）という4つの柱を挙げています。これらの柱は、プラットフォームチームが技術的な卓越性だけでなく、組織全体の価値創出に貢献するための重要な指針となります。
製品戦略のアライメント
製品戦略のアライメントについて、著者は4つのプラットフォームチームが異なる技術的選択を行い、その結果として5つの異なるコンピュートプラットフォームが存在するという事例を挙げています。これは、私が以前経験した状況と非常によく似ています。チーム間の協調不足が、重複した機能と互換性の問題を引き起こし、結果として顧客にとって使いづらい環境を作ってしまうのです。
著者は、この問題に対する解決策として、独立したプロダクトマネジメント、独立したリードIC、全社的な顧客調査からのフィードバック、そして必要に応じた組織再編という4つのアプローチを提案しています。特に、プロダクトマネジメントの独立性について、エンジニアリングマネージャーの直接の影響下から切り離すことの重要性は、実践的な示唆に富んでいます。
計画のアライメント
計画のアライメントに関して、著者は大規模なプロジェクト（1開発者年以上）に焦点を当てることの重要性を強調しています。細かい計画まで全てを統制しようとすると、チームの機動性が失われ、緊急のニーズに対応できなくなるリスクがあります。これは私の経験とも一致しており、特に大規模な組織では、過度な計画の詳細化がかえって効果的な実行の妨げとなることがあります。
著者は、意見の対立を避けることなく、むしろそれを前向きに活用することを提案しています。Amazonの「Have Backbone; Disagree and Commit」という原則を引用しながら、強い信念を持ちつつも、最終的な決定には全面的にコミットするという姿勢の重要性を説いています。
プリンシプルドリーダーシップによるアライメント
著者は、最終的なアライメントが原則に基づいたリーダーシップから生まれると主張しています。これは単なる上意下達ではなく、協調的で透明性のあるプロセスを通じて、チーム全体が理解し、納得できる決定を導き出すことの重要性を示しています。組織の共通目標を達成するための計画と実行は、単なるトップダウンの意思決定ではなく、チーム全体の協力と理解に基づいて進められるべきです。
組織のアライメントへの道筋
組織全体のアライメントを実現するには、単なる技術的な調整以上のものが必要です。著者が示す通り、プラットフォームチームのリーダーは、技術的な卓越性とビジネス価値のバランスを取りながら、組織全体の目標達成に向けて多様なステークホルダーと協力していく必要があります。特に、競合するプロジェクトや優先順位の調整において、オープンな議論と明確な意思決定プロセスが重要となります。
プラットフォームエンジニアリングの成功は、明確な目標設定と、その目標に向けた組織全体の一貫した取り組みにかかっています。アライメントを通じて、組織は効果的なプラットフォームを構築し、継続的な改善を実現することができます。この章は、そのための具体的な指針と実践的なアプローチを提供しています。
章全体からの学び
この章から得られる最も重要な教訓は、プラットフォームアライメントが組織の成功に直接的な影響を与えるという点です。著者が強調するように、アライメントは単なる技術的な統一ではなく、目的、製品戦略、計画という3つの次元で実現される必要があります。私の経験からも、これらの要素が適切に整合していない場合、チーム間の摩擦や非効率な重複投資、そして最終的には顧客満足度の低下につながることを痛感しています。
特に印象的なのは、アライメントが「測定可能な改善」と密接に結びついているという著者の指摘です。プラットフォームの成功を評価するには、まず目標について合意し、それに向かって進む必要があります。アライメントのプロセスを通じて、組織は焦点を当てるべき領域をより明確に理解し、具体的な目標と作業項目を設定することができます。
私の実務経験でも、製品市場のフィードバックを定期的に収集し、内部メトリクスだけでなく実際のユーザーの声に耳を傾けることで、プラットフォームが選択した方向性が正しいかどうかを判断できることを学びました。これは著者が指摘する「プラットフォームが改善すべき点を意識的に選択できる」という考えと完全に一致します。
著者が指摘するように、この章の内容はプラットフォームエンジニアリングに特有のものではありません。しかし、プラットフォームエンジニアリングの文脈では、その価値が直接的な収益成長などの明確な指標で測定できないことが多く、投資先の選択においてより大きな裁量が求められます。これは、プラットフォームリーダーシップの最大の課題の一つとなっています。
最後に、この章は個々のプロダクトチームが独自の視点で構築を進めることの危険性を明確に示しています。確かに、これによって部分的な成功は得られるかもしれませんが、チーム全体としての整合性が欠如すると、真の卓越性は達成できません。プラットフォームエンジニアリングの真の成功は、技術的な優秀性だけでなく、組織全体のアライメントを通じて実現されるのです。
これらの学びを実践に移す際は、組織の規模や成熟度に応じて適切にアプローチを調整する必要があります。アライメントは一朝一夕には達成できませんが、継続的な対話と調整を通じて、段階的に実現していくことが可能です。
Chapter 12. Your Platforms Are Trusted
第12章「Your Platforms Are Trusted」は、プラットフォームエンジニアリングにおける信頼の重要性と、その獲得・維持の方法について深く掘り下げています。著者は、Warren Buffettの「信頼は空気のようなものだ - 存在するときは誰も気付かないが、欠如したときは誰もが気付く」という言葉を引用しながら、プラットフォームの成功には信頼が不可欠であることを強調しています。特に、この章では運用能力、大規模投資の意思決定、そしてビジネスへのボトルネック化という3つの主要な信頼喪失のリスクに焦点を当てています。
運用における信頼構築
運用面での信頼構築について、著者は単なるプラクティスの導入以上のものが必要だと指摘しています。私自身の経験でも、オンコール体制やSLOの設定だけでは、アプリケーションチームの信頼を完全に獲得することは困難でした。特に印象的なのは、経験値の圧縮が不可能であるというAmazonの教訓です。これは、大規模運用の経験は実際の運用を通じてしか得られないという現実を端的に表現しています。
著者は、この課題に対する2つのアプローチを提案しています。1つ目は大規模運用経験を持つリーダーの採用と権限付与、2つ目は運用リスクの許容度に基づくユースケースの優先順位付けです。これらは、私が過去に経験した運用信頼性の向上プロジェクトとも共鳴する実践的なアプローチです。
信頼構築の実践において、私たちのチームで特に効果的だったのは、段階的なアプローチの採用です。まず、非クリティカルなワークロードから始めて、運用の安定性を実証し、そこから徐々にミッションクリティカルなワークロードへと移行していく方法を取りました。例えば、新しいコンテナオーケストレーションプラットフォームの導入時には、最初は内部の開発環境のワークロードのみを対象とし、3ヶ月間の安定運用を確認した後に、段階的に本番環境のワークロードを移行していきました。
この過程で特に重要だったのは、透明性の高いコミュニケーションです。週次のステータスレポートでは、インシデントの詳細な分析結果だけでなく、それに基づく具体的な改善計画も共有しました。また、主要なステークホルダーとの定期的な1on1ミーティングでは、技術的な課題だけでなく、ビジネス目標との整合性についても率直な議論を行いました。このような取り組みを通じて、運用面での信頼を着実に築き上げることができました。
大規模投資における信頼構築
大規模投資に関する信頼構築について、著者は技術的ステークホルダーの賛同とエグゼクティブスポンサーシップの重要性を強調しています。私の経験でも、技術的な正当性だけでなく、ビジネス価値の明確な説明が、大規模投資の承認を得る上で決定的に重要でした。特に、既存システムの維持管理を怠らないことの重要性は、実務を通じて痛感しています。
著者が提示する「Icicle」チームの事例は、特に示唆に富んでいます。高レイテンシーに敏感なワークロードを持つチームの信頼を獲得するために、プラットフォームチームが自身の技術的な「正しさ」にこだわるのではなく、顧客のニーズに合わせて柔軟に戦略を変更した例は、現代のプラットフォームエンジニアリングにおいて極めて重要な教訓を提供しています。
私たちの組織では、大規模投資の承認プロセスにおいて、段階的なマイルストーンと明確な成功指標の設定を重視しています。例えば、新しいマイクロサービスプラットフォームへの投資では、6ヶ月ごとの具体的な目標を設定し、各フェーズでの成果を定量的に評価できるようにしました。これにより、投資の妥当性を継続的に検証し、必要に応じて計画を調整することが可能になりました。
特に重要なのは、ビジネス価値の可視化です。技術的な改善だけでなく、開発者生産性の向上、運用コストの削減、新機能のリリース速度の改善など、具体的な数値で効果を示すことで、エグゼクティブの継続的なサポートを得ることができました。この経験から、大規模投資の成功には、技術的な実現可能性とビジネス価値の両面からの綿密な検討が不可欠だと実感しています。
優先順位付けと信頼
ビジネスのボトルネックとなることを避けるための信頼構築について、著者はベロシティの文化醸成とプロジェクトの優先順位付けの重要性を説いています。私のチームでも、計画された作業と緊急の要求のバランスを取ることは常に課題でした。特に、「次の四半期のOKRまで待つ必要がある」という対応は、アジャイルなビジネス環境では受け入れられないという著者の指摘は、現実の組織運営と強く共鳴します。
著者が紹介するDiego Quirogaの事例は、ボトルネック解消の実践的なアプローチを示しています。特に、セルフサービス化による効率化とサポート要求の分析に基づく改善は、私自身のプラットフォーム改善プロジェクトでも有効だった施策です。
過度に結合したプラットフォームの教訓
著者は、「バッテリー込み」アプローチの失敗事例を通じて、プラットフォームの過度な結合がもたらす問題を説明しています。この事例は、エンドツーエンドのワークフローを提供しようとするあまり、コンポーネント間の結合が強くなり、最終的に運用の安定性と機能追加の柔軟性を失ってしまうという、多くのプラットフォームチームが陥りがちな罠を見事に描き出しています。
章全体からの学び
この章の最も重要な教訓は、信頼の構築には時間がかかるが、その喪失は一瞬であるという現実です。運用上の予期せぬ問題、ビジネスの急激な変化、チームの離職など、私たちの制御を超えた多くの要因が信頼を損なう可能性があります。そのため、プラットフォームリーダーには、日々の活動を通じて継続的に信頼を強化していく努力が求められます。
特に印象的なのは、多くのプラットフォームリーダーが陥りがちな傲慢さへの警告です。技術的な正しさにこだわるあまり、顧客やステークホルダーの声に耳を傾けない態度は、長期的な成功の妨げとなります。プラットフォームの真の成功は、技術的な卓越性とビジネス要求への迅速な対応の両立にかかっているのです。
この章の学びは、現代のクラウドネイティブ環境において、ますます重要性を増していくでしょう。プラットフォームの信頼性と柔軟性の両立、そして顧客との信頼関係の構築は、今後のプラットフォームエンジニアリングの成功に不可欠な要素となります。
Chapter 13. Your Platforms Manage Complexity
第13章「Your Platforms Manage Complexity」は、プラットフォームエンジニアリングにおける複雑性管理の本質と実践について深く掘り下げています。著者は、Donald A. Normanの「人々の望ましい行動ではなく、実際の行動に合わせて設計しなければならない」という言葉を引用しながら、複雑性管理が単なる技術的な課題ではなく、人間の行動や組織の現実を考慮に入れた総合的なアプローチを必要とすることを強調しています。
意図せぬ複雑性の管理
複雑性管理の成功を測る重要な指標の一つは、アプリケーションチームが必要とする「グルー（接着剤）コード」の量です。私の経験では、プラットフォームチームが提供する抽象化が不適切な場合、アプリケーションチームは独自のグルーコードを書かざるを得なくなり、結果として全体の複雑性が増大してしまいます。
特に注目すべきは、著者が指摘する「ヒューマングルー」の問題です。これは、技術的なグルーコードの削減を目指すあまり、人間による手動の調整や対応に依存してしまう状況を指します。私のチームでも、以前は運用上の問題解決に人間の介入を多用していましたが、これは持続可能な解決策ではありませんでした。
このような課題に対して、私たちは自動化と適切な抽象化のバランスを重視するアプローチを採用しています。例えば、マイグレーションプロジェクトでは、所有権メタデータレジストリを活用し、チケットの自動割り当てと進捗管理を実現しました。これにより、人的なプロジェクト管理の負担を大幅に削減することができました。
シャドウプラットフォームの管理
シャドウプラットフォームの問題について、著者は完全な抑制ではなく、適切な管理の重要性を説いています。私の経験でも、アプリケーションチームによる独自のプラットフォーム構築を全面的に禁止することは、イノベーションの芽を摘んでしまう危険性があります。
特に印象的なのは、シャドウプラットフォームを組織の学習機会として捉える視点です。あるプロジェクトでは、データサイエンスチームが構築した独自のプラットフォームを、最終的に全社的なソリューションへと発展させることができました。これは、パイオニア的なイノベーションとエンタープライズレベルの安定性のバランスを取る良い例となりました。
著者が提示する「Single Pane of Glass」のアンチパターンの分析も示唆に富んでいます。統合UIの構築は一見魅力的に見えますが、実際にはベンダーツールの進化に追従することの難しさや、異なるユーザーペルソナのニーズへの対応など、予想以上の複雑性をもたらす可能性があります。
成長の管理による複雑性制御
著者は、無制限な成長が複雑性を増大させる要因となることを警告しています。これは私の実務経験とも強く共鳴します。特に印象的なのは、効率性の向上とチーム規模の拡大のバランスについての指摘です。私のチームでも、新しい課題に直面するたびに人員を増やすのではなく、まず既存のプロセスの効率化や自動化を検討するようにしています。
著者が提案する「既存の領域での新しい作業は、そのチームの既存のメンバーによってまかなわれるべき」というルールは、実践的な指針として非常に有用です。これにより、チームは優先順位の明確化と効率化への投資を迫られ、結果として複雑性の管理にも寄与します。
プロダクトディスカバリーを通じた複雑性管理
プロダクトディスカバリーの重要性について、著者はオープンソースシステムの導入を例に説明しています。私の経験では、顧客の要求をそのまま受け入れてオープンソースシステムを提供するのではなく、真の要件の理解と適切な抽象化のレベルを見極めることが重要です。
特に印象的なのは、データ処理系のOSSに関する事例です。PostgreSQL、Cassandra、MongoDBなどの広範なインターフェースを持つシステムの運用は、ユースケースと利用者の増加に伴って線形に複雑性が増大していきます。これは、多くのプラットフォームチームが直面する現実的な課題です。
内部と外部の複雑性のバランス
最後に著者が示すデータプラットフォームの事例は、複雑性管理の実践的なチャレンジを見事に描き出しています。10人程度のチームがPostgreSQL、Kafka、Cassandraなどの複数のOSSシステムを運用する中で直面した課題は、私自身の経験とも強く共鳴します。特に、運用負荷の増大と顧客要求の多様化のバランスを取ることの難しさは、多くのプラットフォームチームが直面する普遍的な課題です。
著者が描写する改善の試行錯誤のプロセスは、とりわけ示唆に富んでいます。ベンダーのホステッドサービスへの移行、SLAの明確化、APIの完全なカプセル化など、様々なアプローチを試みながらも、それぞれに課題があったという経験は、私たちの組織でも同様でした。特に印象的なのは、これらの「失敗」を通じて、真の顧客ニーズの理解と実現可能な解決策の発見につながっていったという点です。
最終的な解決策として導き出された、シンプルな(key, value)セマンティクスのプラットフォームと特定のユースケースに最適化されたSQL系システムの組み合わせは、複雑性管理の理想的なアプローチを示しています。これは、完璧な解決策を一度に実現しようとするのではなく、段階的な改善と顧客との密接な協力を通じて、持続可能な解決策を見出していく過程の重要性を示しています。
章全体からの学び
この章の最も重要な教訓は、複雑性管理が継続的な取り組みであり、完全な解決は望めないという現実的な認識です。しかし、これは諦めるべき理由ではなく、むしろ組織の北極星として、継続的な改善の方向性を示す指針となります。
私の経験からも、複雑性管理の成功には、技術的なソリューション、組織的な取り組み、そして顧客との協力の3つの要素が不可欠です。特に重要なのは、完璧を求めるのではなく、継続的な改善と学習のサイクルを確立することです。
最後に、この章は現代のプラットフォームエンジニアリングが直面する本質的な課題に対する実践的な洞察を提供しています。複雑性の管理は、技術的な課題であると同時に、組織的な課題でもあります。プラットフォームエンジニアリングチームのリーダーとして、この両面からのアプローチを常に意識しながら、持続可能な改善を推進していく必要があるでしょう。
Chapter 14. Your Platforms Are Loved
第14章「Your Platforms Are Loved」は、プラットフォームエンジニアリングにおける「愛される」という概念の意味と重要性について深く掘り下げています。著者は、Tina Turnerの「What's love got to do with it?」という問いかけから始め、内部向けのツールが「愛される」必要があるのかという根本的な疑問に対して、説得力のある回答を提示しています。この章では、プラットフォームが単に機能するだけでなく、ユーザーに愛される存在となることが、実は生産性向上の重要な指標となることを示しています。
愛されるプラットフォームの本質
著者は、日常生活で私たちが愛用する道具を例に挙げ、プラットフォームが「愛される」とはどういうことかを説明しています。私の経験でも、最も成功したプラットフォームは、必ずしも最も高価なものや機能が豊富なものではなく、特定の目的に対して適切に設計され、信頼性高く動作するものでした。
特に印象的なのは、著者が生産性の直接的な測定の難しさに触れながら、「愛される」ことを生産性の代理指標として捉える視点です。私のチームでも、以前は定量的なメトリクスにこだわりすぎて、実際のユーザー体験を見失いかけた時期がありました。単純な採用率や効率性の指標に固執すると、プラットフォームチームが制御しやすいシステムを作ることに注力してしまい、実際のユーザーニーズを見失うという著者の指摘は、多くのプラットフォームチームが陥りがちな罠を的確に描写しています。
「単に動く」から「愛される」への進化
著者が紹介するAmazonのApolloプラットフォームの事例は、プラットフォームが「愛される」ために必要な要素を具体的に示しています。特に印象的なのは、優れたUIと自動化インターフェース、強い意見を持った設計、そして必要に応じて抽象化を「突き破れる」柔軟性という3つの特徴です。
『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』では、成熟したIT企業の製品開発に共通する3つの特徴として、リスクを開発の最終段階ではなく初期段階で積極的に特定・対処すること、製品の定義とデザインを順序立てて進めるのではなく協調的に同時進行させること、そして単なる機能実装ではなく本質的な問題解決にフォーカスすることを挙げています。また著者は、優れたプロダクトマネジャーの条件として、顧客、データ、自社ビジネス、そして市場・業界それぞれについての深い知見を持つことが不可欠だと説いています。
こちらの方が良いでしょうか？プロダクトマネジメントの本質をよりシンプルに表現してみました。
私のチームでも、最近完了したコンテナオーケストレーションプラットフォームの刷新プロジェクトで、これらの原則を意識的に取り入れました。特に、「システムの状態をUIが正確に反映している」という信頼性の確保と、「特殊なケースにも対応できる拡張ポイントの提供」というバランスの取れた設計により、ユーザーからの高い評価を得ることができました。
ハックのような解決策も愛される理由
著者が紹介する「Waiter」プラットフォームの事例は、特に示唆に富んでいます。技術的には「ハック」のように見える実装でも、ユーザーの実際の問題を解決し、摩擦を最小限に抑えることができれば、強く支持される可能性があることを示しています。
私の経験でも、「理想的」な設計からは外れるものの、ユーザーの具体的な課題を解決する実装が、結果として大きな価値を生み出すケースを何度か経験しました。例えば、あるマイクロサービスプラットフォームでは、理想的なマイクロサービスアーキテクチャの原則から外れる実装を許容することで、開発者の生産性を大幅に向上させることができました。
明白な価値提供による信頼獲得
著者が紹介するS3互換オブジェクトストアの事例は、既知の価値と適切な実装の組み合わせの重要性を示しています。特に重要なのは、認知度、互換性、エンジニアリング品質、市場投入までの時間という4つの要素です。これは、私が過去に経験した失敗から学んだ教訓とも一致します。
章全体からの学び
この章の最も重要な教訓は、プラットフォームが「愛される」ということは、単なる感情的な問題ではなく、実際の生産性と価値創出に直結するという点です。特にSmruti Patelの「マルチツール」という比喩は、プラットフォームの本質を見事に表現しています。
私の経験からも、最も成功したプラットフォームは、必ずしも最新のトレンドを追いかけたものではなく、基本的な信頼性を確保しながら、ユーザーの実際の問題を着実に解決していくアプローチを取ったものでした。愛されるプラットフォームを構築するには、技術的な卓越性だけでなく、ユーザーとの深い信頼関係の構築が不可欠です。これは一朝一夕には達成できませんが、継続的な改善と誠実な対話を通じて、確実に実現できる目標なのです。
おわりに
本書は、プラットフォームエンジニアリングという営みが、技術を極めることと人に寄り添うことの両立を求められる実践であることを、様々な現場での経験を通じて描き出しています。技術的な卓越性を追求しながらも、組織の変革に寄り添い、ステークホルダーとの信頼関係を育み、持続可能な文化を醸成していくという総合的な視点は、現代のソフトウェア開発組織が直面する本質的な課題に対する深い洞察を提供しています。
プラットフォームエンジニアリングは、技術的な基盤を「作って終わり」にするのではなく、組織とともに成長し続ける生命体のような存在です。それは、日々の地道な技術の研鑽と、組織やユーザーのニーズへの繊細な理解が融合することで初めて、真の価値を生み出すことができます。本書は、その困難な実践に挑戦する人々にとって、同じ道を歩む先達からの贈り物となるでしょう。
今後のソフトウェア開発において、プラットフォームエンジニアリングはますます重要な役割を担っていくことでしょう。しかし、その本質は変わることなく、技術を極めることと人に寄り添うことの両立にあり続けるはずです。本書で示された知見をもとに、各組織が自らの文脈に即した実践を積み重ね、技術と人間性が調和した真に価値あるプラットフォームエンジニアリングを実現していくことを願ってやみません。
みなさん、最後まで読んでくれて本当にありがとうございます。途中で挫折せずに付き合ってくれたことに感謝しています。
読者になってくれたら更に感謝です。Xまでフォロワーしてくれたら泣いているかもしれません。
