7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

専門学校4年間の成長記録 - 失敗と後悔から学んだエンジニアの基礎

7
Posted at

はじめに

この記事は誰のため?
この記事は、これから専門学校に入学する方、すでに在学中の全学年の方に向けて書いています。私自身がまだ学びの途中ですが、4年間で経験した成功と失敗、そして「もっと早く知りたかった」と思うことをありのままに記録しました。

特に失敗談や後悔を多く含めています。成功体験だけでは見えない、リアルな学生生活を感じていただければ幸いです。


Part 0: 入学前に知っておきたかった3つのこと

4年間を振り返って、1年生の自分に伝えたいことを3つ挙げるなら:

1. 基礎を固めることが、すべての土台になる

資格勉強は「就活のため」だけではありません。技術書を読むにも、他人のコードをレビューするにも、基本情報レベルの知識がなければ話になりません。「なんとなく動いている」と「なぜ動いているか理解している」の差は、年次を重ねるほど大きく効いてきます。

2. 何でもいいので、自分で何か開発してみる

教科書を読んだだけでは得られない、手を動かし、疑問を持つ中でしか生まれない理解があります。「ここをこうしたい」という考えが出てきて初めて、技術の本質に触れることができます。

3. AIはうまく活用する

生成されたコードを確認せずに使うと「考える力」が落ちます。しかし、エビデンスや最新情報を読み込ませたり、コードの意図を説明してもらう使い方は、学習効率を大きく高めます。AIを「答えをくれる存在」ではなく「一緒に考えてくれるパートナー」として使いましょう。

補足: 無理に知識を深掘りしすぎなくていい
初めのうちは、満遍なく全体を知る方が大事だと考えます。一つの技術を深く掘り下げるのは、全体像が見えてからでも遅くありません。


Part 1: 4年間の実体験と学び


【1年目】資格と基礎 - 土台を作る1年

やったこと

Pythonの基礎やHTML/CSSを学習
当時AIを使ってコードを書くことも主流ではなかったため、Chromeで知らないことを随時調べながら学んでいきました。その過程で、VSCodeの基本的な操作も身につきました。

右も左もわからなかった頃、「どうすれば綺麗なコードを書けるか」という疑問からPEP8を読んだことが、コーディング規約への意識の芽生えでした。

CSの学習と基本情報技術者試験
「まずはITの基礎的な知識を理解しないと始まらない」と考え、基本情報技術者試験の勉強に没頭しました。授業内のみの学習では取得は厳しいと感じ、授業外にキタミ式イラストIT塾 基本情報技術者の参考書を読んで、基礎を学びながら行きや帰りの電車で過去問道場をひたすら解いて勉強をしていました。

  • 勉強時間: 1日3時間程度
  • 勉強期間: 秋頃まで
  • 結果: 午前が7割、午後が満点(一発合格)

過去問は10年分をほぼ完璧にするまで解きました。授業内の学習では進みが遅く、過去問の経験数が少なかったため、どういうパターンの問題があるのか把握するには足りないと感じました。

学内コンテスト
「就職活動で武器になるのではないか」と考え、そこそこの時間(約2週間)を割いていました。テーマにあった物を自分で作ることで、HTMLタグやCSSのプロパティをうまく使えるようになりました。

「ここをこうしたい」という考えも出てきて、JavaScriptを書いて動きを出してみたり、CSSを応用したり、デザインを変えてみたり、試行錯誤することでWebについて理解が進みました。

当時の後悔と今ならこうする

後悔: Gitの知識不足
2年でチーム開発があることを考えると、1年のうちからGitの基本を学んでおくべきでした。就職後もほぼマストで使うツールなので、早めに触れておいて損はありません。

後悔: ドキュメント化の習慣がなかった
学んだことを自分の言葉でドキュメントにまとめる習慣を、1年の頃から身につけておけばよかったと強く後悔しています。知識の定着と見直しができる良さは、4年になってようやく気づきました。

良かったこと: AI流行前だったこと
AIに聞くだけではなく、自分で調べて試すことで知識が定着した気がします。時間はかかりましたが、逆に勉強になりました。

