ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について

はじめに

「才能がない」と言われたことがあるでしょうか。それとも、友人や知り合いと自分を比べて、自分で自分にそう言い聞かせたことがあるでしょうか。

学生の頃からエンジニアを志してきた私は、コンテストで優秀な成績を残す人たちを目の当たりにしてきました。大手IT企業に入社し、優秀な同期と出会いました。勉強会やカンファレンスに足を運び、そこで出会った人たちの軌跡を追ってきました。

華々しくスタートアップを立ち上げた人、革新的なプロダクトを生み出した人、OSSコミュニティで名を馳せる人。一方で、いつの間にか表舞台から姿を消した人もいます。これらがごく一部の狭い世界でしかないことも、自覚しています。

そして今、インターンシップやワークショップで若手エンジニアと接する機会が増えました。3年ほど前に始めたこの活動──正直に言うと、自分が未熟なまま始めてしまったという不安は、今でもどこかにあります。

彼らと一緒に作業する中で、「才能がない」と自己評価する学生やインターン生に出会うことがよくあります。彼らは真剣な表情で「自分には向いていないかもしれません」と告げます。コードを書くのが遅い。エラーの意味が理解できない。他の人は簡単にできることが、自分には難しい──そう語る彼らの目には、諦めと不安が混じっています。

私はその度に、ある問いを投げかけます。「才能って、何だと思う?」

「君には才能がある」とも「才能なんて関係ない」とも言わず、まず考えてもらう。しかし大抵の場合、明確な答えは返ってきません。

実は、私もかつて、才能という言葉に深く囚われていました。

コンテスト会場で、企業の開発フロアで、勉強会の懇親会で、私は何度も「天才」と呼ばれるエンジニアたちに出会いました。彼らは難解なアルゴリズムを一瞬で理解し、複雑なバグを数分で特定し、誰も思いつかないような解決策を次々と生み出していました。そして私は何度も思いました。「自分には才能がない」と。

しかし、多くの「一流」と呼ばれる人々と接し、彼らの日常を観察し、そして時には彼らが立ち止まる瞬間や、消えていく瞬間も目撃する中で、ある重要な事実に気づきました。

才能という言葉は、実は成長を阻む最大の敵なのかもしれない。

このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。

技術力という幻想

才能について語る前に、まずソフトウェアエンジニアリングにおける「技術力」とは何かを整理しておく必要があります。我々の文脈では、才能という言葉はこの技術力と結びつけて語られることが多いためです。

技術力という言葉の曖昧さ

私たちは「技術力が高い」「技術力が低い」という言葉を安易に使いがちです。しかし、その実態は何でしょうか。

率直に言えば、ソフトウェアエンジニアの「技術力」と呼ばれるものの多くは、実は「ちょっと詳しい」「似たようなトラブルを経験している」「これとこれを組み合わせれば行けそう」という程度のものです。

私が使ってきた「エンジニアリング」という言葉にも、工学的な要素はあまり含まれていませんでした。正しくは「テクニック」──つまり、実践的な技術や方法論の集積です。特別なスキルというよりは、日々の積み重ねで身につく経験知なのです。

では、技術力とは何なのか。私の観察では、それは大きく二つの軸に分解できます。一つは「経験の蓄積」、もう一つは「洞察力としてのセンス」です。

センスは知識からはじまる

第一の軸：経験の蓄積

技術力の第一の要素は、経験の蓄積です。これは、しばしば「同じ失敗を繰り返さない力」として評価されます。

具体的には、こういうことです。あるエラーに遭遇したとき、以前に似たようなエラーを見たことがあれば、解決は早くなります。データベースのデッドロック、非同期処理のタイミング問題、キャッシュの不整合──こうした問題は、一度経験していれば「ああ、これか」と気づけます。

これは確かに価値のある能力です。経験豊富なエンジニアが重宝されるのは、このためです。

しかし、これを「才能」と呼ぶのは適切でしょうか。違います。これは単に時間をかけて様々な問題に向き合った結果であり、誰でも積み重ねられるものです。早く始めた人、多く失敗した人が、より多くの経験を持っているだけです。

具体と抽象

第二の軸：洞察力としてのセンス

技術力のもう一つの要素、それが「センス」です。

音楽をやっている人たちの中で「あいつは耳が良い」と評価される能力があります。単に楽器を弾く技術だけでなく、音のバランス、リズムの微妙なズレ、和音の響き方──こうした細部を感じ取る力のことです。

ソフトウェアエンジニアリングにも、これに似たものがあります。

