AI時代の開発を加速する組織づくり - ブログでは書けなかったリアル

Transcript

1. 2025.10.23 AI時代の開発を加速する組織づくり - ブログでは書けなかったリアル “コト”に向き合えているか？AI時代に再考する開発組織のあり方 発表者：増田 浩之 / Product Lead Engineer
2. ⾃⼰紹介 増⽥ 浩之 / Masuda Hiroyuki 株式会社カナリー 『CANARY』Product Lead Engineer 略歴 ⾦融‧⼩売‧営業⽀援など、幅広いスタートアップでのテックリード経験を 経て、株式会社カナリーに⼊社 現在は『CANARY』プロダクトリードエンジニアとして、開発推進、 Enabling、採⽤、マネジメントに取り組む リアルな⽇常 息抜きの時間 󰔡 3⼈の⼦育て真っ最中！毎⽇てんやわんやですw 💼 仕事と⼦育ての両⽴は正直⼤変...でも楽しんでます！ 🏃 毎朝、⻑男と⼀緒にランニング 🚗 家族でドライブ
3. Mission もっといい をつくる
4. Mission もっといい をつくる
5. 不動産テック領域において、BtoC/BtoB両軸でプロダクトを提供中
6. 不動産テック領域において、BtoC/BtoB両軸でプロダクトを提供中 ‧BtoC 不動産マーケットプレイス｢カナリー｣ ‧アプリ版 累計DL数 500万 (Web版もあります！) ‧カテゴリ内ユーザー評価No.1(App Store ★4.8)* ‧TVCMも全国で放映
7. 不動産テック領域において、BtoC/BtoB両軸でプロダクトを提供中 ‧BtoC 不動産マーケットプレイス｢カナリー｣ ‧アプリ版 累計DL数 500万 (Web版もあります！) ‧カテゴリ内ユーザー評価No.1(App Store ★4.8)* ‧TVCMも全国で放映 ‧BtoB 不動産仲会社向けSaaS｢カナリークラウド｣ ‧累計利⽤者数 200万⼈を突破 ‧後発ながら、全国の地⽅⼤⼿企業様を軸に急成⻑
8. AQUA Voice Try-AI Budget 制度のポイント 利⽤できるAIツール例 開発本部の正社員40名を対象に、1⼈あたり⽉ 額$200まで会社負担でAIツールを⾃由に試せ る制度で、「AIをためらわず試す⽂化」をつく ることを⽬的としています。 💡 「試して学ぶ環境を保証することで、組織全体のAI活用を加速」 GitHub Copilot Claude Code ChatGPT, Codex Cursor Devin そのほか新しいツールも随時追加中！
9. 本⽇のアジェンダ 現状把握 MPチーム詳細‧組織課題
10. 本⽇のアジェンダ 現状把握 MPチーム詳細‧組織課題 問題提起と組織基盤 AI時代の課題‧"コト"に向き合う組織とは
11. 本⽇のアジェンダ 現状把握 MPチーム詳細‧組織課題 問題提起と組織基盤 AI時代の課題‧"コト"に向き合う組織とは 3つの実践 ブログでは書けなかったリアルな体験と乗り越え⽅ ドキュメント⽂化の醸成 運⽤負荷の可視化 チーム体制の最適化
12. 本⽇のアジェンダ まとめと展望 AI時代に必要な組織の⼟台 現状把握 MPチーム詳細‧組織課題 問題提起と組織基盤 AI時代の課題‧"コト"に向き合う組織とは 3つの実践 ブログでは書けなかったリアルな体験と乗り越え⽅ ドキュメント⽂化の醸成 運⽤負荷の可視化 チーム体制の最適化
13. 2019年3名 → 2025年21名 チーム⼈数推移 マーケットプレイスチーム(MPチーム)の詳細 不動産マーケットプレイス事業「CANARY」の開発‧運⽤を担当 取扱物件数も 約600万件を突破！ アプリDL数 550万件を突破！
14. 2019年3名 → 2025年21名 チーム⼈数推移 マーケットプレイスチーム(MPチーム)の詳細 不動産マーケットプレイス事業「CANARY」の開発‧運⽤を担当 毎年約2倍近い成⻑を実現 取扱物件数も 約600万件を突破！ アプリDL数 550万件を突破！
15. MPチームの組織課題 急成⻑による課題 約7割が1年以内に⼊社した新規メンバーで構成される急成⻑フェーズ。 増え続けるメンバーを受け⼊れる体制、メンバー増加に伴った開発⽣産性 も追いつかない状況。 役割‧責任の認識ズレ チーム拡⼤に伴い、「誰が何をすべきか」「誰に判断を仰ぐべきか」の線 引きが曖昧になり、意思決定に⽀障をきたしている。 運⽤負荷‧トイルの偏在 ⽇々の調査‧突発対応‧当番運⽤が特定メンバーに集中。 ミーティングや採⽤⾯談などのオーバーヘッドが⾒積もりに織り込まれ ず、計画と実働が乖離。 属⼈化と認知負荷の増⼤ 情報や知識が特定のメンバーに集中し、チーム全体の認知負荷が増⼤。 コミュニケーションの断絶も発⽣し、開発効率が低下。 意思決定の遅延 最終責任やリーダーシップの所在が明確にならず、⽇々議論に時間を要す る状態。タスクの優先順位や判断基準も不明瞭で効率性が低下。 AIに対するキャッチアップ 急速に進化するAI技術に対し、習熟度や得意分野にばらつきがあった 活⽤ノウハウの標準化や共有の仕組みが整っておらず、チーム全体での活 ⽤に課題
16. AIや新しい技術を導⼊しても… 新しい技術やツールは次々と登場している 開発⼿法やチーム体制、働き⽅も⼤きく変化している ただ、導⼊しただけでは「なんとなく便利」で⽌まることも多い 基盤が整っていないと、かえって混乱や属⼈化を招く壁になることもある
17. AI時代の課題 AIの効果は「組織基盤」次第。整っていなければ課題を加速させる。 幻想 「AIや新技術を⼊れれば⽣産性はすぐに上がる」 現実 「AIは加速器。基盤が未整備だと課題も増幅」 課題 属⼈化 判断の曖昧さ 負荷の偏在 解決 標準化 業務整理‧権限の明確化 リチーミング
18. "コト"に向き合うために必要な組織基盤 "コト"に向き合うために取り組んだこと ブログでも紹介しましたが、今⽇は"書けなかったリアル"を共有します 3つの実践 ドキュメントによる知識基盤づくり 運⽤負荷の可視化 チーム再編と役割の明確化 ⽬指した⽅向性 全体最適 局所改善でなく組織全体を俯瞰 継続的改善 ⼀過性ではなく⽂化に根づかせる
19. ドキュメント不⾜が⽣む混乱 オンボーディング資料の不⾜ ⼝頭説明や属⼈化に依存 業務整理‧権限設計の曖昧さ 責任や役割が不明確 コミュニケーションルールの⽋如 同期/⾮同期の使い分けがなく⾮効率 結果として 混乱や意思決定の遅延、⾮効率が発⽣
20. ブログでは書けなかったリアル - ドキュメント⽂化定着の壁 使われない 何を書くべきか不明確 維持できない 散在する 最初は「とにかく書こう」と始めたが失敗 時間をかけても現場で使われず、費⽤対効果が薄い ガイドラインや運⽤フローが未整備 → 書いても更新されず死んだドキュメント化 書き⽅が⼈によってバラバラで統⼀性がなく、参照しづらい 何をドキュメント化すべきか決まっておらず、 効果が⾒えない現状のコストも⾒えず、どこから整備 すべきか判断できない 似たようなドキュメントがあちこちに散在していて、ど れを信じて良いか分からない 効果が薄い ビジネス側とエンジニア側で同じ対象でも違う⾔葉を 使っており、ドキュメントを作っても伝わらず、部署 横断での活⽤効果が薄かった
21. どう打開したか — ドキュメントを"⽂化"にするために 「何を書くか」を明確化 ⽣産性⾼い企業の調査 優先度ルールを定義 ガイドラインと承認フロー 闇雲に書かず必要なものに集中 レビュー頻度の⾼いコードや FAQ を優先 GitLab, Shopify などの事例研究 ドキュメント種別ごとに効果をマッピング 現場コストを可視化 オンボ時間、再説明回数を計測 調査依頼‧ミーティング時間を記録 効果 × 頻度 × 作成/更新コスト 軽量な計算式で優先順位を数値化 テンプレ‧オーナー‧更新フローを整備 鮮度ラベル（Fresh/Warning/Stale） "効くところから、軽量に" ⼩さく始め、効果を実感できる領域から 仕組み作りで持続可能な⽂化に
22. ドキュメントが"⽂化"になった成果 オンボーディング バディの負荷が軽減 新メンバーが納得感を持って⾃⾛できるようになった キャッチアップ期間が短縮 意思決定 業務フローや権限を⽂書化し、誰が決めるかが明確に 意思決定のスピードが向上 承認待ちや調整の⼿戻りが減少 ⽂化定着 「まずドキュメントを参照する」が習慣化 属⼈化が減り、新⼊社員からも⾼評価 チーム全体で"コトに向き合う"ための合意形成の基盤に コミュニケーション 同期/⾮同期のやり取りが円滑に 再説明や質問対応のコストが削減 チャットでの混乱や誤解が減少
23. 運⽤負荷の偏りと"⾒えない壁" ⾒える偏り 運⽤タスクやトイルが特定メンバーに集中 現状を計測できず、改善アクションにつながらない ⾒えない壁 調査依頼や差し込みタスク 採⽤⾯接‧⾯談などの⾮開発業務 役割ごとの責務（例: TLEの調整や意思決定対応） 結果 本来の開発以外に多くの時間を取られ、負荷の偏在と認識ギャップを⽣む
24. ブログでは書けなかったリアル - 数字を出すだけでは⽂化にならない ブログでは書けなかった部分、数字を可視化するだけでは解決できなかった現実的な課題 ⼊⼒の⼿間 ソースの分散 ミーティング時間 / タスク時間 / 調査依頼 / 差 し込みタスク … → 記録⾃体が負担になり定着しない 影の仕事の抱え込み Notion / Google Calendar / 個⼈メモ … → 集約に時間がかかり、数字の信頼性も揺ら ぐ 形骸化のリスク 数字は出ても「どう活かす？」が決まらず改 善に繋がらない 個⼈依頼や突発対応が共有されず、可視化で きないまま積み上がる
25. どう打開したか — 数字を"⽂化"にするための⼯夫 ⼊⼒ルールの統⼀ Notion＋GASで⾃動集計 データを必ず使うルール化 個⼈依頼をチームに展開 Slackスタンプ、Calendar同期 複数ソースを⼀元化 リファインメントや定例で活⽤ 優先度をリファインメントで調整
26. 運⽤負荷の可視化がもたらした成果 属⼈化の解消 稼働の透明性 当番や調査が特定の⼈に集中せず、分担ルールが機能 MTGや採⽤⾯談を含め、計画と実稼働の差が減少 計画の精度向上 改善の議論活性化 「時間が⾜りない」ズレを減らし、スプリントが安定 抱え込みから共有へ 数字を前提に「どこから⾃動化すべきか」合意形成 個⼈依頼もチームに展開し、リファインメントで優先度を調整
27. チーム体制変更の背景 背景：急成⻑中のMPチーム これまで：短期プロジェクト型 メンバー‧施策‧関係者が急増（7割が⼊社1年以内） 課題：意思決定の遅延 / 認知負荷の増⼤ / 役割の曖昧さ 2〜3ヶ⽉単位で組成‧解散 → 柔軟だが継続性に⽋ける 必要な⽅向性 課題：ナレッジ分断 / 属⼈化 / フロー不統⼀ / 振り返り不⾜ MPチームは「1つのプロダクト」を成⻑させる役割 プロダクト型チーム体制へ移⾏（領域ごとにサブチームを分け、⻑期的に責任を担う）
28. ブログでは書けなかったリアル：合意形成と学びのプロセス 正解は1つではなかった 「TLEはサブチーム常駐」 vs 「全体最適を優先」 トレードオフや葛藤が多く、議論に時間を要した 合意形成には、1on1やリーダー陣との⻑時間の対話が必要だった 誰をどこに置くかは化学反応で、スキルだけで割り切れなかった 短期プロジェクト制ではバス因⼦が低く、属⼈化リスクが⾼いという限界が露呈
29. 打開策 — チーム編成の⼯夫 ⾃⼰組織化 チーム⾃⾝に問いかけ、⾃ら構造を設計 Grow and Split ⼤きなチームを分割し、知識を分散‧持続性を 確保 合意形成 徹底的な対話とコミュニケーションを重視 標準化 開発体制‧組織運営の共通ルールを整備
30. 成果 ー 再編で得られた変化 意思決定の⾼速化 認知負荷の軽減 責任の明確化 ナレッジの蓄積 サブチーム単位で判断でき、調整コストが⼤幅 減少 全員が全体を追わずに済み、領域に集中できる サブチームごとに成果と課題を振り返れる 短期でリセットされず、改善サイクルが回りや すくなった
31. まとめ：AI時代に必要な組織の⼟台 AI時代でも"基盤"がすべて 導⼊以前に整えるべき組織の⼟台 ドキュメント⽂化の定着 運⽤負荷‧トイルの可視化と均等化 チーム構造と役割の明確化 "モノ"ではなく"コト"に向き合う時間を確保する
32. Information 一緒に組織づくりをする仲間を 募集しています！ カジュアル面談 も受付中です。 興味がある方はぜひご応募ください！ Thank you 🎵