今ならこうする:

  • Gitの基本コマンドとブランチ戦略を学ぶ(翌年のチーム開発に備えて)
  • 学んだことをMarkdownでドキュメント化する習慣をつける
  • 「とりあえず動くもの」を作って自信をつける

【2年目】バックエンドとチーム開発 - 初めての壁

やったこと

Flaskやjavascript、DBの基礎を学習
簡単なログインやCRUD、データの型、ER図、SQLの作成などを学んでいました。
DB関連ではphpmyadmin、mysqlを使用していました。

進級制作(チーム開発)
Django × Three.jsで「3D内見物件検索サイト」を開発。ここで初めてFigmaGitを使い、チーム開発の難しさとデザインの大切さを学びました。

個人プロジェクトとは全く異なり、複数メンバーの技術力や進捗がバラバラの中で役割分担し、コードレビューを通じて他者の実装を評価する経験をしました。

応用情報技術者試験の取得
基本情報を1年の秋に取得後、2年の4月から応用情報の勉強を始めました。

  • 勉強時間: 1日平均5時間(授業以外の時間を全て使用)
  • 勉強期間: 半年間
  • 結果: 午前8割、午後7割(一発合格)

実際に使用していた参考書(最新版):

午後問に不安があったので、過去問の参考書を買って理解するまでひたすら周回していました。

ベンダ系資格の取得
応用情報取得後、少し時間ができたので、学んだことを形に残そうと思い勉強を始めました。主にUdemyで学習していました。

技術書を読み始める
資格取得のために参考書として購入した、Pythonチュートリアルを読み進める中で、言語の仕様だけでなく、設計思想や歴史的背景を深く学べることに気づきました。

当時の後悔と今ならこうする

大きな後悔: チーム開発でのワンマンプレー
知識がある人(自分を含む)が、メンバーのレベルに合わせずワンマンプレーになってしまうことが多々ありました。周りのチームでも同じ光景を何度も見ました。

良くも悪くもないチームの雰囲気でしたが、成果物は納期がギリギリになったり、メンバーのやる気を損なう結果になりました。

今ならこうする:

  • レベルに合わせた仕事を分配する
    • HTML/CSSができる人 → デザイン実装
    • 初心者 → ドキュメント作成、簡単な機能実装
  • ペアプログラミングで一緒に進める
    • できる人と初心者がペアを組んで、一緒にコードを書く
    • AIペアプロも活用して、生成されたコードをPRでレビュー
    • ただし、全員がGitを理解していることが前提

Git運用での大失敗

  • メンバーが強制pushで上書きしてしまい、コミットの粒度が大きすぎてかなり前に戻ってしまった
  • 全員がGitを使えるほどの知識がなかった

今ならこうする:

  • PRを使ってメンバー同士でレビューを行う(3年のチーム開発で導入したが、全員が理解していない状態だったので、全体がちゃんと理解してから使うべきだった。4年では問題なく使用できた)
  • ブランチを適切に切り分け、何をしているかわかるような命名にする
  • コミットの粒度: 機能単位で分けて、動く状態+テストが通った状態でコミットする

応用情報の勉強の辛さ
試験前1ヶ月は「やりたくないけど、試験が近いからやるしかない」という感じで、毎日勉強するだけの日々に飽きてきました。「受からなかったらもったいない」(特に時間。落ちたらまた半年後になる)という気持ちでひたすらやっていました。

乗り越え方:

  • 適度に友人と遊ぶくらい気持ちに余裕を持つ
  • 睡眠時間は削らず、早起きで時間を稼ぐ
  • バイトを適度に入れ、勉強の息抜きにする

時間配分:
チーム開発と応用情報の取得が重なったため、基本的に一日中どちらかをやっていました。チーム開発は授業内に収める形でやろうとしていましたが、間に合わないこともあったので、資格勉強の息抜きとしてチーム開発の内容を行い、バランスを維持していました。


【3年目】就活と独学 - 悔しさが生んだ成長

やったこと

モバイル・オブジェクト指向言語の習得
SwiftやKotlin、Javaといった言語を通じて、クラス設計やメモリ管理といったオブジェクト指向の本質を学びました。フロントエンドだけでなく、バックエンドやネイティブアプリの設計思想を体験することで、言語の垣根を超えた「プログラミングの本質」が見えるようになりました。

