『エンジニアリング組織論への招待』を読んで〜思考のリファクタをはじめる

『エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング』を読んでの感想となります。（2024/12/26記載）

本の概要

「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。
若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。

引用：

gihyo.jp

動機

・今年色々なところでこの本の噂を聞き興味を持っている。

・最近EM.FMを聞き始め広木さんの考えをもっと知りたいと思っている。

・エンジニア組織のあるべき姿をもう少し立体的に捉えたい。

整理メモ

Chapter 1　思考のリファクタリング
エンジニアリングとは何かを実現すること。
実現するとは曖昧さ・不確実性を減らし、具体性・明確さを増やすこと。

不確実性は未来と他人をもとに発生し、情報により低減する。
組織における人間の不完全さは、情報の非対称性と限定合理性により加速する。

事実を正しく認知し感情にとらわれず判断し、
経験主義と仮説思考による問題の明瞭化を行い、
システム思考を基に要素同士の関係に注目して問題の構造を解き明かすことで、
健全な情報が生まれる。

Chapter 2　メンタリングの技術

心理的な課題と技術的な課題は密接に関係する。
エンジニアリングは不確実性を削減する工程であり、
組織で実現するには人間の不完全さを削減することが重要。

自立型人材を育てるには、上司部下間での期待値の調整が重要。
自らの力で限定合理性の枠から抜けだし、知識を獲得することで、
自己効力感が発生し、応用力が身につき、フィードバックループが生まれる。

生産性に寄与する心理的安全性は、互いに対人リスクを取れる関係を築き、
問題点の指摘、自身の弱みの開示、失敗の報告ができる状態で生まれる。

ゴール認識には、願望、義務、欲求、意志、必然というレベルがある。
意志の段階で初めて行動変化が生まれ、必然の段階で習慣が変化し始める。
必然の段階になると、セルフマスタリーの状態が生まれる。
Chapter 3　アジャイルなチームの原理
アジャイルな状態とは以下状態。これにより自己組織化の状態を作る。
・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い

不確実性には、未来に対する環境不確実性と、他人に対する通信不確実性が存在する。
環境不確実性は、方法不確実性と目的不確実性に分けられる。
不安は通信不確実性を増大し、結果、目的不確実性、方法不確実性を増大する。

アジャイル開発は、役割の分断と情報の非対称性を解消するため、
顧客との協調、個人との対話、動くソフトウェア、変化への適応を重視する。
Chapter 4　学習するチームと不確実性マネジメント
納期までに必要と考えられている３要素は以下。
・理想工期：工数人月／人数
・制約スラック：作業同士の依存関係による無駄
・プロジェクトバッファ：見積もりの不確実性を吸収する期間

制約スラックを削減するためには、作業の属人化によるリソース制約、
作業間の依存関係による依存制約を取り外す。
見積りをノルマではなく予測として扱い、スケジュール予測の収束を管理する。
予実幅を見える化し透明性を保ち、効率よく削減する。
タスクごとのバッファではなく、プロジェクトバッファを用意することで、
スケジュール不確実性の削減を見える化する。

スケジュール不安に対するマネジメントと、マーケット不安に対するマネジメントには対称性がある。
時間境界型プロジェクトでは、納期の手前にバッファを設けて不確実性に備える。
機能境界型プロジェクトでは、計画した機能とMVPの差を用意して不確実性に備える。
２つの不確実性を考慮し、全体のバッファを用意する。

スクラムイベントで、目的不確実性、方法不確実性、情報非対称性を軽減する。
Chapter 5　技術組織の力学とアーキテクチャ

システム実現のための組織構造が最適化されていない場合、
組織全体の情報処理能力は下がり、組織構造の問題が技術的負債として組み込まれる。

組織課題を改善するにはコミュニケーション構造のリファクタリングが必要。
技術的負債が問題となる最大の理由は、追加機能とアーキテクチャに対する情報の非対称性。
技術的負債を非機能要件として整理し、エンジニアと経営者の認識の差を低減する。

企業の内側にあるべき事業上のケイパビリティを外部依存すると、大きな取引コストが生まれる。
外注すべき領域と内製すべき領域は明確な線引きをし、
システムアーキテクチャで持つことで取引コストをコントロールできる。

内製においても、組織設計ミスや構造的問題により、限定的合理性に起因する取引コストは発生し、組織的負債となる。
機能横断チームと機能別チームをバランスよく運営することで解消する。

目標設定は目標が限定合理に陥らないように相互に役割を正しく認識し透明性を保つことが重要。

ビジネスを完全に明晰な言葉で表現しなおすのがプログラミング。
システム開発においてシステムアーキテクチャが、
企業活動においては組織構造が動きやすさの要因となり、相互に影響を与える。
コミュニケーションを通じて、ビジネスの向かうべき方向に一致させる。

まとめ

エンジニアリングとは何か、それを実現するための組織はどうあるべきかを
ミクロからマクロまで叩き込まれました。
ウォーターフォールの受託文化で育った自分としては、
この論を自分のベースに入れ替えたいと真剣に思います。
それこそ、思考のリファクタリングなのか。

特に【局所最適化】による問題は割と身近なところにあり、
企業間の契約にしろ、受発注の関係にしろ、工程間のやり取りにしろ、
リファクタしたい部分いっぱいあるよなー、となりました。
ただ、それをもっと俯瞰してどうプロダクト開発に影響があるかの理解ができました。

また、アジャイル開発に対して改めて考え直すためのきっかけとなりました。
スクラムマスターの役割もの根本もファシリテーターというざっくりな捉え方でいてしまったけど、
Chapter3のアジャイルの状態の実現と考えると、見え方が全然変わります。

いずれにせよ、もっと早めに頭に入れたかった１冊でした。
最後に広木さんが自分と同じ1983年生まれと知り驚愕です。

何度か読み直したい。