HEART フレームワークによるデベロッパー エクスペリエンスの測定: プラットフォーム エンジニア向けガイド

※この投稿は米国時間 2024 年 10 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

端的に言うと、開発者の仕事はソフトウェアの構築、テスト、デプロイ、保守です。しかし、多くのことと同様に、重要なのは結果ではなく過程です。

プラットフォーム エンジニアの間では、その過程をデベロッパー エクスペリエンス（DX）と呼ぶことがあります。これは、ソフトウェアの構築、テスト、デプロイ、保守のプロセスを通じて使用するサービスとツールを開発者がどのように感じ、利用しているかを示すものです。

DX を優先することは必須です。開発者の不満が蓄積すると、効率が低下し、人材が流出するだけでなく、シャドー IT が発生します。逆に、優れた DX は、イノベーションの促進、コミュニティの強化、生産性の向上につながります。ポジティブな DX を実現するには、その現状を測定する必要があります。

私は PlatformCon 2024 で、「Improving your developers' platform experience by applying Google frameworks and methods」（Google のフレームワークとメソッドの適用による開発者のプラットフォーム エクスペリエンスの改善）と題した講演を行い、実用的なデータによって組織の DX を総合的に把握できる Google の HEART フレームワークについてお話ししました。

この記事では、組織の DX をより包括的に把握するために、プラットフォーム エンジニアリングのプラクティスに HEART フレームワークを適用する方法についてのアイデアをご紹介します。ただしその前に、HEART フレームワークとは何かを説明させてください。

HEART フレームワーク: 概要

簡単に言うと、HEART は、目標達成への進捗状況を追跡する特定の指標を定義することで、プラットフォームを使用している間の開発者の行動と態度を測定し、測定値の背後にある実情を明らかにします。プラットフォーム エンジニアリングの過程では、フィードバックによる継続的な改善が重要な要素であるため、このフレームワークは有効であり、プラットフォーム チームとアプリケーション プロダクト チームの双方がデータドリブンかつユーザー中心の意思決定を行うのに役立ちます。

ただし、HEART 自体はデータ収集ツールではありません。重点を置くべき適切な指標をプロダクトやプラットフォームの目的に基づいて選択するための、ユーザー感情の分析フレームワークです。このフレームワークでは、アクティブなポータル ユーザー数などの定量的または実証的なデータと、「ユーザーはポータルのナビゲーションがわかりにくいと感じている」のような定性的または主観的な分析情報をバランス良く取り入れます。言い換えれば、HEART は特定のツールやアセスメントではなく、ユーザー エクスペリエンスを評価するためのフレームワークまたは方法論と考えることができます。つまりこれは、どのように測定するかではなく、何を測定するかを決定するのに役立ちます。

これらの各要素を詳しく見てみましょう。

Happiness（満足度）: プロダクトを使用しているユーザーの実際の満足度

ハイライト: 開発者のフィードバックの収集と分析

主観的指標:

• アンケート: 定期的なアンケートを実施して、全体的な満足度、使いやすさ、課題に関するフィードバックを収集します。トイルがあると、開発者の満足度と士気が低下します。反復的な手作業は、不満が原因の燃え尽き症候群や、プラットフォームの満足度低下の原因となる可能性があります。

• フィードバック メカニズム: ネット プロモーター スコア（NPS）や顧客満足度調査（CSAT）などを利用して、プラットフォームの特定の機能や領域について開発者がフィードバックを直接提供しやすくします。

• インタビューやユーザー グループを通じて、開発者から自由回答式のフィードバックを収集します。

• 感情分析: フィードバック チャネル、サポート チケット、オンライン コミュニティで表明された開発者の感情を分析します。

システム指標:

• 機能リクエスト: 開発者から提出された機能リクエストの数と種類を追跡します。これにより、開発者のニーズや要望を把握して、満足度の向上につながる改善に優先的に取り組むことができます。

注意点: プラットフォームが開発者の生産性を高めることができても、それが必ずしも仕事の満足度向上につながるとは限りません。特に、調査から開発者が不満を抱いていることが伺える場合は、原因の究明が必要です。

Engagement（エンゲージメント）: プラットフォームを利用する開発者の幅広さとその際のエクスペリエンスの質

ハイライト: プラットフォーム エンジニアと開発者の連携の頻度と質（プラットフォームでのインタラクションの強度と質、チャット チャネルへの参加、トレーニング、ゴールデンパスの共有、共同でのトラブルシューティング、アーキテクチャの設計に関するディスカッションへの参加、新規採用者からシニア開発者までを含むすべての開発者によるインタラクションの幅広さ）

主観的指標:

• 連携の質に関するアンケート - チャット チャネル、トレーニング、ゴールデンパスの共有、共同でのトラブルシューティング、アーキテクチャの設計に関するディスカッションなど、連携の深さと種類に焦点を当てます。