応用情報のDB分野の強みをきっかけに、DBスペシャリストを意識
応用情報のDBの得点が良かったことから、DBスペシャリストを取得しようと考えていました。ただ、就活のことも考えると取得する自信がなかったこともあり、資格は諦めました。

後悔はありません。 より実践的な知識を全体的に身につけるいい時間になったのと、就活に力を入れられたからです。その代わりに、就職してから実戦で使えるような知識を身につけるために、DBの書籍を読み進めていました。

就活が中心の生活
5月のGWから企業を探し始め、説明会や選考を受け始めました。主にレバテックさんと個人的に気になった企業を直接申し込む形で進めていました。面接では、ウェブサイトを作って公開した経験や、2年でのチーム開発の経験を武器にして、11月ごろに就職を終えました。

  • 応募企業数: 6〜7社
  • 書類落ち: 2社
  • 内定: 11月頃

最終面接での落選と独学
就職活動中、第一志望の企業の最終面接で落ちるという経験をしました。その時の課題がRubyとGitでした(具体的な内容は企業情報が含まれるため記載できません)。

初めての就活での面接だったこともあり、緊張で言葉足らずになったり、企業に対しての知識が足りなかったように感じました。落ち着いて自信を持って応じることと、焦ってすぐに回答するよりは考えてから受け答えできればもっと印象が良かったのかなと感じます。

面接後は少しショックでしたが、まだ始まったばかりで初めての企業だったので、数分で切り替えられました。

この経験をきっかけに、学校では扱っていないRuby on Railsの独学を始めました。公式ドキュメントを読み、実際にプロジェクトを作り上げ、学内コンテストで入賞するレベルまで作り込むことができました。

  • 勉強時間: 1日4時間程度(授業外)
  • モチベーション: 技術的にも書きやすくて面白かった、自分だけができるという優越感

ただし、学内コンテストで入賞した時は「もっと高みを目指せたな」と思いました。開発が悪いというよりは、企画自体が面白みに欠けた気がします。

当時の後悔と今ならこうする

後悔: 就活の準備不足
面接での受け答えや企業研究が不足していました。

今ならこうする:

  • 企業の事業内容や技術スタックを事前に深く調べる
  • 想定質問を考え、答えを準備しておく
  • 模擬面接をしてもらう

学内コンテストの企画について
技術力があっても、企画で負けることがあります。

おすすめの企画:

  • ユニークで誰もやっていないようなことを題材にする
  • 見やすくて綺麗なUIを作る
  • SNSなどの既存のものを作ってもインパクトが薄い
  • 何か拡張してみたり、「すごい」「おもしろい」などの感想が同時に得られる作品が強い

時間配分:
就活自体、1日の時間をそこまで奪われるものでもないと考えていました。朝早く起きて時間を稼ぎ、余裕があれば勉強していました。


【4年目】技術書・セキュリティ・集中力 - エンジニアとしての土台固め

やったこと

技術書でインプット
時間ができたので、知識のインプットを重視して、様々な書籍を読みました。
API・セキュリティ・原理・原則・思考法など、エンジニアとしての前提のようなものを叩き込みました。

読むペースは本当にバラバラ。読みたいのがあれば買う、全て読むにはページ量が多すぎるようなものもあるので気になったところから読んだり、開発中気になったことを辞書的に使ってみたりしていました。

セキュリティ意識の芽生え
安全なWebアプリケーションの作り方を読んで、セキュリティの各事象について考えるようになったのは、かなり大きな変化でした。フォームや管理画面のアクセス制御など、コード面だけでなくインフラまで、あらゆる脆弱性リスクに目を向けられるようになりました。

読書習慣の変化
普段本を読むことがなかった自分が、技術書をきっかけにエンジニアとは関係のない本まで読むようになりました。文章を読む体力がつき、技術ドキュメントなども抵抗なく読めるようになったのは、この習慣のおかげだと感じます。

集中力と学び方の変化
1・2年は音楽やラジオを聴きながら作業していましたが、4年になって「集中できない」と感じ、何も聞かず没頭するようになりました。

