はじめに
Gene Kim の『The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data』を読みました。
前作『The Phoenix Project（フェニックスプロジェクト）』が「運用（Ops）側の視点」から書かれた小説だったのに対し、本作は同じ Parts Unlimited 社の同じ時間軸を、開発者（Dev）側の視点から描き直した姉妹編です。
面白いのは、著者自身が冒頭で「どちらから読んでも構わない」と明言している点です。実際、前作の登場人物は登場人物一覧に整理されており、前作を読んでいなくても物語としては完結しています。ただし、両方を読むと「同じ地獄を別の窓から覗いていた」という構造がはっきり見えるので、可能なら両方読む価値はあると感じました。
本記事では、ストーリーの筋よりも 「設計・アーキテクチャに関心のあるエンジニアが本書から何を持ち帰れるか」 に重点を置いてまとめます。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data |
| 邦題 | ユニコーン・プロジェクト |
| 著者 | Gene Kim |
| 出版 | IT Revolution Press |
| 位置づけ | 『The Phoenix Project』の姉妹編（同時間軸・開発者視点） |
| 形式 | 技術小説（ビジネスノベル） |
著者の Gene Kim は Tripwire の創業者で13年間 CTO を務めた人物であり、『The DevOps ハンドブック』『Accelerate』の共著者でもあります。つまり本書は、DevOps 系の理論書群を 物語という形で圧縮したもの と捉えるとわかりやすいです。
あらすじ（ネタバレは最小限に）
主人公は Maxine Chambers。開発リーダー兼アーキテクトで、社内製 MRP システムを長年育ててきた腕利きのエンジニアです。関数型プログラミングを好み、純粋関数と合成可能性を思考のツールとして重視するタイプとして描かれます。
物語は、彼女が休暇中に起きた 給与計算システムの障害 の責任を（不当に）押し付けられ、社内で最も炎上している「Phoenix プロジェクト」へ実質的な左遷を食らうところから始まります。
そこで彼女が最初に立てた目標は、驚くほどささやかなものでした。
「自分のノートPCで Phoenix をビルドできるようにする」
これだけです。ところが、これがどうしても達成できません。
- ビルドに必要な項目が100以上足りない
- 誰がそれを持っているのか誰も知らない
- ドキュメントは古いか欠落しており、知識は組織全体に散在している
- 必要なものを得るにはチケットを起票し、別部署の承認を待つ
- そのチケットを処理するために、また別のチケットが必要になる
彼女は「チケットが巨大な輪になって、作られては回され、終わりなく繰り返されている」と表現します。この 「ビルドできない」という一点の描写だけで、組織構造の病理をすべて説明してしまう のが本書の巧みなところです。
やがて彼女は、社内で非公式に問題を解決して回っていた QA マネージャー Kurt を中心とする集団 「反乱軍（The Rebellion）」 に誘われ、Dockside Bar を拠点に、組織のルールの外側から改善を進めていくことになります。
本書の中核：5つの理想（The Five Ideals）
本書のフレームワークが、謎めいた人物 Erik が語る「5つの理想」です。ここが技術者にとって最も持ち帰りやすい部分だと思います。
| # | 理想 | 原語 |
|---|---|---|
| 第一 | 局所性とシンプルさ | Locality and Simplicity |
| 第二 | 集中、フロー、そして喜び | Focus, Flow, and Joy |
| 第三 | 日常業務の改善 | Improvement of Daily Work |
| 第四 | 心理的安全性 | Psychological Safety |
| 第五 | 顧客重視 | Customer Focus |
以下、それぞれを技術的な文脈で読み解いていきます。
第一の理想：局所性とシンプルさ
「1つの変更を、1つのチームが、1つの場所で完結させられるか」 という問いです。
作中でMaxineは、延長保証という一見単純な機能を実装しようとして愕然とします。影響範囲を洗い出すと、6つのチームを巻き込む必要がある ことが判明するのです。彼女はこれを「この機能を出荷するには、トラック1台分のピザが必要になる」と皮肉ります（Amazonの「2枚のピザチーム」への当てこすりです）。
ここで登場する重要な語彙が complect（コンプレクト） です。Rich Hickey が復活させた古語で、「単純なものを絡み合わせて複雑にする」という意味です。
密結合で複雑なシステムでは、コードの1箇所を変更するのではなく、100箇所、1000箇所を変更しなければならない。しかも、ごく小さな変更がシステムの遠隔地に予測不可能な影響を及ぼす。
この理想が優れているのは、コードの設計と組織の設計を同じ言葉で語れる 点だと思います。Maxine が守り続けてきた MRP システムが称賛されるのは、コンポーネントが綿密に分離され、少人数のチームが互いに独立して働けるからでした。Conway の法則の裏返しであり、DDD の境界づけられたコンテキストの話でもあります。
作中では終盤、彼女が既存コードを関数型言語で書き直し、標準ライブラリと組み込みデータ型を使って 50行 まで縮めてみせる場面があります。これも第一の理想の実践例として描かれます。
第二の理想：集中、フロー、そして喜び
「日々の仕事がどう感じられるか」 に関する理想です。
作中で最も痛かったのは、Maxine が「自分の書いたコードがいつ顧客に届くか」を同僚に尋ねる場面です。
- 次のテストサイクルまで2週間
- 運用部門にチケットを起票してデプロイ待ちで3週間
- 合計 7週間
しかも QA は別のチケットシステムを使っており、開発者はアクセス権すら持っていません。2週間後にスプレッドシートで不具合リストが送られてくるのを待つだけです。
Maxine はこれを「私たちはただの機能工場で、顧客が気にするかどうかもわからないウィジェットを出荷しているだけだ」と表現します。フィードバックループが数週間単位に伸びた瞬間、学習は成立しなくなる という指摘です。
対比として描かれるのが、彼女が休日に中学生向けのイベントやオープンソースプロジェクトで、わずかな労力で機能を追加できた体験です。そこには集中とフローと喜びがありました。この落差が、彼女を動かす動機になります。
第三の理想：日常業務の改善
「日々の仕事そのものよりも、日々の仕事の改善を優先する」 という理想です。
Erik はトヨタのアンドンコードを引き、Steven Spear の言葉を紹介します。
すべての問題の母は無知であり、それを克服できるのは学習だけである。
そして第三の理想の対極にあるものとして、TWWADI（The Way We've Always Done It / 常に変わらぬやり方） を挙げます。
- 厳格なプロジェクト計画
- 柔軟性のない調達プロセス
- 強力なアーキテクチャレビュー委員会
- 不定期なリリーススケジュール
- 長い承認プロセス
- 厳格な職務分離
いずれも、災難が起きるたびに再発防止として1つずつ追加されてきたルール です。個々には正当な理由があります。しかし積み重なると、あらゆる作業の調整コストと遅延コストを押し上げ、意思決定の場所と作業の場所を引き離していきます。
Erik はここで W. Edwards Deming を引きます。
悪いシステムは必ず良い人に勝つ。
QA が開発から分離された経緯を語る場面が、これを象徴しています。「無謀な開発者からビジネスを守る」ために作られたルールが、毎年少しずつ増え、最終的に誰も何も動かせない状態を作り上げていた、という自己言及的な告白です。
第四の理想：心理的安全性
問題が起きたとき、「誰が」ではなく「何が」を問える環境 のことです。
Erik は Google の研究を引きつつ、恐怖の文化がどう機能するかを描写します。問題が起きると犯人を特定し、名前を公表し、非難し、新しいルールと承認と研修を増やし、必要なら「腐ったリンゴ」を排除して、問題を解決したと自分を欺く ―― 冒頭で Maxine が Phoenix に飛ばされた経緯そのものです。
John Allspaw の言葉も引かれます。
あらゆる出来事は学びの機会であり、私たちの同意なしに行われた計画外の投資である。
面白いのは、この理想が 製造業の物理的安全性と接続されている ことです。CEO の Steve は「安全は仕事の前提条件だ」と繰り返し、Alcoa の Paul O'Neill の事例（安全を最優先した15年間で純利益が2億ドルから15億ドルへ）が引用されます。心理的安全性を「ソフトな話」ではなく経営指標に接続する構成になっています。
第五の理想：顧客重視
「それは顧客が金を払うものか、それとも社内のサイロにとってだけ価値があるものか」 を容赦なく問う理想です。
終盤、コスト削減を迫られる場面で、この理想は コアとコンテキスト（Core and Context） の議論に接続されます。
- コア：顧客が対価を払い、投資家が報いる中核的な競争力
- コンテキスト：それ以外すべて。人事、給与、メール、社食のPOS ―― ミッションクリティカルであっても、顧客が金を払うものではない
Erik はここで、100年前の工場には自家発電を統括する CPO（最高電力責任者）がいた、という比喩を出します。当時それはコアでした。しかし電力は公益事業から買うインフラになり、その役職は消滅しました。
「十分ではない」ものは残し、「十分以上」のものはアウトソースする（Clayton Christensen）
作中では、この観点でホワイトボードにコンテキストが列挙されていきます。データセンター2つ、古い ERP、社食の POS、PBX、そして自分たちが手塩にかけて育てた CI クラスタまで。「重要だがコンテキストであるものに、最高のエンジニアを張り付けてはいけない」 という判断が下される場面は、なかなか厳しくも示唆的でした。
エンジニアとして刺さった技術的トピック
ビルドと開発環境は「最下層のプラットフォーム」
本書で繰り返し出てくる構造認識がこれです。
ビジネス側には機能やアプリが見える。だからそこには予算がつく。しかし、その下にあるアーキテクチャや、さらに下にある「開発者の生産性を支えるシステム」は見えない。
そして皮肉として、こう続きます。
大手IT企業は最も優秀なエンジニアを最下層に配置する。すべての開発者が恩恵を受けられるからだ。しかし Parts Unlimited では、最優秀のエンジニアが最上層の機能開発におり、開発生産性に取り組んでいるのはインターンだけだった。
プラットフォームエンジニアリングや Developer Experience が語られる現在の文脈を、2019年時点で物語として先取りしている部分だと思います。
マージ地獄の描写
第10章のコードマージの比喩が秀逸でした。
50人の脚本家が、主人公が誰かも結末も決まっていない脚本を、それぞれ数週間かけて個別に Word で書き、締切直前に一部屋に集まって1つの物語に統合しようとする。
Phoenix では100人の開発者が数週間マージせずに作業し、マージには最低3日かかる。統合すべき開発チケットは 392件。「マージ戦略室」なる部屋が存在する時点で異常なのですが、作中人物は誰もそれを異常と思っていません。
Maxine の主張は明快です。バッチサイズを小さくする。製造業と同じで、1日1回マージすれば大惨事は起きない。トランクベース開発の話を、比喩だけで納得させてしまう章です。
「空白のデプロイ」から始める
第13章、Data Hub チームが初めて本番デプロイに挑む場面が個人的なハイライトでした。
彼らはいきなりアプリコードを流すのではなく、HTMLや設定ファイルの末尾に空白を数行足しただけの「何も変わらない変更」 を本番に流します。
1回目：コンテナイメージに必要なファイルが欠けていて30分停止。
2回目：何も起きない。だが実は設定ミスでパイプライン全体が壊れていたと1時間後に判明。
つまり 「デプロイパイプラインそのものを最初のデプロイ対象にする」 という発想です。ここが失敗しても顧客影響はゼロで、学習だけが手に入ります。実務にそのまま持ち込める考え方だと思いました。
テストの並列化と、フレーキーテスト
第17章では、自動テストを増やした結果として新たなボトルネックが生まれます。
- テストが増えすぎて実行に数時間かかる
- 開発者が待ちたくないのでチェックインを避け始める
- さらに、一部のテストが断続的に失敗する
作中に、テストに落ちた開発者が同じテストを2回、3回と実行し、3回目でパスして満足する場面があります。Maxine はこれを「カジノのスロットマシン」と呼び、恥ずかしさと嫌悪を覚えます。
フレーキーテストがなぜ致命的かというと、テストの信号としての価値をゼロにするから です。改善の結果として新しい制約が生まれる、という制約理論的な展開も含めて、現実的な描写でした。
制約は移動する
本書は Data Hub チームの制約が移り変わる様子を丁寧に追いかけます。
- 環境が取得できない → 誰も環境をもらえない
- テストが制約になる → 全機能完成後にしかテストが始まらない
- デプロイが制約になる → 本番投入まで数週間待ち
- データが制約になる → データ定義がサイロごとに食い違う
1つ解決すると次が現れます。ボトルネックは消えるのではなく移動する、というのは TOC の基本ですが、物語で追体験すると納得感が違います。
イベントソーシングへの帰着
終盤、Data Hub（多数のシステムを結ぶポイントツーポイントなメッセージバス）を、イベントバスを中心としたアーキテクチャへ置き換える「Project Shamu」が立ち上がります。
Maxine の評価はこうです。
これは関数型プログラミングの原則を、小さなコードにではなく、企業全体の組織化とアーキテクチャ設計に適用したものだ。
第一の理想（局所性とシンプルさ）を、企業スケールで実装するとイベント駆動になる、という締め方です。ここは賛否が分かれそうですが、アーキテクチャ選択の理由を「トレンドだから」ではなく「局所性を回復するため」と説明している 点は好感が持てました。
なお彼らは終盤、Wardley Map を使ってバリューチェーンのどこがコモディティでどこが競争優位かを整理します。コア/コンテキストの議論を実務レベルに落とす手法として紹介されています。
3つの地平線（Three Horizons）
第16章以降、経営視点のフレームワークとして Geoffrey Moore の「3つの地平線」が導入されます。
| 地平線 | 内容 | 必要なもの |
|---|---|---|
| Horizon 1 | 確立された収益源。予測可能なドル箱事業 | プロセス、一貫性、ルール、コンプライアンス、官僚主義 |
| Horizon 2 | 立ち上がりつつある事業 | 事業構築者による拡大 |
| Horizon 3 | 実験段階のアイデア | スピード、実験、H1のルールを破る自由 |
Horizon 3 で問うべきは3つのリスクだと語られます。
- 市場リスク ― 顧客の真のニーズを解決するか
- 技術リスク ― 技術的に実現可能か
- ビジネスモデルリスク ― 財務的に成立する成長エンジンがあるか
1つでも「No」なら方向転換するか中止する。作中では社内から数百のアイデアを募り、上位30件をピッチさせ、3件に90日を与える、という形で実装されます。
エンジニアとして考えさせられたのは、Horizon 1 に最適化された組織能力（承認プロセス、変更管理、標準化）が、そのまま Horizon 3 を殺す という構造です。同じ会社の中に相反する2つの運営モードが必要になる。この矛盾を組織がどう抱えるかが、本書後半の主題になっています。
前作『The Phoenix Project』との違い
| The Phoenix Project | The Unicorn Project | |
|---|---|---|
| 主人公 | Bill Palmer（IT運用VP） | Maxine Chambers（開発リーダー／アーキテクト） |
| 視点 | Ops | Dev |
| フレームワーク | 3つの道（フロー / フィードバック / 継続的学習） | 5つの理想 |
| 中心テーマ | 業務の流れと制約理論 | 開発者生産性とアーキテクチャ |
| 時間軸 | 同一 | 同一 |
前作が「工場としてのIT」を扱ったのに対し、本作は「開発者が何に阻まれているか」を徹底的に描きます。したがって、コードを書く人ほど本作の方が痛みを共有しやすい と思います。
同じ事件（Phoenix のリリース障害）が両作で描かれるので、読み比べると「同じ現象が、立場によって全く違う物語に見える」という体験ができます。これ自体がサイロの本質を示していて面白いところです。
気になった点・批判的に読んだ部分
公平のために書いておくと、以下は割り引いて読んだ方が良いと感じました。
- 成功が出来過ぎている：ブラックフライデーの施策で追加3,500万ドル、といった数字が気持ちよく決まりすぎます。現実にはここまで綺麗に因果が特定できることは稀です。
- Erik が便利すぎる：バーテンダーの姿をした賢者が要所で正解を教えてくれる構造は、教育的である反面、都合が良すぎます。
- 悪役が単純：Sarah というアンチパターンの塊のような人物が対立軸を担いますが、実際の組織的抵抗はもっと「善意の人による正当な懸念」の形を取ることが多いはずです。
- 「反乱軍」の美化：ルールを破って成果を出す集団が正義として描かれますが、これをそのまま真似すると単なる統制不能になり得ます。作中でも Kurt が停職処分を受ける場面があり、そのリスクは示唆されてはいます。
そのうえで、フレームワーク（5つの理想 / コアとコンテキスト / 3つの地平線）は独立して有用 なので、物語の都合の良さと切り離して使えると思います。
こういう人におすすめ
-
アーキテクチャの話を、経営やビジネスの言葉で説明する必要がある人
「疎結合にしたい」を「変更の局所性がないので調整コストが指数的に増えている」と言い換える語彙が手に入ります。 -
技術的負債の返済を上に説明できずに困っている人
「複雑性負債」「TWWADI」「コアとコンテキスト」は説得の道具になります。 -
CI/CD やプラットフォーム整備の価値を言語化したい人
開発者生産性が最下層のプラットフォームである、という構造認識が得られます。 -
『The Phoenix Project』を読んで面白かったが、開発者としては物足りなかった人
こちらの方が確実に刺さります。
逆に、具体的なツールの導入手順や設定例を求める人には向きません。本書は原理と態度の本であり、実装の本ではありません。そちらは『The DevOps ハンドブック』『Continuous Delivery』『Accelerate』などが担当します。
まとめ
本書を読んで一番残ったのは、Maxine の最初の目標が最後まで一貫していたことです。
「自分のノートPCでビルドできるようにしたい」
このあまりにささやかな願いが達成できない理由を掘っていくと、アーキテクチャの結合度に行き着き、組織構造に行き着き、承認プロセスの歴史に行き着き、最終的には「安全に失敗できない文化」に行き着きます。
5つの理想は、いずれも 「変更を安全かつ小さく、局所的に行えるか」 という一点に収束していると読めます。
- 局所性とシンプルさ ＝ 変更を1箇所で完結させる
- 集中、フロー、喜び ＝ 変更の結果をすぐ知る
- 日常業務の改善 ＝ 変更しやすさ自体を改善対象にする
- 心理的安全性 ＝ 失敗しても罰されない
- 顧客重視 ＝ そもそもその変更に意味があるか問う
技術書として読むと物足りない部分もありますが、「なぜこの設計にするのか」を自分以外の人に説明するための語彙集 としては、かなり実用的な一冊でした。
ここまで読んでいただき、ありがとうございました。
参考
- Gene Kim ほか『The Phoenix Project』（IT Revolution Press, 2013）
- Gene Kim ほか『The DevOps ハンドブック』（2016）
- Nicole Forsgren ほか『Accelerate』（2018）
- Jez Humble / David Farley『Continuous Delivery』（2010）
- Geoffrey Moore『Zone to Win』（4つのゾーン / 3つの地平線）