はじめに
私たちは「実力」という言葉を履き違えています。
特に私がそうでした。様々な人の助力で得た結果、たまたま条件が揃って出せた最高到達点を「自分の実力」だと勘違いしていました。そして、その水準に届かない日々の自分を見て、「なんでもっとできないんだ」と追い込んでいました。結果は散々なものでした。心身ともに疲弊し、パフォーマンスはさらに落ち、悪循環に陥りました。しかし、その経験から大きな学びもありました。
ゾーンに入り、神がかった速度でコードを書く自分。難解なバグを一瞬で特定する自分。私たちは、あの奇跡的な瞬間を「自分の実力」だと信じ、そうでない日を「調子が悪かった」と言い訳します。
逆です。
何もやる気が起きず、頭も回らず、ただ惰性でキーボードを叩いている日。その泥のような日に絞り出したアウトプット。それこそが、紛れもない私の「実力」です。 絶好調のときの成果は、再現性のない「運」や「上振れ」に過ぎません。
この記事では、なぜそう言えるのか、そしてその認識がなぜ重要なのかを考えていきます。これは鬱屈とした日々を過ごしていたかつての自分に向けて書いています。
「最高出力」という幻想
まず、私たちが「実力」だと思い込んでいるものの正体を見てみましょう。
過去半年を振り返ってみてください。「奇跡的にうまくいった日」は何日あったでしょうか。全てが噛み合い、コードがスラスラ書けて、レビューも一発で通り、障害対応も華麗にこなせた日。おそらく、片手で数えられる程度ではないでしょうか。
なぜそんなに少ないのでしょうか。理由は単純です。「最高のパフォーマンス」を出すためには、無数の条件を揃える必要があります。十分な睡眠。適度なストレス。興味のある課題。邪魔の入らない環境。体調の良さ。プライベートの安定。これらすべてが揃う日は、人生において稀なのです。
その稀な瞬間にしか出せないものを「実力」と呼ぶのは、ギャンブルで勝った日の収支を「年収」と呼ぶようなものです。 奇跡を前提にした人生設計は、破綻することが約束されています。それは本人にもコントロールできない「可能性の上限」であって、信頼できる「能力」ではありません。
私自身の話をしましょう。このブログには、いわゆる「おい、」シリーズと呼ばれる記事があります。「おい、本を読め」「おい、スマホを置け」「おい、対話しろ」。ありがたいことに、これらの記事は多くの人に読まれています。はてなブックマークでもたくさんのコメントをいただきました。Xをフォローしてくれている人は知っていると思うのですが4冊紹介するフォーマットも実力以上にアウトプットを出せたと思います。
しかし、正直に言いましょう。あれは私の実力からかなり上振れしています。
あの記事を書いたとき、たまたま言葉がスラスラと出てきました。たまたま自分の経験と文章のリズムが噛み合いました。たまたま読者の琴線に触れるタイミングでした。書籍レベルの何かを目指してブログとして色々出した。同じクオリティのものを、明日また書けるかと問われれば、自信を持ってイエスとは言えません。
あれが私の「実力」だと思い込んでしまうと、危険です。次に書く記事が同じように読まれなかったとき、「調子が悪かった」「本来の力が出せなかった」と言い訳をしてしまいます。しかし実際には、「おい、」シリーズの方が例外なのです。私の本当の実力は、誰にも読まれない記事を淡々と書き続けられるかどうか、そちらの方にあります。
では、なぜ私たちは「最高の自分」を実力だと思い込んでしまうのでしょうか。
それは、そう思いたいからです。「あれが本当の自分だ」と信じることで、今の不甲斐ない自分を一時的なものとして処理できます。「今日は調子が悪いだけ」という言い訳は、私たちの自尊心を守ってくれます。しかし、その言い訳に甘えていると、現実を直視する機会を失ってしまいます。
信頼は「下限」に支払われる
「最高の自分」を実力だと思い込むのは、自分一人の問題なら、まだいいかもしれません。しかし、私たちは一人で働いているわけではありません。
では、社会はどちらを評価するのでしょうか。「最高の自分」か、「最悪の自分」か。
仕事を誰かに頼むとき、私ならどちらを選ぶでしょうか。「調子が良ければ神がかったコードを書くが、悪ければ全く動かないものを出してくる天才」か、「どんなに最悪の状況でも、必ずそこそこ動くものは持ってくる凡人」か。
チームで働いていれば、答えは明らかです。前者はリスクであり、後者は計算できる資産です。天才は賭けられる。凡人は任せられる。 組織が求めているのは、後者です。
なぜでしょうか。仕事には締め切りがあります。依存関係があります。他のメンバーのスケジュールがあります。私の成果物を待っている人がいます。私が遅れれば、その人も遅れます。その人が遅れれば、次の人も遅れます。「今日は調子が悪いので」という言葉は、その連鎖の中では通用しません。
だから、周囲からの信頼とは、「最高の自分」ではなく「最悪の自分」に対して支払われます。
あのシニアエンジニアが信頼されているのは、華麗なワンライナーを書けるからではありません。障害が起きたとき、体調が悪いときでも、最低限の品質で対応を完了させるからです。レビューが溜まっているとき、モチベーションが上がらないときでも、的確なコメントを返すからです。「この人に任せれば、最悪でもこのレベルは下回らない」という安心感。それが信頼の正体です。
プロフェッショナルとは、派手なファインプレーをする人ではありません。どんな悪条件でも、期待された成果を淡々と、確実に納品できる人のことです。野球で言えば、たまにホームランを打つ選手ではなく、どんな状況でも確実にヒットを打てる選手。料理で言えば、たまに絶品を作る料理人ではなく、毎日安定して美味しいものを出せる料理人。派手さはありませんが、計算できます。それがプロです。
なぜマニュアル本を読んでも「床」は上がらないのか
「下限」が大事だということはわかった。では、どうすれば下限を上げられるのか。
その答えを求めて、私たちは成功者の話に耳を傾けます。本、セミナー、SNS。「こうすればうまくいく」と教えてくれる人はたくさんいます。しかし、残念ながら、それらは役に立ちません。
なぜでしょうか。成功とは「その人固有の条件」と「その時点での環境」が噛み合った結果であり、その組み合わせは二度と再現されないからです。10年のキャリアがあった人と、始めたばかりの人では前提が違います。たまたま有名な人にリツイートされた人と、そうでない人では運が違います。他人の成功パターンをコピーしても意味がありません。
だから、私たちがやるべきことは、誰かの成功法則を学ぶことではありません。自分自身の「下限」を把握し、その下限を少しずつ上げていく仕組みを作ることです。 それは誰にも教えてもらえません。自分で試行錯誤するしかないのです。
能力は文脈の中にしかない
他人の成功パターンをコピーしても意味がない。自分の下限を自分で上げていくしかない。そう書きました。
しかし、ここで少し立ち止まって考えたいことがあります。そもそも「能力」とは何なのでしょうか。私たちが上げようとしている「下限」とは、何の下限なのでしょうか。
私たちは「能力」を、自分の中に固定的に存在するパラメータのように考えがちです。技術力がいくつ、コミュニケーション力がいくつ、というように。しかし、私はそうは思いません。能力は、環境によって大きく変わるものです。
私は自分の技術力や業務遂行力を、完全に文脈依存だと思っています。ある環境では、私の思考パターンや働き方が完璧に噛み合い、高いパフォーマンスが出ます。しかし、別の環境では、私は無能になるでしょう。政治的な調整が最優先される組織や、レガシーな技術に固執する現場では、私の強みは発揮されません。
あのプロジェクトがうまくいったのは、自分の技術力が高かったからでしょうか。それとも、チームメンバーが優秀だったからでしょうか。上司が適切にスコープを切ってくれたからでしょうか。インフラが安定していたからでしょうか。ドキュメントが整っていたからでしょうか。締め切りに余裕があったからでしょうか。
その支えが消えた場合、同じクオリティを出せるでしょうか。
「自分には能力がある」と過信するのは危険です。正しい認識はこうです。「この文脈において、これまでの経験と仕組みが噛み合って、たまたま価値が出せている」。
この認識があれば、傲慢にはなれません。自分が成果を出せているのは、周囲の環境や、他者のサポートのおかげであるという事実が見えてきます。そして、その環境が変わったときに自分がどうなるかを、冷静に想像できるようになります。
たとえるなら、魚と水の関係に似ています。魚は水の中では自由に泳げますが、陸に上がれば何もできません。 私たちは常に、自分の能力が機能する「水」の中にいます。その「水」がなくなったとき、私たちは何もできません。
だからこそ、2つのことが必要だと私は思っています。1つは、自分に合った「水」を見つけること。自分の能力が活きる環境を選ぶこと。もう1つは、「水」がなくなったときにも最低限動けるように、自分の「下限」を上げておくことです。環境に恵まれなくても、最低限のアウトプットは出せる状態を作っておくこと。
「頑張り」という免罪符
能力は文脈に依存する。環境が変われば、同じ人間でも発揮できるパフォーマンスは変わる。だからこそ、自分に合った環境を見つけ、下限を上げる仕組みを作ることが大事だと書きました。
ここまで読んで、こう思った人もいるかもしれません。「環境だの仕組みだの言っているけど、結局は頑張れば何とかなるのではないか」と。
気持ちはわかります。私もそう思っていた時期がありました。しかし、残念ながら、そうではありません。
多くの人は、能力の不足を「頑張り」で埋めようとします。環境が悪くても、仕組みがなくても、気合で乗り越えようとします。私もそうでした。
しかし、「頑張り」は実力ではありません。
なぜそう言えるのでしょうか。思い返してみてください。「頑張っています」という言葉を、どんなときに使ったでしょうか。私の場合、成果が出ていないときほど、その言葉を使っていました。深夜まで残業した。休日も勉強した。ドキュメントも読んだ。だから許してほしい。
私も例外ではありません。締め切り前に焦って残業した経験は何度もあります。そのとき、「これだけやっているのだから」という気持ちが、どこかにありました。成果が出なくても、頑張った事実が自分を守ってくれるような気がしていました。
しかし、「これだけ苦労したのだから」という免罪符は、プロの世界では通用しません。 専門的な仕事に対する報酬は、流した汗の量ではなく、生み出した価値に対して支払われるからです。
私が「頑張ったのにできなかった」と最後に言ったのはいつだったでしょうか。その頑張りは、成果とどう結びついていたでしょうか。正直に振り返ると、「頑張り」と「成果」の間には、驚くほど相関がありませんでした。
もう少し踏み込んで考えてみましょう。なぜ「頑張り」は実力にならないのでしょうか。
人間の精神力や体力といった不安定なリソースに依存したシステムは、いずれ破綻するからです。徹夜で乗り切った。気合で押し切った。それは一時的には機能するでしょう。しかし、そのやり方は再現できません。翌週も同じことをやれと言われたら、身体が壊れます。翌月も同じことをやれと言われたら、心が壊れます。
「頑張り」で出した成果は、「最高の自分」と同じです。再現性がありません。だから、実力とは呼べないのです。来月も同じことができないなら、それは実力ではありません。
誤解しないでほしいのは、「頑張るな」と言いたいわけではないということです。踏ん張るべき時は、踏ん張らなければなりません。問題は、頑張ることそれ自体が目的化してしまうことです。方向を考えずにただ頑張る。成果ではなく、頑張っている姿勢で自分を守ろうとする。それは努力ではなく、努力のふりです。
目指すべきは「頑張らなくても成果が出る状態」です。 怠けることではありません。頑張りに依存しなくても回る仕組みを作ることです。そうすれば、本当に踏ん張るべき時に、余力を残しておけます。
環境構築という本当の能力
「頑張り」に頼らない。では、具体的に何をすればいいのでしょうか。
私なりの答えは、「最悪の自分でも動ける仕組みを作る」 ことです。
気力ゼロの日でも実行できる仕組みを、私はいくつ持っているだろうか。この問いを自分に投げかけたとき、意外なほど少ないことに気づきました。
エディタを開いたら自動でテストを走らせる。プルリクエストを出したら自動でレビュワーをアサインする。障害が起きたらアラートを飛ばし、対応手順書を自動で開く。毎朝同じ時間に、昨日のタスクの振り返りをSlackに届ける。毎週同じ曜日に、今週やるべきことをリストアップする。
これはすべて、最悪の状態でも最低限の品質を担保するための仕組みです。
私が目指しているのは、最悪の日でも自動的に手が動き、最低限のクオリティのものが出来上がってしまう状態を作ることです。意志の力で動くのではなく、意志がなくても動いてしまう仕組みを作る。これこそが「環境構築能力」であり、本当の意味での「実力」です。
逆に、仕組み化されていない行動を見てみましょう。
タスク管理ツールを開くのが面倒だから、頭の中で覚えておく。テストを書くのが面倒だから、動作確認は目視でやる。ドキュメントを書くのが面倒だから、後で誰かに聞けばいいと放置する。コードレビューを依頼するのが面倒だから、自分で何度も見直す。
これはすべて、調子が良いときにしか機能しないシステムです。調子が悪くなった瞬間、すべてが崩壊します。頭の中のタスクは忘れます。目視の確認は見落とします。誰かに聞こうと思っていたことは、聞きそびれます。
手を動かすまでのハードルはどこに潜んでいるでしょうか。それを仕組み化ではなく気合で乗り越えていないでしょうか。
私はそう思って、少しずつ仕組みを増やしてきました。
「人」を「環境」に合わせるな
仕組みを作る話をしてきました。しかし、仕組みを作ろうとするとき、多くの人がある罠にはまります。
「自分を変えなければ」という罠です。
たとえば、こんなふうに自分を責めていないでしょうか。「なぜ自分はこんなに集中力がないのか」。「なぜ自分はこんなにやる気が出ないのか」。「なぜ自分は普通の人のように働けないのか」。
その問いの立て方が、そもそも間違っています。
「人」を「環境」に合わせようとするから苦しくなります。「自分を変えなければ」「自分が適応しなければ」と考えるから、うまくいかない自分を責めてしまいます。
発想を逆転させるべきです。
「集中力がなくても成果が出る環境を作れないか」と考える。「やる気がなくても手が動く仕組みを作れないか」と工夫する。「普通の働き方ができなくても、自分なりの働き方で成果を出せないか」と模索する。
「障害」は人側にあるのではありません。環境側にあります。人を直すのではなく、環境を直す。それがエンジニアリングです。
これは、私たちエンジニアにとっては馴染みのある考え方のはずです。ユーザーがシステムを使いこなせないとき、「ユーザーの能力が低い」とは言いません。「UIが悪い」と言います。システムがユーザーに合わせるべきであって、ユーザーがシステムに合わせるべきではありません。
同じことが、自分自身にも言えます。自分という「ユーザー」が動きやすいように、自分の環境という「システム」を設計する。自分の弱点を克服しようとするのではなく、弱点があっても回るように環境を設計する。
私たちは日々、他者のためにシステムを設計しています。そのシステムが、特定の「正常」を前提にしていないでしょうか。最高のコンディションの人間しか使えないように設計されていないでしょうか。最悪の状態の人間でも最低限動けるように設計されているでしょうか。
自分自身の働き方も、同じように設計すべきです。「正常」な自分を前提にしない。「最悪」の自分でも回るように設計する。
弱さこそが、堅牢なシステムを作る
「人」を「環境」に合わせるのではなく、「環境」を「人」に合わせる。自分の弱点を克服しようとするのではなく、弱点があっても回るように環境を設計する。
そう書くと、まるで弱さを隠すための工夫のように聞こえるかもしれません。弱い自分を誤魔化して、なんとかやり過ごすためのハックのように。
しかし、私が言いたいのは、そういうことではありません。むしろ逆です。
弱さは、隠すものではありません。弱さこそが、堅牢なシステムを作るための仕様書になります。
私たちは誰でも、何かしら「苦手なこと」を抱えています。朝が弱い。人前で話すのが苦手。細かい作業が続かない。逆に、一度集中すると周りが見えなくなる。そういった、ごく普通の凸凹です。
「このエラーメッセージは不親切だ」と感じるのは、かつて自分が同じような場面で困った経験があるからです。「このドキュメントはわかりにくい」と感じるのは、かつて自分がわからなくて苦しんだ経験があるからです。「このUIは使いにくい」と感じるのは、かつて自分が同じように躓いた経験があるからです。
欠損は、視点を生みます。 困った経験は、問題を発見する能力になります。痛みを知っているからこそ、他者の痛みに気づけます。うまくいった人には、うまくいかない人の気持ちがわかりません。
私自身、そうでした。「正常」に適応できていた頃の私には、「正常」の問題点が見えませんでした。システムにうまく乗れていた頃の私には、そのシステムから弾かれる人の存在が見えませんでした。自分が躓いて初めて、躓く人のための設計ができるようになりました。
だから、過去の「苦手」を恥じる必要はありません。それは、視点の源泉です。「最悪の自分」を知っているからこそ、「最悪の状態でも動けるシステム」を設計できるのです。 自分のバグを知り尽くしているからこそ、バグに強いシステムを作れます。
評価されるとは、下限が固定されること
ここまで、「下限を上げることが大事だ」と書いてきました。自分の苦手を知り、それを視点として活かし、最悪の状態でも動ける仕組みを作る。それが実力になると。
ここまで読むと、「じゃあ下限を上げ続ければいいんだな」と思うかもしれません。しかし、話はそう単純ではありません。ここで1つ、厄介な問題について触れておかなければなりません。
キャリアを積み、シニアになり、周囲から「できる人」として扱われるようになると、ある種の息苦しさが生まれます。「あの人ならこのレベル」という期待。それは信頼の証であると同時に、私たちを縛る鎖でもあります。
評価されるということは、自分の「下限」が社会的に可視化され、固定されることを意味します。
そして、ここに厄介な問題があります。下限が固定されると、それを下げることが許されなくなるのです。
本来、下限を上げていくためには、一時的に下限を下げる必要があります。これは矛盾しているように聞こえるでしょうが、考えてみれば当然のことです。
新しい領域に挑戦すれば、最初は当然うまくいきません。慣れない技術を使えば、普段の半分のクオリティしか出せません。未経験の役割を引き受ければ、しばらくは無能に見えます。
たとえば、10年間Javaを書いてきたエンジニアがRustを学び始めたとします。最初の数ヶ月、その人の「下限」は確実に下がります。Javaなら寝ぼけていても書けたコードが、Rustでは何時間もかかります。しかし、その一時的な後退を経て、やがてRustでも安定した成果を出せるようになります。同様に、初めてチームリーダーを務める人は、最初は判断を誤り、メンバーとの関係構築に苦労するでしょう。しかし、その経験を経て、リーダーとしての「下限」が形成されていきます。
これは成長のための必要なコストです。一時的に下がった下限は、経験を積むことで元の水準を超えていきます。
しかし、「あの人ならこのレベル」という期待が固定されてしまうと、その期待を下回ることが許されなくなります。失敗が許されません。実験が許されません。成長のための一時的な後退が、信頼の毀損として記録されてしまいます。
だから私は、仕事を選ぶようになりました。自分の下限が確実に通用する領域、自分のシステムが機能する文脈を選ばざるを得なくなりました。「結果を出す以外の選択肢がない」状況で、わざわざ未知の領域に踏み込むリスクを取れなくなりました。
これは成長の鈍化を意味します。安全圏に留まり続けることで、下限は維持されますが、それ以上には上がりません。
皮肉なことに、「信頼される」ことが「成長できなくなる」ことと表裏一体になっています。 評価されることの代償は、挑戦する自由を失うことです。期待に応え続けることと、成長し続けることは、両立しません。
だからこそ、意識的に「失敗してもいい場所」を確保しておく必要があります。誰にも見せないプロジェクト。評価と切り離された実験。下限を一時的に下げることが許される、安全な砂場。それがなければ、私たちは自分の「実力」に閉じ込められてしまいます。
余白がなければ成長できない
評価されることで挑戦する自由を失う。「失敗してもいい場所」を意識的に確保しなければならない。
ここまで書いてきて、気づいたことがあります。これは私個人の問題ではありません。もっと広い話です。
「下限」の問題は、個人だけで解決できるものではありません。
先ほど書いたように、下限を上げるためには、一時的に下限を下げる必要があります。新しいことに挑戦すれば、最初は失敗します。失敗が許されない環境では、挑戦ができません。挑戦ができなければ、成長もできません。
つまり、成長には「余白」が必要なのです。
「余白」とは何でしょうか。失敗しても致命傷にならない空間のことです。期待値を下回っても、信頼が毀損されない関係性のことです。最悪の状態を見せても、それを受け入れてもらえる場所のことです。
エンジニアは強くなければならない。弱音を吐いてはいけない。立ち止まってはいけない。誰よりも速く学び、誰よりも多くのコードを書き、誰よりも深く技術を理解する。その強迫観念は、私たちを奮い立たせるガソリンであると同時に、余白を奪う呪いでもあります。
常に100%を出し続けなければならない。そう思い込んでいる人は多いです。しかし、100%を出し続けることは、人間には不可能です。そして、100%を要求される環境では、人は80%の自分を見せることを恐れます。80%の自分を見せることを恐れるから、新しいことに挑戦できません。新しいことに挑戦できないから、100%のまま停滞します。完璧主義は、成長の敵です。
「挑戦しろ」と背中を押す一方で、いざ失敗すれば「自己責任」の名の下に切り捨てる。そんな構造の中では、誰も本当の意味での挑戦ができません。みんな、自分の下限が確実に通用する範囲でしか動かなくなります。結果として、組織全体の成長が止まります。
だから、「余白」は個人で確保するだけでなく、チームや組織として設計する必要があります。
「最悪の日でも最低限の成果を出せる環境」を作るのは、個人の努力だけでは限界があります。チームとして、組織として、メンバーの「下限」を支える仕組みを作る。失敗を許容する文化を作る。一時的な後退を、成長のための投資として認める空気を作る。
それが本当の意味での「強いチーム」です。 全員が常に100%を出し続けるチームではありません。誰かが50%しか出せない日があっても、チーム全体としては回るように設計されたチームです。
個人の「下限」を上げる努力と、組織として「余白」を確保する努力。この両方が揃って初めて、持続的な成長が可能になります。
床を1ミリずつ上げていく
ここまで、長々と書いてきました。
「最高の自分」ではなく「最悪の自分」が実力である。信頼は下限に支払われる。能力は文脈に依存する。頑張りは実力ではない。環境を設計する。弱さを視点にする。評価は下限を固定する。成長には余白が必要。
いろいろ書きましたが、言いたかったことはシンプルです。「能力」の定義を変えてほしい、ということです。
「最高のときに出せるもの」から「最悪のときにも出せるもの」へ。
自分の状態がベストであることを前提にしない。10分の1のコンディションでも形になるように設計する。緊張しても、失敗しても、体調が悪くてもいい。そのボロボロの状態から這いつくばって出したアウトプットだけを見る。それが、今の私の揺るぎない実力です。
絶望する必要はありません。自分の「下限」、つまり床がどこにあるかを知っていれば、その床の上にレンガを積んでいくことができます。
半年前の自分は、最悪の日に何ができていなかったでしょうか。タスク管理は頭の中だったでしょうか。テストは書いていなかったでしょうか。ドキュメントは後回しにしていたでしょうか。今はそのうち、どれだけ自動化・習慣化されているでしょうか。
継続とは、平均値を上げることではありません。この床を1ミリずつ底上げしていく作業のことです。
派手な成功は、運です。華々しい成果は、上振れです。 そんなものを基準にしてはいけません。運は二度来るとは限りませんが、仕組みは何度でも動きます。
淡々と、最悪の日でも最低限のことをやる。その積み重ねだけが、誰にも奪われない実力になります。いつかその床の高さが、誰かの天井を超えたとき、私は誰からも信頼されるプロフェッショナルになっているはずです。
おわりに
最後に、この記事自体の話をさせてください。
この記事を書きながら、私自身も自分の「下限」と向き合っています。
正直に言えば、この文章を書いている今日も、絶好調とは言えません。頭がぼんやりして、言葉がすぐに出てきません。何度も書いては消し、消しては書いています。「おい、」シリーズのように言葉がスラスラ出てくる日ではありません。
しかし、それでいいのです。
この記事の価値は、私が絶好調のときに華麗な文章を書けることではありません。調子が悪い日でも、キーボードへ向かい、一文字ずつ積み上げ、最後まで形にできるかどうか。それこそが、私の「書く実力」です。
冒頭で書いたように、私はかつて「最高の自分」を実力だと勘違いし、そこに届かない自分を責め続けていました。なんでもっとできないんだ、と。鬱屈とした日々を過ごし、心身ともに疲弊し、パフォーマンスはさらに落ちました。
この記事は、あの頃の自分に向けて書きました。伝えたいのは、「基準が間違っている」ということです。私たちは、自分の「最高の瞬間」に執着しすぎています。あの日の自分、あのプロジェクトでの自分、あの輝いていた自分。しかし、その輝きは再現できません。再現できないものを基準にすれば、永遠に自分を肯定できません。
だから、視点を変えました。
最悪の日に、机に向かえるか。最悪の状態で、最低限のものを出せるか。その「下限」こそが、私の本当の実力です。そしてその下限は、仕組みと環境と、少しずつの積み重ねで、確実に上げていくことができます。
派手な成功を追いかける必要はありません。ただ、最悪の日でも崩れない床を、1ミリずつ上げていけばいいのです。
その床の高さが、いつか私を支えます。誰にも奪えない、揺るぎない実力として。
そして、もう1つ。
自分の弱さを恥じる必要はありません。その弱さがあったからこそ、私は「自分を助けるための仕組み」を発明できました。その仕組みは、いずれ同じ弱さを持つ誰かを救うことになります。私の「最悪の日」の対処法は、誰かにとっての「最高のノウハウ」になります。
自分の下限を知ることは、諦めではありません。出発点です。
