プラットフォームチームが直面する4つの課題：Thoughtworksエキスパートによる洞察

プラットフォームエンジニアリングは、イノベーションを促進し、開発をスケールさせ、組織全体でシームレスな統合を実現するために不可欠です。プラットフォームエンジニアとして、私たちはしばしば、戦略的なソリューション、テクノロジーへの深い理解、および広範なビジネス目標との整合性を必要とする複雑な課題に直面します。この記事では、プラットフォームエンジニアリングに携わってきた私たちの経験を共有し、遭遇した最も差し迫った課題のいくつかと、それらを克服するための実践的な方法について議論します。私たちの仕事を通じて収集した主要な問題と洞察を詳しく見ていきましょう。

テクノロジー環境の課題

毎日、プラットフォームエンジニアは競合する要求をうまくさばかなければなりません。彼らは、多様なフレームワークやテクノロジーを使用するチームに対し、シームレスなサポートを提供する必要があります。これには、たとえばJavaの最新リリースを注視し、セキュリティリスクを評価し、アップグレードの利点を理解するといった最新情報の維持が含まれます。その一方で、依然として古いバージョンで作業している可能性のある人々のために、プラットフォームが円滑に動作することを保証しなければなりません。

このテクノロジーの広がりにより、プラットフォームチームが統一されたアプローチを維持することはほぼ不可能になります。そして変化のペースは容赦ありません。テクノロジーは急速に進化しますが、多くの企業では、そのテクノロジーの成熟度が遅れています。エンタープライズ全体のアーキテクチャフレームワークや共有ガバナンスモデルがないため、個々のチームはしばしば独自の解決策を見つけざるを得なくなり、その結果、努力がサイロ化し、ミスが繰り返され、ベストプラクティスを共有する機会を逃してしまいます。

さらに、常に付きまとう「ベンダー　ロックイン」のリスクがあります。チームが特定のテクノロジー（クラウドプロバイダーであれソフトウェアベンダーであれ）にコミットすると、後戻りは非常に困難になります。システム全体がそのテクノロジーを中心に構築され、組織は単一ベンダーのエコシステムに縛られます。そのテクノロジーを別のシナリオ、チーム、またはクライアントのために転換、再利用、または適応させようとすれば、すべてをゼロから再構築するという見通しに直面します。それはコストと時間のかかる試みです。

では、この複雑さをどう管理すればよいでしょうか？ 答えは「プロダクト　エコシステム」の構築にあります。これは、異なるチームがコンポーネントを構築、共有、再利用できる内部プラットフォームです。このプラットフォームは組織の結合組織となり、フレームワークやテクノロジーが標準化されつつも、さまざまなチームのニーズを満たす柔軟性を備えた中央ハブを提供します。これは単に今日の問題を解決するだけでなく、将来の成長と適応のための基盤を作ることなのです。

鍵となるのは、これらの内部プラットフォームをそれ自体が一つのプロダクトとして扱うことです。他のプロダクトと同様に、これらはポートフォリオ管理戦略によって導かれる必要があります。つまり、サービスをいつ作成し、廃止し、拡張すべきかを定義するロードマップを構築することを意味します。これらの決定は真空中で行われるべきではありません。代わりに、明確に定義されたプロダクト評価指標によって推進されるべきです。個々のチームの好みではなく、企業の長期的な目標に基づいた、事前に確立された基準を満たす新しいツールやテクノロジーのみを導入してください。

効果的なガバナンスは不可欠です。それがなければ、プラットフォームはカオスに陥り、チームはバラバラの方向に進んでしまいます。どのテクノロジーを採用し、どれを廃止し、プラットフォームの目標をより広範な組織目標とどのように一致させるかについて、戦略的な決定を下す責任を持つ専任の委員会またはグループを設立してください。この組織は定期的に会合を持ち、単一のチームにとっての即時的な有用性だけでなく、全体的な戦略との整合性に基づいて新しいテクノロジーを評価・承認する必要があります。