• トイルが増えると、プラットフォームでの開発者エンゲージメントが低下する可能性があります。単調なタスクに過剰な時間を費やしている開発者は、新しい機能を探求し、テストを行い、プラットフォームの進化に貢献できる可能性が低くなります。

システム指標:

• アクティブ ユーザー数: 日、週、月単位のアクティブな開発者数と、開発者がタスクに費やした時間を追跡します。

• 使用パターン: 最もよく使用されているプラットフォーム機能、ツール、ポータル リソースを分析します。

• プラットフォーム エンジニアと開発者の連携の頻度。

• ユーザー エンゲージメントの幅広さ: 新規採用者が十分なスキルを身に付けるまでのオンボーディング時間を追跡し、ゴールデンパスやポータル機能に積極的に貢献しているシニア開発者の割合を測定します。

注意点: エンゲージメントと満足度を混同しないでください。開発者がアンケートでプラットフォームを高く評価していても、使用状況データを見ると、コア機能の利用頻度が低いことや、プラットフォームを積極的に使用しているチームが限られていることが明らかになる場合があります。開発者に「プラットフォームに満足していますか？」ではなく「プラットフォームによって毎日のワークフローはどのように変化しましたか？」と質問してみましょう。

Adoption（採用率）: プラットフォームの拡大率と開発者による機能の採用率

ハイライト: プラットフォームの全体的な受け入れと開発ワークフローへの統合

システム指標:

• 新規ユーザー登録数: プラットフォームの使用を開始する開発者の増加率をモニタリングします。

• 登録からプラットフォームの使用（ゴールデンパス、ツール、ポータル機能の実行）までの時間を追跡します。

• ポータル経由で認証され、ゴールデンパス、ツール、ポータル機能を使用したアクティブ ユーザーの数（週、月、四半期、半年、年ごと）。

• 機能の採用率: 新しい機能やアップデートの普及のスピードと広がりを追跡します。

• プラットフォームから CI / CD を使用している開発者の割合。

• ユーザー、チーム、日、週、月ごとのデプロイ数（単位は基本的に自由選択可能）。

• トレーニング: トレーニング実施後の採用率の変化を評価します。

注意点: 採用率の「ロングテール」を見落とさないようにしましょう。プラットフォームの採用率は、初期段階では急速に増加しても、プラットフォームが進化を続けられず開発者のニーズの変化に対応できなければ、頭打ちになったり低下したりする可能性があります。初期の採用率を測定するだけでなく、数週間、数か月、数年単位での使用状況の変化をモニタリングしましょう。

Retention（定着）: プラットフォームに対する開発者の支持

ハイライト: 長期的なエンゲージメントと離脱の削減

主観的指標:

• 12 か月以上休眠状態のユーザーに対して、離脱者向けアンケートを実施します。

システム指標:

• 離脱率: ポータルにログインしなくなり、使用をやめた開発者の割合を追跡します。

• 休眠ユーザー数: 6 か月後に非アクティブになった開発者を特定して、その理由を調査します。

• 使用頻度の低いサービスを追跡します。

注意点: 離脱理由を正確に特定しましょう。開発者がプラットフォームの使用を中止（離脱）した場合、その理由を把握することが重要です。原因を見誤ると、無駄な作業が発生し、改善の機会を逃す可能性があります。プラットフォーム外の要因を考慮に含めましょう。プロジェクト要件、チーム構造、業界の動向の変化も、離脱の原因になる可能性があります。

Task success（タスクの成功）: 開発者が特定のタスクを完了できる可能性

ハイライト: 開発者の特定のアクティビティに対するプラットフォームのサポートの効率性と有効性

主観的指標:

• アンケートを通じて、継続的に発生しているトイルと、開発者の生産性に対するその悪影響を評価します。トイルがあると結果的に効率が低下し、タスクの完了に要する時間が増えます。

システム指標:

• 完了率: プラットフォーム上でエラーなく正常に実行されたゴールデンパスとツールの割合を測定します。

• ゴールデンパス、ポータル、ツールを使用したタスク完了までの所要時間。

• エラー率: ゴールデンパス、ポータル、ツールのログファイルやモニタリング ダッシュボードから、開発者が遭遇する一般的なエラーや障害を追跡します。

• 平均修復時間（MTTR）: エラーが発生した場合に、その解決にかかる時間です。MTTR が短いほど、プラットフォームの復元力が高く、障害から迅速に復旧できることを示します。

• 開発者プラットフォームとポータルの稼働時間: 開発者プラットフォームとポータルが利用可能で稼働している時間の割合を測定します。稼働時間が長いほど、開発者はプラットフォームに確実にアクセスしてタスクを完了できます。

注意点: タスク成功とタスク完了を混同しないでください。開発者がプラットフォーム上でタスクを完了できるかどうかを測定するだけでは、必ずしも真の成功を測定できません。表面上は最終的な目標が達成されていても、その過程では次善策に頼ったり、非効率的な方法でタスクを完了したりしている場合があります。開発者のワークフローを自然な環境において直に観察し、ワークフローの課題や問題の生じやすい部分を特定することが有効な場合があります。

