Upgrade to Pro — share decks privately, control downloads, hide ads and more …

組織横断で生産性向上を生むまでの道筋とは?

 組織横断で生産性向上を生むまでの道筋とは?

2023/04/26 : 【開発生産性 Meetup #1】開発生産性可視化による変化~事例LTから学ぶベストプラクティス~
https://findy.connpass.com/event/279894/

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. 組織横断で
    生産性向上を生むまでの道筋とは?
    開発生産性 Meetup #1
    1
    Masato Ishigaki
    April 25, 2023

    View full-size slide

  2. 2
    About me
    石垣 雅人
    合同会社 DMM.com
    プラットフォーム事業本部 部長 / VPoE室 / アルファ室
    ・略歴 : エンジニア新卒入社 → PjM → PdM / EM → 部長 + 横断 (URL)
    ・ID基盤 / CS-Platform / DMMポイントクラブ / ユーザーレビュー基盤 : PdM
    ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版,2020)
    ・連携 : 『スモールチームが武器になる時代へ』(ProductZine)
    @i35_267
    @i35_267
    @i35_267

    View full-size slide

  3. 3
    - 問題提起
    - なぜ広める必要があったのか
    - 可観測性と再現性
    - 導入アプローチ
    - 2つのMetrics
    - FindyTeam+導入時
    - 良かったところ
    - 他チーム比較による効用
    - 開発手法→生産性の合理性
    - 採用アトラクト
    Outline

    View full-size slide

  4. 4
    - 問題提起
    - なぜ広める必要があったのか
    - 可観測性と再現性
    - 導入アプローチ
    - 2つのMetrics
    - FindyTeam+導入時
    - 良かったところ
    - 他チーム比較による効用
    - 開発手法→生産性の合理性
    - 採用アトラクト
    Outline

    View full-size slide

  5. 5
    なぜ広める必要があったのか
    独立採算の事業部制・カンパニー制
    - 60事業、エンジニア数 700 ~ 1,000名の規模 ※
    - 事業部制・カンパニー制のプロダクトチーム
    - コンウェイの法則、独立したエンジニア組織と文化
    - GitHub Cloud / GitHub Enterprise. 主にGHCの方へ移行中
    ※ DMM.comおよびEXNOA、2022年2月時点

    View full-size slide

  6. 6
    なぜ広める必要があったのか
    強い開発組織になりたい
    Div. x n
    Dev. x n

    View full-size slide

  7. 7
    可観測性と再現性
    強い開発組織のなるための課題(の一部)
    - 組織のサイロ化
    - リソースマネジメント
    - 知見のサイロ化
    - 同じ失敗
    - 車輪の再開発
    - 人が多ければ多いほど深刻
    - 可観測性と再現性
    - まず戦闘力を観測可能にする(Observability)
    - Observe(観測)Ability(能力)
    - 観測可能にすることで”再現性”が生まれる
    Div. x n
    Dev. x n

    View full-size slide

  8. 8
    - 問題提起
    - なぜ広める必要があったのか
    - 可観測性と再現性
    - 導入アプローチ
    - 2つのMetrics
    - FindyTeam+導入時
    - 良かったところ
    - 他チーム比較による効用
    - 開発手法→生産性の合理性
    - 採用アトラクト
    Outline

    View full-size slide

  9. 9
    2つのMetrics
    2つのMetricsと抽象度
    1. コードを書く → レビュー → Approve → CI → マージ
    a. FindyTeam+などを筆頭としたGitHubベースでの可視化
    b. 機能開発だけにフォーカスした数値
    c. Metrics :
    i. プルリク→マージまでの時間,etc…
    2. プロジェクトとしてのバリューストリーム
    a. 工数・工期。ソフトウェアライフサイクル
    b. 実際の機能がリリースされるまでの俯瞰した数値
    c. Metrics :
    i. 開発比率/ 非開発比率 / 運用保守
    Delivery

    2

    View full-size slide

  10. 10
    2つのMetrics
    1. コードを書く → レビュー → Approve → CI → マージ
    a. FindyTeam+などを筆頭としたGitHubベースでの可視化
    b. 機能開発だけにフォーカスした数値
    c. Metrics :
    i. プルリク→マージまでの時間 ,etc…
    2. プロジェクトとしてのバリューストリーム
    a. 工数・工期。ソフトウェアライフサイクル
    b. 実際の機能がリリースされるまでの俯瞰した数値
    c. Metrics :
    i. 開発比率/ 非開発比率 / 運用保守
    ※会社として勤怠と紐付けて推進中
    プロジェクトA

    View full-size slide

  11. 11
    FindyTeam+ 導入時
    Findy Team+ 導入までの流れ
    - 2022/05/24 : 商談開始
    - 2022/06/01 : トライアルチーム選出
    - 2022/06/11 : 稟議作業
    - 2022/06/xx : トライアル終了
    - 2022/07/01 : 契約開始
    導入のコツ
    - 仲間集め→効果測定→稟議→さらに広げる
    - 一番、人がいるOrgへの導入(事業部側の導入コストゼロ)
    - デモ共有会の実施 → 動画共有でアトラクト
    - 費用を一元管理(会計上の話)

    View full-size slide

  12. 1
    2
    - 問題提起
    - なぜ広める必要があったのか
    - 可観測性と再現性
    - 導入アプローチ
    - 2つのMetrics
    - FindyTeam+導入時
    - 良かったところ
    - 他チーム比較による効用
    - 開発手法→生産性の合理性
    - 採用アトラクト
    Outline

    View full-size slide

  13. 1
    3
    “数値を出すことが、すべてではないが
    そこからしか始まらないこともある“

    View full-size slide

  14. 14
    他チーム比較による効用
    1. 技術投資の経済合理性へのちょっとした理解
    Pain
    - 事業部長 :
    - 「開発が遅い」「競合との機能優位性に勝てない」
    - エンジニア :
    - 「依存関係激しく変更行数が多くてアジリティがでない」
    アプローチ
    - 決裁者へのわかりやすい説明
    - 開発工数の短縮、コストダウン
    - 技術投資・デットテックへの価値観 醸成
    - コストダウンを継続的に行う価値観(リファクタリング)
    - 腐敗させると、みるみる数値が下がっていく

    View full-size slide

  15. 15
    他にも導入してよかったこと
    2. 開発手法→生産性の合理性
    - ブランチ戦略が見えてくる
    - 開発手法が見えてくる
    - 手法ごとに数値に変化が見えてくるa
    - アジャイルでやる。よりも抽象度が1つ下がる
    - CS定例による、客観的な視点も新鮮
    引用 : DevOps 技術: トランクベース開発
    3. 採用アトラクト
    - きちんと開発に投資しているイメージをもってもらえる
    - メンバーのDeveloper Productivity への関心UP

    View full-size slide

  16. 16
    - 問題提起 → 強い開発組織を作る、一歩目
    - 導入アプローチ → 決裁者目線でコストを考え、仲間を見つける
    - 良かったところ → 数値化することで会話が生まれ、改善が起こせる
    まとめ

    View full-size slide