開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity

開発生産性の多角的接点  〜1,000名のクリエイター組織 × 開発生産性〜      1 Masato Ishigaki November
28, 2023

2 - “開発生産性”という言葉は、レイヤーごとに意味が違う  - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う  - 仮説検証 ×
開発生産性は、プロセスと組織設計と向き合う  - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う    Outline 

3 About me  石垣雅人  合同会社 DMM.com   プラットフォーム事業本部第1開発部
部長   VPoE室 / アルファ室     ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020）   ・連載 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）    @i35_267 @i35_267 @i35_267

- クリエイター数は、約1,100名  - 開発チーム数は、約100チーム  - 現在進行中の開発プロジェクトは、約500個  - 開発案件の内製割合は、98%  - 正社員と業務委託の比率 
- 正社員 : 約60%、業務委託 : 約40%    6 DMM.comの開発アウトライン 

仮体制図  Eng Des Eng Eng Des BM BM 経理経営
Eng EM PM/Dir 横断組織 8 “開発生産性”という言葉は、レイヤーごとに意味が違う  開発組織    経営層  CxO・役員  （経営企画 / 経理）   事業責任者  PdM  PdM PdM 年商1,000億円  所属 : 100人  年商 1億円  所属 : 10人 

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

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

Eng Des Eng Eng Des BM BM 経理経営 Eng
EM PM/Dir PdM PdM 横断組織 11 開発チームは、1人月あたりの生産性と向き合う  経営層  CxO・役員  （経営企画 / 経理）   事業責任者  PdM  開発組織    開発チーム内の向き合い     output :   - 1人月あたりの生産性を考える  ※1人月単位なら予算計算がしやすい    要素 :   - ソフトウェアの内部品質、エコシステム  - Four keys, テストカバレッジ   output

12 開発チームの開発生産性を語る3つの次元   引用 : Rethinking Productivity in Software Engineering
->Chapter A Software Development Productivity Framework  “Productivity Dimensions in Software Development  The three dimensions in the proposed productivity framework for software engineering are as follows:   • Velocity: How fast work gets done   • Quality: How well work gets done   • Satisfaction: How satisfying the work is “   “ソフトウェアエンジニアリングのために提案された生産性フレームワークの3つの側面   • 速度：作業の速さ  • 品質：仕事がどれだけうまく行われるか（内部品質・外部品質）   • 満足度：その仕事がどれほど満足しているか”  

13 大事にしたい方針の質問からメトリクスを決めていく  引用 : Table 5-1 Breaking Down Productivity Goal
1 Along the Three Dimensions    

14 コンテキストスイッチを甘く見ない  “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 

15 個々が生産的だと感じる時間帯も偏りはあるがバラバラである   “Three types of developers and   their
perceptions of productivity over the course of a workday”  “湾曲した回帰線は、個々の開発者が信頼範囲を示す影付きの領域で生産的だと感じた日の全体的な   パターンを示しています。朝の人々はまれで（20%）、最大のグループは午後の人々（40%）     これらの結果は、開発者が多様な生産性パターンを持っている一方で、   個人が毎日自分の習慣的なパターンに従っているように見えることを示唆しています。”   引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity 

横断組織 Eng Des Eng Eng Des BM BM 経理
経営 Eng EM PM/Dir PdM PdM 16 1人月あたりの生産性をもとに、未来予測をする  開発組織    経営層  CxO・役員  （経営企画 / 経理）   事業責任者  PdM  工数・工期への向き合い   （計画・ロードマップ）     input :   ・開発生産性 = 1人月あたりの生産性     model :   ・1人月あたりの生産性をもとに未来予測をする     output：  ・大きな手戻りコストの削減   ・追加予算の交渉コスト  ・スコープを削るという悪手を取らなくて済む   ・PM/Dirの大量アサイン回避によるコスト削減     output input not 管理の管理 

経営 Eng EM PM/Dir PdM PdM 17 継続的な事業を作るために、お金に向き合う  開発組織    経営層  CxO・役員  （経営企画 / 経理）   事業責任者  PdM  お金への向き合い    input :   ・開発生産性 = 1人月あたりの単価  ※同じ単価でも工数価値が違うと施策回数と質が違う    model :   ・工数×単価を予算として戦略・戦術の遂行計画   ・この開発力での勝ち筋を見つける   ・投資への金額判断    output :   ・売上利益  output input

経営 Eng EM PM/Dir PdM PdM 18 持続可能な資産に向き合う  開発組織    経営層  CxO・役員  （経営企画 / 経理）   事業責任者  PdM  ソフトウェア資産への向き合い    input :   ・開発生産性 = ソフトウェアの資産価値     model :   ・B/S上のソフトウェア資産 = 税負担・減価償却費用の最適化    output :   ・税負担・減価償却費用の最適化   output input

