エンジニアリング組織論への招待 の商品レビュー

広木大地(著者)

2018/10/20

エンジニアリング組織論、というタイトルで、エンジニア向けかと勝手に思っていたが、実際は組織全般に関わるマネジメントについて丁寧に紹介してくれた本だった。
会社以外のサークルや家庭すら組織であるから、どこへいってもこの知識は役に立つ。
リーダーやマネジャーだけでなく、構成員がこれを理解していれば、もっと組織の雰囲気はよくなり、生産性も上がるはず。
いろいろな場面で活用していきたいと思った。

2018/09/15

タイトルの通り、技術的な話というよりもエンジニアという職業が抱える課題を組織の視点から色々と解説してくれている本。　目から鱗。　仕事をしていて、日々感じていたモヤモヤの正体が見えてきた。　霧が晴れた感じ。　同時に自分の至らなさも見えた。　先は長い。　まずはこれを何回か読み直して、そこから色々と深掘りしていこう。

しっかし、エンジニアっていうのは勉強することありすぎ。

2018/09/11

レコメンドされてなんとなくタイトルにピンときてポチったら、スゴイ本だった！この本やばい。
技術者向けの本ではなく、経営と組織論の本です。
エンジニアリング＝「ものごとを成し遂げる過程の不確実性を極少化する営み」と定義して、そこでおこる人と組織の機能不全のメカニズムをひもといていく教科書みたいな内容。

なんというか、すごく自分の感覚とFitする。
組織における機能不全、それを引き起こすコンフリクトの原因を、
人間個人の認知と心理のメカニズム、各組織の情報・視野・役割の違いがもたらす部分最適化のメカニズム、
それらがもたらす「不安」、その不安をどう極少化するか、
罪を憎んで人を憎まず、みたいな姿勢で描いて、
そして、それらをプログラムのソースコードのように、丁寧に定義・言語化・体系化して表している。
まさにリファクタリング。

※↓このキーワード、全部でてきます。
でも決して拡散してるわけではない。

不確実性のコーン、マイクロマネジメントと自己組織化、
エントロピー、経験主義と仮説思考、認知の歪み、
データドリブンな意思決定の誤解、リアルオプション戦略、
全体論とシステム思考、心理的安全性と組織パフォーマンス、
ジョハリの窓、ウォーターフォールとアジャイル
グーグルの心理的安全性、ダブルループ学習、学習する組織、
CCPM、ストーリーテリング、取引コスト理論、OKR、、、

2024/04/03

「エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング」　広木大地　★★★★☆

前半は非常に面白かった。後半はすこしキツかったかな。
「アジャイル VS ウォーターホール」という図式自体が違うということは、目から鱗が落ちる思いだった。
アジャイルは方法論ではなく、状態なのだ、その状態を作るのが「経験主義」や「仮説思考」。まずやってみて、わからないことを減らすこと。
チームリーダーの諸君に読んでいただきたい一冊。
#引用
・わたしたちは「わからない」もの（「未来」と「他人」）に向き合うことを避けてしまうという習性がある。
・「わからない」ということは、それだけで自分自身を脅かす可能性を考えてしまう（「不安」）。そのようなものに、人は本能的に「攻撃」か「逃避」を選択してしまう。
・エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移行していく過程に行うすべてのことです。不確実性を下げるということは、つまり、「情報を生み出すこと｝にほかならない。
・「怒り」に変わる感情の、その原初的な思いは、気づ付けられたことによる「悲しみ」であって、それを伝えない限り、どんな理屈をこねて、正当化しようとしても相手の行動を変えることはできない。
・経験主義は、わからないを行動に変換し、一歩でも正解にたどり着くための思考の補助線なのです。
・経験主義は、自分のコントロールできるものを通じて、観測できるものを改善する発送です。
・仮説思考は、限られた情報の中から、大胆にモデルを推論し、そのモデルの確からしさを発見するための行動を促す思考様式です。
・コードレビューにおいては、「なぜ、そのようにしたのか？」ということを問いながら、できれば、その人自身が指摘のポイントに気がついてもらうことを促せるのがベストです。時間がなければ「自分はこっちのほうが、こういう理由でよいと思うけど、どう思う？」のように修正案をつけて、相手に考えさせるのが大切。
・人から与えられた説得による知識を「他者説得」、自分自身で気がついたことを「自己説得」といいます。メンタリングでは他者説得よりも自己説得を重視し、その獲得を促します。
・「考える」は行動で、「悩む」は状態なのです。「行動てきていないとき」は「悩み」を聞き出し、気づきを促して「考える」に変えていく必要があります。
・ポジティブな話を聞くときは早く細かくうずき、ネガティブな話や感情への共感を示すときは、ゆっくり深くうなずく。
・「共感」は「相手がそのような気持ちになった理由を理解する」ことです。
・「同感」は「自分が相手と同じ気持ちになること」でうす。
・傾聴において示すべきことは、「共感」であって「同感」ではない。
・能力は習慣の積分、習慣は行動の積分。習慣が能力に変われば、成果につながり、成果は自身となって次の行動を強化してくれます。
・アジャイルは”俊敏な”という形容詞であって、名詞ではない。「Do agile」ではなく「Be agile」。アジャイルは”する”ではなく”なる”。状態のこと。
・「アジャイルな」状態とは ・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクをとれていて心理的安全性が高い
・課題・不安に向かい合い不確実性の削除が効率よくできている
・チーム全体のゴール認識レベルが高い

