【感想・ネタバレ】エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリングのレビュー

広木大地

[ブクログ · ★★★★★]

個人から組織まで様々な視点で抽象的なことから具体的なことまで書かれていてとても良かった。ベスト本です。エンジニア組織に関わる人なら全員読むべき本だと思いました！

[ブクログ · ★★★★★]

不確実性が高いプロジェクトをどのようにドライブするか、各要素ごとにかなり丁寧に書いてある。
私はチームメンタリング部分を参考にしたかったため、それ以外は読み飛ばしたが、かなり具体的で参考になった。
メンタリング部分だけでも読む価値がありそう。

[ブクログ · ★★★★★]

自分的には非常に良書だった。個人レベルの思考方法についてから入り、コミュニケーションを行う上でのメンタリングの重要性、チームにおける開発・マネジメント、組織の力学と徐々にスケールアップしていく流れも良かった。エンジニアリング組織で働く人の学びになる記述が多くある。特にメンタリングのところは、自分がメンティーの立場だったときに記述されていたようなコミュニケーションを実践できていなかった先輩も多かったし、自分がメンター的立場だったときを思い出すと発言や接し方を反省すべきところがたくさん思い返された。ところどころ、「～は○○といいます」みたいなところでは出典を出した方が良い気がしたのと、筆者の経験を踏まえた自身の考えなのか、出典のある定説なのか分からず、モヤモヤ感じるところもあったが、文章の納得性は非常に高いので、割と素直に理解・共感できた。また、節の中での項目間のつながりがよく分からず、伝えたいことが羅列されているように見えてしまう感もあった。その分を差し引いてもぜひ多くの人に読んで欲しい重要な知見が詰め込まれている。

[ブクログ · ★★★★★]

予想に反して、所属している会社で起こっていること、行われていることのバックグラウンドを理解することに役立つ一冊だった。
個人的には本書で解説されたようなアジャイルムーブメントの背景は知らなかったので面白かった。
若手中堅向けな印象、OJTトレーナー研修で読むといいんじゃないかな。
本書終盤に謎の誤字(変換ミスのようなもの)が多いのはどうにも気になったけど本質を損なうものではなかった。

[ブクログ · ★★★★★]

手元に置いておきたい一冊。自組織にあてはめながら、様々な角度から読むことで悩んだ時のバイブルになると思う。

[ブクログ · ★★★★★]

エンジニアリングとは不確実性を減らす作業という定義のもと、個人、対人、チーム、プロダクト、そして組織に対してどのように不確実性と対峙していくかということが丁寧に書かれている。

仕事は学力テストと違い答えのないものが多く、いかにして不確実性と向き合っていくかという観点で大変参考になる書籍だった。

特に以下の内容に気づきを得られた。

・人や組織は限定合理性によって対立する
・アーキテクチャは組織構造に影響を受ける
・技術的負債が溜まりやすくなるのも組織構造の問題

読んだ直後でまだ飲み込みきれていないので、
日を開けてもう一度読み直してみたいと思う。

[ブクログ · ★★★★★]

不確実性の削減＝情報を生み出すこと、など序盤から刺さるワードが多い。

タイトル通りの内容が非常に良くまとまっていて、手元に置いておきたい一冊

[ブクログ · ★★★★★]

エンジニアリングを、進めていく上でどのように組織を作っていくべきかについて網羅的に述べた本。最初は個々人の考え方(メンタリング)から始まり、最後は企業というひとつの大きな組織の中でどうしていくかまで話を広げていく。

個人的に面白いなと思ったのが、プロダクトを作る上で大事なのは「不確実性を減らしていくこと」であるので、不確実性を効率的に減らせるオプションを積極的に採用していくべきというものだった。
これにより、いくつか存在する不確かさ(不安)に対してうまく対処することができるというもの。

あまり自分はこの観点で考えたことがなかったので目新しかった。

また、やはりチームメンバーとのコミュニケーションは重要であるし、組織内に閉じた限定合理性をまでに止められるよう意思伝達は正確に行っていきべきだなと感じた。
メンタリングの際も、自分の考えを押し付けるのではなく、あくまで質問ベースで相手の気づきを促す………これはなかなか難しい。

