読書メモ：エンジニアリング組織論への招待

May 5, 2026

読書メモ。

書籍紹介

エンジニアリング組織論への招待～不確実性に向き合う思考と組織のリファクタリング
https://gihyo.jp/book/2018/978-4-7741-9605-3

若手の頃、Web エンジニアとしての仕事は「コードを書くことだ」と単純にそう思っていた気がします。良いコードを書きたい、悪いコードをリファクタリングしていきたいし、何よりそれによってより良い社会になっていくことを目指していました。

より良いアーキテクチャで品質の高いコードを書くにはどうしたらよいのだろうか。そう考えていくうちに、人々の思考の癖や人間関係、ビジネス環境の中で生まれてくる不合理が、形を変えてコードの中に漏れ出ているように思えてきました。

そして、問題解決のためには、コードだけでなく、人々の思考・組織・ビジネスの「構造」こそリファクタリングしなければいけないと考えるようになりました。それこそがエンジニアリングの本質なのだと気がついたのです。

エンジニアを取り巻く環境には、様々な問題があります。

なぜ、いつまでも堂々巡りの議論をしてしまうのか

なぜ、上司と部下のコミュニケーションは失敗するのか

なぜ、イケてるはずのアジャイルやリーンがうまくいかないのか

なぜ、プロジェクトは炎上し、スケジュール通りに終わらないのか

なぜ、技術的負債が問題となるのか、その正体はなんなのか

なぜ、経営者とエンジニアの認識が食い違うのか

これらの根源は、「わからない」ことに対する不安です。未来や他人の考えていることは絶対にわかりません。ですから、問題なのはちょっとしたきっかけから作られた「構造」であって、誰かが悪いわけではないのです。しかし、長らく続いた不況のためか、日本社会は「わからないもの」に向き合う力が弱くなっているように思います。

けれど、先が見えないという「不確実性」をどう扱うかを知ることができれば、「不安」は「競争力」に変わります。エンジニアリングに必要な思考は、まさにこの不確実性を力に変えるという点なのです。

本書は、「不確実性に向き合う」というたった 1 つの原則から、エンジニアリング問題の解決方法を体系的に捉える組織論です。わからないものを避けるという本能を、どのように理解し、克服し、導くのか。テクノロジーを力に変えたい経営者やエンジニアリーダー、そして、今、かつての私と同じように悩んでいる人のチャレンジへのきっかけとなればうれしいです。

思考のリファクタリング
1. すべてのバグは、思考の中にある
2. 不確実性とエンジニアリング
3. 情報を生み出す考え方
4. 論理的思考の盲点
5. 経験主義と仮説思考
6. 全体論とシステム思考
7. 人間の不完全さを受け入れる
メンタリングの技術
1. メンタリングで相手の思考をリファクタリング
2. 傾聴・可視化・リフレーミング
3. 心理的安全性の作り方
4. 内心でなく行動に注目する
アジャイルなチームの原理
1. アジャイルはチームをメンタリングする技術
2. アジャイルの歴史
3. アジャイルをめぐる誤解
4. アジャイルの格率
学習するチームと不確実性マネジメント
1. いかにして不確実性を管理するか
2. スケジュール予測と不確実性
3. 要求の作り方とマーケット不安
4. スクラムと不安に向き合う振り返り
技術組織の力学とアーキテクチャ
1. 何が技術組織の " 生産性 " を下げるのか
2. 権限以上とアカウンタビリティ
3. 技術的負債の正体
4. 取引コストと技術組織
5. 目標管理と透明性
6. 組織設計とアーキテクチャ

感想

いくつかの分野の内容を総花的にまとめているような本でした。チャプター１は本の導入部にあたるところですが、ここで筆者の意見が最も記載されているように感じます。特に、「エンジニアリングとは、不確実性を下げ、情報を生み出し、秩序を作ること」と定義していることが記憶に残りました。チャプター２以降は、各専門書が扱っている内容をかいつまんで記載しているようなものでした。チャプター２はメンタリングについて、チャプター３と４はアジャイル開発について、チャプター５は経営学的な観点からの組織設計や人材管理についてです。本書を手に取ったときの経験年数やバックグラウンドによって感想は変わると思いますが、わたしにとっては今更読むまでもなかったかも、という本でした。

