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

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

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

2023/11/28 開発生産性の未来:世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜
https://findy.connpass.com/event/298196/

Masato Ishigaki / 石垣雅人

November 28, 2023
Tweet

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. 開発生産性の多角的接点

    〜1,000名のクリエイター組織 × 開発生産性〜



    1
    Masato Ishigaki
    November 28, 2023

    View full-size slide

  2. 2
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    Outline


    View full-size slide

  3. 3
    About me

    石垣 雅人

    合同会社 DMM.com 

    プラットフォーム事業本部 第1開発部 部長 

    VPoE室 / アルファ室 


    ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版,2020)

    ・連載 : 『スモールチームが武器になる時代へ』(ProductZine)

    ・連載 : 『群知能から紐解く、スケールする“組織“の作り方
    』(NewsPicks)


    @i35_267
    @i35_267
    @i35_267

    View full-size slide

  4. - クリエイター数は、約1,100名

    - 開発チーム数は、約100チーム

    - 現在進行中の開発プロジェクトは、約500個

    - 開発案件の内製割合は、98%

    - 正社員と業務委託の比率

    - 正社員 : 約60%、業務委託 : 約40%


    6
    DMM.comの開発アウトライン


    View full-size slide

  5. 7
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    Outline


    View full-size slide

  6. 仮体制図

    Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir 横断
    組織
    8
    “開発生産性”という言葉は、レイヤーごとに意味が違う

    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    事業責任者

    PdM

    PdM
    PdM
    年商1,000億円

    所属 : 100人

    年商 1億円

    所属 : 10人


    View full-size slide

  7. 事業責任者

    PdM

    Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir
    PdM PdM
    横断
    組織
    各領域をオーバーラップさせる

    9
    事業責任者

    PdM

    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    ・“開発生産性が上げるアプローチと抽象度がレイヤーごとに違う

    ・良いソフトウェアが企業価値を上げるには接続してあげる必要がある

    ・ゆえにオーバーラップする部分(接続箇所)の設計が大事になる”


    View full-size slide

  8. 事業責任者

    PdM

    Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir
    PdM PdM
    横断
    組織
    10
    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    output
    input
    “開発生産性”の次元を変換して、入力と出力で渡してあげる

    output
    input
    output
    input

    View full-size slide

  9. Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir
    PdM PdM
    横断
    組織
    11
    開発チームは、1人月あたりの生産性と向き合う

    経営層

    CxO・役員

    (経営企画 / 経理)

    事業責任者

    PdM

    開発組織


    開発チーム内の向き合い 


    output : 

    - 1人月あたりの生産性を考える

    ※1人月単位なら予算計算がしやすい


    要素 : 

    - ソフトウェアの内部品質、 エコシステム

    - Four keys, テストカバレッジ 

    output

    View full-size slide

  10. 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つの側面

    ● 速度:作業の速さ

    ● 品質:仕事がどれだけうまく行われるか(内部品質・外部品質)

    ● 満足度:その仕事がどれほど満足しているか”

    View full-size slide

  11. 13
    大事にしたい方針の質問からメトリクスを決めていく

    引用 : Table 5-1 Breaking Down Productivity Goal 1 Along the Three Dimensions 


    View full-size slide

  12. 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


    View full-size slide

  13. 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


    View full-size slide

  14. 横断
    組織
    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 管理の管理


    View full-size slide

  15. 横断
    組織
    Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir
    PdM PdM
    17
    継続的な事業を作るために、お金に向き合う

    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    事業責任者

    PdM

    お金への向き合い


    input : 

    ・開発生産性 = 1人月あたりの単価

    ※同じ単価でも工数価値が違うと施策回数と質が違う


    model : 

    ・工数×単価を予算として戦略・戦術の遂行計画

    ・この開発力での勝ち筋を見つける

    ・投資への金額判断


    output : 

    ・売上利益

    output
    input

    View full-size slide

  16. 横断
    組織
    Eng Des Eng Eng Des
    BM BM
    経理
    経営
    Eng
    EM PM/Dir
    PdM PdM
    18
    持続可能な資産に向き合う

    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    事業責任者

    PdM

    ソフトウェア資産への向き合い


    input : 

    ・開発生産性 = ソフトウェアの資産価値 


    model : 

    ・B/S上のソフトウェア資産 = 税負担・減価償却
    費用の最適化


    output : 

    ・税負担・減価償却費用の最適化 

    output
    input

    View full-size slide

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

    View full-size slide

  18. Eng Des Eng Eng Des
    BM BM
    経営
    Eng
    EM PM/Dir
    PdM PdM
    横断
    組織
    20
    開発組織


    経営層

    CxO・役員

    (経営企画 / 経理)

    オーバーラップさせる箇所のモニタリング

    事業責任者

    PdM

    モニタリング基盤を構築して、

    正しくレポーティング

    Sales
    Mktg
    BigQuery
    man-month
    (⼯数)
    スループット
    (1⼈⽉あたりの⽣産性)
    cost(⾦額)
    経理
    資産価値 / 減価償却

    View full-size slide

  19. 22
    select

    project_code

    , 工数

    , 工期

    , 実金額

    , 完了予定日

    , 資産計上区分

    where

    {{本部名}} = “xxxxxx”

    and {{部門名}} = “xxxxxx”

    and {{チーム名}} = “xxxxxx”

    ・開発業務区分

    ・開発コード

    ┗ 毎月の工数・金額

    ┗ 毎月の人数

    ┗ 進行ステータス

    ・完了予定日・予実

    ・資産計上区分


    BigQuery

    View full-size slide

  20. 23
    開発業務区分

    ビジュアライズ

    開発施策

    月単位 - 金額

    完了予実

    資産計上区分

    全体サマリー

    月単位 - 工数

    部署名


    View full-size slide

  21. - ソースコードをホスティングして可視化

    - 1つのOrgにリポジトリが集約。コード資産が一元的に見れる




    - チームや組織ごとにサイロ化せずに中央集権型にしてログに残す

    - チーム横断で学習と予測に使う


    View full-size slide

  22. 26
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    Outline


    View full-size slide

  23. 27
    開発チーム × 開発生産性は、
    1人月あたりの生産性を考える

    機能A
    予想工数

    3人月

    1,500万

    フロー効率のチーム

    機能B 機能C
    1人月

    チーム単価500万

    1人月

    チーム単価500万

    1人月

    チーム単価500万


    View full-size slide

  24. 28
    機能A
    予想工数

    3人月

    → 5.5人月

    → 2,750万


    フロー効率のチーム

    機能B 機能C
    開発生産性に影響あるもの

    ・システムの内部品質

    └ リファクタリング、技術負債、エコシステム

    ・チーム生産性

    └ Four Keys、ベロシティー,etc…

    見えやすい

    数値化しやすい

    見えにくい

    数値化しにくい

    追加予算、1,550万

    開発チーム × 開発生産性は、
    1人月あたりの生産性を考える


    View full-size slide

  25. 29
    開発チーム × 開発生産性は、1人月あたりの生産性を考える

    機能A
    予想工数

    3人月

    → 5.5人月

    フロー効率のチーム

    機能B 機能C
    開発生産性に影響あるもの

    ・システムの内部品質

    └ リファクタリング、技術負債、テストカバレッジ

    ・チーム生産性

    └ Four Keys、ベロシティー,etc…

    見えやすい

    数値化しやすい

    見えにくい

    数値化しにくい

    追加予算、500万

    遅れた事実はわかりやすいが

    “なぜ遅れたか”は、数値化しにくい。


    生産性が悪化する要因をきちんと言語化して

    説明責任は自分たちが果たす


    できるだけ内部品質にこだわり、

    自分たちが立てた予想工数を超えていく


    View full-size slide

  26. 30
    機能A 機能A
    1人月

    チーム単価500万

    1人月

    チーム単価500万

    継続的に、1人月あたりの生産性を爆速にしていく


    予想工数を超えていく = 常に自分たちを超えていく = 信頼度


    View full-size slide

  27. 引用 : Is High Quality Software Worth the Cost?

    内部品質を怠ると、すぐに影響がでる


    View full-size slide

  28. 32
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    Outline


    View full-size slide

  29. プロセスと流れてくる情報を考えて、リードタイムを短くする

    PdM / DataAnalyst

    開発チーム

    PM / EM


    View full-size slide

  30. PdM / DataAnalyst

    リソースプールのペイン

    └ 理想スケジュールに間に合わないからエンジニアを追加したい

    └ しかし、スキルが合わなかったり、チーム文化もそう簡単にトレードできない

    └ ただ、採用だと間に合わない。育成はもっと間に合わない


    スケジュール / リスク管理のペイン

    └ スケジュールの手戻りがあるたびにWBS更新

    └ スコープを削ってなんとか間に合わせる作戦

    └ 開発の遅れによる追加予算の交渉

    PM / EM

    開発チーム

    開発作業の周辺にハードルが多い

    ペイン


    View full-size slide

  31. 開発チーム

    PM / EM

    PdM / DataAnalyst

    戦術(施策)のペイン

    └ 施策実施の成功確率が上がってこない。ゆえに計画の工程が長引く。

    └ 開発リソースは確保してしてもったいないから、とりあえずバックログへ”優先度高”で    突っ
    込む

    └ データアナリストから効果的そうな施策が出てきて、差し込みが連発

    └ 開発側からくる追加コストの意義がわからない + 予算がない(リファクタリング等)

    不確実性への対応が、組織としてできていない

    ペイン


    View full-size slide

  32. プロセスと流れてくる情報を考えて、リードタイムを短くする

    PdM / DataAnalyst

    解決策

    ・一気通貫したプロセスと流れてくる情報を管理

    ・そのための組織設計を作っていく


    View full-size slide

  33. 37
    1. 枠を作り、

    2. 人をアサインし、

    3. 権限と裁量を定義し、

    4. 流れる情報をレポートライン作る
    プロセスの作り方


    View full-size slide

  34. 38
    └ 会議体設計

    └ PRD / Design Doc 

    枠を作り、 人をアサインし、 裁量と権限を定義し、 レポートラインを作る
    └ job description

    ・事業構成に必要な枠

    ・プロダクトとシステムを

    考慮(コンウェイの法則)

    ・枠に耐えうる人材がいるか

    ・兼務祭りにならないか

    ・採用はできるのか

    ・何が単独で意思決定できるか

    ・裁量があって決定権がないのは
    NG

    ・どこで何を意思決定するか

    ・フォーマットは何か

    プロセスの作り方


    View full-size slide

  35. 39
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    Outline


    View full-size slide

  36. 40
    事業/経営 × 開発生産性は、事業の
    お金と資産に向き合う 

    売上
    費用
    利益
    開発に紐づく勘定項目

    (主に一般管理費)


    └ 人件費(給与・賞与)

    └ 外注費

    └ 法定福利費

    └ 福利厚生費

    └ 地代家賃

    └ 減価償却費

    └ 採用費

    └ ツール・手数料費

    └ サーバー設備費


    等々


    損益計算書(P/L)
 貸借対照表(B/S)

    資産
    負債
    純資産
    └ 固定資産

    └ 無形固定資産

    └ ソフトウェア


    View full-size slide

  37. 41
    開発生産性をあげると、P/Lはどうなるか

    メリット

    ・0→1の場合は投入コストが下がる

    ・追加人件費の削減

    ・見えない予算の削減

    ・年間を通して施策回数が増えるので間
    接的にKGIに寄与する変数となる

    売上
    費用
    利益
    開発に紐づく勘定項目

    (主に一般管理費)


    └ 人件費(給与・賞与)

    └ 外注費

    └ 法定福利費

    └ 福利厚生費

    └ 地代家賃

    └ 減価償却費

    └ 採用費

    └ ツール・手数料費

    └ サーバー設備費


    等々


    損益計算書(P/L)


    View full-size slide

  38. 42
    ソフトウェア資産計上を理解する

    貸借対照表(B/S)

    資産
    負債
    純資産
    ソフトウェアの資産計上

    価値

    時間

    ソフトウェア仮勘定

    資産計上 → 減価償却開始

    開発中
 1年
 2年
 3年

    └ 固定資産

    └ 無形固定資産

    └ ソフトウェア


    残存価値

    4年
 5年


    View full-size slide

  39. 43
    ソフトウェア資産計上を理解する

    1. ソフトウェアを作る

    2. 資産化 or 費用化の判断

    3. 資産化の場合は、減価償却

    a. 3年 or 5年かけて費用配分

    b. 資産価値の減少を正しく表現

    4. 費用化の場合は全額費用化

    価値

    時間

    ソフトウェア仮勘定

    資産計上 → 減価償却開始

    開発中
 1年
 2年
 3年

    残存価値

    4年
 5年

    ソフトウェアの資産計上


    View full-size slide

  40. 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万

    ※ 初年度


    View full-size slide

  41. 企業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 : 開発コストが高いため減価償却費が大きく、税前利益が
    低くなる。


    ただし、開発の観点から中長期な目線だと早い方が良い 

    - 早期の市場投入 / 競争優位の確保

    - 減価償却費(損益計算書)が低いことでの事業インパクトが下がる

    - 財務レバレッジの低減(負債や外部資金への依存低下)

    View full-size slide

  42. 46
    - 前提として、資産化するべきか費用化するべきかの
    議論はある

    - エンジニア含めて作っているプロダクトの資産価値
    を理解するにはここから始めるのが良い 

    引用 : https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5403.htm
    ソフトウェアを資産化するか、費用化するか興味をもつ


    View full-size slide

  43. 47
    - “開発生産性”という言葉は、レイヤーごとに意味が違う

    - 開発チーム × 開発生産性は、1人月あたりの生産性と向き合う

    - 仮説検証 × 開発生産性は、 プロセスと組織設計と向き合う

    - 事業/経営 × 開発生産性は、持続可能な資産とお金に向き合う


    まとめ


    View full-size slide