プラットフォーム実行ギャップに注意

ビジネスバリュー

内部開発者生産性プラットフォームへのコミットメントを決定することは、経済的なものです。賛成の議論は、効率性、品質、市場投入時間におけるメリットが、その構築と進化に発生する財務的、人的、機会コストを上回るかに依存します。プラットフォームのビジネスケースを明確に説明できない場合、責任ある方法で採用することはできません。計算には、市販サービスの機能を考慮に入れる必要があります。なぜなら、プラットフォームが市販のサービスでは提供できない機能、コンテキストへの特異性、または利便性を提供しない限り、市場に任せてメンテナンスの負担を回避する方が良い可能性があるからです。結局のところ、プラットフォーム戦略は、差別化されていない作業量を削減することに依存しており、増加させることではありません。

デジタルプラットフォームを構築するという決定は、デジタルプラットフォームのビジネス価値を裏付ける責任の始まりにすぎません。プラットフォーム戦略の動機は、高いレベルでは説得力があるかもしれませんが、提供する機能と提供方法を決定する際には、多くの詳細な決定が含まれています。さらに問題を複雑にするのは、テクノロジーの進歩、組織のニーズの進化、そして自社開発ソリューションと競合するクラウドプロバイダーやその他のベンダーによる新しくて改良されたオファリングのリリースに伴い、機能のビジネス上の正当性は時間の経過とともに変化することです。

組織に約束された価値を提供するには、エンドユーザー向けの製品よりも継続的な改善と製品イノベーションの割合を高く計画する必要があります。プラットフォームを管理しやすく、コストを抑えるためには、運用関連の項目をバックログで優先的に扱う必要があります。ユーザーは、新しい機能のストリームよりも、一貫性、安定性、信頼性を高く評価します。また、提供するすべての製品は、いつか市場に出回る新しい製品、内部で構築された後継製品、あるいは能力の責任を製品開発チームに戻すことによって廃止する必要があります。廃止はプラットフォーム製品ライフサイクルの基本的な部分であり、それを考慮しないと、最初に期待したビジネス上のメリットが損なわれる可能性があります。

プロダクト思考

顧客である製品開発チームを喜ばせるように設計された製品を構築していることを決して忘れてはいけません。APIの使いやすさの問題やドキュメントの不足など、開発者がプラットフォームをスムーズに使用することを妨げるものは何でも、プラットフォームのビジネス価値の成功した実現に対する脅威となります。開発者エクスペリエンスを優先しましょう。どんなに技術的に優れていても、誰も使わない製品は成功した製品とは言えません。内部プラットフォームの投資収益率を達成するには、製品開発チームがプラットフォームを使用し、うまく使用することが必要です。そのためには、プラットフォームを理解し、理解し、その機能を認識する必要があります。Max GriffithsがInfrastructure as Productに関する記事で説明しているように、プラットフォーム製品は、他の種類の製品と同様に、顧客の共感、製品所有権、インテリジェントな測定が必要です。

内部製品の1つの利点は、製品の進化と成功に非常に投資しているユーザーがいることです。他の顧客グループと同様に、同僚は懐疑的な人、中立的な人、熱心な人の混合です。熱心な人を活用し、彼らがプラットフォームのアーリーアダプターおよびチャンピオンになるのを支援することは、組織内でのプラットフォームの認識に大いに役立ちます。ロードマップを伝え、フィードバックを受け入れ、ユーザーからの経験を収集することで、プラットフォームの継続的な関連性に貢献します。幸いなことに、皆さんは同じ組織で働いているため、豊富なコミュニケーションチャネルを利用できます。内部プラットフォームにはマーケティングが必要です。一般向け製品のマーケティングとは同じようには見えませんが、それでもマーケティングです。

良好な関係を維持することが採用への鍵です。そのため、避けられない停止が発生した場合、それらを伝え、ユーザーへの影響を軽減するための計画を調整してください。何か問題が発生し、停止が発生した場合（ヒント：発生します）、謝罪と透明性がユーザーを安心させます。管理上の命令を採用戦略として頼るという誘惑に抵抗してください。あなたはユーザーを拘束しているかもしれませんが、彼らが自分たちの利益のために製品を使用することを強制することは、生産的な関係を育むものではありません。

運用効率化

内部プラットフォームを導入する際には、製品開発チームから多大な信頼を得る必要があります。プラットフォームは、組織が機能を果たすために使用するシステムの主要な依存関係となるからです。この信頼を正当化するには、十分な運用能力が必要です。

