はじめに
ワークショップが始まる三十分前、会場の隅で、一人の若者がノートPCの画面を凝視していた。
ブラウザには二十を超えるタブが開かれている。Dockerの公式ドキュメント、Kubernetesの公式リファレンス、Qiita、Zenn、個人ブログ。静かな会場に響くのは、マウスホイールを回す音だけで、彼は次から次へとタブを切り替えながら、何かを探すように、あるいは何かから逃げるように、ドキュメントを読み続けていた。読んでいた、という言葉はきっと正確ではなくて、目で文字を追っているだけで、その言葉が本当に頭の中に入っているかどうかは、おそらく彼自身にも分からなかったのだろうし、分からないことに気づかないふりをしていたのかもしれないし、あるいは気づいていたけれど認めたくなかったのかもしれない。
「準備しておかないと」
ぽつりと呟いた声は、誰に向けられたものでもなかった。会場には他にも何人か早めに来ている参加者がいたけれど、彼らに向けた言葉でもなく、講師である僕に向けた言葉でもなく、けれど僕には分かった、あの言葉は自分自身への言い訳で、読み続けている限り「まだ始めていない」という事実から目を逸らせて、手元にあるyamlファイルを開くことも、Dockerfileを書き始めることもなく、ただスクロールを繰り返していれば、準備という名の猶予期間はどこまでも続いていくような気がして、その錯覚こそが彼を動けなくしているのだと、その姿を見ながら僕は思った。
彼は、昔の僕だ。
気づけば開始時刻になっていた。けれど彼の画面に立ち上がったコンテナは一つもなくて、代わりにあったのは無数に開かれたタブと、そして不思議なことに「今日は勉強した」という、根拠はどこにもないのにどこか心地よい、温かくて柔らかい達成感だけだった。手は動かしていないのに、頭は働かせた気がして、何も作っていないのに、何かを学んだ気がして、この感覚はとても甘くて危険で、僕も何度もこの甘い罠に捕まってきたから分かる。
僕も石橋を叩いて渡るタイプで、新しい技術を学ぶときはまず本を買って安心する。「準備してから」「もう少し理解してから」「完璧になってから」、その言葉は、とても合理的に聞こえる、誰も反論できない、自分自身も反論できない、だから安心してその言葉に逃げ込むことができる。でも、ある時気づいてしまった。「まだ準備が足りない」と思って読み続けるうちに、何時間も、何日も経っていて、僕は実際には何一つ手を動かしていなかったことに。本当は、もっと早く気づいていたのかもしれない。けれど気づかないふりをして、気づきたくなくて、「準備」という名の停滞を「努力」だと自分に言い聞かせていた。
「明日からやろう」という言葉の背後で何が起きているのか、本人は意外と気づいていない。いや、もしかしたら気づいているのかもしれないけれど、気づかないふりをしているのかもしれないし、気づいていることに気づかないふりをしているのかもしれない。
このポストは動けない人の構造を解剖し、そこから抜け出すための実践について書いたもので、三年間ワークショップで自分や多くの若手エンジニアと向き合う中で見えてきたことがある。動けない理由は一見バラバラに見える、けれどこれらの言葉を一つ一つ丁寧に剥いでいくと、驚くほど似た構造が現れる。恥への恐怖、完璧主義、そして「才能がない」という誰も反論できない便利な逃げ道。面白いことに、これらの根底には共通するものがあって、それは「なんとなく不安」「どうも気が進まない」「なんか怖い」という、この「なんか」という輪郭を持たない曖昧な言葉で、僕らはこの「なんか」という便利な言葉の中に、言葉にしたくない、言葉にするのが怖い、言葉にしてしまったら向き合わなければならなくなる、そういう感情を全部押し込めて蓋をしている。
この「なんか」を言葉にしない限り、恐怖は形を持たない。形を持たない恐怖は霧のように僕らの思考を覆って、じわじわと、気づかないうちに、判断力を奪い続ける。ここで一つ断っておきたいのは、僕の「なんか」とあなたの「なんか」は、きっと少し違うということで、僕が恐れているものとあなたが恐れているものは同じではないかもしれないし、僕が「恥」だと感じるものとあなたが「恥」だと感じるものは、同じ言葉を使っていても中身は違うのかもしれない。けれど、それでも共通しているのは、その「なんか」を言葉にしないまま放置していることで、言葉にしない限り、それが何であれ、形を持たないまま僕らの中で勝手に膨らんでいくということだ。
だから本人も周りもなかなか気づかないまま、「準備している」「慎重なだけ」「向いていないのかも」という、どこか優しげに聞こえて、誰も否定できない言葉の裏側で、実は何ヶ月も何年も同じ場所に立ち止まっていて、立ち止まっていることにすら気づかないまま時間だけが過ぎていく。
さらに現代という時代が、この自己欺瞞を加速させている。生成AIに聞けばそれっぽい答えがすぐ返ってきて「理解した気」になれるし、スマホを開けば無限に刺激があって「ちょっと休憩」が気づけば一時間になる。立ち止まっている自分を見て見ぬふりをするための道具が、これほど揃っている時代はない。けれど同時に、この構造を理解すれば抜け出す方法も見えてくる。言語化すること、小さく始めること、遊ぶこと、不完全でも動くこと。これらは全て才能ではなく訓練可能な技術で、動けない理由を言語化できれば、動くための方法も見えてくる。
「なんか不安」と思ったとき、立ち止まって「何が不安なのか」と問いかけるようになった。その答えを、怖くても、恥ずかしくても、認めたくなくても、言葉にするようになった。そうすると不思議なことに動けるようになって、言葉にしてしまえば思ったより大したことなかったりして、「こんなことで止まっていたのか」と拍子抜けするほどで、でも、言葉にしない限り、その「こんなこと」は永遠に巨大な壁であり続ける。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。では、早速はじめていきます。
三つの声
いろんな彼というか昔の僕から動けない理由を聞くと、大きく三つのパターンに分かれる。正確には、休憩時間や終了後に雑談をしていて「今日はどうだった？」と聞くと、こんな答えが返ってくる。
「失敗したくない」という声がある。ワークショップである学生が「エラーが出たら、どうしていいか分からなくなるんです」と言った。その時は「エラーメッセージを読むといいよ」とアドバイスして終わったのだが、後になって考えた。彼が本当に恐れていたのはエラーそのものだったのだろうか。よく思い返してみると、彼は他の参加者を横目で見ていて「みんな進んでる」とも言っていた。つまり、エラーが出たときにそれを解決できない自分が露呈するのが怖かったのではないか。「このエラーの意味が分からない」「基礎的な知識が足りない」と認めることは、自分の無知を他者に見せることになる。他の参加者は解決できているかもしれないし、講師は当然知っている。その中で自分だけが分からない。失敗への恐怖は、実は無知の露呈への恐怖なのかもしれない。エラーそのものは怖くないが、エラーを通じて自分の能力の限界が可視化されることが怖い。だからエラーが出る前に完璧に準備しようとしてドキュメントを読み漁るが、どれだけ読んでも「完璧」には到達しない。そして永遠に始められない。
「もっと良い方法があるはず」という声もある。別の学生は「このやり方で合っているのか分からなくて」と言った。その時の彼の画面を覗き込むと、Dockerfileが半分書きかけのまま止まっていた。「どうしたの？」と聞くと「ベストプラクティスを調べてて」と言い、ブラウザには10個以上のタブが開いていた。終わった後、もう少し話を聞いてみた。「何が一番困った？」「うーん、正解が分からなくて」。その「正解」という言葉が引っかかった。プログラミングに唯一の正解なんてあるだろうか。
後で考えてみると、彼が求めていたのは「正解」ではなく「間違っていないという保証」だったのかもしれない。Dockerfileを書き始めて一行書いては止まり、「これは本当にベストプラクティスなのか」とブラウザに戻って「Docker ベストプラクティス」で検索する。いくつかの記事を読むと別のやり方が紹介されていて「どっちが正しいんだろう」とまた別の記事を読み、さらに別のやり方を見つける。最適解を求めるほど選択肢は増え、決断は遠のく。でもよく考えてみると、おかしなことを言っている。「最適解」は実際にやってみないと分からず、プロジェクトの要件やチームの習熟度、運用の制約といった文脈によって「最適」は変わる。にもかかわらず文脈なしで「最適解」を求めている。これは実は決断を先延ばしにするための言い訳なのかもしれない。なぜ決断を先延ばしにするのか。おそらく決断には責任が伴うからだ。「これで行く」と決めた瞬間、それが間違っていたときの責任を負うことになる。でも「まだ調べている」段階なら責任は発生せず、間違える可能性もなく、評価されることもない。完璧主義は行動の質の問題ではなく、存在の先延ばしの問題なのかもしれない。
「周りの目が気になって」という声は、終わった後の雑談で最も正直に語られた。「質問すると『こんなことも知らないのか』と思われそうで」という学生は、ワークショップ中に何度もつまずいていて画面を見れば分かるのだが、質問もせず隣の人に聞くこともせずに、ただ黙って画面を見つめていた。「どうして質問しなかったの？」と聞くと、「みんな分かってそうな雰囲気で、自分だけ分かってないって思われたくなくて」と言った。でも実際には、後で他の参加者に聞いてみると同じところでつまずいていた人が何人もいたのだが、誰も質問しなかった。みんな同じことを思っていた。恥という感情の不思議なところは、実際の他者の反応ではなく想像上の他者の視線に縛られることだ。「こう思われるかもしれない」という想像がその行動を止めるが、その想像が現実と一致しているかは確かめられない。なぜなら行動していないから。
三つの声の正体
失敗したくない、もっと良い方法があるはず、周りの目が気になる。学生たちから聞いたこれらの言葉を一人になってから反芻していた。一見バラバラに見えるこれらの理由だが、丁寧に分解していくと共通した構造が見えてくる気がした。
すべて恥への恐怖に行き着くのではないか。「失敗したくない」は無知を露呈したくない、つまり恥をかきたくないということであり、「もっと良い方法があるはず」は間違った選択の責任を負いたくない、つまりこれも恥の回避だ。「周りの目が気になる」はそのものズバリ、他者の視線という恥の源泉である。そしてさらに抽象化すると、三つの根源的な恐怖に還元される気がした。恥をかきたくない、損をしたくない、嫌われたくない。
でも面白いことに、これらを具体的に言葉にした瞬間、その恐怖は不思議なほど小さく見える。「エラーメッセージの意味が分からないのが怖い」と言葉にすればそれは解決可能な課題になるし、「ベストプラクティスを知らないのが不安」と認めれば「じゃあまず動くものを作って後で改善しよう」という選択肢が見える。「質問して笑われるのが怖い」と明確にすれば、「実際に笑う人がいるのか？ いたとしてその人の評価を気にする必要があるのか？」と問い直せる。具体的に言葉にした瞬間、恐怖は相対化される。でも多くの人はこの言語化の一歩手前で止まっている。
「なんか」の正体
「なんとなく不安で」「どうも気が進まなくて」「なんか怖くて」。この「なんか」という言葉が問題だ。「なんか」で済ませている限り恐怖は輪郭を持たない。輪郭を持たない恐怖は無限の可能性として脅威を放ち続け、それは霧のように思考空間を覆って判断力を奪う。逆に言えば、恐怖を明瞭に言語化すればそれは相対化可能な「ひとつの感情」へと縮小する。言葉は混沌に秩序を与える。
でも、なぜ人は言語化を避けるのか。試しに自分が動けない理由を紙に書き出してみるといい。「なぜこのタスクに取り掛かれないのか」を具体的に書き始めると手が止まる。なぜか。言語化とは「嫌な自分」と正面から向き合う行為だから。曖昧なままなら自己欺瞞の余地が残り、「本気出せばできる」「時間がないだけ」「環境が悪いだけ」とそう思い込んでいられる。でも一度言葉にしてしまえばもはや逃げ場はない。
「基礎的なことを理解していない」と書けばそれは事実として目の前に現れ、「エラーメッセージを読み飛ばしている」と認めればその怠慢は言い逃れできなくなり、「質問する勇気がない」と言葉にすれば自分の臆病さと向き合わざるを得ない。だから人は言語化を避ける。でもこの回避こそが停滞を生み出す。言葉にできない感情は実体以上に巨大化し、漠然とした不安のまま放置すればそれはどんどん大きくなっていく。「なんとなく怖い」が「とても怖い」になり「絶対に無理」になる。未言語化の不安は輪郭を持たないがゆえに肥大化し、行動を麻痺させる。
このポストは動けない人の構造を解剖しそこから抜け出すための実践について書いたものだ。抽象的な話に聞こえるかもしれないが、これは極めて実践的な話だ。なぜなら動けない理由を言語化できれば動くための方法も見えてくるからだ。ワークショップでドキュメントを読み漁る若者を見ながら、自分もかつてそうだったことを思い出す。そして今も新しい技術に触れるとき同じパターンに陥りそうになる。でも一つだけ変わったことがある。「なんか不安」と思ったとき立ち止まって「何が不安なのか」と問いかけるようになった。その答えを言葉にするようになった。そうすると不思議なことに動けるようになる。「なんか」の正体を一緒に言葉にしてみよう。
なぜこんなに変わりたいのに行動ができないのか
動けない理由を剥いていくと
ワークショップの後、参加者たちと話していて気づいたことがある。動けない理由は人それぞれ違う言葉で語られるが、その言葉を一つ一つ剥いでいくと意外なほど似た構造が現れる。
「失敗したくない」と言った学生に「何が失敗なの？」と聞いてみた。「エラーが出ることです」。「エラーが出ると何が困るの？」「解決できないからです」。「解決できないと何が困るの？」と重ねて聞くと、彼は少し黙って小さな声で言った。「他の人にできないやつだと思われるのが嫌なんです」。ああそうか。エラーが怖いのではなかった。自分で認めるのも嫌だけど、エラーを解決できない自分が他者に見られることが怖かったのだ。
「もっと良い方法があるはず」と言った学生には「今のやり方の何が問題なの？」と聞いた。「うーん、間違ってるかもしれないから」。「間違ってると何が困るの？」「後で直すのが大変だから」。「本当にそれだけ？」と聞くと、彼も少し考えてこう言った。「間違ったやり方を選んだって知られたくないです」。ここでも他者の視線が出てきた。
試しに動けない理由を「○○が怖い」という形に言い換えてみると、面白いことにだいたい三つに集約される。恥をかくのが怖い、損をするのが怖い、嫌われるのが怖い。これらを観察しているとある構造に気づく。すべての中心に「他者の視線」がある。恥は他者がいて初めて成立し、損も他者との比較で生まれ、嫌われるもそのものズバリ他者との関係だ。動けない理由を突き詰めていくと、思考の主語が「自分」ではなく「他人」になっている。
恥という不思議な感情
恥を恐れて動けないとき自分の思考を観察してみるといい。面白いことに気づく。思考の主語が「他人」になっている。「自分がどうしたいか」ではなく「他人にどう見られるか」、「これは面白いか」ではなく「これは評価されるか」と、判断基準の中心にいつの間にか他者の視線が居座っている。
ワークショップでこんなことがあった。ある学生が自分で考えた実装方法を試そうとしていたが、途中で手を止めて「これ間違ってるかもしれない」と言ってブラウザでベストプラクティスを検索し始めた。「さっきの方法試してみたら？」と声をかけると、「でももし間違ってたら恥ずかしいです」と言った。誰に対して？よく考えてみるとおかしな話だ。ワークショップは学ぶ場所で間違えるために来ているのに、彼は間違えることを恥だと感じていた。
恥という感情は本質的に社会的なものだ。一人で山に籠もって生きているなら恥という感情は存在せず、恥は他者の視線があって初めて成立する。だから恥を避けようとすればするほど自分の判断基準は外部に移っていく。「自分はこれを試してみたい」ではなく「これは他者に評価されるか」、「自分はこれが面白い」ではなく「これは正しいと思われるか」となる。これは「外部評価への依存」というきわめて脆弱な存在様式だ。
なぜ脆弱なのか。他者の評価はコントロールできないからだ。どれだけ頑張っても他者がどう評価するかは分からず、評価を気にすればするほどその不確実性に振り回される。さらに皮肉なことに恥を避けようとしてもっと深刻な状態に陥る。「失敗」という一時的な出来事を避けようとして「停滞」という持続的な状態に陥る。一瞬の恥を避けるために何ヶ月も何年も同じ場所に立ち止まる。
でもこの事実に気づくのはいつも後になってからだ。停滞している最中は自分が停滞していることにすら気づかず、「準備している」「勉強している」「タイミングを見計らっている」とそう言い聞かせながら過ごす。恥を避けることに内的エネルギーを費やすほど自己の内側は空洞化していく。他者の評価を内面化し自分で自分を監視する。自己評価の基準が外部にあるときそこにはもう自己は存在しない。
「完璧」という呪い
「完璧に準備してから始める」という言葉は合理的に聞こえるが、ワークショップでこの言葉を聞くたびある疑問が浮かぶ。「完璧」って何だろう。
ある学生はワークショップ開始前に2時間ドキュメントを読んでいて「準備したい」と言っていたが、実際にコンテナを立ち上げることはなかった。「どこまで準備したら始められそう？」と聞くと「全部理解してから」と言った。全部。でも「全部」って何だろう。Dockerの全ての機能を理解する？ Kubernetesの全てのコンポーネントを理解する？ そんなことは実務で何年も使っているエンジニアでも無理だ。つまり「完璧に準備してから始める」は実質的に「決して始めない」と同義だ。
よく考えてみるとおかしなことを言っている。完璧に準備するとは何か。すべてを理解してから始めるということだが、すべてを理解するには実際にやってみるしかなく、やってみないと分からないことは必ずある。ドキュメントに「Podは一つ以上のコンテナを含む」と書いてあれば読めば理解できるが、実際にyamlを書いてkubectl applyしてエラーが出てそのエラーメッセージと格闘して、初めて本当に理解できる。理論的な理解と体験的な理解は違う。「完璧に準備してから」と言う人は実は理論的な理解だけで完璧になれると思っているが、それは不可能だ。体験なしに理解は完成しない。
では、なぜ人は「完璧に準備してから」と言うのか。これは行動の質の問題ではなく存在の先延ばしの問題だ。不完全な自分を世界に晒すことへの恐怖、評価されることへの恐怖、そしてその根底にはやはり恥がある。完璧主義は恥への防衛機制として機能し、「準備不足だから失敗した」という言い訳をあらかじめ用意しておく。決して完成しないものは決して評価されず、評価されなければ恥もかかない。求めるほど遠のくという逆説がここにある。
完璧を求めるから行動できず、行動しないから経験が積めず、経験がないから完璧からは遠のき、そしてさらに完璧を求める。この悪循環。ワークショップである学生が最後に「結局何も完成しませんでした」と言った。でも彼は多くのことを学んだはずだ。エラーメッセージの読み方、yamlの書き方、kubectlのコマンド。不完全でも多くのことを試した。「完成しなかったけど学んだことはたくさんあったんじゃない？」と言うと少し考えて「そうですね。でも完成させたかったです」と言った。
完璧主義者が見落としているのは小さな一歩の価値だ。不完全でも動いた一歩と完璧を求めて動かなかったゼロ。どちらが自分を前に進めるか。答えは明白なのになぜか後者を選んでしまう。
言葉にできない不安の正体
「なんとなく不安で」「どうも気が進まなくて」「なんか怖くて」という言葉を休憩時間によく聞く。「どうして手を動かさないの？」と聞くと「なんとなく」と返ってくる。この「なんか」「なんとなく」という言葉が実は重要な意味を持っている。
試しに「なんとなく不安」と言った学生に「何が不安なの？」と聞いてみた。「うーん、なんか」。「例えば？」「分からないです」。言葉にできない。でもこれは語彙力の問題ではなく言語化を避けているという選択の問題だ。なぜそう思うか。別の機会に同じ学生にもう一度少し角度を変えて聞いてみた。「もし今コンテナを立ち上げようとしたら何が起きると思う？」
すると意外なほど具体的な答えが返ってきた。「エラーが出ると思います。そのエラーの意味が分からなくてどうしていいか分からなくなって時間ばかりかかって結局できなくて周りの人に遅れて」。ああ言葉にできるじゃないか。彼は自分の不安を言語化できないのではなく、言語化したくなかっただけだ。
なぜか。言葉にできない感情は実体以上に巨大化する。「なんとなく不安」のままならその不安の正体は確定しないが、「エラーの意味が分からないのが怖い」と言葉にした瞬間それは具体的な課題になってしまい、具体的な課題になればそれに対処しなければならなくなる。言語化とは「嫌な自分」と正面から向き合う行為だから。
「エラーメッセージの意味が分からない」と認めることは自分の知識不足を認めることであり、「基礎が理解できていない」と言葉にすることは自分の勉強不足を認めることであり、「質問する勇気がない」と明確にすることは自分の臆病さを認めることだ。曖昧なままなら自己欺瞞の余地が残り、「本気出せばできる」「時間がないだけ」「環境が悪いだけ」とそう思い込んでいられるが、一度言葉にしてしまえばもはや逃げ場はない。だから人は言語化を避ける。
でもこの回避こそが停滞を生み出す。輪郭を持たない恐怖は無限の可能性として脅威を放ち続ける。それは霧のように思考空間を覆って判断力を奪い、「なんとなく怖い」が「とても怖い」になり「絶対に無理」になる。未言語化の不安は輪郭を持たないがゆえに肥大化し行動を麻痺させる。
逆に言えば恐怖を明瞭に言語化すればそれは相対化可能な「ひとつの感情」へと縮小する。「エラーメッセージの意味が分からないのが怖い」と言葉にした瞬間それは解決可能な具体的課題になる。言葉は混沌に秩序を与える。言葉を持つことは自由を獲得することに等しい。言語化は自己認識の解像度を上げる行為であり、内面の混沌を構造化し恐怖を名指すことで相対化する力。それが言語化の力だ。
「才能」という最も便利な逃げ道
そして最後にすべてを覆い隠す魔法の言葉がある。「才能がない」。
ワークショップの最後ある学生が「自分には向いていないかもしれません」と言った。「どうしてそう思うの？」と聞くと「他の人より理解が遅いから」と言った。でも観察していて気づいたことがある。彼は理解が遅いのではなく理解しようとしていなかったのだ。
エラーメッセージが出てもちゃんと読んでいなかった。「Expected type X, but got type Y」と明確に書いてあるのに「type X」という文字列だけを拾って、期待される型と実際の型が違うという関係性を読み取っていなかった。ドキュメントを「読んでいる」と言いながら実際には流し読みしていて、主語と述語を把握せず「誰が」「誰に」「何を」しているのかという基本的な構造を理解しないまま「なんとなく」で進めようとしていた。仮説を一つずつ潰すのではなく「ネットワークの問題かもしれない」「データベースの問題かもしれない」と複数の仮説を同時に追いかけてどれも中途半端に確認していた。
これは才能の問題ではなくプロセスの問題だ。エラーメッセージをちゃんと読む、仮説を一つずつ潰す、主語と述語を把握する。誰でもできることだ。でもこの「小さなこと」を飛ばしているから「理解が遅い」ように見える。そしてこの事実から目を逸らすために「才能」という言葉を使う。
「才能がない」という言葉は根深い自己欺瞞であり最も便利な逃避だ。なぜなら才能という言葉を使った瞬間、人は変化の可能性を放棄できるからだ。「才能がないからできない」は「努力してもどうせ無理」と同義で、成長のための努力そのものが無意味に思える。そして才能という言葉はすべてを覆い隠す。恥への恐怖を覆い隠し完璧主義を正当化し言語化を避ける。基礎プロセスを飛ばしていることも努力を怠っていることもすべて「才能」という一言で片付けられる。才能という言葉を使った瞬間思考は停止する。
でも観察していると分かる。「才能がある」ように見える人も実は同じプロセスを踏んでいる。エラーメッセージをちゃんと読み仮説を一つずつ潰し主語と述語を把握している。ただそれだけだ。違いはそのプロセスを意識的に実践しているかどうかであり、それは訓練可能だ。
前のポストで書いたように技術力は経験の蓄積とセンスから成り立ち、そしてどちらも訓練可能だ。センスとは突き詰めれば「何に注目するか」という習慣と「それを面白がれるか」という姿勢だ。でも「才能」という言葉を使えばこうした具体的な分析も具体的な対策もすべて放棄できる。恥への恐怖、完璧主義、言語化の欠如。そのすべてを「才能」という一言で説明する。これが動けない人が抱える最後の砦だ。
動くための小さな一歩
言葉にしてみるという勇気
まず自分の恐怖を具体的に正直に言語化してみる。ワークショップの終わりにこんな提案をしてみた。「今日動けなかった理由を紙に書いてみて」。最初は戸惑った顔をしていた参加者たちだが何人かが書き始めた。
ある学生が書いたのは「エラーが出たときに解決方法が分からなくて周りに遅れるのが嫌だった」という文章だった。書き終わって彼はその紙をじっと見ていて「あれこんなことだったのか」と言った。言葉にした瞬間不思議なことが起きる。恐怖が相対化され「ああこんなことで止まっていたのか」という気づきから「じゃあどうすればいいか」という具体的な対策が見えてくる。
「エラーが出たときに解決方法が分からない」なら「じゃあエラーメッセージの読み方を学ぼう」となり、「周りに遅れるのが嫌」なら「でもこれは学ぶ場所だ。遅れても構わない」となる。抽象的な不安は具体的な課題へと変換され、具体的な課題は具体的な対策で解決できる。
「恥をかきたくない」だけではまだ抽象的だ。もう一歩踏み込んで「このコードをレビューに出したら基礎的な部分の知識不足を指摘されるのが怖い」とここまで具体的にする。すると「じゃあ基礎的な部分を先に学べばいい」という対策が見え、「レビュー前に自分でチェックリストを作ればいい」という方法が浮かび、「そもそも指摘されることは学びのチャンスだ」という視点が得られる。言語化は勇気の技術であり嫌な自分と向き合う技術だが、その一歩がすべてを変える。
現代人が失ったもの
ただ言語化を阻むものは個人の内側だけにあるわけではなく、現代という時代そのものが言語化を難しくしている。ワークショップの休憩時間、参加者たちの多くがスマホを見てTwitterやInstagramをスクロールしLINEに返信しYouTubeのショート動画を見る。私たちは今インスタントで断片的な刺激に取り巻かれている。即座の返信、短い動画、分かりやすい解説とスマホを持つことで即時的な満足にいつでもアクセスでき、「消化しきれなさ」「難しさ」「モヤモヤ」といった時間もコストもかかるものは避けられるようになった。
技術ドキュメントを読むことはまさにこの「モヤモヤ」との戦いだ。Kubernetesの公式ドキュメントを開いても一読してすぐに理解できるものではなく、分からない用語が出てきてそれを調べるとさらに分からない概念が出てくる。読み返し実際に試しエラーが出てまた読み返す。この時間のかかるプロセスがインスタント化した感覚に慣れた私たちには耐えがたい。だからすぐに生成AIに「KubernetesのServiceとは何ですか？要約して」と聞く。確かに分かりやすい説明が返ってきてスッキリする。でもその過程で失われるものがある。
モヤモヤした状態を抱えたまま読み続け試し続けることでしか到達できない深い理解。断片的な知識ではなく体系的な理解。これは要約では得られない。ある学生がワークショップで「生成AIで調べたんですけど実際にやってみるとうまくいかなくて」と言った。よく見ると生成AIの説明を鵜呑みにしてその背後にある前提条件を理解していなかった。「この設定はこういう環境を前提としています」という部分を読み飛ばしていた。生成AIは便利なツールだが使い方を間違えると理解の機会を奪う。
同時にスマホによる常時接続は孤独を奪った。ワークショップ中少し難しい課題に取り組んでいるときすぐにスマホに手が伸びて「ちょっと休憩」と言ってTwitterを開く。退屈に耐えきれず何か刺激を求めてスマホをいじる。一人でドキュメントと向き合う時間一つのことに没頭する孤立。このシンプルな行為が驚くほど難しくなっている。でも言語化には孤独が必要で、自分の内側と向き合うには外部の刺激から離れる必要がある。
そしてもう一つ、ネガティブ・ケイパビリティの欠如だ。これは「結論づけずモヤモヤした状態で留めておく能力」のことで、把握しきれない謎をそのまま抱えておく力だ。新しい技術を学ぶときすぐに「わかった」と思いたくなるが実際にはわかっていないことだらけで、この不確実性に耐える力が現代人には欠けている。
ワークショップでこんなことを言う学生がいた。「全部理解してから次に進みたいんです」。でも「全部理解する」なんて不可能だ。理解は何度も行ったり来たりしながら螺旋を描くように深まっていく。最初は30%の理解、実際に使ってみて50%、エラーと格闘して70%、また別の文脈で使って80%。理解は一度で完成しない。でもこのモヤモヤした状態に耐えられずすぐに「分かった」と結論づけたいために生成AIに「簡潔に説明して」と頼む。簡潔な説明は確かに分かりやすいが、その分かりやすさは複雑さを削ぎ落とした結果で、削ぎ落とされた部分にこそ本質が隠れていることもある。
生成AIという新たな逃避
ChatGPTやClaudeの登場は学習の風景を変えそして新しい逃避の道を開いた。停滞のパターンはこうだ。エラーが出て生成AIに「このエラーどう直す？」と聞き答えが返ってコピペして動いて「解決！」となる。これは答えは得られるが理解は得られず、次に同じエラーに遭遇したときまた同じことを繰り返す。
ワークショップで何度も同じパターンを見た。学生がエラーに遭遇してすぐに生成AIに聞き答えをコピペし次のエラーでまた聞きまたコピペする。三回目に同じようなエラーが出たとき彼は気づいていなくて「あれさっきも似たようなエラーが出たな」という記憶がない。なぜか。自分で考えていないからだ。エラーメッセージを読んでいない。なぜそのエラーが出たのか理解しようとしていない。答えは得られるが学びは得られない。混乱したときすぐに生成AIに頼ると不快感と向き合う機会が失われる。でもこの不快感こそが深い理解への道なのに。
成長のパターンはこうだ。まず自分で理解しようとしてエラーメッセージを読みドキュメントを読み仮説を立てて試す。それでも分からなかったら自分なりの理解をまとめる。その上で生成AIに「私はこう理解したが合ってる？」と質問する。先に自分で考えて生成AIは「答えを教える」のではなく「理解を確認する」役割にする。あるいは「このエラーが出た。なぜこのエラーが出るのか仕組みから説明して。直し方は教えなくていい」と聞いて表面的な解決策ではなく根本的な理解を得る。
ワークショップでこの方法を試した学生がいた。最初は時間がかかったが、三回目に似たようなエラーが出たとき彼は自分で解決できて「ああこれはあの時と同じパターンだ」と言った。理解があれば応用が効く。
生成AIとの付き合い方には四つの落とし穴がある。一つ目は思考の外部化で考えるべきことを全て生成AIに任せてしまうこと。二つ目は流暢性の錯覚で、生成AIの説明は分かりやすいが自分でコードを書こうとすると書けず「分かった気」になっているだけ。三つ目は最適な難易度を見失い自分の理解レベルに合わない質問をしてしまい、基礎を理解していないのに応用的な質問をする。四つ目は不快感から逃げることで、混乱したときモヤモヤしたときすぐに頼ってしまうがその不快感こそが成長の証なのに。
重要なのは自分の頭で考え手を動かし不快感と向き合うことで、これは生成AIがなかった時代もある時代も変わらない真実だ。そしてこれも才能の問題ではなく習慣の問題だ。
遊ぶことから始まる
恥を恐れ完璧を求め言語化から逃げる。この三つが絡み合って人を動けなくする。一つの答えは遊ぶことだ。
ワークショップでこんな提案をしてみた。「次の30分何も見ずにとりあえず動かしてみて」。「えっドキュメント見なくていいんですか？」と驚く学生たちに「いいよ。適当にやってみて。エラーが出ても気にしない。とにかく何か動かしてみる」と答えた。最初は戸惑っていたが徐々に表情が変わってきて「あこれ動いた」「このオプション何だろう」「試してみよう」となった。遊びには「正解」がないから失敗を恐れる必要がない。評価されることもなくただ面白いからやり好奇心のままに試す。この心理的な自由が試行錯誤を促進する。
30分後何人かの学生が予想外のものを作っていた。「Nginxのコンテナを3つ立ち上げてそれぞれ違うページを表示させてみました」。ドキュメント通りではないが動いていて彼は楽しそうだった。「どうやって作ったの？」と聞くと「分からないままとりあえず書いてみたら動いたんです」と言った。この「なんとなく」が実は重要なのだ。
理論を学ぶ前に体験を通じた直感的理解が生まれる。後に理論を学ぶとき「あああの時の『なんとなく』はこういうことだったのか」と腑に落ちる。プログラミングを学び始めた頃を思い出してほしい。「とりあえず動かしてみよう」と思ってよくわからないままコードを書いた経験はないだろうか。エラーが出て何が悪いのかわからないが、いろいろいじっているうちになんとなく動いた。
遊びは内発的動機を育てる。「やらなければならない」ではなく「やりたい」という動機で、これは強制では生まれない。自分で選んで自分のペースで面白いと思うことをやる過程で内発的動機が育つ。失敗への耐性も生まれる。遊んでいるとき失敗は「失敗」ではなくただの「結果」だ。「あこうするとこうなるんだ」という発見と次は別の方法を試してみようという好奇心。
多くの人は学びを始めるときいきなり「正しいやり方」を覚えようとして教科書を読みチュートリアルを見る。でもこれは実は難しい。なぜなら「なぜその型が重要なのか」がわからないまま形だけを真似ようとするから。型の意味を理解するにはその型がない状態を経験する必要がある。だからまず遊ぶ。制約なく好奇心のままに試して失敗を恐れず楽しむ。
ここで少し逆説的なことを言いたい。特に若い時期には根拠がなくても自分を信じることが重要だ。「これが本当に正しい道なのか」「自分に向いているのか」。そんな冷静な自己分析ばかりしていると一歩も踏み出せなくなる。時には根拠のない自信を持って盲信的に突き進むことも必要だ。
「Kubernetesなんて簡単だろう」というある意味で無知ゆえの大胆さ。この「若気の至り」とも言える姿勢が最初の一歩を踏み出させてくれる。
ワークショップで最も早く理解した学生に「なんでそんなに迷わず進めるの？」と聞いてみた。彼は少し考えて「分からないけどとりあえずやってみたら分かるかなって」と言った。根拠のない自信だがその自信が彼を動かした。実際に動いた結果本当に理解した。その盲信的な姿勢がいつか本当の自信に変わり、根拠のない自信が実績という根拠を伴った自信になる。気づけば最初は「嘘」だった「自分はできる」という言葉が本当になっている。完璧主義を捨ててまず遊ぶ。型を学ぶのはその後でいい。
小さく、完璧でなくても、動く
停滞と努力の違いを理解することも重要だ。ワークショップである学生がKubernetesのServiceの概念に数日苦しんでいて、彼は毎日同じドキュメントを読み返していた。「努力している」と本人は言ったが彼は前に進んでいなかった。
よく話を聞くと彼はそもそもネットワークの基礎を理解していなかった。IPアドレスとは何かポートとは何かDNSがどう動くのか。こうした土台がないままKubernetesの抽象的な概念を理解しようとしていた。難しい問題に直面したとき人は二つの道を選ぶ。一つは理解できないまま同じ説明を何度も読み返し同じ場所でぐるぐると回り続けること。もう一つは「何が分からないのか」を見極めてまずそこから順番に理解していくこと。前者を停滞と呼び後者を努力と呼ぶ。
停滞している人はしばしば自分が努力していると思っている。長時間向き合い何度も試している。でも実際には前提となる知識が欠けたまま同じところで足踏みを繰り返しているだけ。「Serviceが分からない」と言っていた学生に「じゃあまずネットワークの基礎から学ぼう」と提案すると最初は不満そうで「それは遠回りじゃないですか」と言った。でも基礎から学び始めて3日後彼は突然Serviceを理解して「ああそういうことか！」と言った。
本当の意味での努力とは今の自分が理解できるところから始めること。Kubernetesが難しいならまずネットワークの基礎から。ネットワークが難しいならまず自分のPCで2つのプログラムを通信させることから。この段階を踏んだ学び方こそが努力の本質だ。
学習には三つのゾーンがある。コンフォートゾーンはすでに理解していることを繰り返す状態で簡単すぎて新しい学びがない。パニックゾーンは現在の理解からかけ離れていて難しすぎて何から手をつければいいかわからない。学習ゾーンは少し難しいが頑張れば手が届き既存の知識を応用すればなんとか理解できる。
「才能がない」と感じているとき実はパニックゾーンに突っ込んでいるだけかもしれない。基礎を理解していないのに応用に挑戦し前提知識がないのに高度な概念を理解しようとする。当たり前だがこれは無理だ。才能の問題ではなく順序の問題だ。
不快感を恐れないことも重要だ。学習において最も反直感的な真実の一つはある種の困難は実は学習を改善するということだ。同じチュートリアルの再読、すでに動くコードの微調整、すぐに答えを探すこと。これらは確かに楽だが長期的な学習効果は低い。
なぜか。脳は情報を取り出すのに苦労すること自体でその情報への神経経路を強化するからだ。簡単すぎる復習ではこの「取り出す苦労」が発生せず記憶が強化されない。効果的な方法は少し忘れかけたタイミングで復習すること。概念を学び1日空けて何も見ずに説明しようとし思い出せない部分を確認する。難しく忘れかけていて思い出すのに苦労するがこの苦労こそが記憶を強化する。
新しい概念を学ぶとき混乱は不快で「もう無理だ」と思う。でもこの不快感こそが成長の証なのだ。脳が新しい構造を構築しようとしている証で既存の理解の枠組みが崩れ新しい理解が生まれつつある証だ。この不快な状態を抱えたまま学び続け逃げずに向き合う。ある日突然繋がる。その瞬間の爽快感はすべての苦労を報いてくれる。「快適ならやり方が間違っている」という言葉がある。本当の成長は常にコンフォートゾーンの外側で起きる。
最後にエラーメッセージをちゃんと読み仮説を一つずつ潰し主語と述語を把握する。こうした小さなこと。ワークショップの最後にある学生が「エラーメッセージちゃんと読んだらちゃんと書いてありました」と言った。当たり前のことだがこの当たり前のことができていない人は驚くほど多い。めんどくさいと感じるかもしれないがこの「めんどくさい」基礎作業を飛ばすから結果的に何倍も時間がかかってしまう。才能があるように見える人はこれらを実践しているだけで意識的か無意識的に。これらは訓練可能だ。小さく始める。不完全でも動く。その積み重ねだけだ。
エンジニアという仕事には一つの大きな救いがある。それは手を動かしている間才能への不安が消えるということだ。「自分には才能がない」という悩みは頭の中でぐるぐる回り始めるとどんどん大きくなるが「これを作りたい」と思って実装を始めた瞬間その悩みはどこかに消える。目の前にあるのは具体的な問題だけだ。
エラーが出て調べて解決してまた詰まってまた調べる。この「詰まる→調べる→解決する」のサイクルを回すこと自体が静かに自信を育てていく。理解の速さには個人差がありこれは残酷な現実だが、人生という長い時間軸で見たときこの速さの差は思ったほど大きくない。むしろ一歩ずつでも前に進み続けた人と途中で立ち止まってしまった人の差の方がはるかに大きい。
時間は誰にも平等だ。その時間を「理解できない問題の前での空回り」に使うか「今理解できることから順に積み上げていく前進」に使うか。この選択が長期的には想像もできないほどの差を生む。ぐちゃぐちゃ考える暇があったら手を動かす。才能について悩む時間を1行でも多くコードを書く時間に変え、理想の自分について考える時間を作りたいものを作る時間に変える。その積み重ねが気づけば「成長」と呼ばれるものになっている。
おわりに
ワークショップで出会った学生の一人が最近こんなメッセージを送ってきた。「ちゃんと読むようになったら解決が早くなりました」。彼は以前「才能がない」と言っていたが実際にはエラーメッセージを読み飛ばしていただけだった。その事実を言語化し意識的に「ちゃんと読む」ようにした。それだけで解決速度は変わった。些細なことだがその些細なことに気づくまで私は何年もかかった。
このポストで繰り返し述べてきたように動けない理由は言葉にしてしまえば驚くほど小さい。恥を恐れていて完璧を求めすぎていて「なんか不安」を「なんか」のまま放置していて、そして「才能がない」という誰も反論できない理由で全てから逃げていた。言葉にした瞬間それらは「対処可能な課題」に変わる。でも言葉にするまでが驚くほど難しい。なぜなら嫌な自分と向き合わなければならないから。
ワークショップを三年続けて一つ確信したことがある。最初は速かったのに途中で離れていった人たちがいて最初は遅かったのに黙々と続けている人たちがいる。三年後後者の方が圧倒的に前に進んでいる。「才能」という言葉を使った瞬間思考は停止する。でも「エラーメッセージを読み飛ばしている」と言語化した瞬間「じゃあちゃんと読めばいい」という対策が見える。そのシンプルな事実に気づくかどうか。それだけの差が長い時間をかけて想像もできないほど大きな差になる。
未熟な自分がワークショップを始めて三年。今でも不安はあり「自分なんかが教えていいのか」と思うこともある。でも若手と一緒に作業する中で気づいた。彼らが必要としているのは全てを知り尽くした完璧な指導者ではない。「才能」という便利な言葉で可能性を閉ざさず「じゃあどうすればいいか」を一緒に考える誰かだ。そしてそれは自分自身に対しても同じだと思っている。
「読んでいる自分は頑張っている気がする」という謎の達成感に私たちはいつまで浸っているのだろうか。本当に必要なのは手を動かすこと。小さく完璧でなくてもでも確実に前に進むこと。言葉にしない限り「なんか」は永遠に巨大な壁であり続けるが、言葉にしてしまえば思ったより大したことなかったりする。その一歩を踏み出すかどうか。結局それだけの話だ。