Chapter 1：思考のリファクタリング #

不確実性とエンジニアリング #

何かを「実現」するときには、「はじめ」と「おわり」が必ずあります。

ソフトウェアにおいて「はじめ」は誰かの曖昧な要求です。それが具体的で明確な形である「おわり」に変わっていく仮定が「実現」で、その仮定のすべてがエンジニアリングという行為です。

つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。

では、エンジニアリングによって減らしていくべき、「曖昧さ」とは何のことでしょうか。それはまだ決まっていないことで、はっきりとしていない、将来どうなるかわからない確実でないもののことです。

経済学や社会学の分野ではそれを「不確実性」と表現します。プロジェクトマネジメントでは、プロジェクト初期においては、曖昧で、不確実な範囲が広く、想定される納期に幅があります。プロジェクトが進むにつれて、徐々に不確実性が下がっていき、いつごろには完成するのかがはっきりしてきます。

このように、ものを実現するというのは、不確実な状態から確実な状態に推移させていく仮定だと理解することができるでしょう。

ということは、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方なのです。

では、「不確実性」の正体とは何でしょうか。実は、「情報」という概念と深い関わりがあります。

クロード・シャノンは、「不確実性」の量をエントロピーと呼びました。そして、不確実な事柄の確率分布がわかっていれば、次のような式でエントロピーを定義できると示しました。

H(X) = -Σ iPilog2Pi

少しわかりわかりにくいので、単純な例で考えてみましょう。明日、晴れる格率が 50%、雨になる格率が 50% として、他の可能性はないとします。そんなときのエントロピーは、次の式で表せます。

-0.5log2(0.5) -0.5log2(0.5) = 1bit

それに対して、明日、晴れる格率が 80%、雨になる格率が 20% だとすると、エントロピーは次のようになります。

-0.8log2(0.8) -0.2log2(0.2) = 0.72bit

明日は 100% 晴れるとしましょう。その場合は次のようになります。

-1log2(1) -0log2(0) = 0bit

発生する格率が偏っているほど、不確実性の量は減っていくことがわかります。

シャノンは「不確実性を減少させる知識」のことを「情報」と定義しました。たとえば、明日、晴れか雨か 50:50 だと思っていた人に対して、「明日は 80% で晴れだよ」という情報を伝えたとします。このとき 1bit の不確実性から、0.72bit の状態に変わることができました。差分 0.28bit を「情報」というわけです。

エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程に行うすべてのことです。エンジニアリングというとつい、技術的なことだけで構成されているような錯覚をしてしまいます。もちろん、技術的な理解や視点は重要ですが、それだけを考えていると本質を見失ってしまいます。

「不確実性を下げること」はつまり、シャノンの定義に従えば、「情報を生み出すこと」に他なりません。いかにして、多くの情報を生み出すことができるのか、そのために何をすべきかというのが、本書で取り扱う一貫したテーマです。

もし、ソフトウェアを書くこと以外に不確実性の削減手段があるのであれば、迷わず提案しましょう。そうすれば、よりよいものを作ることができます。それもまた、エンジニアリングの一部なのです。

人間の不完全さを受け入れる #

社会人に求められる能力として、近年当たり前のように使われている「コミュニケーション能力」という言葉があります。これは、曖昧なもので人よって定義が違います。人と仲良くなったり、特に当たり障りのない会話を楽しんだり、空気を読む力というようにとらえどころがない言葉でもあります。

真に組織に求められるコミュニケーション能力とは、コミュニケーションの不確実性を減少させる能力のことだといえます。さらには、組織内において連鎖的に発生する不確実性のループを止めることができる能力ともいえます。それによって、集団に発生する「情報の非対称性」と「限定合理性」を極力低減させていくことができます。

