開発組織の進化・スケーリングと「開発生産性」

開発生産性カンファレンス 2025での登壇資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. 開発組織の進化・スケーリングと 「開発生産性」 2025/7/3 開発生産性カンファレンス fi 株式会社アトラクタ / Certi ed Scrum Trainer （CST） 吉羽 龍太郎 （@ryuzee）
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー（CST） ▸ X（Twitter）: @ryuzee / https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり
5. 開発組織の進化・スケーリングと 「開発生産性」 ほとんどの企業は数字が大好き。でも多くのことを誤解している ▸ 「数字で測れないものは管理できない」という誤解 ▸ 「数字で測れば管理・改善できる」という誤解 ▸ 「数字で目標を立てれば現場が動く」という誤解 ▸ 「数字で測れば真実が見える」という誤解 ▸ 「数字は一律に比較できる」という誤解 ▸ 「同じ数字を繰り返し測れば改善する」という誤解 5
6. Data is useless without context. 文脈のないデータは 無意味である Nate Silver アメリカの統計学者 メジャーリーグの選手成績予測システム「PECOTA（ペコタ）」を開発し、野球統計界で名を上げた。2008年アメリカ大統領選挙で、州ごとの勝敗予測を的中させたことで一躍有名 になった。 著書に 『The Signal and the Noise: Why So Many Predictions Fail — but Some Don’t』（邦題：『シグナル&ノイズ』）
7. 有効な測定基準を開発するためには、現場につい ての深い知識が相当必要となる。（略）その知識は ほかの状況ではまったく応用できないかもしれな い。難しいのは何を数えればいいか知ることと、そ うやって数えた数字が実際には何を意味している か知ることだ 『測りすぎ――なぜパフォーマンス評価は失敗するのか？』 p.135 ジェリー・Z・ミュラー著、松本裕訳、みすず書房
8. 開発組織の進化・スケーリングと 「開発生産性」 8 ここで（みんな大好き？）開発生産性に目を向けてみましょう fi 出典: ソフトウェア開発における「開発生産性」に関する実態調査レポート https:// ndy.co.jp/3036/
9. 開発組織の進化・スケーリングと 「開発生産性」 まず、「生産性」とは何か？ ▸ 生産性 = 産出 ÷ 投入 ▸ つまり「数字」で表せる ▸ 生産性は大きく2つに分けられる ▸ 物的生産性……生産したものの数や量を元にしたもの ▸ 付加価値生産性……生産したものが生み出した付加価値（金銭など）を元にしたもの ▸ ひとことで「生産性」というと誤解を招く ▸ みんながなんとなくわかる単語をふわっと使うと大体認識が揃わない ▸ DX、アジャイル、AI、MVP…… 9
10. 開発組織の進化・スケーリングと 「開発生産性」 では、「開発生産性」とは何か？ ▸ A. 「チームが所定の期間内で作れるモノの量」（つまり物的生産性。効率） ▸ B. 「チームが所定の期間内で生み出せる価値の量」（つまり付加価値生産性。効果） ▸ どっちなのだろうか？ ▸ 両方なのだろうか？ 10
11. 開発組織の進化・スケーリングと 「開発生産性」 11 実際のところ…… “ 「チームで効率よく働く」（50.6%）と「無 駄な作業を減らす」（47.5%）が上位を占 める結果となりました。一方で、「組織の 業績を上げる」と回答した割合は12.9% にとどまり、この差は統計的に有意な傾向 として確認されています” fi 出典: ソフトウェア開発における「開発生産性」に関する実態調査レポート https:// ndy.co.jp/3036/
12. 開発組織の進化・スケーリングと 「開発生産性」 開発生産性の明確な定義はない ▸ 「物的生産性」（アウトプット、物量、効率）を指して使っていることが多いが、それに限らない ▸ 昨今の議論では「開発生産性」を分類して考えようという流れが見られる ▸ ケント・ベックはエフォート、アウトプット、アウトカム、インパクトの4つに分類して検討 ▸ SPACEフレームワークでは「アウトカム」に注目 ▸ つまりチームや組織で、自分たちの「開発生産性」が何を指すのかを定義しなければいけない ▸ コンテキストが命 ▸ ではコンテキストは？ 12
13. 開発組織の進化・スケーリングと 「開発生産性」 重要なコンテキスト ▸ プロダクトのステージ ▸ チームの構成とチームの性質 ▸ 今回はこの2つをベースに考えていきましょう ▸ 他のコンテキストの例 ▸ そもそもプロダクトなのか、プロジェクトなのか ▸ 内製なのか、外部委託なのか ▸ …… 13
14. 開発組織の進化・スケーリングと 「開発生産性」 プロダクトのはじまり。最初のチーム 14 ※ 模倣型プロダクトだとこのステップはないこともある 仮説検証チーム 変更のフロー ▸ プロダクトの初期は、仮説検証を行う数人の小さなチーム（先遣隊）から始まる ▸ 企画、デザイナー、エンジニアなどが含まれる。少人数で何でもやるので個人の力量に依存する ▸ まだ他の仕事を兼任していることも多く、少人数なのでプロセスもほとんどない ▸ 小さなものをリリースすることもある ▸ 仮説検証でうまくいかなければピボットしたり終了したりする
15. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ 自分たちが取り組む価値のある適切な課題を見つける ▸ お金をかけて開発を始めるべきかどうかを判断する材料を見つける ▸ たとえば顧客候補からの「定性的なフィードバックの収集」 ▸ 優先しなくていいこと ▸ 人の稼働率や効率 ▸ コードの量や品質 ▸ プロダクトの売上 ▸ …… 15
16. 開発組織の進化・スケーリングと 「開発生産性」 16 プロダクト開発を始める（人が増えてアジャイル開発が始まる） ストリームアラインドチーム 変更のフロー ▸ 仮説検証をさらに進めるべく実際のプロダクト開発に着手する ▸ 人を増やし開発できるようにする。それにあわせて何らかのプロセスと責任を決める ▸ 1チームで要件決め、設計、開発、テスト、リリース、運用まで面倒を見る（1チームでなんでもやる） ▸ 1チームなので、アーキテクチャーはモノリシックになるのが普通（モノリスファースト） ▸ プロダクトがうまくいかないと、このままの体制でどこかで終了することも……
17. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ プロダクトそのものが成功に向かって進んでいること ▸ つまり、チームの外側にプロダクトを提示すること ▸ スプリントレビューでも顧客デモでも。プロダクトの価値はチームの外側で決まる ▸ チームの共通理解の醸成（ドメイン、顧客、目的） ▸ 優先しなくていいこと ▸ 完璧な役割分担 ▸ リソース稼働率やタスク消化率 ▸ 細かなプロセスの最適化 17
18. 開発組織の進化・スケーリングと 「開発生産性」 18 プロダクトがうまく行き始めると人が増える ストリームアラインドチーム 変更のフロー ▸ プロダクトの成果が見え始めると、経営層がより多くの「リソース」を投入したくなる ▸ 競合が出てくる前にマーケットシェアを確保するために、開発スピードを上げたい ▸ 少人数ではこなしきれないくらい必要な業務量が増える ▸ 多くの新機能リクエスト、運用やサポート、セキュリティ対応、ドキュメントなどの準備…… ▸ スキルセットの補完（UXやQAなどの専門職）
19. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ プロダクトそのものが成功に向かって進んでいること ▸ リリース頻度やリードタイム ▸ 技術的負債の見える化と適切な対応（開発がプロダクトの成長のボトルネックにならないか） ▸ 認知負荷の軽減 ▸ 優先しなくていいこと ▸ 一人ひとりの「仕事量」を精緻に測ること ▸ 無理に全員に均等にタスクを振ること 19
20. 開発組織の進化・スケーリングと 「開発生産性」 しかし人が増えると課題が増える ▸ 人数が増えるが、扱う仕事の領域や量も増える ▸ その結果、認知負荷が高くなり、開発のパフォーマンスは線形比例では上がらない ▸ 新メンバーのオンボーディングに時間がかかる ▸ アジャイル開発のイベントやミーティングに時間がかかるようになる ▸ つまり人を増やしても、それに見合う効果が限定的になる ▸ そこで構造の見直しを検討する 20
21. 開発組織の進化・スケーリングと 「開発生産性」 21 複数チームによるアジャイル開発への進化 ストリームアラインドチーム フィーチャーチーム 変更のフロー ▸ この時点ではモノリスなので、同一コードベース上で開発するフィーチャーチームに分割する ▸ スキルでチーム分割してしまうと依存関係が増え、リードタイムが伸びやすいので避ける ▸ チーム間は作業の調整が必要なので、プランニングやレビュー、レトロスペクティブを共有 ▸ スクラムの場合、LeSSやNexus、Scrum of Scrumsなどを活用するが、難易度が高い ▸ 複数チームの成果物を継続的に統合してリリースする。つまりストリームは1つ
22. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ プロダクトそのものが成功に向かって進んでいること ▸ チーム単位のスループットではなく、全体のフロー効率 ▸ 全体のフローを阻害するボトルネックの特定 ▸ チーム間の調整コストを最小化する仕組み（意思決定の仕組み、共通理解、ルール……） ▸ 優先しなくていいこと ▸ 各チームの速度の単純な比較 ▸ 個別チームの改善だけに注目すること 22
23. 開発組織の進化・スケーリングと 「開発生産性」 23 だが、そのままスケーリングするのは難しい （=大規模アジャイルは難しい） ストリームアラインドチーム 統合チーム フィーチャーチーム 変更のフロー ▸ 全チームが集まってコミュニケーションを行い、足並みを揃えるモデルはスケールしにくい ▸ 例えばプロダクトマネージャーやプロダクトオーナーの負荷が著しく高くなり、単一障害点になる ▸ 開発者自身の扱わなければいけない範囲が増える（認知負荷が高い） ▸ リリースのときに各チームの成果を統合するオーバーヘッドが大きくなる ▸ 何らかの形で、それぞれのチームの依存関係を小さくし、自律的に動けるようにしなければいけない
24. 開発組織の進化・スケーリングと 「開発生産性」 そこでチームを分離する 24
25. 開発組織の進化・スケーリングと 「開発生産性」 25 プロダクトの成長によってアーキテクチャーの見直しが必要にな る。成長の過程で投資が必要だし成長しているので投資できる ドメインやサービスで分離 ストリームアラインドチーム（コア） ストリームアラインドチーム（社内業務系） ストリームアラインドチーム（決済） ストリームアラインドチーム（認証） 変更のフロー ▸ チームを分離し、アーキテクチャを見直すことで、それぞれのチームが独立してリリース可能になる ▸ 例：モノリス→モジュラーモノリス、モノリスからのサービス分離 ▸ それぞれの領域で法的要件やサービスレベル、性能要件が異なっても、対応が容易になる
26. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ プロダクトそのものが成功に向かって進んでいること（忘れがちになっていく） ▸ 境界の明確化と疎結合の維持（境界があいまいなままで分割すると、逆に混乱する） ▸ 各チームが扱うドメインにおいて「顧客価値」に集中できているか ▸ 各チームの自律性と裁量の確保 ▸ 優先しなくていいこと ▸ チーム間で同一プロセスを適用しようとすること ▸ チームを横並びで比較しようとすること 26
27. 開発組織の進化・スケーリングと 「開発生産性」 （参考） ストリームアラインドチームの境界を決める節理面 ▸ ビジネスドメインのコンテキスト境界（いちばん中心的） ▸ 法令・規制遵守 ▸ 変更のリズム ▸ チームの地理的配置 ▸ リスク ▸ パフォーマンス ▸ 技術（他のチームへの依存関係が限定的な場合） ▸ ユーザーペルソナ ▸ ほかにもあるかもしれない 27
28. 開発組織の進化・スケーリングと 「開発生産性」 28 これによって各チームはリリースをある程度自由に行えるように なる。開発プロセスも自分たちで決められる プラットフォームの抽出 ストリームアラインドチーム iOSチーム ストリームアラインドチーム Androidチーム ストリームアラインドチーム Webチーム プラットフォームチーム バックエンドAPIチーム 変更のフロー ▸ 初期の段階ではバックエンドAPIチームはコラボレーションモードでAPIの仕様や範囲を決める ▸ 基本的には、バックエンドAPIチームはAPIをサービスとして提供し、X-as-a-Serviceモードのインタラクション ▸ プロダクトのドメインがある程度安定していないと、バックエンドAPIが安定せずに問題が波及する
29. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ プラットフォームというプロダクトそのものが成功に向かって進んでいること ▸ プラットフォームが価値提供側チームの負担をどれだけ軽減しているか ▸ プラットフォームがサービス志向であること ▸ UXや使いやすさ、ドキュメント、サポート体制 ▸ 優先しなくていいこと ▸ プラットフォームチーム自身のアウトプット量 ▸ サービス利用者に「従わせる」こと 29
30. 開発組織の進化・スケーリングと 「開発生産性」 30 専門性が必要なコンポーネントで分離 コンプリケイテッドサブシステムチームは研究開発的な要素も あるため、裁量を持った仕事の仕方が必要になることもある ストリームアラインドチーム 機械学習チーム AIチーム コンプリケイテッド サブシステムチーム コンプリケイテッド サブシステムチーム ストリームアラインドチーム 変更のフロー ▸ 機械学習やAIなど専門性が高いとき、内容が複雑でブラックボックスとして扱ったほうがよいときに、コ ンプリケイテッドサブシステムチームに隠蔽する ▸ ストリームアラインドチームはこのチームの成果物を利用する
31. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ 高度な専門領域における技術的品質 ▸ 必要なタイミングまでにデリバリーできること ▸ 他チームからの依頼の受け方と進捗の可視化 ▸ 優先しなくていいこと ▸ 他チームと同じプロセスやルールの適用 ▸ 他チームと同じ指標での生産性比較 31
32. 開発組織の進化・スケーリングと 「開発生産性」 32 社内コンサルティングチーム的な位置づけになる 支援系のチームを分離 ストリームアラインドチーム SREチーム 開発技術チーム イネイブリングチーム イネイブリングチーム ストリームアラインドチーム 変更のフロー ▸ 各チームに必要な知識をトランスファーするイネイブリングチームを用意し、各チームを支援すること で、品質やパフォーマンス（SREであれば信頼性の維持・向上に関すること）の向上につなげる ▸ スキルが身につけば支援は終わるので、チームとの関わりはアドホックなことが多い
33. 開発組織の進化・スケーリングと 「開発生産性」 優先すべきこと、優先しなくていいこと ▸ 優先すべき関心事 ▸ スキルトランスファー ▸ サポート対象チームの改善や学習速度 ▸ 支援終了後のチームの自走力 ▸ 優先しなくていいこと ▸ イネイブリングチームの「出した成果」を指標にすること ▸ イネイブリングチームだけでなく、スクラムマスターやEMのような支援系の職種は、 「定量化」の強い力がかかると余計な仕事ばかりするようになる 33
34. 開発組織の進化・スケーリングと 「開発生産性」 34 プロダクトの進化によって、チーム構造は変化し続けることを前 提にする。これは避けられないものだと考えることが重要 チーム構造は変化し続ける ストリームアラインドチーム コンプリケイテッドサブシステムチーム ストリームアラインドチーム コンプリケイテッドサブシステムチーム ストリームアラインドチーム イネイブリングチーム プラットフォームチーム プラットフォームチーム
35. 開発組織の進化・スケーリングと 「開発生産性」 35 1つの組織のなかにはさまざまなステージのプロダクトやチームがある ▸ 仮説検証中のチームもあれば、スケーリング中のチームもある ▸ ストリームアラインドチームもあれば、コンプリケイテッドサブシステムチームやプラットフォームチー ム、イネイブリングチームもある ▸ プロダクトの状況やチーム構成は変化し続ける
36. 開発組織の進化・スケーリングと 「開発生産性」 36 「開発生産性」の意味や指標はチームごとに異なり、変化し続ける ▸ チームごとに何がいちばん重要かは異なり、開発生産性の意味も異なる ▸ 仮説検証中のチームは「価値ある課題の発見」が重要 ▸ スケーリング中のチームは「安定したデリバリー」が重要 ▸ プラットフォームチームなら「他チームの負担軽減」や「プラットフォームの安定性」が重要 ▸ 指標もそれぞれ異なる ▸ プロダクト指標（利用率、継続率など）、フロー指標（リードタイム、デプロイ頻度など）、チームヘルス （エンゲージメント、学習速度など） ▸ 共通の指標で一律に比較・評価できないし、すべきでもない
37. 開発組織の進化・スケーリングと 「開発生産性」 37 チームタイプ / フェーズ 見るとよいメトリクスの例 （あくまで例であり網羅性はまったくない。自分たちで考えること） 仮説検証チーム（初期） プロダクトの方向性に関する定性的フィードバック、顧客インタビュー／観察数、仮説検証サイクルの回転 数、得られた学び（インサイト）、 1チーム体制での開発 仮説通りに使われているか、ユーザーフィードバック取得までの時間、リリース頻度やリードタイム 複数チーム体制 （スケーリング初期） プロダクトの利用率・継続率、バリューストリーム全体のフロー効率、チーム間依存度、リリース頻度やリー ドタイム 自律チーム （ドメイン分離後） ドメインごとのプロダクト成果指標（例：NPS、CVR）、リリース自律度、意思決定のスピード、チーム間依存 度 プラットフォームチーム 利用チームのCSAT、再利用率、サービス提供の安定性（稼働率など） 専門性コンポーネントチーム コンポーネントの能力、品質、リードタイム イネイブリングチーム 技術支援のインパクト、支援対象チームの改善・自走速度、知識伝播の範囲と速度 全体共通 チームのエンゲージメント
38. 開発組織の進化・スケーリングと 「開発生産性」 チームごとに意味のある「開発生産性」を定義するには？ ▸ チームのミッションやビジョン、ゴールを明確にする ▸ たとえばOKRなどを活用 ▸ 指標の有効性を頻繁にチームで話し合う ▸ 役に立たない指標は取得をやめる ▸ チーム外からの数値化要求への対応は、意図を明らかにするところから ▸ ときには数字信者に対して「ノー」を言わなければいけないことも ▸ そうしないとチームの無駄が増え続ける ▸ 重要なのは「各チームが、自分たちにとって意味ある生産性を定義し、改善していける」こと 38
39. 開発組織の進化・スケーリングと 「開発生産性」 39 まとめ ▸ 「開発生産性」は状況依存で、絶対的な定義や指標は存在しない ▸ プロダクトのステージやチーム構成の変化に応じて、適切な関心事と測定軸も変わる ▸ 「すべてのチームに共通するKPIで一元管理」ではなく、「各チームにとって意味のある成果を定義し、 それを最大化する」ことが重要 ▸ 経営層やマネジメントは「一律の物差しではなく、文脈に即した複数の物差し」で考える重要性を理 解しなければいけない ▸ チームは、「今の自分たちにとって意味のある生産性とは何か」を問い続け、定義と改善を自分たちの手 でコントロールしなければいけない

Comment

No comments...