開発生産性を上げた先に我々は何を開発チームに求めるのか？
スリーシェイクの吉田です。
昨今、エンジニアリングの世界で開発生産性に着目したイベントや手法に注目が集まっているので、そもそも開発生産性を上げた先に何を期待しているのか？について書いてみました。
ソフトウェア領域における生産性の誤解
日本の労働人口があと10年で数百万人不足すると言われる中で、IT業界に限らず、あちらこちらから「生産性向上」というワードが飛び交っています。
一般的には、効率的な仕事をすることにより早く大量のアウトプットを出せますよね？という話かと思います。
例えば製造業の現場では、ロボットの普及により（人が不要になり）安価で品質の良い製品を作ることができました。これがまさに「生産性向上」の代表的イメージです。
しかし、ソフトウェア領域における生産性は、このイメージとは異なります。
前提として、ソフトウェア業務は製造ではなく、スポーツ（開発者、チーム、会社、エンドユーザーで構成される） であると考えればいいのではないでしょうか？
Software development is a team sport
製造のゴールは、「安くて早くて品質の良いものを作ること」。その生産性を測る指標や考え方は、データドリブンであり、客観性がとても高く時代に左右されない普遍的な印象です。一言で言えば「無機質」であり、単一指標でも言い表せる感じ。
（実際の製造業を知りませんので、あくまで筆者のイメージです）
しかし、スポーツのゴールは、「勝つこと（目標を達成すること）」です。
勝つために必要な要素は複雑であり、時代によっても変わります。その生産性を測る指標は、一言で言えば「有機的」であり、単一指標では言い表せない、もやっとしたものです。
同じ「開発生産性」でも、目に見える製造の世界と、目に見えないソフトウェアの世界ではかなり乖離がある点を、非エンジニア領域（特に経営層）で認識していく必要があるのではないでしょうか。
では開発チームの生産性を測る指標がまったくないのか？でいうと、SPACEフレームワークは個人的に腹落ちしやすい、イマドキな指標でしたので紹介します。
SPACEフレームワークとは
Microsoft Researchにより発表された論文、The SPACE of Developer Productivityにて提唱された開発者/開発チームを理解するためのフレームワークです。（最近、Findy Team+にて計測できるようになったらしく、これはかなり嬉しい、流行ってほしいと思いました）
一昔前だと、Pivotal Trackerなどを使ってベロシティに注目して開発チームのパフォーマンス評価をするなどしていました（私も過去使っていて、シンプルなUXで良かった）が、そもそも開発生産性というのは複雑な要因が絡み合ってるので、単一指標で測るのではなく、複数の定量、定性的な指標をみて総合判断しようという枠組みです。
Satisfaction an Well-being
仕事、チーム、ツール、文化にどれだけ満足しているか、幸福度が高いか
Performance
アウトカム（品質、信頼性、バグの有無、開発した機能の顧客インパクト、コスト削減へのインパクトなど）
Activity
アウトプット、活動量（消化したチケット数や、プルリクエスト数、コミット数、レビュー数など）
Communication And Collaboration
開発チーム内外でのコミュニケーション、コラボレーションが効果的にしやすい状況なのか（ドキュメンテーションが十分なのか、レビュー自体の品質がいいか、チーム内外でのネットワーク密度が濃いか、オンボーディングが充実しているか）
Efficiency And Flow
集中してコーディング/エンジニアリングができているか（他チームとの調整や作業待ち、デプロイ待ち、MTGがどれだけあるか）
以上がざっくりとした内容です。全ての指標を使うというよりは、チームの状況に合わせて、上記から最低3つ以上の指標で総合評価したほうが良いよねと提唱されています。
スリーシェイクではSPACEを採用しているか？でいうと、実はまだやっていません。これから半年ぐらいかけて各チームと議論して、それぞれでベストな指標を見出していこうと思います。
余談ですが、論文内に記述された「開発生産性に対する神話と誤解」という箇所は、非エンジニア（特に経営層やマネジメント層）がよく理解しておく必要がある内容です。
開発生産性に対する誤解その1
開発生産性は開発者の活動量（Activity）に関するものだ
特にセールス領域において、パフォーマンス指標は活動量を中心に見ていくことが多いため、ここは勘違いされやすいところです。要するに沢山プルリクエストを出してて、コード量が多い人、レビュー数が多い人、チーム「だけ」が評価される状況はおかしいよねと。
開発生産性に対する誤解その2
開発生産性は開発環境や開発ツールに関するものだ
ここは様々なテックベンダーの利害（我々も漏れなく）があり、どうしても開発生産性の話になると技術やツールの情報が多く見受けられますが、実際にはそれだけじゃないよ。という話です。
エンジニア側はそこは普通に受け止めてる（と私は感じてます）印象ですが、最近非エンジニア領域から「生成AI系開発ツールをみんなに渡しておけば、開発現場よくなるでしょ？」っていう風潮を感じています。まさに誤解であり神話です。
やはり総合的な判断をチーム単位でじっくり見つめながら改善をしていくことがこれからの時代も求められます。
開発生産性に対する誤解その3
またチーム間や個人間で開発生産性を比較することに対しては、危険性をはらんでいます。比較する際にちゃんとデータは正規化されているのか？偏ったデータで判断していないか？という部分です
最後に、どんな測定手法であろうが、偏りと正規化はチェックするべきだ
特にビジネス職の方に対して、SPACEだろうがFour Keysだろうが、組織間やチーム間で単純比較しないでという話をすると「?」という顔をされることがありますが、それはここです。正規化されてないので、単純比較しても意味がないんです。あくまでも、そのチームに対する過去現在未来を見つめる道具（にしたほうがよい、正規化するの大変だし）と捉えるのが良いでしょう。
開発生産性を上げた先に我々が求めるものは…
さて、タイトルに戻って、SPACEなどの多面的な指標を手に入れて、チームの生産性を向上した先に求めるものは、やはり「勝つこと（目標を達成すること）」です。
ではチームにとって勝つことは何なのか？
ここが大事だと思います。チームにとっての勝ち = 目標、役割、期待値を超えることです。裏を返せば、これがちゃんと定義されていないと、スポーツになりません。勝ちが定義されていれば、そこを超えるためのより効果的な指標をSPACEの中でPick Upすることができるでしょう。
開発チームにおいて、ここが明確にされていないことはよくあることです。その状況下で、SPACEだけ取り入れて議論してもあまり意味がないのかなと。まずは個々の開発チームにおける目標について、議論を深めていくことが効果的なエンジニアリングに繋がるのではないでしょうか？
最後に
スリーシェイクのこれからにご興味をお持ちいただいた方、想いに共感してくださった方がいましたら、私やスリーシェイクのメンバーにお気軽にお声がけください！