はじめに
テストが走っている。グリーンのバーがじりじり伸びていく。深夜1時。コーヒーはとっくに冷めている。キーボードに手を置いたまま、画面を眺めていた。
「方法を学べ」で、方法を増やすことの価値を書いた。方法の知識が課題認識を広げる。「方法を選べ」で、選ぶことの価値を書いた。学んだだけでは動けない。責任を持って選ぶことで、初めて前に進める。「方法を選べ」で触れた「情報信仰」、つまりもっと調べれば正しく選べるという嘘の先に、もう1つの嘘がある。「前に正解したから、今回も正解だ」。2本書いた。書いて、少し楽になった気がした。気がしただけかもしれない。
今日は、その先を書く。選んだ後に来るもの。書こうとして、手が止まった。捨てることについて書くのは、学ぶことや選ぶことより難しい。たぶん、自分がまだ捨てきれていないからだと思う。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
選んだのに、捨てられない
ある領域を選んだ。全力を注ぐと決めた。
なのに、頭の片隅にいつも「でも、別の領域も気になる」「あっちも追っておくべきでは」という声がある。選んだはずなのに、選んでいない。形式的には選択した。選んだ領域に時間を使うと決めた。だが、選ばなかった選択肢を手放していない。心のどこかで、まだ握りしめている。「いつか使うかもしれない」「完全に捨てるのはもったいない」。
では、なぜ捨てられないのか。
選ばなかった領域の入門書を3冊読んだことがある。ある日、本棚の前に立って、その3冊を処分しようとした。手に取った。ゴミ袋の口は開いていた。入れなかった。棚に戻した。「いつか読み返すかもしれない」と思った。読み返さないことは知っていた。知っていて、棚に戻した。
これは本の話ではない。その3冊を「無駄だった」と認めたくない。だから手放せない。「ここまで投資したのに」。使った時間は戻らない。戻らないのに、手放すと「無駄だった」ことを認めることになる。頭ではわかっている。手が離れない。「私は広く学んでいる人間だ」という自己像もある。ある領域を捨てると、その像が崩れる。「捨てた領域が爆発的に来たらどうしよう」という恐怖もある。全部、根っこは同じだ。手放したら、自分が減る。そう感じている。身体が拒否する。頭は「捨てろ」と言い、手は棚に戻す。この距離が、捨てることの本当の難しさだ。
だから、全力が出ない。エネルギーが分散する。どれも中途半端になる。エンジニアリングでも同じことが起きる。「今期はバックエンドの設計力を深める」と決めた。なのに、フロントエンドのタスクが降ってくると、つい手を出してしまう。結果、どちらも中途半端になる。
選ぶことと、捨てることは、別の行為だ。選ぶだけでは足りない。選ばなかったものを、本当の意味で手放す必要がある。
では、どう手放すか。まず、「使った時間がもったいない」は捉え直せる。3冊読んだ入門書は、その領域を「知っている」状態にするためのコストだった。使わなくても、「使わない」という判断ができるようになった。それだけで十分なリターンだ。恐怖は、実際に乗り遅れてみると消える。私は量子コンピューティングに乗り遅れた。ロボティクスにも乗り遅れた。結果どうなったか。何も起きなかった。恐怖の正体は、想像の中にしかなかった。
「捨てる」の構造：選択肢、成功体験、アイデンティティ
捨てるとは、可能性を閉じることだ。「Bを選んでいたら得られたかもしれない未来」を、永久に手放すことだ。その未来は、もう来ない。来ないことを受け入れる。これが怖い。だから人は、選んでも捨てない。「いつかBもやるかもしれない」と思っておく。可能性を閉じることを拒否する。でも、「いつか」は来ない。何者かになるとは、なれたはずの何者かを殺すことだ。可能性は美しい言葉だが、閉じなければ永遠に可能性のまま終わる。
ここで、「捨てる」を構造化しておく。前回「選ぶ」を評価・宣言・撤退の3要素で定義したように、「捨てる」にも種類がある。書きながら整理したら、少なくとも3つに分かれた。
1つ目は選択肢を捨てる。選ばなかったものを手放すこと。Aを選んだなら、BとCを手放す。これが一番わかりやすい「捨てる」だ。
2つ目は成功体験を捨てる。過去の正解を手放すこと。かつてうまくいった方法が、今もうまくいくとは限らない。すでに「正解」として自分の中に定着しているものを、意識的に棄却する話だ。「間違っていたもの」を捨てるのは簡単だ。「正しかったもの」を捨てるのが辛い。
3つ目はアイデンティティを捨てる。「自分はこういう人間だ」という自己像を手放すこと。「Goの人」「インフラの人」「広く浅く知っている人」。これらの看板を下ろすこと。3つの中で最も深い層にある。
この3つは、表面から深層に向かっている。選択肢→成功体験→アイデンティティ。そして、多くの人が「捨てられない」と言うとき、実は1つ目はできている。できていないのは2つ目か3つ目だ。
正解の呪い：この三部作の最後の敵
ここで、この三部作を貫く敵の正体を書いておく。
「方法を学べ」で敵は無知だった。方法を知らないから、課題が見えない。学べば倒せる。「方法を選べ」で敵は情報信仰だった。もっと調べれば正しく選べるという嘘。「選ぶ」という行為で断ち切れる。今回の敵は、もっと深い場所にいる。
正解の呪い。
間違ったものを捨てるのは簡単だ。失敗が教えてくれる。「あれはダメだった」と納得できる。正しかったものを捨てるのが地獄だ。成功が、手放させない。正しかったから身体に刻まれる。正しかったから無意識化される。そして、正しかったがゆえに、文脈が変わった後も、手放せない。
情報信仰は「もっと調べれば正解がわかる」だった。正解の呪いは、「前に正解したから今回も正解だ」。根は同じだ。正解への執着が、人を止める。情報信仰が未来の正解にすがるなら、正解の呪いは過去の正解にすがる。この三部作で敵はエスカレートしている。見えない→選べない→手放せない。3つ目の敵が一番手強い。なぜなら、正しかったという事実が、抵抗の根拠になるからだ。
アンラーン：「学び捨てる」という技法
この「正解の呪い」を解くための行為を、私はアンラーン（Unlearn）と呼んでいる。
知識を忘れることではない。忘れるだけなら簡単だ。難しいのは、無意識化された前提を、意識的に棄却し、新しい環境に合った前提を作り直すことだ。学ぶの反対ではない。学んだ上で、学びが作った「型」を手放す。GoからRustに移ったとき、私がやらされたのがまさにこれだった。
過去に成功をもたらした方法が、環境の変化を反映していないとき、それは効果を失い、足枷になる。振り返ると、足枷を外すたびに同じ段階を踏んでいた。まず、何が自分を縛っているか認識する。「データは共有するもの」という前提が足枷だと気づく。次に、違うやり方を小さく試す。Goを封印してRustでプロトタイプを書く。そして、新しい前提から世界を見直す。Goに戻ったとき、見える景色が変わっている。認識する。試す。見直す。このサイクルは一度きりのイベントではない。継続的な習慣だ。この三部作で書いてきた「学ぶ→選ぶ→捨てる→学ぶ」と、構造が重なる。
なぜ成功した人間ほど、アンラーンが難しいのか。
身体が覚えてしまうからだ。
障害対応のランブックを作り込んだことがある。手順1から手順12まで、各ステップの分岐条件つき。よくできていた。3ヶ月間、このランブックで障害を裁いた。ある夜、手順7の時点で想定外のメトリクスが出た。ランブックに書いていないパターンだった。私はランブックの手順8に進んだ。目の前にランブック外の情報があるのに、手順に沿って進んだ。30分後、原因はランブックの想定外の箇所にあったとわかった。手順7で立ち止まっていれば、10分で終わっていた。
もう1つ。本番環境のレスポンスが遅くなった。いつもの手順で調査を始めた。スロークエリログを開く。実行計画を取る。インデックスの設定を確認する。3時間かけて、SQLには問題がないとわかった。問題はSQLではなかった。直前のデプロイで、HTTPクライアントのタイムアウト設定が変わっていた。デプロイのdiffを最初に見ていれば5分でわかった。見なかった。「レスポンスが遅い＝SQLの問題」が身体に刻まれていた。過去10回は本当にSQLが原因だった。11回目はSQLではなかった。
2つのエピソードに共通する構造がある。馴染みの手順が、文字通り目の向く先を変える。見えなくなるのだ。別の原因がすぐそこにあるのに。成功した回数が多いほど、手順への信頼は強くなる。信頼が深くなるほど、手順の外側が見えなくなる。個人が習慣を支配するのではなく、習慣が個人を支配する。そうなったとき、自動化は真に危険なものになる。
賢い人間ほど、この罠が深い。知性が高い人間は、既存の判断を正当化する論理を精巧に組み立てられる。結論が先にあり、その結論を支持する証拠だけを巧みに集める。知性が低ければ正当化が粗いから矛盾が見える。知性が高いと正当化が完璧に見えるから、本人すらおかしいと気づかない。賢ければ賢いほど、自分の限界に対して盲目になりうる。
Goを書き始めた頃を思い出す。何も知らなかった。何も知らないから、設計の選択肢が無限に見えた。goroutineも、channelも、interfaceも、「どう使ってもいい」という自由があった。Goに習熟するほど、「こういう時はこう書く」が固まっていった。速く書けるようになった。代わりに、見える世界が狭くなった。何も知らなかった頃のほうが、可能性は広く見えていた。専門性を積むとは、認知の枠組みを安定させることだ。安定は速さを生むが、代償として隙間を塞ぐ。新しいパターンを受け入れる余地が、少しずつなくなっていく。
行動を修正するだけでは足りない。Goのコードレビューで「goroutineの数を減らせ」と指摘する。これは行動の修正だ。「そもそもgoroutineで並行処理する設計が正しいのか」を疑う。これが前提の修正だ。私はGoを書いていた頃、前者ばかりやっていた。後者に踏み込めなかった。前提を疑うことは、自分がこれまで正しかったという確信を揺るがすからだ。
練習を重ねて環境に順応する。それが逆に成長を止めてしまう。そして、チャンスは余白のある人のところに訪れる。
正解の呪い、AI版
前回「選ぶ」とAI時代の接続を書いた。「捨てる」について、もっと踏み込んで書く。
これだけAIによる激動が来ている。2026年の今、コードを書く行為そのものが変容している。AIがコードを生成し、テストを提案し、リファクタリングを実行する。1年前に「これは人間にしかできない」と言われていたタスクが、次々とAIの射程に入っている。この変化の速度は、過去のどの技術的転換とも比較にならない。
この時代に最も危険なのは、「AIツールを使いこなせている自分」が次の正解の呪いになることだ。
正直に書く。私自身、すでにこの罠に片足を突っ込んでいた。半年前に作ったプロンプトテンプレート集がある。社内ドキュメントの生成、コードレビューの補助、障害対応の初動。用途ごとに作り込んだ。うまく動いていた。あるとき、新しいモデルがリリースされた。試しにテンプレートなしで同じタスクを投げてみた。出力の品質が変わらない。むしろ、以前は必要だった制約条件の指定が冗長になっていた。テンプレートが邪魔をして、新しいモデルの能力を引き出せていなかった。「うまくいっているテンプレートを変える必要はない」。GoからRustに移行したときと同じ声が聞こえた。半年前の「正解」が、今日の足枷になっていた。
今日のプロンプトエンジニアリングのベストプラクティスが、半年後には陳腐化しているかもしれない。「AIの使い方を知っている」というアイデンティティに固執したとき、あなたはモノリスの設計に固執していた私と同じ場所にいる。
この三部作を書いていて、1つの構造に気づいた。読み書きができないことが致命的だった時代があった。今、致命的なのは学び、学び捨て、学び直すことができないことだ。知識の量ではない。知識を入れ替え続ける能力。これに気づいたのは私が最初ではない。たぶん、何十年も前から言われている。言い古された話が、それでもなお刺さるのは、私たちがまだこれを実践できていないからだ。
AI時代のアンラーンには、2つの方向がある。
1つは、AIが代替できるスキルを積極的に手放すことだ。ツールの使い方、言語の文法、フレームワークの設定。どれもAIに聞けば数秒で返ってくる。「広く浅く知っている」の価値が急速に下がっている。AIという外部記憶装置ができた。脳の中に保持する必要のなくなった知識がある。
本当だろうか。「AIが答えてくれるから覚えなくていい」は、危険な短絡だ。前回書いた「道の存在を知らなければ、AIに道を聞くこともできない」。あの問題がここでも効く。完全に捨てたら、AIに何を聞けばいいかすらわからなくなる。「完全に捨てる」と「メンテナンスしない」は違う。骨格だけは残しておく。骨格があれば、AIに適切な質問ができる。
もう1つは、AIが代替できないものを固く持つことだ。何を問うか。何に違和感を覚えるか。何を面白いと感じるか。AIの出力を評価する目。自分だけの観点。好奇心。これはサイクルの外に固定すべきものだ。
謙虚に学び捨てられる人間こそ、最もAIを使いこなせる。AIの出力を鵜呑みにしない。かといって、頭ごなしに否定もしない。自分の前提を疑える人間だけが、AIの出力と自分の知識を突き合わせ、どちらを採るかを判断できる。正解の呪いにかかった人間は、AIの出力と自分の前提に矛盾を見つけたとき、AIを「間違っている」と片づける。初心を持った人間は、「自分の前提のほうが古いのかもしれない」と考える。
AI時代の「捨てる」は、捨てる対象の選別がより精密になる。何でも抱えるのは論外だが、何でも捨てるのも危険だ。その仕分け自体も、半年後には更新が必要になるかもしれない。アンラーンは一度きりのイベントではない。継続的な習慣だ。
GoからRustへ：私のアンラーン
ここまで言葉を並べた。では、私自身はどうだったか。
私はGoで長くコードを書いていた。構文はすぐ慣れる。問題は構文ではなかった。設計の発想が染み付いていた。Goでは「データは共有するもの」だった。複数のgoroutineが同じデータにアクセスする。mutexで守る。channelで調整する。「誰がデータを持っているか」は、あまり考えない。必要なら渡せばいい。コピーすればいい。GCが回収してくれる。
Rustを書き始めたとき、この発想が邪魔をした。Rustでは「データは誰かが所有するもの」だ。所有者は一人。借用（一時的にデータを借りて使うこと）には期限がある。最初、私はGoの感覚で設計した。「とりあえずデータを作って、必要な場所に渡せばいい」。コンパイルが通らない。「じゃあ参照を渡せばいい」。ライフタイムエラー。「クローンすればいい」。パフォーマンスが劣化する。
ここで強調しておきたい。Goの設計が間違っていたわけではない。Goの文脈では完全に正しかった。正しかったから身体に刻まれた。正しかったから繰り返した。正しかったから、手放せない。これが「正解の呪い」の個人版だ。Goという馴染みの設計が、Rustの設計空間を見えなくしていた。先に書いたSQLデバッグと同じ構造だ。「レスポンスが遅い＝SQL」が身体に刻まれていたように、「データ設計＝共有」がGoで身体に刻まれていた。馴染みの前提が、文字通り目の向く先を変える。
私は1ヶ月間、Goを封印した。プロトタイプをすべてRustで書いた。最初の2週間は苦痛だった。Goなら30分で書けるCLIツールに4時間かかった。何度も「Goで書き直したい」と思った。しかし3週目、変化が起きた。構造体を設計しているとき、「この値の所有権をどこに持たせるか」が、考える前に浮かんだ。指が先にコードを書き始めていた。身体がRustの設計を覚え始めていた。
Goに戻ったとき、見える世界が変わっていた。goroutine間の共有データを見る目が違う。「これ、誰が所有しているんだ」と自然に問うようになっていた。あるPRで、goroutineに渡されたスライスを見た。渡した側が、渡した後にそのスライスを変更している。Goではコンパイルが通る。テストも通る。しかし、Rustの目で見ると、「これは共有された可変参照だ」と即座にわかる。データ競合の温床だ。実際に、本番環境で月に1回程度、原因不明のパニックが起きていた。このPRのレビューで指摘し、修正した。パニックは消えた。
Rustを学んでいなければ、このバグは見えなかった。Goの世界に閉じていれば、スライスを渡すのは「普通のこと」だ。Rustの前提で世界を見直したとき、「普通のこと」が「危険なこと」に変わった。これがアンラーンの恩恵だ。古い前提を手放したことで、古い世界すら、より深く見えるようになった。
Rustを学ぶためには、Goで身についた設計の発想を手放す必要があった。手放すのは、構文ではなかった。「データは自由に共有できる」という無意識の前提だった。知識を忘れるのではない。無意識化された前提を、意識的に棄却する。そして、新しい環境に合った前提を、もう一度作り直す。認識する、試す、見直す。先に書いたアンラーンのサイクルそのものだった。
教訓が足枷になるとき
第1回で「具体的な経験から抽象的な構造を取り出す」と書いた。あの操作が「教訓」を生む。教訓は正しい。抽象化された分だけ、広い場面で使える。「テストを書け」「設計を先にやれ」「DRYにしろ」。どれも正しい。
しかし、教訓には1つ致命的な欠陥がある。教訓が生まれた文脈は保存されない。
「テストを書け」は、テストを書かずに深夜対応した経験から生まれた教訓だ。正しい。ただし、30分で捨てるプロトタイプにもテストを書くべきか。「設計を先にやれ」は、設計なしに突き進んで3ヶ月無駄にした経験から生まれた。正しい。ところが、何を作るかすらわかっていない探索段階で設計を先にやるべきか。「DRYにしろ」は、コピペコードの保守地獄から生まれた。正しい。では、2つの似たコードが本当に同じ抽象を共有しているかわからない段階でDRYにすべきか。
いつ正しいかの条件を忘れた教訓は、ドグマになる。
教訓を捨てるのではない。教訓に条件をつけ直す。「テストを書け。ただし、そのコードが明日も生きているなら」「設計を先にやれ。ただし、問題の輪郭が見えているなら」「DRYにしろ。ただし、重複が偶然ではなく構造的なら」。行動を修正するのではない。前提を問い直す。「テストを書く」という行動ではなく、「なぜテストを書くのか、いつ書くべきか」という前提。条件をつけ直すことは、教訓を捨てることではない。教訓を正しく持ち直すことだ。
安全に捨てるための原則
モノリスの設計で壁にぶつかっていた時期がある。コードが肥大化していた。新機能の追加に3日かかる。バグの修正に1日かかる。コードベースの見通しが悪く、変更の影響範囲が予測できない。「書き直したい」と何度も思った。しかし、書き直す時間はない。
あるとき、気づいた。構造を変えたいなら、ゼロから書き直す必要はない。外から見た振る舞いを一切変えずに、内部構造だけを改善する。少しずつ。テストで守りながら。リファクタリングの本質は、テクニックではなかった。過去の設計判断を安全に捨てるための手続きだった。
この経験から得た最も重要な教訓は、「捨てる」を安全に行うための条件だ。
1つ、テストがあること。捨てた後に壊れていないことを確認できる仕組みがなければ、捨てるのは賭けになる。2つ、小さなステップで進むこと。一度に全部捨てようとすると、壊れたときにどこが原因か特定できない。3つ、各ステップの後に動作を確認すること。1ステップごとに確認すれば、疑う範囲は最小になる。
これはコードの話だ。しかし、「安全に捨てるための原則」として、コード以外にも適用できる構造だ。アンラーンは大きな跳躍ではない。小さな実験の連続だ。
捨てることで、余白ができる
「全部やる」から抜け出せなかった時期がある。
なぜ優秀な人間が、優秀であるがゆえに失敗するのか。能力がある人間は何でもこなせる。こなせるから断らない。断らないから、すべてが中途半端になる。自分のことだ。80%を10個やるより、100%を2個やる方が、価値は高い。頭ではわかっている。しかし、80%の案件を断る勇気がなかった。断れば「あいつは協力的じゃない」と思われる。思われないかもしれない。思われるかもしれないという恐怖だけで、十分に断れなくなる。
あるとき、自分にルールを課した。「90点以上でなければ、やらない」。技術情報の取捨選択に適用した。RSSフィードの1つ1つに問う。「これがなくなったら、仕事に支障が出るか」。答えがNoなら解除する。「役に立つかもしれない」はNoだ。「ないと困る」だけがYesだ。数百のフィードが20以下になった。
と書いたが、正直に告白する。このルールを適用した直後、不安になった。「大事な情報を見逃しているのではないか」。1週間は、解除したフィードのサイトを手動で巡回していた。自分で決めたルールを、自分で信じ切れていなかった。2週目で巡回をやめた。何も見逃していなかった。見逃したかもしれないものは、本当に重要なら他のチャネルから流れてくる。この経験で、「捨てても大丈夫」という感覚が身体に刻まれた。
余白があるから、深く潜れる。チャンスは余白のある人のところに訪れる。余白がなければ、チャンスが来ても気づかない。気づいても、手が空いていない。
だが、余白ができた途端に、それを埋めたくなる衝動がある。RSSフィードを減らした翌朝のことを覚えている。フィードリーダーを開いた。20件。5分で読み終わった。残りの25分、椅子の背もたれに体重を預けて、天井を見ていた。何もすることがない。手が勝手にHacker Newsを開いていた。気づいたのは3つ目の記事を読み始めたときだった。積読を処分した。空いた棚に、翌週には新しい本が3冊並んでいた。余白を余白のまま維持する力が、実は一番難しい。「何もしない時間」に耐えられない。退屈が怖い。だが、余白を即座に埋めてしまったら、捨てた意味がない。捨てることと、余白を維持することは、セットで語る必要がある。
組織が捨てられないもの
個人だけの話ではない。組織も、捨てられないものを抱えている。
チームで使っていた監視ツールを捨てようとしたことがある。3年前に私が導入したツールだった。導入時は最適だった。ダッシュボードのテンプレートも作り込んだ。しかし、システムの規模が大きくなり、そのツールでは限界が来ていた。捨てることを提案したのは私だ。私が導入し、私が捨てることを提案した。にもかかわらず、胸が痛かった。会議の場で代替ツールのスライドを映しながら、手のひらが汗ばんでいた。自分の過去の判断を、自分で否定する作業だった。
私ですらこうだ。他の人が導入したものを捨てる提案をすれば、反発はもっと大きい。「あのプロセスは私が導入した」。捨てることが、自分の否定に感じられる。
チームの文化も同じだ。あるチームでは「全員でコードレビューする」が文化だった。チームが4人のときは機能していた。12人になったとき、PRのマージまで平均3日かかるようになった。段階的にコードオーナーシップ制に移行した結果、マージ時間は3日から4時間になった。文化を捨てることは、文化を否定することではない。文化を更新することだ。
ルールは、さらに厄介だ。ルールの本質は「毎回考えなくて済む」という効率化にある。しかし、まさにその利点「考えなくて済む」が、思考停止という副作用を生む。ルールを撤廃するコストは、ルールを作るコストより高い。作るときは「これで問題が防げる」という明確な動機がある。ところが、撤廃するときは「なくても大丈夫だ」という証明が求められる。悪魔の証明だ。誰も手を出さない。結果、ルールは増え続ける。
私が所属していたチームでは、デプロイ手順書が47ステップあった。3年前の障害を受けて追加された手順が半分以上を占めていた。しかし、その障害の原因となったアーキテクチャはすでに刷新されていた。手順の根拠がもう存在しないのに、手順だけが残っていた。「念のため」。この3文字がルールを延命させる。
47ステップを12ステップに削減した。各ステップの「根拠」を洗い出し、根拠が現在のアーキテクチャに適用可能かを検証した。47のうち根拠が明文化されていたのは8つだけ。残り39は「いつからあるか」すら誰も知らなかった。最終的にデプロイ時間は平均45分から8分に短縮された。反発はあった。「念のため残しておくべきだ」と主張する人がいた。「念のため」は論理ではなく恐怖だ。「2週間だけ新しい手順で試す。問題があれば元に戻す」と期限を切った。2週間後、問題は起きなかった。
思考を止めた安全は、安全ではない。原則は「なぜ」を含む。ルールは「なぜ」を消す。
プロジェクトを止めるという仕事
ツールを入れ替える。文化を更新する。ルールを削る。ここまで書いてきた「組織の捨てる」は、まだ方法の更新の話だ。もっと重い「捨てる」がある。プロジェクトそのものを止める。
新しいことを始めるのは、止めることに比べれば楽だ。始めるときは「可能性」を語ればいい。「これが成功したら」という未来の報酬が人を動かす。提案書を書き、予算を取り、チームを組む。始動には勢いがある。止めるときに語るのは可能性の消滅だ。「この投資はリターンを生まない」と宣言することだ。誰も興奮しない。始めるときに必要だったのは1枚の提案書と1人の承認者だった。止めるときに必要なのは、関係者全員への説明と合意と、感情の処理だ。始めるコストと止めるコストの非対称性。これが、組織にゾンビプロジェクトを生む構造だ。
止める決断が難しい理由は、突き詰めると2つに帰着する。
1つ目はステークホルダーの増殖だ。始めるときは起案者と承認者がいれば動く。しかし、時間が経つほど関係者は増える。顧客がつく。他チームが依存する。社外に発表してしまう。ドキュメントが書かれ、研修が組まれ、採用要件に載る。1人の判断で始められたプロジェクトが、半年後には10人の合意なしに止められなくなっている。「あのチームが使っているんですが」「お客様への説明が必要です」「来期の計画に入っています」。止めようとした瞬間、壁がそびえ立つ。顧客が絡んだ時点で、難易度は一段上がる。社外へのコミットメントは、社内の惰性よりはるかに強力なロックインになる。
2つ目はサンクコストの組織版だ。個人のサンクコストは「入門書3冊分の時間がもったいない」程度で済む。組織のサンクコストには数字がつく。「3人月投入しました」「外注費800万です」。数字は感情を正当化する。すでに払ったコストは、続けても止めても戻らない。戻らないのに、「もう少し続ければ成果が出るかもしれない」と思う。この「かもしれない」がゾンビプロジェクトの栄養源だ。先に書いた「正解の呪い」がここでも効いている。過去に承認した判断が「正しかった」と思いたい。止めることは、過去の判断を否定することに感じられる。だから止められない。
では、どうやって止めるのか。5つ書く。書いてみて引っかかった。この5つを私自身、何回実行できたか。数えた。5回中1回だ。知っていてできない。正解の呪いの亜種かもしれない。それでも書く。書くことで次は2回にしたいから。
1つ、始めるときに終了条件を決めておく。撤退ラインの指標。判断時期。最終判断者。始めるときに終わりを設計する。始めるときの冷静さは、走り出した後には失われている。冷静なうちに基準を置いておく。引き継いだ案件でも、後から期限を設けることはできる。
正直に告白する。あるプロジェクトの企画書に「半年後にMAU 1,000未満なら撤退」と書いた。半年後、MAUは300だった。撤退を検討するはずだった。しなかった。「ユーザーの質が高いから数字だけでは判断できない」と言った。自分で決めた基準を、自分で無効化した。冷静なうちに基準を置いておく、と書いたが、基準を置いても、いざとなれば基準の解釈を変えてしまう。人間は。私は。それでも、基準がないよりはましだ。基準があれば、少なくとも「自分が基準を無効化している」という自覚が生まれる。自覚は、次の判断を少しだけましにする。
2つ、判断基準はサンクコストではなく「今後の効果」にする。問うべきは「ここまでいくら使ったか」ではない。「今日この瞬間から、続けた場合と止めた場合で、どちらのリターンが大きいか」だ。止めて浮いたリソースを別の施策に振り向けたほうが効果が大きいなら、止めるのが合理的な判断になる。サンクコストの800万は、どちらを選んでも戻らない。戻らないものを判断材料に入れてはいけない。頭ではわかっている。わかっていても、会議で「800万」という数字が出た瞬間、空気が変わる。数字の重力は強い。私も変わった側の人間だった。「800万」と聞いた瞬間、「もう少し続ければ回収できるのでは」という言葉が口から出かけた。出かけて、飲み込んだ。飲み込めたのは、サンクコストの構造を知っていたからだ。知っていても飲み込むのに3秒かかった。知らなかったら、そのまま言っていた。
3つ、止める決断はリーダーにしかできない。現場は「止めたほうがいい」と気づいていることが多い。しかし、現場には止める権限がない。プロジェクトを承認したのが上位の意思決定者なら、止める権限もその人間にある。承認した最上位の人間が「止める」と言わない限り、プロジェクトは惰性で続く。あるプロジェクトで、全員が「無理だ」とわかっていた。週次の進捗会議で、全員が「順調です」と報告していた。私も報告していた。順調ではなかった。全員が知っていた。知っていて、誰も言わなかった。リーダーが「止める」と言うのを待っていた。リーダーは「もう少し頑張ろう」と言い続けた。リーダーを責めることはできない。リーダーもまた、上位の承認者が「止める」と言うのを待っていたのだから。止める権限は、始めた権限と同じ高さにある。リーダーの仕事は始めることだけではない。止めることもだ。むしろ、止めることのほうが始めることより難しく、より多くの勇気がいる。
4つ、「結論」ではなく「ストーリー」を語る。「プロジェクトXは中止します」。結論だけ伝えると、聞いた側は「なぜ」を自分で補完する。補完された「なぜ」は、たいてい最悪の方向に振れる。「うちのチームが評価されていないのか」「次はうちが切られるのか」。ストーリーを語る必要がある。現状の診断。なぜこの決断に至ったか。組織はどこに向かうのか。関わった人たちの次の行動は何か。この順番で、データとともに伝える。関わった人たちの貢献を認める。止めることは否定ではなく方向転換だ、と言うのは簡単だが、それを本気で信じている態度が伝わらなければ、言葉は空転する。
5つ、伝える順番とタイミングを設計する。一斉発表はハレーションを生む。まず、直接影響を受けるキーマンに個別に伝える。次に関連チームのリーダー。その後、実行メンバー。最後に全社共有。各段階で質問を受け、懸念に答え、合意を積み上げていく。
私がこの「順番」を痛感したのは、失敗からだった。社内ツールの廃止を決めたとき、全社チャンネルで一斉に通知した。効率的だと思った。5分後、「聞いてないんだけど」というDMが3件届いた。全員、そのツールのヘビーユーザーだった。事前に相談すべき人たちだった。廃止は2ヶ月遅れた。先に個別に話していれば、1週間で済んでいた可能性がある。「伝える順番」は効率の問題ではない。信頼の問題だ。効率を優先して信頼を毀損すると、結果的に時間がかかる。
この5つに共通する構造がある。止める決断は、「止める」と言った瞬間に完了するのではない。止めるという意思決定と、止めることを組織に受容させるプロセスは、別の仕事だ。前者は一瞬で終わる。後者に時間がかかる。そして、後者を怠ると、止めたはずのプロジェクトがゾンビとして復活する。「やっぱり必要だったのでは」と。
しかし、これは「止め方」の話であって「止める覚悟」の話ではない。
ここまで5つの方法を書いた。書いて、虚しくなった。方法を知っていても、止める痛みは消えない。あるプロジェクトを止めたときのことを書く。会議室に入る前、廊下で深呼吸した。スライドは15枚用意した。3枚で十分だとわかっていた。しかし、12枚分の「なぜ」を並べないと、自分が納得できなかった。相手を説得するためではない。自分が正しい判断をしたと、自分に言い聞かせるための12枚だった。会議は20分で終わった。誰も反論しなかった。全員が「そうだろうな」という顔をしていた。反論されないのが、かえって辛かった。反論されれば「説得する」という仕事ができる。全員が黙って頷くと、止めた責任が自分一人に凝縮する。
止めた後のほうが辛い。翌週、そのプロジェクトに関わっていたメンバーとすれ違った。「次のアサイン、もう決まりました」と言われた。声のトーンに棘はなかった。なかったが、「次のアサイン」という言葉が刺さった。私が止めたから、この人は「次」を探す必要が出た。正しい判断だったと今でも思う。思うが、正しい判断が人を傷つけないとは限らない。止める側は「組織のため」という大義がある。止められる側には、「自分の半年間が消えた」という事実だけが残る。大義と事実は噛み合わない。
始めるときのコストは目に見える。予算、人員、スケジュール。止めるときのコストは目に見えない。信頼の毀損。士気の低下。「次もどうせ止められるのでは」という不信。この見えないコストが、次のプロジェクトを始めるときに重くのしかかる。止めることのコストは、止めた瞬間ではなく、その後の数ヶ月に分散して現れる。方法論は痛みを消さない。痛みを引き受けた上で、手順を踏む。その順番を、私はまだうまくできていない。
緩やかな陳腐化：痛みのない衰退
過去の成功が、未来の失敗を招くことがある。私はこの構造を、個人の開発スタイルで経験した。しかし、同じ構造がもっと大きなスケールで、企業全体を飲み込む規模で、起きている。
私はこの構造を、かつて関わった製品で目撃した。合理的に正しい判断をし続けた結果、市場から退場する。既存の顧客を大切にする。既存の製品を改善する。投資対効果の高いプロジェクトに資源を配分する。すべて正しい。正しいのに、足元から崩れる。一番恐ろしいのは、「間違った判断をした」のではないことだ。まさにその「正しい学習」が、視野の外にある価値を「価値」として認識できなくさせる。
これは私だ。モノリスの設計で成功していた。成功していたから繰り返した。システムの規模が変わり、マイクロサービスが必要になったとき、私はモノリスの世界の中に閉じ込められていた。マイクロサービスを「複雑すぎて管理コストが見合わない」と評価した。当時の私の文脈では正しい評価だった。しかし、文脈が変わっていた。3ヶ月かけて設計したモノリスが負荷テストで破綻したとき、後輩に言われた。「最初からマイクロサービスで設計していれば、この問題は起きませんでしたよね」。反論できなかった。
企業のジレンマと個人のジレンマは、本当に構図が同じだろうか。企業は組織構造に縛られている。個人は自分の意志で変えられる。にもかかわらず変えられないのは、心理的障壁が構造的障壁と同じくらい強固だからだ。むしろ、個人のほうがたちが悪い。「自分で変えられる」からこそ、変えないことを自分で選んでいることになる。その事実と向き合うのが辛い。企業なら「組織が悪い」と言える。個人には、逃げ場がない。
そして、企業と個人で決定的に異なる点がある。企業がジレンマに陥ると、市場から退場させられる。倒産する。決着がつく。個人は違う。過去の成功に固執し続けても、死ぬわけではない。ただ、静かに陳腐化する。誰も指摘しない。気づいたときには、周回遅れになっている。
私はこれを「緩やかな陳腐化」と呼んでいる。日々の仕事は回る。給料は出る。でも、扱える課題のレベルが上がらない。5年前と同じ問題を、5年前と同じ方法で解いている。世界は5年分進んでいる。相対的に後退している。
そして、この「5年」が縮んでいる。かつて10年かけて進んだ技術的変化が、今は2年で起きる。AI以降は半年で景色が変わる。緩やかな陳腐化の猶予期間が、急速に短くなっている。
ここで、先に書いた「捨てる」の3構造（選択肢→成功体験→アイデンティティ）が、時間圧縮と重なる。成功体験を捨てられない。「このやり方で結果を出してきた」。成功体験から得た学びも捨てられない。「この学びが自分を今の位置に連れてきた」。そして最も深い層、成功体験が形成した自己評価を捨てられない。「自分はこの領域の専門家だ」「自分はものをわかっている側の人間だ」。この3つを抱えたまま社会の変化速度が上がると、どうなるか。成功体験の賞味期限が切れる。学びが前提ごと失効する。自己評価だけが残る。中身のない自己評価ほど厄介なものはない。かつて正しかったという記憶が、今も正しいという錯覚を支える。
正直に書く。これは他人事ではない。私自身、この緩やかな陳腐化を経験した。VM最適化に半年を費やした話を前回書いた。毎日コードを書いていた。技術的に面白いことをしていた。VMのブートシーケンスを最適化する。知的に刺激的な仕事だった。しかし、世界はコンテナに移っていた。起動時間を30秒短縮できたとき、達成感があった。達成感があるのに、陳腐化している。痛みがない。それどころか快感がある。麻酔が効いたまま手遅れになる構造だ。
あのとき私を支えていたのは「VMの最適化ができる自分」という自己評価だった。成功体験が学びを固定し、学びが自己評価を形成し、自己評価が次の学びを阻む。3つの層が互いを強化する。この連鎖を断ち切らなければ、いずれ周囲から「あの人はもう時代についてきていない」と言われる。誰も面と向かっては言わない。言わないから、本人は気づかない。気づいたときには、もう「あの人」になっている。
なぜ断ち切れないのか。根を掘ると、サンクコストやアイデンティティより泥臭い理由が出てくる。体力がないからだ。
成功体験を捨てるとは、一時的に初心者に戻ることだ。初心者に戻れば、失敗する。失敗から這い上がるには体力がいる。若いうちは体力がある。失敗しても翌週に新しいアプローチを試せる。恥をかいても寝たら忘れる。キャリアを重ねるほど、この体力が減る。物理的な体力もだが、もっと根深いのは失敗して這い上がる自分を信じられなくなることだ。
20代の自分は失敗を恐れなかった。恐れなかったのは勇気があったからではない。失敗しても回復できるという、根拠のない確信があったからだ。経験を積むと、確信が揺らぐ。失敗の記憶が積み重なる。這い上がった記憶もある。しかし同時に、「あのときは這い上がれなかった」記憶もある。成功体験にしがみつくのは、過去の栄光が忘れられないからだけではない。もう一度失敗したとき、今の自分に這い上がる力があるか確信が持てないからだ。だから安全な場所から動かない。安全な場所とは、過去に正解だった場所だ。正解の呪いの一番深い根が、ここにある。
これは言い訳だろうか。半分は言い訳だと思う。どちらの半分が言い訳かは、自分でもわからない。しかし半分は構造的な事実だ。捨てることのコストは年齢とともに上がる。新しいことを学ぶ速度は大きくは落ちないが、学び直しに割ける時間は減る。家族がいる。責任がある。「週末にRustを書く」が、独身のときほど気軽にはできない。この制約の中で捨てるには、若いときより精密な判断がいる。何を捨て、何を残すか。体力が無限ではないからこそ、捨てる対象を選ぶ力が問われる。
陳腐化を検知するには、外部のフィードバックが要る。鏡がなければ、自分の顔は見えない。知っていた。知っていて、見ないふりをした時期がある。ある勉強会で、隣に座ったエンジニアがKubernetesのOperatorパターンについて話していた。私は何の話かわからなかった。わからなかったことより、わからないことを隠した自分が恥ずかしかった。帰りの電車で、自分のスキルセットを頭の中で棚卸しした。半分が3年前のまま止まっていた。「定期的に棚卸しをしろ」「社外の勉強会に出ろ」「技術レーダーを半年に1回チェックしろ」。処方箋は知っている。問題は、棚卸しの結果、見つかるものが怖くて問えないことだ。陳腐化の構造は、検知方法がないことではない。検知する勇気がないことだ。
サイクルの外にある軸
学ぶ → 選ぶ → 捨てる → 学ぶ。このサイクルを回し続けろ、と書いてきた。しかし、「永遠に回し続けるのか」という問いが残る。
正直に答える。終わりはない。ただし、「終わりがない」ことは「意味がない」ことではない。
サイクルは円ではない。螺旋階段だ。同じ場所を回っているように見えて、少しずつ高度が上がっている。10年前は「これができた」という達成感だった。今は「このトレードオフの構造はこうなっていたのか」という発見だ。サイクルを回し続けると、「面白い」の解像度が上がる。
そして、サイクルを回し続けていると、「これは回さなくていい」という領域に出会う。何度も学び、選び、捨てた結果、「ここはもう動かさなくていい」という確信が生まれる。自分の中心に、安定した軸ができる。
私の場合、「文章を書くこと」はサイクルの外にある。ツールは変わる。テーマは変わる。でも、書くこと自体は変わらない。「テストを書くこと」もサイクルの外だ。テストの書き方は変わる。ユニットテストからプロパティベーステストに変わり、ミューテーションテストを取り入れた。しかし、「テストを書く」という行為自体は、一度も揺らがなかった。「コードを読むこと」も同じだ。読むソースは変わる。CのカーネルコードからRustのasyncランタイムに変わった。だが、「他人のコードを読んで設計意図を理解する」という行為は、10年前から変わっていない。
サイクルの外にあるもの、変わらない軸は、サイクルを何周も回した結果として見えてくる。最初から「これは変わらない」と決められるものではない。回した結果、「ああ、これだけは毎回残るな」と気づく。捨てようとして手が止まるもの。それが、本当に大事なものだ。捨てることの最大の恩恵は、捨てたものではなく、捨てられなかったものを知ることかもしれない。
第1回で「方法の探求は課題の発見である」と書いた。第2回で「方法を選ぶことがWhyを確定させる」と書いた。そして今回、「方法を捨てることが次のWhyを生む」と書こうとしている。三部作を通じて見えてきたもの。学ぶ・選ぶ・捨てるは、課題の質を上げ続けるための循環だ。AI時代に、この循環の回転速度が上がる。しかし、循環そのものは変わらない。変わらないものを持っている人間が、変わるものを使いこなせる。
そして、また学ぶ
「方法を捨てろ」と書いている自分に引っかかる。これが言えるのは、捨てても食いっぱぐれない人間だ。十分に蓄えがある。金銭だけではない。健康、信頼、交友関係、技術力、実績、業界での評判。捨てても戻れる場所がある。だから「捨てても大丈夫」と言える。この三部作で「学べ」「選べ」「捨てろ」と書いてきた。だが、書きながらずっと引っかかっていた。この三段階は「すでにある程度の蓄積がある人間」を前提としている。蓄積がない段階で捨てたら、何も残らない。捨てることを語るには、捨てるものがなければならない。その前提を持つこと自体が、一種の特権だ。たぶん。
それでも書く。捨てることの恐怖を知っている人間にしか、捨てることの先にある軽さは伝えられない。伝えられているかどうかは、わからないが。
「方法を学べ」で敵は無知だった。知らないから見えない。「方法を選べ」で敵は情報信仰だった。知っているから選べない。今回、敵は正解の呪いだった。正しかったから手放せない。三部作を通じて、敵はずっと同じ根を持っている。正解への執着だ。正解を知らないことへの恐怖。正解を選べないことへの焦り。正解を手放すことへの痛み。形を変えて、ずっとそこにいた。
テストが終わっていた。グリーンだった。冒頭で走っていたテストだ。書き始めたとき、まだ結果は出ていなかった。書いている間に終わっていた。何かを手放す文章を書いている間に、手元のコードは前に進んでいた。画面を閉じて、別のファイルを開いた。次に学ぶものが、もう決まっている気がした。気がしているだけかもしれない。でも、それでいい。
おい、方法を捨てろ。正解だった方法を、正解だったまま、手放せ。
