第1章 チーム指向の組織設計
1-1 チーム指向の組織設計が目指す組織のビジョン
組織設計に求められる7つの要件
要件/概要
1バリューストリームを単位に構造化されている
組織もソフトウェアシステムも、バリューストリームを単位として構造化され、チームはストリームと共に長く存続します
2チームの独立性が高い
他のチームに頼ることなく担当チームが単独でソフトウェアコンポーネントを変更、テスト、デプロイできます
3安定したチームワークを築いている
継続的なチームビルディングによって、チームは信頼と相互理解に基づく安定的なチームワークを築き、いつでも最高のパフォーマンスを発揮します
4チームが行動を自己管理している
「誰が何を、いつ、どのように行うか」を決定する権限をチームが有し、 それを適切に行使しています
5システムやプロセスを継続的に改善している
組織全体がソフトウェアシステムの品質とプロセスの品質を高めること 「に強い関心を持ち、それらの継続的な改善に努めています
6素早く積極的に変化を受け入れる
組織とチームが高いアジリティを持っており、予測困難な変化に対して拒絶することなく、素早く積極的に適応します
7徹底した経験主義で顧客価値を探索している
組織全体が、アイデアや計画が顧客価値に対する仮説でしかないことを理解しており、探索型プロセスを用いてそれを検証する経験主義を貫きます
1-2 チームが組織を駆動する
1-2-1 個人間よりチーム間のパフォーマンス差の方が大きい。
1-2-2 多様性がチームを成功に導く
1-3 チームレベルの設計のための学びを得る
1-3-1 「アジャイルソフトウェア開発」の中核価値・
中核価値1 プロセスやツールよりも個人と対話を価値とする。
中核価値2 包括的なドキュメントよりも動くソフトウェアを価値とする。
中核価値3 契約交渉よりも顧客との協調を価値とする
中核価値4 計画に従うことよりも変化への対応を価値とする
1-3-2 「リーンソフトウェア開発」の原則
原則5 速く提供する
原則6 人を尊重する。
1-3-3「リーン・スタートアップ」の原則
原則4 構築-計測学習 .
1-3-4「DevOps」の原則
第1の道 フローの原則････
第2の道 フィードバックの原則
第3の道 継続的な学習と実験の原則
1-4 組織レベルの設計のための学びを得る
1-4-1「コンウェイの法則」が示す組織とシステムの関係
1-4-2 「Microservices」 におけるチームの独立性
特徴: ビジネス機能に基づく組織化
マイクロサービスアーキテクチャスタイルでは、アプリケーションが対象とするビジネス機能に着目して組織を分割します。そして、その単位でエンドツーエンドの開発を進められるチームを編成します。
従来のエンジニアリング組織に多く見られる組織構造は、技術的専門性ごとにチームが編成される形でしょう。ユーザインタフェースを専門に開発するフロントエンド開発チームや、ビジネスロジックを開発するバックエンド開発チームなどに分かれているのです。さらに、データベースを専門に扱うチームが独立して存在するケースもあります。
こういった水平統合型チームでは、ロジックが重複したり、分散したりする傾向がみられます。必要なロジックを自らが担当するコンポーネントにできる限り埋め込むことで、手っ取り早く済ませようという意識が働くからです。これも、コンウェイの法則の言う作用でしょう。 また、このタイプの組織は、チーム間での調整コストの増大とスケジュールの長期化という問題も生じさせやすくなります。新機能を1つ開発するだけでもフロントエンドからバックエンド、データベースに至るまで、すべてのレイヤーでタスクが発生するからです。そうすると、関係するチームで集まり、結合箇所に関する仕様を調整したり、テスト期間やデプロイ日を調整したりすることになります。
これに対し、技術的機能ではなく、ビジネス機能ごとにチームを編成するアプローチが「ビジネス機能に基づく組織化」です。
ビジネス機能とは、技術的機能に対する用語です。ユーザインタフェースやビジネスロジック、データベースといった分け方が、技術的機能の一例です。一方、ビジネス機能は、アプリケーションを使う側からみた機能です。オンラインショッピングシステムを例にすれば、 仕入れと販売、オンラインカタログ制作、マーケティング、注文管理、フルフィルメント、カスタマーサービスといった機能がそこに含まれています。 マイクロサービスアーキテクチャでは、こういったビジネス機能を単位として、アプリケーションを複数のサービスに分割します。ドメイン駆動設計 (domain-driven design, DDD) における「境界付けられたコンテキスト (bounded context)」は、このような切り口を探す手助けになるでしょう [19] [20]。個々のサービスには、ユーザインタフェースからバックエンドのビジネスロジック、データベースまで、ビジネス機能に必要なものすべてが含まれます。
そしてサービスごとに垂直統合型のチームが付くことで、エンドツーエンドでの機能開発を可能とします。チームは、ユーザインタフェースを開発することも、バックエンドでビジネスロジックを開発することも、データベースを扱うこともできます。これで、水平統合型チームで生じたような複数チーム間での調整の頻度も下がります。
特徴: プロジェクトではなくプロダクト
1-4-3 「チームトポロジー」におけるチームタイプとコミュニケーション帯域
チームタイプ:ストリームアラインドチーム
コミュニケーション帯域
1-5 チーム指向の組織設計に求められる要件を定義する
1-5-1 要件1 バリューストリームを単位に構造化されている
1-5-2 要件2 チームの独立性が高い
1-5-3 要件3 安定したチームワークを築いている
1-5-4 要件4 チームが行動を自己管理している
1-5-5 要件5 システムやプロセスを継続的に改善している
1-5-6 要件6 素早く積極的に変化を受け入れる。
1-5-7 要件7 徹底した経験主義で顧客価値を探索している
1-6 戦略や時代の変化に組織を呼応させる
1-7 まとめとこれから
第2章 組織のパフォーマンスを蝕む問題から捉える組織設計
2-1 問題1：非効率なチーム間コミュニケーションが組織の生産性を削り取る
2-1-1 コミュニケーションそのものに要する時間というコスト
2-1-2 コミュニケーションの準備に要するコスト
2-1-3コミュニケーションを待つ時間というコスト
2-1-4 注視すべきはチーム境界を越えたコミュニケーション
2-2 問題2：非効率なフローが無価値な待ち時間を生じさせる
2-2-1フローは付加価値時間と待ち時間の連続
2-2-2 フローの待ち行列による滞留
2-2-3 制約理論におけるボトルネック
2-2-4 注視すべきはプロセス境界とフロー分割
2-3 問題3：粗悪な内部品質がビジネスに悪影響を及ぼす
まとめると、低品質なコードによる影響は次のようになります。いずれにしても、市場投入までの時間に悪影響を与えていることが読み取れます。
・計画への影響
・見積りの正確性や精度を高めるために、見積り作業に多くの時間をかけるようになる
・見積りや計画に大きなバッファを追加するようになり、スケジュールが長くなる
・開発への影響
・機能開発に対する影響範囲の読み解きや変更に時間がかかる
・テストで検出される欠陥が多く、その修正に時間がかかる
・保守・運用への影響
・リリース後の欠陥修正や本番トラブル対応が増え、開発に割ける時間が削り取られる
・ ライブラリやフレームワークのバージョンアップに時間がかかり、開発に割ける時間が削り取られる
2-3-1 悩ましいのは無謀な意思決定による内部品質の悪化
第1象限(左下):無謀で無自覚な負債
第2象限(左上): 無謀で意図的な負債
第3象限(右上): 慎重で意図的な負債
第4象限(右下): 慎重で無自覚な負債
2-3-2 無謀で無自覚な内部品質悪化
2-3-3 無謀で意図的な内部品質悪化
2-3-4 必要なのはシステム思考による観察
2-4 3つの問題は相互に影響し合う
2-5 まとめ
第3章 内部品質を悪化させる組織設計アンチパターン
3-1 共有リソースプール：プロジェクトの度にチームを編成している
3-1-1 組織設計の概要・
3-1-2 症状1 プロジェクトに適したチーム編成になるかは運次第。
3-1-3 症状2 チームワークもメンバーの組み合わせ次第
3-1-4 問題点 低品質な設計・実装が混入
3-1-5 解決策 プロジェクトを安定したチームにアサイン
3-1-6 関連する原則やガイドライン
3-1-7 関連するアンチパターン
3-2 不連続なチーム：プロダクトに専属チームを配備しない
3-2-1 組織設計の概要
3-2-2 症状 プロジェクトで得た知識の喪失や断片化
3-2-3 問題点 不十分な知識による設計が招く内部品質の低下
3-2-4 解決策 プロダクトや領域に対して連続性のあるチームを編成
3-2-5 関連する原則やガイドライン
3-2-6 関連するアンチパターン
3-3 行き過ぎた固定化：チーム編成を長期に渡り変更していない
3-3-1 組織設計の概要
3-3-2 症状 属人化の進行
3-3-3 問題点 コードの属人化
3-3-4 解決策 流動性の注入
3-3-5 関連する原則やガイドライン
3-4 無制限のコード共有：どの領域のコードでも制限なく誰もが変更できる
3-4-1 組織設計の概要..
3-4-2 症状1 コンポーネントに変更を加える開発者が多数
3-4-3 症状2 コンポーネントに対する理解のばらつきが大きい。
3-4-4 問題点設計の複雑化と割れ窓化による悪循環
3-4-5 解決策 コードのオーナーシップ制の導入
3-4-6 関連する原則やガイドライン
3-4-7 関連するアンチパターン
3-5 保守・運用の分離：開発チームが保守・運用業務を知らない
3-5-1 組織設計の概要
3-5-2 症状 非効率な保守・運用と安定性・信頼性の低いシステム
3-5-3 問題点 保守・運用面の考慮がない設計と実装
3-5-4 解決策 担当プロダクトの開発・保守・運用を1つのチームに統合
3-5-5 関連する原則やガイドライン
3-5-6 関連するアンチパターン
3-6 品質保証の一極集中：品質をテストフェーズに頼り過ぎている
3-6-1 組織設計の概要
3-6-2 症状1 テストプロセスでの網羅的なテスト
3-6-3 症状2 開発プロセスは機能を実装することが何より優先
3-6-4 問題点 レガシーコードの量産
3-6-5 解決策 品質保証に関連する責務の分散と各プロセスの見直し
3-6-6 関連する原則やガイドライン
3-6-7 関連するアンチパターン
3-7 ドメイン知識の過疎地：顧客と開発メンバーの距離が遠い
3-7-1 組織設計の概要
3-7-2 症状 企画から開発への依頼という受発注関係
3-7-3 問題点 ドメイン知識不足が反映された設計・
3-7-4 解決策 プロセスのオーバーラップによって受発注関係とサイロ化を解消
3-7-5 関連する原則やガイドライン
3-7-6 関連するアンチパターン
3-8 無力な他己管理型チーム：チームに決定権がない
3-8-1 組織設計の概要
3-8-2 症状 現場の意見を軽視する意思決定
3-8-3 問題点 内部品質の問題が徐々に積み上がることで開発生産性と品質が低下
3-8-4 解決策 相互信頼にもとづく対等な関係を築いて自己管理型チームに移行
3-8-5 関連する原則やガイドライン
3-8-6 関連するアンチパターン
第4章 コミュニケーションコストとフロー効率を悪化させる組織設計アンチパターン
4-1 スパゲッティ組織：プロジェクト体制が組織内で複雑に絡まっている
4-1-1 組織設計の概要
4-1-2 症状1 高頻度の見積り依頼対応・
4-1-3 症状2 常態的な開発リソース不足
4-1-4 問題点 プロジェクト間で頻発する調整
4-1-5 解決策 サービスインタフェースとしてのプロダクトバックログの配置
4-1-6 関連する原則やガイドライン
4-1-7 関連するアンチパターン
4-2 水平統合：組織を技術観点でチーム分けしている
4-2-1 組織設計の概要
4-2-2 症状1 プロジェクトは全チームの参加が基本
4-2-3 症状2 本番トラブル発生時も全チームでの対応が基本
4-2-4 問題点 チーム間で頻発する調整
4-2-5 解決策 垂直統合型チームへの移行
4-2-6 関連する原則やガイドライン
4-2-7 関連するアンチパターン
4-3 即興的な開発プロセス：開発プロセスがあいまいで過度に柔軟性を重視している
4-3-1 組織設計の概要
4-3-2 症状1 何をするのか、何ができていなければならないかがあいまい
4-3-3 症状2 プロジェクトへの割り込みや変更に対する柔軟すぎる対応
4-3-4 問題点 プロジェクトの計画と実行が複雑
4-3-5 解決策1 プロセスの標準化
4-3-6 解決策2 プロセスのカプセル化
4-3-7 関連する原則やガイドライン
4-3-8 関連するアンチパターン
4-4 低凝集な業務機能：業務機能の一部がチームに欠けている
4-4-1 組織設計の概要
4-4-2 症状1 専門性による行き過ぎた分業
4-4-3 症状2 過剰なリスク回避思考による承認プロセス
4-4-4 症状3 優秀な人材に頼り切った品質向上
4-4-5 問題点 チーム単独でのプロセス実行が不可能
4-4-6 解決策 業務機能の高凝集化、あるいは結合度の調整
低凝集な業務機能によって引き起こされる問題には、当然ながら、高凝集化をもって解決にあたります。複数のチームに散らばった業務要素を1つのチームに統合することが基本戦術です。分業するいくつかの工程をまとめて1つのチームで担うことや、チーム内で承認やレビューを実施できる権限を委譲することが具体策となるでしょう。
4-4-7 関連する原則やガイドライン
4-4-8 関連するアンチパターン
4-5 ねじれコンウェイ：コミュニケーション構造とシステム構造に乖離がある
4-5-1 組織設計の概要
4-5-2 症状 所有権をまたいだコード変更が頻発
4-5-3 問題点 コード変更で生じるチーム間での調整
4-5-4 解決策 チーム間での3種類のコード所有権の使い分け
4-5-5 関連する原則やガイドライン
4-5-6 関連するアンチパターン
4-6 メンバー共有：兼務メンバーがチームに存在する
4-6-1 組織設計の概要
4-6-2 症状1 マルチタスク
4-6-3 症状2 ミーティングの増加
4-6-4 症状3 知識の偏りと負荷の偏り
4-6-5 問題点1 フロー効率の低下による市場投入までの時間の悪化
4-6-6 問題点2 プロジェクトをまたいだ遅延の連鎖・
4-6-7 問題点3 コミュニケーションコストの増大による実務時間減少
4-6-8 問題点4 高負荷とオーナーシップ欠如による内部品質への悪影響
4-6-9 解決策 兼務からの脱却
4-6-10 関連する原則やガイドライン
4-6-11 関連するアンチパターン
4-7 人気者チーム：コンポーネントを共有化し専任の開発チームをつけている
4-7-1 組織設計の概要
4-7-2 症状1 コンポーネントに対するマルチバリューストリーム
4-7-3 症状2高コストな仕様決定
4-7-4 症状3 膨らんでいく機能領域
4-7-5 症状4 仕事に対するモチベーションの低下
4-7-6 問題点 複数のバリューストリームをまたいだボトルネック化
4-7-7 解決策 専任チームの解散と弱いコードの所有
4-7-8 関連する原則やガイドライン
4-7-9 関連するアンチパターン
4-8 バリューストリームの合流点：1つのチームが複数のバリューストリームに配備されている
4-8-1 組織設計の概要
4-8-2 症状 チームに対するマルチバリューストリーム
4-8-3 問題点 バリューストリーム間での開発リソースの競合
4-8-4 解決策 バリューストリームと開発チーム配備の整理
4-8-5 関連する原則やガイドライン
4-8-6 関連するアンチパターン
第5章 チーム中心の組織作りのためのチーム設計の原則
5-1 安定：チームのメンバー構成と担当責務をほぼ一定に保つ
5-1-1 メンバー構成と責務の安定
5-1-2 機能期の持続
5-1-3 知識の蓄積による継続的な改善
5-1-4 予測可能性の向上
5-1-5 関連する原則やガイドライン
5-1-6 関連するアンチパターン
5-2 アトミック：組織内でチームを「個」として扱う
5-2-1 組織内での「個」としてのチーム
5-2-2 チームの自律
5-2-3 チーム思考でのミッション遂行
5-2-4 チーム指向での組織のスケール
5-2-5 関連する原則やガイドライン
5-2-6 関連するアンチパターン
5-3 専属：メンバーを兼務させない
5-3-1 兼務者のいないチーム
5-3-2 チームに対するオーナーシップの醸成
5-3-3 高いコミットメント
5-3-4 関連する原則やガイドライン
5-3-5 関連するアンチパターン
5-4 少人数：チームメンバー数を制限する
5-4-1 緊密なコミュニケーションの実現・
5-4-2 主体性の発露
5-4-3 バッチサイズの削減
5-4-4 アジリティの獲得
5-4-5 マネジメントコストの削減
5-4-6 関連する原則やガイドライン、アンチパターン
5-5 流動性：少しずつチーム編成を変えていく
5-5-1 安定性と流動性の併存
5-5-2 属人化の緩和
5-5-3 マンネリの解消と人材の育成
5-5-4 ラーニングゾーンへの移行
5-5-5 知識とネットワークの組織的拡大
5-5-6 関連する原則やガイドライン
5-5-7 関連するアンチパターン
5-6 イテレーティブ：フィードバックループをプロセスに組み込む
5-6-1 経験主義に基づく意思決定
5-6-2 プロジェクト/リリース/イテレーションのフィードバックループ
5-6-3 日次的なフィードバックループ
5-6-4 継続的なフィードバックループ
5-6-5 関連する原則やガイドライン
5-6-6 関連するアンチパターン
第6章 チームの機能と配備を考えるためのチーム責務定義ガイドライン
6-1 ストリームアラインド：チームをバリューストリームに対して配備する
6-1-1 ガイドラインの概要
6-1-2 安定したバリューストリームを作る
6-1-3 単一のバリューストリームに配備する
6-1-4 複数バリューストリームへの配備による問題を回避/軽減する
6-1-5 1つのバリューストリームに複数の開発チームを配備することもある
6-1-6 関連する原則やガイドライン
6-1-7 関連するアンチパターン
6-2 コードのオーナーシップ制：コードごとの所有権を各チームに持たせる
6-2-1 ガイドラインの概要
6-2-2 チーム内では共同所有する
6-2-3 チーム外に対しては「弱いコードの所有」とする
6-2-4 技術の選択肢を適度に制限する
6-2-5 コードを無闇に非公開としない。
6-2-6 コードの所有権を明示する
6-2-7 組織全体に仕様を公開する
6-2-8 関連する原則やガイドライン
6-2-9 関連するアンチパターン
6-3 バリエーション分割：対応プラットフォームごとにチームを分ける
6-3-1 ガイドラインの概要
6-3-2 個別の仮説を並列で検証する
6-3-3 成功したら移植し、失敗したら移植しない
6-3-4 洗練させてから移植する
6-3-5 リリース日に意味を持つものは同時に進める
6-3-6 業務負荷に偏りがあるなら分割しない。
6-3-7 人員数が少ない時はバリエーション間のマルチスキル化を進める
6-3-8 関連する原則やガイドライン
6-3-9 関連するアンチパターン
6-4 垂直統合：エンドツーエンドの開発チームを作る
6-4-1 ガイドラインの概要
6-4-2 フロントエンド開発とバックエンド開発を統合する
6-4-3 共有バックエンドはいずれかのバリエーションチームが担う
6-4-4 組織として技術力を獲得していない間は水平統合を採用する
6-4-5 アーキテクチャ量子に着目してチームが引き受ける範囲を決める
6-4-6 関連する原則やガイドライン
6-4-7 関連するアンチパターン
6-5 DevOps：開発と保守・運用を1つのチームに統合する
6-5-1 ガイドラインの概要
6-5-2 開発業務や保守・運用業務に投下するリソース量の基準を決める
6-5-3 各業務への投下時間を記録する...
6-5-4 オンコールローテーションを整備する
6-5-5 デプロイパイプラインの自動化率向上と効率化に力を注ぐ
6-5-6 保守・運用の負荷が高まってきたら開発よりその改善を優先する
6-5-7 保守・運用の負荷が大きい状態のままで統合しない
6-5-8 開発と運用を統合できない組織もある
6-5-9 関連する原則やガイドライン
6-5-10 関連するアンチパターン
6-6 機能横断：より多くの業務機能を1つのチームに統合する
6-6-1 ガイドラインの概要
6-6-2 企画機能の一部と開発を統合する
6-6-3 品質保証と開発を統合する
6-6-4 無理して機能横断を進めない
6-6-5 関連する原則やガイドライン
6-6-6 関連するアンチパターン
6-7-1 ガイドラインの概要
6-7-2 人員不足はマルチスキル化で解消できることもある
6-7-3 T型やπ型人材を推奨する
6-7-4 無理に押し付けない
6-7-5 関連する原則やガイドライン
6-7-6 関連するアンチパターン
第7章 組織のリファクタリング・リアーキテクティング
7-1 組織設計をアーキテクティングと設計で責務分けする
7-2 SPACEフレームワークで組織の開発生産性をモニタリングする
7-2-1 SPACE フレームワーク
7-2-2 満足度と幸福度: Satisfaction and well-being
7-2-3 パフォーマンス: Performance
7-2-4 活動:Activity
7-2-5 コミュニケーションとコラボレーション: Communication and collaboration
7-2-6 効率とフロー: Efficiency and flow
7-2-7 指標の選択方針
フローを増やすための指標選び例
ソフトウェアの内部品質を改善するための指標選び例
・ソフトウェアの内部品質を改善するために計測する指標
ディメンション/指標
満足度と幸福度：チームやプロダクトに対する誇り
パフォーマンス：コードカバレッジ、チームによる保守性の評価、欠陥の数、 変更失敗率、計画予実
活動：ブルリクエストのサイズ、コントリビューター数、マイナーコントリビューター数
コミュニケーションとコラボレーション：他チームからのプルリクエスト受け入れ数
効率とフロー：開発と保守・運用の投下工数比率
7-3 指標を正しく活用する
7-3-1 情報と知識に変換したうえでの組織全体への共有
7-3-2 組織として重要視することの明示
7-3-3 アウトカムが最優先
7-4 まとめ：組織にもリファクタリング・リアーキテクティングを！
