はじめに
自分が初めてプレイヤー兼リードという立場になったとき、最初に壊れたのはコードではなく自分のスケジュールだった。設計レビューの合間に採用面接が入り、その隙間に「あの機能、来週には出せますよね」という確認が飛んでくる。手を動かしていれば進捗が出る世界から、人と合意を取らないと何も進まない世界に放り込まれた感覚があった。
困ったのは、参考になる情報の粒度だ。技術記事はアーキテクチャの話なら詳しいのに、組織をどう設計するかになると途端に抽象的な精神論になる。逆にマネジメント本を開くと、今度はソフトウェア開発の制約がまるで考慮されていない。レビューのリードタイムや技術的負債の返済計画みたいな、自分が毎日向き合っている変数が出てこない。
そこで読み方を変えた。組織やステークホルダーを、自分が普段扱っている分散システムと同じものとして見る。ノードがあり、レイテンシがあり、情報の伝播には遅延がある。合意形成はコンセンサスアルゴリズムで、期待値のズレは状態の不整合だ。この視点を持てる本だけを選んで読むようにしたら、急に実用的になった。
今回紹介するのは、エンジニアリング組織の設計と運用に直接効いた4冊である。いずれも日本では話題になりにくい。ただ、組織を仕組みとして捉える本が欲しいなら、国内で定番化している数冊よりも手応えがある。全体像をつかむ1冊から入り、組織文化の構造を深掘りし、変革の実行と日々の期待値調整まで降りていく順に並べた。
① The Engineering Executive's Primer: Impactful Technical Leadership — Will Larson
著者のWill LarsonはStripeやCalmでエンジニアリング組織を率いてきた人物で、技術リーダー向けの書き手としても知られている。前作にあたる『An Elegant Puzzle』や『Staff Engineer』を読んだことがあるなら、その延長線上にある本だと考えていい。
扱っているのはエンジニアリング組織を経営のレイヤーで動かすための実務だ。エンジニアリング戦略の書き方、組織構造の決め方、採用計画と予算の組み立て、経営陣への技術的な説明責任の果たし方。章ごとに独立したトピックになっていて、必要なところから読める構成になっている。
自分にとって一番効いたのはエンジニアリング戦略の章だった。戦略を「診断」と「方針」と「行動」に分けて書くという型が示されていて、これに従って自分のチームの技術方針を書き直したら、曖昧だった部分がはっきり見えた。移行計画の優先順位について、他部署と議論できる状態になったのが大きい。
注意点は、想定読者がかなり上のレイヤーに寄っていることだ。予算承認や取締役会の話が出てくるので、数人のチームをまとめ始めた段階だと使えない章も出てくる。その場合は組織設計と技術戦略の章だけ先に読むのが現実的だろう。
こんな人に: テックリードやEMから一段上の役割に進もうとしていて、技術判断を経営の言葉に翻訳する必要が出てきた人。
② Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization — Dave Logan, John King, Halee Fischer-Wright
著者らは組織文化の研究者とコンサルタントのチームで、2万人以上への調査をもとにこの本を書いている。文化を気分や雰囲気として語らず、観測可能な指標として扱っているのが特徴だ。
この本の中心にあるのは、組織文化を5つの段階に分けるモデルだ。判定材料になるのはメンバーが日常で使う言葉で、「どうせ無理」が支配的なステージ2、「自分は優秀だが周りが足を引っ張る」というステージ3、「我々ならできる」のステージ4という具合に整理されている。そして各段階から次へ上げるための具体的な介入方法が示される。
エンジニアリング組織で特に刺さるのがステージ3の記述だ。技術力の高い個人が集まっているのに、情報が共有されずレビューが属人化し、各自が自分の領域を守ってしまう状態。心当たりのある人は多いと思う。この本は、そこを抜けるには三者間の関係を意図的に作る必要があると説く。二人の関係に第三者を紹介してつなげていく、という地味な作業の積み重ねだ。
自分はこれを読んでから、ペアレビューを三人体制に変えたり、別チームのエンジニア同士を意図的に引き合わせたりするようになった。効果が出るまでに数ヶ月かかるが、知識のサイロが崩れていく感覚はあった。事例が米国企業寄りで冗長な箇所もあるので、段階の定義と移行方法の章を中心に読めば十分だ。
こんな人に: 個人の技術力は十分なのに、チームとしての成果が噛み合わない組織を預かっている人。
③ 企業変革の核心―「このままでいい」をどう打ち破るか — John P. Kotter
著者はハーバード・ビジネス・スクールで長く変革の研究をしてきたJohn P. Kotterである。変革の8段階プロセスで有名な人だが、この本はその第一段階である危機感の醸成だけを掘り下げた一冊だ。日本語で読めるのもありがたい。
主題は、変革が失敗する最大の原因が現状満足だという指摘にある。表面的には忙しく動いているのに、本質的な変化が起きない状態を著者は「偽りの危機感」と呼んで区別する。会議が増え、資料が増え、それでレガシーシステムの刷新が一歩も進まないというのは、技術組織でもよく見る風景だろう。
Kotterが示す処方は、データを並べて説得する方向ではない。実物を見せ、外部の声を直接届け、危機を可視化するアプローチを取る。本番障害の記録を経営会議でそのまま共有する、顧客からの問い合わせを開発チームに直接流す、といった動かし方がこれに当たる。
自分はこの本を読んで、技術的負債の説明方法を変えた。負債の総量をグラフで示すのをやめ、ある一つの修正にどれだけの工数と手戻りがかかったかを具体的に追跡して見せた。抽象的な数字より、個別の事実のほうが人は動く。逆に危機感を煽りすぎる副作用についても一章を割いているので、そこは併せて読んでおきたい。
こんな人に: 刷新や移行の必要性は共有されているのに、優先順位が上がらないまま時間が過ぎている組織にいる人。
④ Managing Expectations — Naomi Karten
著者のNaomi KartenはIT業界のコンサルタントとして、システム部門とユーザー部門の間に立ち続けてきた人だ。扱う題材がソフトウェア開発の現場そのものなので、エンジニアには読みやすい。
テーマは期待値のマネジメントに絞られている。要件が合意されたはずなのに完成物で揉める、スケジュールの認識が部署ごとにずれている、こうしたトラブルの発生源を分解していく。著者の立場は明確で、期待値のズレは相手の理解力の問題ではなく、こちらの伝達設計の問題だという。
面白いのは、情報を出さないことが期待値を悪化させるという指摘だ。進捗が思わしくないときに報告を控えると、相手は空白を自分に都合のいい想像で埋めてしまう。そして認識の差は時間とともに広がる。分散システムでハートビートを止めたらどうなるかを考えれば、納得しやすい話だと思う。
自分は見積もりの伝え方をこの本で改めた。単一の日付を出すのをやめ、前提条件と不確実性の幅を添えて渡す。前提が崩れた時点ですぐ再共有する。手間は増えたが、締め切り直前の交渉がほぼなくなった。刊行は古く、アジャイルという語もほとんど出てこないが、書かれている原則の寿命は長い。
こんな人に: 技術的には問題なく進んでいるのに、関係者との認識合わせで消耗している人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 全体像 | The Engineering Executive's Primer | 技術戦略と組織設計を経営の言葉で語る型 |
| 文化の診断 | Tribal Leadership | チームの状態を言語から判定する指標 |
| 変革の起動 | 企業変革の核心 | 現状満足を崩して優先順位を動かす手順 |
| 日々の運用 | Managing Expectations | 期待値のズレを早期に検知する伝達設計 |
今の課題に応じて1冊を選ぶなら、こんな基準になる。
- 技術判断を経営層に説明する場が増えてきた: The Engineering Executive's Primer
- 優秀なメンバーがいるのに協調が生まれない: Tribal Leadership
- リファクタや移行の必要性が理解されつつ着手されない: 企業変革の核心
- 納期や仕様の認識違いで何度も揉めている: Managing Expectations
4冊に共通しているのは、組織を感覚ではなく仕組みとして扱う姿勢だ。システム設計で培った思考がそのまま使える領域は、思っているより広い。