エンジニアリング組織論への招待
対人関係のリスクは、本当に切れてもどうなってもいいという時と、リスクを取ったとしても関係が変わらないことを理解しているとき
行動→習慣→能力→成果→行動
ここで、能力および成果はアンコントローラブル
プロジェクトマネージャーとプロダクトマネージャーの違い
そもそもマネジメントとは、対象となるものの資源、資産、リスクを管理し、効果を最大化させること
終了することが目的
スケジュール不安を減少させることに取り組んでいる
終わらせないことが目的
マーケット不安を減少させることに取り組んでいる
異なる不安に対してアプローチしている
開発方式というスコープで話してきたが、アジャイル開発については「チーム全体をメンタリングする」ための方法論である。
開発方式に見える部分はその方法論の表面的な一部にすぎない
よって、メンタリングの技術を伴っていない場合、望ましい効果を得ることは難しい
では、「チーム全体をメンタリングする」とはなにか
チームが総体として、チーム自体のゴールに対して高いゴール認識を持ちチーム自体がチームをメンタリングしている状態
（別にセルフマスタリーは十分条件じゃない。）
ウォーターフォールかアジャイルかという選択肢は成り立たない
単位が揃っていないからである。
ウォーターフォールのスコープは方法不確実性とスケジュール不安
アジャイル開発はそれに加えて目的不確実性とそれに伴うマーケット不安。そして継続するチームマネジメント、つまり通信不確実性である。
経営学としてのアジャイル
ソフトウェア開発よりむしろ、経営学あるいは組織学習という文脈の中で生まれてきた
思想史
エンジニアリングとは不確実性を確実性に変えていくこと
不確実性
未来不確実性
方法不確実性
目的不確実性
他人不確実性
これが方法不確実性を、目的不確実性を増大
アジャイル開発とは、自分たちの状態や周囲に存在する不確実性をしっかりと観察し、チーム状態をよりアジャイルに導いていくための暫定状態で用いている手法のこと 4章 学習するチームと不確実性マネジメント
いかにして不確実性を管理するか
不確実な要素をリストアップし、インパクトの大きいものから継続的に削減する仕組みを考える
スケジュール予測と不確実性
スケジュールには3要素ある
理想工期
プロジェクトバッファ
スケジュール不安の見える化
CCPM
個別タスクのバッファをそれぞれとって合計するのではなく、個別タスクのバッファを一旦取り除き、その後、個別タスクのバッファと発生確率を決めて全体で一つのバッファをもつ
第5章 技術組織の力学とアーキテクチャ
組織成果
←情報処理必要量
←市場の不確実性
←情報処理能力
←保有するシステムと組織形態
https://gyazo.com/1c934420d91a47a87abafd0931bab0d5
329ページ
組織とシステムの関係性
なぜ発生するのか
組織構造というものが「コミュニケーションコストの構造」であるという点から考えると理解しやすい
コミュニケーションコストの坂道と同じようにシステムの構造を作っていく行為が最も効率的になってしまう
責任と権限
責任と権限の不一致
責任はあるが権限はない場合
裁量がないのに責任を負わされるので嫌気がさす
責任はないが権限はある
上司からは部下が何をやっているのか判断ができない。結果、その上司の上司への説明責任を果たせないことになる。
見えてしまえば技術的負債ではない
技術的負債に光を当てる
技術的負債の可視化
アーキテクチャの複雑性
循環的複雑度の可視化
依存関係の分析
コードチャーンの分析
将来要件の不確実性
非機能要件の具体化
仮説・戦略の透明化
ユビキタス言語の作成
アーキテクチャ複雑性の可視化
循環的複雑度の可視化
ソースコードの文化の構造をグラフとして捉えてその中に閉じたループの数を数え上げたもの
取引コストと技術組織
自分たちのものではないリソースを使うときにはそれに伴うコストが発生する
取引コストによって会社の境界線が決まる
エンジニアリングカンパニー
企業活動は、市場に存在する不確実性と、複数人の組織のコミュニケーションの不確実性とを相手にしたエンジニアリング