platform-infrastructure について
社内プラットフォームや共有インフラを設計するプロダクト・エンジニアリングリーダー向けのガイドスキルです。利用者の課題、導入、拡張性のある基盤、プラットフォームの価値を左右する運用上の判断を扱います。
主な機能
- 01プラットフォームの目的と準備状況の評価
- 02効果の大きいインフラ投資の特定
- 03開発者の導入を重視した設計
- 04インフラ拡張の事前計画
- 05構造化コンテンツの発見性向上
活用シーン
- 01プラットフォーム構築前の開発者課題の特定
- 02導入に向けた組織の準備状況とガバナンスの評価
- 03利用が上限に達する前のインフラ整備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/platform-infrastructureを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
プラットフォームインフラストラクチャ
5 人のプロダクトおよびエンジニアリングのリーダーから得た知見を活用し、社内プラットフォームと共有技術インフラストラクチャの設計と拡張をユーザーに支援します。
支援の方法
ユーザーからプラットフォームインフラストラクチャについて相談された場合：
- プラットフォームの目的を理解する - 社内開発者、外部パートナー、またはその両方のために構築するのかを尋ねます
- 組織の準備状況を評価する - プラットフォームを支えるための導入体制とガバナンス体制が整っているかを確認します
- 効果を高めるポイントを特定する - プラットフォームへの投資によって、どこで最も大きな価値の増幅が得られるかを見つけられるよう支援します
- 導入されやすい設計にする - 理論上の問題ではなく、実際の開発者の問題をプラットフォームが解決できるようにします
基本原則
共通の機能を共有インフラストラクチャに抽象化する
Daniel Lereya：「私たちは初めて立ち止まり、『列はどんなものか』と考えました。そして、すべてのプロダクトアーキテクチャもそれを中心に整理し……新しい列を追加する作業は、具体的なことだけを考えればよくなりました。」機能開発の速度を高めるには、繰り返し使うコンポーネントを共有インフラストラクチャに抽象化し、開発者が固有のロジックだけに集中できるようにする必要があります。
目に見えないインフラストラクチャが最も重要なことも多い
Asha Sharma：「何百もの機能が重要だったのではなく、すべてはインフラストラクチャとプラットフォームにありました……パフォーマンス、信頼性、プライバシー、安全性、そのすべてです。」主要なプラットフォームの成功は、目に見える機能よりも、信頼性や速度などの「目に見えない」品質に左右されることがよくあります。
必要になる前に拡張を計画する
Ivan Zhao：「COVID の最中、インフラストラクチャをまったく拡張できませんでした。長い間、Simon は時期尚早な最適化を避けるのがとても得意でした……Postgres の最大インスタンスさえ使い切っていました。」時期尚早な最適化を避けるのはよいことですが、利用が急増した際の「破滅的な」事態を避けるため、インフラストラクチャは十分に先を見越して計画する必要があります。
アーキテクチャに発見しやすさを組み込む
Eli Schwartz：「健康に関するすべての質問はこれだと言えるように、カテゴリ分けされたサイトマップを作成し、サイトマップから……検索エンジンがサイト全体を巡回できるようにすれば、すべての質問と回答が見つけられるようになります。」大規模なプラットフォームでは、HTML サイトマップや内部リンクなどの構造上の決定が、検索エンジンからの発見しやすさにとって重要です。
サーバーサイドでのトラッキングをデフォルトにする
Vijay：「最大の間違いは、クライアントサイド SDK を使って分析を設定することです……クライアントではなく、サーバーからイベントのトラッキングを始めてください。」データの信頼性、プラットフォーム間の一貫性、開発者によるメンテナンスの面で、サーバーサイドのトラッキングはクライアントサイド SDK より優れています。
ユーザーを支援するための質問
- 「このプラットフォームの『ユーザー』は誰で、現在どのような問題を解決しようとしていますか？」
- 「生産性を最も損なっている、現在の開発者エクスペリエンス上の課題は何ですか？」
- 「このプラットフォームが実際に導入されているかどうかを、どのように測定しますか？」
- 「これは内製か購入かの判断ですか。それとも、今は手作業のままにすべきですか？」
- 「現在のインフラストラクチャが限界に達するのはいつですか。いわば『破滅までの時計』はどのくらいですか？」
注意すべきよくある間違い
- 抽象的な未来に向けた構築 - 現在の開発者の課題ではなく、予測されるニーズに基づいて機能を作ること
- プロダクトオーナーシップのないプラットフォーム - 専任のプロダクトマネジメントを置かず、インフラストラクチャを技術プロジェクトとして扱うこと
- 手遅れになるまで時期尚早な最適化を避ける - インフラストラクチャの限界を監視せず、障害が起きる前に拡張プロジェクトを始められないこと
- デフォルトでクライアントサイドトラッキングを使う - サーバーサイドのイベントトラッキングではなく、ブラウザー SDK を使用すること
- 移行コストを無視する - 既存のソリューションからチームを移行する労力を考慮せず、新しいプラットフォームを構築すること
詳細
5 人のゲストから得た 6 つすべての知見については、references/guest-insights.md を参照してください。
関連スキル
- platform-strategy
- product-operations
- scoping-cutting