最後に、ベンダーロックインのリスクを軽減するために、チームは「ベンダーに依存しない（vendor-agnostic）テクノロジー」の採用を検討すべきです。TerraformやDopplerのようなツールは、特定のプロバイダーに固定されることなく、チームが複数のクラウドプロバイダー間で運用できるようにすることで柔軟性を提供します。これらのテクノロジーは、インフラストラクチャを標準化しつつ、必要に応じてベンダーを切り替える自由を維持する方法を提供します。これは将来の制約に対するバッファを提供する積極的なアプローチです。

ユーザー中心主義の課題

プラットフォームエンジニアリングにおいて、しばしば見落とされがちな皮肉があります。それは、プラットフォームは社内ユーザー（開発者、データサイエンティスト、その他の技術チーム）向けに構築されているにもかかわらず、それらのユーザーとそのニーズを理解することが驚くほど難しい場合があるということです。プラットフォームを、特定のユーザーニーズを満たすために設計された製品ではなく、テクノロジーの集合体として捉えてしまうという罠に陥りがちです。しかし、ユーザー中心主義を見失うと、その背後にあるテクノロジーがどれほど洗練されていても、的外れなプラットフォームを構築してしまうリスクがあります。

根本的な問題は、プラットフォームがユーザーから切り離されて設計されていることが多いことです。私たちは、高度な技術を持つユーザーが複雑な環境を直感的に操作できるだろうという前提でツールを開発しています。しかし、現実ははるかに複雑です。開発者やデータサイエンティストは技術的な環境に慣れているかもしれませんが、複数のツールやインターフェースを操作しなければならない断片的な体験に圧倒されてしまうことがあります。ある瞬間はKubernetesで作業していたのに、次の瞬間には監視用のGrafanaとログやパイプライン用の別のツールを切り替えているのです。その結果、ユーザーは支離滅裂でイライラさせられる体験になってしまいます。

ここで、プラットフォームエンジニアリングの真の課題が明らかになります。つまり、この根底にある複雑さを軽減し、シームレスで一貫性があり、直感的に操作できるプラットフォームをいかに実現するかということです。そのためには、プラットフォームを単なる技術の寄せ集めとして捉えるのではなく、ユーザーを中心として設計された製品として捉える必要があります。

真にユーザー中心のプラットフォームを構築するには、ユーザーエクスペリエンス（UX）デザインのベストプラクティスを取り入れる必要があります。UXデザインは、顧客向け製品と関連付けられることが多い分野です。UXの原則を社内プラットフォーム設計に適用することで、ユーザージャーニー全体を考え始めることができます。つまり、次のような重要な質問を自問自答するということです。ユーザーはどのようにしてプラットフォームを発見するのか？オンボーディングプロセスはどのようなものか？概念実証の構築や新しいワークロードの導入を始める際に、インターフェースはどれほど直感的か？

効果が実証されている解決策の一つは、社内開発者ポータルの開発です。単一の統合インターフェースを提供することで、社内ポータルはユーザーが複数のツールを切り替えることなく、プラットフォームの様々な機能を操作できるようにします。アクセスを簡素化し、認知負荷を軽減し、より合理的で一貫性のあるユーザーエクスペリエンスを提供します。このアプローチは、開発者やデータサイエンティストの作業負担を軽減するだけでなく、プラットフォームの進化と拡張を最小限の摩擦で実現します。

プラットフォームエンジニアリングは、その性質上、複雑な技術を扱います。しかし、だからといってプラットフォームが使いにくくなるわけではありません。あらゆる場面で摩擦を減らすことに重点を置くことで、開発者エクスペリエンスを向上することができます。これを実現する方法の一つは、適切なレベルの抽象化を実装することです。重要なのは、使いやすさを向上するのに十分な抽象化でありながら、柔軟性を制限するほどには抽象化しないというバランスを取ることです。

異なる組織、さらには同じ組織内の異なるチームであっても、抽象化に対するニーズは様々です。目標は、ユーザーに「セーフティネット」を提供することです。これには、賢明なデフォルト設定、リソース制限、および一般的なワークフローのための明確な「ゴールデンパス（黄金の道）」が含まれます。これにより、特に規制の厳しい環境において、ユーザーが不安定さを招くような決定を下すことから保護されます。コンプライアンスツールなどの「標準搭載（out-of-the-box）機能」を提供することで、ユーザーは基礎となる複雑さを心配することなく、自分たちが最も得意とすること、つまりイノベーションと構築に集中できるようになります。

