「エンジニアリング組織論への招待」の読書感想文
かなーり有名な本だと思ってるんですがエンジニアリング組織論への招待を読みました
なぜこのチョイス？
マネージャーとの 1 on 1 でマネジメント系でおすすめの本ないですかって聞いたら
「不確実性についての話ならこの本がいい」と勧められたので
全体感想
「そもそもエンジニアリングってなんだ」と問いかけて、
「エンジニアリングとは何かを実現することだ」ときちんと定義してから始まるのはよかった
その中で今ないものを実現するのだからその計画には不確実性が伴うという感じに話が進んでく
自分の思考、他人、チーム、組織全体と対象を大きくしながらそれぞれ不確実性のある部分とそれにどう対応すべきかが書いてある
特に他人の不確実性の章ではメンタリングと呼ばれる指導、支援の方法が丁寧に説明されてた
なのでいわゆるプログラマーと呼ばれるコードを書く人以外にも割と当てはまる話が多いと思う
個人的には、
「未来と他人は本質的に完全に理解することは不可能」というのと
「問題には観測できる / できない、コントロールできる / できないの4パターンがあり、観測できないものはそもそもコントロールできない(他人がどう思っているのかは見ることはできないしコントロールすることもできない)。観測できるがコントロールできないものは、観測できてコントロールできることを使って間接的に制御していくしかない (他人の行動は観測できるがコントロールはできないので、自分の行動によって働きかけて制御していくしかない)」
という部分がかなり納得感があった
概要
章ごとに短くまとめて行きます
Chapter 1 思考のリファクタリング
エンジニアリングとは「実現」していくための科学分野
企業において何かを「実現」するときには最初のアイディアの状態から最終的に具体的な仕事になるまでだんだんと不確実性が減っていく
不確実性には「未来の不確実性 = 環境不確実性」と「他人の不確実性 = 通信不確実性」が存在する
不確実なものをだんだんと確実なものにするためには情報が必要になる
情報を生み出すためにはやってみないとわからないという「経験主義」と経験から得た少ない情報からもしかしてこういう法則があるんじゃないかと大胆に考える「仮説思考」が必要
Chapter 2 メンタリングの技術
最近よく聞くメンターとはビジネスや教育の現場で若い社員 (メンティ)を良い導き手としてサポートする人間のことで、その手法をメンタリングと呼ぶ
メンターとメンティの関係性は
お互いに弱さを見せることができる
お互いに敬意を持っている
お互いにメンティの成長期待を持っている
であると効果的
答えを教えるのではなく、メンティが答えに辿り着く手助けをする
メンターとメンティで次のアクションを決めるときは「SMART」というフレームワークを使うと良い
Specific: 具体的
Measureable: 計測可能
Achevable: 到達可能
Related: メンティの課題に関連している
Time-Bound: 時間制限
Chapeter 3 アジャイルなチームの原理
アジャイル開発とは開発初期に綿密な計画を立てることは不可能という事実を受け入れ、小さなリリースとフィードバックを繰り返しながらプロダクトを開発していく手法
アジャイルとは何を作るべきかがわからない、マーケットの不確実性が高い領域において効果的
アジャイルとは不確実に向き合う、少人数の対話と重視する、役割を分けない、意思決定を遅延すると行った方法をとる
意思決定の遅延はネガティブに聞こえるが、計画初期のまだなんの経験もない状態のときに大きな意思決定をするのではなく、小さなリリースをしてフィードバックを受け、経験と情報が増えるまで大きな意思決定を先送りにするという意味
Chapter 4 学習するチームと不確実性マネジメント
不確実性は3つに大別される
方法不確実性
目的不確実性
通信不確実性
方法不確実性とはスケジュール予測と見積もりの手法に対するもの
リリーススケジュールは「間に合うか / 間に合わないか」ではなく「スケジュール予測が収束していくか」を管理しなくてないけない
不安量の大きいタスクを細かく解体し、Tシャツサイズ見積もりやストーリーポイント見積もりで相対見積もりを行う
目的不確実性はマーケットに対するもの
大きなプロダクトを実装し、いざリリースしたときにマーケットの求めるものと違っていた場合には損失は大きくなる
リリースポイントを細かく設定し、リリースのたびにマーケットの反応をみながら次のリリースの計画を立てると良い
通信不確実性は他者とのやりとりに対するもの
スクラムでは短いタイムボックスの中で見積もり、日々の進捗共有、成果物の確認、プロセスの振り返りを行う
基本的には対話を重視したフレームワークなので誰が何をしているかがチーム全体で共有しやすくなる
Chapter 5 技術組織の力学とアーキテクチャ
組織の人数が増えていったとき、理想としては比例して生産性も上がっていって欲しい
しかし実際には人が増えるとコミュニケーションのコストが大きくなり、だんだん生産性は下がっていく
コミュニケーションが無駄に多くならないよう、権限と責任を部下に移譲する必要がある
