たまには本業に関連する本を。ITプロジェクトにおいて必ず直面する「不確実性」のマネジメントと生産性の高い自律したチームの作り方。「技術的負債（ブラックボックス化したシステム）」の取り扱い方についても紹介されています（1年半これを生業にしていましたが、当時の僕の考えは間違っていなかったようです）。
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
↓気になったらここからポチっと（買ってくれるとお小遣いが入ります）↓
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
この本を読むとわかること
思考のリファクタリング
- エンジニアリングの本質は「不確実性の削減」
- ウォーターフォールに代表される「設計主義的な開発プロセス」とアジャイルに代表される「経験主義的な開発プロセス」
- 不確実性の高いものから優先的に取り組むことで不確実性を下げるのが経験主義
- 問題解決よりも課題定義・仮説思考を重視
- 対人関係でコントロールできるものとできないもの
- 全体の関係性をとらえる「システム思考」
- 「情報の透明性」とは情報公開ではなく、伝えるべき情報が組織内に双方向で正しく伝えられ「情報の不確実性」が低減していること
メンタリングの技術
- メンタリングとは対話によって思考の範囲を限定する枠を外し、その人自身で問題解決できるよう促すこと
- コンフォートゾーンから一歩踏み出させること
- メンタリングの特徴は「他者説得」ではなく「自己説得」
- 自分で考えることで応用力を醸成
- 答えを教えるのではなく質問することで思考の盲点を見つけ自己解決に導く
- 「悩む」と「考える」の区別
- コンフォートゾーンへとどまろうとする「思考停止」を打破する質問方法
- メンティの自己開示を促し、フィードバックを受け入れられるような関係を築くことで開く「未知の窓」
アジャイルなチームの原理
- アジャイルはチームをメンタリングする技術
- 市場環境やニーズの多様化に伴う「プロジェクト型開発」から「プロダクト型開発」へのシフト
- 計画重視のプロジェクト型開発とマーケット重視のプロダクト型開発
- 組織の「限定合理性」と「情報の非対称性」の解消を試みるアプローチがアジャイルな方法論
- アジャイルに関する5つの誤解
- アジャイル開発は決まったプロセスである
- アジャイル開発では設計をしない
- アジャイル開発は優秀なメンバーが必要
- アジャイル開発では中長期計画がない
- アジャイル開発は開発者に決定権がある手法だ
- ルールや契約によって役割を分断する前にコミュニケーションや対話を重視することを宣言した「アジャイルソフトウェア開発宣言」
- レスポンスタイムを最適化するプロジェクト型チームと、スループットを最適化するプロダクト型チーム
学習するチームと不確実性マネジメント
- ソフトウェア開発における3大不確実性
- 方法不確実性：スケジュール予測と見積もりの手法
- 目的不確実性：要求と仮説検証の手法
- 通信不確実性：振り返りの手法
- スケジュール不安を見える化するための「スケジュール予測が収束するか」というマネジメント
- 小さいスプリントの繰り返しによる精度・再現性の向上
- 不安量の大きいタスクの解体
- 各スプリントごとの生産性を測定し平均と偏差を測定することで見積もり精度を向上
- 何を作るかというマーケット不安を解消するためのリリース順序の優先順位付け
- 「リーンキャンバス」による仮説構築
技術組織の力学とアーキテクチャ
- 人数を増やしても線形に生産性が伸びるわけではないソフトウェア開発
- 作られるシステムの構造はシステムを作る組織の構造そっくりになるという「コンウェイの法則」
- 権限移譲によって向上するチームの情報処理能力・自己判断力
- 優れた開発チームの組織設計と権限委譲
- 時を経たシステムにおける不可解な開発速度の低下という「技術的負債」
- 技術的負債の測り方
- アーキテクチャのリファクタリング（作り直し）を判断するための技術的負債の「利子率」
- 技術的負債にメスを入れるために明らかにすべき2つの情報非対称性
- 複数の要件が1つのソフトウェアに入り込んだ「モノリシック（一枚岩）」なアーキテクチャと、シンプルを追求したマイクロサービスアーキテクチャ
- システムの劣化を防ぐための「腐敗防止層」という中間のクッション