最初は無音が落ち着かなかったですが、徐々に一つのタスクに意識が向くようになった気がします。手が空いた時間も、自分のコードを見直したり、得た知識をドキュメントにまとめたりするようにした結果、前よりも知識の定着も開発の進みも良くなっていった印象を受けます。

知識をドキュメントに起こすことの重要性
4年から始めました。きっかけは、どこかでそのような記事を見てやってみようと思ったのと、AIにコードを書かせていたときに、何をしているか自分では理解できていないという問題に直面したからです。

AIのコードをちゃんと理解して使用するためにドキュメントにまとめるようにしています。作業終わりに30分くらいで作る感じです。時間がかかる時も全然ありますし、詰まったものを解決した時すぐにドキュメントに起こしたりすることもあります。

書籍や調べ物で得た知識を、自分の言葉でドキュメントにまとめ直すことで理解が格段に深まることを実感しました。「わかったつもり」と「人に説明できる」の間には大きな差があり、アウトプットすることが最良のインプットだと気づけたのは大きな収穫です。

AIツールの進化と活用
2年からGPT(無償)、3年でCopilot(学生プラン)を使い始め、途中から、質が高く生成が速いと噂だったCursorに移行して開発。企画などを考えるときはGeminiの学生Proプランを使用して壁打ちしていました。4年でClaude ProとCopilot、Geminiの学生Proプランをしています。

使い分け:

  • Copilotのplanモードで指示を作成
  • 適切かClaudeに聞きながらコーディング
  • Geminiは気になったことや質問などの普段使い

使い方によっては学習効率が上がりますが、生成されたコードを確認せずに使用したら、自分で考える力が落ちます。 エビデンスや最新情報などを読み込ませたり調べてもらいながら、生成されたコードを説明してもらうのに使うのはかなり使える印象です。

使い始めた頃は精度がそこまで高くなかったので、勉強にはほとんど使用していませんでしたが、開発における学習はAIに聞きながら学習できるので積極的に活用しています。何をしているかやコードの意図などを確認するのに使用しています。

当時の後悔と今ならこうする

大きな後悔: ドキュメント化を4年から始めたこと
1年の頃からドキュメントにまとめておくことは、知識の定着にとって本当に大事だと思います。4年間で最も後悔していることの一つです。

後悔: AIへの依存
課題などで「とりあえず動くもの」を作るために、確認せずにAIのコードを使用していたことが多々ありました。今思えば、自分で理解することによって、もっと知識をつけられたと思いますし、いいコードを書く練習になったのではないかと後悔しています。

簡単な作品を作る課題は、どれだけ応用して自分のアイデアと結びつけるかが大事だと思いました。そしてそれがモチベーションになり、より良い勉強になると思います。

良かったこと: 筋トレを継続したこと
4年間を通して週末のバイトと筋トレを続けていました。体を動かすことで脳が活性化し、リフレッシュできたと感じています。


Part 2: 4年間を経て気づいたこと


基礎知識はすべての土台になる

1年目に「まず基礎を固めよう」と基本情報の勉強に没頭し、2年目には応用情報やベンダ系資格まで取得しました。当時は「就職活動で武器になるだろう」という考えだけで突っ走っていましたが、振り返ると効果は想像以上でした。

エントリーシートの時点で他の応募者と差別化でき、書類選考の通過率が段違い。周りの資格保有者たちも内定獲得が早く、採用企業側にとって「基礎を習得している」という証明になっていたのだと思います。

そして何より、技術書を読むにも、他人のコードをレビューするにも、基本情報レベルの知識がなければ話になりません。「なんとなく動いている」と「なぜ動いているか理解している」の差は、年次を重ねるほど大きく効いてきました。


手を動かし、「なぜ」を問い続けること

1年目の学内コンテストでは、テーマにあった物を自分で作ることによって、HTMLやCSSの理解が一気に進みました。

自分で疑問を持ち、調べ、形にすることで、初めて「なぜそうなっているのか」を深掘りできるようになりました。教科書を読んだだけでは得られない、手を動かし、疑問を持つ中でしか生まれない理解がありました。