ユーザー中心のプラットフォームエンジニアリングにおける最後のハードルは、直接的なフィードバックの欠如です。内部ユーザーは自分のプロジェクトに深く関わっていることが多いため、プラットフォームをどのように使用しているか、どのような障害に直面しているか、あるいはどのような機能があれば良いかについて、必要な洞察を提供してくれないことがあります。このフィードバックがなければ、プラットフォームチームは推測に頼らざるを得ず、間違った領域に投資したり、貴重な改善の機会を逃したりする可能性があります。

これを克服するには、プラットフォームの使用に関する「実践コミュニティ（Communities of Practice）」を育成することが不可欠です。開発者であれデータサイエンティストであれ、その他の技術チームであれ、ユーザーが経験、課題、提案を共有できるスペースを作ることで、実用的な洞察を豊富に得ることができます。それ以上に、アンケート、インタビュー、フォーカスグループを通じて積極的にユーザーと関わることが重要です。私たちは、彼らの使用パターンやペインポイントを理解するために時間を割き、これらのデータを使用してプラットフォーム体験を継続的に洗練させていく必要があります。

組織的な課題

プラットフォームエンジニアリングチームにとって、最も根強い課題の一つは技術的なものではなく、組織的なものです。テクノロジーが急速なペースで進化し続ける中、プラットフォームチームはしばしば企業の広範な目標と同期が取れていないことに気づきます。その根本原因は何でしょうか？企業の長期的な方向性に関する可視性の欠如、プラットフォームチームが何をすべきかについての誤解、およびプラットフォームエンジニアと、彼らの仕事に依存している非技術的なステークホルダーとの間の断絶です。

3つの主要な組織的課題を分析し、プラットフォームチームがいかにして企業の全体的なミッションと自らの取り組みをより良く一致させることができるかを探ってみましょう。

長期的な可視性の欠如

すべてのプラットフォームチームの成功の中核にあるのは、企業の戦略的ロードマップを理解する能力です。しかし、あまりにも頻繁に、プラットフォームチームは組織が進んでいる方向についての洞察を欠いています。企業は1年後、3年後、あるいは5年後に何を必要とするでしょうか？将来のマイルストーンを達成するために、プラットフォームチームが提供しなければならない構成要素は何でしょうか？

これらの問いに対する明確さがなければ、プラットフォームチームは推測するしかありません。彼らは長期的なインパクトのあるプロジェクトを犠牲にして、差し迫った短期的なニーズに取り組むかもしれません。その結果、組織が将来必要とする不可欠なコンポーネントの提供に苦労し、遅延、非効率、および機会の損失を招く可能性があります。

解決策はシンプルですが、実行が容易とは限りません。それは「内部の整合性（アライメント）」です。プラットフォームチームは組織の他の部門とより密接に連携する必要があります。プラットフォームエンジニアリングと開発チームの連絡役となる専任の「テクニカルプロダクトオーナー」を置くことで、双方はロードマップが同期していることを確認できます。プラットフォームチームが組織の戦略的方向性と優先順位についての洞察を得る、定期的なチーム横断的な議論が不可欠です。これにより、プラットフォームチームのイニシアチブがタイムリーであるだけでなく、企業の将来の成功に不可欠なものとなります。

プラットフォームチームに関する誤解

プラットフォームチームが実際に何をすべきかについては、広範な誤解があります。彼らは常に問題を修正し、火を消し、あるいは単発のリクエストに応える「リアクティブ（反応的）モード」で活動すべきなのでしょうか？それとも、構造化され予測可能な方法で企業の目標に貢献する、独自の「プロアクティブ（先見的）で戦略的なロードマップ」を持つべきでしょうか？

この緊張はフラストレーションにつながる可能性があります。プラットフォームエンジニアは、反応的なタスクに圧倒され、大規模で長期的なイニシアチブに集中できないため、常にキャッチアップに追われているように感じるかもしれません。これは生産性に影響を与えるだけでなく、プラットフォームチームが企業にもたらす価値を制限します。

