#Book [[📒エンジニア組織を強くする開発生産性の教科書]] ## 2.1 現状の可視化 ~課題の優先付け~ ### 2.1.1 [[🗃️開発生産性]]に対する理解をチームで深める - [[🗃️開発生産性]]をなぜ高める必要があるのか - 自分たちにとってどのようにポジティブな結果につながるのか ### 2.1.2 [[🗃️開発生産性]]の現状を可視化する - 認識のすり合わせ - 何に課題を持っているのか - まずは定性的な観点から「理想の状態」について抽象的な議論を行なってみる - 定性的な観点での現状認識 - [[🗃️開発生産性]]についての共通認識 - 現状の課題感 - [[🗃️開発生産性]]が高い状態についての共通認識 - 取り組みのアイディア - 定量的な観点での現状認識 - 将来的に、レベル2、レベル3を追っていくことが必要になる - まずは[[🗃️仕事量の生産性]]から確認していく - [[🗃️Four Keys]] - 追いやすい指標は、[[🗃️デプロイ頻度]] - [[🗃️SPACE]] - [[🗃️Four Keys]]の指標だけでは見えない側面も評価できる - どちらかのフレームワークではなく両方の指標をみることで、より多角的な評価ができる - 他の組織の事例を鵜呑みにしても意味がない - 💭ちゃんと何のために、どこを目指して数値を取るのか認識揃えないと、うまくいかないよな〜という肌感はあるので納得 ### 2.1.3 改善すべき課題の特定と優先順位付け - 可視化された指標の確認 - チームでの課題の洗い出しと、原因特定 - 原因の深掘り - 課題への対策の立案 - 例 - タスクサイズが大きい場合はタスクを分割する - 同じPRで複数のタスクをこなさないようにする - 課題の優先順位付け - 影響の大きさ - 課題の緊急度 - 解決の難易度 ## 2.2 [[🗃️目標設定]]と改善の実施 ### 2.2.1 [[🗃️目標設定]]と改善案の立案 - [[🗃️KGI]]を決めておく - その後、[[🗃️KPI]]を明確にしておく - 💭ここはちゃんとなりたい姿を自分たちで定義してからやらないと、数値ありきになってしまいそうなのでそこは注意したい - 達成可能な[[🗃️目標]]を設定する - [[🗃️SMART]] - 組織や個人の目標と関連性を持たせ、期限を明確にすることで計画を立てやすくなる - [[🗃️個人目標]]の考えかた - なるべく自分でコントロールしやすいものを選ぶ - 影響範囲が自分のみで狭いと、チームが追いかけたい指標から少し離れてしまうケースも出てくる - [[🗃️チーム目標]] - 1人の力では達成できないものが適切 - [[🗃️Four Keys]]は一人では完結しないものの1つ - 実行計画を共有する - 改善策の立案 - 改善策の実施スケジュール ### 2.2.2 改善策の実行と[[🗃️モニタリング]] - [[🗃️レトロスペクティブ]]のタイミングで、指標を洗い出し、振り返りをする - 週報や日報のタイミングで集計したものを振り返る - [[🗃️Slack]]に通知する - 改善策の実行を管理する - 予定されている期日に対し、計画通りに進んでいるかどうかを管理することも重要 - 定性的な観点で効果を確認する - チームメンバーへのヒアリングやアンケート - 自身のモチベーションに変化があったかを確認する - 改善策を調整する ### 2.2.3 改善効果の評価と次のサイクルに向けた方針の更新 - 改善策の効果を評価する - 改善案の立案時に設定した目標と、実際の達成値を比較し、目標の達成度を評価する - 何を持って成功とするのか？どの程度できたら、チームとして評価するのかを決めておく必要がある - 改善プロセスの振り返りを実施する - 改善策の立案から実行、モニタリングまでの一連のプロセスの振り返り、うまくいった点、うまくいかなかった点を洗い出す - 改善策の修正を検討する ### 継続的な改善への意識付け - 日常的な開発プロセスとして組み込む - メンバーのモチベーションを維持する - 成果の可視化と称賛 - 個人の貢献の認知と評価 - 学習と成長の機会の提供 - チームメンバーを大切にする - 継続的な改善活動はチームメンバーにストレスがかかる可能性がある - 適切なタイミングで休息を取り、リフレッシュする機会を設ける