「開発者体験が良い」とはどういう状態？ 3つの要素から考える
ファインディは「挑戦するエンジニアのプラットフォームをつくる。」というビジョンを掲げ、エンジニア採用のマッチングサービスなどの事業を提供している。浜田氏が担当するエンジニア組織支援SaaS「Findy Team+」は、多様なコード管理ツールやイシュー管理ツールのデータを連携させ、開発生産性を多角的に可視化するプロダクトだ。さまざまな指標を通じて開発プロセスの改善点を特定し、継続的な改善を支援する。さらに、Googleカレンダーと連携してミーティング時間の分析も行えるなど、開発以外の側面も考慮に入れている。
講演のテーマとなるDevExは「Developer Experience」の略で、日本語では「開発者体験」を指す。これは、開発者が自分の仕事に対してどのように感じ、考え、価値を見出しているかを示す指標だ。ソフトウェア開発においては、変更のリードタイム、デプロイ頻度、変更失敗率、修復時間などを評価する「Four Keys」が注目されているが、浜田氏はモチベーションとアウトプットの両方が重要であるとし、「DevExこそ、これらを同時に把握できる指標だ」と述べ、今回その内容を深く掘り下げたいと語った。
DevExを改善すれば、開発者個人には高い生産性と創造性がもたらされ、開発チームにはより良い行動品質とイノベーションが生まれ、組織全体には高い定着率と利益が期待できるという。浜田氏は、いくつかの論文に基づいてDevExの3つの要素である「フロー状態」「認知負荷」「フィードバックループ」について説明した。
フロー状態とは、集中力が高まり、活力に満ちて楽しさを感じながら作業に取り組める精神状態を指す。開発者がこの状態に入ると、生産性が向上し、イノベーションや成長に繋がる。浜田氏は、深い集中を保って業務に取り組む開発者は、そうでない開発者に比べて生産性が50%向上し、仕事に魅力を感じる開発者は、生産性を30%高く感じるといった調査結果を示した。
認知負荷は、開発者がタスクを実行する際に必要な精神的処理の量を指す。認知負荷が高いと、タスクの完了に時間と労力が多くかかる。コードの理解度が高い開発者は、低い開発者に比べて42%生産性が高く、ツールや作業プロセスを直感的に理解できる開発者は、自分を50%革新的（イノベーションを起こし、本質的な価値を提供できる）と感じている。
フィードバックループとは、進行中の作業に対するフィードバックと学習の循環を指す。迅速なフィードバックループは開発を加速させるが、遅いループはプロセスを中断させ、タスクの切り替え時にフラストレーションや遅延を引き起こす。コードレビューが速い開発者は遅い開発者よりも20%革新的だと感じており、迅速に質問に対応するチームは、対応が遅いチームと比較して技術的負債が50%少ない。
DevExの3つの要素を測定してみる
浜田氏は、「DevExという指標を測定するには、先に紹介した、フロー状態、認知負荷、フィードバックループの3つの要素それぞれに対して、『Perceptions（理解、認識）、Workflows（システムのプロセスの振る舞い）、KPI（組織が目指すべき指標）』という3つの項目を測定します」と、その方法を紹介した。3要素それぞれについてPerceptionsとWorkflowsを測定、KPIは3要素全体をまとめて測定する。
Perceptionsは、開発者のフィードバックループ、フロー状態、認知負荷に関する定性情報を収集する。具体的には、Google Formsに設問を設定し、各項目について開発者に満足度を5段階で記載してもらった。
Workflowsでは、フィードバックループ、フロー状態、認知負荷に関する情報を収集するが、GitHubやJiraなどの開発システムから得られる定量情報が対象となる。フィードバックループについては、CI実行時間、コードレビュー・ターンアラウンドタイム、デプロイ・リードタイムの3つを測定した。CI実行時間は、CIの結果を生成するのにかかる時間を意味する。ファインディではGitHub Actionsを使用しており、コンソール上からCIの平均実行時間を抽出した。コードレビュー・ターンアラウンドタイムは、レビューを依頼してからレビューが完了までの時間であり、デプロイ・リードタイムは、Four Keysの項目の1つである、変更のリードタイムから取得した。
Workflowsの認知負荷については、プルリクエスト数、デプロイ手動ステップ数、ドキュメント改善頻度を、フロー状態は、ミーティング時間、トイル対応の割合、インシデント頻度を測定した。
KPIでは、ソフトウェア提供プロセスの容易性、従業員のエンゲージメントと満足度、計画通りのデリバリーであるかを測定した。PerceptionsとWorkflowsだけでは細かい数値が多いので、個別最適になってしまう可能性がある。そのため組織が目指すべき目標としてKPIを定義し、その達成状況を確認することで、個別最適ではなく全体のパフォーマンスやアウトプットの測定を目指した。
「目標の数字はクリア」でも無理してない？ 健全なチームの作り方
DevExの事例として、浜田氏が所属する「Findy Team+」開発チームの2024年8月におけるDevExの測定結果が示された。スコアは高い順に3色で色分けされ、緑が最も良く、次いで黄色、赤が最も注意が必要な状態を表している。測定結果について、浜田氏は「全体としては赤が1つ、あとは黄色と緑なので、比較的良い状態ではないかと思われます」とコメントした。
Perceptionsに注目すると、全体的に良好で赤の項目はなかった。ただし、認知負荷に関しては黄色となっており、コードベースの複雑さについてリファクタリングなどの対応が必要と考えられる。また、本番監視やドキュメント、オンコール体制など一部の項目で改善の余地があることもわかった。
次に、Workflowsでは、赤が1つあり、黄色が多数あった。赤となったのはCIの平均実行時間で、黄色になっているレビュー依頼から完了までのターンアラウンドタイムやプルリクエスト数なども開発速度に直結する重要な指標だ。実は、これらは基準を高めに設定しており、あえて黄色や赤になりやすくしている。これにより、課題に早期に気づきやすくなり、改善のサイクルを回すきっかけを増やすためだ。なお、KPIの測定結果は全て緑となっており、開発チームの良好な状態が確認できた。
次は緑、黄色、赤の結果をスコア化し、3つの要素がそれぞれ100点となるよう計算しなおした。その結果、フィードバックループが83、認知負荷が72、フロー状態が83というスコアになった。KPIは、未達の場合は全体のスコアを押し下げると考え、緑は1倍、黄色は0.9倍、赤は0.8倍と少しずつスコアを減算する設定にした。これら数値を、3要素を頂点としたチャートで示すと、開発チームのどこが特長でどこが課題かがよくわかる。
今回の測定結果について浜田氏は、「定性データが含まれていることで、定量データだけでは見落とされがちなアイデアや、数値的には問題がないように見えても潜在的な問題を検知できた点が良かったと思います。また、色分けしたことで、一目瞭然でどこを改善していけばいいかがわかるので、ビジュアライズしていくのは大事です」と振り返った。
ツールから自動取得する定量データでは非常に良い値が出るかもしれないが、それはメンバーがたびたび残業するなど、健全とは言えない場合も考えられる。サーベイによる定性データからは「疲れている」「無理をしている」といった状況も浮き彫りになる。
浜田氏は今後も評価基準や方法を見直し、より手軽にデータを取得する方法を確立していく方針を示し、最後に「各チームの健康状態をひと目で確認できる仕組みを目指しています。これは、マネージャーや上司が全チームのDevExをまとめて把握できる状態を想定しており、特に複数のチームを管理するマネージャーにとっては非常に有用なものになるのではと考えています」とコメントした。
