開発生産性を上げるための3つの鍵
エンジニア不足が叫ばれるなか、開発生産性が注目を集めています。
開発生産性ほど、チームの成果と士気に影響を与えるものはありません。コードは準備できているのに、指定日まで展開できない。やっと展開できたと思ったら、すぐに他のコードでバグが発生して、全部元に戻さなくてはならない。他チームの改修が遅延続きで、いつまで経ってもリリースできない。こんな状況が続いて改善が見込めなかったら、多くの人が「もうこの会社辞めようかな」と思うでしょう。
「LeanとDevOpsの科学」著者のニコル・フォースグレン博士もそんな1人でしたが、彼女の打ち手は型破りでした。IBMの大規模開発を率いて疲弊していた彼女は、「もっと良い開発手法があるのでは」と経営陣に相談したところ、真に受けてもらえませんでした。「だったら私がデータで検証してやる」と考えた彼女は、企業の開発生産性と業績の関係の研究に打ち込み、博士号を取得します。
開発能力と業績の関係を解明した彼女は、その後、開発生産性の評価と提案を行うSaaSプロダクト「DORA（DevOps Research and Assessment」を開発し、後にGoogleがそれを買収しました。フォースグレン博士は、GitHubを経て、現在はMicrosoft Researchでエンジニアの生産性や体験を向上させる研究を率いています。
「4つの指標」で終わっていないか
DORAで革命的だったのは、開発生産性は「Four Keys」と呼ばれる4つの指標で把握できる、という洞察でした。
デプロイ頻度：コードを本番環境に展開する頻度
変更リードタイム：コード確定（コミット）後、本番環境にデプロイされるまでの時間
変更障害率：デプロイした変更のうち、修正が必要になった割合
復元時間：障害が発生してから復旧するまでの平均時間
加えて、「何が『良い』水準なのか？」に対する答えも提供しています。
デプロイ頻度：オンデマンド（1日数回）
変更リードタイム：1日～1週間
変更障害率：0%～15%
復元時間：1日未満
開発生産性の高い企業と低い企業と比べると、前者はケタ違いのペースで機能をリリースし、顧客に価値を届けている、ということが分かりました。
デプロイ頻度：46倍の頻度でコードを展開
変更リードタイム：440倍の速さで展開を完了
変更障害率：1/5しか変更時に障害が起きない
復元時間：170倍の速さで復元
この分かり易さが大きな支持を得て「Four Keys」は広まりましたが、2023年版のレポートでは、「これらの指標だけに執着しても、無意味だ」と警鐘を鳴らしています。その気になれば、数値をごまかすことは可能ですし、何より、測定しただけではその根本の働き方をどう変えれば良いのか答えは出ないからです。
結果を出すための3つの鍵とは
では、開発生産性を上げるには、何が必要なのでしょうか。DORAの最新の研究では、
学びを促す環境
継続的な「フロー」状態の創出
迅速なフィードバック
の3つが鍵である、としています。それぞれ見ていきましょう。
① 学びを促す環境
継続的改善と知見共有の文化を醸成するためには、日々の業務の中で「学び」が積極的に起こる環境が必要です。このような環境を用意することで、デプロイ頻度、変更リードタイム、チームの士気など、様々な角度から生産性を改善することができます。組織全体の業績向上にも寄与するため、どんな開発組織にとっても価値のある投資と言えます。
コード保守性：他者が管理するコードの変更、コードベース内の例の参照、他人のコードの再利用、依存関係のある新バージョンへの追加・移行など、開発者が日々コードを更新するのを容易にするシステムやツールが必要です。
文章化：ドキュメントの質は、技術的な機能と相互作用しながら、組織の生産性を向上させてくれます。プロダクトやサービスの重要な使途を文章化し、開発プロセスの一部として更新・編集を続けるよう維持すると、多数のチームメンバーがそれを参照しながら組織の目標達成に向け取り組むことができます。
ツールの選択権：使うツールは開発の成果を左右します。現場のメンバー以上にどんなツールが有効かを知る人はいないため、ツールの選択権を委譲することが大事です。
創造的な文化：権力主義や官僚主義に陥ることなく、メンバーの想像力を発揮させるようなカルチャーは、ソフトウェアや組織の生産性を向上させ、社員の燃え尽き症候群も軽減してくれることが解明されています。新しい解決策を受け入れ、高い協力と信頼を通じてスムーズに情報共有をすることが、創造的な文化作りには欠かせません。
② 継続的な「フロー」状態の創出
時間の感覚が失われるぐらい業務に集中できることで、生産性が飛躍的に高まる状態を「（flow）フロー」と言います。開発チームにとっては、これが理想の状態です。これを実現するためには、フロー状態を妨げる「邪魔」をあらゆる技術・組織・業務面の仕組みを通じて排除する必要があります。
継続的デリバリー（CD）：オンデマンドで本番環境にデプロイできるようになると、より早くリリースができ、仕事の成果を実感しやすくなります。これを実現するには、トランクベース開発（細かく頻繁なアップデートをコア「トランク」に統合するバージョン管理手法）、継続的統合・テストなど、複数の手法を実践する必要があります。
データベース変更管理：データベースに変更を加える際は、チームのペースを落とさない形で行うのが理想です。具体的には、スクリプトの保存、変更の見える化、関係者との連携などが求められます。
デプロイの自動化：デプロイが完全に自動化され、手動介入が不要な状態を指します。
柔軟なインフラ：インフラの心配をしなくて済むようになるためには、⑴オンデマンドのコンピューティングサービス、⑵広帯域のネットワークアクセス（スマホ、パソコンなど様々な端末に対応）、⑶コンピューティングリソースの集約、⑷強い弾力性、⑸使用度合いの計測、の5つを実現する必要があります。クラウドの採用理由の1つは、このインフラの柔軟性であることが多いです。
疎結合のチーム：チーム間で調整せずに、要求に応じてテスト及びデプロイできるソフトウェア及び組織の構造は、フロー状態創出に大きく寄与します。逆に、これができないと、常に他チームに依存し、自分達のペースで仕事ができない状態となります。
変更承認の合理化：多くの組織では、運用及びセキュリティリスクを軽減するために、デプロイの際に幹部や専門家の承認が必要なプロセスがあります。実は、これらの承認プロセスが変更の障害率を低下させるという証拠はありません。逆に、承認のステップを増やすことで、プロセスが遅くなり、デプロイの頻度が遅れ、それに伴い本番環境への負荷が増えるため、結局障害率は高くなるということが分かっています。
バージョン管理：デプロイする全てのコードのバージョンを管理することで、不具合発生時や監査時にコードの検証がしやすくなります。
小さなバッチでの作業：コードの変更をこまめに行うことで、リードタイムを短縮し、より速くその効果や性能を検証することができます。小単位の変更は、コミットからデプロイまでの速度を上げ、同時に安定性も増すため、小さなバッチのほうがバグが少ない可能性が高いです。
③ 迅速なフィードバック
迅速なフィードバックは、開発のライフサイクル全体を通して、チームが迅速に示唆を得られるための鍵となります。チームが行う変更の良し悪しに自信を持てるようになり、より迅速な反復と高品質なソフトウェアに繋がります。これにより、生産性が向上し、チームが競争力を維持し、顧客に最大限の価値を提供することができるようになります。
継続的インテグレーション（CI）：「大変な作業は、こまめにやって痛みを軽減しよう」という思想です。具体的には、コードを定期的にチェックし、各チェックポイントでテストを通じてバグを検出し、見つかったら直ちに修正する一連の手法を指します。
モニタリングと可視性：モニタリングと可視性ツールにより、チームはシステムの健全性を理解できます。ユーザー体験をモニタリングできるだけでなく、エンジニアが素早くシステムを修正し、出現するパターンを探索することもできます。
レジリエンスエンジニアリング：障害を防ぐだけではなく、耐障害性のあるシステムを設計、構築、運用しよう、という考え方です。具体的な手法は、継続的改善、障害許容、データの整合性、負荷分散、レプリケーション、自動スケーリング、自動復旧などが含まれます。これらを実践することで、想定外の障害が起きても一貫した性能を提供できる信頼性の高い分散型システムを構築できます。
セキュリティの浸透：開発ライフサイクルのデザイン及びテスト段階にセキュリティを統合することで、セキュリティ上の懸念事項を是正することができます。セキュリティレビュー、セキュリティチームの参加、事前承認されたライブラリやパッケージの使用、セキュリティ機能のテストが含まれます。
テストの自動化：開発完了後ではなく、開発ライフサイクルの全工程でテストを自動的に行うことが大事です。生産性の高い企業では、テスト駆動開発を実践し、テスト結果を10分未満で見て、テストソフトウェアを継続的に見直ししています。
テストデータ管理：自動テストの重要な部分となりつつあるテストデータの管理。必要十分かつ最小限なデータをオンデマンドで取得できるよう管理する必要があります。
見るべき指標は、4つだけじゃない
「Four Keys」のような指標を導入する中で、フォースグレン博士は開発生産性には様々な誤解があることに気が付きました。「Four Keys」だけに固執する人はもちろん、組織ではなく個人の生産性に固執する人、個人の生産性を活動量だけで測ろうとする人、ツールやシステムにばかり執着する人。。。
本当に開発生産性を可視化するためには
複数の種類の目標（満足度、成果、活動量、コラボレーション、フロー）を
様々なレベル（個人、チーム、システム）で
見なくてはなりません。この点をクリアにするために、現在は「SPACE（Satisfaction & Well-being, Performance, Activity, Communication & Collaboration, Efficiency & Flow）」という包括的なフレームワークを提案しています。これが見るべき指標の全体像であり、有名になった「Four Keys」は、それらの中から一部の結果指標に焦点を当てたもの、と整理し直すことができます。
AI革命の中、開発生産性はどう進化するのか
2024年度のDORA研究レポートは、今月中リリース予定とされていますが、特にAIが開発生産性への取り組みにどう影響を与えるかに焦点を当てると見られています。
信頼性：開発者の特定のタスクにおいて、AIはどの程度貢献しているか?
接点・範囲：開発者の業務の中で、どんな場面でAIと対話しているか?
姿勢：開発者は、生産性やキャリアに対するAIの影響をどう感じているか?
未来予想：開発者は、日常生活におけるAIの影響について、どんな予想をしているか?
ご興味ある方は、こちらから通知のサインアップが可能です。また新しい発見がありましたら、共有させて頂きます。