はじめに
本記事では、文系・未経験の立場からWebエンジニアとして業務に向き合う中で、学習を業務にうまく活かせない状態から抜け出すために、どのような点が転換点になったのかを整理しています。
私は現在、26卒として就職を控えている学生です。TOKIUMというIT企業の長期インターンに参加し、約8ヶ月間、実務でのWebアプリ開発に携わってきました。
インターンを始めたばかりの頃は、「努力はしているつもりなのに身についている実感がなく、調べたり教わったりしても、次にどう活かせばよいか分からない」という状態に苦戦していました。本記事は、その原因を振り返りながら、思考法が切り替わるきっかけになった経験を言語化しました。
第1章から第3章では、当時の問題の原因を、次の三つの観点から整理しています。
- 課題をどう切り分ければいいかを知ったこと
- 知識を点ではなく、構造として捉えられるようになったこと
- 理解を一過性で終わらせず、蓄積できるようになったこと
特定の技術やフレームワークを解説するものではありませんが、同じように「頑張り方が分からない」状態にある人にとって、何らかの手がかりになればと考えています。
目次
はじめに
① 手を動かしながら、考え方を学んだこと
② 仕組みを知ることで、理解の土台ができたこと
③ 理解を「自分の言葉」で扱えるようになったこと
おわりに
① 手を動かしながら、考え方を学んだこと
文系・未経験として一番大きかった変化は、「理解してから手を動かす」でも「とりあえず動かす」でもなく、手を動かしながら、理解の仕方そのものを学んだことでした。
当初は、何が分かっていないのかも分からず、「考える」「理解する」という行為をどう始めればいいのか掴めていなかったと思います。
当時は、WebアプリやPCの挙動について、どこで何が起きているのかを想像できていませんでした。分解して考える対象という認識が薄く、仕組みというより「よく分からない何か」が動いている、という感覚に近かったです。そのため、何かおかしい挙動が起きても、どこから考えればいいのか分かりませんでした。
そのため、エラーや想定外の動きが出ると、自分で切り分けるよりも、AIや検索にそのまま投げてしまうことが多かったと思います。これはサボりたいわけでも、考えたくないわけでもなく、考え方の取っかかりが分からないため、自分で解消できる気がしなかったというのが正直なところです。
状況が変わり始めたのは、エラーや挙動に対して「どう向き合えばいいか」を具体的に教えてもらったことがきっかけでした。たとえば、エラーメッセージのどこを見るのか、どの処理が呼ばれていそうかをどう推測するのか、どこから切り分けていくのかといった、実際の手順です。これによって、「自分は何が分かっていないのか」「今、どこで詰まっているのか」を徐々に自覚できるようになりました。
これによって、「正しい順序で考えれば、自分でも状況を整理できそう」と思えるようになりました。
補足:コード・実装の理解の仕方が変わったこと
この頃から、コードや実装の理解の仕方についても考え方が変わりました。学習初期は、一行一行すべて説明できるようにする、すべて言語化して理解する、という指導を受け、その通りに実践しようとしていました。ただ、自分の場合は完璧主義なところもあり、既存実装を読むのに時間がかかりすぎたり、全体像が見えないまま細部に入り込んでしまったりすることが多くありました。そこで、コードそのものよりも一段抽象度を上げて、
- アーキテクチャ全体がどうなっているか
- クラスやメソッド同士がどうつながっているか
- データがどこからどこへ流れているか
といった点を意識して理解するようになりました。もちろん基本的な文法や構文が分かっている前提ではありますが、作業の目的から逆算して必要な理解を行えば良いと認識を改めたことで、心理的にも作業的にもかなり楽になりました。
② 仕組みを知ることで、理解の土台ができたこと
①で手を動かしながら理解する感覚が少し掴めてきた一方で、それだけではいただいたレビュー指摘や設計の話が腹落ちしない場面がありました。
そこで大きかったのが、PCやWebの仕組みを体系的に学んだ経験です。
当初は、PCがどのように動いているのかといったITの基本的な知識が十分に身についていませんでした。バックエンドやフロントエンド、データの受け渡し、APIといった言葉は知っていましたが、それらを分けて捉え、関係性として理解する視点がなく、知識が点のまま存在していたと思います。
そのため、データベースへの負荷を減らす、再利用可能な設計にするといった話を聞いても、言葉や概念として理解はできるものの、なぜそれが重要なのか、どこに効くのかがピンときていない時がありました。
この時点で、先輩からWeb技術の基礎やオブジェクト指向、リーダブルコードに関する本を薦めていただき、読んで理解はしていたつもりでした。
ただ、内容以前に、それらの知識を有機的に結びつける土台がもう一段階足りていなかったのだと思います。
そのような中、将来的に必要になることもあり、基本情報技術者試験と応用情報技術者試験の学習に取り組みました。特に良かったのは、次のような分野を体系として学べたことです。
- ソフトウェアの基本的な構造
- データベースの役割
- ネットワークの考え方
- OSやメモリの働き
自分は短期記憶があまり得意ではありませんが、資格学習では問題演習を通じて同じ概念に何度も触れます。一度で理解できなくても、間違えたり、他の知識と結びつけたりする中で、少しずつ長期記憶に残っていく感覚がありました。
その結果、コンピュータの中で起きていることについて、ブラックボックスというイメージが徐々に除去されていきました。どこで何が起きていそうか、これはどのレイヤーの話なのかを徐々に考えられるようになり、設計やパフォーマンスの話も処理の流れの中に位置付けられるようになってきました。教わった内容が頭の中で適切に整理され、取りだしやすくなった感覚が得られました。
以前は、本を読んでも途中で分からなくなり、目が滑ってしまうことが多くありましたが、資格学習で土台ができたことで、レビューや技術書の内容が理解につながりやすくなったと思います。
なお、上司に薦めていただいた本でも同じような内容は学べたはずですが、自分には「資格」という形式が合っていました。学ぶ内容に加え、個々人の特性に合った学び方が理解の進み具合に影響を与えていると思いました。
③ 理解を「自分の言葉」で扱えるようになったこと
①と②を通じて、エラーや実装に向き合うための足場と、PCやWebの仕組みに関する土台が少しずつできてきました。一方で、レビューや学習内容をその場では理解できた気がするのに、時間が経つとあまり身についていない、という感覚が残っていました。
当時は、レビューで指摘を受けたり説明を聞いたりすると、「なるほど」と思って次に進むことが多かったです。ただ、後から同じような場面に出会ったときに、その学びをうまく活かせていないことがありました。なぜその指摘が入ったのか、他の実装でも同じことに気をつけられるのか、といった点まで整理できていなかったのだと思います。
この課題をはっきり意識するようになったのは、学んだ内容やレビューの指摘を自分の言葉で説明しようとしたときでした。一文でまとめようとすると、思った以上に言葉に詰まることが多く、「分かったつもりだったが、実は理解しきれていなかった」ということに気づかされました。
言葉にできない部分は、そのまま理解が浅い部分でもあります。学んだ内容やレビュー指摘を自分の言葉で表そうとすることで、どこが曖昧なのか、どこを調べ直す必要があるのかが、以前よりもはっきり見えるようになりました。言語化をアウトプットというより、理解の状態を確認し、整理するための手段だと捉えることで前進できたと感じました。
その結果、レビュー内容をその場限りで終わらせず、別の実装で思い出して気をつけたり、似たような指摘を受けた際に結びつけたりすることが、少しずつできるようになりました。一度学んだことを、次の場面で再利用できる感覚が生まれたと思います。
「自分の言葉で説明する」というと当たり前のように聞こえるかもしれませんが、実際にやってみると、本質的に理解できていない部分ほど言葉に詰まることが分かりました。その詰まりによって、理解できている範囲と曖昧な範囲の境界が明確になります。自分はこの境界が見えるようになったことで、次に何を深掘りすればよいかを判断しやすくなりました。
おわりに
本稿で整理してきた三つの経験は、振り返ってみると、それぞれが独立した工夫というより、いくつかの要素が相互に影響し合いながら噛み合っていった過程だったように思います。課題をどう切り分けて考えればよいかを知り、知識を構造として捉えるための前提ができたことで、理解した内容を自分の中に蓄積していく余地が生まれました。
もちろん、これらは決して自分一人で獲得できたものではありません。
日々のレビューや対話の中で考え方を言語化してもらったことや、分からない状態を前提にサポートしてもらえたことが、成長を支える大きな土台になっていました。また、先輩の業務の進め方を間近で見る中で、自分の理解の進め方についても、見直す余地があると感じるようになりました。
何を学ぶかだけでなく、どう学ぶかという点を見直せたことも、①〜③で整理した変化を支えていた要素の一つだったと感じています。
学習を業務にうまく活かせない状態にあった頃は、努力の量や意欲の問題だと捉えていました。しかし今振り返ると、問題だったのは努力そのものではなく、考え始めるための手順や、理解を扱うための前提が揃っていなかったことでした。本稿で整理した内容は、その前提がどのように形作られていったかを、あくまで一つの体験として記録したものです。
すべての人に当てはまる内容ではないかもしれませんが、自分と似たようなところで立ち止まっている人にとって、自分の状況を整理する際の一つの材料になればと思います!