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

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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  

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

69 連載中 

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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