どんな本
「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」を読みました。 技術書大賞（翔泳社）などを受賞している非常に評判の良い本です。
エンジニアリングの本質は、「不確実性の削減」であるという論の元、どうすれば不確実性を下げることができるか、というテーマで書かれており、 第１章では個人、２章では1:1の人間関係、3.4章ではチームやプロダクト、5章では組織における不確実性の削減について記述されています。
あいまいな要件定義や現場と経営陣の意識のズレにうんざりしている人に、特に有益な本だと思います。
覚えておきたいと思ったこと
本を分かりやすく要約した書評はたくさんあるので、このブログでは自分が特に覚えておきたいと思ったことをまとめます。
Chapter1 思考のリファクタリング
エンジニアリングの本質が不確実性の削減であると気づけないと、確実でない要求仕様、確実でない実現手段にストレスを感じて 確実なものを確実な手段で提供したいというありえない理想を描いてストレスを感じてしまう。
人は事実を正しく認知することは難しい。そのため、自分の認知がいつ、どのように歪むのか知る必要がある。
怒りを感じた時、何をどのように傷つけられたか深く捉えることが重要である。
私たちは何か問題に出くわしたとき、つい、コントロールできないものを操作して、観測できないものを改善するという不可能な問題設定を行ってしまう。
不確実性が大きいもの、つまりプロジェクトが生み出す利益の変動幅が大きい場合、その確からしさを確認する方法を生み出すことができれば、プロジェクト全体をリスクに減らす必要がなくなる。
個人の性質そのものを変えることは難しいが、個人同士の関係性を変えることはそこまで難しくない。システム思考は、個々人の性質より、個々人の関係性に問題の構造を見つける考え方である。
他者理解の不確実性、伝達の不確実性、成果の不確実性（仮に理解されても予想されたように行動するとは限らない
情報の透明性 -透明性とは継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性、情報の非対称を削減し、限定合理性の働きを弱められている状態のこと。
自分自身がどのように本能に囚われているのか知り、仮設と検証を通じて、未来の不確実性を下げていきながら、同じ目的で働いている人々とのコミュニケーション不確実性を減らしていく必要がある。
不確実性を削減し、秩序をつくることがエンジニアリングの出発点、性質である。
Chapter2 メンタリングの技術
メンタリングでは、次にとるべき行動がはっきりするよう促す必要がある。それがあいまいなままでは悩みが継続する。 考えるは行動で、悩みは状態である。メンターは、メンティが行動できていないとき、悩みを聞き出し、気づきを促して考えるに変えていく必要がある。
自分は分かっているけど相手は分かっていない、またはその逆の状態では、双方にとって最適な解決策は生まれない。
心理的安全性とは、対人リスクをとっても問題ないという信念がチームで共有されている状態
メンタリングを効果的にするためには、自分の弱さ、自分の失敗を開示できる状況をつくりあげる。
Chapter3 アジャイルなチームの原理
アジャイル開発は従来の開発型と比べて平均して三倍の成功率と三分の一の失敗率
アジャイルな状態とは、情報の非対称性が少ない、認知のゆがみが少ない、チームより小さい限定合理性が働かない、心理的安全性が高い、課題・不安に向き合い不確実性の削減ができている、チーム全体のゴール意識のレベルが高い 状態。 このような状態であれば生産性を高めて自律的に成長できる。
Chapter4 学習するチームと不確実性マネジメント
エンジニアリングは不確実性を削減することであり、どこにどんな不確実性があるのか観察する必要がある。
不確実性は、方法不確実性、目的不確実性、通信不確実性の三つの不確実性がある。
スケジュール不安を見える化する必要がある。
個別の不安量が分かった場合、不安なタスクの順に問題解決をする。
何を作るかという不確実性のことを目的不確実性という。何を作るかが正しかったかは、リリースして初めてわかる。 どのような機能をどのような順番でリリースしていけばよいのか優先順位付けする必要がある。
Chapter5 技術組織の力学とアーキテクチャ
組織における問題解決のためには、組織の持つコミュニケーションの構造をリファクタリングする必要がある。
権限と組織設計のポイントは、1明示的な責任と責任の移譲を行う、2権限と責任の不一致をなくす、3権限同士の衝突を最小にする、4権限の衝突解消レベルを最小にする の4つ。
技術的負債が問題となるのは、それが見えないからである。経営者から見えるようにすれば、管理可能なものとなる。
技術的負債に光を当てるためには、エンジニアは知っていて、経営者が知らないことと、経営者が知っていてエンジニアがしらないことを解消していく必要がある。前者はアーキテクチャの不確実性で、後者は将来要件の不確実性である。
企業活動は、市場に存在する不確実性と複数人の組織のコミュニケーションの不確実性とを相手にしたエンジニアリングである。 組織上の課題は、個人の問題として捉えられがちであるが、根本的な問題は構造上の問題と気づけば対立は消滅する。
解決すべき問題は、その姿が見えれば悩みから考えるに変わる。必要なのは、組織やビジネス、プロセス、システムへのエンジニアリングである。
