自分を無限のリソースのように扱っていた

私はシステムのあらゆる部分を入念に最適化することに膨大な労力を注いだが、そのすべてを動かしている、最も重要でありながら最も信頼性の低い唯一のコンポーネントには、ほとんど何の労力も割かなかった。それは私自身だ。私は自分を、無限で、いつでも使える、フル出力で永遠に走り続けられる機械のようなリソースとして扱っていた。そしてプロジェクトは、その過ちの代償を、何度も、そして高くついた形で支払うことになった。

これは私が最も長く抵抗してきた教訓だ。それを認めることが、言い訳をしているように感じられたからだ。だがこれは言い訳ではない。これは、私がモデル化することを拒んだひとつの制約を正確に記述したものにすぎない。そして、現実の制約をモデル化することを拒んでも、その制約が消えてなくなるわけではない。ただ、いつか不意打ちを食らうだけだ。

一度もモデル化しなかった唯一のコンポーネント

私は限界について注意深く考えることに誇りを持っていた。システムのあらゆる部分について、その容量、故障モード、負荷時の挙動、どこで壊れるかを推論した。あらゆる部分について、ただひとつを除いて。私はその同じエンジニアリング上の誠実さを、一度も自分自身に適用しなかった。

口にすることもなく暗黙のうちに、私は自分が永遠にフル出力で走り続けられると仮定していた。自分のエネルギーと集中力は無限で、いつでも蛇口をひねれば出てくるものであり、作業をする人間には容量の上限も、計画に織り込むべき故障モードも存在しない、と。有能なエンジニアなら、コンポーネントをそんなふうにモデル化することは決してない。ひとつの重要な部品が無限のスループットを持ち、保守を一切必要としないという前提でシステムを設計したりはしない。それなのに、私はまさにそのとおりに自分自身をモデル化していた——しかも、そうしていることに気づきもせずに。

クレーターで終わるスプリント

パターンはいつも同じだった。それを見抜くまでに、恥ずかしくなるほど多くの繰り返しを要した。まず、激しく、高揚するような作業の爆発がある——持続可能な限界をはるかに超えて走り続ける、完全な集中の長い時間。それが生産的で、緊急で、心地よく感じられるからだ。そしてその後、完全に予測どおりに、墜落がやってくる。何日も、ときには何週間も、ほとんど何の作業もできない時期。井戸はただ干上がり、どれだけ努力しても再び満ちることはない。

そして毎回毎回、私は自分を責めた。自分の規律のなさを、弱さを、押し通せなかったことを。私はその墜落を、個人的な道徳上の欠陥として、もっとタフな人間なら被らずに済んだはずのものとして扱った。長いあいだ、その墜落がそもそも人格の問題などではないという考えは、頭をよぎりさえしなかった。それは、有限のリソースを限界を超えて走らせたことの、完全に機械的な帰結だった。有限のリソースは、それを酷使したときに有限のリソースが常にやることをやっただけだ。唯一意外だったのは、私が何度も意外がり続けていたことだった。

バーンアウトは意志力の失敗ではなく、システムの失敗である

これが、ようやく何かを変えてくれた捉え直しだった。私は自分の崩壊を、意志の失敗として扱ってきた——もっと強くあるべきだった、押し通すべきだった、もっと強く望むべきだった、と。だがバーンアウトは人格の欠陥ではない。それをそう扱うことは、自分が繰り返しそれを引き起こすことを保証するだけだ。

バーンアウトとは、どんなシステムであれ、持続可能な容量を超えて十分に長く走らせたときに起こることにすぎない。それはシステムの失敗であって、道徳の失敗ではない。それを意志力の問題と呼ぶのは、オーバーヒートしたエンジンを臆病さの問題と呼ぶようなものだ——何が悪かったのかを根本的に誤診しており、だからこそ、まさに間違った処方箋を出すことになる。オーバーヒートしたエンジンへの答えは、もっと勇敢になれと要求することではない。それが最初から持っていたはずの限界を超えて走らせるのをやめることだ。疲弊したオペレーターに意志力を上乗せしても、より多くの出力は生まれない。ただ、より深刻な墜落を生むだけだ。

