#Book [[📒エンジニア組織を強くする開発生産性の教科書]] ## 4.1 指標選択の考え方 ### 4.1.1 考慮すべきポイント - 1. 計測の難易度 - 簡単に計測できるかどうか - 2. [[🗃️開発生産性]]への影響度合い - 計測した後に、その指標を改善しやすいかどうか - 変動の原因が特定しにくい指標は導入初期は避けた方が良い - 自分たちがコントロールできる指標を選ぶことがおすすめ - 3. ユーザー価値や事業貢献との関連性 - 計測結果が事業にどれだけ貢献したか - [[🗃️損益計算書|🗃️PL]]に直結する指標なのか - 4. 改善可能性 - 指標が悪化した場合にどのような改善アクションを取れるかを考慮する - 5. わかりやすく受け入れられやすい指標か - 6. 中長期でビジョンに沿った指標になっているか - 7. 全体最適の視点 ## 4.2 [[🗃️Four Keys]] ### 4.2.2 [[🗃️デプロイ頻度]] - 計測しやすい、わかりやすい、改善が見えやすい - 価値提供のスピードを表す重要な指標 - [[🗃️デプロイ頻度]]が高いということは、コードの変更からリリースまでのサイクルが短いということ - 適切なデプロイ頻度 - チームによって異なる - 1日に複数回の[[🗃️デプロイ]]が望ましいかも ### 4.2.3 [[🗃️変更のリードタイム]] - 開発のスピードを示す - 無駄な待ち時間がない - 改善方法 - [[🗃️モブプロ]] ### 4.2.4 [[🗃️変更失敗率]] ### 4.2.5 [[🗃️平均修復時間]] - デリバリーの安定性を示す指標 - [[🗃️システム障害]]検知の仕組み、対応プロセスの改善により改善できる ### 4.2.6 [[🗃️Four Keys]]は良い指標だが万能ではない - [[🗃️Four Keys]]の指標は相互に関連している - バランスの取れた改善を行うことが重要 - [[🗃️組織文化]]も[[🗃️Four Keys]]のパフォーマンスに影響する - 失敗を恐れない文化 - 協力的な文化 - 学習と実験を奨励する文化 ## 4.4 [[🗃️開発生産性]]に直接的に結びつく指標 - [[🗃️要件定義]]フェーズ - [[🗃️システム要件|🗃️要件]]が十分に[[🗃️ドキュメンテーション]]されているか - 開発中に[[🗃️システム要件|🗃️要件]]が変わらないか - [[🗃️設計]]・実装フェーズ - マージ時間 - [[🗃️自動テスト]]のコードカバレッジ - [[🗃️バリューストリーム]]指標 - [[🗃️バリューストリームマッピング|🗃️VSM]]の作成をすることが有効な手段 - 待ち時間が長いプロセスを特定する - 指標 - [[🗃️サイクルタイム]] - 価値のある[[🗃️フィーチャー]]の割合 ### 4.4.5 [[🗃️組織文化]]指標 - [[🗃️エンゲージメント]] - 愛着や貢献意欲を示す - [[🗃️職務満足度|🗃️従業員満足度]] - 仕事や職場にどの程度満足しているかを示す - [[🖇️開発者体験サーベイ、めっちゃよかったんで、おすすめです - Money Forward Developers Blog]] ## 4.5 [[🗃️開発者体験]]と[[🗃️SPACE]]フレームワーク - 満足度と幸福度(Satisifaction and well-being) - [[🗃️開発者]]は自分の仕事にやりがいを感じているか？ - ワークライフバランスが適切に保たれているか？ - [[🗃️多様性]]が尊重される環境か？ - パフォーマンス(Performance) - [[🗃️Four Keys]] - 活動(Activity) - コードの変更頻度 - [[🗃️コードレビュー]]の活発さ: コメントや参加人数 - [[🗃️技術的負債|🗃️技術負債]]の蓄積情報: コードの複雑度や重複度 - [[🗃️開発者]]の割り込み状況 - コミュニケーションとコラボレーション - 知識共有の活発さ: [[🗃️ドキュメンテーション]]の充実度 - チーム間のコラボレーション - コミュニケーションツールの活用度 - [[🗃️心理的安全性]] - 効率とフロー(Efficiency and flow) - 開発環境のセットアップ時間 - ビルド・テストの自動化率 - 割り込みの少ない集中時間の確保 - ツールやプロセスのシームレスな統合 -