解決策は、より明確な組織構造とガバナンスを採用することです。プラットフォームチームは、独自のロードマップと内部プロセスを備えた明確なミッションを持つべきです。これにより、チームは場当たり的なリクエストへの対応にすべての時間を費やすのではなく、プロアクティブで価値主導の仕事に集中できるようになります。責任と期待値を概説する明確な「チームAPI」を設定し、境界線を作ることは、組織内でのプラットフォームチームの役割を定義し、より戦略的に運用することを可能にします。

非技術系ステークホルダーからの不信感

プラットフォームチームにとってのもう一つの共通の組織的課題は、非技術的なステークホルダーによるプラットフォームテクノロジーへの不信感です。多くの場合、ビジネスリーダーや他の非技術系チームは、プラットフォームチームが提供する価値を完全には理解していません。彼らはプラットフォームを、イノベーションを推進し、効率を向上させ、システムの安定性を確保する役割を理解せずに、単なるもう一つのコストセンターとして見るかもしれません。

このギャップを埋めるために、プラットフォームチームは一貫してその価値を示さなければなりません。これは、単にアップタイムの統計やインフラの更新を報告する以上のことを意味します。これには、プラットフォームの機能がいかに組織全体の成功に貢献しているかを定期的に実演することが含まれます。これを行う一つの効果的な方法は、プラットフォームイニシアチブの投資利益率（ROI）を定量化する「社内デモとメトリクス」を活用することです。たとえば、FinOpsイニシアチブを通じてプラットフォームがいかにクラウドワークロードのコストを削減したか、あるいは、いかにセキュリティとコンプライアンスを向上させたかを示すことで、プラットフォームチームはその戦略的重要性を説得力を持って訴えることができます。

プラットフォームチームは、しばしば「高い認知負荷」への対処に追われ、「火消しモード（緊急対応）」を強いられ、本来の責任範囲外の「追加のワークロード」に負担を感じ、組織全体からの「断絶感」に悩み、それが組織全体から孤立感を抱かざるを得ない状況に陥ります。こうした課題は単にフラストレーションを募らせるだけでなく、チームの士気を低下させ、生産性を阻害し、最終的にはプラットフォームチームが最大限の能力を発揮することを阻む可能性があります。

ユーザー中心主義の課題

プラットフォームチームは、しばしば高い認知負荷に対処し、緊急対応モードに追い込まれ、本来の責務以外の追加作業に追われ、組織全体から疎外感を抱かざるを得ない状況に陥ります。こうした課題は単にフラストレーションを募らせるだけでなく、チームの士気を低下させ、生産性を阻害し、最終的にはプラットフォームチームが最大限の能力を発揮することを阻む可能性があります。

高い認知負荷

プラットフォームエンジニアはしばしば高い認知負荷、つまり膨大な量の技術情報を管理することによって引き起こされる精神的な緊張を強いられます。この負荷は重層的で、エンジニアは複数のクラウドプロバイダー、オープンソースプロダクト、およびサードパーティツールを常に把握しておく必要があります。さらに、.NET、Java、Angularなどの多様な技術スタックや、Postgres、Mongo、Cassandraなどの無数のデータベースをサポートしなければならないという事実が、複雑さを増大させます。これらすべてが、エンジニアが日々の業務で継続的に保持し適用しなければならない膨大な知識の蓄積へとつながります。

さらに、認知負荷はテクノロジー自体からだけでなく、プラットフォーム上で動作するプロダクトからも生じます。エンジニアは、これらのプロダクトの背後にあるビジネスプロセスやルールに直接関与しているわけではないかもしれませんが、プロダクト、ビジネス、プラットフォームチーム間の絶え間ないコラボレーションにより、しばしばビジネスロジックも頭に入れておく必要があります。

これに対処するためには、ガバナンスが重要な役割を果たします。テクノロジースタックを標準化し、ロギングやモニタリングのためのツールの数を減らし、サポートされるテクノロジーの限定されたセットに合わせることで、認知的な負担を大幅に軽減できます。さらに、責任を明確にし、チーム間の相互作用を合理化するための「チームAPI」を定義することは、明確な境界線と期待値を確立することで精神的な負荷を軽減するのに役立ちます。

