アーキテクチャモダナイゼーションを実現する組織

アーキテクチャモダナイゼーション - Forkwell Library#121
https://forkwell.connpass.com/event/385048/ にて、話させていただいた資料です。

Transcript

1. アーキテクチャモダナイゼーションを実現する 組織 アーキテクチャモダナイゼーション - Forkwell Library#121 株式会社スリーシェイク Sreake事業部 佐藤慧太 Copyright © 3-shake, Inc. All Rights Reserved. 1
2. 自己紹介 佐藤 慧太@SatohJohn • 2023/1 株式会社スリーシェイク入社 • Google Cloud Partner Top Engineer ’24、’25、’26 選出 • お客様の労苦 <Toil>を減らす • 娘のお世話を精一杯やっています
3. Copyright © 3-shake, Inc. All Rights Reserved. 会社名 株式会社スリーシェイク（3-shake, Inc.） 設立 2015 年 1 月 代表者 代表取締役社長　吉田 拓真 所在地 東京都中央区銀座8-21-1 住友不動産汐留浜離宮ビル7F 社員数 176名（2026年2月時点） 提供開始 2018/8 シリーズB 総額 8.48億 円 総額 5億円 調達・資本業務提携 総額 10億円 提供開始 提供開始 提供開始 2018/10 2020/12 2021/12 シリーズA 総額5億円 2021/1 2022/5 2024/11 沿革 Googleクラウド・AWSの両方のエンジニアリングに強みを持つ Kubernetes Certified Service Provider(KCSP)を取得 資格関連 会社概要
4. SREの思想・技術をベースに、4つの領域でプロフェッショナルサービスを提供しています Copyright © 3-shake, Inc. All Rights Reserved. SRE / DevOps ・プラットフォーム構築 / 運用高度化 　 Google Cloud / AWS / Kubernetes / IaC ・信頼性 / 生産性 / DevEx向上 　 SRE / o11y / CI/CD / Platform Engineering ・セキュリティ強化 　 アセスメント / SIEM / WAF / CSIRT Application Modernization AI / ML DBRE ・アプリケーションモダナイゼーション 　 API / マイクロサービス / リファクタリング ・開発プロセス改善・高度化 　 AI駆動開発 / 開発環境 / CI/CD ・組織組成・強化 　 アジャイル / スクラム / チームトポロジー ・生成AI導入 / 活用 　 ワークショップ / RAG ・AIエージェント開発 　 MCP / A2A / 既存システム連携 ・モデル開発環境構築 　 MLOps / データフライホイール ・データベース構築 / 移行 / 性能改善 　 PostgreSQL / MySQL / Spanner / TiDB ・データ基盤構築 　 Looker / Snowflake / BigQuery / Redshift ※記載されている会社名、製品名、サービス名等は、各社の登録商標または商標です Sreakeの事業
5. モダナイゼーション、こんな壁にぶつかっていませんか？ 5 これらは技術の問題でしょうか？ マイクロサービスに 移行したのに デプロイは遅くなった 技術的負債の返済を 始めたが 半年で元の優先度に 戻った 新アーキテクチャを 設計したが チーム間の調整コスト が爆発した
6. モダナイゼーション、こんな壁にぶつかっていませんか？ 6 これらは技術の問題でしょうか？ ── 実は組織の問題です マイクロサービスに 移行したのに デプロイは遅くなった 技術的負債の返済を 始めたが 半年で元の優先度に 戻った 新アーキテクチャを 設計したが チーム間の調整コスト が爆発した
7. 目的 モダナイゼーションを技術ではなく 組織の視点で説明し、 明日からの行動に繋げる 7
8. 目次 1. モダナイゼーションと「組織」の問題（第1・2章） 2. モダナイゼーションに必要な組織の姿 ── チームトポロジー（第11・13章） 3. モダナイゼーションを推進する組織 ── AMET（第15章） 4. モダナイゼーションを根付かせる組織 ── 学習とスキルアップ（第17章） 5. AI Agent 時代の組織を考える 6. まとめ：明日からできること 8
9. セッションターゲット • モダナイゼーションに迫られている、 ビジネスリーダーと会話をするエンジニア • モダナイゼーションに興味のある、 知見をつけたいエンジニア • エンジニアとの折衝を行うビジネス職 9
10. Architecture Modernization（Nick Tune 著） • DDD、チームトポロジー、 ウォードリーマッピングなどの定評ある手法 • 技術・組織・戦略の3つの視点から システム刷新を解説 • 詳細な技術書というより概念や考え方などを 通して広く学べる • 株式会社スリーシェイク 5名にて翻訳 10 https://www.shoeisha.co.jp/book/detail/9784798195063
11. Architecture Modernization（Nick Tune 著） 11 https://www.shoeisha.co.jp/book/detail/9784798195063 • 組織について 以下の章から一部ピックアップして紹介 ◦ 第1章 モダナイゼーションとは / 第2章 旅に向けた準備 ◦ 第11章 チームトポロジー / 第13章 内部開発者プラットフォーム ◦ 第15章 AMET / 第17章 学習とスキルアップ
12. なぜ「組織」の問題なのか （第1章,第2章） 01 Copyright © 3-shake, Inc. All Rights Reserved. 12
13. なぜ、モダナイゼーションが必要なのか 13 変化は必ず起きて、競争優位性を保てなくなるから
14. モダナイゼーションとは何か • モダナイゼーション ＝ 技術の刷新だけではない • 技術、組織、そして文化の変革 • 目指すのは「持続可能な高速フロー」 a. アイデアから本番環境への迅速かつ安全なデリバリー b. 複数年にわたって維持できる能力 14
15. モダナイゼーションとは何か 15
16. ソフトウェアは組織の鏡である システムを設計する組織は、その組織のコミュニケーション構造を コピーした構造の設計を生み出す ── Melvyn Conway (1968) 16 コンウェイの法則の力を無視してアーキテクチャを考え出そうとすると、 ミスマッチが生じ、多くの摩擦と問題が生じる ── Martin Fowler ソフトウェアの高速なフローを実現するには組織構造が密接に関係する https://www.melconway.com/Home/Conways_Law.html https://martinfowler.com/bliki/ConwaysLaw.html
17. コンウェイの法則が裏目に出たケース 17 • マーケティング IT 部門（ユーザー向け）と IT 部門（プラット フォーム）が断絶 • プラットフォーム API の信頼性が低くてもマーケティング IT 側が 責任を押し付けられた • 技術的回避策（プラットフォームのデータ同期機能の構築）を 選んだ結果、同期維持に認知負荷の大部分が消費された ある旅行会社 事例:
18. コンウェイの法則が裏目に出たケース 18 ソフトウェアアーキテクチャが組織の コミュニケーション機能不全を反映してしまった 教訓:
19. 組織は準備できているか？── 5つの問い 19 1. ビジネスリーダーは新機能開発の速度を落とす覚悟があるか？ 2. レガシーシステムの変更が複雑で時間がかかることを 理解しているか？ 3. 予期せぬ事態が発生し大幅な遅延やコスト増加が生じた場合、 どう反応するか？ 4. 予算の仕組み、作業の優先順位付けを変え、 チームに権限委譲する準備があるか？ 5. 学習とスキルアップに十分な時間と資金を投資する 意思があるか？
20. 組織は準備できているか？── 5つの問い 20 とはいえ 5つの問いをするにしても、経営層も指標がないと覚悟も何もない そして、現場を常に見ているわけではない 「技術的負債があるから〜〜」では伝わらない 事業はどうするんだ、と言われて終わってしまう
21. 経営層との合意形成 — 経営層の言葉に翻訳する 21 技術的負債 機会損失コスト リファクタリング 市場投入速度の改善 アーキテクチャ刷新 事業継続性のリスク低減 新機能の開発に本来の3倍の時間がかかっている 競合は2週間で出せるものが自社は3カ月 現行システムを理解する人が2名のみ
22. 経営層との合意形成 — 経営層の言葉に翻訳する 22 技術的負債 機会損失コスト リファクタリング 市場投入速度の改善 アーキテクチャ刷新 事業継続性のリスク低減 新機能の開発に本来の3倍の時間がかかっている 競合は2週間で出せるものが自社は3カ月 現行システムを理解する人が2名のみ 「技術的負債」は技術者の概念 ビジネスリーダーにはビジネスインパクトで語る
23. 合意形成の実践アプローチ 23 ステップ1: 現状を可視化する • デリバリーの速度を定量的に示す（DORAメトリクス） • 障害対応にかかるコスト・時間を集計する • 「技術的負債のせいで失っている機会」を具体的に列挙する
24. 合意形成の実践アプローチ 24 ステップ2: 小さく始めて信頼を得る • いきなり全面刷新を提案しない。 3〜6カ月で成果が見えるパイロットを提案する • 成果をビジネス指標で報告する （デプロイ頻度、障害復旧時間、新機能リリース速度）
25. 合意形成の実践アプローチ 25 ステップ3: 継続的にコミットメントを維持する • 定期的な進捗報告をビジネス言語で行う • 「例外」「特別なケース」による割り込みを可視化影響を数字で示す — 「通常業務を一時保留にする」という話を含む
26. モダナイゼーションに必要な組織の姿 （第11,13章） 02 Copyright © 3-shake, Inc. All Rights Reserved. 26
27. チームトポロジー ── ソシオテクニカルなアプローチ 27 • Matthew Skelton & Manuel Pais（2019年） • 組織とソフトウェアの設計を同時に最適化する 体系的なアプローチ • 目的: チームの自律性と高速なフローの実現 • 4つのチームタイプと 3つのインタラクションモードで構成 ソシオテクニカル: 社会システム（人間・組織）と技術システムを別々のものではなく 相互に依存し合う一つのシステムとして捉える概念 https://amzn.asia/d/08eqWa2n
28. 5つの基本原則 28 1. 持続可能な高速フロー ── 速度と品質はトレードオフではない 2. 小規模で長期的なチーム ── 5〜9人の安定したグループ 3. チームファーストの考え方 ── 人は「リソース」ではない 4. You build it, you run it ── 開発から運用まで一貫した責任 5. 認知負荷の最小化 ── チームが扱える範囲に責任を制限
29. 原則の実践（1）── フローとチーム 29 • 『Accelerate』の研究 （現在はGoogle CloudのDORAプログラムとして継続） • 高パフォーマンスチームは1日に複数回デプロイし ダウンタイムも少なく回復も迅速 • DORAの4つのキーメトリクスで自組織の現在地を測定可能 1. 持続可能な高速フロー https://dora.dev/research/2024/ https://dora.dev/insights/dora-2025-year-in-review/
30. 原則の実践（1）── フローとチーム 30 • 5〜9人で信頼を維持。超えるとサブチームが形成され始める • すべての作業は個人ではなくチームに向けられる • コンテキストスイッチは生産性に大きな負担 a. 目標設定と評価もチーム単位で b. チームはなるべく解散をしない 2. 小規模で長期的なチーム 3. チームファースト
31. 原則の実践（2）── 責任と認知負荷 31 • 運用性を考慮した機能開発が自然に行われる • 他チームとのデプロイ調整が不要になり、フローが大幅に高速化 • 7digitalの実例 各チームが毎朝ダッシュボードで確認 → 運用しないチームでは見たことがない良い品質が達成できている 4. You build it, you run it
32. 原則の実践（2）── 責任と認知負荷 32 5. 認知負荷の最小化 • 認知負荷には3種類ある: 課題内在性（軽減困難）/ 課題外在性（削減すべき）/ 学習関連（増や したい） • 認知負荷が高い兆候: 過度のコンテキストスイッチ、デリバリーペースの低下 • 対処法 サブドメインが大きすぎる　→ 複数の小さなサブドメインに分割
33. 4つのチームタイプ 33 チームタイプ 役割 ストリームアラインドチーム バリューストリームに端から端まで責任を持つ。組織 の大多数がこのタイプ プラットフォームチーム ストリームアラインドチームの認知負荷を 軽減する共有機能を提供 コンプリケイテッドサブシステム チーム 高度な専門知識を要する複雑なサブシステムを 担当 イネーブリングチーム 新しい技術やプラクティスの習得を支援。 終了条件あり バリューストリーム: 顧客に製品やサービスを届けるために必要な、アイデア立案から納品、リリースまでの一連プロセス
34. 4つのチームタイプ 34
35. プラットフォームチームを支える技術 35 「内部開発者プラットフォーム」のポイント • プラットフォームチームの役割は、 ストリームアラインドチームの認知負荷を軽減 すること • セルフサービスで利用でき、開発者体験（DX）が優れていることが重要 ◦ 0から Google Cloud や AWS, Azure などの既存 Platform を 組織構造に合わせてカスタマイズして利用するなど • 「薄いプラットフォーム」から始め、チームの実際のニーズに基づいて 段階的に成長させる
36. プラットフォームチームを支える技術 36
37. プラットフォームチームを支える技術 37 関心事 Google Cloud サービス コンテナ実行基盤 Google Kubernetes Engine / Cloud Run CI/CD Cloud Build / Cloud Deploy o11y Cloud Monitoring / Cloud Logging / Cloud Trace AppHub セキュリティ IAM / Workload Identity / Binary Authorization Google Security Operations 組織ポリシー AI/ML Vertex AI
38. 各チームの3つのインタラクションモード ポイント コラボレーションは有用だが認知負荷コストが高い。 メリットが正当化できなければXaaSに切り替えるべき — チームの疎結合 38 モード 特徴 認知負荷 コラボレーション 2チームが密接に協力して共通目標を 達成 高い X-as-a-Service 明確に定義されたサービスを提供 ・interfaceに従い利用 低い ファシリテーティング 一方が他方のスキルアップや目標達 成を支援 中程度
39. 3つのインタラクションモード 39
40. 一度設計して終わりではない ── 継続的な見極め 40 進化が必要なサイン • 過度のコラボレーション（ドメイン境界が最適でない） • 過度のコンテキストスイッチ（認知負荷が高すぎる） • デリバリーのペースが遅くなっている • 過度なデリバリー調整（境界と変化が整合していない） ポイント 数年ごとの大規模な組織再編ではなく、絶えず見極めて進化できる組 織を構築すべきである
41. モダナイゼーションを推進する組織 （第15章） 03 Copyright © 3-shake, Inc. All Rights Reserved. 41 皆さんの組織で、モダナイゼーションが「始まったが止まった」経験はありますか？
42. AMET ── アーキテクチャモダナイゼーションイネーブリングチーム 42 定義 • モダナイゼーションの慣性の力に立ち向かう一時的なチーム • ワークショップ開催、コーチング 、優先度の維持を通じて モダナイゼーションを推進 • 最終的にAMET自体が不要になる状態を目指す（一時的な足場） • 全モダナイゼーション作業を担う「モダナイゼーションチーム」 • すべてのアーキテクチャを設計する「中央集権的アーキテクトチーム」 AMETではないもの
43. AMETが解決する6つの課題 43 課題 AMETの目的 着手できない・分析麻痺 モダナイゼーションを始動させる 他業務との競合で進捗が遅れる 高い勢いを維持する 設計の知識・経験不足 よりよい設計を支援する 従来手法への後戻り 持続可能な変化を促進する 関係者がモダナイゼーションの価値を理解 できない ビジョンを周知し続ける ある分野の学びが他で活かされない 学びを共有・展開する
44. AMET — 3〜6カ月で始動し、役割を終えたら外す 44
45. AMET — 3〜6カ月で始動し、役割を終えたら外す 45 意思決定と 方向性を主導 ファシリテートから 見学に後退 1対1コーチングで リーダーの能力を確認 リーダー自身が主導、 AMET解散 AMETの関与度は時間とともに低下し、最終的に組織自身が モダナイゼーションを主導する
46. 意思決定を分散する ── アーキテクチャアドバイスプロセス 46 原則 誰でもアーキテクチャに関する決定を下せる。 ただし、影響を受ける人々と専門家に事前に相談することが条件 ポイント • ADR（Architecture Decision Records）で議論と決定を記録する • 原則と社内版テクノロジーレーダーを意思決定の指針にする • 週1回1時間のアーキテクチャ相談フォーラムを開催する
47. アーキテクチャアドバイスプロセスのフロー 47
48. モダナイゼーションを根付かせる組織 （第17章） 04 Copyright © 3-shake, Inc. All Rights Reserved. 48
49. モダナイゼーションの成否は学習にかかっている 49 なぜ学習が必要か • モダナイゼーションが野心的であるほど、学習への投資がより必要 • 継続的に「進化」を続ける必要がある • 多くの新スキルの習得には数カ月を要する • 計画・予算の段階で学習コストを考慮しないと将来の問題になる
50. モダナイゼーションの成否は学習にかかっている 50 • 読書会のような小さな種から始める • 同僚から尊敬されているインフルエンサーに権限を与え、 「トレーナー養成」方式でスキルを伝播 • 小さな成功体験を積み重ねる どう始めるか ── 種をまき、育てる やってみせ　言って聞かせて　させてみて　ほめてやらねば　人は動かじ — 山本五十六
51. モダナイゼーションの成否は学習にかかっている 51 手法 概要 コミュニティ・オブ・ プラクティス（CoP） 共通の関心を持つ人々の定期的な集まり バイトサイズ アーキテクチャセッション 月2回、45〜60分。 チーム間で知識を広め集団的理解を深める メンタリングプログラム 明示的なプログラムとして確立。人事評価と同等に扱う モブ/ペアプログラミング 実践を通じた最も効果的な学習 社内テックカンファレンス 年1〜2回。知識の伝播と一体感の創出
52. 2つの事例に学ぶ ── 共通点は「学習文化」 52 PayFit: (フランス / HRテックユニコーン / 規模 約1000人 • エンジニアリングディレクターがDDD読書会を開始（隔週） ◦ スタッフエンジニア + 数名のマネージャ → 他のメンバーを巻き込み • 2年かけて成長し、経営陣を通し、全社的な 「単一の給与計算ドメインに対して」ドメインディスカバリーと モダナイゼーションの実施 • 「給与期間」を「6人が7つの異なる意味で使う」状態を解消
53. 2つの事例に学ぶ ── 共通点は「学習文化」 53 Infor( CloudSuite ): (アメリカ / Eコマース / 規模 約20人 • アーキテクチャ変更の前に、まず技術的卓越性 の構築に注力 ◦ Timber Kerkvliet 氏の採用 ◦ Samman Method で学習文化を育成 → ボトムアップでコアドメインを特定 • 逆コンウェイ操作(理想のアーキテクチャに基づきチームを組成)を 段階的に適用
54. 学習メソッド ── Samman Method 54 Emily Bacheによる「勉強会をして終わり」ではなく、 安全な環境でのインプットと、実際の業務でのアウトプットを交互に繰り返す仕組み ラーニングアワー (Learning Hours) アンサンブルワーキング (Ensemble Working) https://sammancoaching.org/ 日々の業務（プロダクションコード）から意図的に切り離された、短時間（通常1時間程度）の集中的な学習 セッションです。「コードカタ（Code Kata）」と呼ばれる短いプログラミング課題などを使い、安全な環境 で新しい技術や概念を練習します。 ラーニングアワーで学んだ技術を、実際のプロダクションコード（業務のコード）に適用していく実践プロセ スです。チーム全員（3〜6人程度）が一つの画面を共有し、協力してコードを書く「モブプログラミング（ア ンサンブルプログラミング）」の形式をとります。
55. 学習を組織のDNAに組み込む 55 実践ポイント • 学習活動は通常の勤務時間内に組み込み、他の業務と同等に扱う • メンバーのメンタリングを追加業務ではなく、 人事評価で同等の重要度として扱う • 経営陣や上位層が学習を奨励していると感じさせる環境をつくる 7digital: (イギリス / 音楽配信) 1. 月に2日間の学習時間、毎週数時間の議論タイム（CTOが強く奨励） 2. 結果: 全チームが毎日プロダクションにデプロイ、入社初日にデプロイ、 バグは昼食前に解決
56. 学習を組織のDNAに組み込む 56 • CTOがカンファレンス参加費を半額しか出さない • チーフアーキテクトがカンファレンスを公然とバカにする • メンタリングを追加業務として課しつつ、同じ作業量を期待する • 変革を技術的なものだけと考え、合意形成なしに進める • 逆コンウェイ操作を現在のシステム制約を無視して適用しようとする アンチパターン → 優秀な人材の流出
57. AI Agent 時代の組織を考える 05 Copyright © 3-shake, Inc. All Rights Reserved. 57 Coding AI Agent の台頭は、モダナイゼーションの組織論をどう変えるか？
58. Coding AI Agent の台頭 58 • 2025年以降、自律的にコードを書く AI Agent が急速に発展 • Claude Code、GitHub Copilot、Gemini CLI Agent mode、Devin、Cursor Agent など • コード生成だけでなく、調査・設計・テスト・リファクタリングまで 一貫して実行 • 「エンジニア1人あたりの生産性」の前提が変わりつつある
59. Coding AI Agent の台頭 59 • 2025年以降、自律的にコードを書く AI Agent が急速に発展 • Claude Code、GitHub Copilot、Gemini CLI Agent mode、Devin、Cursor Agent など • コード生成だけでなく、調査・設計・テスト・リファクタリングまで 一貫して実行 • 「エンジニア1人あたりの生産性」の前提が変わりつつある 問い AI Agent がコードを書いてくれるなら、 組織の話はもう不要か？
60. AI Agent でも変わらないもの 60 • ドメイン知識のヒアリング 「給与期間」を6人が7つの意味で使う問題は AI では解決できない • 組織間のコミュニケーション 部門の断絶、責任の押し付け合いは人間の課題 • ビジネスコンテキストの理解と意思決定 何をモダナイズすべきか、優先順位は何か モダナイゼーションの本質的な難しさはコードではなくコンテキストにある
61. AI Agent で加速できること 61 一方で、AI Agent はモダナイゼーションの実行フェーズを大幅に加速する ポイント AI Agent は「手を動かす速度」を上げるが、 「正しい方向」を決めるのは組織、効率の良い「作業環境」を作るのも組織 活用領域 具体例 現状の可視化 レガシーコードの構造分析、依存関係の整理、ドキュメント生成 PoC の高速作成 新アーキテクチャの検証用プロトタイプを数時間で構築 移行の自動化 コードの機械的なリファクタリング 、テストの自動生成 学習の加速 コードベースの説明、ペアプログラミングの相手としての活用
62. AI Agent を入れただけでは変わらない 62 https://hirokidaichi.github.io/presentation/devsummit.html#26 https://www.faros.ai/blog/ai-software-engineering https://medium.com/nick-tune-tech-strategy-blog/the-structure-and-process-fallacy-40640e84423
63. AI Agent を入れただけでは変わらない 63 https://hirokidaichi.github.io/presentation/devsummit.html#26 https://www.faros.ai/blog/ai-software-engineering https://medium.com/nick-tune-tech-strategy-blog/the-structure-and-process-fallacy-40640e84423 じゃあ PR レビュー時間が少なくなれば 良いのか？ 品質、信頼を担保する機構はどう作る？ — 構造とプロセスの誤謬
64. AI Agent 導入を経営層にどう伝えるか 64 AI Agent は「エンジニアの遊び道具」ではなく、ビジネスの武器である 注意 Agent の導入にもコストがかかる（ライセンス、ガバナンス整備、学習時間） → パート1で述べた合意形成のアプローチがここでも必要 AI Agent を導入したい モダナイゼーションの 投資対効果を数倍に 高められる 開発者の生産性が上がる 新機能の市場投入を 現在の半分の期間で 実現できる
65. AI Agent を武器にするための組織の条件 65 AI Agent の効果は組織の成熟度に比例する 組織の状態 AI Agent の効果 ドメイン知識が属人的 Agent に正しい指示が出せず 、的外れな 成果物が量産される チーム間にコミュニケーション不全 Agent が生成したコードが他チームの 前提と矛盾する 学習文化がない Agent の使い方がチーム間で共有されず、 効果にばらつき ドメイン知識が共有されている Agent に的確な指示を出せる、高品質な 成果物が得られる チームの自律性が高い Agent を活用した素早い意思決定と 実装が可能になる
66. AI Agent を武器にするための組織の条件 66 AI Agent の効果は組織の成熟度に比例する 組織の状態 AI Agent の効果 ドメイン知識が属人的 Agent に正しい指示が出せず 、的外れな 成果物が量産される チーム間にコミュニケーション不全 Agent が生成したコードが他チームの 前提と矛盾する 学習文化がない Agent の使い方がチーム間で共有されず、 効果にばらつき ドメイン知識が共有されている Agent に的確な指示を出せる、高品質な 成果物が得られる チームの自律性が高い Agent を活用した素早い意思決定と 実装が可能になる 本書の組織論を実践することが、 AI Agent 時代の競争優位に繋がる
67. まとめ Copyright © 3-shake, Inc. All Rights Reserved. 67
68. 明日からできること 68
69. 明日からできること 69 個人+複数人として • 読書会を始める（1冊、2人から） • バイトサイズアーキテクチャセッションを試す(月2回、45分) • 自チームの認知負荷を振り返る
70. 明日からできること 70 チームとして • DORAメトリクスで現在地を測定する • チームの自律性レベルを確認する（ロードマップの決定権はあるか？） • You build it, you run it を始める（小さく、1つのサービスから）
71. 明日からできること 71 組織として • リーダー層に5つの問いを投げかける • AMET的な役割を検討する • 学習を通常業務と同等に扱う制度を設計する
72. 最後に 72 持続可能な変化は組織の内部から生まれなければならない — Joao Rosa (第15章) アーキテクチャモダナイゼーションについてご相談ございましたら 次のお問い合わせ先にご連絡ください お問い合わせ先： 株式会社スリーシェイク URL: 　https://sreake.com/contact/ Email: 　sreake-sales@3-shake.com ※お知り合いのスリーシェイク社員経由でも構いません
73. ありがとうございました Copyright © 3-shake, Inc. All Rights Reserved. 73