コードを見たとき、「このコード、何か変だな」と直感的に感じる。実行する前から「ここでバグが出そう」と予感する。設計図を見て「この構造は将来的に問題になる」と察知する。

これが、エンジニアにおける「センス」です。

重要なのは、これは単なる経験の蓄積とは質的に異なるということです。同じ年数働いていても、このセンスを持つ人と持たない人がいます。では、このセンスとは何なのでしょうか。

センスの哲学 (文春e-book)

センスの正体──三つの具体的な現れ方

センスは抽象的な概念に聞こえますが、実は具体的に分解できます。私の観察では、センスは主に三つの形で現れます。

1. 細部への注目力

センスのあるエンジニアは、コード全体の機能だけでなく、細部のリズムやバランスに気づきます。

例えば、関数の長さのバランス。あるファイルに25行の関数と5行の関数が混在しているとき、「なぜこの差があるのか」と気づきます。命名の一貫性。ある場所ではgetUserDataと書き、別の場所ではfetchUserと書いているとき、その揺らぎに違和感を覚えます。

これらは動作に直接影響しないこともあります。でも、コードの「匂い」として現れます。そして、この匂いに気づけるかどうかが、センスの有無を分けます。

ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

2. 構造の美しさへの感受性

センスのあるエンジニアは、「美しいコード」と「醜いコード」を区別できます。そして最も重要なのは、なぜ美しいと感じるのか、その理由を言語化できることです。

「この関数は単一責任原則を守っているから美しい」 「この命名は意図が明確に伝わるから良い」 「この抽象化は読みやすさと柔軟性を両立しているから綺麗」

単に「良い」「悪い」と感じるだけでなく、その判断の根拠を意識できる。これがセンスです。そして、この言語化能力が、他者にも伝えられる知見へと昇華されます。

Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考

改訂新版　良いコード／悪いコードで学ぶ設計入門 ―保守しやすい　成長し続けるコードの書き方

3. 問題の本質を見抜く力

最も価値が高いのは、表面的な問題の背後にある本質的な問題を見抜く力です。

例えば、バグが報告されたとします。表面的には「nullポインタ例外」かもしれません。しかし、センスのあるエンジニアは、その背後に「状態管理の設計が不適切」という本質的な問題があることに気づきます。

エラーログを見て、「このエラーが頻発しているということは、そもそもこの処理フローに問題がある」と洞察します。パフォーマンスの問題を見て、「これは単にクエリの最適化の問題ではなく、データモデルの設計から見直すべき」と判断します。

この「一歩踏み込んで問題を捉える力」こそが、経験を超えたセンスの核心です。

ライト、ついてますか　問題発見の人間学

センスは訓練できるのか

ここまで読んで、「じゃあセンスは才能じゃないか」と思うかもしれません。

違います。センスも訓練できます。

なぜなら、センスとは突き詰めれば「何に注目するか」という習慣と、「それを面白がれるか」という姿勢だからです。どちらも意識的に育てることができます。

熟達論―人はいつまでも学び、成長できる―

訓練法1：意識的な観察の習慣

最初は意識的に練習します。コードレビューをするとき、ただ「動くか動かないか」だけでなく、以下の点に注目してみます。

• 関数の長さのバランスは適切か
• 命名に一貫性はあるか、揺らぎは意図的か
• 抽象度の上下動に違和感はないか
• コメントの密度は適切か
• 変数のスコープの範囲は適切か

最初は面倒です。でも、こうした細部に意識的に注目する習慣を続けていると、やがて自然と細部が目に入るようになります。これがセンスを磨くということです。

訓練法2：本質を掴む読み方

優れたエンジニアのコードを読むとき、ただ写経するのではなく、その背後にある思考を読み取ろうとします。

• なぜこの構造を選んだのか
• なぜこの命名にしたのか
• なぜこの順序で処理しているのか
• なぜこの部分だけ抽象化したのか

そして、そこから本質的な要素を抽出し、自分のコードに応用する。この「本質を掴む」プロセスを繰り返すことで、表面的なパターンの暗記を超えた理解が生まれます。

訓練法3：面白がる回路を作る

最も重要なのは、問題を面白がる姿勢を育てることです。

センスのあるエンジニアは、エラーや問題を「厄介だ」ではなく「興味深い」と捉えています。この姿勢は、選択できるものです。

最初は意識的に「これは面白い」と自分に言い聞かせます。

「このバグ、再現条件が複雑で面白い」 「このエラーメッセージ、何を伝えようとしているのか興味深い」 「この設計の問題、どう解決すべきか考えるのが楽しい」

