第13章 マネージャー

スクラムには「マネージャー」という役割は定義されていませんが、組織において彼らは「チームを形作り、環境を整え、価値の流れを最適化する」ための不可欠な支援者となります。

13.1 概要

アジャイルへの移行において、マネージャーの役割はなくなるのではなく、コマンド＆コントロール（指示と統制）から、チームが成功するための「環境作り」へとシフトします。

13.2 チームを編成する ＆ 13.3 チームを育てる

マネージャーは個々のタスクを管理する代わりに、チームという「枠組み」を設計し、能力を最大限に引き出す責任を負います。

• 境界とゴールの設定: チームが自律的に意思決定できる範囲を明確にし、戦略的な方向性を提示します。
• 権限の委譲: どこまでをチームに任せるかを明文化し、段階的に委譲を進めます。
• 能力開発（T型スキル）: メンバーの技術的・思考的なスキルアップを支援し、機能領域のリーダーシップを促します。
• チームの安定: 頻繁なメンバー変更を避け、高いパフォーマンスを維持できる「長寿なチーム」を保護します。

13.4 環境を合わせてなじませる

組織全体の調整役として、スクラムの価値観を広め、外部との障壁を取り除きます。

• 組織的インピディメントの解消: チーム単独では解決できない組織構造の課題や、部門間の壁を解消します。
• 対外調整: サプライヤーや他部門との関係を、よりアジャイルな協力体制へとシフトさせます。

13.5 価値創造の流れを作る

マネージャーは、コンセプトからデリバリーまでのプロセス全体（バリューストリーム）を俯瞰し、最適化します。

• 全体最適の視点: 局所的な最適化ではなく、システム全体としての流れを妨げている要因を特定します。
• 財政と評価の管理: 予算の管理を行い、活動量（工数）ではなく「動作するソフトウェア」や「学習速度」に基づいた評価基準を策定します。

13.6 プロジェクトマネージャーの扱い

スクラムにプロジェクトマネージャー（PM）は存在しませんが、その責任は再分配されます。

• 責任の分散: 伝統的なPM業務（スコープ、時間、コスト、品質等）は、プロダクトオーナー、スクラムマスター、開発チームの3者で分担します。
• 大規模組織での役割: 多数のチーム調整が必要な場合、指示ではなく情報の透明性を高める「ハブ」として機能するマネージャーが残ることもあります。

13.7 まとめ：伝統的マネジメントとの比較

項目	伝統的なアプローチ	スクラムのアプローチ
タスク管理	マネージャーが割り当てる	チームが自律的に定義する
パフォーマンス評価	個別（個人）に行う	チームへの貢献と全体価値を重視する
主眼	プロセスの標準化	価値創造の流れの最適化

---

エンジニアリングへの適用メモ

• セルフマネジメントへの応用: フリーランスとして、自分自身の「マネージャー」になりましょう。自分の作業の「境界」を定め、学習（JSTQB、Next.js等）を通じて「能力を伸ばす」活動は、自分というチームへの投資です。
• 「価値の流れ」を意識する: コーディングだけでなく、デプロイやフィードバック獲得までを一つの流れとして捉え、どこに「詰まり（インピディメント）」があるかを特定する視点が、サイト開発の効率を劇的に高めます。
• PM業務の分散を理解する: 案件において「何を、いつまでに、どの品質で」作るかを、クライアント（PO的役割）と対等に議論し、自らコントロールする姿勢が、高付加価値なエンジニアとしての信頼に繋がります。