hachimaki37/20240617-devexmodel

LT勉強会で発表した資料です。
開発者体験の基となる「DevEx」という論文と「開発者体験に関するアンケート調査の結果」についてまとめました。こちらは新しくプロジェクトを立ち上げ、2名で進めています。

キーワードは、「開発者体験」,「SPACE」,「DevEx」の3つ、昨今話題の開発者体験についてです！

Transcript

1. 勉強会/DevEx モデル 2024/6/17
2. ちょこっとシンキングタイム！
3. 設問 1. みなさん、開発生産性を高められていますか？ （こないだ参加した外部の勉強会で、これ言いすぎて嫌われてますって言ってまし た）
4. 設問 2. みなさん、開発生産性の高め方を知っていますか？
5. 設問 3. みなさん、そもそも開発生産性って何か知っていますか？
6. 本日の勉強会で何かヒントになる きっかけを作れたらと思っています （正直、私はよくﾜｶﾗﾅｲ🤦）
7. これを聞くと、 開発生産性が爆上がり？ 銀の弾丸とは！ 👏👏👏👏👏👏👏👏👏👏👏👏 👏👏👏👏👏👏👏👏
8. 最初にお伝えします
9. そんなものはねーッッッ！！！！
10. すみません。少し心を乱したようです 気を取り直して
11. 「DevEx」と「開発者体験に関するア ンケート調査の結果」 をお伝えする会
12. 楽しくやっていきましょう！ 👏👏👏👏
13. 最初にお伝えします
14. 我々開発者にとって より良い作業環境を備えることができれば、 個人、チーム および組織のパフォーマンスの 成果向上が見込める
15. みなさん、今こんな気持ちではないでしょうか
16. （は？何言ってんのこの人？）
17. 要するに、
18. フォースタートアップスで働く 開発者の開発者体験が向上すれば、 フォースタートアップスの 個人およびチームの開発生産性は上がり、 組織のパフォーマンスの成果向上が見込める よって、日本の進化・我々の働く環境や給与などにもよ い影響を与えていくことでしょう （信じている）
19. そんなお話を本日します
20. はじめに - 本日の勉強会では、開発者体験の基となる「 DevEx」という論文と「開発者体験に 関するアンケート調査の結果」についてお話します - こちらは、新しくプロジェクトを立ち上げ進めています。いわば一旦の成果発表の会 です - 本日のキーワードは、「開発者体験」 ,「SPACE」,「DevEx」の3つです - 今からすごくしゃべります。座学中心で恐縮ですが、途中で当てるかもしれません。 ぜひ聞き耳を立ててご参加ください - ※私個人の見解や認識が含まれます。その点ご了承ください
21. 本題に入るその前に💡
22. 開発生産性とは何か？
23. 開発生産性とは何か？ 開発生産性 = アウトプット / インプット ？ = Four Keys の指標？ = PRの数 ？ = ストーリーポイントの量(ベロシティ）？ = アウトカム / アウトプット ？ みなさんは、開発生産性をどのように定義していますか？
24. 開発生産性とは何か？ 様々な開発生産性の勉強会に参加をしておりますが、開発生産性の定義は、企業に よってばらつきがみられます。ということは、開発生産性は定義の仕方によって変わると いうことです。 要するに、開発生産性の定義に 正解はない。また定義することは、非常に難しいという のが私の見解です
25. なぜ難しいのか？
26. なぜ難しいのか？ おそらく長期的なパフォーマンスへの相関（開発とビジネス）のメカニズムを理解する必 要があるからだと考えます 要するに、事業構造がどのように開発と繋がっているのか を理解しなければならない。 だから難しいのだと https://speakerdeck.com/sms_tech/managing-engineering-organization-in-a-stra tegic-way?slide=23 よく目にするのは、エンジニアリングの生産性を示す指標として Four Keys を採用してい る企業は多い
27. Four Keys とは？ みなさん、ご存知でしょうか？
28. Four Keys とは？ DORA（DevOps Research and Assessment）が6年におよぶ研究を踏まえて提唱し た、ソフトウェア開発チームのパフォーマンスを測る 4つの指標のことを Four Keys と言 う
29. 4つの指標とは？ - デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 - 変更のリードタイム - commit から本番環境稼働までの所要時間 - 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（ %） - サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 弊社でも Findy Team + を利用して Four Keys を可視化してたりしますよね
30. ただし、落とし穴がここにある
31. 開発生産性は「単一の指標」や「アクティビティデータ」 だけでは測定することはできない Σ('◉⌓◉’)❗ by SPACE （SPACEは後ほど説明します）
32. なぜか？
33. なぜか？ - 書籍：「Lean と DevOpsの科学」では、組織のパフォーマンスとデリバリのパフォー マンスを別物扱いとしており、Four Keys はデリバリのパフォーマンスの指標として 使われている。つまり、厳密には開発の生産性というよりも、 エンジニアリングチー ムのデリバリのパフォーマンスに関する指標が Four Keys である - 開発生産性を図るためには、生産性のさまざまな側面を捉え、 多面的に評価する ことが必要である - 開発生産性とは、エンジニアリングチームのデリバリのパフォーマンス（ Four Keys）と多面的な評価（開発者体験）の 両輪の関係から成り立つのではないかと考 えています
34. 多面的に開発生産性を評価するには？
35. 多面的に開発生産性を評価するには？ - 生産性のさまざまな側面を把握するために開発され、 5つのディメンションから構成 されるSPACEというフレームワークである。 - 個人、チームあるいはグループ、システムレベルなど、さまざまなレベルで適用さ れるメトリクスを数多く提案している - ※ただしSPACE は、あくまで5つのディメンションからなる開発生産性をとらえるた めのフレームワークであり、具体的な手法を提供するものではない
37. SPACEの5つのディメンション
38. SPACEの5つのディメンション - Satisfaction and well being(満足度/達成感) - 開発者が仕事、チーム、ツール、文化にどれだけ満足しているか。満足度とエンゲージメントの低下 は、燃え尽き症候群や生産性の低下が近づいている兆候である可能性 - 従業員満足度、開発者の効率性、燃え尽き症候群 など - Performance(パフォーマンス) - システムまたはプロセスの結果。ソフトウェア開発者のパフォーマンスを定量化することは困難であ る。そのため、パフォーマンス（開発者が書いたコードは、期待どおりに機能したか）は出力ではなく結 果として評価するのが最適 - 品質：信頼性、バグの不在、影響：顧客満足度、機能の使用、コスト削減 など - Activity(活動) - 作業の実行中に完了したアクションまたは出力の数 - 設計とコーディング。設計ドキュメントと仕様、作業項目、プルリクエスト、コミット、コードレビューの量 または数 など
39. SPACEの5つのディメンション - Communication and collaboration(コミュニケーション) - 人々やチームがどのようにコミュニケーションを取り、協力し合うかを表す - ドキュメントと専門知識の発見可能性、新メンバーのオンボーディング時間と経験、誰が誰とどのよう に接続しているかを示すネットワーク メトリック など - Efficiency and flow(効率性) - 個人またはシステムを通じて、中断や遅延を最小限に抑えて作業を完了したり、作業を進めたりする 能力を指す。生産性の概念化は、多くの開発者が作業中に「フロー状態に入る」こと - 中断: 量、タイミング、間隔、開発作業とフローへの影響 など SPACEは、すべてのディメンションを同時に使用することは推奨しておらず、これら 3つ のディメンションから取ることを推奨している
40. DevEx PJ チームでやりたいこと
41. DevEx PJ チームでやりたいこと - フォースタートアップスで働く開発者の開発者体験の向上。それは、より開発現場 に近い課題の発見、それに基づく改善（組織・チームのパフォーマンス改善） - エンジニアの方々に長く活躍していただける環境づくり - ジョインされたエンジニアの方が、素早く生産性をあげられる仕組みづくり（最大限 力が発揮できるように）
42. なぜか？
43. なぜか？ - 今日の非常に多くの企業がソフトウェア主導で成り立っており、イノベーション創造 や世の成長にはテクノロジーの力が必要不可欠 になってきています - いわば、エンジニアである「私たちの力が必要不可欠になっている 」と考えています - 開発者体験で感じる障害を特定し取り除くことができれば、 今よりも価値の高いア ウトカムやアウトプットのデリバリー（価値を届ける）に繋がっていく のではないかと 考えた そうなったらみんなハッピーじゃないですか？
44. そのためには、我々開発者にとって、 より良い作業環境（開発者体験）を 備える必要がある
45. SPACEは、具体的な手法を 提供するものではなかった
46. そこで！DevEx
47. DevEx とは - 開発者体験に関する研究。Abi Noda らによる研究で、書籍：「LeanとDevOpsの 科学」を著した Nicole Forsgren(ニコール フォースグレン) も共著者として名前を 連ねている - 開発者体験というはっきりとしない概念について、それを 測定する枠組みを提供し ている - 開発者体験とは、開発者が開発を行なう過程で考えたり、感じたりする総合的な体 験のことをいう - ※この研究の調査対象は、すでに DevEx 企業 (DX) に取り組んでいる企業で働く 開発者。つまり、DevEx の改善に取り組んでいることを示している可能性および、 DevEx を重視する層に到達した可能性が高い
49. なぜ、DevEx なのか？
50. なぜ、DevEx なのか？ - 開発生産性を多面的に評価する具体的な手法を提供 している。つまり、Four Keys との両輪の関係が成り立つ - チーム・組織は、フロー状態、フィードバックループ、認知負荷の 3 つの主要な領 域に焦点を当てることで、改善に向けた一歩を踏み出すことができる - つまり、このフレームワークに基づいて、開発者体験を調査し、把握することで、 よ り開発現場に近い課題の発見やそれに基づく改善ができる のではないかと考えた
51. DevEx の 3 つの側面
52. DevEx の 3 つの側面 フロー状態： 活動を行っている人がエネルギーに満ちた集中力、完全な関与、楽しさの感覚に完全に浸っている精神状態を指 す。分かりやすく言うと、ゾーン状態です - 綿密な作業に多くの時間を割いている開発者は、専用の時間がない開発者に比べて生産性が 50% 高いと 感じています - 時間をかけて深い作業に費やすことは、開発者が真の生産性を発揮できるようにするという点で、大 きな利益をもたらす。開発者やチームが集中する時間を確保するよう奨励することが重要であり、開 発者やチームの環境は中断を最小限に抑えてこの実践をサポートする必要があります - 自分の仕事に魅力を感じている開発者は、仕事が退屈だと感じている開発者に比べて、生産性が 30% 高 いと感じています - ここでは、チーム内の個人間、または組織内のチーム間でのタスクの配分を再考することが役立ちま す
53. DevEx の 3 つの側面 フィードバックループ： 実行されたアクションに対する応答の速度と品質を指す。より短いリードタイムを維持している組織は、競合他社に 比べてパフォーマンス目標を超える可能性が 2 倍高いことが一貫して示されています - コードレビューの所要時間が速いと報告する開発者は、所要時間が遅いと報告する開発者に比べて、革新 的であると感じています。コードレビューが迅速に完了することで、開発者やチームは次のアイデアにすぐに 移ることができ、次の素晴らしいものを思いつくための準備が整えられます - 緊密なフィードバックループは、別の前向きな結果をもたらします。開発者の質問に対して迅速に応答する チームは、応答が遅いチームよりも技術的負債が 50% 少ないと報告されています。開発者が繰り返し質問 する内容を文書化したり、開発者が必要な回答に簡単かつ迅速にアクセスして、コードを作成する際に適切 なコーディング手法とソリューションを統合できるようにツールを導入したりすることは有益です。これにより、 技術的負債が軽減されます
54. DevEx の 3 つの側面 認知負荷： 開発者がタスクを完了するために必要な精神的処理の量を指す。認知負荷が低いと、開発者、開発チーム、および その組織にとってより良い結果が得られるという仮説が立てられています - 作業しているコードを高度に理解していると報告した開発者は、理解度が低い、またはまったく理解していな いと報告した開発者よりも 42% 生産性が高いと感じています。これは、チームが迅速に行動する必要があ り、コードを明確、シンプル、または十分に文書化することを見落としている場合によくあるパターンです。 チーム内およびチーム間でコードを理解できるようにするツールと規約は、将来の生産性を保証します - ツールや作業プロセスが直観的で使いやすいと感じている開発者は、不透明なプロセスや理解しにくいプロ セスを持つ開発者と比べて、自分たちが 50% 革新的であると感じています。直感的でないツールやプロセス は、個人やチームの創造性を大きく妨げます
55. どんな成果が得られるのか？
56. どんな成果が得られるのか？ フィードバックループ、認知負荷、フロー状態が改善されると、 個人、チーム および組織のパフォーマンスの成果向上が見込めます
57. どんな？
58. どんな？ 個人（開発者）の成果： 個々の開発者に利益をもたらす。特に作業設計の改善が、 仕事のパフォーマンス、創造 性、学習、燃え尽き症候群の軽減 にプラスの影響を与えます
59. どんな？ チームの成果： 個々の開発者に利益をもたらす可能性があります。作業設計の改善が、 コード品質と技 術的負債の解消に繋がり、チームに利益をもたらします
60. どんな？ 組織の成果： 組織の成果は労働者の雇用主に利益をもたらします。開発者の作業の改善が、 組織の 収益性と目標達成能力にプラスの影響を与えます。また、支持するのに役立つ証拠を提 供できます
61. 要するに、
62. 我々開発者にとって より良い作業環境を備えることができれば、 個人、チーム および組織のパフォーマンスの 成果向上が見込めるということです
63. 要するに、
64. フォースタートアップスで働く 開発者の開発者体験(フィードバックループ、認知負荷、フ ロー状態)が向上すれば、 フォースタートアップスの 個人およびチームの開発生産性は上がり、 組織のパフォーマンスの成果向上が見込める よって、日本の進化・我々の働く環境や給与などにもよい影 響を与えていくことでしょう （信じている）
65. これら研究を基にサーベイを設計し、 「開発者体験に関するアンケート調査」 を実施させて頂きました
67. ここまでが、開発者体験の基となる 「DevEx」についてでした
68. 質問タイム （回答できなかったらすみません）
69. 開発者体験アンケート結果報告 （別紙参照）
70. さいごに 6/28~29日で開発生産性カンファレンスが行われるので、参加を予定しています。これ から具体的な改善テーマを考え、みなさん開発者にとってより良い作業環境を備える活 動を行っていく予定です。 このアンケート結果をぜひ改善に活かしてみてはいかがでしょうか。 信じるか信じないかはあなた次第です。 （※四半期に一回、アンケート調査を実施し改善サイクルを回す予定です 󰢛）
71. 参考資料 - SPACE - https://queue.acm.org/detail.cfm?id=3454124 - https://www.infoq.com/jp/news/2021/05/space-developer-productivity/ - DevEX - https://queue.acm.org/detail.cfm?id=3595878 - https://queue.acm.org/detail.cfm?id=3639443 - https://moneyforward-dev.jp/entry/2024/03/07/090000 - Four Keys - https://newrelic.com/jp/blog/best-practices/what-is-four-keys - https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-mea sure-your-devops-performance?hl=ja
72. おしまい ありがとうございました！