開発組織の戦略と変革に効く4冊

Posted at 2026-11-01

はじめに

テックリードになって半年ほど、自分は完全に行き詰まっていた。コードは書ける。設計レビューでも的を射た指摘ができる。それでもプロジェクトは前に進まなかった。

原因は後から分かった。四半期のロードマップに20個の項目が並んでいて、そのどれも落とせなかったからだ。「技術負債の返済」「監視の強化」「新機能の開発」「ドキュメント整備」。全部大事に見える。結果として全部が中途半端に進み、どれも終わらなかった。

もうひとつ詰まっていたのが合意形成だ。CI のパイプラインを整えてテストを書く文化に移したい、と自分は思っていた。技術的な障害はほとんどない。それでも半年経っても浸透しなかった。必要なのはツールの選定ではなく、なぜ今これをやるのかを周りと共有する段取りだった。

このあたりの壁は、設計の本やフレームワークの本には書いていない。自分が助けられたのは、戦略・プロダクト開発・組織変革・対話を扱う本だった。どれも海外では定番で、日本語版も出ている。

今回は4冊を、全体像から実践、そして日々の足場という順に並べて紹介する。

著者はUCLAアンダーソン経営大学院の教授で、戦略論の研究を数十年続けてきた人物だ。企業の戦略立案にも長く関わっている。

この本の前半は、ほぼ「悪い戦略」の解剖に費やされる。目標をただ並べたもの、威勢のいいスローガン、都合の悪い選択を回避したもの。どれも戦略の体裁をしているが中身がない。自分が書いていたロードマップは、この分類にほぼ全部当てはまっていた。

良い戦略の構造も明快に示される。何が起きているのかを見立てる診断、どう攻めるかの基本方針、そして矛盾しない具体的な行動。この3つが揃って初めて戦略と呼べる、という主張だ。

エンジニアにとって効くのは「てこ」の考え方だと思う。限られた工数をどこに集中させれば効果が跳ねるか。アーキテクチャの意思決定も結局これで、全方向に手を伸ばした設計は何も速くしない。

難点は事例が大企業や軍事寄りで、読み通すのに少し体力がいる点。最初は第1部だけ読んで、自分のロードマップを採点してみるのがいい。

こんな人に: やることリストが膨らみ続けて優先順位が決まらない人

著者は IMVU を創業した起業家で、シリコンバレーの開発現場から「リーン」の方法論をまとめ上げた。

中心にあるのは構築・計測・学習のループだ。作って終わりにせず、何を検証したかったのかを先に決める。この順番を守るだけで、無駄に作り込む量がはっきり減る。

MVP の扱いも誤解されやすいところを丁寧に押さえている。機能を削った劣化版を出すことではなく、仮説を確かめる最小の実験単位を設計することだ。自分はここを読んで、プロトタイプのスコープの決め方を変えた。

計測の話はエンジニアの仕事に直結する。虚栄の指標、つまり累計ユーザー数のように右肩上がりにしかならない数字を追うのをやめて、コホート単位で見る。これはログ設計やイベント定義をどう切るかという実装の問題になる。

事例が2010年代前半なので、今では当たり前になった部分もある。それでも「学習の単位をどう設計するか」という論点は古びていない。

こんな人に: 機能を出しているのに手応えが掴めないプロダクト開発者

著者はハーバード・ビジネス・スクールの教授で、組織変革の研究では最も参照される一人だ。

この本は変革を8段階のプロセスに分解する。危機感を共有する、推進チームを作る、ビジョンを示す、繰り返し伝える、障害を取り除く、短期的な成果を出す、勢いを維持する、文化に根付かせる。順番を飛ばすと失敗する、というのが主張の核だ。

自分に刺さったのは「短期的な成果を意図的に設計する」という話だった。モノリスの分割にしてもテスト整備にしても、成果が出るのは1年後だと説明している限り周囲の支持は続かない。3ヶ月で見える変化をどこに置くかを先に決めるべきだった。

CI/CD の導入やコードレビュー文化の定着が止まる理由は、ほとんど技術側にない。合意形成の段取りが抜けている。この本はその段取りを具体的に言語化してくれる。

記述はトップダウンの変革を前提にしている箇所が多い。チームリード層が読むなら、権限の大きさに合わせて縮小して解釈する必要がある。

こんな人に: 技術的な改善提案が組織に浸透せず止まっている人

著者は Thinking Environment という対話の手法を提唱した実践家で、30年以上にわたって思考を引き出す環境の研究を続けてきた。

主張はシンプルだ。人は遮られない環境で初めてまともに考えられる。だから聞き手の仕事は、助言することより先に、相手が考え切れる場を保つことにある。

具体的な作法も多い。相手が話し終わるまで口を挟まない。注意の質を保つ。質問は選択肢を狭めない形にする。どれも地味だが、1on1 や設計レビューでの効果はすぐ出る。

自分がこの本を読んでやめたのは、相手の話の途中で解決策をかぶせる癖だった。黙って最後まで聞くようにしたら、メンバーが自分で答えに辿り着く場面が増えた。障害のふりかえりでも、原因の掘り下げが深くなった。

ビジネス書らしい章立てではなく、エッセイに近い語り口なので、理論的な整理を期待すると物足りないかもしれない。実践の手引きとして読むのが合う。

こんな人に: 1on1 やふりかえりの質を上げたいリード・メンター

今の課題に合わせて1冊選ぶなら、こう考えるといい。

4冊とも実装の話はしていない。それでも、設計力だけでは越えられなかった壁を自分はこの順番で越えた。