開発スピードを落とさないために必要なイネーブルメント組織の在り方

Transcript

1. 開発スピード を 落とさない ために必要な イネーブルメント組織 の在り方 名村 卓 株式会社LayerX
2. 自己紹介 ~ 2016 - 株式会社サイバーエージェント 各種サービスやメディアの開発 ~ 2022 - 株式会社メルカリ USでの開発、CTOなど ~ 現在 - 株式会社 LayerX Enablement担当
3. 今日の内容 様々なサービスを開発における “Enablement” について、過去 の経験や LayerX での実践などを交えて説明し、その重要性 と、組織における在り方について話します。
4. 事業が成功するための サービス開発について
5. 過去、成功してきたプロジェクトの共通項を整理 開発速 度 生産性 意思決 定
6. サービスの立ち上げ期は、満たしやすい 開発速 度 生産性 意思決 定 少人数 コンテキスト理 解 全容を 把握している 意思決定の 数が多い 1人の 担当範囲が 広い
7. 事業の成長と共に起きること 運良くプロダクトがマーケットフィットし、成長すると... 人 が増える 機能 が増える
8. 拡大に伴う様々な弊害 専業化 複雑化 多様化 把握コストの 増大 意思決定の 低速化 自分で 決められない 担当領域の 狭小化 コミュニケーション コストの増大 変更コストの 増大 負債の蓄積 コンテキスト伝達の 難易度上昇 合意が必要
9. 拡大に伴う様々な弊害 専業化 複雑化 多様化 拡大し続けるには、受け入れなければならない
10. どうやって、この弊害と戦うのか？
11. Team Topologies https://teamtopologies.com/
12. 認知負 荷 プロジェクトの生産性を阻害する要素
13. 認知負荷について理解する 脳のワーキングメモリには限界がある 脳は、ワーキングメモリを使って、物事を遂行する ワーキングメモリにかかる負荷が「認知負荷」
14. 認知負荷には、様々な種類がある 内在的 負荷 外在的 負荷 学習的 負荷 Intrinsic Extraneous Germane
15. 課題そのものの難易度や複雑さに関連する負荷 例 “大規模なサービスアーキテクチャの設計” “最適なアルゴリズムの適用” “銀行送金の仕組み” 内在的 負荷 Intrinsic
16. 課題とは関係のない事象の負荷 例 “手動作業での開発環境へのデプロイ” “開発環境の構築が複雑、かつ再現性がない” “開発用マシンへの制約” 外在的 負荷 Extraneous
17. 新たな概念を学習し、知識にするための負荷 例 “コードレビューを受けて問題部分を改修” “ペアプログラミングを実施” “技術的負債の解消” 学習的 負荷 Germane
18. ワーキングメモリにおける認知負荷のバランス 内在的 負荷 外在的 負荷 学習的 負荷
19. Enablement とは何を目指しているのか 外在的負荷を削減 内在的・学習的負荷の軽減する 認知負荷の最適化
20. Enablement とは何を目指しているのか ワーキングメモリ の チューニング
21. Enabling Team
22. LayerX における Enabling Team の役割 認知負 荷の 把握 他チーム への 伝授 ツールや 手法の 開発
23. LayerX における Enabling Team プロダクト開発（スプリント）に直接 参加し、プロダクトの機能開発を行う 定期的にカジュアルな「お茶会」を開催し、 プロダクト開発チームの本音を吸い上げる 認知負 荷の 把握
24. LayerX における Enabling Team プロダクト開発チームの認知負荷を低減する ツールを提案・開発する ツールや 手法の 開発
25. LayerX における Enabling Team プロジェクトに参加し、実際にツールを 導入し、試行錯誤していく Enabling Team がいなくてもツールや手法を 実践できるよう伝授していく 開発 チームへ 伝授
26. Enabling Team にとって重要なこと 技術的に正しいことが 常に正しいわけではない 認知負荷を増やすことは 回避する
27. Enabling Team で気をつけるべきこと 火消し屋にならないように 注意する（期限を決める）
28. LayerX における Enabling 組織の立ち位置 バクラク事業部 プロダクト開発 Platform Engineering Enabling Team DevOps Team ・ ・ ・ ・ ・ ・
29. 開発組織以外への応用 エンジニアリング以外の全ての領域でも 認知負荷の概念は共通 営業・マーケ・人事・経理など、あらゆる会社組織でも認知負荷 の改善を目的とした “Enablement” は有効
30. LayerX における Enablement 事例の紹介
31. エンジニアオンボーディングの改善例 lx.sh というシェルツールによって、開発環境構築や、開発に 関する支援を自動で行えるようにしている ./lx.sh usage: lx.sh <command> [options] commands: bootstrap Launch setup scripts for setup local development tools <install/upgrade> Install/Upgrade required tools in local machine git <clone|pull|branch> Run git operations for all repositories branch Print current branch name of all repositories init <env|db> Initialize local setup. It runs all without subcommands. docker <start|stop> Start middlewares with docker compose ... https://tech.layerx.co.jp/entry/2022/12/12/131507
32. エンジニアオンボーディングの改善例 lxdev というTUIツールで、開発プロセス実行を簡素化 https://tech.layerx.co.jp/entry/2022/12/12/131507
33. コンテキストを文書で残す文化 ADR (Architecture Decision Records) や Design Docs を残 すことで、コンテキストを把握できるようにする *LLMによって、コンテキストを文書で残すことの重要性がさらに増している https://tech.layerx.co.jp/entry/2022/12/12/131507
34. PR-Agent を活用したレビューコストの削減 GPT-4oを使い、PRに含まれている変更サマリを自動記述 *ただし “Why” はエンジニアがちゃんと書く
35. サービスの利用環境チェック お問い合わせからの問題解決までの情報収集の簡素化
36. プロダクト機能理解のための AI Bot
37. 営業向けの企業調査ツール 様々な企業に関する情報を収集・構造化する
38. 商談分析ツール 営業のコールや商談などを分析し、文字情報化や データ抽出を行う
39. Enablement の今後と可能性 Enablementの 可能性が無限に広がった LLMの発展で 非構造な情報の扱いが 容易になった
40. ご清聴ありがとうございました