また、タスクの成功がビジネス上の目標と地続きであるかどうかにもご注意ください。タスクの完了をあまりに重視すると、ビジネス目標への幅広い影響を見落としてしまうことがあります。開発者がプラットフォーム上でタスクを効率的に完了できても、それらのタスクがビジネス全体の目標達成につながらないのであれば、プラットフォームの真の価値は証明されません。

プラットフォーム エンジニアリングへの HEART フレームワークの適用

これらすべてのカテゴリを毎回使用する必要はありません。考慮すべきカテゴリの数は、評価の具体的な目標とコンテキストによって異なります。すべてを考慮することも、目標に応じてカテゴリを絞り込むこともできます。次に例を示します。

• 新規開発者のオンボーディングの改善: 採用率、タスクの成功、満足度に焦点を絞ります。

• 新機能のリリース: 採用率と満足度に焦点を絞ります。

• プラットフォームの使用率向上: エンゲージメント、定着、タスクの成功を追跡します。

1 つのカテゴリのみに頼ると、全体像を把握できない可能性が高いのでご注意ください。

このフレームワークを使用すべきタイミング

理想的には、プラットフォームのリリースから数か月後に HEART フレームワークを使用してベースライン評価を行い、初期の DX に関する価値ある分析情報を入手します。プラットフォームが進化するにつれて、この初期データは進捗の測定と傾向の特定に役立つベンチマークになります。早期に測定を行うことで、UX の問題への事前対処、データに基づく設計上の意思決定、迅速なイテレーションによる機能の最適化と開発者の満足度向上が可能になります。MVP、つまり実用に耐える最小限の状態から開始する場合、コア機能が確立され、フィードバックを提供する小規模な初期ユーザー グループができたタイミングでベースライン評価を実施します。

使用期間が 12 か月を過ぎたら、新しいプラットフォームやより成熟したプラットフォームを具現化するための指標を追加することもできます。これにより、プラットフォームの実際の使われ方を把握して DX に対する理解を深めたり、プラットフォームに加えた変更が及ぼす影響を測定したり、改善すべき領域を特定してその後の開発作業に優先順位を付けたりすることができます。新しいゴールデンパスやツールを追加したか、機能を強化した場合は、それらの成功と開発者の行動への影響を測定する指標を追跡する必要があります。

HEART 指標の評価頻度は、以下を含む複数の要因によって決まります。

• プラットフォームの成熟度: 新しいプラットフォームほど、進捗の追跡や早期の問題への対処を目的として、レビューの頻度を（1 か月ごとや四半期ごとなどに）高くするメリットが大きくなります。プラットフォームが成熟するにつれて、HEART 評価の頻度を（半年ごとや 1 年ごとなどに）低くすることができます。

• 変化率: 更新や変更がプラスに働くようにするには、プラットフォームのメジャー アップデート、新しいポータル機能やゴールデンパスの導入、ユーザー行動の変化などにより、プラットフォームが急速に進化している時期に、HEART フレームワークをより頻繁に適用しましょう。そうすることで、それぞれの変更が主な指標に及ぼす影響を綿密にモニタリングできます。

• プラットフォームの規模と複雑さ: 規模が大きく、複雑なプラットフォームほど、細かな点や潜在的な問題を把握するために、より頻繁な評価が必要になります。

• チームのキャパシティ: HEART 評価を実行するには時間とリソースが必要です。チームが対応できる作業量を考慮して、頻度を適宜調整しましょう。

HEART フレームワークに基づく（四半期ごとや半年ごとなどの）定期的な詳細評価をスケジュールし、プラットフォームのパフォーマンスをより深く理解して、改善すべき領域を特定しましょう。

プラットフォーム エンジニアリングへの理解を深める

このブログ投稿では、HEART フレームワークをプラットフォーム エンジニアリングに適用して、DX を測定および改善する方法をご紹介しました。そして、このフレームワークの 5 つの主要な要素（満足度、エンゲージメント、採用率、定着、タスクの成功）について考察し、各要素に固有の指標と、適用のタイミングを説明しました。こうした分析情報を活用することで、プラットフォーム エンジニアリング チームは開発者にとってよりポジティブで生産性の高い環境を構築できるため、ソフトウェア開発作業の成功が促進されます。プラットフォーム エンジニアリングについてさらに理解を深めたい方には、Google Cloud の他の投稿、「プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体何なのか」、「プラットフォーム エンジニアリングにまつわる、さらなる 5 つの誤解」、「プラットフォーム エンジニアリングのキャリアを積むための基盤づくり」などをおすすめします。

プラットフォーム エンジニアリングのセクションが追加された DORA Report 2024 もぜひご確認ください。

-アプリケーション プラットフォーム担当 EMEA プラクティス ソリューション リード Darren Evans