こうした「面白がる回路」を作ることが、センスを磨く本質です。すると徐々に、本当に面白く感じられるようになってきます。そして、面白がれるようになると、自然と深く考えるようになり、結果としてセンスが磨かれます。

技術力もセンスも、どちらも成長可能

結局のところ、技術力を構成する二つの軸──経験の蓄積とセンスという洞察力──は、どちらも成長可能な能力です。

経験は、時間をかけて多くの問題に向き合うことで自然と積み重なります。失敗を恐れず、様々なことに挑戦することで、経験値は増えていきます。

センスは、意識的な訓練によって磨かれます。細部に注目し、本質を掴もうとし、問題を面白がることで、徐々に洞察力が深まっていきます。

どちらも「才能」という固定的な能力ではありません。時間と意識的な努力によって育てられるスキルなのです。

「あの人は技術力がある」と言われる人は、単に先に始めて多くの経験を積んだか、意識的にセンスを磨く習慣を持っているか、あるいはその両方です。

そして、その両方とも、今からでも始められます。

才能という名の逃避

「才能がない」という言葉は、一見すると謙虚に聞こえます。しかし実のところ、これは危険な自己欺瞞です。

なぜなら、才能という言葉を使った瞬間、私たちは変化の可能性を放棄してしまうからです。「才能がないからできない」は、「努力してもどうせ無理」と同義です。そして一度この思考に陥ると、成長のための努力そのものが無意味に思えてきます。

私自身、新人時代にこの罠に嵌っていました。新しい技術概念と格闘していた頃、何度もこう思いました。「自分にはこの考え方を理解する才能がないのだろう」と。そしてその思考は、学習を放棄する口実となりました。難しいドキュメントを読むことを避け、エラーメッセージと真剣に向き合うことから逃げました。

でも、ある時気づきました。私が「才能がない」と諦めていた領域で活躍している先輩たちも、実は最初から理解していたわけではありませんでした。彼らは単に、私が避けていた苦痛と向き合い続けていただけだったのです。

私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)

性格と人格

才能を考える上で、重要な区別があります。それは性格と人格の違いです。

性格とは、通常の日にどう反応するか──つまり、私たちの自然な傾向や気質のことを指します。一方で人格とは、困難な日にどう振る舞うか──つまり、意図的に選択される態度や行動のことです。

この区別は、才能という概念を理解する上でとても重要です。私たちはよく、性格と人格を混同してしまいます。「私は物覚えが悪い」「集中力がない」「創造性がない」──これらは一見すると先天的な限界のように聞こえます。しかし実際には、これらの多くは人格、つまり訓練可能な能力の領域なのです。

例えば、「集中力がない」と自己評価する人の多くは、実は集中する環境や方法を知らないだけかもしれません。スマートフォンの通知をオフにし、作業を25分単位に区切り、定期的に休憩を取る──こうした具体的な方法を実践することで、「集中力」は劇的に向上します。

重要なのは、こうした能力を「才能」ではなく「性格スキル」として捉え直すことです。才能は固定的で変えられないものですが、スキルは練習によって向上させることができます。この視点の転換が、成長への扉を開くのです。

世界一やさしい「才能」の見つけ方　一生ものの自信が手に入る自己理解メソッド

不快感という成長の証

才能という幻想から抜け出すために、もう一つ重要な認識があります。それは、学習における不快感の本質的な役割です。

「快適に学べる」というのは、実は矛盾した概念かもしれません。スキルを真に習得するまで快適にはなれないのですが、習得する前の練習は必然的に不快だからです。そして人は、その不快感を避けようとします。これが、多くの人が成長の途中で挫折する根本的な理由です。

Docker最適化の学習を例に取りましょう。BuildKitのキャッシュ戦略を理解しようとするとき、最初はかなり混乱します。レイヤーの仕組み、マウントの種類、キャッシュの無効化条件──これらの概念は最初、全く繋がらない断片として現れます。この混乱は不快です。だから多くの人は、「とりあえず動けばいい」と表面的な理解で妥協します。

しかし、この不快感こそが成長の証なのです。脳が新しい構造を構築しようとしている証。既存の理解の枠組みが崩れ、新しい理解が生まれつつある証です。この不快感から逃げずに、むしろそれを「成長が起きている」というサインとして受け入れられるかどうか──それが、習得できる人とできない人を分ける分岐点になります。

「快適なら、やり方が間違っている」という言葉があります。この言葉は、学習の本質を突いています。本当の成長は、常にコンフォートゾーンの外側で起きるのです。