ペースの算術

この下に横たわっているのは、私が完全に無視していたひとつの算術だ。長く困難なプロジェクトは、ある一瞬のピーク出力で勝てるものではない。それは、非常に長い時間にわたって積分された総出力によって勝つものだ。そしてここに、最初から明白であるべきだったことがある。何ヶ月にもわたって安定して保たれた、ほどほどで持続可能なペースの総和は、クレーターで区切られた英雄的なスプリントの総和を、はるかに上回る。

スプリントのほうが速く感じられる。その瞬間においては、本当に速い。だがプロジェクトの実際の距離にわたって見れば、それははるかに遅い。墜落が、爆発が得たものよりも多くを奪うからだ。華々しい過労の一週間はいずれも、惨めな回復の二週間を買っただけで、その取引は、全期間にわたって正直に計算すれば常に損だった。私はその瞬間にどれだけ速く感じるかを最適化していた。それは、レースが何ヶ月という単位で測られるときには、まさに間違った変数だ。

休息は裏切りではなく、入力である

私を閉じ込めていたものの一部は、休息についての考え方だった。私はそれを作業の不在として扱った——進捗から盗まれた時間、罪悪感を覚えるべき贅沢、献身が足りない証拠として。だから私はそれを最小化し、最小化することに美徳を感じた。

だが、持続的な認知作業を行う有限のリソースにとって、回復は出力の対極ではない。それは出力に必要な入力だ。休息は作業から奪われる時間ではなく、そもそも作業を可能にしているものの一部なのだ。休息を拒むことは献身ではない。それは機械を保守せずに走らせ、避けがたい故障を、保守を省いたことの直接的で予見可能な結果としてではなく、運の悪さとして扱うことだ。私は、ひとつの要件を怠ることを、美徳と取り違えていたのだ。

オペレーターを前提に設計する

そこでようやく、私は長いあいだ避けてきた当たり前のことをやり始めた。それを動かしている人間の実際の制約を中心に据えてプロジェクトを設計すること——他のあらゆる現実の制約を前提に設計するのとまったく同じやり方で。立派に見えて崩壊で終わるペースではなく、本当に保てるペースを。悪い日のための意図的なバッファを——悪い日は必ずやってくるのだから。そして、自分自身の容量を、無限のエンジンに対して自分が及ばないものとしてではなく、有限で、変動し、保守できるものとして正直に計算すること。

これは最初、自分の基準を下げることのように感じられた。だが実際はその逆だった。それは、人間でできている部分も含めて、現実のシステムをついに真剣に受け止めることだった——その部分が決してなれないものを装うのをやめて。

より深い教訓——あなたがモデル化を拒む、そのボトルネックがあなた自身だ

結局のところ、こういうことだ。ほぼ一人で担われるどんなプロジェクトにおいても、その人物こそがシステム全体で最も重要なコンポーネントであり——そして、皮肉なことに、私たちが現実の、限りある、保守できるものとして扱うことを最も嫌がる相手でもある。私たちはコードを愛情込めて最適化し、オペレーターを容赦なく酷使する。そして、なぜ全体がいつまでも失速し続けるのかと首をかしげる。

だがプロジェクトは、オペレーターが動いているあいだしか進まない。そしてオペレーターは無限ではない。持続可能性は、本当の作業が終わってから手をつければいい、柔らかくて、任意で、自己満足的な飾りなどではない。それは、残りのすべての作業がその内側に収まらなければならない、硬い制約なのだ。私は長いあいだ、自分のシステムの最も重要な部分を、エンジニアリングに値しない唯一の部分として扱ってきた。プロジェクトはその過ちから逃げ切れなかった。そして、結局のところ、私自身もそうだった。

— シグナルもリターンも提供しない。投資助言ではない。