19 開発組織    経営層  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 資産 / 減価償却 “開発生産性”の意味を変換して、入力と出力で渡してあげる  

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

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

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

- ソースコードをホスティングして可視化  - 1つのOrgにリポジトリが集約。コード資産が一元的に見れる        - チームや組織ごとにサイロ化せずに中央集権型にしてログに残す  -
チーム横断で学習と予測に使う 

27 開発チーム × 開発生産性は、 1人月あたりの生産性を考える  機能A 予想工数  3人月  1,500万  フロー効率のチーム 
機能B 機能C 1人月  チーム単価500万  1人月  チーム単価500万  1人月  チーム単価500万 

28 機能A 予想工数  3人月  → 5.5人月  → 2,750万    フロー効率のチーム 
機能B 機能C 開発生産性に影響あるもの  ・システムの内部品質  └ リファクタリング、技術負債、エコシステム  ・チーム生産性  └ Four Keys、ベロシティー,etc…  見えやすい  数値化しやすい  見えにくい  数値化しにくい  追加予算、1,550万  開発チーム × 開発生産性は、 1人月あたりの生産性を考える 

29 開発チーム × 開発生産性は、1人月あたりの生産性を考える  機能A 予想工数  3人月  → 5.5人月  フロー効率のチーム 
機能B 機能C 開発生産性に影響あるもの  ・システムの内部品質  └ リファクタリング、技術負債、テストカバレッジ  ・チーム生産性  └ Four Keys、ベロシティー,etc…  見えやすい  数値化しやすい  見えにくい  数値化しにくい  追加予算、500万  遅れた事実はわかりやすいが  “なぜ遅れたか”は、数値化しにくい。    生産性が悪化する要因をきちんと言語化して  説明責任は自分たちが果たす    できるだけ内部品質にこだわり、  自分たちが立てた予想工数を超えていく   

30 機能A 機能A 1人月  チーム単価500万  1人月  チーム単価500万  継続的に、1人月あたりの生産性を爆速にしていく    予想工数を超えていく
= 常に自分たちを超えていく = 信頼度 

引用 : Is High Quality Software Worth the Cost?  内部品質を怠ると、すぐに影響がでる 

プロセスと流れてくる情報を考えて、リードタイムを短くする   PdM / DataAnalyst  開発チーム  PM / EM 

PdM / DataAnalyst  リソースプールのペイン  └ 理想スケジュールに間に合わないからエンジニアを追加したい   └ しかし、スキルが合わなかったり、チーム文化もそう簡単にトレードできない  
└ ただ、採用だと間に合わない。育成はもっと間に合わない     スケジュール / リスク管理のペイン  └ スケジュールの手戻りがあるたびにWBS更新   └ スコープを削ってなんとか間に合わせる作戦   └ 開発の遅れによる追加予算の交渉   PM / EM  開発チーム  開発作業の周辺にハードルが多い  ペイン 

開発チーム  PM / EM  PdM / DataAnalyst  戦術（施策）のペイン  └ 施策実施の成功確率が上がってこない。ゆえに計画の工程が長引く。
  └ 開発リソースは確保してしてもったいないから、とりあえずバックログへ”優先度高”で　　　突っ込む  └ データアナリストから効果的そうな施策が出てきて、差し込みが連発   └ 開発側からくる追加コストの意義がわからない + 予算がない（リファクタリング等）   不確実性への対応が、組織としてできていない  ペイン 

プロセスと流れてくる情報を考えて、リードタイムを短くする  PdM / DataAnalyst  解決策  ・一気通貫したプロセスと流れてくる情報を管理  ・そのための組織設計を作っていく   

37 1. 枠を作り、  2. 人をアサインし、  3. 権限と裁量を定義し、  4. 流れる情報をレポートライン作るプロセスの作り方 

38 └ 会議体設計  └ PRD / Design Doc   枠を作り、
人をアサインし、裁量と権限を定義し、レポートラインを作る └ job description  ・事業構成に必要な枠  ・プロダクトとシステムを  考慮（コンウェイの法則）  ・枠に耐えうる人材がいるか  ・兼務祭りにならないか  ・採用はできるのか  ・何が単独で意思決定できるか  ・裁量があって決定権がないのは NG  ・どこで何を意思決定するか  ・フォーマットは何か  プロセスの作り方 