これは、プラットフォームチームが、ネットワーキング、スケーリング、災害復旧などのソフトウェアインフラストラクチャの基本をしっかりと理解している必要があることを意味します。プラットフォームエンジニアリングチームが基盤となるテクノロジーに苦労するならば、製品開発チームにとって堅牢な製品を構築することはできません。さらに、現代の運用における卓越性は、インフラストラクチャを超えて、信頼性を確保する実践にまで及びます。書籍「Site Reliability Engineering」（[https://www.amazon.com/gp/product/149192912X/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=149192912X&linkCode=as2&tag=martinfowlerc-20](https://www.amazon.com/gp/product/149192912X/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=149192912X&linkCode=as2&tag=martinfowlerc-20)）は、この分野における最先端の状況をよく説明しています。プラットフォーム組織がオブザーバビリティ、モニタリング、SLOなどのSRE実践に関するスキルを持っていない場合、製品チームの信頼を損なうリスクがあるだけでなく、問題が発生してもそれに気づかないリスクもあります。

プラットフォーム組織は、インシデントを効率的に管理し、そこから学ぶ成熟度も備えている必要があります。時間外サポート、アラートシステム、非難のないインシデント事後レビューを優先事項とするべきです。そのためには、プロセスの確立、雇用契約の言葉の変更、公正な報酬の予算化、そして[オンコールを十分に快適な体験にする](https://ctford.github.io/oncall-charter)ために必要な対応を行う必要があるかもしれません。これは計画にも影響を与えます。マイグレーションなどの大きな変更が必要な場合は、ユーザーのダウンタイムを最小限に抑えるために、段階的な変更に投資する必要があります。

ソフトウェアエンジニアリングの卓越性

プラットフォーム組織は単なる運用部門ではないため、運用能力以上のものが必要です。かなりのカスタムアプリケーションを作成する予定がなくても、スクリプト、テンプレート、構成ファイルは急速に複雑化します。プラットフォームを迅速かつ安全に変更する能力を維持したい場合は、適切な方法で構築する必要があります。

インフラストラクチャの文脈におけるソフトウェアエンジニアリングの卓越性の私たちの好きな要約は、Kief Morrisの著書「Infrastructure as Code」（[https://www.amazon.com/gp/product/1491924357/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491924357&linkCode=as2&tag=martinfowlerc-20](https://www.amazon.com/gp/product/1491924357/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1491924357&linkCode=as2&tag=martinfowlerc-20)）で定義されているインフラストラクチャ・アズ・コードの3つのコアプラクティスです。

• すべてをコードとして定義する
• 進行中のすべての作業を継続的にテストおよび提供する
• 独立して変更できる小さくシンプルな部品を構築する

組織がこれらの実践を一貫して適用できれば、プラットフォームビジョンを実行できる可能性がはるかに高くなります。それらがなければ、ある時点でインフラストラクチャを良好な状態にすることはできますが、開発チームのニーズの変化に伴う進化のペースを維持することはできません。

内部製品を使用すると、製品開発チームにも負担がかかります。優れた製品開発チームは、依存関係によって提供されるサービスレベルを認識し、それらを独自の設計に組み込み、エンジニアリングプラクティスを使用して、サービスレベル目標に影響を与える可能性のあるリスクを軽減します。これらの依存関係が社内で提供される場合、これはさらに重要です。なぜなら、プラットフォームの品質がいかに高くても、商用SaaSプロバイダーのレベルに達することはまずないからです。

健康的なチーム

個々のスキルは重要ですが、長期にわたって卓越性を維持するには、強力なチームレベルの規律が必要です。プラットフォームシステムがビジネスの他の部分によって依存されている場合、それらを維持するための専門知識が少数の忙しい個人によってのみ保持されることは許されません。明確なミッションを持つ自律的なチームが必要であり、個々のコードまたはシステムの所有を避ける必要があります。彼らは知識共有、ドキュメント、オンボーディングに投資しなければなりません。宝くじに当たった人が1人いることが、プラットフォームの存続を脅かすべきではありません。

これらのプラットフォームエンジニアリングチームの生産性を維持するには、作業を計画するためのシステムが成熟している必要があります。彼らは、価値の観点から説明されたアイテムのバックログを持ち、優先順位付けのプロセスを持っている必要があります。そうでなければ、緊急の事項が重要な事項を圧倒する可能性があります。インシデントと計画外の作業は避けられませんが、チームの時間の多くが労力に費やされる場合、製品の改善に投資する能力がなくなります。チームは一度に多くのプラットフォーム製品を管理しようとすべきではありません。

Matthew SkeltonとManuel Paisの著書「Team Topologies」（[/bliki/TeamTopologies.html](/bliki/TeamTopologies.html)）で議論されている認知負荷という考え方は、チームのミッションを管理可能に保つのに役立つと考えています。チームがまったく異なるタスク間でコンテキストを頻繁に切り替える場合、認知負荷は大きすぎます。そして、これが起こると、チームは日々の作業を行う能力が低下するだけでなく、新しいチームメンバーがすべてのシステムで作業するのに必要な自信を得るのも困難になります。

はじめに

組織にこれらの能力がまだない場合、プラットフォーム戦略の採用が不可能になるのでしょうか？経験からしか得られない教訓なしに、どのようにしてこれらの能力を構築するのか、と尋ねるかもしれません。

秘密は、実行の質を妥協することではなく、最初は野心の範囲を控えめにすることです。規模の大小に関わらず、プラットフォームの取り組みはビジネス価値を生み出し、製品志向で導かれ、運用とソフトウェアエンジニアリングの卓越性で実装され、新しいプラットフォームサービスを維持できるチーム構造によって支えられる必要があります。それ以下だと、期待したブーストは、組織内の開発者の間で新興のプラットフォームの評判を損なうドラッグになる可能性があります。

テクノロジー資産のよく理解されている部分にターゲットを絞った、小さく焦点を絞ったプラットフォームサービスの方が、難易度が低くなります。全体的な視点からプラットフォームを検討するという責任から解放されるわけではありませんが、そこから始めて構築することができます。たとえば、製品チームの運用上の負担を軽減し、サービス全体の可視性を向上させることができるロギングクラスタを提供することは、高度な財務モデリングを行うことなく、明確なビジネス価値をもたらします。それでも、顧客にサービスを提供するように（可用性、鮮度、検索UIが開発者のニーズを満たしていますか？）製品思考を必要としますが、その製品思考は、たとえば統一された開発者ポータルを提供するために必要なものほど成熟している必要はありません。そして、たとえば、組織のすべてのマイクロサービスにオブザーバビリティサイドカーを構築するほどではありませんが、それでもソフトウェアエンジニアリング、運用スキル、そして健全なチームが必要です。

最初に自問自答すべき質問は、「製品チームを助けるために構築できる最小限のものは何か[1]」です。2つ目は、時期が来たときにどのようにアップグレードまたは移行できるかということです。最先端技術は急速に進化しており、ベンダーが独自の組織であるからといって、ベンダーロックインの痛みがなくなるわけではありません。プラットフォームサービスの廃止に長年にわたる苦痛を伴う移行が必要な場合は、おそらく設計図に戻って製品を簡素化する必要があります。詳細なカレンダーや多数の代替技術を準備する必要はありませんが、現実的なライフタイム（3～5年）とソリューションを置き換えるためのアーキテクチャ上の境界を考慮に入れることで、設計をよりシンプルでよりデカップリングされたものにすることができます。

プラットフォームの採用は任意であることをお勧めします。これは、2つの方法でプラットフォーム戦略をサポートします。第一に、製品チームがプラットフォームサービスをオプトアウトできる場合、サービスを疎結合に保つことが奨励され、新しい世代のサービスを立ち上げたり、商用オファリングに置き換えたりする際にプラットフォームに役立ちます。第二に、プラットフォーム組織が製品チームによるプラットフォームのメリットの評価に依存している場合、顧客満足を最優先事項として維持する強いプレッシャーがプラットフォーム組織に加わります。プラットフォームへの強制的な移行は、チームの製品思考の規律を長期的に損なうリスクのあるショートカットです。

新しいプラットフォーム機能の成熟度に関する期待値を設定するために、単純な分類システムが役立つ場合があります。たとえば、新しい機能がベータ版であることを示すためです。実験的な機能は、コア機能またはプラットフォームと同じ高い可用性を提供する必要がないため、成熟度分類にSLOとサポートレベルを関連付けることができます。たとえば、24時間体制のサポートは必要ないかもしれません。機能がフルサポートに昇格したら、プラットフォームのユーザーは、ミッションクリティカルなコンポーネントを構築できるほど強力なSLOを期待できますが、それ以前は、より要求の低い期待値を設定することで、プラットフォームチームは、強力な（そして長期的な）コミットメントを行う前に、製品に関する仮定を検証し、実験する自由が得られます。

上記の点を考慮すれば、さらなる利点が得られます。プラットフォームチームは、非常に効果的な製品の小さなポートフォリオを管理します。認知負荷は小さく、焦点は、ライトを点け続けるだけでなく、開発チームの市場投入までの時間を継続的に短縮することに集中できます。

結論

デジタルプラットフォームは、技術製品のポートフォリオです。すべての製品と同様に、プラットフォームは使用を通じて価値を生み出します。適切なビジネス上の正当性、慎重な製品管理、そして効果的な技術実行により、デジタルプラットフォームは製品開発チームの認知負荷を軽減し、組織のイノベーションを加速させることで成功します。プラットフォームには、資金、人材、機会費用という点で多大な投資が必要です。これらの投資は、製品開発チームが顧客向けの製品を迅速かつ効率的に開発する能力にプラスの影響を与えることで回収されます。

デジタルプラットフォームの開発は戦略的な意思決定であり、軽々しく行うべきではありません。直接的な財務上の考慮事項に加えて、デジタルプラットフォームは組織内の関係にも圧力をかけます。製品開発者は、商用クラウドプロバイダーの提供物を経験しており、それらの高まった期待に応えるために、プラットフォームエンジニアリングチームは製品管理と技術実装の両方において成熟している必要があります。また、製品開発チームは、プラットフォーム組織の良いパートナーとなり、サービス運用における責任を分担する必要があります。

デジタルプラットフォームは、戦力倍増効果をもたらすため、競争優位性を開発することと、大きな生産性の阻害要因を導入することの間には微妙な線があります。製品ライフサイクル全体で行う決定によって、どちら側を歩くかが決まります。良いニュースは、他のすべての種類のソフトウェア開発と同様に、小さく始めて、顧客に共感し、成功（と失敗）から学び、全体像を常に念頭に置いていれば、成功する可能性は十分にあるということです。