はじめに
私たちのチームと輪読会
こんにちは。私たちACS事業部は、プラットフォームエンジニアリング（※）の知識を深め、多角的な視点から議論したいと考えています。そのため、『Platform Engineering』（O'Reilly）の輪読会を定期的に開催しています。得た知識を業務におけるプラットフォームの課題解決に役立てることを目指して、輪読会に取り組んでいます。
※：ソフトウェアの開発とデリバリを目的としたセルフサービス型の開発者プラットフォームの構築と運用に関する分野です。ソフトウェア開発者とオペレーター間の協業を支援し、企業のソフトウェアデリバリプロセスを効率化し、品質を向上させるためのアプローチです。
なぜこの本を選んだのか？
近年、プラットフォームエンジニアリングは、ソフトウェア開発においてますます重要な役割を担うようになっています。私たちは、この分野を体系的に学べる書籍を探していました。 そんな中で出会ったのが、O'Reillyの『Platform Engineering』です。この本は、プラットフォームエンジニアリングの概念から実践的な方法まで網羅されています。チームで読み解き、議論することで、知見を深めたいと考えました。
これまでの進捗と、ブログ執筆の背景
気がつけば、輪読会も中盤戦に突入！全14章の内、第7章までを読み終えたところです。 興奮冷めやらぬうちに、得られた知見を皆様とシェアしたいという思いが沸き上がり、このブログを執筆することにしました。
このブログでは、これまで読み進めてきた第7章までの内容を振り返り、チームで得られた学びを整理して共有します。輪読会に参加したメンバーのうちの5名で分担して書きました。それぞれの視点や気づきが詰まっていると思います！プラットフォームエンジニアリングに関心のある方々、そして私たちのチームの取り組みに興味をお持ちいただいた方に、少しでも有益な情報をお届けできれば幸いです。
※章タイトルはブログ執筆者による訳です。
章のまとめと学び
第1章：プラットフォームエンジニアリングが不可欠になる理由
章の内容
ソフトウェア組織は長年にわたり、共有コードやツール、インフラの管理に苦労してきました。中央集権的な管理と自由裁量の両極端を行き来する中で、根本的な課題は解決されず、クラウドやOSSの普及により複雑性はさらに増しています。
この章では、そうした背景を踏まえ、プラットフォームエンジニアリングが複雑性にどう対処するかを以下の観点から解説しています。
プラットフォームの定義
セルフサービスAPIやツール、ナレッジ、サポートを含む基盤を、アプリケーション開発チームが再利用可能な内部プロダクトとして提供するもの。これにより、開発の迅速化と品質の向上が実現されます。
複雑性の要因と「接着剤」問題
多様なOSSやクラウドサービスを各チームが個別に選択し組み合わせた結果、それらをつなぐ「統合コード＝接着剤」が各所に散在し、複雑性が増大。これがメンテナンス性を低下させ、「変更しづらい環境＝沼地」を生み出しています。
- プラットフォームによる解決アプローチ
- 「利用技術や構成要素＝プリミティブ」の絞り込み
- アプリごとに必要だった「接続・設定コード＝統合コード」の削減
- OSSやクラウドの利用統一による移行コストの一元化
- 開発者自身による運用まで見据えた設計
- 専任チームによる継続的なプラットフォーム改善
プラットフォームエンジニアリングは、これらを通じて開発・運用の複雑性を制御し、組織全体の生産性を底上げする戦略的アプローチとして位置づけられています。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
◆プラットフォームエンジニアリングの必要性
書籍では、過去25年間にわたってソフトウェア組織が直面してきた課題として、コード、ツール、インフラの共有に関する問題が挙げられています。この問題に対して、多くの組織が中央チームを作り、解決を試みてきましたが、うまくいっていない事例が多く見られます。中央チームによるプロダクト提供が使いにくかったり、ニーズを無視していたりすることが問題となり、各アプリケーションチームにクラウドやOSSの選択を任せる方向へシフトしています。しかし、このアプローチも、運用や保守の複雑さを増し、生産性を低下させる要因となっています。
プラットフォームエンジニアリングは、このような複雑さを管理し、効率を高めるための解決策となります。特に、選択肢の多さがもたらす問題や、クラウドやOSSの複雑さをどのように扱うかについての理解が重要であることを学びました。
◆プラットフォームエンジニアリングの価値
プラットフォームエンジニアリングが価値を提供する方法として、プリミティブを制限し、アプリケーションチームが開発したものを自ら運用できるようにする点が強調されています。複雑さを管理するためにプラットフォームを構築することは、エンジニアリングの生産性を向上させるだけでなく、運用の負担を軽減し、最終的には全体の効率を高めるという視点が非常に印象的でした。
また、プラットフォームを単なるツールやインフラとしてではなく、プロダクトとして捉えるべきだという点も重要です。顧客中心のアプローチでプラットフォームを設計し、運用の複雑さを抽象化することが、より高い価値を生み出す鍵となります。
◆組織内でのプラットフォームエンジニアリングの役割
書籍では、プラットフォームエンジニアリングのチームがどのようにして組織全体の複雑さを管理し、他のチームが迅速に開発と運用を行えるようにするのかについても詳しく説明されています。プラットフォームチームは、インフラチームや開発ツールチーム、SREチームなどと連携し、協力して複雑さを管理する役割を担います。
特に印象的だったのは、プラットフォームエンジニアリングが他のチームと異なり、システム全体の複雑さを抽象化し、必要な「接着剤」の量を最小限に抑える方法を示している点です。これにより、各チームがより効率的に作業を進めることができるようになります。
◆プラットフォームが支援するイノベーション
プラットフォームは、単に運用の複雑さを管理するだけでなく、イノベーションをサポートする役割も担っています。開発者が迅速に新機能をリリースし、実験を行うためには、プラットフォームの支援が欠かせません。プラットフォームエンジニアリングがイノベーションと実験をサポートする方法として、アプリケーション開発者が安全に新機能を本番環境にデプロイできるようにする仕組みが重要であると感じました。
改めてプラットフォームエンジニアリングの重要性を再認識し、システムの複雑さを管理しながらイノベーションを促進する方法を学んだことは大きな収穫でした。
輪読会参加者の声
- 「 『セントラルチームを排除して、クラウド・OSSを選択できるように』の内容は『伽藍とバザール』っぽい」
- 「Wikiページはプラットフォームとは見なされない⇒これは意見分かれそう。プラットフォームに関する考え方の難しさ」
- 「開発利便性とセキュリティ要件はよく対立する」
- 「PEは大きな企業にしか適用できないのか？」
- 「システムがスパゲッティになる前に小さく始めるのも。」
第2章：プラットフォームエンジニアリングの柱
章の内容
プラットフォームエンジニアリングを実現するうえで不可欠な4つの柱が、本章で提示されています。
プロダクト（Product）
顧客体験を重視したプロダクト設計が基本です。用途の汎用性に応じて以下を使い分けます。
- 舗装されたパス：一般的なニーズに対応する標準的な使いやすいプラットフォーム
- 鉄道：特定の業務要件に合わせて設計された専用パス
また、キュレーション・プロダクト・アプローチにより、顧客ニーズに合致する機能を厳選・提供する姿勢が求められます。
開発（Development）
プラットフォームはソフトウェアそのものであり、APIやクライアントツール、OSSカスタマイズ、メタデータとの統合といった抽象化の実装が中核です。
広さ（Breadth）
多様な開発者に対応するには、セルフサービス、マルチテナンシー、ガードレール設計が重要です。特に ユーザー観察可能性（Observability） は、利用状況の可視化と改善に不可欠です。
運用（Operations）
プラットフォームはビジネスの基盤であり、信頼性ある運用体制が求められます。
- SLO/SLA管理、変更管理、合成モニタリング、運用レビューといった実践
- プラットフォーム全体の責任を持つ専任チームによる継続的な改善
さらに章末では、生成AIによるツーリング変革やオペレーション支援といった将来の拡張可能性にも言及しています。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
◆プラットフォームエンジニアリングの4つの柱
書籍では、プラットフォームエンジニアリングの成功に不可欠な4つの柱が紹介されています。これらは、「プロダクトアプローチ」「ソフトウェア開発」「幅広い開発者対応」「運用基盤」といった要素で構成され、複雑なシステムを管理し、ビジネスの基盤として運用するために必要なポイントとして強調されています。
特に「プロダクトアプローチ」の重要性に共感しました。技術的な観点を超えて、顧客のニーズに基づくサービスの提供が求められ、プラットフォームは単に技術的なツールではなく、ビジネスを支えるための「プロダクト」として位置づけられています。この視点がプラットフォームを成功に導く鍵となると感じました。
◆ソフトウェア開発と抽象化
プラットフォームエンジニアリングにおけるソフトウェア開発は、インフラやツールのレベルで行われるのではなく、複数のプロダクトラインを持つ大規模なソフトウェア組織の中で行われます。ここでは、社内で構築したソフトウェアの抽象化が重要であり、OSSや外部システムとの連携においても、抽象化を通じて複雑さを管理することが求められます。
「抽象化されたソフトウェア開発」の重要性を理解する中で、複雑なシステムをシンプルにするための努力が如何に重要かを再認識しました。プラットフォームエンジニアリングの本質は、複雑なシステムをユーザーにとって使いやすく、効果的に抽象化することにあると言えます。
◆プラットフォーム運用の重要性
プラットフォームエンジニアリングの成功には、運用の安定性が不可欠です。特に「プラットフォーム全体に対する責任」という部分では、プラットフォームエンジニアリングチームが運用全体を管理し、ユーザーにとって信頼できる基盤を提供する責任が強調されています。運用の規律がないと、どんなに優れた技術でも顧客から信頼されなくなり、最終的にはプラットフォームの価値が損なわれます。
運用が確立していないと、システム全体が不安定になり、ユーザーに過度な負担を強いることになります。この点については、運用面でも高い規律を守ることが重要であると感じました。
輪読会参加者の声
- 「顧客は開発チームなのだから、PFチームにもソフトウェアエンジニアが必要、というのはある意味当然かもしれない」
- 「CIチーム（の『SRE支援』 ）の知見や経験はPEに繋がるのか？PlaTTの提供にどう関わっていくのか？」
- 「> 抽象化されたソフトウェア開発 Daprもこの一つに入る？」
第3章：いつ、どのように始めるか
章の内容
組織規模・状況別にプラットフォームエンジニアリング開始の最適タイミングと方法を解説しています。
スタートアップでは初期チームは不要な一方、大企業では既存組織からの文化変革が鍵となります。
シナリオ別アプローチ
小規模スタートアップ
初期は共有コード中心。コア外はアウトソースで課題解決。協力体制の限界
機能不全なら正式組織へ移行検討。責任明確化必須。大規模な既存企業
従来のインフラチームからプラットフォームエンジニアリング文化へ変革が必要。技術だけでなく文化変革が重要。
プラットフォーム進化の初期段階
初期ステージ（試行錯誤）
エンジニア約50名までを追跡。プロダクト/市場適合性を探索。個人ツール・迅速コーディング・限定テスト・手動デプロイが中心。プラットフォームチームは未設置。コードからデプロイまでの摩擦低減に注力。次のステージ（管理された段階）
開発環境の自動化、テスト・デプロイメント強化、オブザーバビリティ、変更・意思決定共有が重要。プラットフォームコンポーネントが出現し、環境管理が始まる。プラットフォームチームは必須ではないが、インフラ・自動化に注力する小グループも。プラットフォームエンジニアリングは依然として共有責任。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
発見可能性とチーム間の連携の重要性
プラットフォームの成功には、提供されるサービスや情報（ドキュメント）が、それを必要とするユーザー(開発者)や顧客に「いかに簡単に見つけられるか、認識されるか」という「発見可能性」の概念が重要となります。そして、この発見可能性を最大化するためには、チーム間の密な連携が不可欠であると学びました。特にチーム立ち上げ初期段階では、発見可能性と連携が大きな課題となる傾向があると思います。一方、適切にチーム間連携が取れていれば、提供されたサービスは開発チーム内でスムーズに展開され、必要なサービスの適用へと繋がるはずです。
現実的な問題解決のアプローチ
プラットフォームエンジニアリングは、将来の理想像だけでなく、現在の具体的な課題解決から始めるべきであることに気づかされました。
どうしても理想を追究したくなります。現時点での作業方針をブレさせないためにも、目標・理想は大切だと思いますが、囚われすぎてしまう事には注意が必要だと感じました。
何より重要なことは、解決するためのプラットフォームという位置づけが、多くのチームの関心を呼ぶことが大切であることに共感を得ることが出来ました。
輪読会参加者の声
- 人材のリストラや、変化を好まないリーダの交代について
- 日本では、なかなか難しい。これらを行える文化・仕組みがある企業でないと、実行は難しいと感じた。
- 日本に置き換えて考えた場合
- 好意的な開発チームリーダから巻き込んで行く事が大切。
- 変化を好まないリーダが過半数を占めるような組織だと、プラットフォームエンジニアリングはうまく行かないだろう。
- 狭い範囲でのエンジニアの満足度を高めるサービスを見つけていくことが必要
第4章：優れたプラットフォーム・チームの構築
章の内容
プラットフォームチーム構築の鍵を解説しています。
単一専門性のリスク、エンジニアの主要4役割、採用・評価、マネージャー特性、チーム文化構築が焦点です。
チーム構成のバランス
プラットフォームチームは、システムとソフトウェアエンジニアのバランスが不可欠です。
偏りは運用過多や開発過多のリスクを生みます。主要な役割と専門性
バランスの取れたチームには、以下の役割理解と配置が重要です。ソフトウェアエンジニア: コードとシステム全体を理解。
システムエンジニア: 広範なインフラ知識で構築・問題解決。
信頼性エンジニア: 信頼性向上に貢献。
システムスペシャリスト: 特定分野に特化し、技術レベルを向上。採用・評価とマネージャー特性
採用では、コーディングに加え、システム理解度、設計能力、顧客共感性を評価します。優れたマネージャーは、プラットフォーム運用経験、大規模・長期プロジェクト経験、細部へのこだわりが鍵です。チーム文化の構築
多様な専門性を持つエンジニアが尊重し協力し合える環境が重要です。組織リーダーは新しい文化を強化し、互いに感謝し合う文化を育むことで、チーム全体の成功に繋がります。
気づきや学び
システム、開発に集中してしまう
どうしても自分の分野や好みに、今までの経験に引きずられてしまうため、複数のエンジニアが所属するチーム編成が必要バランスの重要性
プラットフォームチーム構成する上で、バランスがとても大切という事に考えさせられました。 チームの立ち上げのキッカケは、何か問題が発覚しした際に立ち上げられるのかなと思います。 そのため、初期のチームはかなり、技術的な偏りが出てくるのではないかと考えます。 それをいかに、偏りをなくし特定の分野に固執しないチーム作りが求められている気がします。役割について
本文中にマネージャーやエンジニアといった役割、および採用について言及されています。 それらをすべて網羅することは、現実的ではないと感じています。 ですが一方で、大規模なプラットフォームチームを目指すのであれば、これらすべての要素が必要になるということなのだと思います。 結局のところ、自分たちの組織がどこを目指し、どのようなプラットフォームチームを構成していくのかを明確にすることが最も重要なのかもしれません。
輪読会参加者の声
- 書籍で求められているチームの人事のレベルがかなり高い、このような人材が本当に集まるのか疑問
- 対象読者は、ある程度の人事権を持っている人を想定している感じがする
- 知名度のある大企業など、採用における応募の多い事が前提とした書き方がされている
- 前章で、スタートアップ企業などはプラットフォームチームが不要という記述もあったため、このような書き方があれている前提があるのかもしれない。
- 人のスキルに依存する所が大きい印象があった
- 事例の記載が無く、抽象的な表現が多い
- プラットフォームにおける事例に関しては、現在求められている所なのだと感じる所がある
第5章：プロダクトとしてのプラットフォーム
章の内容
この章では、プラットフォームを「プロダクト（製品）」として社内顧客に提供するための心構えと方法、そしてよくある失敗について語られています。
以下の4つの節によって構成されているため、それぞれについて説明します。
- 「顧客を重視するプロダクト文化」
- 「プロダクト発見と市場分析」
- 「プロダクトの実行を成功させる：プロダクトロードマップの作成」
- 「プロダクトの失敗例」
「顧客を重視するプロダクト文化」
プラットフォームにおける顧客とは、そのプラットフォームの利用者を指します。
つまり、用意したプラットフォームを利用して新規事業のためのシステムを開発したり、既存システムの運用、アップデートなどを行うアプリケーションエンジニアなどがプラットフォームにおける「顧客」にあたるわけです。
そのためプラットフォームエンジニアリングにおける顧客とは、いわゆる社内の顧客であり、本節ではこの社内の顧客の特徴について詳しく語られています。
通常のビジネスであれば、顧客に必要とされているかどうかはそのプロダクトの売り上げなどを成果として判別できますが、プラットフォームの場合はそれができません。
プラットフォームにおける成果とは「利用者の満足度がどれほど高いか」「利用者の不便さをどれだけ解消したか」「どれほどの生産性向上につながったか」というものになりますが、それを知るためには、常にそれらを計測できるようにしておくことが必要です。
そのため、プラットフォームが組織のために機能しているかを常に測定し、多くの利用者の声に耳を傾ける必要があります。
また、会社に所属するメンバーは日々入れ替わっていくため、プラットフォームを利用する顧客の属性も日々変化していきます。
「変化する顧客環境の中でいかに特定の顧客のニーズを越えて、解決すべき一般化可能な問題に目を向けられるかが重要である」ということがこの節で説明されています。
「プロダクト発見と市場分析」
この節では、プラットフォームで何に取り組むべきかをどのように決めるべきか？という問いに対して、広く顧客に採用されるプラットフォームを作るための情報を収集する方法についてまとめられています。
いきなり全社向けの巨大なプラットフォームを作ることは現実的ではなく、まずは協力してくれる社内のチームを見つけ、スモールスタートで始めることが望ましいとされています。
そのような社内のパートナーを見つける際のポイントとして、以下のようなものを判断の指標に入れると良いでしょう。
- 潜在的なユーザー層を確認する。
- それらのユーザーにとっての潜在的利益を定量化する。
- 潜在的なユーザーに導入コストを提示する。
- ユーザーがどれくらいの期間で移行し、メリットを享受できるかを見積もる。
- ユーザーの意欲を評価する。
- 現在の予算状況を考慮する。
また、新たな機能のプラットフォームを提供した際にそのインパクトを測定するための指標を設ける必要があります。
- 移行にかかるオーバーヘッド時間は？(プラットフォームを使用するコスト）
- プラットフォーム利用者にどれだけの時間やお金を節約させているか？(プラットフォーム採用のメリット）
- 潜在的なユーザーベースの何パーセントが自発的にこのプラットフォームを採用しているか？(顧客の需要）
- プラットフォームのCSATスコアは？(プラットフォームに対する顧客の意見）
これらを測定するためのメトリクスは「インパクト・メトリクス」と呼ばれており、どの様なメトリクスをインパクト・メトリクスとして定義するかによって、プラットフォームチームが測るべき顧客の反応を正確に測定できるかが決まります。
これらの指標やメトリクスは定期的に見直し、改善し続けていくことでプロダクトに対する顧客の評価をなるべく正確にとらえ続けることが重要です。
また、顧客の求めていること＝達成すべき課題とは限らない、ということについても触れられていました。
顧客の求めていることはあくまでも顧客が触れている環境独自のものである可能性があり、本質的で汎用的な解決策は別にある可能性があるからです。
「プロダクトの実行を成功させる：プロダクトロードマップの作成」
プロダクトの発見と市場分析を行い、作るべきプラットフォームが定まってきたら、続いてはロードマップの作成を行っていきます。
ロードマップは以下のように整理すると良いということが説明されています。
- ビジョン：長期的な目標。より良い未来のプラットフォームの本質的な特徴を描こうとするもの
- 戦略：中期的な目標。ビジョンを達成するために何をすべきか（＝何がビジョンの達成を妨げているのか）
- 目標と指標：1年の目標。達成すべき技術的なOKRなど
- マイルストーン：四半期ごと。目標と指標を達成するためにブレイクダウンした具体的な作業
最後に、これらを顧客向けのロードマップとしてまとめ、共有しながら進めていくことで、本質的な目標を見失うことなくプラットフォームの開発を進めていくことができます。
「プロダクトの失敗例」
最後に、プラットフォームをプロダクトとして開発していく際に陥りがちな失敗パターンについて説明されています。
主に、以下の5つが挙げられています。
- 移行コストの過小評価
- ユーザーに対する変更予算の過大評価
- 安定性が低いときに新機能の価値を過大評価する
- エンジニアリング・チームの規模に対してプロダクト・マネージャーが多すぎる
- エンジニアリング・マネジャーがすべき仕事をプロダクト・マネジャーがすること(タスクマネジメントはプロダクトマネージャーの仕事ではない)
主に顧客のジョインにおける見積もりミスや、新機能や役割分担における認識のずれが失敗を引き起こす要因になる、ということがまとめられています。
気づきや学び
章を通して感じたこととしては、「プラットフォームチームに求められる能力値は非常に高い」ということです。 この章で語られていることをまとめると、プラットフォームチームが成果を上げるためには以下の三つが重要になることが分かります。
- プラットフォームというプロダクトがどのようにして顧客の解決につながっているかを正しくヒアリングし、測定すること
- 顧客の願いをそのままかなえることではなく、より本質的な解決策を導き出すこと
- 解決策（新機能）を顧客にそのメリットが十分伝わるような形式で共有すること
これらの前提を踏まえて成果を出すためには顧客に対して必要な情報を引き出したり、逆に顧客の目線でメリットを伝えるためのコミュニケーション能力や、顧客が管理しているシステム・ツールにおいて必要なメトリクスを得るためのオブザーバビリティの知識や、本質的な課題解決方法を導くことのできる技術力が必要なことが分かります。
これらは一朝一夕で身に着けられるものではないため、普段から技術についてのアンテナを張り、コミュニケーションに磨きをかけていくことプラットフォームエンジニアを目指す人にとっては大切だと感じました。
輪読会参加者の声
輪読会に参加したメンバーからは、以下のような声がありました。
- 顧客のニーズを聞くためには質問の仕方がなるべく具体的であるほうが良い、ということを学べた
- 顧客の期待と異なる伝わり方をする可能性があるため、「顧客向けロードマップ」では、顧客に見せるべき情報とそうでない情報を明確に区別すべきであり
- 移行コストの過小評価や、安定性が低い状況での新機能追加の危険性などは、当てはまる場面が多そう
- 顧客がやっていることを理解でき、なおかつより良い解決策を導き出せる知識量がPFチームには必要だと感じた
- メトリクスを取得するという文化自体を組織にもたらす、という目的を考えれば、まずはSREを組織に導入するということは理にかなっているのかも…
第6章：オペレーティング・プラットフォーム
章の内容
この章では、プラットフォームエンジニアリングにおける運用プラクティスに焦点を当てています。
プラットフォームチームが所有し取り組むべき3つの主要な運用プラクティスとして、オンコール、ユーザーサポート、運用フィードバックが挙げられています。
オンコールプラクティスでは、24時間365日の体制の必要性と、開発者と運用担当者が同じチームに所属し、オンコールローテーションに参加する「Merged DevOps」アプローチが推奨されています。
また、オンコール負荷を持続可能なレベルに保つための具体的な数値目標や、誤報の削減、安定性の優先順位付けの重要性が強調されています。
ユーザーサポートのセクションでは、エンジニアがユーザーサポートを行うべき理由が説明され、サポートレベルの公式化、クリティカルでないサポートのオンコールからの切り離し、
サポートスペシャリストの雇用といった段階的なアプローチが提案されています。遠隔地の顧客サポートや、大規模な組織におけるサポート体制の拡大についても触れられています。
運用フィードバックのプラクティスでは、SLOとSLA、変更管理、合成モニタリング、運用レビューの4つの重要なプラクティスが詳述されています。SLOとSLAは顧客向けと社内向けで異なるアプローチが必要であること、
変更管理は自動化だけでなく文書化とレビューが重要であること、合成モニタリングはエンドツーエンドの監視と顧客理解に役立つこと、運用レビューはチームと組織レベルで定期的に行い、リーダーシップの積極的な関与が必要であることが述べられています。
全体として、このドキュメントは、プラットフォームチームが運用上の問題をプロアクティブに対処し、機能開発と運用のバランスを取るために、これらの運用プラクティスに日常的に投資する必要性を強調しています。
気づきや学び
◆オンコール
SREであれば、信頼性向上のため、インシデント時にオンコール対応を行うことが多々あります。
一方Platformチームでオンコールを行うといったイメージがありませんでした。
Platform払い出し後に、運用業務を開発チームが行うか、SREやDevOpsチームに分割するかで意見が分かれます。
大規模チームだと、開発と運用の両方にフォーカスできる人員がいるため分割の必要性が低いといったことが明記されていました。
確かにPlatformチームは払い出しのみがスコープではないため、オンコールや運用といったサポートがスコープに入るのは不思議ではありません。
また、オンコールなどサポートを行うことで、Platformが開発チームに必要とされているかの調査に利用することもできるので、すごく腹に落ちました。
◆サポートの自動化
グローバルをサポートするSaaSなどのプロダクトであれば、時差をカバーする目的で24/365な体制を敷く事があるかと思います。
その際、タイムゾーンをカバーする人材を採用したり、何らかの方法で自動化をする必要があるでしょう。
輪読会参加者の声
- Platform Engineeringの文脈でサポートが出るのはちょっと意外。でも確かに投げっぱなしジャーマンはいかんよな。
- 24時間365日のオンコール体制の重要性が説かれていたが、これが現代の日本においてベストプラクティスなのかは疑問。
- 運用は、少なくとも負荷問題からプラットフォームチームだけで賄うのは不可で、SREとの協力関係は必要。
- 認知負荷の軽減を目的とするPlatform Engineeringだが、Platform Engineering自体の認知負荷が高いと改めて感じた。
- 「最善のアプローチは、すべての誤報を取り除き、オンコールの負荷を、ビジネスに影響を与える問題を週にせいぜい5件までに抑えることに集中する」とあるが、これは指標に使えそう。
第7章：プランニングとデリバリー
章の内容
この章では、プラットフォームエンジニアリングにおける長期プロジェクトの計画と実行を成功させるためのベストプラクティス、特に長期プロジェクトの進め方、提案書の書き方、アクションプランの策定、そしてチーム運営やロードマップ計画について解説しています。
- プロジェクトの失敗とその背景
- プラットフォームチームは「正しいものを作っているのに、価値を証明できない」ことがある。
- 長期プロジェクトでは、計画の不備や外的要因による遅延が致命的になる。
- ステークホルダーへの説明不足が信頼を損なう。
- 成功の鍵：計画と文書化
- 提案書には「背景」「問題」「解決策の選択肢」「提案内容」「行動計画」の5要素が必要。
- アクションプランでは、テスト基準、依存関係、人員、採用促進、マイルストーンを明確にする。
- ボトムアップのロードマップ
- KTLO（Keep The Lights On）、マンデート、システム改善の3つの作業プールを見積もる。
- システム改善は「信頼性」「効率」「セキュリティ」の3カテゴリに分類し、スタックランクで優先順位をつける。
- 情報共有と信頼構築
- 「Wins and Challenges」による隔週の進捗共有が、チームの価値を可視化し、信頼を築く。
- 外部との信頼構築には、課題の共有も重要。ただし、慎重な配慮が必要。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
◆プロジェクトの失敗とその背景
書籍では、プロジェクト長期化の要因として、スコープの拡大、初期の肥大化、問題の不明確さ、チーム離職が挙げられています。 これらを避けるには、現実的なスコープ、段階的開発、明確な問題定義、チーム安定化が重要である説明がされています。
スコープ管理の難しさは多くのチームで共通の課題かと思います。「小さく始めて、頻繁に届ける」という原則を意識し、初期の段階で価値を提供できる小さな単位に分割することの重要性を感じました。また、チームの心理的安全性を高め、離職を防ぐための努力も継続的に行う必要がある点に共感しました。
◆成功の鍵：計画と文書化
書籍では、長期プロジェクト成功のため、提案文書でゴールと要件を明確にすることの重要性が書かれています。鍵となる「背景」「問題」「解決策」「根拠」「行動計画」の5要素が挙げられていました。 提案後には、テスト基準、依存関係、人員計画、採用促進を含むアクションプランが必要である点や、マイルストーン管理の重要性、プロジェクトマネージャーの早期過度な関与は避けるべきという点についても書かれていました。
特に初期の提案段階で、ビジネス側の期待値と技術的な実現可能性のギャップを埋める丁寧なコミュニケーションが不可欠だと感じました。依存関係の洗い出しは、後工程での手戻りを防ぐために、より時間をかけて行うのがよさそうです。
◆ボトムアップのロードマップ
書籍では、運用と改善に焦点を当てたボトムアップ・ロードマップの重要性が書かれています。 KTLO（運用維持）、経営層指示、システム改善（信頼性、効率性、セキュリティ）の3要素での見積もりについて説明されています。また、インナーソーシングへの過度な依存は避けるべきアンチパターンであることについても書かれていました。
日々の運用業務に追われがちなプラットフォームチームにとって、システム改善のための時間を意識的に確保することの重要性を再認識しました。また、インナーソーシングは理想論だけでなく、現実的な運用負荷や責任範囲を考慮する必要があるという点は、示唆的で重要な点と感じました。
◆情報共有と信頼構築
書籍では、隔週の「Wins and Challenges」によるステータス共有が推奨されています。状況、行動、結果を簡潔に報告し、勝利と課題を共有することで、透明性と信頼性を高めることが解説されています。
定期的な情報共有は、ステークホルダーの期待値を調整し、信頼関係を構築する上で有効だと改めて感じました。特に課題をオープンに共有することは、早期の支援につながる可能性があり、心理的なハードルを下げて実践していくことがポイントとなりそうです。
輪読会参加者の声
- 「自分たちが何を解決しようとしているのか理解するのが大切」
- 「CTOなどにPEチームの責任者になってもらうのはこれが理由なんだろうな」
- 「大き過ぎる計画はプロジェクトがネバーエンディング状態になるため、小さい目標からたてて、一つ達成したら、次の目標を作成する」
- 「財務は、エンジニアのことは分からんが、コストは削減すべきと考えている」
全体を通して
組織がプラットフォームを効率的に構築・運用するための知識と戦略について説明されていました。技術的な側面だけでなく、組織構造やプロセス、ステークホルダー管理といった非技術的な側面も重視し、プラットフォームエンジニアリングを組織全体の戦略的な要素として捉える重要性が強調されている点が印象的でした。
プラットフォームエンジニアリングチームが直面する可能性のある課題に対する解決策と、ベストプラクティスを学ぶことができ、有益な内容でした。具体的な事例やベストプラクティスが随所に示されており、読者は自身の組織の状況に合わせてこれらの知識を適用し、実践的な戦略を立てる上で役立つと感じました。
おわりに
ここまで、第7章までの内容を振り返ってきました。チームで輪読会を進める中で、プラットフォームエンジニアリングという分野の奥深さ、そしてその重要性を改めて認識しました。多くの気づきを得ることができました。チームの議論からその雰囲気が少しでもお伝えできていれば嬉しいです。今回の輪読会を通じて得た知見を活かし、プラットフォームエンジニアリングへの取り組みをさらに加速させていきたいと思います。
弊社では、プラットフォームエンジニアリングの推進支援をしております。ご興味持たれた方がいらっしゃいましたら、ぜひ以下リンクよりご覧ください。
また、後半部分（第8章〜第14章）についても、第二弾としてブログ化する予定です。 次回のブログも熱量込めて作っていきますので、ご期待ください！
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