・アジャイルソフトウェア開発宣言は「顧客との協調」「個人との対話」「動くソフトウェア」「変化への適応」を重視すべき
・不確実なことを減らすには、一番不確実なことから確かめていくこと。そうすれば、早く失敗するので、一番早く問題解決できます。
・システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。
・組織階層の深さや地理的に離れた複数人が関わるコード、離職者の数、関わっている開発者の人数など、コミュニケーションコストが一般的に多くかかるであろう環境ほど、バグが多くなる傾向が発見された。

2018/12/25

ものすごく濃密に情報が詰まっていて、かつこういった書籍にありがちな個人の経験に基づいた意見でなく論理的に説明されています。
文句ない良書です。

「エンジニア」と「組織論」といったワードから手に取らない人も多そうですが、そのほとんどはエンジニアにも組織論にも留まらない普遍的な内容が書かれています。
そのため誰にでもオススメしたい本です。
ターゲットが絞りすぎたタイトルになっていて、この本が手に取られないのがもったいなく思います。

2018/06/25

分かりにくい。もっと全体観のある本かと思っていたが、そうではなく、個別の知識をバラバラに詰め込んだという印象。色々なキーワードを得る事はできるかもしれないが、それらが整理されたかと言うとそうでもない。全体観が見えないので途中から読むのが苦痛だった。

2018/06/04

文句なしの良書だと思う。
エンジニアリングとは不確実性を削減する行為であるというシンプルな定義からはじめ、不確実性の観点から思考技術、メンタリング、アジャイルマネジメント、組織論の各種手法を解説している。
みんな一回は読んでほしい…。

2018/05/27

仕事の現場で起こっている問題を体系的に整理されており、その点は共感できた。
ただ、その問題の解決策については実践的なものはなかった。
この問題は一つの答えがあるわけではないので仕方ない気もする。

2018/04/23

エンジニア組織を経営するための指南書。巷の「アジャイルについての本」とは一線を画し、マネージメントに焦点を当てた経営書/教科書といった印象を受けた。

本書で一環として説かれているエンジニアリングの本質は「いかにして不確実性を減らすか」。優れたエンジニア組織はこの命題に対して自発的に取り組むことができる組織であり、筆者は著書の中で、リーダーとして求められる思考と行動を3つの段階に分けて解説する。

一つ目は自身の思考を変えること。VUCAの時代、世の中は不確実性に溢れ、物事の因果関係がとても複雑であるため、「論理的思考」もUpdateが必要。経験主義ではなく仮説思考へ、ロジックツリーのような分析ではなく全体を一つのシステムとして捉える思考へ。

二つ目は他人の思考を変えること＝メンタリング。目指すは「自ら考える人材を作る」ことであり、心理的安全性を与えつつ、相手に傾聴し、認知を示しながら自己効力感を高める。

三つ目は組織への落とし込み。基本はメンタリングを個人だけでなく、チーム全体に対して行うこと。ことエンジニア組織については、不確実性に立ち向かうためのマネジメント手法（注：開発手法ではない）として優れているアジャイルを導入し、抽象的で自由度のある指示でも動ける組織を目指すべき。

本書では特に3点目に紙面が割かれており、個別具体的なアジャイル導入論が展開されており、教科書のよう。特に役に立ったのが、①アジャイルに対するよくある誤解をどう解くか、②大きな組織におけるコミュニケーション問題を解決するための4つの処方箋、③技術的負債を組織設計で解決する考え方。

2018/04/23

「ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と言われながらも、実際に社会学的観点からエンジニアリングの問題を語った本ってそんなに無かったので、良い本が出たなと。過去にもTeam GeekやDevOps系の本で類例はあったかもしれないが、科学的な視点を織り交ぜつつ、丁寧に論を進めている本はなかなかなかった。