DevExフレームワークを活用したDX測定ツール導入の軌跡と展望
こんにちは、プログリットのエンジニアKokiです。
普段はスピフルでリードエンジニアとしてフロントエンド、サーバーサイド、AIアプリケーションの開発をしています。
今回はDX測定ツールを導入した話をしたいと思います。
※カバー写真：UnsplashのGary Bendigが撮影した写真
導入した背景
スピフルで得たDevExへの挑戦の記事で迅速に開発していく為に細かいチップスを紹介しましたように、スピフルでは一定のスピード感を持って開発が出来ていました。 2023年12月に正式リリースしてからも加速するかと思いきや、そうでも無く何処となくコンフォートゾーンに陥っている気がしていました。 スピフルチームでは、月1回の定期振り返り会を行っていますが、そこではあまり定量的な開発効率をKPIとして追っておらず、定性的な観点をメインで振り返りを行っていました。
月1回の振り返りを通じて、チーム内のGoodポイントやDevelopmentポイントを共有していましたが、課題や改善の余地を見つけるのが困難で定性的な振り返りだけではチームの成長に限界があると感じていました。
また、スピフルチームではリリース頻度を高めた成功事例を他のプロダクトチームでも広めたいと考えていましたが、リリースサイクルを短くすることはそう簡単に出来るものではなく潜在的な課題がいくつもあるのを感じていました。
今までの取り組み
スピフルチームではまず、月ごとにイシュー消化数を数値化する取り組みを始めました。しかし、イシューごとにボリューム感が異なり、数値化されたデータは信頼性が低下し、形骸化し定着には至りませんでした。
DevExフレームワークを選んだ理由
どのイシューでも一定のボリューム感になるように、Googleが提唱するFour Keysメトリクスを試してみることにしました。このメトリクスは、デプロイ頻度やリードタイム、変更失敗率、回復時間の4つの指標を用いて、開発パフォーマンスを評価します。特に、デプロイ頻度の向上は、プロダクトチーム全体にとって重要な目標であるため、スピフルチーム以外のiOSチーム、サーバーチームなどのメンバーにも協力してもらい、定量的なデータを収集しました。
しかし、Four Keysメトリクスを試行していく中で、別の課題が見えてきました。定量的なデータだけでは、チームが直面している本質的な課題や開発プロセスの改善点を十分に捉えることが難しいということです。たとえば、仕様変更による手戻りや他のチームとの調整に時間がかかる点、リリースサイクルの遅れなど、開発の流れに影響を与える要因は、単に数値では表しきれない部分が多くありました。さらに、メトリクスの結果に基づいたディスカッションでは、数値化されることでかえってモチベーションが低下するという意見もありました。
このような背景から、Four Keysの指標だけでは限界があると感じ、より広範な視点でエンジニアの体験や満足度を捉える必要があると考え始めました。その際に注目したのが、Nicole Forsgren氏らが提唱したSPACEフレームワークです。このフレームワークは、エンジニアの幸福度や認知負荷、そしてフィードバックループの速さなど、より人的要因を重視している点が魅力的でした。
具体的には、次の3つのポイントがSPACEフレームワークを参考する決め手となりました。
エンジニアの幸福度や満足度が生産性に直結している
SPACEフレームワークは、エンジニアが自分の仕事にどれだけ満足しているか、どれだけ幸せに感じているかを重視します。これらの要素が、生産性と密接に関連していることが、様々な研究で示されています。
生産性の向上が直接的に顧客への価値提供に繋がるわけではない
Four Keysメトリクスは生産性の向上に焦点を当てていますが、SPACEフレームワークでは、エンジニアの活動がお客様へのアウトカムにどれだけ寄与しているかも重要視しています。
組織ごとに異なる指標が必要である
すべての開発チームが同じメトリクスで測定されるわけではなく、それぞれの組織に最適な指標を設定する必要があります。SPACEフレームワークは、この柔軟性を持っている点が非常に魅力的でした。
これらの理由から、Four Keysに加えて、エンジニアの体験を包括的に評価できるSPACEフレームワークをベースにすることを決めました。これによって、定量的な指標だけでなく、エンジニアの内面的な満足度やストレスの要因を可視化し、より効果的な改善活動が可能になると考えています。
では、エンジニアが満足度やアウトカム、組織ごとの指標をどうやって決めていくのが良いでしょうか？
SPACEフレームワークでも測定するメトリクスを紹介されていますが、今回はより新しくアップデートされた、DevExフレームワークに注目することにしました。
DevExフレームワークとは
DevExフレームワークはSPACEフレームワークと同じNicole Forsgren氏と後述のDevExサービスのDXツールのCEOである Abi Noda氏が作り上げたものになります。
DevExは、21人の6ヶ月〜20年以上の開発経験のあるエンジニアにインタビューを行い、ソフトウェアを構築するときの作業のしやすさなどを聞き、コードの健全性についての持論や開発環境、小さくリリース出来る環境など、Experienceに関する要因を洗い出したのが元となっています。
※インタビューの内容はこちらの論文にまとめられているので、興味ある方は御覧ください。
これらインタビューを元に３つの軸にまとめたものがこちらの図になり解説すると
Feedback Loops
誰か（PRレビューなど）や何か（CIでの実行時間）を待つ時間が長くなると、一時中断して他タスクにスイッチしたりとフラストレーションが生まれす。慣れた作業でも思いの外、時間がかかったりします。
Cognitive Load（認知負荷）
複雑な仕様や慣れない開発環境への理解は精神的に疲れます。特に古参メンバーよりも新メンバーに負荷がよりかかりやすいので、声を上げやすい環境が大切になります。
Flow State
エネルギーに満ちた集中力、完全な没入感、そして楽しさに完全に浸っている精神状態で、エンジニアが幸せを感じる所ではないでしょうか。
Feedback Loops、Cognitive Load、Flow Stateを総合すると、開発者が遭遇するあらゆる種類の摩擦が要約されます。DevEx は複雑で微妙な問題なため、単一の軸だけでなく複数の軸を認識し分析することで、チームの働き方をより深く理解し、より適切な議論と意思決定を行うことができます。
これら３次元を測定するためのメトリクス例も以下のように提示してくれているので紹介します。
※ こちらの表を日本語に翻訳したものになります
この表などを参考にメトリクスを取ることでエンジニアの内なる声を聞き、課題を特定することが可能になります。
DXツール選定プロセス
今回は２つのツールをトライアル検証してみました。Four Keysを中心としたツールとDevExをベースにしたDXツールです。
前者のツールをトライしてみたことで、前述のとおりFour Keysだけでは不十分だと感じたので、DXツールを運用してみることにしました。このツールでは、Snapshotというアンケート機能を使って先程のDevExの3次元を測定することができます。
さらに、このDXツールにはSQLを利用して独自の分析を行う機能が備わっており、私達の今後のニーズにも対応する柔軟性があります。これにより、コーディング以外の側面も包括的に計測することが可能だと確信し導入することにしました。
導入プロセスとチームの反応
DX測定ツールの導入に際して、チームメンバーには以下の事を明確に伝えました：
DXツールを導入する意義：エンジニアの幸福度（満足度）を可視化し、Four Keysなど定量的な指標と合わせ見る事でお客様への価値提供出来ている（＝ミッション貢献度合い）事を実感することで、会社のミッションと実務との繋がりを持たせ、最終的にお客様へのアウトカムをエンジニアが直接感じられるようにすること。
測定結果が給与評価には関係ないこと：評価がツール導入の目的ではないことを強調し、安心して取り組める環境を作りました。
DXツールの使われ方：ツールの使い方や、短期・中期・長期的な目的について、チームと共有しました。
この使われ方は机上の空論レベルではありますがDevExフレームワークにより具体的な成果物を目指したいかを共有しました。
短期的にはチームでの開発振り返りやリリースサイクルの向上に役立てる。
中長期的にはビジネスインパクトや技術的負債の改善を目指す。
長期的には生産性を経営陣に伝えるための材料とすることを目標としました。
さらに、これらはメンバーの協力がないと成り立たないと白旗をあげ、各職域（サーバー、iOSなど）の代表者が参加するDX（生産性向上）チームを結成することができました。
チームの反応
導入からまだ1ヶ月も経っていないため、具体的な成果報告は難しいですが、初回のSnapshotアンケートからいくつかのポジティブな発見がありました：
Batch Size（Delivering small、 incremental changes）への所感に課題感があり、中央値よりも最大で41点低かったことが判明。
※中央値とは：年に一度、同サービスを使う全企業を分析し業界50位のスコアから相対スコア
Incident Response（Process for dealing with errors or incidents）では、各チームによるポイントのばらつきが大きく、解決へのサポートが必要なチームが多かったため、早速DXチームで対応フローの型化を検討。
Documentation（Having good internal documentation）では、平均よりポイントが高く、普段からドキュメントを丁寧に作成しているメンバーの良さが反映されました。
また、全社的に行っているモチベーションクラウドではAAA評価と高得点であるにも関わらず、DXツールによるアンケートでは逆にチームのストレッチポイントが明確になりました。
モチベーションクラウドの取り組みについては別途記事を書いているのでぜひご覧ください。
一方で、Snapshotアンケートは1回目だったため、質問に対する認識のズレが個人ごとに見られ、結果を素直に受け止めるには後数回アンケートを取る必要があることも分かりました。
今後の展望
短期的にはリリースサイクルを短縮し、お客様への価値提供を強化することを目指しています。そのため、Snapshotアンケート結果を丁寧に分析し改善活動を推進していきます。
また、長期的には、各メンバーがDevExの3軸を意識し、自発的に改善活動を行う文化を根付かせたいと考えています。プログリットのバリューである「Own Issues」をさらに強化し、エンジニアが自分の課題を積極的に解決する文化を築いていきたいです。
具体的には、四半期ごとのSnapshotアンケートの実施、DXチームによるディスカッションと改善活動、さらには勉強会の開催を通じて、DevExへの理解とエンジニアリングの質を高めていく予定です。
全体の振り返りと将来的な期待
今回のDXツール導入を通じて、一回やってみる事が出来るメンバーがいる事の有り難さを感じました。
２ヶ月近くツールの検証に付き合ってくれてありがとうございました。
プログリットではこういったチャレンジもそうですし、技術的なチャレンジにも寛容な風土だなと感じます。
先日インターン生のKaiさんがKMP導入にチャレンジしてくれました。そちらの記事もぜひご覧になってください！
プログリットでは、プロダクト開発のメンバーを募集しています！
プログリットの「世界で自由に活躍できる人を増やす」というミッションに共感してくださる方、全員が顧客への価値を考え抜く組織の中で、お互いに切磋琢磨しながら成長していきたいという方は、ぜひカジュアル面談でお話ししましょう！
この記事が気に入ったらサポートをしてみませんか？