ネガティブ・ケイパビリティ　答えの出ない事態に耐える力 (朝日選書)

才能がないと言う前に

インターンシップやワークショップで若手と一緒に作業をしていて気づいたことがあります。「才能がない」と自己評価する人の多くが、実は才能の問題ではなく、もっと基礎的なプロセスを飛ばしているだけだということです。

syu-m-5151.hatenablog.com

ドキュメントを読んでいない

「自分には向いていない」と言う学生がいました。コードがうまく動かないし、エラーが理解できないと。しかし彼は、エラーメッセージを実際には読み飛ばしていたのです。

エラーメッセージには「Expected type X, but got type Y」と明確に書いてあります。しかし「type X」という文字列だけを拾って、期待される型と実際の型が違うという関係性を読み取っていませんでした。

これは彼だけの問題ではありません。ドキュメントを「読んでいるつもり」でも、実際には自分の仮説に都合のよい部分だけを拾い読みしている人は驚くほど多いのです。APIのリファレンスに「このメソッドは非同期です」と書いてあっても、Promiseを返すのか、コールバックを受け取るのか、await可能なのか──書かれているはずの詳細を読んでいません。

仮説を一つずつ潰していない

別の学生は「バグが見つからない」と何時間も格闘していました。しかし彼は、複数の仮説を同時に追いかけて、どれも中途半端に確認していたのです。「ネットワークの問題かもしれない」と言いながらネットワークのログを確認せず、「データベースの問題かもしれない」と言いながらクエリを確認しない。

問題解決には、仮説を一つずつ潰していくプロセスが必要です。この地道なプロセスを飛ばして、「なんとなく」で進めようとするから、何時間経っても解決しないのです。

仮説行動――マップ・ループ・リープで学びを最大化し、大胆な未来を実現する

主語と述語を把握していない

技術文書を読むとき、主語と述語の関係を曖昧にしたまま読み進めている人は非常に多いのです。「誰が」「誰に」「何を」しているのか──この基本的な構造を把握しないまま、「なんとなく」で理解したつもりになっています。

小さなことの積み重ね

エラーメッセージをちゃんと読む。仮説を一つずつ潰す。主語と述語を把握する。誰でもできることです。しかし、この「小さなこと」の積み重ねが、「才能がある」ように見える人と「才能がない」と思い込む人を分けています。

才能があるように見える人は、これらの基礎的なプロセスを、意識的か無意識的に実践しています。これらは訓練可能です。才能ではありません。最初は意識的にやる必要があります。めんどくさいと感じるかもしれません。でも、この「めんどくさい」基礎作業を飛ばすから、結果的に何倍も時間がかかってしまうのです。

なぜ、ちゃんと読めないのか

「ちゃんと読むことによる成功体験」が積めていない──これが、根本的な問題かもしれません。

奪われた集中力: もう一度〝じっくり〟考えるための方法

インスタント化と「モヤモヤ」への耐性の喪失

私たちは今、インスタントで断片的な刺激に取り巻かれています。YouTubeのレコメンド、TikTokの短い動画、LINEスタンプ──一定のリズムで繰り返されるインスタントで分かりやすい感覚やコミュニケーションが蔓延しています。スマホを持つことで、即時的な満足にいつでもアクセスできる状態にあり、「消化しきれなさ」「難しさ」「モヤモヤ」といった時間もコストもかかるものは人気がなくなっています。

技術ドキュメントを読むことは、まさにこの「モヤモヤ」との戦いです。一読してすぐに理解できるものではありません。何度も読み返し、実際に試し、エラーに出会い、また読み返す。この時間のかかるプロセスが、インスタント化した感覚に慣れた私たちには耐えがたいのです。

新しい技術を学ぶとき、最初は「モヤモヤ」します。でも、このモヤモヤした状態を抱えたまま、読み続け、試し続けることでしか、深い理解には到達できません。ChatGPTやClaudeに「要約して」と頼んでしまう。確かに、それでスッキリはします。でも、その過程で失われるものがあります。

孤独と孤立の喪失

スマホによる常時接続の世界では、何か一つのことに取り組み、一つのことに没頭する＜孤立＞が喪失しています。反射的なコミュニケーションを積み重ねるということは、相手の人格や心理状態を想像しないコミュニケーションです。同時に、退屈に耐えきれず、何か刺激やコミュニケーションを求めてスマホをいじってしまい、自分一人で時間を過ごす＜孤独＞も失われかけています。