その他にも、プロダクトの目標を再整理するためにリーンキャンバスを利用するというのはなるほどなと思った。


ちょうど今、少人数でこのようなプロダクト作りに取り組んでいるので積極的に試していきたい。

[ブクログ · ★★★★★]

　組織論のお勉強。すごくよくまとめられている。

　スクラムは、経験的プロセス制御理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性と最適化とリスクの管理を行う。

　…いずれにしても、現代においても経験主義的な発想というのは、しばしば抜け落ちがちで、「考えれば答えが出る」という学力テスト的な価値観が蔓延しているように思います。

　パースは、人間の推論能力の方法として、従来の演繹法、経験主義で重視された帰納法に加えて、仮説法というものがあり、「これこそ、新しい諸観念を導入する唯一の論理的操作である」と述べました。
　
　…仮説法は、「わずかな痕跡」から、それを説明可能とする大胆な思考展開・モデル化を行い、それを検証するための行動につなげる推論方法です。

　仮説思考は、経験主義をさらに生産的な（不確実性を削減する）ものにするための「大胆な跳躍」をもたらします。そして、仮説は、今あるデータからは、演繹的・帰納的には導くことのできないものです。人間的な直感やひらめきによって、今までの情報や様々な偶然が積み重なって生まれる跳躍であって、天下り的な結論や合議による凡庸なアイデアは「仮説」にはなりえないのです。

■コミュニケーションの不確実性（ニクラス・ルーマン）
・他者理解の不確実性：人は他人や事象を完全には理解できない
・伝達の不確実性：コミュニケーションが到達するとは限らない
・成果の不確実性：仮に理解されたとしても予想されたように行動するとは限らない

　…組織の人数が増えるにつれて、スケールするはずの情報処理能力が実際には線形に推移せず、徐々にそれよりも悪くなるのは、これら「情報の非対称性」と「限定合理性」が存在するからです。

■限定合理性
　人間の能力には限界があります。すべての情報をすべての人が適切に処理できるわけではありませんし、同じように認知するわけでもありません。こうした認識範囲や能力の限界から、限られた範囲でしか合理的な行動が取れない性質が限定合理性です。個人的に最適な戦略が、全体にとって最適になるとは限らないのです。

「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。
「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。

■「心理的安全性」を高めることで現れる影響
・率直に話すようになる
・考えが明晰になる
・意義ある対立が後押しされる
・失敗が緩和される
・イノベーションが促される
・組織内の障害ではなく目標に集中できるようになる
・責任感が向上する

■アジャイル
・アジャイル：目的地（ゴール）。環境に適応して、最も効率よく不確実性を減少させられている状態。理想状態なので、決して到達できない地点。
・アジャイルなチーム：目的に向かう集団。理想状態に向かって、前進しているチームの状態。ゴール認識のレベルが高くチームマスタリーを得ている。
・アジャイルな方法論：目的地に向かうための考え方。理想状態にチームが向かうために、お互いにメンタリングし、不確実性に向き合い、減少させるにはどうしたらよいか考えるための組織学習の方法論や考え方
・アジャイル（型）開発：目的地に向かう特定の移動手段。アジャイルな方法論を取り込んだある具体的なチームで実行されている開発プロセスのこと。移動中に状況に応じて書き換えられ、別のものに変化していく。
・アジャイル開発手法（アジャイルプラクティス）：移動手段の手引書に書かれていること。アジャイルな方法論を取り入れやすくするためのルールやフレームワークとしてまとめられている手法。多くの場合、状況に合わせてそこに書かれていることも変化させる必要があると書かれている。


　ヴェロシティは、あくまで計画の予測可能性を高めることや、チームの健康状態を測るために使うべきです。
　…
　もしスプリントごとに見積りを行い、ヴェロシティを測定すれば、その値は妥当性のあるものになります。一方、ヴェロシティが上がったからといって、それは見積りの誤差があったことを示すだけです。チームは、ヴェロシティを上げることよりもむしろ、ヴェロシティが安定し、将来の予見可能性を上げることに投資をしていく必要があります。

■エンジニアリングの不確実性
・環境不確実性→目的不確実性…戦略
　　　　　　　→方法不確実性…戦術
・通信不確実性　　　　　　　…兵站


