CTOのあたまの中

Transcript

1. 事業戦略 組織 システム CTO のあたまの中 事業とチームとシステムを、そろえ続ける人のはなし 読了目安 10 分 ／ 各ページ右上の小さな三つの丸は、そのページが「事業戦略・組織・システム」のどの話か を示します CONTENTS 1. CTO って何をする人？ 2. 三つの丸をそろえ続ける 3. 第1章 変わる速さが違う 4. 第2章 複雑さは掛け算 5. 第3章 作って終わりじゃない 6. 第4章 システムは変わり続ける 7. 第5章 チームの形 8. 第6章 CTO の計器盤 9. まとめ 10. 付録・出典 1 / 33
2. 2 序 CTO って、何をする人？ むかし、Microsoft の CTO だった人が「CTO とは何か？」と 聞かれてこう答えました。「知るか」。冗談ですが、半分は本当 です。CTO の仕事は会社によってまるで違い、「インフラの番 人」「未来を語る人」「外で技術を語る顔」「大きな絵を描く 人」の 4 タイプに分けています（Amazon の CTO、Werner Vogels）。 だからこの絵本では、いろいろな CTO に共通する芯の部分だ けを取り出して、こう呼ぶことにします。「事業とチームとシ ステムをそろえ続ける人」。 インフラの番人 未来を語る人 外で語る顔 大きな絵を描く人 動かし続ける 次の技術を選ぶ 採用・信頼・発信 戦略と技術をつなぐ Werner Vogels（Amazon CTO）が紹介した 4 分類をもとに作図 ここがポイント：どのタイプでも、やっていることの芯は同じです。「事業がどこへ行きたいか」と「今のチームとシステムで行けるか」のズレを、ずっと 直し続けています。 2 / 33
3. 3 序 三つの丸を、そろえ続ける 会社には三つの丸があります。事業戦略（どこへ行きたい か）、組織（誰が、どんなチームでやるか）、システム（何を使 って、どう動かすか）。 この三つは互いに引っ張り合っていて、どれか一つが動くと他 の二つもズレます。ズレたままにしておくと、「やりたいのに できない」「作ったのに使われない」が起きます。CTO は、こ の三つの重なりを大きく保ち続ける係です。 ズレるとどうなる？ 事業戦略 組織 CTO 重なりを保つ システム 戦略 ⇄ 組織：やりたいのに人がいない 戦略 ⇄ システム：やりたいのに作れない 組織 ⇄ システム：作ったのに動かせない 三つ全部が重なる場所を 広げ続けるのが CTO の仕事 3 / 33
4. 4 第1章 変わる速さが違う 事業戦略は、天気のように変わる お客さんの好みが変わる、強いライバルが現れる、新しい法律 ができる。会社の「行きたい方向」が半年ごとに変わるのは、 失敗ではなく自然なことです。良い会社ほど、まわりの変化に 合わせて素早く進路を変えます。 問題は、進路を変えるたびに、チームとシステムがついてこら れるかどうかです。 目指す方向 新技術 法改正 新市場へ 大口顧客 ライバル出現 時間 方向が変わる点（橙）は「事件」ではなく、会社が生きている証拠 4 / 33
5. 5 第1章 変わる速さが違う 組織は明日変えられる。システムは一晩では変えられない 教室の席替えは一晩でできます。でも校舎の間取りを変えるの は、設計して、工事して、何か月もかかります。会社も同じで す。組織は「席替え」で、翌日には新しいチームで動き出せま す。システムは「校舎」で、壁を動かすには時間もお金もかか ります。 戦略は天気のように変わり、組織はすぐ追いつけるのに、シス テムだけが遅れる。これが CTO の悩みの出発点です。 戦略 組織 会議 1 回で決まる 辞令 1 枚で翌日から システム 設計・工事・引っ越し … 何か月も 変えるのにかかる時間 → 5 / 33
6. 6 第1章 変わる速さが違う だから CTO は先読みして、道路を広げておく 人口が増えてから道路を広げようとすると、工事のあいだずっ と渋滞します。良い都市計画は「5 年後にこのあたりに人が増 える」と読んで、先に太い道を通しておきます。 CTO も同じです。今の戦略だけでなく、「次に会社が行きそう な方向」を読んで、そこへ伸びやすいシステムの骨組み（アー キテクチャ）を先に用意します。すべてを当てる必要はありま せん。「どちらに転んでも困らない形」を選ぶのがコツです。 今 5 年後（先読み） まだ空き地 だから CTO は：戦略の「次の一手」を経営と一緒に読み、どちらに転んでも困らないアーキテクチャを先に選んでおく。 太い道を先に通しておいたので渋滞しない 6 / 33
7. 7 第2章 複雑さは掛け算 人は足し算で増える。複雑さは掛け算で増える チームに人を入れるのは、1 人ずつです。10 人が 20 人になる には、10 人ぶんの採用がいります。ところがシステムのやや こしさは、機能を足すたびに掛け算で増えていきます。「動く ソフトウェアは、手入れをしない限りどんどん複雑になる」と いうのは、50 年前から知られている法則です。 足し算で増える人手で、掛け算で増える複雑さに向き合う。放 っておけば必ず負けます。だから CTO は、複雑さの増え方そ のものを抑える工夫をします。 大きさ ↑ 複雑さ（掛け算） 人の数（足し算） ここまでは同じに見える 機能の数 → Lehman の「複雑性増大の法則」のイメージ。手入れをしないと橙の線になる 7 / 33
8. 8 第2章 複雑さは掛け算 部品がつながると、線の数が爆発する なぜ掛け算なのでしょう。部品が 3 個なら、部品同士のつなが り（線）は 3 本です。5 個なら 10 本、10 個なら 45 本。部品 が 3 倍になっただけで、線は 15 倍になります。線の数は、部 品の数の 2 乗に近い勢いで増えるのです。 ややこしさの正体は、部品の数ではなく線の数です。線が多い ほど、一か所を直したときに「あれ、こっちも壊れた」が起き やすくなります。 部品 3 個 線3本 部品 5 個 線 10 本 線の数 = 部品 × (部品 − 1) ÷ 2。部品が増えるほど、線は一気に増える 部品 10 個 線 45 本 8 / 33
9. 9 第2章 複雑さは掛け算 共通パーツがあれば、変更は 1 回で済む ここが CTO の腕の見せどころです。線の数を減らす方法があ ります。共通の部品（規格）を作ることです。エンジニアの言 葉では、共通モジュールを切り出す、インターフェースを統一 する、部品同士を疎結合にする、と言います。家じゅうのコン セントが同じ規格なら、新しい家電は 1 種類のプラグで済み ます。もし部屋ごとに形が違ったら、家電を替えるたびに全部 屋を直すことになります。 変更が 1 か所で済むなら、複雑さは足し算のまま。1 つの変更 で何か所も直すなら、複雑さは掛け算になります。システムの 骨組み（アーキテクチャ）を変えるとは、この「1 回で済む 形」に組み替えることです。 共通パーツあり：変更は 1 回 共通部品 機能A 機能B バラバラ：変更が芋づる式 1 2 3 1 機能C 直すのは 1 か所。全機能に反映される 機能D 機能A 機能B 機能C 4 機能D 同じ変更を 4 か所で。壊しやすく、抜け漏れも出る 9 / 33
10. 10 第2章 複雑さは掛け算 放置した複雑さは、利息のつく借金 急いでいるとき、「とりあえず動く形」で作ることがありま す。これは悪いことではありません。借金と同じで、うまく使 えば早くゴールにたどり着けます。 ただし借金には利息がつきます。技術的負債と呼ばれるこの借 金は、返さずにいると「次の変更にかかる時間」という形で 利息が膨らみます。CTO は、借金の残高を見ながら「今は借 りる」「今は返す」を決めています。 この言葉を作った Ward Cunningham の本来の意味は、「作っ たときの理解」と「今の理解」のズレのことです。作った後に 分かったことをコードに反映しないままにすると、ズレが借金 として残ります。 次の変更にかかる時間 ↑ 借りる 作り直し・整理で返済 利息が膨らむ だから CTO は：複雑さの増え方を測り、共通パーツへの組み替え（借金の返済）に使う時間を、あらかじめ確保する。 限界 返した 時間 → 10 / 33
11. 11 第3章 作って終わりじゃない 営業は契約でゴール。システムは、そこがスタート 営業の仕事は、契約が取れたらひとつの区切りです。もちろん 関係は続きますが、「その案件」はいったん完了します。 システムは違います。完成して動き始めた日から、動かし続け る仕事が始まります。止まったら直す、増えたユーザーに耐え る、新しい法律に合わせる。作ったものは、使われている限り ずっと面倒を見なければなりません。 営業 システム 契約！ この案件は完了 完成！ 障害対応 増強 法対応 更新 ここからが本番。使われている限り続く 時間 → 11 / 33
12. 12 第3章 作って終わりじゃない 一生にかかるお金の 6〜8 割は、「作った後」 ソフトウェアが生まれてから引退するまでにかかるお金のう ち、最初に作る分はほんの一部です。技術者の団体である IEEE は、生涯コストの 60〜80% が保守だとしています。研究 者によっては 90% 以上という報告もあります。 「作るのにいくら？」だけで判断すると、氷山の見えている部 分しか見ていないことになります。CTO は水面の下も含めて 見積もります。 見えている部分 作る 見えていない部分 動かし続ける 生涯コストの 60〜80% 出典：IEEE Computer Society（保守が生涯コストの 60〜80%） 12 / 33
13. 13 第3章 作って終わりじゃない 人は、だんだん「守る側」に取られていく 会社ができたばかりのころ、エンジニアは全員が新しいもの を作っています。ところが作ったものが増えるにつれ、「動か し続ける」ために人が必要になります。数年たつと、気づけば 半分以上が保守に回っている、ということが普通に起こりま す。 人数は同じでも、新しいものを作れる力は年々減っていく。こ の静かな目減りを見落とすと、「昔はもっと速かったのに」と なります。 エンジニアの人数 ↑ 全体は増えているのに… 新しく作る 1年目 動かし続ける 3年目 年数5年目 → 人数（全体の高さ）は増えても、「新しく作る」帯（青）は薄くなっていく 13 / 33
14. 14 第3章 作って終わりじゃない 会社の IT 予算は、平均 66% が「店を開け続けるため」 調査会社 Gartner は、IT のお金を三つに分けて見ます。Run （今のものを動かし続ける）、Grow（今の事業を伸ばす）、 Transform（新しい事業に賭ける）。お店にたとえると、今の 店を開け続ける費用（家賃・光熱費・修繕）、今の店を大きく する費用（品揃え・広告）、新しい店を出す費用、の三つで す。 平均的な会社は、予算の 66% を Run、つまり「今の店を開け 続ける費用」に使っています。理想は半々と言われますが、そ こに近づけるのは簡単ではありません。CTO はこの配分を毎 年にらんでいます。 Run 66% が Run（平均） 今の店を開け続ける … 66% Grow 今の店を大きくする Transform 新しい店を出す Grow / Transform の内訳は会社により異なるため図は例示 出典：Gartner「Run, Grow and Transform the Business」平均 Run 66% 14 / 33
15. 15 第3章 作って終わりじゃない 遠くを目指すなら、守る人以上に投資する 事業戦略が「今できていること」のすぐ隣を目指すなら、今 の人数で少しずつ進めば足ります。でも、戦略が今の提供価値 よりずっと遠くを目指しているなら、守るだけで手一杯の組織 では絶対に届きません。 だから CTO は経営に言います。「保守に取られる人数を差し引 いて、なお前に進める人数が要ります」。天秤の左に守る重 さ、右に投資。右が重くならないと、船は前に進みません。 戦略が目指す場所 守る 保守・運用 投資 目標 新規・改善 今の提供価値 右（投資）が重いときだけ、前に進める だから CTO は：保守に取られる人数を数字で示し、戦略が目指す遠さに見合う投資を経営に求める。 遠いほど、右の箱を重くする 15 / 33
16. 16 第4章 システムは変わり続ける お客さんの数が変わると、合う店の形も変わる 屋台は 1 人で切り盛りできて、身軽です。でもお客さんが増え たら、屋台を 10 台並べるより路面店を構えたほうがうまくい きます。さらに増えれば、路面店を大きくするより、チェーン 店として店ごとに役割を分けたほうが回ります。 システムも同じです。ユーザーが 100 人のときの最適な形 と、100 万人のときの最適な形は違います。小さいうちの形を 無理に使い続けると動けなくなり、最初から巨大な形で作ると 重くて進めません。CTO は「今の大きさに合う形」を選び、 大きくなったら作り替える、ということを何度も繰り返しま す。 作り替え 屋台 ユーザー 100 人 1 台で十分（モノリス） 作り替え 路面店 1 万人 役割ごとに分ける（サービス分割） チェーン店 100 万人 チームごとに所有する形 16 / 33
17. 17 第4章 システムは変わり続ける 作り替えは一気にではなく、板を一枚ずつ 古い言い伝えに「テセウスの船」があります。港に飾られた英 雄の船は、朽ちた板を一枚ずつ新しい板に替え続け、何十年か のちには元の板が一枚も残っていなかった。それでも人々はそ れを同じ船と呼び、船は一度も港を離れずに済んだ、という話 です。 システムの作り替えも同じです。全部を一度に新しくして何か 月も止めるのではなく、動かし続けたまま、部分ごとに順番に 置き換える。お客さんは変化に気づかないまま、気づけば船は 新しくなっています。 1 年目 5 年目 新しい板は 1 枚 ほぼ新しい板。船は一度も止まっていない 緑＝新しい部分。動かしたまま少しずつ置き換える（Strangler Fig パターンとも呼ばれる） 17 / 33
18. 18 第4章 システムは変わり続ける システムは、他人が作った土台の上に立っている 自分たちで書いたプログラムは、じつはシステム全体のほんの 一部です。その下には、世界中の人が無料で公開しているソフ トウェア（OSS）があり、さらにその下に OS、さらにその下 にコンピュータ本体やクラウドがあります。 つまりシステムとは、何段もの「他人の土台」の上に建てた小 さな家です。エンジニアはこの土台を「依存関係 （dependencies）」と呼びます。土台が変われば、家も影響を 受けます。 自分たちのコード 自分で 決められる OSS（世界中の人が作った部品） OS・ミドルウェア ハードウェア・クラウド 下の層ほど、自分たちでは決められない 決められない 18 / 33
19. 19 第4章 システムは変わり続ける 土台は毎年更新される。止まると使えなくなる 手元の iPhone を思い出してください。iOS は毎年新しくな り、アプリも新しい iOS に合わせて作り直されます。古い iPhone を更新せずに使い続けると、ある日「このアプリは新 しい iOS が必要です」と言われ、銀行アプリや LINE が動かな くなります。安全上の穴も直されなくなります。 会社のシステムも同じです。OSS も OS もクラウドも毎年更新 され、古い版はやがてサポートが終わります（EOL、End of Life）。更新を止めた瞬間から、動いていたものが少しずつ使 えなくなっていく。CTO は、この更新の時間をあらかじめ計 画に組み込みます。 iOS 16 iOS 17 iOS 18 iOS 19 iOS 20 土台（iOS）は毎年更新される → iOS 16 のまま 更新を止めた iPhone ・銀行アプリ「iOS 18 以上が必要です」 ・LINE の新機能が使えない ・安全上の穴が直されない iOS 20 最新 更新し続けた iPhone ・アプリが全部動く ・安全な状態が保たれる ・毎年少しの手間で済む 会社のシステムでは iOS の代わりに OSS・OS・クラウドが毎年更新される 19 / 33
20. 20 第4章 システムは変わり続ける 抽象化が進むと、同じものを小さく作れる 土台が進化するのは、面倒なだけではありません。大きな恵み でもあります。昔は自分でサーバーを買って並べていた仕事 を、今はクラウドが引き受けてくれます。さらに「サーバーの ことを一切考えなくていい」仕組み（サーバーレス）まで登場 しました。 難しい部分が土台に吸い込まれる（抽象化）と、同じサービス をずっと少ない人数で作れます。従業員 55 人の会社が、数十 億人が使うメッセージアプリを動かし、190 億ドルで買収され た例は有名です。 2000 年ごろ 自分でサーバーを買い、並べ、守る クラウド時代 サーバーは借りる サーバーレス・AI 土台（マネージドサービス）がほぼ全部やってくれる 同じサービスを作るのに必要な人手（イメージ）→ WhatsApp は従業員 55 人で数十億ユーザーを支え、190 億ドルで Facebook に買収された 20 / 33
21. 21 第4章 システムは変わり続ける だから、小さな新製品が大きな製品を置き換える ここに大きな会社の落とし穴があります。大きな製品は機能が 多く、お客さんの要望に応え続けます。一方、新しい土台の上 に生まれた小さな製品は、最初は機能が少なく、性能も劣り ます。「あんなおもちゃ、うちの客は求めていない」と正しく 判断します。 ところが小さな製品は新しい土台の力で猛スピードで成長 し、ある日、お客さんが必要とする水準を追い越します。正し い判断をし続けた大企業が負ける。これが「イノベーターの ジレンマ」です。CTO は、自分たちが追い越される側になら ないよう、新しい土台の芽を見張っています。 性能・機能 ↑ 大きな製品 お客さんが必要とする水準（点線） ここで追い越す 小さな新製品 時間 → Clayton Christensen『イノベーターのジレンマ』の図式より 21 / 33
22. 22 第4章 システムは変わり続ける だからシステムは、建物ではなく庭 規模で形が変わり、土台も動く。建物は完成したら、しばらく 放っておいても形は変わりません。でもシステムは庭に近い、 と昔から言われています。植えたとおりに育つ木もあれば、枯 れる木もある。放っておけば雑草が生え、伸びすぎた枝が日を 遮ります。 庭は「完成」しません。季節ごとに手入れをし、育ちすぎたら 剪定し、合わなくなった木は植え替える。CTO は庭師の親方 のように、どこに手を入れるかを決め続けます。 手入れを続けた庭 放置した庭 木の間隔が保たれ、光が届く 絡み合って、どれを切ればいいか分からない 『達人プログラマー』の「ソフトウェアは建築ではなくガーデニング」の比喩より だから CTO は：規模の変化と土台の更新を先読みし、作り替えと更新を「予定」として計画に入れる。 22 / 33
23. 23 第5章 チームの形 チームの形が、そのままシステムの形になる 不思議な法則があります。「システムの形は、それを作った組 織の形に似る」（コンウェイの法則）。3 つのチームで作れば、 システムも 3 つの塊になり、チーム同士の仲が悪ければ、塊同 士のつなぎ目もぎこちなくなります。 これを逆手に取ることもできます。「こういうシステムにした い」と決めてから、それに合う形にチームを組み替える。組織 は明日変えられるので、組織を先に変えてシステムを引っ張る のは、CTO の強力な手のひとつです。 チームの形 A班 できあがるシステムの形 C班 B班 A C B チームのつながり方が、そのままシステムのつなぎ目になる（コンウェイの法則） 23 / 33
24. 24 第5章 チームの形 チームには、4 つの形がある 組織が大きくなると、全員が同じ種類の仕事をするわけにはい きません。よく使われる分け方が 4 つあります。 ストリームアラインドチーム：お客さんに届く価値を、端 から端まで担当する主役のチーム プラットフォームチーム：主役たちが共通で使う道具や土 台を整える裏方チーム イネイブリングチーム：新しい技術を主役チームに教えて 回るコーチ コンプリケイテッド・サブシステムチーム：特別に難しい 部品だけを専門に受け持つ職人 ストリーム A お客さんへ届ける ストリーム B お客さんへ届ける ストリーム C お客さんへ届ける イネイブ コーチ サブシステム ↑ 主役 職人 プラットフォームチーム 共通の道具・土台を整える Team Topologies（Skelton & Pais）の 4 チームタイプ 24 / 33
25. 25 第5章 チームの形 シニアエンジニアにも、4 つのタイプがある ベテランのエンジニアも、得意な役目が分かれます。よく知ら れた 4 タイプです。 テックリード：1 つのチームの舵取り役。同じ仲間と長く走 る アーキテクト：街全体の設計図を描く人。どの技術をどう 組むかを決める ソルバー：こじれた難問の火消し役。解けるまで深く潜る 右腕：経営者の分身として、大きな組織を動かす テックリード チームの舵取り 同じ仲間と長く アーキテクト 街全体の設計図 技術の組み方を決める ソルバー 難問の火消し役 解けるまで深く潜る 右腕 経営者の分身 大きな組織を動かす Will Larson『Staff Engineer』の 4 アーキタイプ 25 / 33
26. 26 第5章 チームの形 小さいうちは何でも屋、大きくなると専門家 会社が小さいうちは、画面からサーバーまで一人で見られる 「何でも屋」のエンジニアがいちばん活躍します。チームの形 も 1 つで足ります。 システムが複雑になるにつれ、「この難しい部品だけの職人」 や「社内向けの道具を作る裏方」が必要になります。エンジニ アがおよそ 100 人を超えるとアーキテクトが、1000 人を超え ると右腕が自然に生まれるという観察もあります。CTO は、 今の大きさに合わせて「どんな人を、どこに置くか」を組み替 え続けます。 何でも屋 チーム 1 つ テックリード 主役チームが複数に アーキテクト プラットフォーム 職人チーム 右腕 コーチ・専門部隊 〜10 人 〜100 人 〜1000 人 それ以上 必要な人材と組織の形は、規模とともに変わる（Larson の観察をもとに作図） 26 / 33
27. 27 第5章 チームの形 良いチームを組める力そのものが、競争力になる 製品の機能は、お金と時間をかければ真似できます。でも「こ の規模でこの形のチームを組み、この人をここに置く」という 組織を組み立てる力は、外から見えにくく、真似しにくい。 だから、システムと組織をうまく組み合わせられること自体 が、事業戦略の武器になります。CTO は技術の責任者である と同時に、この「積み木の組み方」の責任者でもあります。 同じ積み木でも 組み方で城になる ただ並べただけ 真似しにくい強さ だから CTO は：今の規模に合うチームの形と人の配置を決める。必要なら組織を先に変えて、システムを引っ張る。 27 / 33
28. 28 第6章 CTO の計器盤 CTO が毎日見ている、3 つのメーター 飛行機のパイロットが計器を見るように、CTO も数字を見て います。大きく 3 つです。 投資の量：組織とシステムに、どれくらいお金と人をかけ ているか（Run と Grow のバランス） システムの健全さ：どれくらいの頻度で安全に変更できて いるか（DORA の 4 指標：デプロイ頻度・リードタイム・ 変更失敗率・復旧時間）。それに加えて、壊れずに動き続け ているか、安全上の穴が残っていないか（稼働率・障害件 数・脆弱性） エンジニアの生産性：忙しそうかではなく、価値が出てい るか、気持ちよく働けているか（SPACE）。人が辞めていな いか、採用できているかも含めて見る 投資の量 Run / Grow の配分 システムの健全さ 生産性 DORA の 4 指標 SPACE（成果・満足・流れ） ＋ 稼働率・障害・脆弱性 ＋ 離職・採用 健全さは DORA と SRE（SLO）、生産性は SPACE の考え方をもとに、信頼性・安全・人の指標をまとめて読んでいる 28 / 33
29. 29 第6章 CTO の計器盤 レガシーの、5 つの症状 古くなって手に負えなくなったシステムを「レガシー」と呼び ます。人間の体調と同じで、症状が出ます。 変更するたびに、よく壊れる（変更失敗率が高い） 新しい機能が、いつまでたっても出ない エンジニアが辞めていく セキュリティの穴が、次々見つかる お客さんからの不具合報告が、止まらない 調査では、優れたチーム（DORA の区分で「エリート」）の変 更失敗率は約 5%、苦しんでいるチーム（「ロー」）は約 40% という報告があります。同じ「変更」なのに、失敗する確率が 8 倍違うのです。 変更するとよく壊れる 新機能が出ない エンジニアが辞める 脆弱性が次々に 不具合報告が止まらない 症状チェック 変更失敗率 エリート 約 5% ロー 約 40% 出典：DORA 2024 年報告の引用（getDX 解説記事） 29 / 33
30. 30 第6章 CTO の計器盤 作り直すか、直し続けるか 症状が重いと、「いっそ全部作り直そう」という話になりま す。これは CTO にとって、もっとも重い判断のひとつです。 作り直しには有名な警告があります。「古いコードには、直さ れた無数のバグという経験が詰まっている。ゼロから書くと、 その経験を全部捨てて、ライバルに 2〜3 年の猶予をプレゼン トすることになる」。実際、ゼロから作り直して市場を失った 有名ブラウザの例があります。 一方で、少しずつ置き換える「テセウスの船」のやり方なら、 動かし続けながら新しくできます。CTO は症状の重さ、事業 の急ぎ具合、チームの体力を見て、どちらの道を選ぶかを決め ます。 全面書き直し（リライト） 速く見えるが、経験を捨てる。数年止まる危険 レガシー 症状・急ぎ・体力で決める 段階的に置き換え（テセウスの船） 動かしたまま、板を一枚ずつ新しく。遅いが確実 Joel Spolsky「Things You Should Never Do」と、その反論（段階的置き換え）の両論 だから CTO は：3 つのメーターを見続け、症状が出たら「直し続ける」か「作り替える」かを決める。 30 / 33
31. 31 まとめ 三つの丸を、そろえ続ける もう一度、最初の絵に戻ります。CTO の仕事は、事業戦略と 組織とシステムの重なりを大きく保ち続けることでした。 難しいのは、三つがそれぞれ勝手に動くからです。戦略は天気 のように変わり、システムの複雑さは掛け算で増え、土台は毎 日更新される。だから一度そろえても、すぐにズレます。 屋台が路面店になり、チェーン店になるように、CTO は会社 の大きさと向かう先に合わせて、システムとチームの形を替え 続けます。終わりのない仕事ですが、だからこそ、会社が遠く まで行けるのです。 戦略は変わる 事業戦略 複雑さは増える 土台は動く ここがポイント：「作って終わり」でないのは大変ですが、形を替え続けられるからこそ、会社は大きくなれます。 組織 CTO だから、 そろえ続ける システム 31 / 33
32. 32 付録 付録：CTO の仕事は、ほかにもある ここまでは「三つの丸をそろえる」という芯の話でした。実際 の CTO は、その芯のまわりに、いくつもの仕事を抱えていま す。 セキュリティと信頼性：事故が起きないよう、起きても止 まらないよう、最後の責任を持つ 採用と育成：良いエンジニアを集め、育て、辞めない環境 を作る 技術の発信：外に技術力を示して、採用・信頼・資金につ なげる コスト管理：クラウド代や外部サービス代を、効果と見合 わせて管理する 経営との通訳：技術の現実を、経営が判断できる言葉（投 資と効果、リスク）に翻訳する セキュリティ 経営との通訳 三つの丸を そろえる コスト管理 採用・育成 技術の発信 32 / 33
33. 33 巻末 出典 本文中の数字と引用は、以下の資料によります（いずれも 2026-09-10 取得）。 Werner Vogels, "The Different CTO Roles," All Things Distributed — allthingsdistri buted.com（p.2 の 4 タイプ） Camille Fournier, "On the role of CTO" — camilletalk.com Melvin Conway のコンウェイの法則、および逆コンウェイ戦略（Forsgren, Humbl e, Kim『Accelerate』）（p.23） Manny Lehman, Laws of Software Evolution（複雑性増大の法則） — 解説 microse rvices.io（p.7） Frederick P. Brooks Jr., "No Silver Bullet"（『人月の神話』所収）（p.7〜10） Ward Cunningham の技術的負債 — Agile Alliance（p.10） IEEE Computer Society：保守が生涯コストの 60〜80% — 整理記事 ventionteams. com（p.12） Gartner, "Run, Grow and Transform the Business IT Spending" — gartner.com、 平均 Run 66% の記述は awecomm.com（p.14） テセウスの船とレガシー置き換え — understandlegacycode.com（p.17, 30） Andrew Hunt & David Thomas『達人プログラマー』のガーデニング比喩（p.22） "The Rise of Serverless Computing," Communications of the ACM — cacm.acm.or g、WhatsApp 55 人・190 億ドルの事例は Medium 記事（p.20） Clayton M. Christensen『イノベーターのジレンマ』（1997）（p.21） Matthew Skelton & Manuel Pais『Team Topologies』の 4 チームタイプ（p.24） Will Larson, "Staff Engineer's Archetypes" — lethain.com、staffeng.com（p.25, 2 6） DORA, "A history of DORA's software delivery metrics" — dora.dev、エリート約 5%／ロー約 40% の引用は getdx.com（p.28, 29） Nicole Forsgren et al., "The SPACE of Developer Productivity," ACM Queue（202 1）（p.28） Joel Spolsky, "Things You Should Never Do, Part I" — joelonsoftware.com、反論 の整理 neverrewrite.com（p.30） 数値は出典間で幅があるものがあります（保守コスト比率、DORA の失敗率区分など）。本文では出典の表記をそのまま使い、断定を避けています。 33 / 33