開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity

開発生産性の現在地点  〜エンジニアリングが及ぼす多角的視点〜    1 Masato Ishigaki  February 15, 2024 

2 About me  石垣雅人  合同会社 DMM.com     ・著
: 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020）   ・連載 : 『開発生産性の多角的視点』（CodeZine）   ・連載 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）   

3 - 開発生産性の現在地点  - 生産性の可視化に対する議論  - 開発生産性はエンジニア"だけ"のモノではなくなった？  - ペイン) 摩擦を減らすには、互いに信頼を獲得すること 
- 生産性が低いチームを強くするには順番がある      Outline 

- 生産性が低いチームを強くするには順番がある  Outline  歴史・時流的な話  論点整理 

- 生産性が低いチームを強くするには順番がある  Outline  組織と生産性の話 

- 生産性が低いチームを強くするには順番がある  Outline  心持ち的な話 

この2つの時流を抑えておけば大体OK  - State of DevOps Report  - Developer Productivity Engineering 
    8

State of DevOps Reportを調べると出てくるもの  dora.dev/ amazon.co.jp/dp/B07L2R3LTN 9

State of DevOps Reportの歴史は長い & 複雑  引用 : https://note.com/ishiguro/n/n12f6ac8a70a9  
10

ミスリードを起こしやすい箇所  引用 : https://note.com/ishiguro/n/n12f6ac8a70a9   初版 GoogleがDORA社を買収枝分かれ 11

これらで語られる開発生産性の範囲  - ソフトウェアであること  not 組み込みやミドルウェア（と考えたほうがいい）    - DevOps周辺の生産性であること  それが組織全体の生産性・収益性であると主張（議論の余地あり）   
  12

推測するな、計測せよ  が現実的な位置まで来た    ※ はじめは推測から始めた方がいい 13

押し上げた背景には、  メトリクスサービスの発展がある  ┗ サービス監視ツール・・・Datadog, NewRelic  ┗ ログ収集・・・Elasticsearch, Splunk  ┗ クラウドサービス・・・AWS,
GCP, Azure  ┗ CI / CD・・・GitHub Actions, Circle CI  ┗ ソースコード管理・・・GitHub  ┗ コード品質・・・SonarQube, Code Climate  ┗ チームパフォーマンス・・・Findy Team+, Offers MGR    14

Four keysパイプラインも充実  GitHub - dora-team/fourkeys  15

Four keysパイプラインも充実  https://findy-team.io/dashboard 16

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年〜 

Developer Productivity Engineeringとは  THE DEVELOPER PRODUCTTIVITY ENGINEERING HAND BOOK  18

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

Developer Productivity  “Management” != ”Engineering”  20 https://youtu.be/SECl10JDaBE?si=ymVAYtDzP5Eqm5o7

Four keysに対する議論  - そもそも、生産性は測れない  Martin Fowler - CannotMeasureProductivity    -
Four Keysの数値を良くしても悪影響になるケースもある  無下にデプロイ回数を増やして、コミュニケーションコストが上がることもある    - DevOpsの生産性が、組織全体の生産性とは限らない  サイクルタイムとリードタイムは一致しているか。もっと複雑ではないのか  22

何を計測するのか / 誰のために計測するのか  23

何を計測するのか / 誰のために計測するのか  • 「Measure process -- not output」  •
アウトプットではなく、プロセスを計測せよ  - The elusive quest to measure developer productivity - GitHub Universe 2019     24

何を計測するのか / 誰のために計測するのか    「チームのためか、チーム外のためか」  予算獲得の根拠ため？それともチーム内で完結？  全体的な底上げ？トップラインの引き上げ？       
25

計測に力を入れすぎない  - データ化するのは楽しい  だからといってハマらない    - 生産性データが組織の状態をすべてを網羅することはない  あくまでも傾向値で、Data-Informedの考え方で捉える    -
計測に時間をかけるのではなく、課題解決に時間をかける  コードの複雑性を見ているのではなく、手を動かし改善→改善幅を見る  26

ここでの論点整理  DevOpsの生産性は、  組織全体の生産性（価値）となり得るか  27

  それは”バリューストリーム”を描けばわかる    限りなく近くなってきたとはいえ、  きっとエンジニア組織が改善しても  全体が即時に改善される幅は多くない    28

Ex. Streamlining change approval  （変更承認の合理化）  Heavyweight change process  ↓  
Clear change process  State of DevOps Report 2019   30

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

「開発生産性」は  エンジニア”だけ”のものではなくなった  最近の時流  - エンジニアリングのコモディティー化  あらゆる技術は誰でも利用可能な武器となる    - 競争優位性としての”生産性”  投入タイミングの自由自在さ、機能優位性を作れるか 
    33

❶ 事業的観点での開発生産性向上の効果   = 利益損失の最小化  PdM, BMが考えた仮説が ”一定の確率” で価値を上げると仮定すると”継続的な速さ”は価値になる 
  - Q単位の仮説検証プロセスの回転数  - 1施策あたりのリードタイム短縮      34

- 売上損失の最小化ができる  - 最小限の障害、ロードバックの素早さ  - サーバー費用の最小化、A/B環境の構築による影響範囲小    - 無駄な開発費用（販管費）  -
車輪の再発明、炎上プロジェクトへの人員投下  35 ❷ 事業的観点での開発生産性向上の効果   = 利益損失の最小化 

