はじめに
こんにちは。ACS事業部の田中、土居、本田、青木です。
以前、「『Platform Engineering (O’Reilly)』輪読会レポート第一弾 ～ 第1章から第7章で語られるプラットフォームチームの挑戦と戦略」というブログを出させていただきました。
このブログはこちらの続きとなります。
私たちACS事業部は、プラットフォームエンジニアリング（※）の知識を深めるために、 そのため、『Platform Engineering』（O'Reilly）の輪読会を定期的に開催しています。得た知識を業務におけるプラットフォームの課題解決に役立てることを目指して、輪読会に取り組んでいます。
※：ソフトウェアの開発とデリバリを目的としたセルフサービス型の開発者プラットフォームの構築と運用に関する分野です。ソフトウェア開発者とオペレーター間の協業を支援し、企業のソフトウェアデリバリプロセスを効率化し、品質を向上させるためのアプローチです。
引き続き、Platform Engineeringの輪読会は続いており、先月最終章まで輪読会を終えることができました。
このブログでは、これまで読み進めてきた第7章までの内容を振り返り、チームで得られた学びを整理して共有します。輪読会に参加したメンバーのうちの4名で分担して書きました。
プラットフォームエンジニアリングに関心のある方々、そして私たちのチームの取り組みに興味をお持ちいただいた方に、少しでも有益な情報をお届けできれば幸いです。
今回は、後半戦の輪読会ブログとなります！第8章～第14章まで、前回同様「章の内容」、「学び」、「輪読会参加者の声」を書いていきます。
第8章：プラットフォームの設計
【執筆：田中】
章の内容
この章ではプラットフォームの設計とリアーキテクチャについて論じています。 プラットフォームが成長するにつれてアーキテクチャの再評価と改善が必要となり、リアーキテクチャがV2アプローチよりも現実的で効果的な方法であると主張しています。
1. V2構築よりもリアーキテクチャが望ましい理由
V2アプローチは、新システムをゼロから構築し、既存のシステムを置き換えるものですが、これには以下のような課題があります。 - セカンドシステム効果：チームが既存システムのあらゆる欠点を修正しようとし、最終的に失敗するか、ユーザーに受け入れられないリスクがある - V2構築で求められるエンジニアリングマインドセットを持つことは困難。既存のプラットフォームチームの文化は通常、セトラーやタウンプランナーの思考に沿っており、V2構築に必要なパイオニア的アプローチとは衝突しがちである - 補足：エンジニアには大別して3つの種別に分けられる - 曖昧なニーズから素早く「動くもの」を作る「パイオニア」 - スケールに対応した製品を構築する「セトラー」 - 効率と堅牢性を追求する「タウンプランナー」
一方、リアーキテクチャは、システムが稼働しつつ、そのアーキテクチャを段階的に再実装する反復的なプロセスです。
変更の範囲が既存のプラットフォーム内のアーキテクチャ改善に限定され、無駄な機能追加を避け、顧客への影響やリスクを最小限に抑えられるため、V2のような高リスクな全面改修よりも望ましいアプローチとされています。
2. アーキテクチャによるセキュリティへの取り組み
プラットフォームアーキテクチャにおいて、セキュリティは信頼性、機能、効率性と同じく重要な能力ですが、最も困難な分野の一つです。 サイバー攻撃を完全に防ぐのではなく、システムが変化する状況に適応し、失敗の影響を最小限に抑える「レジリエンスアプローチ」が推奨されます。
レジリエンスアプローチは、アプリケーションエンジニアに「セキュリティ意識」を強いるのではなく、「システム設計を最高のレバレッジポイント」とし、セキュリティをプラットフォームの機能やアーキテクチャに組み込んで「見えないもの」にすることを目指します。
現代のサイバーセキュリティは、適応を可能にし、セキュアな設定を強制し、より安全な方法をより早く、より簡単に実行できるプラットフォームの設計、構築、運用を含みます。 このアプローチは、潜在的な危害源（ハザード）を排除または削減するために、システムを再構築することを意味します。
プラットフォームチームは、自動テストツール、IaCなどの標準化されたデプロイツール、構成管理パターン、トークン・シークレット管理システム、標準化された可観測性ツール、共通の認証・認可ミドルウェア、テナント分離アーキテクチャなどのパターンを設計に組み込むことで、攻撃に対するレジリエンスを維持し、機能提供、信頼性、効率性といった他の成功要因も促進します。
さらに、開発者が安全な選択肢をデフォルトで利用できるよう「舗装された道（paved paths）」を導入することで、「セキュリティ・バイ・デザイン」だけでなく「セキュリティ・バイ・デフォルト」を実現します。 これにより、アプリケーション開発チームはセキュリティの懸念から解放され、本質的な価値創造に集中できるようになります。これらの取り組みは、攻撃者に対して迅速かつ安全な変化を可能にし、組織の継続的な成功を導きます。
3. リアーキテクチャのためのガードレール
リアーキテクチャを成功させるためには、既存ユーザーへの混乱を最小限に抑え、理想的には変更に気づかせない「ガードレール」の導入が不可欠です。 以下の主要なガードレールにより、チームとユーザー双方の変更コストを低減し、混乱なく大規模なシステム変更を成功に導きます。
| ガードレール | 説明 |
|---|---|
| 互換性 | 後方互換性を損なう変更は、特にマルチテナントプラットフォームでは致命的です。 避けられない場合は、新しいAPIとして導入し、既存ユーザーに十分な移行期間を設けることで、段階的な切り替えを促します。 |
| テスト | 基盤インフラの頻繁で安全なリリースには、堅牢なテストプロセスが不可欠です。 ユーザーの依存テストを含む統合テスト環境、プロパティベーステスト、ファジングなどの現代的なテスト手法への投資が求められます。 生産環境でのディープな合成モニタリングも有効ですが、「YOLO（一か八か）本番テスト」ではなく、シャドウ/カナリアデプロイメントと組み合わせ、監視テストを通過するまで本番トラフィックを制限すべきです。 |
| 下位環境 | 顧客のプレリリース検証のために専用の非本番環境を活用し、顧客がアプリケーションのテストを行うことで、徹底的な統合テストを実施します。 この環境の安定性を保つことが重要です。 |
| 段階的リリース | 製品機能のリリース管理と同様に、カナリアリリース、段階的ロールアウト、顧客サブセットへのリリース、ベータリリースなどを適用し、大規模な障害なくプラットフォーム変更を安全に本番環境に導入します。 |
| OSSの採用 | 内部プラットフォームの場合、基盤となるOSSの最新リリースに少し遅れて追従することで、コミュニティのテストと更新の恩恵を受けることができます。ただし、コミュニティサポートやセキュリティパッチの機会を逃さないよう注意が必要です。 |
4. 再構築の計画
プラットフォームの再構築は、必要な予算の確保が難しく、既存システムでの「一時しのぎ」が続いてしまうと、その必要性が経営層に伝わらないリスクがあります。
これを成功させるためには、以下の4つの計画フレームワークが不可欠です。
| 計画フレームワーク | 説明 |
|---|---|
| 最終的な再構築目標を大きく考える | 3〜5年の期間で、機能、効率性、信頼性、セキュリティという全てのシステム能力において大幅な改善を目指します。 既存プラットフォームや隣接システムの統合、先進的なオープンソースソフトウェア（OSS）やベンダーシステムの採用も検討します。 |
| 移行コストを考慮する | 既存顧客を新アーキテクチャへ移行させるための現実的なコストと計画を提案に含め、厳しく評価します。 膨大な移行コストがかかる計画は再検討が必要です。 |
| 12ヶ月間の大きな成果を特定する | 長期プロジェクトのリスクを管理するため、12ヶ月サイクルで実質的なビジネス価値を提供できる部分的な実装を計画します。 新アーキテクチャの能力を示す高価値な機能を特定し、少なくとも1つのアプリケーションチームと協力して早期に利用を開始することを目指します。 主要目標、より小規模な目標、新コンポーネントの本番稼働といった複数の目標を設定し、柔軟に進めます。 |
| リーダーシップの賛同を得て、待つ準備をする | 再構築には3〜5年間の集中的な投資と多大なコスト・リスクが伴うため、早期にリーダーシップの強力な賛同を得ることが不可欠です。 場合によっては、より大きなビジネスインパクトを持つ新技術の登場を待つ判断も考慮すべきです。 |
また、新しく採用したエンジニアに再構築の主導を任せることをアンチパターンとし、プラットフォームや企業文化を十分に理解するまでは既存チームへの貢献に留めるべきとしています。
プラットフォームの再構築は、プラットフォームの継続的な成功に向けた戦略的投資であり、慎重な計画と実行が求められます。
気づきや学び
プロダクトの再構築に関わった経験から、プラットフォームの再構築のためにガードレールを整備することの重要性を説いている部分に強く共感しました。
後方互換性を損なう変更は、既存顧客の乖離に繋がりかねません。段階的な切り替えを促し、移行期間を長く設けるだけでなく、ユーザーから理解を得るために十分な説明や施策を実施する必要もありそうです。
また、本章で述べられている視点をプラットフォーム構築時に持っておくことで、再構築時のコスト・リスクをさらに低減できるのではないかと感じました。
輪読会参加者の声
- レガシーシステムは難しいだろうけれど、確かにV2構築よりもリアーキテクトの方がうまく行くのかな？
- 短期で成果を出すことでリスクを抑えるという点は、説得力があると感じた
- リアーキテクチャは高コストでリスクもある。避け続けると技術的負債が蓄積する。現実的な難しさと必要性のバランスが求められそう
第9章：プラットフォームの移行と終了
【執筆：田中】
章の内容
この章では、プラットフォームエンジニアリングにおける移行の課題とその管理方法に焦点を当てています。 プラットフォームの安定性を提供するという目標にもかかわらず、セキュリティやベンダーの変更など、継続的なシステム進化により、移行が避けられない「実存的な課題」となっています。 優れたプラットフォームチームは、自動化、明確なコミュニケーション、そして顧客の負担を最小限に抑えるためのエンジニアリング的アプローチを通じて、移行を価値を証明する機会と見なします。 また、移行先がない場合のプラットフォームの廃止に関する意思決定と調整のベストプラクティスについても詳細に論じられています。
1.移行のアンチパターン
プラットフォームの移行は、企業規模が大きくなると以下のような強制的なアプローチが取られがちです。であり、同じアンチパターンが繰り返し発生します。
- 上層部からの強制的な期限の設定
- 要件が不明瞭なまま以降に踏み切る
- 移行時テストの不足
これらは、本来、最終手段としてのみ使用されるべきであり、プラットフォームチームは移行に際して入念に事前作業を行う必要があります。
2.より簡単な移行
より簡単な移行を実現するため、プラットフォームエンジニアリングチームはまずエンジニアリングの観点からアプローチすべきだと提言されています。 移行を容易にするためにはエンジニアリング戦略と顧客との綿密な調整が必要です。
- 企業が急速に成長している場合、移行サポートは新しいプラットフォームチームが最初に取り組むべきです
- 顧客が作業をする必要がなく、移行を意識することのない「透明性の高い移行」が理想です
- 依存関係を把握し、コミュニケーションを円滑にするため、誰がプラットフォームのどの部分を使用しているか、誰がそれらを所有しているかといった利用状況メタデータを収集・追跡することが有用です
- 移行の優先順位を付け、顧客やプラットフォームチーム自身に与える影響（テストの複雑化など）を避ける
- 顧客のフラストレーションを避けるため、移行に関する情報をロードマップに組み込み、ニュースレターや四半期計画セッションを通じて頻繁に発信すべき
3.プラットフォームの廃止
プラットフォームチームは、基盤となるシステムの進化やセキュリティ問題、ベンダーの変更など絶え間ない変化に直面するため、時にはユーザーが移行できる代替システムを提供せずに現行のシステムを停止にするも必要となります。 以下の特定のケースに限定してプラットフォームの廃止を検討すべきです。
- 当初期待した多様な設定を求める一部のユーザーや、ごく少数のユーザーしか使用しなくなった機能を提供していた場合
- 採用率が低いにもかかわらず、サポートの負担が高い場合や、その複雑さがプラットフォームの他の変更を困難にしている場合
- より優先度の高いエンジニアリング作業に集中すべき場合
廃止は、新しいシステムではサポートできない特定の機能に深く依存している少数の顧客が残った、移行作業の最終手段として使用されるべきです。 全体的な企業の利益のために、一部のユーザーを失望させることになっても、廃止を恐れるべきではありません。
気づきや学び
プラットフォームの移行と廃止はユーザー体験を向上させることを目的として行いますが、同時に良くないユーザー体験を引き起こしかねません。 積み重ねてきたプラットフォームの良い印象を、1回の大きな失敗で塗り替えてしまわないよう、ユーザーとその体験を中心に考え、入念な計画と事前作業の徹底が重要だと学びました。
輪読会参加者の声
- 移行タスクそのものをどう消化するか？を考えるだけでなく、そもそももっと簡易的に移行するためにできることはないか？と考えるのは確かに重要そう
- 移行作業の最後の20%は特に難しく、予期せぬ問題や組織の調整が必要になる、という意味かと思うが、その部分が無視できない場合、それを乗り越えるための戦略の検討が重要と思った
- 最後の20%の移行作業は多くの痛みを伴うかもしれないが、古いものを稼働させ続けることにも同じくらい多くの痛みがある（＋さらに多くのリスクも）というのは説得力があると思った
第10章：ステークホルダーとの関係性を管理する
【執筆：土居】
章の内容
この章では、プラットフォーム・エンジニアリングにおけるステークホルダー（利害関係者）との関係管理について解説しています。 みなさんはステークホルダーネジメントと聞くとどんな内容を思い浮かべますか？社内政治ですか？泥臭いものですか？ プロダクトマネジメントとは異なり、ステークホルダーマネジメントは、関係者のリーダーたちに自分たちの選択が正しいと納得させることに重点を置きます。ステークホルダーからの支持が得られない場合、どれほど優れたプラットフォームを構築しても成功は難しくなります。
とはいえ、ステークホルダーとの関係をゼロサムゲームにする必要はありません。お互いの視点を理解し、ビジネスの成功のために協力することが重要です。ステークホルダーマネジメントは単なる政治活動ではなく、組織の規模が大きくなるにつれて発生する、異なる視点や優先順位を持つ関係者との調整を行うための手段です。
ここでは、ステークホルダーマネジメントの手法として以下の4つが紹介されています。
ステークホルダーを理解し、その影響力を測るために、パワー・インタレストグリッドという手法が紹介されています。このグリッドを用いて、ステークホルダーを「高パワー・高インタレスト」「高パワー・低インタレスト」「低パワー・高インタレスト」「低パワー・低インタレスト」の4つの象限に分類し、それぞれに対して適切なコミュニケーション戦略を立てることが重要です。
ステークホルダーとのコミュニケーションにおいては、過剰な詳細情報の共有を避け、伝えたいメッセージに焦点を当てることが重要です。定期的な1on1やインターロックミーティング、顧客諮問委員会（CAB）などを活用し、情報を共有し、フィードバックを得ることが推奨されています。
ステークホルダーとの意見の相違やエスカレーションに対処するためには、ビジネスインパクトを明確にし、妥協点を見つけることが重要です。「ノー」と言う場合でも、関係を損なわないように注意し、代替案や別の解決策を提案することが大切です。影のプラットフォーム（既存プラットフォームと重複するシステム）の構築についても、その背景にある理由を理解し、協力や代替案の提案を通じて、より良い解決策を見つけることが重要です。
予算管理においては、ビジネス成果とより直接的に結びつくように努力する必要があります。優先度の低いプロジェクトを一時停止または縮小し、ビジネス価値を示すための努力が必要です。また、ステークホルダーとの良好な関係を築くことで、厳しい状況でも乗り越えることができます。
気づきや学び
パワー・インタレストグリッドはPMBOK等で紹介もされるようにプロジェクトマネジメントの分野でのステークホルダーマネジメント手法としても有名なものですが、関心・影響力が最も高いエリアのステークホルダーに対しての対応がいつでも最優先されるわけではないという点は目から鱗でした。
書籍では、CPOや主要なエンジニアリングチームリーダーが、最も関心の高いエリアに位置づけられていましたが、彼らは常に多忙を極め、プラットフォームに対して要求がある場合の期待値が高いです。そのため、プラットフォームチームが作るものに対しての厳しい意見が寄せられ、期待に答えられない場合は、別のシャドウ・プラットフォームを構築したり・プラットフォームチームの健全性が損なわれることにも繋がります。
ニーズや期待値が高いということは、それだけ失敗した場合のリスクも高いということなので、まだプラットフォームチームが立ち上がったばかりで実装が慣れていない場合は、このような組織の中心的なエンジニアリングチームではなく、別のステークホルダーから関わっていったほうがよい場合もあります。
また、プラットフォームチームの取り組みをビジネス成果に直接結びつけることこそ、プラットフォーム・エンジニアリングの本質です。どうしても作ったプロダクトがどれほど優れたものかという一点に説明が偏る傾向がありますが、以下の点を常に心がけることが重要です。 1. エンジニアリングチームの開発にどう寄与するのか 2. それを利用しない場合にどういった事が起こり得るのか 3. 投資対効果を数値として説明する（単一のエンジニアリングチームではなく、複数のエンジニアリングチームへ横展開した場合の試算も含める） 4. プロジェクト縮小や機能限定も前提としておく
輪読会参加者の声
- ステークホルダーを4分類し、時間を割くべきステークホルダーを特定する方法はこの書籍を呼んでいて一番しっくり来た箇所
- 彼らには理解できないが、彼らが関心を持つべきことのように見えることを伝えるだけで、問題を引き起こす可能性がある
- ステークホルダーに自分たちのケースをサポートするためにエンジニアリングの詳細を提供することで、意見の相違を解決しようとするのを見たことがある
第11章：あなたのプラットフォームは整合しているか
【執筆：本田】
章の内容
プラットフォームチームの成功には「アラインメント（連携）」が不可欠です。これが欠けると、「目的」「プロダクト戦略」「計画」のミスマッチが生じ、重複・互換性のないプロダクトや計画遅延を招きます。利用率重視は顧客ニーズ無視のリスクがあるため、二次指標とすべきです。
- 目的（Purpose）: 全体的な視点を持たず、狭い焦点で運用されているプラットフォームチーム。
- プロダクト戦略（Product Strategy）: サイロ化してプロダクトを構築し、不必要に重複したり、クロスプラットフォームでの利用を困難にしたりするプラットフォームチーム。
- 計画（Planning）: 重要なプロジェクトの実行において互いをサポートせず、むしろ邪魔をし、顧客とのタイムラインや状況変更について誤ったコミュニケーションをとるプラットフォームチーム。
1. アラインメント実現のための戦略
- 目的のアラインメント: 適切な人材配置と、共通のプロダクト管理・運用プラクティスによる文化の連携、チーム間の協業促進（例：ドッグフーディング）。
- プロダクト戦略のアラインメント: 独立したプロダクトマネジメントやリードIC配置でクロスプラットフォーム思考を促し、顧客調査からフィードバック収集。再編は高コスト・明確なメリットがある場合のみ。
- 計画のアラインメント: 大規模プロジェクトに限定し、対立を恐れず「Disagree and Commit」の原則で対応。
2. アラインメントはあらゆるチームの成功の鍵
プラットフォームの価値は収益成長のような明確なビジネス指標から数段階離れていることが多く、アラインメントの欠如がプラットフォーム戦略の失敗に繋がりやすくなります。リーダーが意思決定を避け、個々のチームが狭い視点で行動すると、部分的な成功はあっても、組織全体としての大きな成果は達成できません。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
1. 縦割りの意識
文化の整合を行う中で、「ユーザーをステークホルダーではなく顧客として捉える」といった記載があります。
やはり、この考え方が重要になってくるのだと改めて感じました。どうしても「ユーザーは社内の人間だから」といった意識が働き、顧客視点を忘れがちです。プラットフォームチームが提供するサービスを利用するのは、同じ会社のエンジニアであっても、そのエンジニアは「顧客」であるという認識を持つことが重要な事だと感じました。
「顧客」という意識を持つことで、目的を整理し全体の整合性を取りプラットフォーム・エンジニアリングを成功に導くというブレない軸ができるのだと思います。
2. 整合性（アライメント）
「プラットフォーム・エンジニアリングに特有のものではない」という点に注目が必要かと思います。「整合性（アラインメント）」をとり、共通の目的を築き、チームを整合させることは、あらゆるチームの成功にとって重要な要素です。
プラットフォーム・エンジニアリングにおいても、これらの基本的な原則を適用することが求められているのだと感じました。
輪読会参加者の声
- プラットフォーム・エンジニアリングは、エンジニアリングと入っているものの、単に特定の技術領域の手法ではなく、営利組織全体における管理手法であると感じた。
- 本文中に、「導入率は「補助的な指標」である」という記載がある。そもそも、顧客に選択肢がない状況での高い導入率は、成功とは言えないのだろうと思う
- チーム間の足並みが揃っていないと、機能の重複や互換性のないプロダクトが生じ、結果的に顧客のフラストレーションにつながるという指摘は、まさにその通りだと思う
第12章：あなたのプラットフォームは信頼されているか
【執筆：本田】
章の内容
1. 信頼の重要性と喪失要因
- プラットフォーム成功には顧客・外部からの信頼が不可欠
- 信頼がないと計画は破綻し、危機対応に追われる
- 信頼を失う主因として、運用力不足、大規模投資の承認欠如、ビジネスのボトルネック化がある
- リーダーの独裁的判断は短期効率的でも長期的に組織の信頼を損なう
- 責任委譲とチーム全体での信頼構築が重要
2. 運用・投資における信頼獲得
- 運用は単なるオンコールでなく、人材育成とリスク許容度に基づく優先度設定が必要
- 新規プラットフォームや再構築には事前承認とスポンサー確保が必須
- 新規投資中も既存システムの改善を継続し、ユーザー信頼を維持
- 柔軟かつ高品質な対応で、信頼不足による停滞を防ぐ
3. デリバリーと設計による信頼維持
- プラットフォームがボトルネック化しないよう、迅速かつアジャイルに対応
- セルフサービス化や機能スコープの適正化でチーム負荷を軽減
- 「全部入り」ではなくAPIを基盤としたビルディングブロック設計を採用し、結合を緩和
- 段階的な移行・再構築でコストを抑えつつ価値を確保
4. まとめ
信頼は築くのに時間がかかるが、失うのは一瞬。予期せぬ障害や組織変化、人材流出など外部要因でも簡単に揺らぐため、リーダーは常に行動で信頼を補強する必要がある。
一方で、リーダーの傲慢さや不透明な姿勢、顧客やステークホルダーの声を無視することは信頼を損ねる典型例。成功には「信頼の構築と維持」が不可欠であり、それがビジネスに対応できるプラットフォームを実現する鍵となる。
気づきや学び
私が特に印象的だと感じた箇所をいくつか取り上げていきたいと思います。
1. 信頼の重要性と築き方
信頼というものを、漠然と捉えていましたが、具体的に事例を出して説明されており、理解が深まりました。
一方で、出されている事例を自分が遂行していたとして、結果的に信頼を得たという事はあっても、信頼を得るための対策という事を意識できるかと考えると、難しいと感じました。信頼を得るためには、日々の積み重ねによるものが大きいと思いますが、うまく行かないときの一つの重要な要素になりえるのだと思いました。
2. 過去の傾向からの判断
「過去の傾向に基づいて投資判断を行うのは、ある種の“賭け”だった」という記載がありましたが、適切な分析がなされるとまさに効果を発揮するのだと思います。
「プラットフォームの視点」としての要因として大切なことであると感じました。一方で、分析データが適切でなかったり、過去の傾向が未来に通用しない場合もあるため、確かに賭けだったのだろうと感じました。
ですが成功事例もあることから、過去の要因分析をおろそかすることは出来ず、要因分析を出来るようにするためには、日々のデータ収集や分析が重要なのだと思いました。
輪読会参加者の声
- 経験が少ないリーダーがチームを率いる場合、どのように信頼を得ればよいのかは課題になりそう。
- 信頼を得るためにプロダクト戦略まで変更する場合があることに驚いた。
- 旧システムの問題点を言うだけ言って管理できないようなプラットフォームチームが新しいプラットフォームを管理できるかい、って感じで信頼できない気がする
第13章：あなたのプラットフォームは複雑さを管理するか
【執筆：青木】
章の内容
プラットフォーム・エンジニアリングは複雑性を適切に管理し、レバレッジを最大化することを目的としていますが、 この章ではその取り組みを確実に成功に導くために管理する必要がある4つの複雑性について触れています。
1. 人員調整による偶発的な複雑性の管理
ここでいう「偶発的な複雑性」は、第1章で述べられた「技術的なつなぎ」に加え、「人的なつなぎ」を指します。
プラットフォームチームがアプリケーションチームからの要求やプラットフォームの管理を過度に人に依存すると、問題が生じます。例えば、担当者の異動などでプラットフォームの管理メンバーがいなくなると、必要な情報が失われ、その結果、新たなタスクや考慮事項が発生し、さらなる複雑性を招きます。
このような事態を避けるため、定型的な作業や対応方法が明確な問題は、できる限り自動化やソフトウェアで対応すべきです。そして、人間が関わる部分は、本当に人が介在すべき高度なタスクに限定することが重要です。これにより、組織全体の効率が向上し、予期せぬ複雑性を効果的に管理することができます。
2. 影のプラットフォームの複雑性管理
「影のプラットフォーム」とは、プラットフォームチームが提供する機能やテンプレートが不十分な場合、アプリケーションチームが独自に構築・運用するプラットフォームのことです。これは、特に技術力の高いアプリケーションチームに特に見られる傾向です。
このような状況に対し、プラットフォームチームが自社のプラットフォーム利用率を高めるために、影のプラットフォームの利用を制限し、強制的に移行させようとすることがあります。しかし、この対応は非効率であるだけでなく、イノベーションや新しい試みを阻害する可能性があります。
本当に重要なのは、どのような影のプラットフォームが存在するかを把握することです。その内容が他のチームにも役立つものであれば、開発したアプリケーションチームと協力し、その機能を公式なプラットフォームに取り込むべきです。これにより、組織全体の効率が向上し、イノベーションを促進することができます。
3. 成長を制御することによる複雑性の管理
プラットフォームチームが初期段階から安定した組織へと拡大する際、プロダクト提供のギャップを埋めるには人員を増やすしかないと考えがちです。
開発とオンコール対応を担うエンジニア、プロダクトマネージャー、そしてその他必要な支援人員を揃える唯一の方法は、継続的な成長であると見なされます。
しかし、人員やプラットフォームの規模が拡大するほど、複雑性も増大します。
アプリケーションチームと異なり、プラットフォームチームは直接収益を生み出さない 「コストセンター」 と見なされ、効率性が重視されます。この領域のリーダーは、賢明な効率性の文化を築く責任があります。なぜなら、複雑性は効率性の最大の敵だからです。
プラットフォーム・エンジニアリングの役割は、「効率性を維持ししながらシステムとプロセスを戦略的に簡素化する」ことにあります。
4. プロダクトディスカバリーを通じた複雑性管理
プロダクトディスカバリーとは、単に顧客の要求をそのまま製品に反映させるのではなく、「利用可能で、有用で、実現可能な、問題に対するプロダクトソリューションを創造する」ための活動です。その本質は、顧客が本当に求めているものが何かを深く掘り下げ、焦点を絞り込んでいくことにあります。
多くのチームは、顧客から求められたオープンソースシステムを、それがプラットフォーム全体にとって適切かどうかを検討する時間もなく、そのまま提供しがちです。その結果、運用上の複雑性がユーザー数やユースケースの増加とともに直線的に増大し、運用チームは多大な負担に直面します。自動化によって運用効率を上げても、オープンソースプロダクトは機能が広範すぎることが多く、根本的な解決にはなりません。
プラットフォームを成功に導くためには、アプリケーションチームとの緊密なコミュニケーションを通じて、彼らの本質的な要求を明確にすることが不可欠です。この理解に基づいて、要求された技術スタックを「簡素化」したり、「複数の機能を統合」することで、シンプルで効率的なソリューションを提供できます。これにより、運用効率とアプリケーションチームへの価値提供を最大化し、プラットフォームの成功を実現できるのです。
気づきや学び
プラットフォーム・エンジニアリングを考える上で大切などは「複雑性をなるべく減らすにはどうすればよいか」だと思っていましたが、一番大切なのは減らすことではなく、「本当に複雑性が必要な箇所に注力できるようにプラットフォームをシンプルにする」ことであるということを学びました。
また、プラットフォームチーム以外が管理しているプラットフォームの存在を許容する、というのも重要な学びでした。
影のプラットフォームが存在するのは「プラットフォームチームが需要にこたえきれていない」か、「アプリケーションチームで扱っている技術領域的にどうしてもプラットフォームのような構造が必要になる」の二つのパターンがあり、どちらにせよ独自のプラットフォームの作成、運用を止めさせるのはアンチパターンであるということは、プラットフォームを運営する側が忘れてはいけない点だと感じました。
他にもプラットフォームチームがコストセンターである点や、本質的なソリューションを提供するためにコミュニケーションをとる点など、プラットフォームチームの属性や目的などの輪郭をより明確につかむことができました。
輪読会参加者の声
- 人的つなぎを少なくするために、異常時にとりあえずプラットフォームチームに確認するみたいなのをなくせるようにしたほうがいいのか？
- 「プラットフォームエンジニアの数を直線的に増やす必要はない」とはいうものの、増やすべきか否かの見極めはかなり難しい気がする
- やはりプラットフォームチームはアプリケーションチームから信頼されるだけの、技術力、コミュニケーション力両方を高める必要があなぁ
- アプリチームだけでなく、プラットフォームチームのためのプラットフォームになっているか？という視点も大切だと思った
第14章：あなたのプラットフォームは愛されているか
【執筆：青木】
章の内容
プラットフォームが組織に受け入れられているかを示す主要な指標は、結局のところ、「よりシンプルに、より速く、より安く、そしてユーザーがそれを気に入ること」に集約されます。しかし、ここには2つの重要な疑問が生まれます。
1. ユーザーが「気に入る」プラットフォームは本当に必要か？
社内エンジニア向けのシステムが、ユーザーが使うのを「気に入る（love）」と感じるほど優れていることを目指すべきなのかという疑問です。「気に入る」という感情的な側面は、顧客に製品を愛用してもらうことを目的とする企業にとっては重要です。しかし、社内プラットフォームも同じ目標を掲げるべきなのでしょうか？
2. そのコストに見合うか？
2つ目の問いは「プラットフォームユーザーの『気に入る（love）』を勝ち取ることは、コストに見合うのか？」という点です。 GoogleやNetflixのような大規模なテクノロジー企業は、従業員が絶賛するような独自の社内ツールを構築できますが、多くの企業にとって、それほど多くの時間と労力を費やすことは、経済的に現実的ではないかもしれません。
「愛される」プラットフォームであるべき理由
これらの疑問に答えるために、あなたが普段から使っている、例えばキッチンやガレージにあるお気に入りのツールを考えてみてください。それらの中には高機能、高価格でなくても、あなたの特定のニーズに合わせて丁寧に作られており、うまく機能することで作業に喜びをもたらしてくれます。
私たちが「愛される」プラットフォームについて語るとき、まさにこれが意味するところです。社内プラットフォームにとっての「愛」は、生産性向上の優れた代替指標となります。 というのも、エンジニアリングの生産性を客観的に測定する良い方法がまだ確立されたとはいえないからです。
もちろん今日においては「導入率」や「効率性」といった指標は生まれてはいます。 しかしそれだけを重要視してしまった場合、私たちの仕事が「複雑さの管理」ではなく「複雑さの排除」であると誤解してしまいます。その結果、ユーザーが「気に入る」システムではなく、プラットフォームチームが管理しやすいだけのシステムを構築してしまうことにつながります。
この章では実際にAmazonの内部で開発されたプラットフォームに対して様々な例を交えながら、どのようにして顧客（アプリケーションチームのエンジニアなど）に好かれるプラットフォームになっていたのはなぜか、という点を詳細に解説しています。
そのいずれにも共通しているのは、アプリケーションチームからいかにニーズをくみ取り、「ユーザーのベロシティを促進し、ユーザーに喜びをもたらし、彼らがしていることを素晴らしいものにする」という目標を達成するためにどのようなプラットフォームを作り信頼してもらえるようにするか、ということを考えていたということです。 「プラットフォーム・エンジニアリングという世界での愛は、完全に根付く前に強い信頼の基盤を必要とすることを忘れてはならない」という言葉で締めくくられています。
気づきや学び
プラットフォーム・エンジニアリングの業務に携わる中で、プラットフォームの成功指標が未確立であるというギャップを感じていましたが、「愛されていること」がそのギャップを埋める解となり、ユーザーの高い満足度を示す指標であると理解することができました。
他の章の内容とも重なりますが、「愛されるプラットフォーム」とは、以下の要素で成り立っています。
- 愛してもらえるようなプラットフォームを作る
- 愛してもらえるためには信頼性の高いプラットフォームである必要がある
- 信頼性が高いとユーザーに感じてもらえるようにするためには、ユーザーの本質的な要求を読み解く必要がある
- 読み解くためには、コミュニケーションを密接に取る必要がある
最終的にユーザーに愛されるプラットフォームを作っていけるようにすることが、プラットフォーム・エンジニアリングの本質なんだということがこの章での一番の学びとなりました。
輪読会参加者の声
- 「プラットフォームの導入を『作れば使われるだろう』という考え方に任せていた」というのはどのプラットフォームエンジニアも通る道なんだなとしみじみ感じた。
- アプリケーションチームが使うのを「気に入る」ためのシステムではなく、プラットフォームチームが制御しやすいシステムを構築することにつながるというのはかつて様々な組織で起こっているアンチパターンだと思う。実際にそのような現場も見たことがある
- 単純な指標のみに焦点をあててしまうと本質を見誤るのはその通りだと感じた！
- 「優れたインターフェース」というのは単純にUIとして機能が提供されるだけではなく、APIも用意されており様々なシステムの連携方法が用意されていることなのだな、というのがAmazonの事例を読んでよく分かった
おわりに
前回のブログから、書籍のすべての章の内容を振り返ってきました。
この本は特定のツールに対してではなく、プラットフォームエンジニアリングという概念そのものについての知識を体系的に身に着けることができました。 英語の本となりますが、気になった方はぜひお手に取って読んでみてください。
弊社では、プラットフォームエンジニアリングの推進支援だけでなく、プラットフォームエンジニアリングを推し進める内部開発者ポータルとしてPlaTTというサービスをリリースしています。ご興味がございましたら是非ご覧ください。
ここまで長いブログとなりましたが、お読みいただきありがとうございました。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
