エンジニアリング組織論への招待
対人関係のリスクは、本当に切れてもどうなってもいいという時と、リスクを取ったとしても関係が変わらないことを理解しているとき
行動→習慣→能力→成果→行動
ここで、能力および成果はアンコントローラブル
プロジェクトマネージャーとプロダクトマネージャーの違い
そもそもマネジメントとは、対象となるものの資源、資産、リスクを管理し、効果を最大化させること
終了することが目的
スケジュール不安を減少させることに取り組んでいる
終わらせないことが目的
マーケット不安を減少させることに取り組んでいる
異なる不安に対してアプローチしている
開発方式というスコープで話してきたが、アジャイル開発については「チーム全体をメンタリングする」ための方法論である。
開発方式に見える部分はその方法論の表面的な一部にすぎない
よって、メンタリングの技術を伴っていない場合、望ましい効果を得ることは難しい
では、「チーム全体をメンタリングする」とはなにか
チームが総体として、チーム自体のゴールに対して高いゴール認識を持ちチーム自体がチームをメンタリングしている状態
（別にセルフマスタリーは十分条件じゃない。）
ウォーターフォールかアジャイルかという選択肢は成り立たない
単位が揃っていないからである。
ウォーターフォールのスコープは方法不確実性とスケジュール不安
アジャイル開発はそれに加えて目的不確実性とそれに伴うマーケット不安。そして継続するチームマネジメント、つまり通信不確実性である。
経営学としてのアジャイル
ソフトウェア開発よりむしろ、経営学あるいは組織学習という文脈の中で生まれてきた
思想史
エンジニアリングとは不確実性を確実性に変えていくこと
不確実性
未来不確実性
方法不確実性
目的不確実性
他人不確実性
これが方法不確実性を、目的不確実性を増大
アジャイル開発とは、自分たちの状態や周囲に存在する不確実性をしっかりと観察し、チーム状態をよりアジャイルに導いていくための暫定状態で用いている手法のこと 4章 学習するチームと不確実性マネジメント
いかにして不確実性を管理するか
不確実な要素をリストアップし、インパクトの大きいものから継続的に削減する仕組みを考える
スケジュール予測と不確実性
スケジュールには3要素ある
理想工期
プロジェクトバッファ
スケジュール不安の見える化
CCPM
個別タスクのバッファをそれぞれとって合計するのではなく、個別タスクのバッファを一旦取り除き、その後、個別タスクのバッファと発生確率を決めて全体で一つのバッファをもつ