エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

著者 : 広木大地

• 技術評論社 (2018年2月22日発売)

作品紹介・あらすじ

技術的負債・経営との不和。プロジェクトの理不尽。上がらない生産性。そのすべての正体は不確実性の扱い方の失敗にあった。「コミュニケーションにおける不確実性を減らすには?」「技術的負債を解消する方法とは?」「経営陣とエンジニア間の認識のずれを解消するには?」エンジニアリングにおける、課題を解決する思考の整理方法やメンタリング手法を解説!

感想・レビュー・書評

[dsukesanさんの感想 · 2022年3月24日]

頭プラスで働くUXデザイナーが薦める本

https://note.com/hiroko_nozawa/n/n0e11111d4847

[AkikoSuginoharaさんの感想 · 2018年3月24日]

アジャイル、スクラム、技術的負債といった言葉だけが先行することが多いけど、その成り立ちと、不確実性つまり不安の扱い方の観点で説かれていて、腑に落ちた。
個人がいかに自律的であるか。そして組織、ビジネス、プロセス、システムをエンジニアリングすること。エンジニア組織論ではなく、エンジニアリング組織論。学び多き良書だった。

#エンジニアリング組織論への招待 #不確実性に向き合う #要再読

[Takamaru Suzukiさんの感想 · 2020年12月27日]

エンジニアリング組織のみならず、ビジネス組織を設計するうえで、あるいはマネジャーがメンバーをメンタリングするうえで重要な示唆に富んだ一冊。

特に、「不確実性の減少をめざす」という本書のキーコンセプトはきわめて汎用的であるとともに、スタートアップのような変化が激しい環境では殊更重要。

[P_tanさんの感想 · 2018年6月4日]

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

[mura-miさんの感想 · 2018年3月2日]

世には表層的な「アジャイルなプラクティス」について取り上げることに終止した書籍が多い中，コミュニケーションや組織論などといった社会科学の背景からキチンと解説した良書．

「アジャイル」を一面的に良いもの，推し進めるものとして紹介する書籍とはことなり，「ウォーターフォールとアジャイル」という対立軸の有意な側面とそうでない側面について論じて，アジャイルのムーブメントを相対的に論じているところもとても好感が持てる．

[中田 裕太 / Nakata Yutaさんの感想 · 2024年3月31日]

組織論は、問題と構造明らかにする作業であり、そこには、個人の考え方・偏見がある。そのうえで、問題を落とし所として解決するのではなく、根本的に両者のやりたいところはどこなのか？そこを見極め、納得して進める必要がある。また、技術と組織においては、望ましい役割、組織サイズなど変数がいくつもある。常に考えておくべきことは、傾聴とコミュニケーション。そしてリーダーの言ってることは抽象度が高いのは当たり前ということ。

[necomeisterさんの感想 · 2023年9月25日]

何だかエッセイだなという感じ。

アジャイルなチーム、学習するチーム、組織力学などエンジニアが取り巻く不確実性にどのように挑むかが述べてある。
数式で語っているところもあれば、なんだか出典がよく分からない図(筆者の図解?)で説明されている所もあり、説得力が上がったり下がったりして読みにくい。

考えの根底に貫いていることはなんとなくエンジニアには伝わる本だと思うんだけどなぁ。

[torishimaさんの感想 · 2021年1月31日]

読んでる途中だけど良書、
マネージャーや、リーダーなどの人は読んでおいて損はない、
ちょっと量が多いのでゆっくり読むか、いいとことって読むと良いとおもう

[matchyyさんの感想 · 2020年12月13日]

組織における情報の透明性、
開発における見積りの不確実性を解決しようとしたときに、
どういうことを考えていけばいいのか、
最初の一歩の踏み出し方を教えてくれる本な気がしました。

どの章でも、どの問題でも、
まずは何がわかっていて、何がわかっていないのか、
無知の知ではないが、わかっていないことを知ることを基礎としている気がします。

