開発生産性
3つのレイヤーでとらえる
レベル1：仕事量の生産性
レベル2：期待付加価値の生産性
リリースした施策にどの程度の価値があったのかを評価するのには時間がかかるため、プロダクトチーム全体で価値があると「期待している」施策がどの程度リリースできたのかに注目する レベル3：実現付加価値の生産性
事業部門全体がコントロール
多くの場合、遅行指標になるため、最終的な判断には使うことができますが、リアルタイムな評価には不向き
https://gyazo.com/4e0eea04c5502df9cea1429f840fbf04
https://gyazo.com/0019a8e31174d5ad59b5f2ad7fc659ff
McKinseyは仕事量の測定にのみフォーカスしている
測定にかかるコストについて触れていない
測定することが生み出すネガティブな効果に触れていない
個人の仕事量に関心があるのは誰か？計測している人のみ
Kent
Gergely
コンテキストが大事。まったく同じチームでまったく同じものを作るのでも無い限り、指標の意味するところは変わってくる デプロイが多くて価値提供が早いが障害が多いプロダクト、デプロイが少なくて価値提供が遅いが障害が少ないプロダクトのような2つの良し悪しはFour Keysの指標だけでは決められない チームの開発者が何に時間を何割使うのが最適か？という問いも文脈次第 コーディングせずに計画づくりや教育・学習、インタビュー（面接）に時間を使うのが誤りなのか？
そもそも、開発にあてる時間が増えれば成果が増えるという仮説は正しいのか？（とは？）
前提として、生産量を目的としてはいけない
評価ではなく価値創造のための武器として生産量 / 生産効率を見る
生産性の改善はアウトプット量ではなくプロセスの改善になってきた
開発生産性に関するデータは信頼を作る糸口
チーム外からの信頼が積み重なれば管理・監視の意味合いでの可視化は不要
エンジニアが自分たちのために開発生産性を考えるのが正しい姿
なぜすれ違うのか
事業・経営を行う人は見積もり・予測に従って計画をつくるが外れる 開発組織からすれば見積もりは外れるという共通認識がある
事業・経営を行う人はリカバリーのために動かせる変数が人件費（人員の投入）しかない あとは既存メンバーに対してプレッシャーをかけたり業務調整するなど
開発組織からすれば人月の神話の課題を知っているので人を動かして欲しくない 開発生産性という言葉の勘所
どのフローの話？
リリースまでのリードタイムの話
コストの投資対効果、スループット（予算に対する生産）
どこのプロセスの話？
https://gyazo.com/9f0607963f3f015429edf64cd707b046
どのレイヤーの話？
https://gyazo.com/9148a0f4dcb99e5def09d114c9cf282b
生産性をあげて何をしたい？
正確性と立体感
関係しそうな変数・数値はたくさんあるがどれも近似値にすぎない https://gyazo.com/2d9904637cdcfb9a9f2898c78242bc1e
無理に飛躍して現場の論理や指標を管理会計に繋げてはいけない オーバーラップする箇所の言葉を変換する
開発生産性があがると
費用
固定人件費は変わらない
無駄な開発費用が減る
売上
施策が一定の確率で価値を上げると仮定すると継続的な速さは価値になる
仮説検証プロセスの回転数向上、施策あたりのリードタイム削減
損失の最小化
障害回数の減少、ロールバックの速さ
サーバー費用の最小化
エンジニアはソフトウェア"資産"を作っている
資産を増やす、耐用年数を長くするという観点から入ると良い
https://gyazo.com/57867a4fccd38fb828205f07401adcf7
経営陣との会話で使う指標を変えた
定量的でわかりやすい
プロジェクトの価値を見積もるのは難しい
X万円投資していつ回収できるか？なんて誰にもわからず仮のPLで押し問答
最終的には信頼ベースでGoサイン
プロダクトビジョンと事業戦略の繋がりが明確であれば、プロダクトの機能リリースが新規価値であり、差別化になる
細かい数字抜きに投資すればよいGoサインが出る
プレスリリースの数が増える、対外的にアピールができ、社内のモメンタムを生む https://gyazo.com/0cf462d51f481bf58eccf5391b1632f8
高速にゴミを作っても仕方ない
が、その能力があるのが前提