また、資格試験で得た「正解を覚える」という学習スタイルから、技術書を通じて「なぜそうなっているのか」という本質的な理解へシフトすることで、エンジニアとしての教養が深まりました。


品質にこだわる

2年目のチーム制作で痛感したことがあります。発表直前に「UIは完璧だからエラーハンドリングは少し手抜きしよう」という誘惑に駆られることがありました。しかし、本番環境では想定外の入力や予期しないエラーが必ず発生します。

納期に迫られる気持ちは理解しますが、「誰もが触るコード」だからこそ、最後まで品質に拘り続けることの重要性を学びました。


技術書はとりあえず読んでみる

1・2年目は「動けばOK」という感覚でコードを書いていました。しかし4年目にプリンシプル オブ プログラミングから原理・原則を学び、安全なWebアプリケーションの作り方でセキュリティの各事象に向き合ったことで、「なぜこの設計なのか」「このコードにはどんなリスクがあるのか」を自然と考えるようになりました。

フォームのバリデーション、管理画面のアクセス制御、SQLインジェクション対策など、「動くコード」と「安全なコード」は別物だという意識が、エンジニアとしての成長を一段押し上げたと感じます。コードの量ではなく、判断の質が変わった1年でした。


集中とアウトプットが学びの質を変える

4年目のもう一つの大きな変化は、学び方そのものでした。音楽を止め、手が空いた時間をドキュメント作成に充てるようにしただけで、知識の定着速度が大きく変わりました。

「わかったつもり」と「人に説明できる」の間には大きな差があります。アウトプットすることが最良のインプットだと気づけたのは大きな収穫です。「ながら作業」をやめて一つのことに没頭する姿勢は、エンジニアに限らず、どんな仕事でも活きる習慣だと思います。


Part 3: 失敗から学んだこと - 同じ過ちを繰り返さないために

ここでは、4年間で経験した具体的な失敗パターンとその対処法をまとめます。私と同じ失敗をしないために、参考にしていただければ幸いです。


失敗1: チーム開発でのワンマンプレー

何が起きたか:
知識がある人が、メンバーのレベルに合わせずワンマンプレーになってしまった。自分もその一人でした。納期がギリギリになったり、メンバーのやる気を損なう結果になりました。

なぜ起きたか:

  • 「自分がやった方が早い」という焦り
  • メンバーのレベルに合わせたタスク分配ができていない
  • コミュニケーション不足

対処法:

  • レベルに合わせた仕事を分配する
    • HTML/CSSができる人 → デザイン実装
    • 初心者 → ドキュメント作成、簡単な機能実装
  • ペアプログラミングで一緒に進める
    • できる人と初心者がペアを組んで、一緒にコードを書く
    • AIペアプロも活用して、生成されたコードをPRでレビュー
  • 定期的にチームで進捗を共有する

失敗2: Gitの理解不足

何が起きたか:

  • メンバーが強制pushで上書きしてしまった
  • コミットの粒度が大きすぎて、かなり前に戻ってしまった
  • 全員がGitを使えるほどの知識がなかった

対処法:

  • PRを使ってメンバー同士でレビューを行う(ただし、全員がGitを理解していることが前提)
  • ブランチを適切に切り分け、何をしているかわかるような命名にする
  • コミットの粒度: 機能単位で分けて、動く状態+テストが通った状態でコミットする
  • 1年のうちからGitの基本を学んでおく(2年でチーム開発があるため)

失敗3: AIへの依存

何が起きたか:
課題などで「とりあえず動くもの」を作るために、確認せずにAIのコードを使用していた。何をしているか自分では理解できていないという問題に直面しました。

対処法:

  • 生成されたコードを必ず確認する
  • AIに「このコードを説明して」と聞く
  • エビデンスや最新情報を読み込ませて、一緒に考える使い方をする
  • 簡単な作品を作る課題は、どれだけ応用して自分のアイデアと結びつけるかが大事

失敗4: ドキュメント化の習慣がなかった

何が起きたか:
学んだことをドキュメントにまとめる習慣がなく、4年になってようやく始めた。知識の定着と見直しができる良さを、もっと早く知りたかった。

対処法:

  • 1年の頃からドキュメント化を始める
  • Markdownで学んだことをまとめる
  • 作業終わりに30分程度で、その日学んだことを書く
  • 詰まったものを解決した時、すぐにドキュメントに起こす