　実際のところ、どのようにアーキテクチャを組むのかというのは、ビジネス戦略上極めて重要な経営意思決定といえます。取引コストは、企業組織の境界線を決めるものです。システムにおいても同様で、内製領域と外部調達の領域を決めるのは、経営上不可欠な視点です。

[ブクログ · ★★★★★]

他人と未来は分からない、という考えが一貫していてよかった。1章と2章は特に、他人に対してネガティブな感情を持った時、再度読み直したい。よい本！

[ブクログ · ★★★★★]

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

[ブクログ · ★★★★★]

組織の動かし方、作り方のヒントを得られればと思い、購入した。
1周ですべてを理解するのは無理なので、何周もして少しずつ理解度を深めていきたい。
アジャイルについて勘違いしていたので、本書で書かれているアジャイルの起点を忘れずに、日々の業務で活用していこうと思う。

[ブクログ · ★★★★★]

非エンジニアのプロダクトオーナーやマネージャーがエンジニアと共にプロダクト開発をする場合には必読です。相互理解を進められれるはず。

[ブクログ · ★★★★★]

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

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

[ブクログ · ★★★★★]

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

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

[ブクログ · ★★★★★]

説明損益計算書ベースでの運営に偏りがちなネットベンチャーに対する貸借対照表ベースでのマネジメント論。
技術的負債の話はエンジニア内でもよく出るが、顧客資産に関わる話をしてるのは、エンジニア本でもこれが最初ではないでしょうか？

エンジニアの楽園を作ることが狙いに見えるエンジニアキャリア本が多い中で、この本だけはエンジニアとしての事業に対しての当事者性に基づいて書かれていて、それだけで評価5です。

ちなみに、これに近いのが『仕事の説明書〜あなたは今どんなゲームをしているのか』です。ただし、パッと見、組織論からはちょっと離れますが、これもテクノロジーを利用した事業をやっている会社にとっては、組織論だと思います。

マネジメントというと、最初にヒューマンに行きがちですが、定性的なものは、実はデザイナーの方が得意かもしれません。

ただし、早すぎるテクノロジービジネスにおいては、これらの本に書かれている、数字の『設計』の理解は外せません。何故なら、コンピュータは、数字でコントロールするのですから、エンジニアはコンピュータで扱う数字の設計が外せません。

これを読めば、エンジニアの楽園を作ることを目的にしたマネジメントが長期的に如何に詰みやすいか逆に見えてくると思います。

[ブクログ · ★★★★★]

「情報の非対称性」を軸に昨今のソフトウェア開発現場や組織に横たわる課題を紐解いていく、と雑にまとめ。

個人的には非常に漠然と感じていたことを整理してくれた感じでスッキリしました。

かねてより、自分が進化生態学を専門としていたことはこの業種の理解に相当役立っていると感じていたけど、それは偶然ではなくて必然でもあるのだなー、と。

一方、読んでしまったからにはこれを活かさなければ、という思いも持ったのでした。ひとまず、同じように読んだ人、同僚と対話してみたい。

[ブクログ · ★★★★★]

企業の組織構造と技術アーキテクチャの相関性など、この２分野をリンクして語る本は他に見当たらない気がして貴重。

興味を引くぶんナレッジが凝縮されているが、ちょっと深堀りするには他の書籍を読むなども必要。

実際に著者の講演を聴く機会があったので、その際おすすめしてもらったのは「ビジネススクールでは学べない世界最先端の経営学」
組織論について確かに参考になる話が多い。（読書中）

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

■感想
ソフトウェアを作っていると色々と曖昧なもの・ことに出くわすが、それらを「不確実性」として説明しており、自身の経験と照らし合わせても納得できる論が多いと感じた。

■参考になったこと
・エンジニアリングは不確実性を減少させる活動
・不確実性＝①目的不確実性、②方法不確実性、③通信不確実性
・行動は外部から観察可能、状態は観察不可能。「考える」は行動、「悩む」は状態
・プロジェクトマネジメントとプロダクトマネジメントの違い（目的と対処すべき不確実性が異なる）

[ブクログ · ★★★★☆]