スマホ時代に必要なのは孤独と孤立であり、それらがあってこそ、自分を浸している感覚に耳を澄ませ、刺激的な経験と折り合いをつけることができます。技術ドキュメントを読むことは、まさにこの「孤立」を必要とします。一人で、ドキュメントと向き合う時間。このシンプルな行為が、現代では驚くほど難しくなっています。

ネガティブ・ケイパビリティの欠如

ネガティブ・ケイパビリティとは、「結論づけず、モヤモヤした状態で留めておく能力」です。把握しきれない謎をそのまま抱えておくことで、そこから新しい何かをどこまでも汲み取ろうとする姿勢のことです。これは、他者の経験を理解したり、技術を学んだりするときに必要です。謎を安易に「自分のわかる範囲」に回収しない能力と言えます。

新しい技術を学ぶとき、すぐに「わかった」と思いたくなります。でも実際には、わかっていないことだらけです。このモヤモヤした状態を抱えたまま、読み続け、試し続ける。この能力が、現代人には欠けているのかもしれません。

自己啓発の罠と他者の想像力

悩みや困難を抱えている人は、「自分の直観に従って判断しろ」「自分の情熱に従え」というメッセージに心を揺さぶられます。しかし、このアプローチには内なる声は一つであり、その声こそ自分を然るべき一つの進路へと導いてくれるはずという前提があります。他者の想像力は、「ノイズ」としてラベリングされてしまいます。

私たちは、一枚岩のような存在ではありません。自分の内側にはいくつもの声が発せられています。「他者に見られる自分」も自分の重要な構成要素となるので、他者はノイズどころか、自分を豊かに育てるものです。

「才能がない」という言葉も、実はこの自己啓発の罠と表裏一体です。「才能がないから無理」は自己責任の裏返しです。でも実際には、他者の想像力を借りること、ドキュメントを丁寧に読むこと、先輩に質問することは、ノイズではなく成長の糧なのです。

「自分の頭で考える」の代わりに、「他人の頭で考える」「他者の想像力を自分に取り入れる」ことが大切です。

才能ではなく、学び方の問題

「才能がある」と見なされる人々を注意深く見ると、彼らの多くは特別な能力を持っているわけではありません。彼らは効果的な学び方を知っているだけなのです。

例えば、指摘と助言の違いを理解している人は、より速く成長します。「このコードのどこが悪いですか?」は指摘を求める質問で、過去の実績に焦点を当て、しばしば批判的な応答を引き出します。一方で「このコードをより保守性の高いものにするにはどうアプローチすべきでしょうか?」は助言を求める質問で、未来に焦点を当て、建設的な提案を引き出します。

この小さな違いが、学びの質を大きく変えます。才能があるように見える人は、こうした学び方の技術を実践しています。彼らは「分からない」と素直に認め、「教えてください」と謙虚に頼み、そして得られた助言を素直に実践します。これは才能ではなく、態度の問題なのです。

学びとは何か－〈探究人〉になるために (岩波新書)

後退も成長のプロセスの一部

才能という概念を手放すと、もう一つ重要な認識が生まれます。それは、成長が必ずしも直線的ではないということです。

私たちは、成長を一方向的な進歩として捉えがちです。しかし実際の成長は、螺旋を描くように進んでいきます。前進し、停滞し、時には後退し、そしてまた前進します。この後退期を「才能がない証拠」として捉えるか、「成長のための再編成」として捉えるかで、その後の軌道は大きく変わります。

技術を学ぶ過程でも、この現象は頻繁に起きます。新しいフレームワークを学び始めた当初は順調に進みます。しかし、ある程度理解が深まると、突然全てが分からなくなる瞬間が来ます。これは実は、表面的な理解から深い理解へと移行する兆候なのです。しかし多くの人は、この瞬間を「やはり自分には才能がない」と解釈し、学習を放棄してしまいます。

人は前進するために時に立ち止まり、後退し、そしてまた前進した先には以前よりも大きく飛躍しています。このプロセスを理解することで、停滞期や後退期を前向きに捉え直すことができます。それは失敗ではなく、次の飛躍のための準備期間なのです。

手を動かすことの救い

エンジニアという仕事には、一つの大きな救いがあります。それは、手を動かしている間、才能への不安が消えるということです。

「自分には才能がない」という悩みは、頭の中でぐるぐる回り始めると、どんどん大きくなります。でも「これを作りたい」と思って実装を始めた瞬間、その悩みはどこかに消えます。目の前にあるのは、具体的な問題だけです。