そして、しばしば組織において言及されるのが、「情報の透明性」です。情報の透明性というと、「できる限りの情報を公開すること」だと勘違いされがちですが、それは１つの手段です。公開するだけでは、コミュニケーション不確実性のうち、伝達の不確実性をわずかに下げるにすぎません。

「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性を作ることです。情報公開が情報の透明性を作るわけではありません。

「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。

Chapter 2：思考のリファクタリング #

メンタリングで相手の思考をリファクタリング #

周りの状況などから、自ら今までわからなかったことを理解した状況を「自己説得」といいます。

自己説得には次のような特徴があり、これを促すようにサポートするのが、メンタリングによる教育効果といえます。

他人が質問で促す
体感を伴う
行動の変化が発生しやすい

自己説得を生み出すには、答えを言うのではなく、適切な質問の積み重ねが重要です。質問に酔って、より望ましい解決策を自ら発見できるよう促すことができます。

あるとき、別の会社の後輩から「今やっているプロジェクトは、残業時間が多すぎてダメなんです。プロダクトオーナーはそれを問題と思ってないんです」と相談をされたことがありました。

私は、「プロダクトオーナーは、それを問題と思っていないって、どうして判断したの？」というように問いかけてみました。すると、彼は、不意をつかれた顔をして、「残業が多い状況をそのままにしているからです」と答えました。

さらに私は、「なぜ、そのプロダクトオーナーは残業してまで、今やっていることをしたいと思っているの？」と問いかけました。それに対して、彼は小さく「考えたことがなかったです」と答えました。

そして「その人が何を考えているかわからなければどうしたらいい？」とまで聞くと彼は、「話し合えてなかったですね。そういうことか。なんで気が付かなかったんだ」と興奮気味に話していました。

この興奮は、きっとみなさんには伝わりにくいことでしょう。問題も解決策も引いてみると当たり前のことばかりだからです。しかし、その彼にとっては、見えていない／見えなくなっている次の行動がはっきりしたので、悩みが悩みではなくなってしまったのです。

私がしたことは、「事実確認」と「情報の非対称性の解消」に気がつくような質問を投げかけただけです。もし、この場面で、最初から「もっとプロダクトオーナーと話し合いなよ」と答えたら、彼はこの次の行動にコミットできたでしょうか。きっと難しかったでしょう。

「答え」ではなく、質問を通じてメンティにとっての思考回路の盲点となっている部分を外していき、自ら解決策に導くのが自己説得の方法です。そもそも、問題解決するのは、メンターではなく、メンティです。すべてのその人の問題は当人しか解決できないので、解決策を言うこと自体が、相手への経緯を欠いた行為とも言えます。

傾聴・可視化・リフレーミング #

メンタリングによって、問題解決を促したという事例を人に伝えるのは非常に難しいところがあります。というのも、悩んでいる本人にとってはそのときは整理されていない問題で、整理されてしまった後はとても単純な問題だったりするからです。

それを後から、理路整然と問題を事例として他の人に説明すると、効いている人は「当たり前の結論だな」としか感じることができません。モヤモヤしていることをそのまま他の人に伝えることは難しいからです。

もやもやした悩みは、解けてしまえばなんということはないものなのですが、１人でその状況に対応するのは難しいものです。ですので、メンターは、メンティに対して、「問題を解決してあげよう」という意識ではなく、「モヤモヤしていない問題に変換してあげよう」と考えることが重要です。

「モヤモヤしていない問題」とは何でしょうか。それは、メンティにとって、「答えはまだわからない」が「明確に次にすべき行動がわかる」ような問題です。

メンタリングでは、「次に取るべき行動」がはっきりするように促す必要があります。それが曖昧なままでは「悩み」は継続します。しかし、「次のとるべき行動」がはっきりすれば、「考える」ことはあっても、「悩む」ことは少なくなるでしょう。

要するに「考える」は行動で、「悩む」は状態なのです。考えているのであれば、それはメンターがその行動を見ることができます。しかし、「悩み」であれば、メンターは心の状態を観察することはできません。

メンティが「行動できていない」ときに、メンターは、「悩み」を聞き出し、気づきを促して「考える」に変えていく必要があります。

