こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。
最近はもっぱら DevEx に興味が湧いています。6/28、29日に開催された 開発生産性カンファレンス に参加してきて、開発生産性や開発者体験について非常に学びある2日間を過ごしました。
今回のテックブログでは、開発者体験の基となる「DevEx: What Actually Drives Productivity」という論文を基に、フォースタートアップスの開発組織で行った「開発者体験に関するアンケート調査」と「開発生産性とは一体何なのか」を私自身の経験や見解に基づいて、書いていきたいと思います。
キーワードは、「開発生産性」、「SPACE」、「DevEx」です。盛り沢山の内容になってしまったため、執筆を2つに分けています。今回は「開発生産性とは一体何なのか」を中心とした内容になっており、「開発者体験に関するアンケート調査」については、続編をお待ちいただけますと幸いです。
※組織戦略・アーキテクチャ戦略・ROI的観点での開発生産性というよりは、より開発現場に近い課題の発見、それに基づく改善アプローチにフォーカスしています。また、個人的見解や解釈が含まれる点にご了承いただけますと幸いです。
目次
- はじめに
- DevEx プロジェクトで実現したいこと
- なぜ、開発生産性を高める必要があるのか
- 開発生産性とは何か
- なぜ、開発生産性を定義することは難しいのか
- 開発現場における開発生産性とは
- 開発生産性を多面的に評価するには
- 続編に向けて
- 参考資料
はじめに
- 開発生産性を高められていますか？（先日参加した外部の勉強会で、これを言いすぎると嫌われますよって言われました）
- 開発生産性の高め方をご存知ですか？
- そもそも開発生産性とは何かをご存知でしょうか？
フォースタートアップスでは、プロジェクト制度という「開発者が自発的にテーマを決めて取り組むことができる制度」があります。その制度を使い、開発組織・チームの開発生産性向上を目的としたプロジェクト（以下、DevEx プロジェクトと呼ぶ）を今年5月に起案し、私を含めた2名で推進しています。
開発者にとって、より良い作業環境を備えることができれば、個人、チームおよび組織のパフォーマンスの成果向上が見込めます。そんなお話をします。
DevEx プロジェクトで実現したいこと
それは、開発組織・チームの開発生産性の向上です。以下3つの実現を目指し、DevEx プロジェクトを推進しています。
- フォースタートアップスで働く開発者の
- 開発者体験の向上（より開発現場に近い課題の発見、それに基づく改善）
- エンゲージメントの向上（長く活躍していただける環境、仕組みづくり）
- 早期戦力化（新しくジョインされた方々が、素早く生産性をあげられる仕組みづくり）
なぜこれらの実現を目指したいのかというと、開発組織・チームには、生産的な活動を継続的且つスピーディーに回していくことが重要だと考えているためです。
なぜ、開発生産性を高める必要があるのか
限られたエンジニアの貴重な時間の中で、価値の高いアウトカムをデリバリーしていくためです。すなわち、価値提供機会の向上です。
今日、数多くの企業がソフトウェア主導で成り立っており、イノベーションの創出や社会の成長にはテクノロジーの力が必要不可欠になってきています。いわば、エンジニアの力が不可欠です。
エンジニアの有限な時間で価値の高いアウトカムを実現するためには、スピーディーなサイクルを継続的に回し続けることが重要だと考えています。なぜなら、変化多様なこの時代に何がアウトカムとなるのか、どんなアウトカムが本質的な課題解決になるのか、そもそも誰も分からない世の中になってきているからです。
価値の高いと思えるアウトカムを継続的にデリバリーしていくことこそが、本質的な課題解決の鍵となっていくのではないでしょうか。
開発生産性とは何か
- アウトプット/インプット？
- アウトカム/アウトプット ？
- Four Keys？
- プルリクエスト数？
- ROI？
- ストーリーポイント（ベロシティ）の消化量？
みなさまは、開発生産性をどのように定義しておりますでしょうか。
様々な開発生産性の勉強会に参加し、私なりの仮説があります。それは、開発生産性の定義は企業によってばらつきが見られる。つまり、開発生産性は定義の仕方によって変化するのではないかということです。
また、先日参加した 開発生産性カンファレンス において感じたことは、開発生産性の定義は「組織における立場やレイヤーによって変化する」ということです。組織における立場やレイヤーによって関心ごとは異なり、可視化すべき指標が変わってくるからだと考えています。
要するに、開発生産性の定義には明確な正解はなく、組織における立場やレイヤーによって変化する。そのため、定義すること自体が非常に難しい。
一つ念頭に置くとすれば、開発生産性が高かったとしても無駄な生産であれば、何も価値を生み出せないということです。
なぜ、開発生産性を定義することは難しいのか
2つの見解があります。
長期的なパフォーマンスへの相関（開発とビジネス）のメカニズムを理解する必要があるから。要するに、事業構造がどのように開発と繋がっているのかを理解しなければならないことが難しい。
上記述べたように、組織における立場やレイヤーによって関心ごとが変化するから。要するに、開発現場、マネージャー、経営層など、レイヤーによって関心ごとは異なり、可視化すべき指標やそれら指標の重要性を理解しなければならないことが難しい。
これらの難しさにより、開発生産性の定義には明確な正解はなく、定義すること自体が非常に難しいのではないかと考えています。
開発現場における開発生産性とは
Four Keys を採用している企業をよく耳にします。フォースタートアップスの開発組織は、Findy Team+ を利用し、Four Keys やサイクルタイムを用いて開発生産性を可視化しています。
ここで簡単に Four Keys について触れたいと思います。
Four Keys とは
DORA（DevOps Research and Assessment）が6年におよぶ研究を踏まえて提唱した、ソフトウェア開発チームのパフォーマンスを計る4つの指標のことを Four Keys と呼びます。
その4つの指標は、
- デプロイの頻度
- 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム
- commit から本番環境稼働までの所要時間
- 変更障害率
- デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間
- 組織が本番環境での障害から回復するのにかかる時間
デプロイの頻度が高い、変更のリードタイムが低い、変更障害率が低い、サービス復元時間が低い = 開発生産性が高いと言われることが多いように感じています。
本当にそうなのか？
後ほど触れますが、The SPACE of Developer Productivity（以下、SPACE と呼ぶ）というフレームワークでは、開発生産性は単一の指標やアクティビティデータだけでは測定することはできない。つまり、Four Keys の4つの指標だけを可視化しても、開発生産性を図りきれないのでは？そんな疑問を持っておりました。
書籍『LeanとDevOpsの科学』では、組織パフォーマンスとデリバリーパフォーマンスを別物扱いとしており、Four Keys はデリバリーパフォーマンスの指標として使われています。つまり、厳密には開発生産性というよりは、エンジニアリングチームのデリバリーのパフォーマンスに関する指標が Four Keys なのではないかと（ただし、デリバリーパフォーマンスが高い = 組織パフォーマンスへ正当な影響を及ぼすとも書かれている）。
開発生産性を図るためには、生産性のさまざまな側面を捉え、多面的に評価することが必要であり、エンジニアリングチームのデリバリーパフォーマンス（Four Keys）と多面的な評価（DevEx）の両輪の関係から開発生産性は成り立つのではないかと考えています。
開発生産性を多面的に評価するには
昨今話題となっている「SPACE」というフレームワークがあります。生産性のさまざまな側面を把握するために開発され、5つのディメンションから構成されます。また個人、チームあるいはグループ、システムレベルなど、さまざまなレベルで適用されるメトリクスを数多く提唱しています。
ここで SPACE のディメンションについて、少し触れたいと思います。
SPACE の5つのディメンション
- Satisfaction and well being（満足度と達成感）
- Performance（パフォーマンス）
- システムまたはプロセスの結果
- 信頼性、バグ軽減、顧客満足度 など
- Activity（活動）
- 作業中に完了したアクションまたは出力数
- ドキュメント、プルリクエスト、コミット、コードレビューの量 など
- Communication and collaboration（コミュニケーションとコラボレーション）
- 人々やチームがどのようにコミュニケーションを取り協力し合うか
- 新メンバーのオンボーディング時間、誰が誰とどのように関係値があるのか など
- Efficiency and flow（効率性）
- 中断や遅延の頻度
- 中断の量、間隔、フロー状態の頻度 など
これらすべてのディメンションを同時に使用することは推奨しておらず、3つのディメンションからメトリクスを作ることを推奨しています。また、具体的な手法を提供するものではなく、メトリクスを独自に作成する必要があります。
DevEx プロジェクトでは、もう少しライトに「開発現場に近い課題の発見、それに基づく改善」ができないかと考えており、そんな時にマネーフォワード社が実施していた「開発者体験サーベイ、めっちゃよかったんで、おすすめです」の記事にて、DevEx in Action（以下、DevEx と呼ぶ）という論文に辿り着きました。
DevEx とは何か
開発者体験（開発者が開発を行なう過程で考えたり、感じたりする総合的な体験）というはっきりとしない概念について、それを測定する枠組みを提供しています。Abi Noda氏らによる開発者体験に関する研究であり、書籍『LeanとDevOpsの科学』を著した Nicole Forsgren氏も共著者として名前を連ねています。
DevEx の3つの側面
DevEx では、「フロー状態」、「フィードバックループ」、「認知負荷」の3つの側面で、開発者の体験を捉えています。
- フロー状態
- 活動を行っている人がエネルギーに満ちた集中力、完全な関与、楽しさの感覚に完全に浸っている精神状態を指す（ゾーン状態とも言い換えることができる）
- フィードバックループ
- 実行されたアクションに対する応答の速度と品質を指す
- 認知負荷
- 開発者がタスクを完了するための必要な精神的処理の量を指す
これら3つの主要な領域に焦点を当てることで、開発組織・チームは改善に向けた一歩を踏み出すことができます。
どんな成果が得られるのか
これら3つの側面が改善されると、誰にとって、どんな成果が得られるのでしょうか。以下、論文から抜粋した研究結果です。
Outcomes
When considering the outcomes of development work or the developer experience, many researchers and people think about productivity.8,21 In our years of experience, however, we have seen that the improvements in developers' work go far beyond personal productivity for individual contributors,16 to include team and organizational outcomes.7,11 This investigation considers outcomes at the developer, team, and organizational levels, which is supported by WDT.23
Developer outcomes
Developer outcomes are those that benefit an individual developer. In particular, prior WDT research shows that improved work design positively influences job performance, creativity,22 and learning5—three outcomes investigated in this study.
Team outcomes
Team outcomes are those that can benefit an individual developer but more likely accrue at the team level of work and are therefore operationalized and studied at this level. WDT also shows that outcomes such as quality benefit teams.22 In the context of DevEx, we want to capture how work design can impact the quality of the system the team can work in, and therefore capture this as code quality and technical debt.
Organization outcomes
Organization outcomes benefit a worker's employer.improvements in developer work positively affect an organization's profitability and its ability to achieve goals.
要するに、
- 個人（開発者）の成果
- 仕事のパフォーマンス、創造性、学習、燃え尽き症候群の軽減にプラスの影響をもたらす
- チームの成果
- コード品質、技術的負債にプラスの影響を与え、チームに利益をもたらす
- 組織の成果
- 組織の収益性と目標達成能力にプラスの影響をもたらす
「フロー状態」、「フィードバックループ」、「認知負荷」、これら3つの側面が改善されることで、個人の生産性を遥かに超え、チーム・組織へ正当な影響を与える。その結果、組織パフォーマンスの成果向上に繋がっていくのではないかと理解しました。
続編に向けて
いかがでしたでしょうか。開発生産性とは一体何なのか、なぜ開発生産性を高めなければならないのか（根幹の話）、開発生産性を高める上での課題は何なのか（ボトルネックの話）、そして開発生産性をどのように高めていくのか（手段の話）、少なくともこれらの方向性を整えていくことが重要なのかもしれません。
DevEx プロジェクトでは、DevEx の研究を基に「開発現場の開発者体験を定量化」することにしました。目的は、開発組織・チームの開発生産性を向上させるための課題発見です。 独自に開発者体験サーベイを設計し、フォースタートアップスの開発組織で「開発者体験に関するアンケート調査」を行いました。
次回のテックブログでは、「開発者体験に関するアンケート調査」を中心とした内容を予定しています。乞うご期待ください！
参考資料
- SPACE
- DevEX
- Four Keys
