はじめに
自己紹介
はじめまして。新卒1年目のバックエンドエンジニアとして働いている ktmage です。
文系の経営学部出身で、学生時代にプログラミングの授業を受けたことはなく、情報系やコンピュータサイエンスの基礎もほとんどありませんでした。
そんな状態からエンジニアになった自分が、配属から半年ほど働いて感じたことをまとめます。
特に、これからエンジニアを目指す人（文系出身で不安がある人も含めて）が「まず何をやると良いか」を考える材料になれば嬉しいです。
この記事を書くことになった経緯
社内のアドベントカレンダーで記事を書く機会があり、本記事を書くことにしました。
テーマに悩んだのですが、学生から社会人に移り変わったタイミングで感じたことは新卒のうちに書いておきたいと思い、「文系がバックエンドエンジニアになる」をテーマにしました。
入社前は「文系だからエンジニアになれるのか？」という漠然とした不安があり、自分の中でもずっと気になっているテーマでした。
ただ、働いてみるとその感覚は少しずつ変わってきています。
今回は、その実感をなるべく読んでいる人にも伝わるように、できるだけ具体的に整理して書きます。
この記事で伝えたいこと
この記事を通して伝えたいのは、主に以下のことです。
- 文系からエンジニアになるために、やってよかった・やればよかったこと
- 25卒目線での、なるべく最新版の感覚
ざっくり時系列
前提として自分がプログラミングを始めてから就職するまでの時系列をまとめたいと思います。
自分は大学2年生から勉強を始めて、少しずつできることを増やしながら就職しました。
細かい順番は前後しているかもしれませんが、雰囲気としてはこんな感じです。
- 大学2年：プログラミングに触れてみる
- 大学2〜3年：気になった技術をいっぱい触る
- Unity
- .NET WPF
- Web
- React
- Express
- TypeScript
- etc..
- 大学3年：就活を見据えて、ポートフォリオやスキルを整えはじめる
- メモアプリを作る
- 基本情報技術者試験
- 就活~
やってよかったこと
Webの個人開発を1つ作って公開したこと
これは個人的に、いちばんやってよかったことです。
WebアプリやWebサービスなど、自分で何か1つ作り、公開するまで完遂する経験は本当に学びが多かったです。
「完成度」を追い求める必要はなく、たとえ小さなものでもいいので、0から1まで一貫して作りきることが大事だと思います。
ここが本当に大切です。
ここまでやると、仕事で自分が何をするのか、その輪郭がつかめるようになります。
なぜ「公開まで完遂」が効くのかというと、コードを書く以外にも必要なことを一通り経験できるからです。例えば、以下のようなことです。
- 何を作るかを決めて、要件を言語化する
- 詰まったときに原因を切り分けて、必要なら設計も見直す
- 動く状態にして、人に見せられる形で出す
成果物を人に見せられる状態にしておくと、就職活動や面談でも価値になるうえに、何より自分自身の自信になります。
自分の場合は、以下の技術スタックで簡単なメモアプリのようなものを作りました。
- TypeScript
- React
- Express
- Prisma + MySQL
クオリティはあまり関係なく（AIでなんかすごそうなものはいくらでもできるので）、「なぜこの技術スタックにしたのか」「なぜこの設計にしたのか」まで言語化できると、学びがより深まると思います。
例えば、メモアプリでも「入力→保存→一覧→詳細→編集→削除」みたいな一連の流れを作るだけで、API設計、DB設計、エラー処理、画面の状態管理など、実務に直結する要素が自然に出てきます。
もしこれから始めるなら、まずは「ログインなし」「CRUDだけ」みたいに範囲を絞って、短期間で公開まで持っていくのがおすすめです。
おまけ：スクリーンショット
（雰囲気が伝わればと思い、当時の画面を載せておきます）
基本情報技術者試験を取得したこと
もう1つやってよかったことは、基本情報技術者試験を取ったことです。
文系出身だと、情報系やCS系のバックボーンがない分、自分の能力を示す“わかりやすい証明”が少なくなりがちです。
AIで開発を進められる時代だからこそ、「基礎を理解している」ことを示せる指標は以前より重要になってくると思っています。
個人的には、AIを使うほど「前提の置き方」や「検証の観点」が重要になると感じています。何が分かっていて何が分かっていないかが整理できると、AIの出力も使える形にしやすいです。
基本情報技術者試験は、IT系の基礎知識を体系的に学べるだけでなく、客観的な指標としても使えます。
1〜2ヶ月程度の勉強で十分狙えるので、就活前に取っておくのは良いと思います。
実際に業務で活きることもあるので、無駄はないです！
（ここ基本情報でやったとこだ！みたいなことはザラにある。）
やればよかったこと
チーム開発を経験すること
今振り返ると、チーム開発をもっと経験しておけばよかったと思います。
友人との共同開発でもいいですし、できれば実務に近いアルバイトなどでのチーム開発経験があると、学べることが多いです。
個人開発では得られない、役割分担・コミュニケーション・レビューの流れなどの経験は、現場に出た後にも活きるものだと感じています。
特に、チームだと「正しいコードを書く」だけでは進みません。例えば、次のような要素が入ってきます。
- 仕様の認識合わせ（どこまでやるか、優先度は何か）
- レビューでの指摘の受け方・返し方
- 相談のタイミング（抱え込まない）
- 他人のコードを読んで理解する力
もしこれから始めるなら、身近な友人との小さな共同開発でもいいので、GitHubでIssueを切って進めたり、PRレビューを回したりすると、学べることが一気に増えます。
個人的には「まずIssueを小さく切る」「毎回PRを出す」だけでも、かなり実務っぽくなります。
テックブログを書くこと
もう1つ、もっと早くアウトプットを習慣化しておけばよかったと感じています。
具体的にはテックブログを書くことです。
テックブログを書くこと自体は意外とハードルが低く、学んだことをそのまま文章にするだけでも価値があります。
文章として残すことで理解が整理でき、振り返りもしやすくなり、将来の自分にとっても資産になります。
もう少し踏み込むと、ブログを書くことで「人に説明できる形まで理解する」習慣がつきます。面接や面談でも、自分の言葉で整理して話しやすくなりました。
「毎日書く」ではなく「月に1本」でも十分なので、続けられるペースで習慣化するのが一番大事だと思います。
最初は「詰まったポイントと解決策だけ」「学んだこと3つだけ」みたいに、短くてもいいので形にするのがおすすめです。
おわりに
ここまで読んでくださってありがとうございます。
この記事では、以下4つの要素を紹介しました。
- 個人開発
- 資格取得
- チーム開発
- テックブログ
（ありきたりな内容かと思いますが、それほど重要なのかなと思います）
これは配属から半年ほど働いた時点での、自分なりの正直な振り返りです。一意見として取り入れてくださると幸いです！
これから文系からエンジニアを目指す人の助けになれば、それ以上の喜びはありません。
Discussion