失敗5: 就活の準備不足

何が起きたか:
初めての就活での面接で、緊張で言葉足らずになったり、企業に対しての知識が足りなかった。

対処法:

  • 企業の事業内容や技術スタックを事前に深く調べる
  • 想定質問を考え、答えを準備しておく
  • 模擬面接をしてもらう
  • 落ち着いて自信を持って応じる
  • 焦ってすぐに回答するよりは、考えてから受け答えする

Part 4: 各学年での優先順位

自分の経験を元に、各学年で「これだけはやっておくべき」ことをまとめました。


1年目の優先順位

必須:

  1. 基本情報技術者試験の取得(または同等の基礎知識の習得)
  2. 何でもいいので、自分で何か開発してみる
  3. Gitの基本を学ぶ

推奨:

  1. ドキュメント化の習慣をつける
  2. PEP8などのコーディング規約を読む
  3. 技術書を1冊読む

余裕があれば:

  1. 学内コンテストに参加する
  2. AIツールを試してみる

2年目の優先順位

必須:

  1. チーム開発でGitを使いこなす
  2. 応用情報技術者試験の取得(または同等の知識の習得)
  3. バックエンドとDBの基礎を固める

推奨:

  1. 技術書を読む習慣をつける
  2. ベンダ系資格を取得する
  3. セキュリティの基礎を学ぶ

余裕があれば:

  1. オブジェクト指向の理解を深める
  2. Udemyなどで実践的な講座を受講する

3年目の優先順位

必須:

  1. 就活の準備(企業研究、自己分析)
  2. 面接対策(想定質問)
  3. 実践的なプロジェクトを作る

推奨:

  1. 新しい言語やフレームワークに挑戦する。または得意な言語を深掘りする
  2. DBの知識を深める
  3. 学内コンテストで入賞を目指す

余裕があれば:

  1. 高度資格(DBスペシャリストなど)に挑戦する
  2. 技術コミュニティに参加してみる

4年目の優先順位

必須:

  1. セキュリティの知識を深める
  2. 設計思想や原理・原則を学ぶ
  3. ドキュメント化の習慣を徹底する

推奨:

  1. AIツールを使いこなす
  2. 集中力を高める習慣をつける
  3. 技術書を辞書的に使う

余裕があれば:

  1. 技術ブログを書く(Qiitaなど)

4年間のまとめ

取得資格

  • 国家資格: 基本情報技術者、応用情報技術者
  • 認定資格: Python3エンジニア認定基礎、Python3エンジニアデータ分析、Microsoft Azure Fundamentals (AZ-900, AI-900)

経験した技術・ツール

  • Frontend/App: React, Next.js, Flutter, Swift, Kotlin
  • Backend: Python (Flask, Django, FastAPI), Ruby (Ruby on Rails), Java
  • Design/DevOps: Figma, Git/GitHub, Azure, GCP, Supabase
  • AI Tool: Claude (Main), Cursor, GitHub Copilot, ChatGPT, Gemini

書籍(当時読んだ書籍の最新版を記載しています)

Udemy


おわりに:これから学ぶ皆様へ

4年間を振り返って、やっておいて本当に良かったことは「遠回りに見えることを、愚直にやり続けたこと」です。

  • 資格試験の勉強は無駄じゃない。技術を理解するための語彙力になる
  • 読書は無駄じゃない。コードや設計の善し悪しを判断する材料になる
  • 挫折は無駄じゃない。新しい技術へ飛び込む最高のきっかけになる
  • アウトプットは無駄じゃない。「わかったつもり」を「本当にわかった」に変えてくれる

近道はないけれど、一つ一つの経験が確実に積み上がっていきます。

この記事が、これから専門学校で学ぶ方、現在在学中の方の参考になれば幸いです。私自身もまだまだ学びの途中です。一緒に成長していきましょう。


執筆後記

この記事は、4年間の成功と失敗をありのままに記録したものです。もし「ここはこうした方が良い」「この部分をもっと詳しく知りたい」などのフィードバックがあれば、ぜひコメントで教えてください。

7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?