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

1年で人数1.5倍、PR数5.5倍増。 品質とアウトカムはどうなったか、 何が効いたか

Avatar for ike ike
June 27, 2026

1年で人数1.5倍、PR数5.5倍増。 品質とアウトカムはどうなったか、 何が効いたか

Avatar for ike

ike

June 27, 2026

More Decks by ike

Other Decks in Programming

Transcript

  1. 池松 恭平 / ike @ike002jp  2021/05〜 カウシェ   Backend Engineer   ➝ EM

    / PdM   ➝ CTO  2014/04〜 DeNA   Backend Engineer   ➝ EM
  2. 技術職系は30名。1チーム数名の⼩チームが複数ある体制で運営。 Ad/UX Team プロダクト部 所属 (8名) テクノロジー部 所属 (28名) 正社員:PdM

    (ex:DeNA) 正社員:PdM 新卒 業務委託:PdM (ex:DeNA) 正社員:Design 業務委託:Design 正社員:Backend (ex:Showcase Gig) 正社員:Mobile EM (ex:スタンバイ) 業務委託:Backend 正社員:Backend EM (ex:サイバーエージェント) 業務委託:QA (ex:LINEヤフー) 業務委託:Data 正社員:Backend (ex:Speee) 正社員:Mobile (ex:サイバーエージェント) 正社員:Backend EM (ex:ラクスル) 業務委託:Backend (ex:HRBrain) 業務委託:Backend 業務委託:Backend 業務委託:Mobile (ex:サイバーエージェント) 業務委託:QA (ex:LINEヤフー) 業務委託:ML (ex:モノタロウ) 正社員:Backend (ex:ミツカリ) 正社員:Mobile EM (ex:メルカリ) 業務委託:Backend (ex:freee) 業務委託:Mobile (ex:DeNA) 正社員:CTO (ex:DeNA) 正社員:Backend (ex:フラー) 業務委託:Backend (ex:DeNA) 正社員:PdM 新卒 Farm Team ※ 内部で仮想的に2チームで運⽤ 正社員:Backend (ex:HRarain) 正社員:Backend (ex:DeNA) 業務委託:Backend 業務委託:Backend 業務委託:Mobile 業務委託:QA (ex:SHIFT) 正社員:QA (ex:マネーフォワード) 業務委託:Backend (ex:DeNA) EC Team ※ 内部で仮想的に2チームで運⽤ 新規 Team ML / Data Team Platform Engineering Team
  3. 技術職系は 19 ➝ 30⼈(1.5倍) Merge PRは⽉に 252 ➝ 1,400件(5.5倍 )

    中以上障害は⽉に1-6件で横ばい 1⼈あたり売総は1.6倍
  4. 知能労働のモニタリングコストは圧倒的に安くなった • AI前 ◦ 「ほどほど」で⽌まりがち ◦ e.g. Four Keysとその周辺を⾒る •

    AIによる変化 ◦ 数値取得‧分析‧可視化の実⾏コストが⼤きく減少 ▪ 現実的にモニタリング可能な指標が⼤幅に増加 ▪ 徹底的な深堀りが可能に
  5. カウシェでこの1年で、モニタリング対象となった指標の例 • AI起点のPull Requestの割合 • Pull Requestのうち、設計系のPull Requestのリードタイム • AIのみで(⼈介在なしで)レビュー完結しているPull

    Requestの割合 • 施策の実装の計画書と、実際どうだったかの乖離率 • Pull Requestの1commit率 • … ※ 今までも⾒ようと思えば⾒れていたものも多いが、   コスト(⼿間)が⼤きすぎて、損益分岐点を超えていた
  6. 改善していくための、徹底的な深堀りが可能に • 新規加⼊者のXX数値は‧‧‧ • 新規加⼊者を除いた、チームごとのXX数値は‧‧‧ • レビューリードタイムは全体の課題なのか、 特定個⼈、あるいは特定集団の課題なのか? • PR数伸びているが、Skill改修等、

    機能開発ではないPRの増加で開発⼒が薄まっていないか? • 現時点でReview時間が⻑い⼀部のPRの、特徴や共通点は何? 平均じゃなくて、中央値は? 90パーセンタイルは? • ⼈がReviewしているPRとして残っているのは、想定通りの特徴のPRが残っている?
  7. • ⼈数が増える中で、本当は何に課題があるのかの特定 ◦ 様々なカットで様々な指標を定期的に確認 ▪ ⼈別、チームごと、技術領域別(Backend, Mobile, …)、 PR種類別(実装, 設計,

    テスト, リファクタ, …)、etc ◦ 確認したうえで、原因を仮説化 ▪ オンボーディングなのか • タスクのアサインができていない? ▪ 1チームのサイズなのか • メンターに負荷集中してて、開発時間が減少? ◦ ⼈が増える過程でも、どのチームで何が起こっているか、 ⼈に聞かずともわかりやすい 以前は諦めていた計測‧分析の例1
  8. • AIのみReview完了率 ◦ レビューのボトルネックを解消したくて設定 ◦ 単純な指標に⾒えるが… ▪ 多数のbotがいるので、どれがAIかの判定 ▪ approveの順序やrejectの考慮

    (⼈があとからapproveしたら?) ▪ 集計対象メンバーの管理 ▪ etc ◦ 結果 ▪ Reviewの⾃動化に改善アクションが集中 ▪ PRの83%がAI⾃動でReveiw ➝ Mergeされる状態に 以前は諦めていた計測‧分析の例2
  9. AI前提での、指標化 & モニタリングのメリット • ⼈が増える過程でも、どのチームで何が起こっているか、 ⼈に聞かずともわかりやすい ◦ 全体の構造的な課題なのか ◦ 特定チーム、特定個⼈に起因する課題なのか

    • 改善ポイントの仮説強度を上げられる ◦ 「たぶんここが課題かな…」 ➝ 「ここしかなくない…?」 ◦ ⼈数が少ない中だと、改善を外すわけにもいかないので重要 • 結果、AI活⽤のリソース投下場所を絞れる ◦ 各々の思う改善を⾊々やっていく、よりも、 フォーカスができて成果が得られやすい
  10. 告知 • 📣 採⽤中 📣 ◦ Backend、Mobile、Platform、ML/DS、Data、EM、VPoE、PdM、Designer … • 📣

    7/17 (⾦曜)、7/24(⾦曜) 1930〜 渋⾕カウシェオフィスにてMeetUpを開催 📣 ◦ 「カウシェって実際どんな感じなのか」 ◦ 「中の⼈に直接はなしを聞いてみたいな」