エラーが出る。調べる。解決する。また詰まる。また調べる。この「詰まる→調べる→解決する」のサイクルを回すこと自体が、静かに自信を育てていきます。最初は1つのエラーに1時間かかったのが、30分になり、10分になる。その変化を実感するとき、「成長している」という手応えが得られます。

理想ではなく、作りたいものを追う

重要なのは、「優秀なエンジニアになりたい」という抽象的な目標ではなく、「このアプリを作りたい」「この機能を実装したい」という具体的な目標に向かって手を動かすことです。

完璧主義に陥る人は、結果に過度な完成度を求めるあまり、小さな一歩を踏み出せません。「理想的なアーキテクチャを設計してから始めよう」「全ての技術を理解してから作ろう」──そう考えて、結局何も始められない。

でも実際には、小さく作って、動かして、直して、また作る。このサイクルを回すことでしか、良いものは生まれません。一つのエラーを解決する。一つの機能を実装する。一つのテストを通す。この小さな積み上げが、気づけば大きなものになっています。

綿密な計画よりも、不完全でも動く一歩の方が、はるかに価値があります。

あえて視野を狭めろ

ここで、少し逆説的なことを言います。特に若い時期には、根拠がなくても、自分を信じることが重要です。

「才能という幻想」を批判してきたこの記事で、矛盾するように聞こえるかもしれません。しかし、「自分には才能がある」という固定的な思い込みと、「自分はできるようになる」という成長への信頼は、全く別物です。

若いうちは、視野をあえて狭めることも必要です。「これが本当に正しい道なのか」「自分に向いているのか」──そんな冷静な自己分析ばかりしていると、一歩も踏み出せなくなります。時には、根拠のない自信を持って、盲信的に突き進むことも必要です。

「プログラミングなんて簡単だろう」という、ある意味で無知ゆえの大胆さ。この「若気の至り」とも言える姿勢が、最初の一歩を踏み出させてくれます。

その盲信的な姿勢が、いつか本当の自信に変わります。根拠のない自信が、実績という根拠を伴った自信になります。そして気づけば、最初は「嘘」だった「自分はできる」という言葉が、本当になっているのです。

問題を面白がる力

もう一つ、見落とされがちな視点があります。それは、学びにおける遊び心です。

才能があるように見える人は、実はこの遊び心を持っています。彼らは学びを苦痛として捉えるのではなく、謎解きとして楽しんでいます。新しいバグに出会えば「面白い現象だ」と興味を持ち、理解できない概念に出会えば「理解できたら面白そうだ」と好奇心を抱きます。

この姿勢は、才能ではなく選択です。同じ状況を「苦痛」として捉えるか「挑戦」として捉えるか──その選択が、長期的な成長の軌道を決めます。そして、この選択は意識的に訓練できます。

義務として学ぶのではなく、探究心を持って取り組むとき、人は最も成長します。

ぐちゃぐちゃ考える暇があったら

才能があるかどうかなんて、作っているときには関係ありません。目の前のエラーメッセージは、あなたが才能があるかどうかなんて気にしていません。ただ、解決策を求めているだけです。

ドキュメントを読む。エラーメッセージをちゃんと読む。仮説を立てて検証する。うまくいかなければ別の方法を試す。これらは全て、才能ではなく、プロセスです。

コンテストで優秀な成績を残した人たちも、結局は同じことをしています。彼らが特別なのではありません。ただ、このプロセスを高速で回せるようになっただけです。そして、その高速化は、繰り返しによってしか得られません。

自分が未熟だと不安に思いながらインターンシップを始めた私が、3年経って確信していることがあります。それは、手を動かし続けた人は、必ず前に進んでいるということです。

才能について悩む時間を、1行でも多くコードを書く時間に変える。理想の自分について考える時間を、作りたいものを作る時間に変える。その積み重ねが、気づけば「成長」と呼ばれるものになっています。

才能という言葉を使わない

ここまで読んで、一つの結論に至るかもしれません。それは、才能という言葉を使わないことの重要性です。

「才能がある」「才能がない」──この二元論は、成長の可能性を見えなくしてしまいます。代わりに、より具体的で建設的な言葉を使うべきです。

「まだ学んでいない」「まだ練習が足りない」「まだ自分に合った学び方に出会っていない」──こうした表現は、現在の状態を固定的なものではなく、変化可能なものとして捉えさせます。

インターン生に技術を教える際も、この視点の転換を意識しています。「才能がない」という言葉を聞いたら、必ず問い返します。「具体的に、何が難しいと感じている?」と。すると、「才能」という曖昧な概念ではなく、具体的な課題が見えてきます。そして具体的な課題は、具体的な対策で解決できます。

