内部プラットフォームが誰も使いたがらないプロジェクトになってしまう理由
ローンチから数ヶ月後、不満の声が聞こえ始める。「パイプラインが硬直的すぎる」「必要なデータベースアクセス権限が得られない」「ステージング環境が本番と一致しない」。プラットフォームを構築したチームはフラストレーションを感じる。ドキュメントはすべて整えた。標準パイプラインも提供した。仕事は完了したと思っていた。しかしプロダクトチームは回避策を見つけ、独自のスクリプトを作り、静かにプラットフォームから離れていく。
このパターンは組織を問わず繰り返される。プラットフォームチームは何かを構築し、完成を宣言し、次に進む。プラットフォームは進化を必要とするプロダクトとしてではなく、納期のあるプロジェクトとして扱われた。結果は、誰も実際には使わない高価なインフラストラクチャである。
プロジェクト思考の罠
プラットフォームがプロジェクトとして扱われると、チームは単一のマイルストーン、つまりローンチ日に向けて作業する。ポータルを設計し、標準パイプラインを設定し、ドキュメントを書き、作業は完了したと見なす。プラットフォームが存在すれば、チームが採用し、すべてがスムーズに進むという前提がある。
その前提はほぼ常に間違っている。
開発者のニーズはプロジェクトの進化とともに変化する。当初は基本的なビルド＆デプロイパイプラインしか必要としなかったチームも、やがて本番をミラーリングしたステージング環境が必要になる。データベースマイグレーションを実行したり、監視ツールと統合したり、特定のサービスにアクセスしたりする必要が出てくる。プラットフォームがこれらの変化するニーズに適応できなければ、開発者は自分たちで問題を解決する。独自のパイプラインを作り、独自の環境をプロビジョニングし、プラットフォームを完全にバイパスする。プラットフォーム構築への投資は無駄な努力になる。
プラットフォームを内部プロダクトとして扱う
代わりとなるアプローチは、プラットフォームをプロジェクトではなくプロダクトとして扱うことだ。これは、プラットフォームチームが外部顧客にサービスを提供するプロダクトチームと同じように機能することを意味する。ただし、顧客は同じ組織内の開発者である。
プロダクトチームは仮定に基づいて機能を構築しない。ユーザーと話し、データを収集し、フィードバックに基づいて反復する。プラットフォームチームも同じことをする必要がある。何が開発者を遅らせているのかを理解する必要がある。開発プロセスのどの部分が最も痛みを引き起こしているか？ どのパイプラインが最も頻繁に失敗し、その理由は？ どの環境が最も摩擦を生んでいるか？
このプロダクト思考は、プラットフォームチームの働き方を変える。開発者が必要だと思うものに基づいて機能を構築する代わりに、会話とデータに基づいて意思決定を行う。採用率を測定する。実際に標準パイプラインを使用しているチームはいくつか？ コミットからデプロイまでどのくらいの時間がかかるか？ チームがプラットフォームの使用を拒否した場合、プラットフォームチームは彼らを責めない。プラットフォーム体験に何が欠けているか、何が壊れているかを調査する。
プロダクト思考が実際にどのように見えるか
プロダクト思考を持つプラットフォームチームは、いくつかの点で異なる行動をとる。
開発者からのフィードバックに基づいて改善のバックログを維持する。自分たちのアイデアだけではない。最も多くのチームにとって最も摩擦を取り除く作業を優先する。プロダクトチームと同様にサイクルでアップデートをリリースし、各変更が実際に役立っているかを測定する。
また、プラットフォームの最初のバージョンが完璧ではないことを受け入れる。初期のパイプラインテンプレートは硬直的すぎるかもしれない。ドキュメントは重要なエッジケースを見逃しているかもしれない。オンボーディングプロセスは混乱を招くかもしれない。これらは失敗ではない。プラットフォームに反復が必要であるというシグナルである。重要なのは、そのフィードバックを収集し、それに基づいて行動するメカニズムを持つことである。
難しい部分：組織の考え方を変える
プロジェクト思考からプロダクト思考への転換は容易ではない。特に、内部ツールを常にインフラストラクチャプロジェクトとして扱ってきた組織では難しい。インフラストラクチャプロジェクトには固定されたスコープと納期がある。プロダクトには継続的な開発サイクルと進化する要件がある。
この転換には、プラットフォームチームが自分の役割について考え方を変える必要がある。彼らは完成したシステムを納品するビルダーではない。彼らは開発者体験を継続的に改善するサービスプロバイダーである。彼らの成功は、プラットフォームがいくつの機能を持っているかではなく、開発者がどれだけ価値を提供できるかによって測定される。
また、組織のサポートも必要である。プラットフォームチームは、調査、フィードバック収集、反復に時間を費やす許可を得る必要がある。ポータルを予定通りに出荷したかどうかだけでなく、開発者のベロシティやプラットフォーム採用率などの成果に基づいて評価される必要がある。
プラットフォームが適応に失敗するとき
プロダクト思考がなければ、プラットフォームはボトルネックになる。開発者は、特定のニーズに合わない硬直的なプロセスに制約されていると感じる。彼らはプラットフォームを回避し始め、チーム間で一貫性が失われる。あるチームは標準パイプラインを使用し、別のチームはカスタムスクリプトを使用し、さらに別のチームは自動化をまったく使用しない。プラットフォームが削減するはずだった認知負荷は実際には増加する。なぜなら、開発者はプラットフォームと回避策の両方を学ばなければならないからだ。
最悪の結果は、プラットフォームチームがツールを採用しない開発者を責めることだ。「作ったのに、なぜ使ってくれないのか？」 答えは通常シンプルだ。プラットフォームが彼らの実際の問題を解決していないのだ。プラットフォームチームは、実際に必要とされていたものではなく、自分たちが必要だと思ったものを構築した。
プラットフォームチームのための実践的なチェックリスト
内部プラットフォームを構築または維持している場合、自分自身をチェックするための短いチェックリストを以下に示す。
- どのチームがプラットフォームを使用し、どのチームが避けているかを把握しているか？
- 開発者がプラットフォームを使用する際の上位3つの摩擦点を挙げられるか？
- ユーザーとの定期的なフィードバックサイクルを持っているか？ 単なる提案箱ではない。
- アップタイムや機能数だけでなく、採用率や開発者ベロシティを測定しているか？
- ユーザーへの影響に基づいて改善を優先するバックログを持っているか？
- チームがプラットフォームを回避したとき、その理由を調査するか、それとも彼らを責めるか？
これらのほとんどに「はい」と答えられないなら、おそらくプロジェクトを運営しており、プロダクトを運営していない。
まとめ
ユーザーとともに進化しないプラットフォームは放棄される。プラットフォームを内部プロダクトとして扱うことは、作業が決して完了しないことを受け入れることを意味する。プラットフォームチームの仕事は、開発者の摩擦を継続的に減らし、変化するニーズに対応し、自分の変更が実際に役立っているかを測定することである。プラットフォームチームが作業の完了を宣言した瞬間が、プラットフォームが死に始める瞬間である。