内部開発者プラットフォームの測定と進化の方法

内部開発者プラットフォームを立ち上げて数ヶ月後、気になる兆候に気づくかもしれません。採用数が頭打ちになっている。チームは依然として手動でパイプラインを構築している。新しいサービスはテンプレートを使わずに古いリポジトリをコピーして作成されている。せっかく作ったポータルはほとんど使われていない。

これはよくある話です。プラットフォームを構築するのは難しいですが、それを維持し続けるのはさらに困難です。測定も進化もされないプラットフォームは、やがて使われなくなります。開発者は以前のやり方に戻り、プラットフォームへの投資は無駄になります。

採用率から始める、しかしそこで止まらない

最も明白な指標は採用率です。デフォルトのパイプラインを利用しているチームはいくつか？ポータルのテンプレートを通じて作成された新しいサービスはどれくらいか？採用率が低いということは何かが間違っていることを示していますが、何が間違っているかまでは教えてくれません。

プラットフォームが悪いと結論づける前に、チームと話をしましょう。使い方がわからないのかもしれません。ドキュメントが不明瞭なのかもしれません。テンプレートが彼らのユースケースに対して硬直的すぎるのかもしれません。あるいは、すでに自分たちにとってよりうまく機能する独自のセットアップを持っているのかもしれません。

採用率はシグナルであり、診断ではありません。それを会話のきっかけとして使い、前提を持って判断しないようにしましょう。

開発者の待機時間を測定する

プラットフォームは摩擦を減らすために存在します。摩擦を測定する最良の方法は、開発者が何かを待つ時間を調べることです。

以下の待機時間を考えてみてください：

• 新しいサービスをゼロから開発環境として使える状態にするまでにどれくらい時間がかかるか？
• プルリクエストがマージされてからコードが本番環境に到達するまでにどれくらい時間がかかるか？
• 手動承認を待つためにどれくらいの時間が費やされているか？
• テスト環境が準備できていないために開発者が待つことはどれくらいあるか？

優れたプラットフォームは、これらの待機時間を大幅に短縮するはずです。開発者が開発環境を待つために数日も費やしているなら、プラットフォームは正しい問題を解決していません。

実際に機能するフィードバックループを作成する

プラットフォームチームには、開発者が問題を報告したり、改善点を提案したり、単に不満を言ったりするための明確なチャネルが必要です。これは、社内フォーラム、定期的なアンケート、プラットフォームチームとプロダクトチーム間の定期的な議論などが考えられます。

重要なのはフィードバックの量ではありません。それにどう対応するかです。開発者がSpring Bootテンプレートに標準的なロギング設定が欠けていると報告したら、すぐに修正しましょう。そのような報告が無視されれば、開発者は信頼を失い、再び独自のソリューションを構築し始めます。

フィードバックループは、目に見える変化につながったときに機能します。開発者は自分の意見が重要であると実感する必要があります。

データとリクエストに基づいて進化させる

採用データ、待機時間の測定結果、フィードバックが揃ったら、意図的にプラットフォームを進化させ始めることができます。

例えば、複数のチームがゴールデンパスにまだ含まれていないプログラミング言語のサポートを要求するかもしれません。そのリクエストを評価します：

• これは1つのチームからのものか、それとも複数のチームからのものか？
• その言語は安定しており、本番環境で安全に使用できるか？
• プラットフォームチームは過剰に負担をかけずにサポートできるか？

これらの答えが肯定的であれば、その言語をオプションとして追加します。全員に強制する必要はありませんが、必要な人が使えるようにします。

別の例：開発者が、コミットのたびにすべてのテストを実行するためパイプラインが遅すぎると不満を言う場合があります。プラットフォームチームは、よりスマートなテスト選択を導入し、変更されたコードに関連するテストのみを実行することで対応できます。

ガードレールを時間の経過とともに調整する

プラットフォームは通常、厳格なガードレールから始まります。すべてのデプロイにプラットフォームチームの手動承認が必要かもしれません。数ヶ月後、プロダクトチームが成熟し、めったにミスをしなくなったことに気づくかもしれません。ガードレールは緩和できます。すべてのセキュリティチェックが通過すれば、手動承認は自動承認に変わります。

一方、開発者がルールを回避したためにインシデントが増加した場合は、ガードレールを再び強化します。

ガードレールはプラットフォームを使用するチームの成熟度に合わせるべきです。それらは永続的なルールではありません。組織が学習するにつれて進化する調整可能な境界です。

測定しないとどうなるか

測定も変更もされないプラットフォームは時代遅れになります。開発者はそれを使わなくなります。回避策を見つけます。独自のスクリプトやツールを構築します。プラットフォームは誰もが無視する放棄されたプロジェクトになります。

プラットフォームチームは常に問い続けなければなりません：

• プラットフォームはまだ実際の問題を解決しているか？
• 開発者はまだ助けられているか？
• 答えが不確かに感じられ始めたら、評価と調整の時です。

プラットフォーム進化のための実践的チェックリスト

• パイプラインとテンプレートの採用率を毎月追跡する
• プルリクエストマージから本番デプロイまでの時間を測定する
• 四半期ごとに開発者満足度調査を実施する
• プラットフォームチームとプロダクトチーム間で毎月フィードバックセッションを開催する
• 3ヶ月ごとにガードレールを見直し、インシデントデータに基づいて調整する
• すべての機能リクエストを記録し、チーム横断的な需要を確認する
• 未使用のプラットフォーム機能を削除してメンテナンス負荷を軽減する

まとめ

プラットフォームは一度構築して終わりではありません。継続的な注意を必要とするプロダクトです。採用率を測定し、待機時間を短縮し、フィードバックに耳を傾け、チームの成熟度に合わせてガードレールを調整しましょう。プラットフォームを生きたプロダクトとして扱うとき、開発者は実際にそれを使いたいと思うようになります。