火消しモード

プラットフォームチームにとっての大きな課題は、火消しモード、つまり長期的なソリューションの構築に集中する代わりに、インシデントや運用上の問題に常に対応している状態に陥ることです。チームはしばしば、プラットフォームの改善に関するプロアクティブな仕事から、突然のプロダクション停止への対処や緊急のビジネスリクエストへの対応へと切り替えなければならず、ロードマップから引き離されます。

この反応的な状態は生産性に影響を与えるだけでなく、プラットフォームチームが戦略的な方法でプラットフォームの機能を向上させることを妨げます。このサイクルから抜け出すために、プラットフォームチームは「You build it, you run it（構築者が運用も担う）」というマインドセットを受け入れる必要があります。ここでは、運用上の責任がプロダクトチームや開発チームと共有されます。より多くの運用タスクを開発チームに移管することで、プラットフォームエンジニアは火を消すことではなく、インパクトの大きいプロジェクトに集中できるようになります。

監視の自動化やフォールト トレランスのデフォルトの実装など、プロセスとツールの改善にさらに投資することで、問題が拡大する前に予防でき、絶え間ない対処の必要性が軽減されます。

追加の作業負荷

プラットフォームエンジニアが直面するもう一つのハードルは、本来の業務範囲外にある追加作業負荷が絶えず増加していることです。これは多くの場合、ビジネス部門からプラットフォームチームにカスタム機能やレポートの作成を依頼されることで発生します。特に、クラウドプロバイダーやサードパーティベンダーがビジネス要件を満たす標準機能を提供していない場合に顕著です。

これらの要求に応えることは重要ですが、プラットフォームチームの主要なミッションである社内プラットフォームの開発と改良の妨げとなります。これを管理するために、プラットフォームチームは明確な委任プロセスを確立する必要があります。カスタムビジネスリクエストなど、プラットフォームチームのコアミッションから外れる責任は、多くの場合、専任のビジネスチームまたはサポートチームに委任できます。委譲の文化を築き、プラットフォームチームの責任範囲をより明確に定義することで、プラットフォームエンジニアは業務の優先順位をより効果的に設定し、コア以外のタスクに圧倒されるのを避けることができます。

断絶感

プラットフォームチームでは、組織全体からの疎外感という問題がよく見られます。エンジニアは、自分の仕事が会社のより広範な目標にどのように位置づけられているのかを把握できず、エンゲージメントの低下や離職率の上昇につながることがあります。プラットフォームエンジニアは、自分の仕事が会社のミッション、ビジョン、戦略目標と合致していないと感じることが多く、組織全体から孤立感を抱くことがあります。これに対処するため、プラットフォームチームはロードマップを組織目標と整合させる必要があります。企業が急成長期にあるか、コスト削減策を実施しているかに関わらず、プラットフォームチームの目標はこれらを反映し、サポートするものでなければなりません。例えば、事業拡大期には、新製品の市場投入までの時間を短縮する取り組みを優先する必要があります。一方、財務が逼迫している時期には、コストと効率を最適化するFinOpsプラクティスの導入に注力する必要があります。プラットフォームエンジニアが開発チームやビジネスチームと連携できる社内コミュニティを構築することで、組織とのより深いつながりを育むことができます。プラットフォームが主要なビジネス成果にどのように貢献しているかを定期的に伝えることで、疎外感を軽減し、プラットフォームチームが自分たちが大切にされていると感じ、会社の方向性に合致していると感じることができます。

結論

プラットフォームエンジニアリングは複雑でありながらやりがいのある仕事であり、組織に意義ある変化をもたらすための独自の課題と機会を提供します。私たちは、進化するテクノロジー環境の中で、強力なガバナンス、ユーザー中心の設計、およびビジネス目標との整合性を通じて価値を提供することに常に注力しています。ここで概説した課題に取り組むことで、プラットフォームチームは成長、イノベーション、およびオペレーショナルエクセレンスの実現に大きく貢献できるようになります。