心理的安全性の作り方 #

「心理的安全性とは」、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現して働くことができること」というような定義がなされます。

心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」というのではないかと考えても不思議はありません。

そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考える人もいるでしょう。いわゆる「アットホームな会社です」の状態です。プライベートで仲がよいような状態でも、「対人リスク」を感じることや「自分の地位」を脅かされるような強さは無いかもしれません。ある意味で、間違いなく「心理的安全性」が高いのだといえます。

しかし、その状態は「高い生産性」と本当に関係するのでしょうか。高い生産性につながるような「心理的安全性」と、緊張感のないぬるま湯的な「心理的安全性」にはどのようなちがいがあるのでしょうか。

『チームが機能するとはどういうことか』という本の中で、著者のエイミー・エドモンドソンは「心理的安全性」を高めることで次のような影響がチームに現れると解説しています。

影響	解説
率直に話すようになる	課題について他の人がどう思うかをそれほど気にしないでも発言することができる
考えが明晰になる	不安が少ないため、認知の歪みが少なく、考えを明晰に表現できる
意義ある対立が後押しされる	関係性の悪化に伴った対立ではなく、より本質的な対立を健全に議論できる
失敗が緩和される	失敗を報告しやすくなり、ミスについて話し合う機会が増え、学習を行える
イノベーションが促される	今までの前提を取り払って、思考することができるようになり、創造的な意見が出る
組織内の障害でなく目標に集中できるようになる	目標に対して、ストレートに向き合えている。組織内の理不尽を取り除くことに力をかけないでも済む状態にある
責任感が向上する	対人リスクをとっても、目標に対して自律的に行動できるようになる

これは、友人関係にたとえて考えればわかりやすいかもしれません。本当の友人であれば、その人のダメなところもちゃんと指摘できるし、自分のダメなところも見せられるものです。ただ一緒にいると、馬鹿騒ぎできるから楽しい。そういった関係では、いざ自分自身が悩んだときに相談することができないし、友人がなにか悪いことをしていても、それを止めることができなかったりします。

この友達にであれば、何を指摘したとしても、自分がどんなダメなことをしたとしても、人間関係が終わるようなことはないだろうと考えるように、率直に飾らずに話せるかどうかというのが、「心理的安全性」という概念の重要な視点です。

このような通常「対人リスク」が伴う行動が増えている状態が、「心理的安全性」が高い状態だといえます。

Chapter 5：技術組織の力学とアーキテクチャ #

何が技術組織の " 生産性 " を下げるのか #

アメリカの著名なソフトウェア工学者であるトム・デマルコは、自身の著書である『ピープルウェア』の中で、次のように述べています。

ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである

この言葉にあるように、システムを構築していく組織における情報処理能力を考えるにあたって、重要な点は人間同士の関係性の問題です。

エンジニア組織の改善に必要なことは、組織全体のコミュニケーションの改善です。より大きな組織における問題の解決のためには、組織のもつコミュニケーションの構造をリファクタリングしていく必要があります。個々人の意識の力は弱く、様々な関係性から生まれる「空気」のようなものによって気がつかないうちに悪い方向へと組織を導いてしまいます。そのようなことが起こらないように、そして経営者や技術リーダー自身が「空気」に支配されないように、構造的な問題の解決に取り組む必要があります。

対応	解説
権限の移譲と期待値調整	コミュニケーションの必要性を減らし、コミュニケーションの失敗を防ぐためには、適切な権限委譲とそれに伴う期待値の調整が必要
適切な組織・コミュニケーション・外部リソース調達の設計	職能ではなく、責任やケイパビリティの単位で組織やコミュニケーションを設計していくことで、コミュニケーションコストを減らし、システムに反映される
全体感のあるゴール設定と透明性の確保	組織の各要素の間で生まれる情報の非対称性を減らすため、透明性の確保と全体感のあるゴール設定をもつことで、限定合理性の発生する余地を減らしていく
技術的負債の見える化	組織的な問題の発露である「技術的負債」現象の見える化を通じて、対応可能な課題に変えていく