生産性の可視化について
そもそも生産性は測れない
数値をよくしても悪影響になるケースもある
アウトプットではなくプロセスを計測するべき
何を計測するか、誰のために計測するか
データが全ての状況を伝えるというわけではない
計測やデータ化ではなく課題解決に時間をかけるべき
開発生産性はエンジニアだけのものではなくなった
事業的観点では開発生産性向上とは利益損失の最小化のこと
そもそも経営層にとっての開発生産性は「販管費」とか「資産」、責任者は「コスト」とか「工数」、開発は「人月の生産性」
レイヤーによって開発生産性の共通認識が違うので、次元を変換して開発生産性を接続してあげる必要がある
摩擦を減らすにはお互いの信頼を獲得すること
見積もりの不完全生による事業計画のずれ
経営者：エンジニアの見積もりを信じて計画を作るのに毎回遅れる。ただ、なぜ遅れるかわからない。リカバリーのために人件費（エンジニア、PM）を投入して解決しようとする。
開発者：見積もりはそもそも外れるという共通認識がある。遅れた事実は分かり易いのに遅れた原因は数値化しにくい。エンジニアを大量投入されても人月の神話状態で解決してない。根本解決のためにも内部品質の改善に予算を使いたいが結果が出るのに時間がかかるので理解が得られない。
開発の投資対効果を図るのは難しい
リリース直後に数値（例えば売上）が出ればその先の予算どりなどもし易い→見え易いし測り易い
リファクタリングなどは1年後や数年後を見据えてやることが多い。今やるべきことは多いがリターンは不確かで不安定。→見えにくく計りにくい
失敗とは見積もりの失敗である
納期が遅れたとか予算オーバーとかでプロジェクトが失敗したというよりも失敗したのは見積もり。
何が成功として図ることができるのか。それを図ることは不可能に等しい
エンジニアのフロー状態は見落とされる
開発者はタスクの進捗やコンテキストの切り替えや中断が少ない時に生産的だと感じる
しかし実際は、絶えずコンテキストを切り替えていて、1時間に何度もこれを行なっている。開発者は平均して1時間に13回のタスクを切り替えている。
タイムボックスの違いの大きさ
マネージャーは1時間区切りでタスクをこなす
エンジニアは半日単位でタスクをこなす
開発生産性を下げる要素
説明責任を果たさないと負のループは終わらない
見えにくく計りにくい部分を以下に説明するか
信頼があればそこの理解も得られているはずなので開発速度は気にならない
生産性が低いチームを強くする順番
アウトプットを上げた後にアウトカム（価値結果）を考える
組織や制度が数値向上を目標にすると多少なりとも圧がかかり数値を作るためだけに行動する
状態が数値を作り、数値が状態を作るわけではない
他者と比較することは無意味。過去の自分たちと比較していく
つようエンジニアを採用するのは困難で時間がかかる、既存の開発リソースを最大化させることは明日からできる
所感
開発生産性ってよく言われるけど見てるレイヤーによって視点が全然違う。
この手の話はメンバー（エンジニアやPM）だけではなくてクライアントにも理解してもらって初めて動きやすくなる気がするけど、そのためのコミュニケーションが必要そう。エンジニアからPMに理解してもらうための説明はPMからクライアントに理解してもらうための説明にそのまま適用できないので、それぞれがそれぞれを理解し合おうとする姿勢や、結局は信頼が必要なんだろうなと思う。