CodeNote

読書メモ『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』広木大地（著） を読んだので、書籍から得た知見をご紹介します。

背景 マネージャー向け推薦図書

約4年前に読了していたのですが、社内でマネージャー向けの推薦図書として扱うことになったので、今更になりましたが読書メモを公開することにしました。

所感 全ビジネスパーソン向け必読書

“エンジニアリング組織論” というタイトルからエンジニア向けの本と思われそうですが、社内にエンジニアが居る会社のマネージャーは必読書だと思っています。欲を言えば、同僚にエンジニアが居る、全てのビジネスパーソンに読んでほしいです。

キーワード

以下、自分用の検索キーワードです。

• データ駆動な意思決定の誤解
• 不確実性コーン
• カレー作りの寓話
• アジャイル
• プロジェクトマネジメントとプロダクトマネジメント
• 技術的負債
• コンウェイの法則/逆コンウェイの法則
• マイクロサービス

以下、印象に残った箇所の引用とメモです。

Chapter1　思考のリファクタリング

1-5.経験主義と仮説思考

■理性主義と経験主義

経験主義では、知識の源泉を「経験」に求めます。実験を行ったり、行動を行うことでしか、「知識」は得られないという強烈なパラダイムシフトを引き起こしました。

（中略）

過去の話から、「過去の人々は愚かだったが、現在はそうではない」といった解釈をするのは早計です。現代においても、そして、エンジニアリングの世界においても「理性主義」的な態度というのは、ここ数年前まで常識的なものとされていました。
実際の経験に基づかずに、理性によって、設計主義的にソフトウェアを組み上げることが可能であるという前提に立ったプロセスが、ウォーターフォールをはじめとする「設計主義的プロセス」でした。
それに対して、近年主流となりつつあるスクラムのようなソフトウェア開発手法を「経験主義的プロセス」と呼ばれています。スクラムの手引き書である『スクラムガイド』には、以下のように経験主義に対して言及があります。

📝
ウォーターフォール = 設計主義的プロセス
スクラム = 経験主義的プロセス

データ駆動な意思決定の誤解

悲しいかな「データ駆動な意思決定」について、多く誤解があるように思います。大量のデータが存在すれば、そこから次にとるべき正しい行動がわかるとする誤解です。実際は、常にデータは不完全ですし、そこから意思決定は導けません。

「データ駆動な意思決定」は、

・「仮説」を推論するために、もっているデータの可視化をする
・「仮説」が正しかったのか、統計的に検証する

ということにおいて、有効な考え方であって、データから演繹的・帰納的に決定論的に答えが導けるわけではありません。
そのため、数少ないデータから大胆に顧客のインサイトや仮説を推論し、それが正しいのかという不確実性を検証するための行動をとるというのが重要なことです。

1-7.人間の不完全さを受け入れる

■情報の非対称性

情報の非対称性とは、同じ目的をもった集団で、何かの情報を片方の人が知っていて、もう片方の人が知らないという状態です。上司が把握している情報を部下は把握していないとか、その逆に現場が把握している情報を、経営陣は把握していないなどの状態です。

また、人は、正確に自分の考えていることを、他人に伝えることは不可能なので、何か情報を伝達しているつもりであっても、そこの非対称性が生まれます。
情報に非対称性があることは当たり前のことですが、しばしば、人は、自分の抱えている状態を他人も把握しているはずだと勘違いして、あるいは把握していてほしいという願望に基づいて行動してしまいます。
「ハンロンのカミソリ」という言葉があります。それは次のような警句です。

無能で十分に説明のつくことを悪意のせいにするな
（ロバート・J・ハンロン）

この警句が示すように、お互いの情報伝達が不完全で、それゆえに引き起こされた問題であっても、何か害意や悪意をその中に見出してしまいがちなのが人間の性です。

Chapter3　アジャイルなチームの原理

3-1.アジャイルはチームをメンタリングする技術

アジャイル開発が必要とされた2つの理由
ソフトウェア開発の中で、「アジャイル開発」が必要とされたことには2つの理由があります。それは、「ソフトウェアが大規模化・複雑化」したこと、そして、「マーケットの不確実性に対応する」必要性が出てきたことです。

プロジェクトマネジメントとプロダクトマネジメント

■○○マネジメントの意味
（中略）
プロジェクトは、「はじめ」と「おわり」があり、それが効果を上げて「終了すること」が目的です。それに対して、プロダクトは「製品・サービス」ですので、そのプロダクトが継続的に収益を上げて、損益分岐点を超えて発展することで、「終了しないこと」が目的になります。

3-3.アジャイルをめぐる誤解

アジャイルに関する5つの誤解

■誤解1：アジャイル開発は決まったプロセスである
■誤解2：アジャイル開発では設計をしない
■誤解3：アジャイル開発は、優秀なメンバーでないとできない
■誤解4：アジャイル開発では中長期計画がない
■誤解5：アジャイル開発は開発者に決定権がある方法だ

3-4.アジャイルの格率

「アジャイル」は理想状態
アジャイルという言葉は、「ある理想的な状態」を指しています。その理想的な状態というのは、「チームが環境に適応して、不確実性を最も効率よく削減できている状態」のことです。これは、自己組織化とも呼ばれます。この状態は、理想的な状態なので決して到達することのできないような高いゴールを指しています。
この状態に向かうために、チームにはある「問い」が投げかけられます。それは「どのようにしたら、私たちはもっと不確実性を減らすことができるだろうか」という問いです。

Chapter4 学習するチームと不確実性マネジメント

4-2.スケジュール予測と不確実性

悲観的見積りと楽観的見積り

■見積りとエージェンシースラック
見積りは、あくまで予測です。しかし、この予測を「ノルマ」として扱ってしまった場合、それが達成できないときに能力や評価の問題にされる可能性が出てしまいます。本来、予測が当たらないのであれば、予測精度に問題があるのであって、仕事を達成できなかったことによるものではないはずなのにです。
予測を「ノルマ」にした途端、それを達成するための過負荷な労働が生まれ、クオリティは下がってしまいます。あるいは、スケジュールの予測精度はどんどんと下がってしまいます。このようなことを避けるため、エンジニアは次からは防衛的で悲観的なケースでの見積りを行おうとします。

4-3.要求の作り方とマーケット不安

スケジュール不安とマーケット不安の対称性

時間境界型プロジェクトでは、納期の手前にプロジェクトバッファを用意して、時間の不確実性に備えます。それに対して、機能境界型のプロジェクトでは、当初計画した機能とMVPの差を用意して不確実性に備えます。これがスコープバッファです。現実的なプロジェクトにおいては、この2つの境界（時間と機能）は並行して全体のバッファを用意し、それらが重なる面の中にプロジェクトが着するように備えます。このように機能と時間には、一定の対称性があります。

Chapter5 技術組織の力学とアーキテクチャ

5-1.何が技術組織の“生産性”を下げるのか

見えてしまえば「技術的負債」ではない
（中略）
正体の見えてしまった「技術的負債」を構成するタスクは、一般に非機能要件と呼ばれます。これは、表面の機能には影響がないが、性能や拡張性、運用性といったことに関する要求によって生まれる要件です。
つまり、技術的負債は、「見えない」からこそ技術的負債と呼ばれるのです。その1つひとつが見えてしまえば、まだ満たされていない「非機能要件」のリストとして、管理可能なものになります。

技術的負債に光を当てる
技術的負債が問題となるのは、それが見えないからです。経営者から見えるようにしてしまえば、管理可能なものになります。

以上、エンジニアリング組織論を実践していきたい、現場からお送りしました。