「開発生産性」が経営層に伝わらない理由は、  “言語”が違うから   

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

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 資産 / 減価償却 “開発生産性”の意味が違う 

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

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

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

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

44 開発業務区分  ビジュアライズ  開発施策  月単位 - 金額  完了予実  資産計上区分  全体サマリー 
月単位 - 工数  部署名 

SQLライクな柔軟な分析  プロジェクト A分析チーム単位の施策ではなく  横断プロジェクトの分析  45

設定した指標（KPI）を横断的に観測（約1,000名）    KPI : 開発に集中できているか  を工数と金額でモニタリング  46

Google Apps Script  にて自動生成  勤怠ツール  プロジェクトA  └ 6時間  ミーティング  └
2時間    施策と工数  マッピング  人事データ  プロジェクト  データ  BPM  システム  経理・主計  給与  DWH  データパイプライン  生産性  レポート  BigQuery投入  Google Sheet  Looker  47

これは開発組織が50〜100名以上だとベスト    - どちらかというと決裁権限がある部長以上が中心で見るもの    - 開発人数の規模が小さければ、シンプルなメトリクスでカバー  48

50 見積もりの不完全性による、事業計画のズレ    t  見積もりの工数  = 15人月  実際の工数  = 20人月 
(工期も1ヶ月ズレ)  超過分・調子が悪くなる  └ 設計ミス    ・スコープクリープ  1ヶ月  2ヶ月  3ヶ月  4ヶ月  5ヶ月  6ヶ月  ・景気よくスタート    工数  ・見積もり計画 

51 すれ違いの発生箇所  事業/経営  - エンジニアの見積もり（予測）を信じて、計画を作る  - なのに毎回遅れる。ただ、なぜ遅れるのかはわからない  - リカバリーのための人件費（エンジニア、PM）を投入 

52 すれ違いの発生箇所  開発組織  - 見積もりは、そもそも外れるものという共通認識がある  - 遅れた事実はわかりやすいが、“なぜ遅れたか”は数値化しにくい。  - 大量投入されても、”人月の神話”状態（課題 !=
解決策）  - “ただ”、内部品質の改善に予算を使いたいが結果がでるのに時間がかかる 

53 開発の投資対効果を測るのは難しい  時間軸の違い  「見えやすく測りやすい」👀  「見えにくく測りにくい」✘  ・キャンペーン施策、効果に直結するエンハンス開発    リリースした直後に数値（例えば売上）として跳ね返ってきたり、KPIがLTVでも期間で予算
のリクープの計算がしやすい    ・リファクタリングやリプレイス、定期的なバージョンアップといった内部品質    半年後、1年後、数年後を見据えて「今やっておくべきこと」が多く存在するがリターンも不安定で不確か     

54 見えにくく測りにくいもの  リプレイス  リファクタリング  膨大な予算をかけて  元に戻す 

ソフトウェア開発の失敗確率  引用: CHAOS REPORT 2015  OnTime（時間通り）、OnBudget（予算内）、OnTarget（目標達成）、OnGoal（目的達成）、Value（価値）、Satisfaction（満足度）   自分たちの ”予測通り” に達成できたか 
55

失敗とは、見積もりの失敗である  納期が遅れたとか、予算がオーバーしたとかでプロジェクトが失敗したと言うよりも、   失敗したのは見積もりなのだと言いたい。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

そして、その見積もりもだいたい外れる  引用: IPA 「IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果」  計画より上回っている   計画より下回っている  57

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  

59 なぜ、エンジニアの”フロー状態”  は見落とされるのか  Introducing Developer Velocity Lab to improve developers’
work and well-being  

引用 : 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

タイムボックスの違いが大きい  Developer Productivity Engineering   – The Next Big Thing
in Software Development by Justin Reock  61

62 開発生産性を下げる要素    - 開発生産性を下げているのは、開発組織だけとは限らない  - └ 一番下げているのは、SDLC以外の箇所かも    -
ただ、説明責任を果たさないと負のループは終わらない  - 特に「見えにくく測りにくい」の価値  - 一番は、信頼関係が作れれば完璧  - └ 信頼が積み上がっていれば、開発速度は何も気にならない   

- 生産性が低いチームを強くするには順番がある  Outline  心持ち的な話 

  まず、アウトプット（出力量）をあげた後に  アウトカム（価値結果）を考える    64 「開発生産性を上げる vs ムダなものを作る確率を下げる」  　  まず、エンジニアがどこにコミットするべきかを判断 
　何を作るべきかは違う知識が沢山いる   

  “数値”を高めると強い組織になるのか、  強い組織の”状態”が数値を高めるのか            65 「グットハートの法則、キャベルの法則」 
組織や制度が数値向上を目的にすると、  多少なりとも圧がかかり数字を作るためだけに行動する    状態が数値を作り、数値が状態を作るわけではない 

  常に自分たちの”予測”を超えていく  66 他者と比較することの無意味さ  自分たちを主語に改善していく  記録→予測ベースの開発へ  比較しない  自分たち  過去の自分たち  他 
比較 

採用するか、開発生産性をあげるか  技術投資の費用対効果  - 強いエンジニアの採用（難化）  - 大きな福利厚生となり多くの問題を解決する    - 開発生産性をあげていく（明日から）  -
現存する開発リソースの最大化 

- 生産性が低いチームを強くするには順番がある      まとめ 

69 連載中 

参考文献  - 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   

参考文献  - 著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   

参考文献  - 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 

開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current stat...

開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity

Transcript

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured