この記事について
技術的負債がたまる。見積もりが当たらない。経営と現場の話がかみ合わない。
開発の現場でよく聞くこうした悩みを、私たちはつい「あの人の力不足」「あのチームの意識の問題」として片づけてしまいがちです。
本書は、それらがすべて一本の線でつながっていることを見せてくれる本です。その線の名前は「不確実性」。
2018年に出た本ですが、AIで作るスピードが一気に上がった今こそ読み直す価値がある、と感じました。作ることが速くなった分、残った悩みがどこから来ているのかが、かえってくっきり見えるからです。
私は部署にClaude Codeを配って広げてきた中で、「作るのは速くなったのに、なぜか楽にならない」という場面に何度も出会いました。本書は、その理由を考えるための地図になる一冊でした。
書籍情報
| 項目 | 内容 |
|---|---|
| 書名 | エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング |
| 著者 | 広木 大地 |
| 出版社 | 技術評論社 |
| 発売日 | 2018年2月22日 |
| ページ数 | 304ページ |
| 定価 | 2,618円（税込） |
どんな本か？
一言でいうと、組織の悩みを「不確実性」という一つのレンズで解きほぐす本です。
著者の広木大地さんは、エンジニアリングを「わからない状態を、わかる状態に変えていく営み」と捉えます。そして組織の問題の多くは、2つの不確実性をうまく扱えないことから生まれると整理します。
- 環境の不確実性：未来がわからない不安（何を作るべきか、いつ終わるか）
- コミュニケーションの不確実性：他人の考えがわからない不安
本の進み方も特徴的です。第1章で個人の考え方を扱い、第2章で一対一のメンタリング、第3・4章でチーム、第5章で組織全体へと、扱う範囲を少しずつ広げていきます。章タイトルに「リファクタリング」という言葉が使われている通り、思考も組織も、コードと同じように整理し直せるものとして書かれているんですよね。
本書の核心 ― 悩みの正体は「わからなさ」にある
「わかった？」は意味のない言葉
第2章に、「『わかった？』は意味のない言葉」という節があります。この見出しを見たとき、思わず手が止まりました。
「わかった？」と聞かれて「わかりません」と答えられる人は、ほとんどいません。だからこの質問は、聞いた側が安心するためのものになってしまう。本書は、内心は見ることができないけれど、行動は見ることができる、という立場をとります。相手が理解したかどうかは、次にどう動いたかで確かめるしかない。
能力は習慣の積分、習慣は行動の積分、という言い方も印象的でした。育成の話を「やる気」や「意識」から切り離して、見える行動の話に置き換えてくれるので、明日から手を付けられる形になります。
自分メモ: 私は仕事を頼むとき、背景と期待値に加えて「完了条件」を先に渡すようにしています。何ができたら終わりなのかが決まっていれば、「わかった？」と聞かなくても、出てきたもので確かめられる。人に頼むときもAIに頼むときも、確かめられる形で渡すことが、コミュニケーションの不確実性を減らす一番の近道だと感じています。
権限は、不確実性と一緒に渡す
第5章の「権限委譲とアカウンタビリティ」も、管理職として何度も読み返したくなるところです。
権限があいまいなままだと、現場は判断のたびに上に確認しに行くことになり、組織全体の情報処理が詰まります。本書は、権限委譲には段階があることを示し、それをチームですり合わせる方法としてデリゲーションポーカーを紹介しています。「これは誰が、どこまで決めていいのか」を、あらかじめ言葉にしておく道具です。
任せる・任せないの二択で考えると、どうしても極端になります。段階で考えると、「ここまでは任せる、ここからは相談」という線が引けるようになるんですよね。
技術的負債は「見えない」から問題になる
第5章の「技術的負債の正体」には、「見えてしまえば『技術的負債』ではない」という節があります。
負債そのものより、負債がどれだけあるのかが見えないことが問題だ、という捉え方です。見えていれば、返すか、今は返さないかを判断できる。見えていないと、判断の材料がないまま、ただ「なんとなく遅い」が続いていきます。
これは技術的負債に限らない話だと思います。チームの中の「あの人しか知らない手順」も、見えないうちは負債と同じ働きをします。
自分メモ: 私の部署では、AIへの指示のルールをCLAUDE.mdやスキルに書き出して、gitで版管理しています。チームの合言葉は「同じ指示を2回したらスキル化」です。頭の中にある判断基準は、書き出した瞬間に「見える負債」になって、直したり捨てたりできるようになる。本書の言う「光を当てる」は、こういうことなのかなと思いました。
本書の構成（全5章）
第1章：思考のリファクタリング
「すべてのバグは、思考の中にある」という節から始まります。不確実性とは何か、どこから生まれるのかを整理したうえで、論理的思考・仮説思考・システム思考という3つの考え方を扱います。
論理的思考の盲点として、人は事実を正しく認知できないこと（認知の歪みや認知的不協和）にも踏み込むのが本書らしいところです。「部分だけしか見ないことで対立が起こる」という節は、チームの対立を誰かのせいにする前に読みたい内容でした。「問題解決より問題発見のほうが難しい」という言葉が、章の中で形を変えて何度も出てきます。
第2章：メンタリングの技術
相手が自分で考えて動けるように支える技術としてのメンタリングです。「他者説得」から「自己説得」へ、「悩む」と「考える」の違い、傾聴・可視化・リフレーミング、心理的安全性の作り方と続きます。
「アットホームな会社」は心理的安全性が高いか、という問いかけも入っていて、仲が良いことと、安心して意見を言えることは別だと気づかされます。
第3章：アジャイルなチームの原理
アジャイルを「チームをメンタリングする技術」と位置づけ、その歴史をデミング博士のPDCAやトヨタ生産方式、知識経営までさかのぼって整理します。「アジャイルをするな、アジャイルになれ」という節の通り、手法の話より、チームがどういう状態を目指すのかの話として読める章です。アジャイルをめぐる5つの誤解も整理されています。
第4章：学習するチームと不確実性マネジメント
スケジュールの不安と、何を作るべきかというマーケットの不安を、どう減らしていくかを扱います。悲観的見積りと楽観的見積り、「計画でなく実績から予測する」、そしてスクラムを不安に向き合うフレームワークとして読み解きます。見積もりがいつもこじれるチームは、この章から読んでもいいと思います。
第5章：技術組織の力学とアーキテクチャ
組織全体の話です。何が技術組織の「生産性」を下げるのか、権限委譲とアカウンタビリティ、技術的負債の正体、取引コストと機能横断チーム、OKRによる目標の透明化、そして組織設計とアーキテクチャ（逆コンウェイ作戦、マイクロサービス）までを扱います。組織の形はシステムの形に表れるという視点は、エンジニアでない管理職にも役に立つはずです。
AI時代に読む『エンジニアリング組織論への招待』
AIは「環境の不確実性」を安くした
本書では、不確実性を減らすには情報を生み出すしかない、と繰り返し語られます。わからないことは、作って、試して、確かめるしかない。
AIで変わったのは、まさにここだと思います。試しに作ってみるコストが、ほとんどゼロになりました。以前なら数週間かけて確かめていた「これを作ったら使われるか」を、数日で形にして確かめられる。環境の不確実性を減らすための「試す」が、一気に安くなったわけです。
だからこそ、残るのはもう一つのほうです。
残るのは「コミュニケーションの不確実性」
作るのが速くなると、何が起きるか。私の部署では、アウトプットが一気に増えて、確認と承認が私のところに集まり、私自身がボトルネックになりました。
本書の言葉で言えば、組織の情報処理能力が、作る速さに追いつかなくなった状態です。何を作るか、どこまでできていればOKか、誰が決めるのか。そうした「人と人のあいだのわからなさ」は、AIがどれだけ速くなっても勝手には減りません。
さらにAIの時代には、人と人のあいだに、人とAIのあいだが加わります。AIに渡した前提があいまいなら、AIはそれらしいもので埋めてきます。AIは、こちらの思考の解像度をそのまま映す鏡だと思っています。うまく動かないとき、原因は出力より、こちらの判断基準があいまいなことのほうにある場合が多いんですよね。
自分メモ: 確認が自分に集まったとき、効いたのは「可逆・低影響のものは承認不要、不可逆・本番に関わるものは厳格に」という線を先に引くことでした。本書の権限委譲の段階と同じで、全部を同じ重さで確認しようとするから詰まる。どこまで任せるかを言葉にしておくことは、AIの時代にこそ重くなる管理職の仕事だと感じています。
組織の形は、AIの使われ方にも表れる
第5章のコンウェイの法則（組織の形がシステムの形に表れる）は、AIの導入にもそのまま当てはまると思います。
部署にAIを配ったとき、私はエンジニアと非エンジニアで入口（最初の設定）を分けました。同じ道具でも、仕事の流れが違えば、使われ方もつまずく場所も違うからです。組織の形を無視して一律に配ると、どこかで「使われない」が起きる。ツールの設計は、組織の設計とセットで考える。逆コンウェイ作戦の考え方は、AI導入の順番を考えるときにも役に立ちます。
「他者説得」から「自己説得」へ
AIを広げ始めたころの私は、「全員が使うべきだ」と思っていました。1on1でメンバーに「最近、AIの話ばかりされる」と言われて、自分の焦りが圧になっていたと気づいたことがあります。
本書の第2章にある「他者説得」から「自己説得」へという考え方を読んで、あのとき足りなかったのはこれだったと思いました。人は、説得されて動くより、自分で納得したときに動く。だから今は、使用率で見るのをやめて成果で見るようにしています。使っていない人を責めるより、「何が使いにくいのか」を聞くほうが先です。
自分メモ: AIで作業が速くなるほど、管理職の仕事は「作る」から「わからなさを減らす」へ寄っていくと感じます。何を作るかを決める、どこまで任せるかを決める、相手が自分で納得できるように聞く。本書が8年前に書いていたことは、AIの時代のマネジメントの教科書としても、そのまま読めました。
こんな人におすすめ
- エンジニアリングマネージャーやテックリードになり、チームの生産性や育成に悩んでいる方
- 見積もりや技術的負債の議論が、いつもこじれてしまう職場の方
- 開発チームとどう話せばいいかわからない経営者・プロダクトマネージャーの方
- AIを導入したのに「作るのは速くなったのに楽にならない」と感じている管理職の方
- 『エンジニア育成現場の「失敗」集めてみた。』や『SCRUMMASTER THE BOOK』を読んで、その背景にある考え方を体系的に知りたくなった方
第1章は抽象度が高めなので、現場の悩みがはっきりしている方は、第4章（見積もり・スクラム）や第5章（技術的負債・組織設計）から読み始めてもいいと思います。
まとめ
本書の本質を一言にすると、こうなります。
組織の悩みの正体は、「わからなさ」である。
未来がわからない不安と、他人の考えがわからない不安。技術的負債も、見積もりのずれも、経営と現場のすれ違いも、この2つのどちらかに行き着く。誰かを責める前に、どのわからなさが残っているのかを見る。それだけで、打てる手がまったく変わってきます。
個人的な学びは、AIで「作る」が速くなるほど、残る不確実性は人と人のあいだに集まるということでした。作って試すのは安くなった。だからこそ、何を作るか、どこまで任せるか、相手がどう納得するかを設計する仕事の比重が上がっていく。
AIを使ったチームづくりを進める立場の人にこそ、手元に置いておきたい一冊です。
関連する書評
※この記事にはAmazonアソシエイトのリンクが含まれています。
