『エンジニア組織を強くする 開発生産性の教科書』を読んでみた。
開発生産性向上に取り組むにあたって指標をどうするか悩みどころだったのでそのあたりは参考になりました。
開発生産性はエンジニアリングだけではなくプロダクト全体の生産性を指すというのはなるほど。レベル 1 だけでなくレベル 2/3 も追うということだと思うけど、Findy Team+ のようなツールの数値だけでなく、KPI 達成や売上の変化もちゃんと見る必要があると思われる。
あと、やみくもに数値の改善を図るわけではなくて、開発生産性向上の目的は何か、そのために自分たちにが改善するべき指標はどれなのかを見極めるのが重要そう。
この本を読んでみて、とりあえず、Findy Team+ の指標をどう見てどうアプローチしていくのかざっくり整理できたのでよかった。あとはチーム内で話ながら方向性を調節していくのがよさそう。
以下、読書メモ。(5章以降の事例は流し読み)
第1章
学んだ / 知った
- プロダクトを通じて得られる結果がプロダクトのゴール
- KPI 達成, 売上, 利益
- 開発生産性はエンジニアリングだけではなくプロダクト全体の生産性を指す
- 開発生産性 = 得られた成果物 (アウトプット) ÷ 投入した生産要素 (インプット)
- 自組織にとって何がアウトプットで何がインプットであるか、何を開発生産性と呼ぶのかを明確にする
- 開発生産性のレベル
- レベル1: 仕事量の生産性 → 特定の作業量をどれだけ効率的にこなせたか
- レベル2: 期待付加価値の生産性 → 各施策がプロダクトにどれだけの価値をもたらすか (期待される価値がどの程度リリースできたか)
- レベル3: 実現付加価値の生産性 → タスクがビジネスの目標に貢献できているか (プロダクトにより KPI 達成や売上貢献ができているか)
- 定性的な気付き (日々の仕事に対して課題に感じている部分はないか) x 定量データ
- 戦略ロードマップの策定
- どのような価値を提供するのか
- ユーザーのニーズに合致しているか
- ロードマップの各施策の優先度を測る
- 加重スコアリング
- RICE スコア (reach, impact, confidence, effort)
- よくない状態に対応しなかった場合にどれだけの機会損失が生じるか
- リモートワークによってプロセスが見えにくい → アウトプットやアウトカムに対する見える化が求められる
- 少ないリソースでどれだけのアウトプットを得られるか
- 生産性を可視化することでチームは自分たちで状況を把握して自分たちで改善を進められる
- 作るべきものを間違えてはいけない (提供価値0)
- クラウドの本質的特性
- オンデマンド
- 幅広いネットワークアクセス (クライアントを選ばない)
- リソースプーリング
- 迅速な拡張性と縮小性 (スケールアウト/スケールイン)
- 従量課金
感想 / 意見 / その他
- アウトプット/インプット/開発生産性の定義はシステムの特性やフェーズによって変わりそう
- 実施タスクと期待価値の関係はどうやって検証するんだろう
- なんとなく、レベル1 と レベル2/3 はスコープが違う話に思える
- レベル1 は量にフォーカスした話, レベル2/3 は質にフォーカスした話
- レベル1 から 2, 3 と段階を踏む感じではなく、レベル1 と レベル2/3 は直交する概念のような気がする
- メンテナンス性の向上は開発生産性にも寄与する
- よくない状態への対応は新規機能開発に比べて優先度が下がりがち
第2章
学んだ / 知った
- 何を開発生産性と呼ぶか
- 現状把握 (可視化)
- 定性的な観点
- 定量的な観点
- Four Keys (DORA メトリクス)
- デプロイ頻度
- 変更のリードタイム
- 変更失敗率
- 平均修復時間
- SPACE フレームワーク
- Satisfaction and Well being (チームメンバーやステークホルダーの満足度と幸福度)
- Performance (生産性/効率)
- Activity (チームメンバーがどのような活動にどのくらい時間を掛けているか)
- Communication and Collaboration (コミュニケーションの質と量)
- Efficiency and Flow (リソースの使用効率)
- 指標の推移やトレンドを把握する + どういう要因で変化しているか
- 開発生産性向上への取り組みを日常の開発プロセスに組み込む (習慣化)
感想 / 意見 / その他
- 定性的な観点で挙げた課題に対して定量的な数値を出すと効率よさそう (やみくもに数値を並べてもしょうがない)
- チームによって重視する指標は変わりそう (自チームがどの指標を重視するか)
第3章
学んだ / 知った
- 開発生産性の定義を明確にする
- 何をインプットとして何をアウトプットとするか
- プロダクトの成長に合わせた技術の見直し
- 技術をどう選ぶかだけでなく活用できているかを定期的に見直す
- セキュリティは日頃の開発から意識する (セキュアバイデザイン)
- 品質面の意識を向上させる
- ナレッジ共有とドキュメンテーションで繰り返しの対応や問い合わせを防止する
感想 / 意見 / その他
- 開発生産性向上の目的をどこに置くか (リードタイム短縮, 品質向上, ...)
- 採用した技術やツールが活用できてるか見直す大事そう
- 開発だけでなくビジネス側のタスクも可視化して進捗を管理する必要あり
- ドキュメント作成をタスクに含めたりレビュープロセスのチェック項目に含めるのやりたい
- 開発生産性の指標には事業目標とかも加味した方がよさそう
- この章の内容が開発生産性向上のトラブルシューティングに使えそう
第4.1~4.3章
学んだ / 知った
- 計測したあとに改善しやすい指標を選択する
- 計測結果が事業にどれだけ貢献したか
- 組織全体のパフォーマンス向上に寄与する指標かどうかz
- Four Keys
- デプロイ頻度
- 変更のリードタイム
- 変更失敗率
- 平均修復時間
- デプロイ頻度 = 価値提供のスピード, 開発プロセスの効率性
- 適切なデプロイ頻度はチームやプロジェクトによって異なる
- 大きなタスクを小さなインクリメントに分割する
- 失敗の定義 (何をもって失敗とするか)
- システムダウン
- パフォーマンス劣化
- ユーザーからの問い合わせ
- 障害の定義 (何をもって障害とするか)
- サービスダウン
- 機能低下
- 障害発生期間の開始と終了をいつとするか
- 最初のエラー発生時点
- 最初のユーザー問い合わせの時点
- すべてのコードを均等にテストするのではなく重要度に基づいてテストの優先順位を決める
感想 / 意見 / その他
- ユーザー価値や事業貢献との関連性を評価するの難しそう
- 「顧客からのフィードバックへの対応時間」はどうやって計測するのか
- デプロイ頻度はただ上げればいいわけではなく適切な状態 (頻度と1回のデプロイの変更量) を維持することが大事そう
- 変更失敗率には問い合わせの数なども加味した方がいいのかしら
- 平均修復時間は Findy Team+ だけだと正しい値の計測が難しい気がする (結局、first commit からマージまでの時間なので調査や方針検討の時間が加味されてなさそう)
- テストの選択的実行よさそう
