内部開発者プラットフォームを導入するための 3 ステップのフレームワーク
内部開発者プラットフォーム (IDP) は、デプロイ パイプライン、構成管理、環境のプロビジョニングに伴う負担をなくし、開発者がソフトウェアの提供に集中できるようにします。エンジニアリング マネージャーにとって、まさに求めていたものと言えるでしょう。しかし、内部開発者プラットフォームの必要性を認識することと、実際に導入することは別の問題です。
プラットフォームによってセットアップや保守に必要なリソースのレベルは異なりますが、導入に対して体系的なアプローチをとることで、組織は確実に最高のスタートを切ることができます。適切な内部開発者プラットフォームを選択して、ロールアウトを成功させることで、開発者の時間とリソースを大幅に節約できます。
この記事では、IDP の概念から具体的なアクションへと移行する準備ができているエンジニアリング マネージャー向けに、3 ステップのフレームワークをご紹介します。
次のようなエリアをカバーします。
候補となるベンダーを特定するために、提案依頼書 (RFP) を発行する
選択したツールをロールアウトして導入を行う
成功を測定して、開発者エクスペリエンスの改善を追跡する
内部開発者プラットフォーム向けに RFP を作成する方法
IDP 導入の最初のステップは、提案依頼書 (RFP) を作成することです。RFP とは、組織が内部開発者プラットフォームに何を求めているかを正確に伝えるものです。ベンダーは、ガイド付きデモや無料のソフトウェア トライアルなどを通じて、こうしたニーズをどのように満たせるかを示す提案で回答します。これにより、チームは提案を審査するための明確な評価基準も得られます。
IDP に含むべき要素
RFP で考慮すべき主なエリアは、次の 3 つがあります。
課題: 内部開発者プラットフォームで解決できる、エンジニアリング チームが現在抱えている課題は何ですか? おそらく解決したい主要な課題は、いくつかあることでしょう。
ゴール: 内部開発者プラットフォームを導入することで、どのような成果を出す必要がありますか?
製品要件: こうしたゴールを達成するには、どのような機能や性能が必要ですか?
次に例を示します。
開発者がチームに加入したり異動したりする際にナレッジが失われているのであれば、チームとしてのゴールは開発者のオンボーディングのスピードアップかもしれません。セルフサービス ワークフローやナレッジベースの統合などを通じて、セルフサービスを可能にして、手動で設定を行うようなステップを減らす機能を優先するとよいでしょう。
エンジニアリング組織が拡大しており、より多くのベスト プラクティスや基準に従う必要がある場合は、セキュリティの向上と脆弱性の削減をゴールとすべきかもしれません。セキュリティ プラットフォームとの統合や、スコアカードによるコンプライアンスの監視機能も必要となるでしょう。
エンジニアの生産性を高めて、彼らが最も得意とする作業により多くの時間を費やせるように支援することが難しいと感じている場合は、チームがサービスを迅速に立ち上げられるように、セットアップ時間を短縮すべきでしょう。こうしたケースでは、インフラストラクチャの自動化とテンプレート化が必要です。
現状を把握する
課題をより深く理解して、ゴールを決定するために、組織における開発者エクスペリエンスの現状を評価します。現状をすでに把握していると思い込むのではなく、開発者アンケートの実施、既存のプロセスの監査、開発者フォーカス グループの開催などを行い、改善が必要なエリアを調査します。今後のステップを必ず説明して、IDP の進捗についてチームに随時報告しましょう。
アトラシアンの「開発者エクスペリエンスの現状レポート」によると、所属する組織が開発者エクスペリエンスを優先していると考えている開発者は半数未満であることがわかりました。開発者の 3 人に 2 人が、業務の非効率性によって依然として週に 8 時間以上を無駄にしていることを考えれば、この結果も当然と言えるでしょう。
内部開発者プラットフォームのロールアウト方法
内部開発者プラットフォームを選択したら、コラボレーションでロールアウト プロセスを計画して、導入状況を追跡します。すぐに使える内部開発者プラットフォームは、ロールアウトにおいてチームの各メンバーに求められる労力を削減します。例えば Compass は、適切にセットアップして保守するためにフルスタック エンジニア 4 名を必要とする Backstage のようなオープンソース プラットフォームよりも、必要なエンジニアリング リソースがはるかに少なくて済みます。Compass を使用すると、ソース コード管理ツールを接続してリポジトリをインポートし、わずか 10 分でソフトウェア コンポーネント カタログを構築できます。
運営委員会を結成する
ロールアウトをさらにスムーズに進めるために、数名の主要な関係者で運営委員会を結成します。こうした専門メンバーがサポートの提供やプロセスの監視を行い、必要に応じて調整の判断を下します。
委員会は次のような担当者で構成しましょう。
エグゼクティブ スポンサー: 開発者プラットフォームの取り組みを主導する最上位の責任者です。最高技術責任者、エンジニアリング担当の副社長、プラットフォーム責任者が、この役割に適しています。
影響力のある開発者: 組織全体から影響力のある開発者の小グループを選出し、内部開発者プラットフォームのロールアウト計画の設計を支援してもらうか、少なくとも計画に関する情報を共有するようにします。
プラットフォーム チームまたは DevOps エンジニア: 統合は、内部開発者プラットフォームが価値を提供するための仕組みの鍵となるため、こうしたツールの責任者は、ロールアウトにおける重要なパートナーとなる必要があります。
ポリシーの所有者またはガバナンス チーム: 内部開発者プラットフォームによって、エンジニアリング チームが基準やベスト プラクティスを遵守しやすくなるため、計画時にこうした基準を担当するメンバーと連携すると役立ちます。
ロールアウト スケジュールを作成する
運営委員会を設置したら、内部開発者プラットフォームをロールアウトするためのスケジュールを作成します。新しい内部開発者プラットフォームを使用するすべてのチームに対してスケジュールを伝達し、必要に応じて調整できるように、計画の実現可能性についてさらなるフィードバックを求めましょう。スケジュールを進めながら、定期的に状況を確認して、進捗と導入度を評価し、サポートを提供します。
Compass の使用をすぐに開始できるよう、導入ガイドをご用意しました。
内部開発者プラットフォームの成功を測定する方法
進捗を測定するには、最初に RFP を作成したときに設定したゴールに立ち返ります。内部開発者プラットフォームが目標としていた価値を提供しているかどうかの全体像を示す、定性的ならびに定量的な主要業績指標 (KPI) の両方を策定します。Compass では、カスタム スコアカードを作成して KPI を定義し、エンジニアリング チームが確実に同じ基準を目指せるようにサポートできます。
多くの人は、KPI を「厳密な数値」や「客観的な指標」と考えています。こうした見方は収益や失敗率のような定量的な概念には有効でしょう。しかし、開発者エクスペリエンスは主観的なものであるため、その KPI は、ソフトウェアのデリバリーの体感的な容易さ、体感的な生産性、従業員のエンゲージメントや満足度など、ある程度定性的なものになります。
組織にとって最適な測定基準を見つける
ゴールに応じて、追跡対象となりうる要素の例をいくつかご紹介します。
セキュリティの向上が目標である場合は、四半期ごとに未解決の脆弱性を一定数減らすことを目指すのがおすすめです。
生産性の向上を目指す場合は、インフラストラクチャのプロビジョニングにかかるリード タイムを 5 日から 2 時間に短縮することを KPI として設定できます。
オンボーディングの迅速化が目標である場合は、新しい開発者が生産性を発揮するまでの時間を追跡して、その短縮を目指すことができます。
開発者エクスペリエンスの向上が最も重要である場合は、開発者アンケートでより高い開発者満足度スコアを目指すとよいでしょう。
継続して追跡する
内部開発者プラットフォームの効果が現れるまでには、時間がかかる場合があります。進捗の監視を続け、チームとのチェックインやふりかえりを行い、内部開発者プラットフォームが長期的に期待される成果をもたらしているかどうかを話し合いましょう。
チームのふりかえりは、うまくいっていることとそうでないことについて振り返る機会を開発者やリーダーに提供します。Atlassian Team Playbook のふりかえりプレイでは、基本的なふりかえりの手順やテンプレートのほか、特定の状況に応じたバリエーションをご確認いただけます。