40 事業/経営 × 開発生産性は、事業のお金と資産に向き合う   売上費用利益開発に紐づく勘定項目 
（主に一般管理費）    └ 人件費（給与・賞与）  └ 外注費  └ 法定福利費  └ 福利厚生費  └ 地代家賃  └ 減価償却費  └ 採用費  └ ツール・手数料費  └ サーバー設備費    等々    損益計算書（P/L）  貸借対照表（B/S）  資産負債純資産 └ 固定資産  └ 無形固定資産  └ ソフトウェア   

41 開発生産性をあげると、P/Lはどうなるか  メリット  ・0→1の場合は投入コストが下がる  ・追加人件費の削減  ・見えない予算の削減  ・年間を通して施策回数が増えるので間接的にKGIに寄与する変数となる  売上費用
利益開発に紐づく勘定項目  （主に一般管理費）    └ 人件費（給与・賞与）  └ 外注費  └ 法定福利費  └ 福利厚生費  └ 地代家賃  └ 減価償却費  └ 採用費  └ ツール・手数料費  └ サーバー設備費    等々    損益計算書（P/L） 

42 ソフトウェア資産計上を理解する  貸借対照表（B/S）  資産負債純資産ソフトウェアの資産計上  価値  時間  ソフトウェア仮勘定 
資産計上 → 減価償却開始   開発中  1年  2年  3年  └ 固定資産  └ 無形固定資産  └ ソフトウェア    残存価値  4年  5年 

43 ソフトウェア資産計上を理解する  1. ソフトウェアを作る  2. 資産化 or 費用化の判断  3. 資産化の場合は、減価償却 
a. 3年 or 5年かけて費用配分  b. 資産価値の減少を正しく表現  4. 費用化の場合は全額費用化  価値  時間  ソフトウェア仮勘定  資産計上 → 減価償却開始   開発中  1年  2年  3年  残存価値  4年  5年  ソフトウェアの資産計上 

44 ソフトウェアの資産計上  価値  時間  ソフトウェア仮勘定  資産計上 → 減価償却開始   開発中 
1年  2年  3年  残存価値  1. 1,000万で、ソフトウェアを作る  2. 資産化 or 費用化の判断  3. 資産化の場合は、減価償却をして3年かけて費用配分。(資産価値の減少を正しく表現)   4. 費用化の場合は全額費用化  企業A（企業Bと同じ価値のものを作るとする）  - 開発費用 : - 100万  - 減価償却 : 20万（100万 / 5年）（P/Lへ反映）   - 税前利益 : +5,000万（生み出した利益）   - 調整後税前利益 : +4,980万（5,000 - 20）  - 税負担 : 4,980万 * 30% = -1,494万  ※ 初年度  開発が早い！  開発が遅い  開発性生産性との関連は、税負担と減価償却費  企業B（企業Aと同じ価値のものを作るとする）  - 開発費用 : - 500万  - 減価償却 : 100万（500万 / 5年）（P/Lへ反映）   - 税前利益 : +5,000万（生み出した利益）   - 調整後税前利益 : +4,900万（5,000 -100）  - 税負担 : 4,900万 * 30% = -1,470万  ※ 初年度 

企業A（同じ価値のものを作るとする）  - 開発費用 : - 100万  - 減価償却 : 20万（100万
/ 5年）  - 税前利益 : +5,000万（生み出した利益）   - 調整後税前利益 : +4,980万（5,000 - 20）  - 税負担 : 4,980万 * 30% = -1,494万  ※ 初年度  開発が早い！  開発が遅い  企業B（同じ価値のものを作るとする）  - 開発費用 : - 500万  - 減価償却 : 100万（500万 / 5年）  - 税前利益 : +5,000万（生み出した利益）   - 調整後税前利益 : +4,900万（5,000 -100）  - 税負担 : 4,900万 * 30% = -1,470万  ※ 初年度  結論:  - 企業A : 開発コストが低いため減価償却費も低く、税前利益が高くなる。  - 企業B : 開発コストが高いため減価償却費が大きく、税前利益が低くなる。    ただし、開発の観点から中長期な目線だと早い方が良い   - 早期の市場投入 / 競争優位の確保   - 減価償却費（損益計算書）が低いことでの事業インパクトが下がる   - 財務レバレッジの低減（負債や外部資金への依存低下）  

46 - 前提として、資産化するべきか費用化するべきかの議論はある  - エンジニア含めて作っているプロダクトの資産価値を理解するにはここから始めるのが良い   引用 :
https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5403.htm ソフトウェアを資産化するか、費用化するか興味をもつ 

開発生産性は、プロセスと組織設計と向き合う  - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う    まとめ 

開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifac...

開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured

Transcript