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

「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is developme...

「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?

2024/6/28 開発生産性カンファレンス2024 登壇資料
https://dev-productivity-con.findy-code.io/2024

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

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

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

  2. 19 ”隠された失敗”が増えると....
 
 1. 優先度を細かく決めないといけなくなる
 a. そうしないと意図通りにモノがでてこない
 2. 細かく管理しないといけなくなる
 a.

    ホフスタッターの法則があるか
 3. 遅れを取り戻す、追加コスト / 調整コストがかかる
 a. オンボーディングコスト(ブルックスの法則)
 b. 採用コスト(採用業務 + 追加人件費)

  3. this is exactly the problem with "refactoring the code". 


    In many cases it means doing a really important work, but it's indistinguishable from almost-slacking-off, like renaming variables for no apparent reason.
 And this is what I mean by "don't refactor the code": use different words when talking about things you did, are doing or plan to do. Don't "refactor". Instead try these:
 「リファクタリングをしたいです」という言葉を使わない
 - リファクリングは良いことなので許容するが何をしているかはあまりわかっていない 
 - かつ、リファクタリングには終わりがないので「いつまでやるの?」状態で工数を取っていく 
 信頼ポイント - リファクタリング
 ──言葉の丁寧さ──
 21
  4. 信頼ポイント - 見積もり
 ──傾向値の提供──
 ◦ 見積もりの予測と実際の乖離が生まれる閾値の共有 
 
 引用: IPA

    「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 
 計画より上回っている 
 計画より下回っている 
 22
  5. 信頼ポイント - リファクタリング
 ──外部データの提供──
 論文 : 
 “Code Red: The

    Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases” (https://arxiv.org/abs/2203.04374)
 
 低品質のコードは高品質のコードに比べて、
 - 欠陥数の増加:
 - 「15倍」ある
 - 問題解決時間の延長:
 - 問題を解決するには平均で「124%」
 - 予測不可能性の増加:
 - 問題解決には最大で「9倍」も長いサイクルタイム
 23
  6. 開発生産性という言葉の勘所 ①
 ── どのフローの話?── 
 27 - 🙋 いつリリースされるの?なんか遅くね?
 -

    ┗ リードタイムの議論
 
 - 🙋 開発組織にかけるコストの投資対効果あってる?
 - ┗ スループットの議論(予算に対する生産)
 ┗ エンジニアが不足しているのか多すぎなのか
 リードタイム
 スループット

  7. 開発生産性という言葉の勘所 ③
 ── どのレイヤーの話?── 
 29 開発組織
 
 経営層
 CxO・役員


    (経営企画 / 経理) 
 Eng Des Eng Eng Des BM BM 経理 経営 Eng EM PM/Dir PdM PdM 横断 組織 事業責任者
 PdM
 P/L 販管費 cost(⾦額) cost(⾦額) man-month(⼯数) スループット(1⼈⽉あたりの⽣産性) man-month(⼯数) B/S 資産 / 減価償却 組織のレイヤーごとに
 開発生産性の意味が違う

  8. - クリエイター目線の期待値
 - ┗ GitHub Copilot、Figma AIを使いたい。テストを早くしたい。
 - ┗ フロー状態を長くしたい。技術負債を無くしたい。


    - PdM / EM目線の期待値
 - ┗ 予定どおりに仮説検証したい。
 - ┗ 開発プロセスのリードタイムを短縮したい。
 - 事業 / 経営目線の期待値
 - ┗ (良いもの >)早く > 安くを出したい。場合によってはソ購入も。
 30 開発生産性という言葉の勘所 ④
 ── 生産性を上げて何がしたい?── 

  9. 開発生産性という言葉の勘所
 31 必ず、言葉の定義を定める必要がある
 
 ① どこのフローの話? → リードタイム・スループット
 ② どのプロセスの話?

    → スコープの認識
 ③ どのレイヤーの話? → 出力単位の変換
 ④ 生産性を上げて何がしたい? → 期待値

  10. ▼ オブザーバビリティー(ソフトウェアの状態)
 ┗ サービス監視ツール・・・Datadog, NewRelic
 ┗ クラウドサービス・・・AWS, GCP, Azureサービス 


    ┗ CI / CD・・・GitHub Actions, Circle CI, Argo CD 
 ▼ 個・チーム生産性(個・チームの状態)
 ┗ コード・・・GitHub, AI(Copilot), SonarQube 
 ┗ チームパフォーマンス・・・Findy Team+, Offers MGR 
 ┗ バックログ・・・JIRA, ZenHubのレポート(Burndown Chart, Control Chart) 
 ┗ フロー状態・・・Googleカレンダーデータ(ミーティング) 
 生産性に影響しそうな変数は沢山取れる
 33 ▼ P/L(予算のコスト)
 ┗ 人件費(ソフトウェア仮勘定)
 ┗ 減価償却費
 ┗ 採用費(フィー)
 ┗ 通信費(サーバー費用等)
 ┗ ライセンス費,etc..

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

    経営 Eng EM PM/Dir PdM PdM 横断 組織 36 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 人数サイズ
 予算権限

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

    経営 Eng EM PM/Dir PdM PdM 横断 組織 37 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 人数サイズ
 予算権限
 ▼ P/L(予算が操作可能変数)
 ┗ 人件費(ソフトウェア仮勘定) 
 ┗ 減価償却費
 ┗ 採用費(フィー)
 ┗ 通信費(サーバー費用等) 
 ┗ ライセンス費,etc..
 ▼ 個・チームの生産性
 ┗ コード
 ┗ チームパフォーマンス
 ┗ バックログ
 ┗ フロー状態
 
 ▼オブザーバビリティー
 ┗ n ...
 
 スループット(1⼈⽉あたりの⽣産性) 立体感
 プロセスは
 上から下へ
 生産性の価値
 cost(⾦額) man-month(⼯数) 使
 っ
 て
 い
 る
 武
 器
 接続箇所

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

    経営 Eng EM PM/Dir PdM PdM 横断 組織 38 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 人数サイズ
 予算権限
 スループット(1⼈⽉あたりの⽣産性) 立体感
 プロセスは
 上から下へ
 生産性の価値
 cost(⾦額) man-month(⼯数) 接続箇所
 無理に飛躍して、
 現場の指標を
 管理会計に繋げない。
 机上の空論になる

  14. Eng Des Eng Eng Des BM BM 経営 Eng EM

    PM/Dir PdM PdM 横断 組織 39 開発組織
 
 経営層
 CxO・役員
 (経営企画 / 経理) 
 オーバーラップさせる箇所の意味を変換すればいい
 事業責任者
 PdM
 工数と金額を共通言語として、 
 現場と事業を繋いでいる
 Sales Mktg BigQuery man-month (⼯数) スループット (1⼈⽉あたりの⽣産性) cost(⾦額) 経理 資産価値 / 減価償却
  15. 42 42 select
 project_code
 , 工数
 , 工期
 , 実金額


    , 人数
 , 完了予定日
 , 資産計上区分
 where
 {{本部名}} = “xxxxxx”
 and {{部門名}} = “xxxxxx”
 and {{チーム名}} = “xxxxxx”
 BigQuery
  16. Google Apps Script
 にて自動生成
 勤怠ツール
 プロジェクトA
 └ 6時間
 ミーティング
 └

    2時間
 
 施策と工数
 マッピング
 人事データ
 プロジェクト
 データ
 BPM
 システム
 経理・主計
 給与
 DWH
 データパイプライン
 生産性
 レポート
 BigQuery投入
 Google Sheet
 Looker
 44
  17. 46 - 「その活動をして儲かるの?」の代表格
 i. 開発生産性を上げる改善って、どう儲かるの?
 ii. スクラムを導入したら、どう儲かるの?
 iii. リファクタリングしたら、どう儲かるの?
 iv.

    リモートワークにしたら、どう儲かるの?
 v. MVPで小さくしたら、どう儲かるの?
 - 本当に思っているかどうかは別にして、本質的には顧客が喜ぶ先にある、コストに 対しての売上・利益への貢献依存度は考えている
 事業責任者・経営層の頭の中

  18. 47 開発に影響がある管理会計(一部)
 売上 費用 利益 開発に紐づく勘定項目
 (主に販管費)
 
 └ 人件費(給与・賞与)


    └ 外注費
 └ 法定福利費
 └ 地代家賃
 └ 減価償却費
 └ 採用費
 └ ツール・手数料費
 └ サーバー設備費
 
 等々
 
 損益計算書(P/L)
 貸借対照表(B/S)
 現在の資源スナップショット
 資産 負債 純資産 └ 固定資産
 └ 無形固定資産
 └ ソフトウェア
 └ ソフトウェア仮勘定
 
 

  19. 48 ソフトウェア資産の蓄積と売上の時間軸
 
 資産 負債 純資産 売上 費用 利益 資産の蓄積


    (時間軸が長い)
 (売上へ間接的)
 cash in
 (時間軸が短い)
 (売上に直接的)
 積分(数年先に必要なことを今やってる.ex.バージョンアップやリファクタリング )
 微分
 開発
 資産→売上
 
 開発→資産
 
 作る
 減らす
 (資産を作っている段階では売れるかわからない)

  20. 50 開発生産性を上げると、P/L(コスト)はどうなるか
 
 - 固定人件費は変わらない
 - ただ、無駄な開発費用が減る
 - 無駄 :

    炎上プロジェクトへの人員投下、調整コスト、 イニシャルコスト増、車輪の再発明
 - 税率は一長一短
 
 
 売上 費用 利益 損益計算書(P/L)

  21. - 売上損失の最小化
 - ロードバックの素早さ、最小限の障害
 - 回転数があがるとデプロイが増えるので障害 は増えることを考慮
 - A/B環境の構築による影響範囲小
 -

    サーバー費用の最小化
 52 売上 費用 利益 損益計算書(P/L)
 開発生産性を上げると、P/L(コスト)はどうなるか

  22. 55 1. 資産価値があるソフトウェアを作る 
 a. ソフトウェア仮勘定として蓄積
 2. リリースとともに本勘定へ(減価償却) 
 3.

    資産価値がないものは、費用化 
 4. 資産価値があるものを沢山作ったほうが利益 幅は大きくなる(税は大きくなる)
 
 価値
 時間
 ソフトウェア仮勘定
 開発中
 1年
 2年
 3年
 4年
 5年
 ソフトウェアの資産価値があるものを沢山作ったほうが 利益幅は大きくなる
 資産計上 → 減価償却
 残存価値
 開発生産性を上げると、P/L(コスト)はどうなるか
 利益
  23. 58 儲かっていない箇所を最適化していく
 取っ掛かりとして、
 1. 開発中(イニシャルコストの削減 = 開発を継続的に早く)
 2. ミーティング(ムダな会議はないか)
 3.

    保守運用の作業(ムダな作業はないか)
 を見てみる。
 これを金額に落とし込んでみる。
 今期、人件費に対してソフトウェア資産価値を作っている業務の割合を調べて みる / 聞いてみる

  24. 参考文献
 - 大規模言語モデル時代と開発生産性
 https://speakerdeck.com/hirokidaichi/da-gui-mo-yan-yu-moderushi-dai-nokai-fa-sheng-chan-xing
 - 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
 - IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 
 https://www.ipa.go.jp/publish/wp-sd/qv6pgp0000000vv2-att/000069381.pdf 
 - 著 Christian Ciceri & 他12名 | 「ソフトウェアアーキテクチャメトリクス」
 - 開発生産性の多角的接点〜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
 - リファクタリング(第2版) 
 https://www.ohmsha.co.jp/book/9784274224546/ 
 

  25. 参考文献
 - 著 ジェリー・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
 - 財務諸表というフレームワークで考えるソフトウェア開発と技術的負債
 https://note.com/yshnb/n/ndf039850b614 
 - 経営とソフトウェアエンジニアリングの接続 | yasaichi | 
 https://web-salad.hateblo.jp/entry/2022/09/30/130000
 - そのリファクタリングは最初から間違っている
 https://youtu.be/j2qnF6e_n60?si=aLgIhSdULZTr2qcE 
 

  26. 参考文献
 - 国税庁 : No.5403 少額の減価償却資産になるかどうかの判定の例示 
 https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5403.htm 
 - 国税庁

    : 第8節 資本的支出と修繕費 
 https://www.nta.go.jp/law/tsutatsu/kihon/hojin/07/07_08.htm 
 - Don't refactor the code 
 https://dev.to/katafrakt/dont-refactor-the-code-igk 
 - Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases 
 https://arxiv.org/abs/2203.04374