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

開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current stat...

開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity

2024/2/15 Developers Summit 2024 登壇資料
https://event.shoeisha.jp/devsumi/20240215

Masato Ishigaki / 石垣雅人

February 15, 2024
Tweet

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. 2 About me
 石垣 雅人
 合同会社 DMM.com 
 
 ・著

    : 『DMMを支えるデータ駆動戦略』(マイナビ出版,2020) 
 ・連載 : 『開発生産性の多角的視点』(CodeZine) 
 ・連載 : 『スモールチームが武器になる時代へ』(ProductZine) 
 ・連載 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks)
 

  2. 押し上げた背景には、
 メトリクスサービスの発展がある
 ┗ サービス監視ツール・・・Datadog, NewRelic
 ┗ ログ収集・・・Elasticsearch, Splunk
 ┗ クラウドサービス・・・AWS,

    GCP, Azure
 ┗ CI / CD・・・GitHub Actions, Circle CI
 ┗ ソースコード管理・・・GitHub
 ┗ コード品質・・・SonarQube, Code Climate
 ┗ チームパフォーマンス・・・Findy Team+, Offers MGR
 
 14
  3. 17 DevOps
 2009年〜
 Cloud
 2006年〜
 
 MicroServices
 2014年〜
 Agile
 2001年〜


    Lean Startup
 2008年〜
 
 トヨタ生産方式
 1973年〜
 
 WF
 1970年〜
 
 技術革新によって開発者体験・サイズが変化
 DPEへと発展
 ※ 個人的紐づけ
 State of DevOps Report
 2013年〜
 Full Cycle Developers
 2018年〜

  4. Developer Productivity Engineeringとは
 Developer Productivity Engineering is a discipline of

    using data and acceleration techniques to improve essential software development processes for greater automation, fast feedback cycles, and reliable feedback.
 Developer Productivity Engineering は、自動化、迅速なフィードバックサイク ル、信頼性の高いフィードバックを実現するために、データと加速技術を使用 してソフトウェア開発プロセスを改善するための分野です.
 THE DEVELOPER PRODUCTTIVITY ENGINEERING HAND BOOK
 19
  5. Four keysに対する議論
 - そもそも、生産性は測れない
 Martin Fowler - CannotMeasureProductivity
 
 -

    Four Keysの数値を良くしても悪影響になるケースもある
 無下にデプロイ回数を増やして、コミュニケーションコストが上がることもある
 
 - DevOpsの生産性が、組織全体の生産性とは限らない
 サイクルタイムとリードタイムは一致しているか。もっと複雑ではないのか
 22
  6. 何を計測するのか / 誰のために計測するのか
 • 「Measure process -- not output」
 •

    アウトプットではなく、プロセスを計測せよ
 - The elusive quest to measure developer productivity - GitHub Universe 2019 
 
 24
  7. 計測に力を入れすぎない
 - データ化するのは楽しい
 だからといってハマらない
 
 - 生産性データが組織の状態をすべてを網羅することはない
 あくまでも傾向値で、Data-Informedの考え方で捉える
 
 -

    計測に時間をかけるのではなく、課題解決に時間をかける
 コードの複雑性を見ているのではなく、手を動かし改善→改善幅を見る
 26
  8. 29

  9. 1. Can changes be promoted to production without manual change

    approvals?
 - 手動による変更承認なしで、変更を実稼働環境にプロモートできますか?
 
 2. Do production changes need to be approved by an external body before deployment or implementation?
 - 運用上の変更は、展開または実装前に外部機関の承認を受ける必要がありますか?
 
 3. Do you rely on peer review to manage changes?
 - 変更を管理するためにピアレビューに依存していますか?
 
 4. Do team members have a clear understanding of the process to get changes approved for implementation
 - チームメンバーは、変更の実装を承認してもらうプロセスを明確に理解していますか?
 Ex. Streamlining change approval
 (変更承認の合理化)
 DevOps capabilities: process Streamlining change approval 
 31
  10. - 売上損失の最小化ができる
 - 最小限の障害、ロードバックの素早さ
 - サーバー費用の最小化、A/B環境の構築による影響範囲小
 
 - 無駄な開発費用(販管費)
 -

    車輪の再発明、炎上プロジェクトへの人員投下
 35 ❷ 事業的観点での開発生産性向上の効果 
 = 利益損失の最小化

  11. 仮体制図
 Eng Des Eng Eng Des BM BM 経理 経営

    Eng EM PM/Dir 横断組 織 37 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理)
 事業責任者
 PdM
 PdM PdM 年商1,000億円
 所属 : 100人
 年商 1億円
 所属 : 10人

  12. 38 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 Eng

    Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 事業責任者
 PdM
 財務諸表
 ・P/L : 販管費への影響度合い 
 ・B/S : 資産、償却、税負担への影響 
 金額
 ・販管費の最適化 
 ※ 同じ単価でも、施策回数と質が違う 
 ※ 生産性が落ちてくると、追加投資額が必要 
 
 工数・工期(計画・ロードマップ) 
 ・生産性が高くなると当初計画よりも短くなる 
 ・もしくは類推見積もりの角度が上がる 
 開発チーム内の向き合い 
 ・ソフトウェアの内部品質、エコシステム 
 ・Four keys, テストカバレッジ 
 数値の流れ
 P/L 販管費 cost(⾦額) cost(⾦額) man-month(⼯数) スループット(1⼈⽉あたりの⽣産性) man-month(⼯数) B/S 資産 / 減価償却 “開発生産性”の意味が違う

  13. 事業責任者
 PdM
 Eng Des Eng Eng Des BM BM 経理

    経営 Eng EM PM/Dir PdM PdM 横断 組織 各領域をオーバーラップさせる
 39 事業責任者
 PdM
 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 ・“開発生産性が上げるアプローチと抽象度がレイヤーごとに違う
 ・良いソフトウェアが企業価値を上げるには”接続”してあげる必要がある
 ・ゆえにオーバーラップする部分(接続箇所)の設計が大事になる”

  14. 事業責任者
 PdM
 Eng Des Eng Eng Des BM BM 経理

    経営 Eng EM PM/Dir PdM PdM 横断 組織 40 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 output input 次元を変換して、入力と出力で渡してあげる
 
 output input output input
  15. Eng Des Eng Eng Des BM BM 経営 Eng EM

    PM/Dir PdM PdM 横断 組織 41 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 オーバーラップさせる箇所のモニタリング
 事業責任者
 PdM
 モニタリング基盤を構築して、 
 正しくレポーティング
 Sales Mktg BigQuery man-month (⼯数) スループット (1⼈⽉あたりの⽣産性) cost(⾦額) 経理 資産価値 / 減価償却
  16. 42

  17. 43 select
 project_code
 , 工数
 , 工期
 , 実金額
 ,

    完了予定日
 , 資産計上区分
 where
 {{本部名}} = “xxxxxx”
 and {{部門名}} = “xxxxxx”
 and {{チーム名}} = “xxxxxx”
 ・開発業務区分
 ・開発コード
 ┗ 毎月の工数・金額
 ┗ 毎月の人数
 ┗ 進行ステータス
 ・完了予定日・予実
 ・資産計上区分
 
 内製
 外注

  18. Google Apps Script
 にて自動生成
 勤怠ツール
 プロジェクトA
 └ 6時間
 ミーティング
 └

    2時間
 
 施策と工数
 マッピング
 人事データ
 プロジェクト
 データ
 BPM
 システム
 経理・主計
 給与
 DWH
 データパイプライン
 生産性
 レポート
 BigQuery投入
 Google Sheet
 Looker
 47
  19. 50 見積もりの不完全性による、事業計画のズレ
 
 t
 見積もりの工数
 = 15人月
 実際の工数
 = 20人月


    (工期も1ヶ月ズレ)
 超過分 ・調子が悪くなる
 └ 設計ミス
 
 ・スコープクリープ
 1ヶ 月
 2ヶ 月
 3ヶ 月
 4ヶ 月
 5ヶ 月
 6ヶ 月
 ・景気よくスタート
 
 工数
 ・見積もり計画

  20. 53 開発の投資対効果を測るのは難しい
 時間軸の違い
 「見えやすく測りやすい」👀
 「見えにくく測りにくい」✘
 ・キャンペーン施策、効果に直結するエンハ ンス開発
 
 リリースした直後に数値(例えば売上)として 跳ね返ってきたり、KPIがLTVでも期間で予算

    のリクープの計算がしやすい
 
 ・リファクタリングやリプレイス、定期的なバー ジョンアップといった内部品質
 
 半年後、1年後、数年後を見据えて「今やって おくべきこと」が多く存在するがリターンも不安 定で不確か
 
 

  21. 失敗とは、見積もりの失敗である
 納期が遅れたとか、予算がオーバーしたとかでプロジェクトが失敗したと言うよりも、 
 失敗したのは見積もりなのだと言いたい。CHAOSレポートはソフトウェアプロジェクトの失敗の記録では なく、ソフトウェア見積りの失敗の記録なのだ。
 
 何が成功として勘定できるのか。測ることが可能なのであれば、答えは投資へのリターンとなるべきだ。 悲しいかなこれを測ることなど不可能に等しい。
 Rather than

    saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure.
 So what counts as success? If we could measure it the answer has to be Return on Investment. Sadly this is usually next to impossible to measure (see my discussion in CannotMeasureProductivity) In the end it's a fuzzy sense of business satisfaction relative to the cost of the project. 
 引用: WhatIsFailure(失敗とは): マーティンファウラー 
 56
  22. 58 なぜ、エンジニアの”フロー状態”
 は見落とされるのか
 “The Cost of Context Switching
 Developers reported

    that they usually feel most productive when they make progress on tasks and when they have only a few context switches and interruptions. 
 However, observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour. For example, developers switched tasks on average 13 times an hour and spent just about 6 minutes on a task before switching to another one. “ 
 “開発者たちは、タスクの進捗を感じる時や、コンテキストの切り替えや中断が少ない時に最も生産的 だと感じることが多いと報告しています。 
 
 しかし、開発者の労働日を観察すると彼らは絶えずコンテキストを切り替えており、しばしば1時間に何 度もこれを行っています。例えば、開発者は平均して 1時間に13回タスクを切り替え、約6分間タスクに 集中して別のタスクに移っています” 
 引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity 

  23. 引用 : MAKER'S SCHEDULE, MANAGER'S SCHEDULE
 “There are two types

    of schedule, which I'll call the manager's schedule and the maker's schedule.
 The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. 
 You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.
 ~ 
 there's another way of using time that's common among people who make things, like programmers and writers. 
 They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.” 
 
 - タイムボックスが、エンジニアとマネージャーでは違う
 - マネージャーは、1時間区切りでタスクをこなす
 - メーカー(エンジニア)は、半日単位でタスクをこなす
 タイムボックスの違いが大きい
 60
  24. 62 開発生産性を下げる要素
 
 - 開発生産性を下げているのは、開発組織だけとは限らない
 - └ 一番下げているのは、SDLC以外の箇所かも
 
 -

    ただ、説明責任を果たさないと負のループは終わらない
 - 特に「見えにくく測りにくい」の価値
 - 一番は、信頼関係が作れれば完璧
 - └ 信頼が積み上がっていれば、開発速度は何も気にならない
 

  25. 
 “数値”を高めると強い組織になるのか、
 強い組織の”状態”が数値を高めるのか
 
 
 
 
 
 65 「グットハートの法則、キャベルの法則」


    組織や制度が数値向上を目的にすると、
 多少なりとも圧がかかり数字を作るためだけに行動する
 
 状態が数値を作り、数値が状態を作るわけではない

  26. 参考文献
 - MAKER'S SCHEDULE, MANAGER'S SCHEDULE | Paul Graham |

    https://www.paulgraham.com/makersschedule.html
 - DevEx: What Actually Drives Productivity | Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler | https://queue.acm.org/detail.cfm?id=3595878
 - The SPACE of Developer Productivity | Nicole Forsgren,Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler| 
 - https://queue.acm.org/detail.cfm?id=3454124
 - How Do Interruptions Affect Productivity? | Duncan P. Brumby, Christian P. Janssen & Gloria Mark | https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_9
 - 開発生産性の低下による、事業の失敗はなぜ起こるのか | 石垣 雅人 | https://speakerdeck.com/i35_267/productivitypitfalls
 - CHAOS REPORT 2015 | The Standish Group International, Inc.| https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf
 - WhatIsFailure | martin fowler | 
 - https://martinfowler.com/bliki/WhatIsFailure.html
 - CannetMeasureProductivity | martin fowler | 
 - https://martinfowler.com/bliki/CannotMeasureProductivity.html
 

  27. 参考文献
 - 著Christian Ciceri & 他12名 | 「ソフトウェアアーキテクチャメトリクス」
 - デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感|

    onk | 
 https://onk.hatenablog.jp/entry/2023/03/10/045349
 - 開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 | 石垣雅人 |
 https://speakerdeck.com/i35_267/multifaceted-touchpoints-of-development-productivity
 - Is High Quality Software Worth the Cost? | martin fowler | 
 - https://martinfowler.com/articles/is-quality-worth-cost.html
 - 著 ジェリー・Z・ミュラー | 「測りすぎ――なぜパフォーマンス評価は失敗するのか?」
 - 著 Jr FrederickP.Brooks | 「人月の神話【新装版】」
 - あらゆるプロセスや方法論は-型-であり-成功を保証するものではない | 石垣 雅人 | 
 https://medium.com/i35-267/eb272f719fe
 - ソフトウェアメトリックス調査2020システム開発・保守調査| 一般社団法人 日本情報システム・ユーザー協会 | https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf
 - 見積もりをしない | 石垣 雅人 | 
 https://speakerdeck.com/i35_267/jian-ji-moriwosinai
 

  28. 参考文献
 - LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report | シリコンバレーからのノート|

    https://note.com/ishiguro/n/n12f6ac8a70a9
 - LeanとDevOps生産性の神話(2) - 11年目のState of DevOps Report | シリコンバレーからのノート | https://note.com/ishiguro/n/n08923d170e32
 - LeanとDevOps生産性の神話(3) - 11年目のState of DevOps Report | シリコンバレーからのノート | https://note.com/ishiguro/n/n7c8c21fcffb6
 - Streamlining change approval | DORA | 
 - https://dora.dev/devops-capabilities/process/streamlining-change-approval/
 - アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ | kokotatata | https://kokotatata.hatenablog.com/entry/2021/12/23/051947
 - DPE (Developer Productivity Engineering) & DXE (Developer Experience Engineer) | 雪泥鴻爪--IT技術者の随筆 | https://yinlei.org/it-iot/
 - AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり | Kengo TODA | https://blog.kengo-toda.jp/entry/2023/11/03/201546
 - 経営とソフトウェアエンジニアリングの接続 | yasaichi | 
 https://web-salad.hateblo.jp/entry/2022/09/30/130000