組織のマネージメントを考えたときに、
この本を読むことで知識の整理、行動の促進、自身の立ち位置の把握と、
振り返りを生むことが多い本だと思いました。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
●「エンジニアリング」とは一体何でしょうか。
（中略）
私たちは、自分たちが日々行っている「エンジニアリング」とは一体何なのかをよく知らないということです。
（中略）
エンジニアリングとは、つまるところ、「実現」していくための科学分野だといえるでしょう。（P.10-11）
●不確実性コーン。プロジェクト初期においての見積もりは、見積もりに対して4倍から1/4の範囲で誤差があります。後半になればなるほどその誤差は減ります。つまり「実現」するエンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。（P.12）
●シャノンは、不確実性の量をエントロピーと呼びました。例として天気として、明日は晴れか雨だけだとします。明日は晴れが50%（雨が50%）の場合1bit、晴れが80％（雨が20%）の場合0.72bit、晴れが100%（雨が0%）の場合0bit。（本にはエントロピーの式がある）発生する確率が偏っているほど、不確実性の量は減っていくことがわかります。（P.15）
○全体論とシステム志向は、「人は、問題を個人の責任にしたり、全体像を見失った局所的最適な思考をしてしまう」ので、それが全体像ではないかもしれない、問題は関係性にあるのではないあかという視点と問題解決のための目を提供し、行動を促すものでした。（P.67）
○「情報の非対称性」と「限定的理性」、この2つが、組織における人間の不完全さを加速させ、組織に忍んでいる理不尽の増幅装置となってしまうのです。（P.69）
○「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。（P.72）
●メンターとメンティの関係性の条件。
・謙虚：お互いに弱さを見せられる
・敬意：お互いに敬意を持っている
・信頼：お互いにメンティの成長期待をもっている（P.81）
●「悩む」と「考える」の違い
（中略）
「悩んでいる」というのは、頭の中に様々なことが去来し、ぐるぐると思考がめぐり続け、もやもやが取れない状態だと考えています。
（中略）
この状態になったときには、サポートが必要dふぇ、共に考えるための戦略を立てていく必要があります。（P.87）
○メンターは、メンティの問題を直接解くことはできません。メンターができることは、問題を「簡単な問題に変換する」ことだけです。（P.96-97）
●認知フレームを発見する「キーワード」（P.101）
（それぞれの系で抜粋。相手の裏側を考えるのに非常に有効に思える）
こちら系　：この会社　：同じ側にいるように思えるが、実は一体感を持っていない。
あちら系　：あの部署は：同じくくりにいるはずなのに、向こう側と線引きしている。
極端系　　：いつも　　：ゼロ一で、グラデーションなしの物事判断
すべき系　：～すべき　：「～すべき」という枠組みの中で限定的に考えている
決めつけ系：どうせ　：感情的に決めていて、事実確認なしで推論している
●承認（アクノレッジメント）の3つの段階（P.112）
存在承認：挨拶を始め、相手がここにいることに対するメッセージ。
行動承認：行動に対して言葉で出して伝える。例えばほめること。
結果承認：できあがったものに対して主観を込めて伝える。ほめるより広い範囲への承認。
○マネジメントとは、対象となる○○の資源・資産・リスクを管理し、効果を最大化する手法（P.136）
○「アジャイル」状態とは、具体的にどのような状態でしょうか。それは以下のような状態のいのことを意味しています。
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い（P.141）
●SECIモデル（P.151）
共同化・表出化・連結化・内面化という各フェーズを繰り返していくことで、知識というものが発展的に組織的に蓄積されます。
・共同化：組織において共通の経験を積み重ねることで、暗黙的な経験的な知識が共有されているフェーズ。共同化を促すためには、経験や思い、信念などをストーリーテリングする場が必要になる。
（異なる人が独自に実施）
・表出化：体感的で明文化されていない経験的知識の共通点や抽象的な構造・類似点を見つけモデル化していく工程。これはメンタリング的な対話によって引き出されていく。
（構造化、類似点の抽出によりモデリング、文章化）
・連結化：複数の形式的な知識を積み重ねて、1つの知識体系を作るフェーズ。そのためには、形式知を共有・編集・結合させるような場が必要で、Wikiなどのシステムはそのようなことを目的としている。
（Wikiなどによる凝縮して他の人ができるようにする）
・内面化：形式知として生まれた知識体系を知識として覚えている状態から、実践や行動を通じて、体感的・身体的に「理解できた」という状態に変えるフェーズ
（文書化された知識を実践や行動に移すが、ゆっくりと見ながらでもよい練習している状態）
○「見積り」について考えてみましょう。ソフトウェア開発は同じことを二度と繰り返す必要が基本的にないので、毎回どこかしら初めての作業になります。そのため、作業見積もりというのはいい加減なもので、正解とは限りません。ですが、作業実績であればどうでしょうか。これは過去の実例なので正確な数値です。これをもとに将来を見通すほうが、より正確になるはずです。（P.177）
（アジャイルに限らず予測と実績を取得しておくことで、初めて改善できる。やるやらを考える時にも、なんのためにやるのか、測定できる何が改善されるのかを考えないといけないということ。）
○プロジェクト型チームはレスポンスタイムを最適化する。
プロダクト型チームはスループットを最適化する。（P.179）
●見積りは、あくまで予測です。しかし、この予測を「ノルマ」として扱ってしまった場合、それが達成できないときに能力や評価の問題にされる可能性が出てしまいます。
（中略）
予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティは下がってしまいます。あるいは、スケジュールの予測精度はどんどんと下がってしまいます。このようなことを避けるために、エンジニアは次からは防衛的で悲観的なケースで見積りを行うとします。（P.190）
●2点見積り、3点見積り（P.193）
●エピック→テーマ→ストーリー→タスク（P.208）
○すでに成功しているビジネスであれば、公開されている情報からでもリーンキャンバスを再現することはできるでしょう。成功しているビジネス10個程度ピックアップして、そこからリーンキャンバスを想像するという練習を繰り返すと、プロダクトのもつ本質が見えてくるようになります。
　仮説検証における仮説は、十分な情報があるところとから導かれる正解ではありません。わずかな痕跡からでもよいのではっきりとした具体的なイメージをもつことで、はじめて仮説と現実の違いを認識することができます。（P.220）
○技術的負債は「見ることができない」（P.256）
●技術的負債というと抽象度が高く見ることができないが、解決方法を調査検討することで何が問題が見えてきます。見えてこればそれはただのタスクでしかありません。（P.264）
●システム外注における取引コスト
・探索のコスト：クオリティの高い外注先を探す、関係を構築するコスト
・交渉のコスト：契約条件をまとめるコスト
・監督のコスト：品質の監視、維持、検収をするコスト（P.276）

[yumu19さんの感想 · 2020年3月30日]

とても面白かった。エンジニアリングとは不確実性を減らすこと。不確実性は未来と他人。コミュニケーションの不確実性により情報の非対称性が生まれる。

最初に認知の歪みに触れてるのがよい。

著者プロフィール

広木大地（ひろき だいち）
株式会社レクター取締役。2008年度、新卒第1期として株式会社ミクシィに入社。同社メディア統括部部長、開発部部長、サービス本部長執行役員などを歴任。2015年同社を退社し、現在は技術組織顧問として複数社のCTO支援を行なっている。2018年2月22日に『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』を刊行、第6回ブクログ大賞を受賞。