「あなたには向いていないかも」ではなく、「どういう環境や説明の仕方なら理解できるだろうか」と考えます。この視点の転換が、教育者として最も重要な態度なのかもしれません。

では、才能という言葉を使わないとしたら、何を語るべきなのでしょうか。それは、成長のメカニズムそのものです。どうすれば効果的に学べるか。どうすれば困難に直面しても諦めずに続けられるか。どうすれば自分の可能性を最大限に引き出せるか──こうした実践的な問いに答えることが、才能という幻想よりもはるかに価値があります。

これは抽象的な話ではありません。とても実践的な話です。毎朝同じ時間に起きる習慣。集中できる環境を整える工夫。失敗から学ぶための振り返りの時間。他者から助言を求める勇気──これらは全て、トレーニング可能なスキルです。そして、これらのスキルの蓄積が、才能と呼ばれるものの正体なのかもしれません。

HIDDEN POTENTIAL 可能性の科学――あなたの限界は、まだ先にある (三笠書房　電子書籍)

時間という最も公平な資源

才能という概念に対して、時間は最も公平な資源です。どんな人にも、1日は24時間しかありません。

もちろん、その24時間をどう使えるかは、環境によって大きく異なります。しかし、与えられた時間の中で、何を選択するか──その選択の積み重ねが、最終的な差を生みます。

才能がある人とない人の違いは、実は時間の使い方の違いなのかもしれません。才能があるように見える人は、学習に多くの時間を投資しています。しかしそれは、単純に勉強時間が長いという意味ではありません。むしろ、質の高い時間の使い方を知っているということです。

例えば、同じ1時間でも、受動的にチュートリアルを見るのと、能動的に問題を解こうとするのでは、学びの質が全く異なります。同じエラーに出会っても、すぐに答えを探すのと、まず自分で考えてみるのでは、理解の深さが変わります。

時間という公平な資源を、どう使うか。これは才能ではなく、戦略の問題です。そして戦略は、学ぶことができます。

あっという間に人は死ぬから　「時間を食べつくすモンスター」の正体と倒し方

停滞と努力の違い

時間の使い方について語るとき、見落とされがちな重要な区別があります。それは、停滞と努力の違いです。

Kubernetesのワークショップで、あるインターン生がServiceの概念に数日苦しんでいました。彼は毎日、同じドキュメントを読み返していました。「努力している」と本人は言いました。でも、彼は前に進んでいませんでした。

よく話を聞くと、彼はそもそもネットワークの基礎を理解していませんでした。IPアドレスとは何か、ポートとは何か、DNSがどう動くのか──こうした土台がないまま、Kubernetesの抽象的な概念を理解しようとしていたのです。

難しい問題に直面したとき、人は二つの道を選びます。一つは、理解できないまま同じ説明を何度も読み返し、同じ場所でぐるぐると回り続けること。もう一つは、「何が分からないのか」を見極めて、まずそこから順番に理解していくこと。

前者を停滞と呼び、後者を努力と呼びます。

停滞している人は、しばしば自分が努力していると思っています。長時間向き合っている。何度も試している。でも実際には、前提となる知識が欠けたまま、同じところで足踏みを繰り返しているだけなのです。

本当の意味での努力とは、今の自分が理解できるところから始めることです。Kubernetesが難しいなら、まずネットワークの基礎から。ネットワークが難しいなら、まず自分のPCで2つのプログラムを通信させることから。この段階を踏んだ学び方こそが、努力の本質です。

理解の速さには個人差があります。これは残酷な現実です。でも、人生という長い時間軸で見たとき、この速さの差は思ったほど大きくありません。むしろ、一歩ずつでも前に進み続けた人と、途中で立ち止まってしまった人の差の方が、はるかに大きいのです。

時間は誰にも平等です。でも、その時間を「理解できない問題の前での空回り」に使うか、「今理解できることから順に積み上げていく前進」に使うか──この選択が、長期的には想像もできないほどの差を生みます。

だから、ゆっくり急いでください。今日から始めて、でも焦らず、着実に。目の前の問題が難しすぎるなら、何が前提として必要かを見極めて、より基礎的なところから。その地道な積み重ねこそが、あなたを想像もしなかった場所へと連れて行ってくれます。

超一流になるのは才能か努力か？ (文春e-book)

どうしようもなく満たされない性質について

ここまで「才能という言葉を使わないこと」を言ってきましたが、最後に一つだけ、もしエンジニアに才能というものがあるとすれば何か、という問いに答えたいと思います。

