チームの境界
チームの境界は、どこまでをそのチームが理解し、判断し、責任を持つかを決める線です。境界が広すぎると認知負荷が高くなり、狭すぎると依存関係が増えます。
よい境界は、価値の流れ、ドメイン、技術的な結合、運用責任を見ながら設計します。組織図の都合だけで決めると、実際の仕事の流れとずれてしまいます。
問い
- このチームは何に責任を持つのか
- どこから先は別チームの責任か
- 依存関係は多すぎないか
- 顧客価値を届けるために必要な判断がチーム内でできるか
- 認知負荷は大きすぎないか
チーム境界は一度決めたら終わりではありません。プロダクトや技術、組織の成長に合わせて見直す必要があります。
- 組織的創造性を覚醒させる「揺さぶり」の質問
- リーン・バリュー・ツリー(LVT)
- 顧客フィードバックの流れを作る
- プラットフォームチームの考え方
- システムを変えるふりかえり
- OKRとプロダクト戦略
- アジャイルなガバナンス
- WIP制限はチームの集中を守る
- AI時代の2025年にPdMが読むべき5冊
- 意思決定を記録する
- Team Topologies の最初の一歩
- Product Ops
- チームのメトリクス
- 仮説としてのロードマップ
- Opportunity Solution Tree
- デュアルトラックアジャイル
- プロダクトディスカバリーの基本ループ
- アウトプットではなくアウトカムで見る
- 15%ソリューション
- チャタムハウスルール
- ベガスルール
- 戦略展開
- オペレーティングモデル
- 変革疲れ
- Go-to-Market
- ポジショニング
- セグメンテーション
- ペルソナ
- カスタマージャーニーマップ
- サービスブループリント
- Blameless Postmortem
- ガードレール
- システム思考
- チームの境界
- Stream-aligned Team
- Enabling Team
- Architecture Decision Record
- 技術的負債
- バリューストリーム
- Communities of Practice
- 意思決定権
- Delegation Poker
- ワーキングアグリーメント
- Team API
- 社会技術システム
- コンウェイの法則
- 認知負荷
- 心理的安全性
- 機会費用
- Impact Mapping
- Cost of Delay
- RICE優先順位づけ
- A/Bテスト
- コホート分析
- Pirate Metrics
- North Star Metric
- Product-Market Fit
- Jobs to be Done
- プロトタイプ
- MVP
- リトルの法則
- 累積フロー図
- サイクルタイム
- リードタイム
- カンバン
- バックログリファインメント
- スプリントゴール
- ベロシティ
- ストーリーポイント
- 受け入れ条件
- ユーザーストーリー
- Definition of Ready
- Definition of Done
- Thinkers 50コミュニティが選んだ最も影響力のある経営本(2023)
- 組織変革フレームワーク
- 4Cフレームワークを使ったワークショップの作り方
- スクラムマスターが読むべき5冊
- WIP制限の値の設定方法
- リーンキャンバスから事業計画書へ
- 新規事業の4つのアプローチ(PGTM)
- アジャイル認定資格というもの
- アジャイル導入の「最小限」の読書リスト
- 雑誌『anan』で「アジャイル」
- スクラムマスターは開発メンバーになれるのか?