不確実性マネジメントについて拾い読みした。学びはあったが、出典が明記されていないため著者の意見と一般的な話の見分けがつかないこと、他の文献を読んでの学習が難しいことがマイナス。

スケジュールの最善ケースと最悪ケースの幅が、スケジュール不確実性である。このスケジュール幅を可視化して効率よく削減していくことが重要。最後になって初めて幅が大きいと分かるのが最悪。

多点見積もりから求められる不安量＝見積もり偏差が大きいタスクから順に問題解決することで、スケジュール不安を早期に減らすことができる。

不安量の大きいタスクを、不安量の小さいタスクに分解することで、不安量を減らしたり、不安部分のみを切り出して先に対処するなどの対策が打てるようになる。

[ブクログ · ★★★★☆]

エンジニアリングと経営の両面から、組織がどのように利益や目標を追求すべきか/できるかを説いている。数的モデルも登場し、説得力があるように感じた

[ブクログ · ★★★★☆]

エンジニアリングの組織において生産性を高めたいので、読みました。エンジニアリングは不確実性を減少させる活動であるという定義はしっくりきました。ソフトウェアの開発は不確実性が最大の状態から、情報を積み上げてそれを削減していく。計画についても、間に合わせるではなく、完了予定を確定させていく、という考え方。アジャイルをするではなくアジャイルになる。ちゃんと計画・設計し、かつ仕様変更に対して俊敏に適応する。それでいて意思決定は遅らせる。プロジェクトにおいて不確実性の観点で優先順位を見極め、よいタイミングで確定させていく。そのためには、実績をもって見積り、計画を立てる。

[ブクログ · ★★★★☆]

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

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

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

（以下抜粋。○：完全抜粋、●：簡略抜粋）
●「エンジニアリング」とは一体何でしょうか。
（中略）
私たちは、自分たちが日々行っている「エンジニアリング」とは一体何なのかをよく知らないということです。
（中略）
エンジニアリングとは、つまるところ、「実現」していくための科学分野だといえるでしょう。（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）

[ブクログ · ★★★★☆]

個人、チーム、組織それぞれの枠組みについて、不確実性を低減する（わからないことをわかるようにする）考え方に基づく適切な思考ツールを整理している感じだった。

一部の人だけでなく、全員の考え方を変えていかないと運用は難しそうなので、本書を読むだけでなく、ワークショップを開催するなどの意識合わせが必要になると思う。

メンタリング（メンター、メンティ）について失敗例、成功例それぞれ詳しく説明されてるのはよかった。

読む人の立場によって関心ポイントが違いそう。

不確実性の解消方法という観点で戦略を整理する考え方は合理主義だなと思ったけど、経験主義的に運用するのが大事だなと。

[ブクログ · ★★★★☆]

自分が何となくもやもやと考えていたものがきちんと言語化されており、インデックスとしてメタ的に理解するのにも向いていると感じた。
一方で個々の説明はそれほど十分でもなく、体系的に理解するというよりはあくまで横断的にインデックスとして理解するいう印象で、この本を元に気になる部分は知識を深めていくという読み方が良さそうと感じた。

[ブクログ · ★★★★☆]

全く予想してなかった思ったよりアカデミック寄りでした。でも全てを不確実性と向き合うためと考えるのはとても腑に落ちる。やはりマーケット不安重視のプロダクト向き組織とスケジュール不安重視のプロジェクト向きに組織での差が納得できた。興味があるセクションとあまり参考にならないセクションの差が激しかったものの読んで良かった。参考になった。

[ブクログ · ★★★★☆]

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

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

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

[ブクログ · ★★★☆☆]

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

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

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

[ブクログ · ★★★☆☆]

様々な課題や感情が絡み合って、もつれた問題に対して、さまざまな理論を引用しながら、カテゴライズ、細分化して解きほぐし、解決可能な課題にしていく。個人個人の課題解決から、チーム、プロセス、組織の課題解決ヘと発展させていく。
知らなかった概念が数多く登場し、分かりやすく解説されているが、ちょっと盛り込みすぎて、断片的なイメージだったり、行間を読み解けないところがあって消化不良な感じ。特に中盤から後半にかけての、アジャイルや技術的な負債に関する洞察は、別の書籍に任せた方が良さそうかな。