それは、どうしようもなく満たされない性質です。

知りたいと思う。理解したいと思う。作りたいと思う。解決したいと思う。そして、その過程を楽しめる。それをしてないと、ちゃんと生きていけない。そういう性質。

これは祝福でもあり、同時に呪いでもあります。

なぜなら、これらの能力はコントロールできないことが多いからです。夜中の3時に突然コードのことを考え始める。休日なのに技術ドキュメントを読んでしまう。趣味と仕事の境界が曖昧になる。多くの不都合を抱えています。

だから、あまり気にしなくて良いのです。

才能と能力が一致しているのは、かなり稀です。「満たされなさ」を持っていても、それが必ずしも成果に結びつくわけではありません。逆に、その「満たされなさ」を持たずとも、優れたエンジニアになることは十分に可能です。

自分に才能があるのかないのか。何者かになれる人となれない人の違いは何なのか。

その境目はありません。

「才能がある」とか「天才だ」というのは、原因ではなく結果に対して付けられる評価です。何かを成し遂げた後で、周りが「あの人には才能があったんだ」と言うだけです。

始める前から、自分に才能があるかどうかなんて、誰にも分かりません。そして、それを気にする必要もありません。

重要なのは、今、目の前にあることに取り組むかどうか。その選択だけです。

ご冗談でしょう、ファインマンさん（上） (岩波現代文庫)

ご冗談でしょう、ファインマンさん（下） (岩波現代文庫)

おわりに

様々な場所で、様々な「才能」を目撃してきました。コンテスト会場、企業のオフィス、勉強会、ワークショップ──華々しく成功した人も、静かに立ち去った人も、黙々と歩き続けている人も。

私が伝えたかったのは「才能なんて存在しない」という単純なメッセージではありません。「才能という言葉を使うことで、私たちは何を見失っているのか」ということです。

才能という言葉は便利です。でも、その便利さと引き換えに、私たちは変化の可能性を、成長の余地を、自分と他者の可能性を信じる力を手放しています。

「才能がない」という言葉を、もし今、心の中で繰り返しているのなら──それは本当は違うかもしれません。

エラーメッセージを、ちゃんと読んでいないだけかもしれません。仮説を、一つずつ潰していないだけかもしれません。インスタントな答えを求めて、モヤモヤと向き合っていないだけかもしれません。まだ、自分に合った学び方に出会っていないだけかもしれません。

小さなことです。でも、その小さなことを飛ばしているから、「才能がない」と思い込んでしまう。

コンテストで輝いていた同期が、燃え尽きていることがあります。勉強会で熱心だった後輩が、姿を見せなくなることがあります。一方で、当時は目立たなかった誰かが、誰も予想しなかった場所で花を咲かせていることもあります。

スタート地点の優劣など、長い人生においてはほとんど意味をなさない──20代を通じて、私はそう学びました。あなたの可能性は、スタート地点では測れません。どれだけ伸びたか、どれだけ学んだか、どれだけ変化したか──それこそが、本当の意味での能力です。

才能という幻想を手放したとき、初めて見えてくる景色があります。それは、不完全な今の自分を受け入れ、それでも前に進み続けることの静かな勇気です。

未熟な自分がインターンシップを始めて3年。今でも不安はあります。でも、若手と一緒に作業する中で気づきました。彼らが必要としているのは、全てを知り尽くした指導者ではありません。共に悩み、共に考え、そして「才能」という言葉で可能性を閉ざさない、そんな誰かです。

この記事を通じて、私自身もまた、自分に言い聞かせています。

才能があるかどうかなんて、後になってから誰かが決めることです。大切なのは、今、目の前にあることに手を動かし続けること。その積み重ねだけです。

---

最後に、私自身のことを少しだけ。

私にはいくつかの目標があります。

世界的に有名なOSSを作って、海外で見知らぬ人にコーヒーを奢ってもらいたいです。書籍をコンスタントに出して、いつか道端でサインを求められたいです。週刊プレイボーイに連載を載せて、毎週誰から指摘されても反論ができるようにグラビア雑誌を買うことです。

できるかどうかは分かりません。才能があるかどうかも分かりません。でも、文章を書き続けています。コードを書き続けています。

なぜなら、それが私にとって「満たされなさ」を満たす行為だからです。そして、その過程を楽しんでいるからです。

あなたにも、そんな「満たされなさ」があるなら。それに向かって、ただ手を動かし続けてください。

それが才能かどうかなんて、後になってから誰かが決めることです。

---