自己変容を受け入れる
おやかた氏のサークルである親方Projectでは、様々な同人誌を出したり、それを底本とした書籍を出版している。
その親方Projectで出している合同誌が今度の冬コミに出る。正式なタイトルは忘れたが、たぶん「ワンストップ！学び」とかそういうタイトルだったと思う。学びをテーマにした本だ。
あなたのサークル「親方Project」は、コミックマーケット105で「月曜日 西地区 “う”ブロック－27a(西２ホール)」に配置されました！コミケWebカタログにてサークル情報ページ公開中です！ https://t.co/onykmDsyQJ #C105WebCatalog
— おやかた@冬コミ月曜 西う27ab(bは技書博) (@oyakata2438) November 8, 2024
さて、筆者は、この合同誌に5章の記事を寄稿したので、5日連続でその原稿をnoteに公開していこうと思う。興味があれば、是非コミケや技術書典など、実イベントで印刷された本を手に取ってみてほしい。
12/10 学びと言語化
12/11 学びのプロセスを詳細に分解する
12/12 学びhack
12/13 自己変容を受け入れる
12/16 生成AIを活用する
今日は12/13の「自己変容を受け入れる」だ。
最後の章だけは寄稿したものとは少し違うバージョンを書き下ろしの予定だ。楽しみにしていてほしい。
第四章：自己変容を受け入れる
学びと言語化にて、学ぶとは自己変容であると書いたが、ここまで自己変容については触れてこなかった。この章では、学びにおいて意外と重要な自己変容について書いてみよう。
学びにおける自己変容
学びによる自己変容とは、単なる知識の蓄積以上のものだ。それは、物事の見方や考え方、さらには自分自身に対する理解までもが変化していく過程を指す。時として、それは人生の大きな転換点ともなりうる。
プログラミングを例に考えてみよう。最初は「プログラミングは難しい」と感じていた人が、学びを重ねることで「プログラミングは工夫次第で実現できる」という考え方に変わっていく。これは単にプログラミングの技術を習得しただけでなく、問題に対するアプローチの仕方自体が変容したことを意味する。
自己変容は、主に四つの側面で起こる。
第一には認知的枠組みの更新だ。新しい情報や視点に触れることで、これまで持っていた思考の枠組みが更新される。「エラーは失敗の証」という考えから、「エラーは次のステップへのヒント」という見方への転換は、その典型例だ。
第二には価値観や態度の変容だ。「完璧なコードを書かなければ」という強迫的な考えから、「まず動くものを作り、それを改善していく」という現実的な姿勢への転換などが、これにあたる。これは単なる技術的な進歩ではなく、ものづくりに対する根本的な態度の変化を示している。
第三には自己認識の深化だ。学びを通じて「自分は何を知らないのか」「なぜこのように考えるのか」といった問いに向き合うことで、自分自身への理解が深まっていく。たとえば、「自分は細部にこだわりすぎる傾向がある」という気づきは、より効率的な学習方法の選択につながる。
第四には日々の行動様式の変化だ。問題に直面したとき、以前なら諦めていたかもしれないが、「きっと解決方法がある」と信じて調査を続けられるようになる。エラーメッセージを見ても慌てなくなり、むしろ「次に何をすべきか」を考える手がかりとして捉えられるようになる。
自己変容のプロセスと段階
自己変容は一朝一夕には起こらない。それは段階的なプロセスとして進行する。最初の段階は「気づき」だ。自分の現状や限界に気づき、変化の必要性を認識する。新しい技術に触れたとき、「このままでは時代に取り残される」という危機感を覚えるのは、この段階の典型だ。
次に「準備」の段階がある。新しい知識や技術を学び、変化に向けて準備を整える。この段階では、具体的な目標を設定し、必要なリソースを集める。新しいプログラミング言語を学ぶと決めたなら、まずは基本的な文法や開発環境の整備から始める。
そして「実践」の段階で実際の変化が起こる。学んだことを実際に試し、失敗と成功を繰り返しながら、新しい自分を形作っていく。最初は不安定で、以前の方法に戻りたくなることもある。しかし、一つ一つの経験が、新しい習慣や考え方を形成していく。
最後に「定着」の段階で新しい自分が形成される。変化が自然なものとなり、新しい考え方や行動が無意識のうちに出てくるようになる。たとえば、問題解決のアプローチが、以前とは全く異なる形で自然に行えるようになる。
このプロセスをより効果的に進めるには、内省的な態度が欠かせない。自分の思考や行動を客観的に観察し、「なぜそう考えるのか」「なぜそう行動するのか」を問い続ける姿勢が必要だ。ソフトウェア開発で言えば、コードレビューは単なる品質管理以上の意味を持つ。自分のコードの特徴や癖を知り、より良い方法を学ぶ機会となる。
批判的思考も重要な要素だ。新しい情報や手法に出会ったとき、それを鵜呑みにせず、自分なりに検証し、既存の知識と照らし合わせて評価する。これにより、より深い理解と確かな変化が可能になる。たとえば、新しいフレームワークを導入する際、その利点だけでなく、自分たちのプロジェクトにとって本当に適切かを慎重に検討する姿勢が必要だ。
自己変容の個人差を理解する
自己変容に対する適性は、人によって大きく異なる。変化を自然に受け入れられる人もいれば、強い抵抗を感じる人もいる。これは単なる性格の違いではなく、それぞれの経験や価値観、思考様式が影響している。
変化を受け入れやすい人には、いくつかの共通した特徴がある。新しいアイデアや異なる価値観に対して、「面白そうだ」「試してみたい」という好奇心を自然に感じる。失敗を恐れすぎず、むしろ学びの機会として捉えられる。そして、常に自分を改善していきたいという強い意欲を持っている。
一方、変化を受け入れづらい人は、既存の自分への愛着が強かったり、失敗への不安が大きかったりする。「今のやり方で十分だ」「変化によって何かを失うのではないか」という思いが、新しい一歩を踏み出すことを躊躇させる。
しかし、これは克服できない壁ではない。変化への抵抗を感じる人でも、適切なアプローチを取ることで、徐々に自己変容を受け入れられるようになる。最も効果的なのは、小さなステップから始めることだ。大きな変革を一度に目指すのではなく、わずかな思考や行動の変化から試してみる。
たとえば、新しい技術を学ぶ際、いきなり本番のプロジェクトに導入するのではなく、まずは小さな個人プロジェクトで試してみる。あるいは、チーム内で限定的な範囲から始めてみる。こうした段階的なアプローチにより、変化への不安を最小限に抑えながら、新しい経験を積むことができる。
メタ認知と自己変容
自己変容をより効果的に進めるには、メタ認知、つまり自分の思考や学習プロセスを客観的に観察し、理解する能力が重要となる。これは単に「何を学んでいるか」だけでなく、「どのように学んでいるか」「なぜそのように学ぼうとしているのか」を理解することを意味する。
具体例を見てみよう。ソフトウェア開発の場合、新しい技術を学ぶとき、多くの人は「とりあえずチュートリアルをやる」というアプローチを取る。しかし、メタ認知を働かせることで、このアプローチ自体を見直すことができる。なぜチュートリアルを選んだのか、自分の学び方の特徴は何か、より効果的な方法はないか、といった具合に。
実践的な振り返りの方法として、開発者の多くが活用している「ふりかえり」の手法が参考になる。一日の終わりに、その日の学びを三つの観点から振り返る。「今日理解できたこと」「まだ理解できていないこと」「次に試したいこと」。これを継続することで、自分の学びのパターンや、効果的な方法が見えてくる。
技術書を読むときも同様だ。単に内容を追うだけでなく、「なぜここで理解に詰まったのか」「どの説明が特に分かりやすかったか」「自分なりの理解の仕方は何か」を意識的に観察する。この観察を通じて、自分に合った学び方が見えてくる。
自己変容を阻む要因
変化を望みながらも、なかなか一歩を踏み出せないことがある。その背景には様々な要因が存在する。現状への安住は、その代表的なものだ。慣れ親しんだ環境や方法から抜け出すことへの不安は、誰しもが感じるものだ。
具体的な例を見てみよう。プログラマーがある言語やフレームワークに長年携わっていると、新しい技術への移行に大きな抵抗を感じる。その理由は、蓄積してきた知識や経験が一時的に通用しなくなる不安、新しい環境での失敗への恐れ、そして学び直しの労力への躊躇だ。
この抵抗を和らげるためには、段階的なアプローチが効果的だ。新しい技術を完全に採用する前に、小規模なプロジェクトや個人的な実験から始める。既存の技術と新しい技術を並行して使うことで、急激な変化によるストレスを軽減できる。
自己診断のポイントとして、以下のような点に注目するといい。新しい技術や方法に触れたとき、即座に「それは無理だ」と判断していないか。失敗を過度に恐れて、挑戦を避けていないか。過去の投資を過度に気にして、新しい選択肢を検討する機会を逃していないか。これらの点を定期的にチェックすることで、自己変容を妨げる要因に気づきやすくなる。
大きな自己変容を受け入れる
自己変容には様々な規模がある。日々の小さな気づきによる変化もあれば、キャリアを大きく転換するような変化もある。特に大きな自己変容は、勇気が必要だ。しかし、それを受け入れる準備ができていれば、新たな可能性が開かれる。
技術者のキャリアを例にとると、ある技術スタックから全く異なる技術スタックへの移行は、大きな自己変容を必要とする。バックエンドエンジニアからフロントエンドエンジニアへの転向、あるいは特定の言語やフレームワークから全く異なるものへの移行は、その典型例だ。これは単なる技術の習得以上に、開発に対する考え方そのものの変革を求められる。
また、技術者からマネージャーへの転身も重要な自己変容の例だ。これまでとは全く異なる役割や責任を担うことになる。コードを書くことから人を導くことへ、技術的な問題解決から組織的な課題への対応へと、求められるスキルセットが大きく変わる。
このような大きな変化に向き合うとき、重要なのは段階的なアプローチだ。いきなり全てを変えようとするのではなく、まずは小さな実験から始める。新しい技術なら、サイドプロジェクトでの試用から。マネジメントなら、チームでの小さなリーダーシップの機会から。そして、その経験から学びながら、徐々に変化の規模を広げていく。
コラム：筆者が体験した二度の大きな自己変容
筆者は実に大きな自己変容を二度行っている。
一度目は、JavaScriptとReactへの転向だった。当時の筆者はバックエンド開発をしていたのだが、2015年に登場したECMA Script 2015という、今あるモダンなJavaScriptの形が定まったことで、あらゆる技術がJavaScriptに収束していく確信を得たことと、Reactに出会い同様にReactに収束していく確信を得たことで、フロントエンド、JavaScript/Reactに一点集中するという大きな賭けに出た。
この転向から得た最大の学びは、技術の変遷を見極める目だ。新しい技術が登場したとき、それが一時的なブームなのか、本質的な変化なのかを見分ける力が磨かれた。
2024年末である現代においてはPython, Java, JavaScriptが世界で最も使われている三大プログラミング言語である。JavaScriptやその発展形であるTypeScriptはフロントエンドのみならず、バックエンドでもメジャーな言語になった。フロントエンド技術としてはReactが文句なくスタンダードである。つまり筆者は掛けに大勝ちできた。
次の大きな自己変容は、一回目の転向で得たフロントエンドエンジニアとしてのキャリアを置いて、LLM（大規模言語モデル）の社会実装に全力を注ぐ決断だった。2022年末にChatGPTと出会い、2023年3月頃の土日に寝食を忘れて48時間耐久LLM研究をやってみたら、物の見事にLLMの魅力にとりつかれた。その後すぐ会社を辞める連絡をして、当時LLMで知り合った人と一緒にやっていく決断をして、そのあとその人が新しく立ち上げた会社に入社することが決まった。いまは、TypeScriptでフロントエンドもバックエンドも触っている、というかここ一年はバックエンドとLLMしか触ってない。
この二度目の転向では、直感を信じる勇気の重要性を学んだ。ChatGPTとの出会いは、まさに「これが未来を変える」という直感的な確信をもたらした。また、既存のキャリアを捨てるような大きな決断でも、それまでの経験は必ず新しいフィールドで活きることも実感として理解できた。
この大いなる掛けが、もう一度大勝ちをするかはこれから歴史が証明することになるが、筆者は当然一回目よりも大きな勝ちになると確信している。
これらの大きな変化を可能にしたのは、強い知的好奇心だ。筆者にとって、興味の対象を徹底的に探求することは自然なことだった。このような好奇心は、自己変容を受け入れる強力な原動力となる。
自己変容を促進する環境づくり
自己変容を効果的に進めるには、適切な環境づくりが重要だ。まず、変化を受け入れやすい心理的な環境が必要だ。「このままではうまくいかない」という危機感と、「変われば良くなる」という希望のバランスを保つことが重要だ。また、理想と現実のバランスも重要だ。高すぎる理想は挫折を招き、低すぎる理想は変化の動機を失わせる。
物理的な環境も重要だ。新しい学びや実践の機会を得やすい環境、失敗しても大きなダメージを受けない環境を整えることで、より積極的に変化に取り組める。たとえば、新しい技術を学ぶなら、実験用の開発環境を用意する。新しい役割に挑戦するなら、まずは小規模なプロジェクトで試してみる。
また、変化のプロセスを支えてくれる仲間や、メンターの存在も重要な要素となる。同じような変化を経験した人からのアドバイスは、特に価値がある。彼らの経験は、自分の変化の道筋を照らす灯台となる。特に技術の世界では、先人の経験から学ぶことで、同じ失敗を避け、より効率的な成長が可能となる。
さらに、変化を受け入れやすい思考様式を育むことも大切だ。新しいアイデアや異なる視点に対してオープンな態度を持つ。失敗を恐れすぎず、それを学びの機会として捉える。そして、自分の考えや行動を客観的に観察し、必要な調整を加えていく。この姿勢は、継続的な成長の基盤となる。
自己変容の多様性を理解する
自己変容のプロセスは、人によって大きく異なる。知的好奇心が原動力となる人もいれば、必要に迫られての変化もある。また、競争心や達成欲求が変化を促す場合もある。重要なのは、自分に合った形で自己変容を受け入れることだ。他人の変容のペースや方法と比較する必要はない。
たとえば、新しい技術への適応を考えてみよう。早い段階から積極的に取り入れる人もいれば、十分に成熟してから採用する人もいる。どちらが正しいということはない。むしろ、その人の状況や性向に合った選択が最適なのだ。技術選択において重要なのは、その技術が自分やチームにとって本当に必要かどうかを見極めることだ。
また、変化の動機も人それぞれだ。技術的な興味から始まることもあれば、キャリアの必要性から始まることもある。時には、周りの影響や、偶然の出会いがきっかけとなることもある。これらの違いは、変化のプロセスや結果に影響を与えるが、どれも等しく価値のある動機となりうる。
自己変容がうまくいかないとき
すべての自己変容が成功するわけではない。時には目標とは異なる方向に進むこともある。しかし、一見失敗したように見える変化でも、長期的には思わぬ形で活きることがある。技術学習を例にとると、ある技術の学習は直接的には実務で活用できなくても、その過程で得た考え方や知見が、別の場面で価値を持つことがある。
重要なのは、その経験から何を学び取れるかだ。たとえ目標とした変化が達成できなくても、そのプロセスで得られた気づきや、培われたスキル、広がった視野は、必ず何らかの形で役立つ。それは即座に現れることもあれば、何年も経って初めて価値を発揮することもある。
また、「うまくいかない」と感じるとき、それは本当に失敗なのか、それとも単に時期尚早だったのか、あるいは別の形での成功だったのかを、改めて考えてみる価値がある。変化の価値は、必ずしも当初の目標達成だけにあるわけではないのだ。
特に技術の世界では、一見無駄に見える回り道が、後になって重要な意味を持つことがある。たとえば、実務では使わない言語やパラダイムを学ぶことで、プログラミング全般への理解が深まることがある。また、一つの技術を深く理解することで、他の技術への応用力が高まることもある。
コラム：筆者の「失敗」から得た学び
筆者がバックエンドをやっていた頃、色々とうまくいかないことがあった。
HaskellやScalaやGo言語に手を出してみたり、DDDを学んだりしてきた。これらは当時の実務としてはうまく活用できなかった。
しかし、この「失敗」は別の形で実を結んだ。
JavaScriptは元々関数型言語の要素が色濃い言語である。最近は特に関数型言語としての特性が好まれる傾向が強く、たとえばReactなんかも関数型言語としてのエッセンスを学んでいると理解が捗る。そのため、HaskellやScalaの経験が役に立った。
同様にDDDやGoなんかもその後の設計方針に色々と反映されている。一見無駄に思えた学びが、思わぬ形で活きてくることは少なくない。
最近では、技術的負債への向き合い方も変わってきた。以前は完璧な設計を目指していたが、今は「本当に守るべき部分」を見極めることの方が重要だと考えている。技術の進歩は速く、今の負債は明日の当たり前になることもある。むしろ、変化に対する柔軟性を保つことの方が大切なのだ。
また、理想と現実のバランスも変わった。理想を追い求めることは大切だが、地に足のついた現実的なアプローチも同様に重要だ。どこにも完璧な環境や理想の楽園はない。それを認識した上で、今できる最善を尽くすことの方が生産的だ。
不安との付き合い方も学んだ。コントロールできないことを過度に心配しても仕方ない。むしろ、そのときできるベストを尽くし、それで十分だと認めることの方が建設的だ。
まとめ
学びにおける自己変容は、避けて通れないプロセスである。それは時として不安や抵抗を伴うが、これらの感情は変化の自然な一部として受け入れることが重要だ。変化は段階的に進み、時には後戻りしながらも、着実に前に進んでいく。
自己変容は、必ずしも計画通りに進むとは限らない。時には失敗し、時には予想外の方向に進むこともある。しかし、その過程で得られる学びは、必ず何らかの形で価値を持つ。重要なのは、変化を恐れず、かといって無理もせず、自分のペースで着実に前進していくことだ。そして、その過程で得られる気づきや学びを、次の変化への糧としていくことである。
このような自己変容の過程は、まさに学びそのものであり、それは終わりのない旅だ。その旅を楽しみ、自分なりの歩み方を見つけていくことこそが、真の学びの姿なのかもしれない。自己変容を受け入れることは、より豊かな学びの世界への扉を開くことなのだ。
お知らせ
学び合同誌にはこのような形で寄稿した。明日は第四章「自己変容を受け入れる」をお届けしよう。
12/10 学びと言語化
12/11 学びのプロセスを詳細に分解する
12/12 学びhack
12/13 自己変容を受け入れる
12/16 生成AIを活用する
次は12/16に公開予定の、書き下ろしでまたお会いしましょう。