開発者の生産性の測定方法にどんな方法があるのかを調べる
i-hrm個人としてもそうだし、チームとしても高い生産性を発揮するためには生産性自体を測定可能な状態にしたい
現状が把握できないと改善点もわからないし、また現時点に課題があることすら把握ができない
そういうことはなくしていきたいので生産性についてどのような測定方法が存在するのかを調べる
まずはOKRはよく聞くのでこれについて押さえる
目標と主な成果（Objectives and Key Results、略称OKR）は、個人、チーム、組織が測定可能な目標を定義し、その成果を追跡するために使用する目標設定のフレームワークである。OKRの開発は、一般に、在職中にインテルにこのアプローチを導入したアンドリュー・グローブによるとされている[when?] ジョン・ドアは、「Measure What Matters」と呼ばれるOKRの本を出版している。2017年にGoogle、Bono、Gates FoundationがOKRで世界を揺るがす方法[1]と呼ばれるOKRの本を出版した。
近年では開発者の生産性を計測するフレームワークとしてSPACEが提案されている
i-hrm
DeepL翻訳、途中でコピペに疲れたので放棄している
What Is Developer Productivity?
開発者の生産性とは、簡単に言えば、開発者が任意の時間枠/指標においてどれだけ生産的であるかということです。企業は、追跡したい目標や指標（例えば、修正されたバグやコードレビューの実施など）を作成し、何が許容範囲なのかの基準値を得ることができます。そして、その結果に基づいて開発者を評価し、生産性を把握することができます。IanとMarkが1日に5回デプロイしているのなら、Steveはなぜ3回しかデプロイしていないのでしょうか？会社レベルでの非効率的なプロセス、対処可能な行動、またはスティーブを助けるために導入可能な生産性ツールはないだろうか？
これらの測定基準に加えて、ソフトウェア開発者の生産性を測定するために、異なるフレームワークを採用する複数の方法があります。例えば、以下で説明するSPACEフレームワークを使用することもできますし、OKRを使用することもできます。
ああ、OKRですね。これには2つの問題があります。
まず、率直に言いますが、技術的負債は悲しいことにほとんどの企業で問題になっています。私たちは、新機能がOKRの主な、まあ、特徴である例を数え切れないほど見てきました。技術的負債が置き去りにされ、ゆっくりと積み重なり、開発者の血圧を急上昇させる。もし、正しい方法でOKRを行いたいのであれば、技術的負債を是正・除去するための時間とスペースを確保することである。
次に、多くの企業が実際にGoogleやMicrosoftになることなく、GoogleやMicrosoftのように速く移動したいと考えているため、リソースや適切なツールの不足は、開発者やDevOpsチームに計り知れないプレッシャーを与える可能性があります。Googleにならなくてもいいのです。規模を拡大すればいいのです。ソフトウェア・エンジニアの間で起こっている「チャンク・アンド・バーン」問題の一部にならないようにしましょう。
What is SPACE?
開発者の生産性は、単一の指標で定義できるものではありません。例えば、開発者一人当たりのアウトプット数だけで開発者の生産性を評価しようとすると、重要な文脈を見落とすことになります。開発者の勤務時間が遅いかもしれないし、アウトプットの品質が低いかもしれないし、顧客価値の低い単純な機能かもしれません。生産性を明確に把握するためには、いくつかの異なるストーリーポイントをマッピングする必要があるのです。Nicole Forsgrenは、GitHubとMicrosoftの他の研究者とともに、SPACEフレームワークを作成することによってこの問題に取り組みました。
S: 満足と幸福
P：パフォーマンス
A：アクティビティ
C：コミュニケーションとコラボレーション
E：効率とフロー
このフレームワークは、開発者の生産性を全体的に把握するのに役立ち、管理者が変化を評価するためのツールになります。
Satisfaction And Well-Being
開発者は、何よりもまず、人間です。その生産性は、仕事、チーム、文化にどれだけ充実感を感じられるかに影響されます。さらに言えば、その人の生産性は、全体的な幸福感や健康状態にも影響されます。
満足度と幸福度を評価するためには、開発者にとって何が重要かを理解することが重要です。インパクトのあるプロジェクトで働くこと、コードが顧客に利用されるのを見ること、インスピレーションを与えてくれる同僚と働くことなどは、すべて職場の満足度を高めることにつながる例です。
主な指標をいくつか紹介します。
- 従業員満足度。開発者が自分の仕事にどれだけ満足しているか。
- 開発者エフィカシー。仕事を完成させるために必要なツールやリソースへのアクセス。
- 燃え尽き症候群。仕事に対する疲労感。
Performance
開発者のパフォーマンスは、彼らの仕事の成果である。ビジネスの成果は開発者の成果とは直接結びつかないことが多いので、これを測定するのは難しいかもしれません。ビジネスの成果には、セールス、マーケティング、顧客満足度など、さまざまな要素が絡んできます。このため、焦点を当てる成果は、ビジネスと開発者の両方に特化したものにする必要があります。
開発者に特化したもの：品質、信頼性、バグのなさ、サービス全体の健全性。
ビジネス固有：顧客満足度、採用率、機能使用率、コスト削減。
Activity
開発者アクティビティとは、作業中に行ったアクションやアウトプットの数である。ここで得られる洞察は確かにあるが、より限定的かもしれない。たとえば、開発者が1日に行うすべてのアクションを測定することは事実上不可能ですし、それらのアクションが高品質であるかどうかを判断することも困難です。
測定可能な活動の例としては、以下のようなものがあります。
設計書や仕様書の量や数、プルリクエスト、コミット、コードレビュー、ビルド数、デプロイ頻度、インシデントの軽減など。
Communication And Collaboration
開発者は、最高品質の生産性を生み出すために、効果的なコミュニケーションとコラボレーションを行う必要があります。ソフトウェア開発は本質的に創造的なプロセスであり、同僚からの絶え間ないフィードバックやアイデアの提供を必要とします。コミュニケーションとコラボレーションは、開発者全体の満足度にも大きく関わってきます。
企業は、開発者の入社時の経験、レビューの質、開発者同士のつながりを見ることで、コミュニケーションとコラボレーションを評価することができます。
Efficiency And Flow
開発効率やフローとは、開発者がどれだけ中断されることなく継続的に進歩できるかを示すものである。"フロー状態になる "ということは、誰もが経験するか、聞いたことがあるはずです。フロー状態になるには、最小限の気晴らしで連続して仕事をする空間が必要です。
また、フロー状態になることと同様に、情報や知識の流れも重要です。重要な人材が知識のサイロ化によって失われ、企業の基本的な業務遂行能力に支障をきたす可能性があります。例えば、ソフトウェア配信の知識を持つ開発者が一人、サイロの中で作業していると、他の全員にソフトウェア配信の健全性についての情報が全く伝わらないことになります。
効率とフローを把握するために使用できる指標には、以下のようなものがあります。
プロセスで必要とされるハンドオフの数。
迅速かつ効率的に作業を完了させる能力
システム全体の所要時間、プロセス間の所要時間など。
i-hrm会社レベルでの非効率的なプロセス、対処可能な行動、またはスティーブを助けるために導入可能な生産性ツールはないだろうか？
生産性を上げるためにはツールの導入だけではなく、必要に応じてソーシャルサポートを選択することも必要
多くの企業が実際にGoogleやMicrosoftになることなく、GoogleやMicrosoftのように速く移動したいと考えているため、リソースや適切なツールの不足は、開発者やDevOpsチームに計り知れないプレッシャーを与える可能性があります。
Google規模の企業ではないのにGoogleのように開発チームは振る舞えないかを考えてしまっているのは違う
開発効率やフローとは、開発者がどれだけ中断されることなく継続的に進歩できるかを示すものである。
割り込み業務とかはフロー状態の妨げになる
あとはslackの確認頻度なども関係性はありそう
i-hrm作業の並列化と作業あたりの時間を短くする事が必要