開発生産性を組織全体の「生産性」へ！ 部門間連携の壁を越える実践的ステップ

Transcript

1. 開発生産性を組織全体の「生産性」へ！ 部門間連携の壁を越える実践的ステップ 開発生産性カンファレンス2025 2025年7月4日 牛窪 翔
2. 自己紹介 2 • 牛窪 翔 (Sho Ushikubo) • 株式会社kubellでエンジニアリングマネージャーをしています • 筋トレが趣味です • どうすればひとがより生産的で、かつ楽しく働けるのかに重きを おいて、マネージャーとして試行錯誤しています ◦ 組織開発や事業管理、人的資本経営に関心があります • Xとnoteでマネジメントや (最近は) 生成AIの発信をしています ◦ X (旧: Twitter) - @sudo5in5k ◦ note - @sudo5in5k
3. 事業概要 *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2025年3月末時点。 • 国内最大級のビジネスチャット「Chatwork」を展開 業界のパイオニアであり国内利用者数No.1*1 導入社数は91.4万社*2を突破 • 圧倒的な顧客基盤とプラットフォームを背景に、チャット経由で業務を請け負いDXを推進する BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」 業務代行 経理・総務・事務など幅広い業務に対応 人事・労務など専門性の高い業務に対応 採用 経理・会計 労務 営業事務 AI・SaaSを徹底活用 3
4. なぜ開発生産性は部門で隔たりがあるのか 開発生産性指標 • Four Keys（DORA） • SPACE Framework • 開発者体験指標 目的はチームの健康度や 技術的効率性 ビジネス上の指標 目的は事業成長や 競争優位性 なぜこの乖離が生まれるのか？ 時間軸の違い 開発：短期改善サイクル ビジネス：中長期成果重視 言語の違い 技術指標vs財務指標 成功基準の違い 開発：品質・速度の向上 ビジネス：売上・利益への貢献 • 売上・利益成長率 • 従業員生産性 • ROI/投資効率 導入 4
5. なぜ開発生産性は部門で隔たりがあるのか 導入 https://qiita.com/hirokidaichi/items/53f0865398829bdebef1 「開発生産性について議論する前に知っておきたいこと」より引用 レベル1に相当する開発生産性と、レベル3orそれ以上であるビジネス価値・指標とは、部門を跨いだ壁がある状態 5 部門間の「言語の翻訳」が必要で、技術的な成果を事業的な価値に変換し、お互いが理解できる共通言語・指標の構築が鍵
6. 今日お話すること 導入 理論編 実践編 問いかけ編 開発生産性は理解していることを前提に、それをどのように部門間の共通言語・生産性指標とつなげ昇華させていくか 本資料の構成 体系化・抽象化したプロセスの説明 kubellにおける実践例 みなさんができるアクション 各章で以下を説明 • 1章 - 部分言語の理解と構築 • 2章 - 共通言語の設計 • 3章 - 共通言語から指標化 6
7. 01 | 部分言語の理解 と構築
8. 部分言語の理解と構築 - 現状把握と深堀り 第1章 各部門のKPI・経営数値を微底的に確認する 決算資料や社内資料を隅々まで目をこらして、現状を正確に把握する どこを見るか • 決算資料・IR資料 • 部門別レポート • 経営会議資料 • OKR/目標管理資料 何を探すか • 経営重要指標 • 目標値・基準値 • 成長戦略との関連 • 課題・ボトルネック なぜ重要か • 共通言語の基盤 • 接続ポイント発見 • 各方面との対話準備 重要な観点 「数値を見つける」だけでなく、「なぜその数値が重要なのか」「どう測定されているか」「誰が責任を持っているか」 まで理解することで、後の共通言語構築の成功を決める 理論編 8
9. 部分言語の理解と構築 - 現状把握と深堀り 第1章 実践編 kubellでの現状把握プロセス 各部門ヒアリング・決算資料分析・経営ダッシュボード調査からエンジニア組織ではどういった課題がありそうか？ 部門別ヒアリング エンジニア・EM プロダクト部門・事業管理部門 本部長・役員陣 各部門が追う具体的なKPIを確認 決算資料分析 IR資料・決算説明会 EBITDA・売上高 従業員1人あたり営業利益 経営が最重視する数値を特定 ダッシュボード調査 経営ダッシュボード Findy Team+ プロジェクト進捗シート 既存の測定方法・ツールを確認 ヒアリングで出てきた課題・疑問 • 「プロダクトロードマップ通り施策がリリースできる？」 • 「開発の運用保守比率はどれくらい？」 • 「エンジニアの活動がどう経営上の指標に役に立っているだろう？」 • 「新しいツール導入の費用は妥当？・これまでかかっている費用は最適化されているもの？」 9
10. 10 https://www.kubell.com/ir/library/presentations/ 株式会社kubell 「2025年12月期 第1四半期 決算説明資料」より引用 重要視しているのは、売上高・利益・EBITDA 部分言語の理解と構築 - 現状把握と深堀り 第1章 実践編
11. 11 https://www.kubell.com/ir/library/presentations/ 株式会社kubell 「2025年12月期 第1四半期 決算説明資料」より引用 KPIはARR(年間経常収益)・登録ID数・課金ID数・ARPU(課金IDあたりの平均単価)を重視 部分言語の理解と構築 - 現状把握と深堀り 第1章 実践編
12. 部分言語の理解と構築 - 現状把握と深堀り 第1章 実践編 kubellでの深堀り 営業利益の分解から考える 売上 - 費用 = 営業利益 エンジニアの活動は売上に「直接」貢献しない 費用削減は直接貢献可能 12 費用削減のアプローチはときに必要だが、 持続的な成長にはならないと判断
13. 部分言語の理解と構築 - 現状把握と深堀り 第1章 実践編 kubellでの深堀り 営業利益の分解では見えづらかったが、EBITDAとソフトウェア資産計上の文脈から考える EBITDA = 営業利益 + 減価償却費 ソフトウェア資産計上の基本構造 項目 説明 資産計上 開発にかかった費用のうち、一定の要件 を満たすものは「ソフトウェア」として 無形固定資産に計上される 減価償却 資産計上されたソフトウェアは、通常数年に わたって償却される（例：5年定額法など） EBITDAとの 関係 EBITDAは「営業利益＋減価償却費」なので、 人件費やシステム費が一括費用化されない ことでEBITDAが高く見えるようになる フローで見ると エンジニアが資産計上しうるシステムやプロダクトを開発 システム・プロダクト開発活動の実施 開発の人件費や外注費、システム費の一部が「資産計上」 無形固定資産として計上 P/Lにはその年度に全額反映されず「減価償却」される 数年間にわたって分割して費用計上 財務指標の改善に直接貢献 EBITDA増加 エンジニアが資産計上になる(=収益性が見込めそう)プロダクト開発をすればEBITDAという経営指標に直接貢献 13
14. 部分言語の理解と構築 - 現状把握と深堀り 第1章 問いかけ編 あなたの会社では何の数字を追っていますか？ 収益構造・利益分解・様々な指標を解釈 → エンジニア活動の寄与をじっくり考えてみよう 会社が追っている数値 経営重要指標（売上、利益、成長率など） 例：ARR、EBITDA、LTV/CAC... 競合比較で使われる指標 例：従業員1人あたり売上、市場シェア... 今すぐできるアクション 決算資料・IR資料を確認 最新の決算説明会資料をダウンロード 他部門との1on1設定 各部門のマネージャーと30分の対話 社内ダッシュボードの調査 既存の数値管理ツールを隅々まで確認 エンジニア部門の目標 デプロイ頻度、リードタイム、品質指標... 他部門（営業、マーケ、CS等）の目標 各部門の重要指標を書き出してみよう 14
15. 部分言語の理解と構築 - 部分言語化 第1章 発見を「言語」に変換する ①現状把握 ②深掘りの結果を、みんなが理解できる形に言語化しよう 部分言語基本テンプレート 【誰が】→【何をした】→【結果こうなる】 例：kubellの場合 【エンジニアが】→【新規施策を開発した】→【結果EBITDAが向上する】 【エンジニアが】→【DBリプレイスした】→【結果費用が削減される】 実際に作ってみよう！ 関係性を整理 • エンジニアの活動は何？ • それが経営指標にどう影響する？ • どんな数値や言葉で表現できる？ 文章を作成 • 上記テンプレートを活用してもよいです • 簡潔に、数値があれば具体的に実際に書いてみよう 問いかけ編 実践編 理論編 15
16. 02 | 共通言語の設計
17. 共通言語の設計 第2章 理論編 ここまでで作ったもの・もとからあるもの 経営・他部門向け 部分言語 #1 エンジニアの活動がどの指標に結びつくものなのか言語化と知識 課題：まだ分離したままで、2つの部分言語がつながっていない エンジニア向け 部分言語 #2 開発生産性指標 （Four Keys）など 解決策：架け橋を作る ① 接続の設計 両方の言語を理解し、共通言語化 ② 指標の作成と共有 なぜその指標が重要なのか 全員での共通認識 ③ 継続的調整 部門間での 定期的な見直しプロセス 17
18. 共通言語の設計 - つながりの可視化 第2章 実践編 接続の設計 部分言語の集合から、エンジニアの活動と 経営指標の中間過程を可視化する kubellでの設計法：相関マップの作成 エンジニアの活動と経営指標をつなげるための 活動を、職能ごと相関（≒因果）マップで可視化 相関マップの目的 • エンジニアの活動と経営指標の間にある「中間成果」を含めて、相関（因果）関係を流れとして可視化したマップ • 仮説を出し、対話を生むことが目的 で、継続的にアップデートする未完成の構造図 として活用 • 虫食い（未定義や関係がありそうだが未確定な要素のつながりがある状態）な箇所があっても問題ない 18
19. 共通言語の設計 - つながりの可視化 第2章 実践編 EBITDA 資産計上できるプロジェクトをフロー効率で 積み上げることでEBITDAの向上に貢献 費用 適切な費用削減と資産計上プロジェクトの バランスを最適化し営業利益に貢献 品質 SLA準拠と技術的負債解消によるEBITDAと 費用の最適化を支える 組織レイヤー 経営層 CTO/CPO PdM EM エンジニア どれだけEBITDA を増やせるか どれだけ資産計上できる施策を「フロー効率で」積み上げられるか そのために行動したか 各部門でどれだけ費用を抑えられるか 抑えられるシステム・ツールは何か？ 合計費用を 抑えられるか 費用を抑えるため どれだけ効率的な 実装ができるか SLAを違反しないためのプロダクト品質を達成できるか ユーザーの信頼を損なわないか SLI/SLOなどサービスパフォーマンスを 測定する指標を達成できるか EBITDA 費用 品質 相関マップによりいくつかの軸と各職能ごと何がねらいなのかみえてきた結果、共通言語化できそう 19
20. 共通言語の設計 - 共通言語化 第2章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 各施策のリードタイムの基本的な考え方の設定 チーム構成と処理能力 施策ごとに各チームごと誰かが割り当てら れ、人数やスキルレベル・稼働率によって、 おおよそ1日あたりの処理能力は決まる 例：フロントエンドチームは1日あたり2人日 分の作業が可能 施策では、チームごとおおよそ必要な作業量が あり、それらを合算すると総工数になる 例：総工数30人日＝フロント10人日＋バック 5人日＋インフラ15人日（直列なら） 必要な総工数をチーム全体の1日あたりの処理 能力で割ることでリードタイムが算出できる 例：30人日÷6人日＝5日間（※直列なら） メンバーの工数を一定割き、積み上げ、施策に必要な総工数に届き、プロジェクトは完了することでエンジニアの活動を整理 工数の積み上げ リードタイムの計算 • プロセス間の依存関係がある（例えばkubellであればざっくりと、要求・要件定義→設計→開発→QA→運用） • 資産計上できても、プロダクト観点で新規機能を作るのか・機能改善施策なのか・開発観点で運用保守寄りなのか、求 められるフェーズや戦略に伴って、どこに重きを置くか、どのようなプロダクトKPIを伸ばしていきたいかは変わる 開発プロセスや施策内容もリードタイムに関係する 20
21. 共通言語の設計 第2章 問いかけ編 1 つながりの可視化 エンジニア活動と経営指標の中間過程を 可視化する 可視化する方法は何がよさそうか？ 活動と経営指標の間の「中間成果」は？ どの職能がどの活動にどう関わるか？ 2 仮説と対話の生成 未完成の構造図として活用し継続的に 対話を促す どんな仮説を立て、検証すべきか？ 対話を生むための効果的な問いかけは？ 虫食い状態でも進められる所は？ 3 共通言語への転換 つながりから共通理解を得て言語化 職能間で共通理解できる概念は？ どう定義すれば多くの職能で使えるか？ 部門固有の文脈をどう共通言語にする？ 部分言語のつながりを可視化、対話を通じて共通言語を設計してみよう 明日から始められる実践ステップ • 小さく始める ◦ 一部の活動と指標だけでも可視化し始め、対話のきっかけを作る (例: kubellの場合は相関マップ) ◦ 完璧を求めず、まずは仮説を可視化することが重要 • 多様な視点の統合 ◦ 複数の職能で共通しているものや、それぞれ異なる言葉で表現している同じ概念を見つけて共通理解を図る • 継続的な更新 ◦ 可視化した成果物は「完成品」ではなく「進化するツール」 ◦ 新たな気づき・対話から得られた洞察を反映させよう 21
22. 03 | 共通言語から 指標化
23. 共通言語から指標化 第3章 理論編 指標を作る際のポイント 接続の設計と整合性がとれる指標設計か とれない場合は指標を変える、指標が正しそうなら接続の設計を変えるチャンス 指標から何を期待し、誰がどんな行動に落とし込むか想像ができるか 目的を達成するための課題を明確に示し、行動を促すものでなければいけない いきなり複雑にしすぎない、多く作りすぎない 全てのビジネス指標や開発生産性指標と結びつける必要はなく、組織に適した材料やこれまでのデータを活かすアプローチ 問いかけ編 共通言語から指標を作成しよう これまでの成果を形にして、部門間の連携・責任の明確化・整合性のある意思決定や対話を助けるものにしよう 23
24. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 24
25. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 工数を使って(input) 施策を出している(output) 施策あたりの工数の記録開始 月次で施策の平均工数を指標化 25
26. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 資産化金額が達してるか？ また、それを裏付ける 割合が高いか？ 金額・割合を追っていく 26
27. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 割合が低いとしたら、 資産化できる施策を 高い頻度で実施できているか？ 開発上の運用保守が多いかも しれない？ 施策の種別を記録し、実施割合 も確認する数値 27
28. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない あまり施策が実施しきれてないな ら、施策のリードタイムが 伸びていないか？ もしくは施策数が少ないか？ 施策数とリードタイムを記録し、 追っていく 28
29. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 施策のリードタイム が伸びているなら、 どこかのプロセス (要件, 見積もり, 設計開発, QA, etc..) でボトルネックがないか？ 各プロセスリードタイム指標化 29
30. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 各チームでの変更リードタイム の面で改善できる プロセスがないか？ 変更リードタイム指標で確認 (Findy Team+) 30
31. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 各チームで施策を増やすためにデ プロイ頻度の面で 改善できるプロセスがないか？ デプロイ頻度指標で確認 (Findy Team+) 31
32. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない ビジネス指標・ねらいと 開発生産性を つなぐ共通言語と指標ができた 32
33. 共通言語から指標化 第3章 実践編 全職能の人たちが、フロー効率で(リードタイムを短く)、多くの資産計上できる施策の完了に貢献できるかを言語に 課題の原因を深堀りしやすいような指標設計にする、KPIツリーのように厳密でなくてかまわない 原因の深堀りができる指標設計にすることと、 そのための接続の設計方針を考えることが大事 (例: kubellの場合は相関マップ) 33
34. 共通言語と指標化、その後の注意点 補足 1 因果関係が曖昧になりがち • 共通言語と指標化は因果関係でなく、相関止まりのものもある • 仮説とその検証の運用をある程度の期間継続すること (特にこれらの指標の関連は遅行性がみられる) 2 抽象化と数値化のバランスが大事 • 部門間の共通言語は言葉だけ共有されても意味が通じづらい、指標化だけしても独り歩きしてしまう • 活用されるコンテキストや判断にどう反映されるかも共有すること • 数値で判断できない価値（信頼関係・文化）も尊重すること 3 スモールスタートからでよく、対話のきっかけにしよう • 共通言語や指標を作っても、定着させる合意コスト・文化適合は必要で、効果を確認・FBをもらい改善を繰り返す • 手段が目的化しないようにし (グッドハートの法則)、「監視」でなく、「対話のきっかけ」を 34
35. 生産性は育てていく「生きた言語」 総括 今日お話したこと: どのように開発生産性と部門間の共通言語・生産性指標とをつなげていくか 一度作って終わりでなく、対話を通じて改善し続ける「生きた言語」として育てて、組織全体を生産的にしましょう！ 35 1 部分言語の理解と構築 各部門のKPI・指標を理解し、 エンジニアの活動がどう貢献するか言語化 2 共通言語の設計 エンジニアの活動と経営指標のつながりを可視化し、 部門横断で通じる「共通言語」を設計 3 共通言語から指標へ 設計した共通言語から指標を作り、 課題の発見と具体的な改善アクションを促す