[[📒開発生産性Conference 2024]] ## 💭参加した感想 - まずこれまでの自分の行動に反省。 - 例) [[🗃️リードタイム]]は短いほうがいいので注視しよう - 人によって開発生産性が指すものが異なってくるので、さきに数値から入るのではなくて、「自分たちがどうなっていたいのか」、「目指しているゴールはなにか」というところから考える必要がある。 - その認識をチームで揃えずに定量的な数値を追っても、ただ余計な管理コストを増やすだけになりそう。 - いろんな人がいっていたけど、開発生産性をチーム外からの声でいれるのは危険。開発者、開発チームが自分たちのパフォーマンスを知るために導入するのがよい。 - なんでチーム外の人たちは開発生産性を取りたいのか？取らせたいのか？ - 開発チームへの不信感、やっていることが事業に価値があるか見えてこないからである - なので、[[🗃️Four Keys]]をただ測るのではなくて、自分たちがやっていることが事業に貢献していることを証明していく必要がある - 必ずしも生産性を測る数値でなくてもよくて、ちゃんと事業の最終ゴールから逆算して設定されたゴールを着実に達成していくでもいいのかもしれない - 本来、スクラムは↑の状態を目指している。それが[[🗃️スプリントレビュー]]。 - [[🗃️物的生産性]](アウトプット、アクティビティ)ではなくて、[[🗃️付加価値生産性]]を追っていくべき。 - より少ないコストで、[[🗃️アウトカム]]を大きくしていくことが大事 - アクティビティや、アウトプットを増やせば、顧客への届けられる価値も増えるというのは、あくまで仮説にすぎない。 - 作っているものが価値があるとわかって、はじめて物的生産性をあげることが、アウトカムにつながるというロジックが成り立つ - ↑がわかっていないと、顧客に価値のないもの(ゴミ)を大量生産することになってしまう。 - だからこそ、まずは顧客への[[🗃️アウトカム]]に集中するようにするのが大事 - 効率性ではなくて、もっと顧客の価値に注力しようという気持ちになった - タスクをやるときに、これって顧客の価値につながっているのか考える - 顧客に価値が届けられているのか、なりたいチーム像になれているのかを客観的に把握するために定量的な数値も扱えるようになっていきたい ## 👍 Pickup ### [[🎫プロダクト拡大フェーズでプロダクト検証サイクル効率化を目指す過程で見えたもの]] #### 感想 - 理想の[[🗃️チーム]]像が共感できた。エモかった。 - 「チーム間ではチームを1人格とする」という考え方よい - チームメンバーの得意を強みにして、個人特性を才能として扱うという考え方が好き - チームが同じ命綱で進むというたとえもわかりやすい - ボトルネックのペースにあわせる -> ドラム - [[🗃️リードタイム]]に適度な余裕を持つ -> バッファ - 早すぎる仕掛を防ぐ -> ロープ - 古参のメンバーに頼りすぎる状況をなくすために、[[🗃️リファクタリング]]は最古参のメンバー以外で進めて、他のメンバーのプロダクト理解を促進した事例は参考になりそう ### [[🎫価値創造と開発生産性]] #### 感想 - Aチーム、BチームのFour Keysを比較してもどちらが生産性が高いかはわからない - Aチームがいくら開発が速くてもゴミを作っているだけなら生産性が高いとはいえない - 同一チームの数値の変化を比較するのは役に立つ - 開発生産性で大切なのは数値よりもコンテキストが大事 - 開発したい課題を明確にしてから、意味のある数字を使う - 目標で使われる[[🗃️SMART]]は、Measurable(測定可能か？)が強調されるけどRelated(関連性があるか？)のほうが大事 - まず計測すべきは価値創造ができているか - [[🗃️ゴール]]の達成が目指すべきところ - [[🗃️ゴール]]が達成できているのであれば、タスクは全ておわらなくていいし、アウトプットの量も気にしなくてよい ### [[🎫開発生産性をあげる改善って儲かるの？に答えられるようにする]] #### 感想 - 本来、開発チームへの信頼が高ければ、[[🗃️開発生産性]]は不要である - すれ違いの発生箇所として、エンジニアの見積もりを信じて計画を作るけど、毎回見積もりからズレて遅れる。そうすると開発チームへの信頼が下がることになる - 「なぜ遅れたか？」は数値化しにくい -> なぜ遅れたかかちゃんと事実を提示できていないなと反省。 - [[🗃️開発生産性]]を議論するときは、どこのフロー、どこのプロセス、どこのレイヤー、生産性をあげてなにをしたいか？を整理しないとズレが生じる - 経営層やマネージャー層が知りたいのは、開発チームのやっていることがちゃんと事業貢献につながっているかをみたいはず。とりえあず[[🗃️Four Keys]]で開発チームが語ると、お互いの話していることにズレが発生しそう。 - P/L(損益計算書)で開発チームがやっていることを語れることは重要そう - 開発生産性をあげると、 - 無駄な費用が減る - (作るものが一定の価値のあるものである前提がある場合)開発の速さは売上に繋がる - [[🗃️ソフトウェア]]は資産である - リリースされたら減価償却が始まる -> 資産としての価値は下がっていく - [[🗃️リファクタリング]]は、ソフトウェアの耐久年数を延長させる -> 資産の価値を保つことになる - こう考えると、リファクタリングもB/S的に見て価値のある活動に見える - 問い合わせ対応などは、資産を増やすことにも耐久年数を延長させることにもならないので、できる限り減らせるといい気がする ### [[🎫爆速開発文化を支えるProduct Engineerの開発生産性向上の取組み]] #### 感想 - アウトカムスコア定義をして、1スプリントごとのアウトカムを計測している - [[🗃️アウトカム]] = 要望企業数 / 開発コスト * 業務インパクト - [[🗃️アウトカム]]0のタスクも発生する。-> [[🗃️アウトカム]]を増やすにはという議論が生まれる - 開発生産性を向上させる取り組みがどれもよい - 改善デー - 定期的(月1くらい？)に日頃から気になっているけどなかなかできない細かい修正をする - 開発者の精神衛生を保つ効果ありそう。細かい気になりが処せるの楽しそう。こういう日が設けられているだけでも、気持ち楽な気がする - [[🗃️コードレビュー]]ガイドラインの策定 - レビューアーに期待すること、レビューイーに期待することを書いておく - レビューアーに期待しないことを定義しておく - バグの発見、仕様に沿って実装されていることはレビュアーに期待しないみたい - でもこれを定義しておくことで、実装者が質を担保して実装することになる。あと、レビュアーのレビューで細かく見るコストが減ったらしい。 - レビューガイドは、非同期で決めたとのこと - まずメンバー全員に意見を出してもらって、すりあわせたらしい。 ### [[🎫開発生産性の観点から考える自動テスト]] #### 感想 - なぜテストを書くのか？の[[👤和田 卓人(t_wada)]]さんの回答がとても腑に落ちた - 素早く躊躇なく変化し続ける力を得るため - テストの分類がアイスクリームコーンになるのはアンチパターン - 手動テストや、[[🗃️E2Eテスト]]が多くてユニットテストが少ないみたいなケース - E2Eテストは、不安定だし、コストがかかる -> [[🗃️アジリティ]]は下がってしまう - これは本来の自動テストの目的とずれてしまう - だからE2Eは本当に重要なケースのみを担保したり、デプロイには影響内容にするのがいいんだろうな