期待付加価値の生産性向上 株式会社クライド 陶山大輝

自己紹介 ● 2022/10 ~ DevOps エンジニア ○ 開発者体験の向上 ○ ビジネスサイドとの連携改善 ● 2023/03 ~ TPM/PO

目次 ● 開発生産性とは ● 仕事量の生産性向上 ● 期待付加価値の生産性向上 ● 最後に

開発生産性とは

開発生産性の3階層 ● 仕事量の生産性 ○ 時間あたりの、仕事量 ● 期待付加価値の生産性 ○ 時間あたりの、価値を期待される仕事量 ● 実現付加価値の生産性 ○ 時間あたりの、実現できた価値 参考：開発生産性について議論する前に知っておきたいこと - Qiita

開発生産性への考察 ● 仕事量の生産性 ○ エンジニアに閉じた問題として解決しやすい部分 ○ → エンジニアの主な関心 ● 期待付加価値の生産性 ○ ビジネスサイドとの連携により解決できる部分 ○ → エンジニアとビジネスサイドの主な関心 ● 実現付加価値の生産性 ○ 任意の部門との連携により解決できる部分 ○ → ビジネスサイド（特に経営層）の主な関心

仕事量の生産性向上

仕事量の生産性 ● 課題 ○ 予定のリリース日から月単位での遅延の発生 ■ → 仕事の生産性へより責任を持つ必要がある

仕事量の生産性 ● 目的 ○ 開発者体験を向上させ、仕事量の生産性を上昇させられる状態にする ● 目標 ○ PRのオープンからマージまでの時間：24h以下 ● 戦略・戦術 ○ 生産性を可視化する ■ Finy Team+を利用し、2週間ごとにチームの生産性を計測し、議論 ○ 開発者体験の向上に寄与する施策を実行する ■ CDパイプラインの構築 ■ レビュー体制の改善 ● ピアレビューの採用、レビューの優先順位の見直し、など

仕事量の生産性 ● 結果 ○ 開発者体験は向上 ■ PRのオープンからマージまでの時間：25.0h → 10.5h ● レビュー体制変更の影響で、92.3hまで一時は増加（2022/12 ~ 2023/01） ■ レビューされずにマージされた割合：83.6% → 29.4% ■ → メンバー間での体験の良さについてのコメントが増える ■ → 社内で開発者体験の良さが評価され、真似するチームが出てくる 参考：2022/08 ~ 2022/09 と 2023/02 ~ 2023/03 の比較

期待付加価値の生産性向上

期待付加価値の生産性 ● 課題 ○ 開発の際のユーザー視点の欠如 ○ 開発の際の事業視点の欠如 ○ → 課題の解像度を上げる必要がある

期待付加価値の生産性 ● 目的 ○ ビジネスサイドと連携しやすい状態にする ● 目標 ○ ビジネスサイドとの連携への解像度が低いため設定できず ● 戦略・戦術 ○ ビジネスサイドの状態を把握する ■ 2週間ごとにPMとエンジニア間で課題を共有し、議論 ○ ビジネスサイドとの連携に寄与する施策を実行する ■ リソースの問題で十分な施策は実行できず ■ 参考：ビジネスサイドとの連携の改善｜Daiki Suyama

期待付加価値の生産性 ● 結果 ○ 単発の施策では改善が難しいことがわかる ■ 開発の際のユーザー視点の欠如 ● PM含め開発チームの役割定義が曖昧（組織） ● 仮説検証が開発フローに組み込まれていない（開発フロー） ■ 開発の際の事業視点の欠如 ● PM含め開発チームの役割定義が曖昧（組織） ● ロードマップが十分でなく一貫性のない開発が進む（開発フロー）

最後に

重要な考え方 ● 構造的な視点を持つ ○ 根本的な問題の解決により、全体最適をすることができる ○ 効果的な解決策に取り組みやすく、効率よく改善することができる ● 例 ○ 戦略的に考える ■ 課題 → 目的 → 目標 → 戦略 → 戦術 ○ 多層的に考える ■ 外部環境 → 組織全体 → 部署 → チーム → 個人 ○ 時間的に考える ■ 5年 → 3年 → 1年 → 1ヶ月 → 1週間

現在の戦略・戦術（一部） ● 開発方法の見直し ○ 機能の作成方法の見直し ■ PRDの導入と運用 ■ ディスカバリー用のMTGの設定 ■ INVESTの原則に従ったPBIへの変更 ○ 進捗管理方法の見直し ■ スプリントゴールの明示によるマイクロマネジメントの撤廃 ■ ロードマップによる徹底的な管理 ○ → デュアルトラックアジャイルの実現 ● 組織体制の見直し ○ PMの役割の明文化 ○ スクラム開発チームの再組成 ○ → 自律分散型組織の実現

ご静聴ありがとうございました！