文系から未経験でエンジニアへ。SaaSスタートアップ長期インターンに挑戦した理由

文系から未経験でエンジニアへ。SaaSスタートアップ長期インターンに挑戦した理由

takuma

今回は、文系学部からエンジニアの道へ挑戦し、現在SaaS系スタートアップで長期インターンをされているユイさんにお話を伺います。ユイさん、本日はよろしくお願いします！

ユイさん

ユイです、よろしくお願いします！私の経験が、同じように文系からエンジニアを目指す方の参考になれば嬉しいです。

takuma

ありがとうございます。早速ですが、プロフィールを拝見すると、もともとは金融やコンサル業界を目指していたとか。そこから、なぜ畑違いのエンジニアという道を選んだのですか？

ユイさん

はい。周りの友人と同じようにサマーインターンの選考を受けていたんですが、どうしても「自分が本当にやりたいことなのか」という疑問が拭えなくて…。そんな時に、あるSaaS企業の創業ストーリーを記事で読んだのが、大きなきっかけになりました。

金融・コンサル業界を目指していた私が感じた「違和感」

大学2年生の夏、私の周りの友人たちは、いわゆる「就活エリート」を目指して外資系コンサルや投資銀行のサマーインターンシップに向けた準備を始めていました。
私もその流れに乗り、SPIの対策本を読み、グループディスカッションの練習会に参加する毎日でした。
しかし、対策を進めれば進めるほど、「自分は本当に、企業の経営課題を解決したり、M&Aのアドバイスをしたりする仕事に情熱を注げるのだろうか？」という違和感が日に日に大きくなっていきました。

もちろん、それらの仕事が社会に与えるインパクトの大きさは理解していました。
しかし、私自身の興味の根源は、もっと身近で、もっと直接的な「ものづくり」にあるのではないかと感じ始めたのです。
経済学部の授業で学んだマクロ経済の理論よりも、ゼミで統計ソフトを使ってデータを分析し、小さな発見をする方が何倍も楽しかった。
その「楽しい」という純粋な気持ちに、蓋をしてはいけないと思ったのです。

そんなモヤモヤを抱えていたある日、Webメディアでとある国内SaaS企業の特集記事を読みました。
たった数人のチームが、自分たちの感じた課題を解決するためにプロダクトを開発し、それが今や何万社もの企業に使われているというストーリー。
それに衝撃を受けると同時に、「これだ。私も、自分の手で課題を解決できるプロダクトを作りたい」と強く感じました。
その瞬間が、私のキャリアの方向性が180度変わった瞬間でした。

独学でプログラミングを始めたきっかけと、最初の壁

エンジニアになろうと決意したものの、当時の私は完全な未経験者。
大学のPCスキルに関する授業で少しWordやExcelを触ったことがある程度で、プログラミングの知識は皆無でした。
そこで、まずは定番と言われる学習サイト「Progate」に登録し、HTML/CSSのコースから始めることに。
初めて自分の書いたコードがブラウザ上で文字や色として表示された時の感動は、今でも忘れられません。
「本当に作れた…！」と、自分の部屋で一人、声に出して喜んだのを覚えています。

Progateを一通り終えた後は、より実践的なスキルを求めて「Udemy」の動画講座に投資しました。
特に、JavaScriptの基礎からES6のモダンな記法までを網羅した講座は、私の学習の基礎を築いてくれました。
しかし、ここで最初の大きな壁にぶつかります。
それは、「チュートリアルは理解できるのに、いざ自分で何かを作ろうとすると、一行もコードが書けない」という、多くの初学者が経験する壁でした。

動画の通りにコードを写せば動く。でも、なぜそう動くのか、その「なぜ」の部分が全く理解できていなかったのです。
エラーが出ればパニックになり、解決方法をGoogleで検索しても、出てくるのは専門用語ばかりで理解できない。
チュートリアルをなぞるだけの「作業」になってしまっている自分に気づき、深い無力感を覚えました。
この時期が、精神的には一番辛かったかもしれません。

情報系学生との差を痛感。それでもエンジニアを目指した理由

学習を進める中で、もう一つの壁として立ちはだかったのが、情報系学部に所属する学生たちとの圧倒的な知識量の差でした。
SNSで「#駆け出しエンジニアと繋がりたい」といったハッシュタグを覗けば、同年代の学生が当たり前のようにGitHubでコードを公開し、技術記事を書き、個人開発のアプリをリリースしている。
彼らが話す「状態管理」や「コンポーネント指向」、「API」といった言葉の意味すら、私には理解できませんでした。

大学の数少ない情報系の友人に相談しても、「え、まだそんなことやってるの？」という反応をされるのが怖くて、なかなか踏み込んだ質問ができませんでした。
彼らにとっての「常識」が、私にとっては「専門知識」。この埋めがたい差を前に、「今から始めても、彼らに追いつくのは不可能なのではないか」と何度も心が折れそうになりました。

それでも私がエンジニアの道を諦めなかったのは、「非エンジニアの視点を持つ自分だからこそ、作れるプロダクトがあるかもしれない」という小さな希望があったからです。
経済学を学んだからこそわかるユーザーのインサイトや、ビジネスの視点。
これを技術と掛け合わせることができれば、情報系学生にはない、自分だけの価値を発揮できるのではないか。
そう信じることで、なんとか学習を続けるモチベーションを保っていました。
「知らない」ことは弱みではなく、むしろ「伸びしろ」なのだと、自分に言い聞かせていました。

ポートフォリオなし！独学の文系学生が技術面接を突破した具体的な戦略

takuma

なるほど…。その「違和感」や「差」を感じながらも、自分の強みを見出して学習を続けたのがすごいですね。とはいえ、スキルが追いついていない中でのインターン探しは、かなり大変だったんじゃないですか？

ユイさん

おっしゃる通り、本当に大変でした。特に、見せられるようなポートフォリオが何もない状態だったので、書類選考の段階で苦労しました。でも、その中で自分なりに工夫した点もいくつかあります。

takuma

ポートフォリオなしでの挑戦…！それはぜひ詳しくお聞きしたいです。スキルをアピールできない分、何を武器に戦ったのでしょうか？

ユイさん

はい。私が意識したのは、完成された「技術力」ではなく、現在進行形の「学習プロセス」を見せることでした。具体的には、GitHubの活用方法と、面接でのストーリーテリングを工夫しました。

「技術力」ではなく「学習プロセス」を見せるためのGitHub活用術

ポートフォリオがない私が、唯一自分の学習意欲を客観的に示せる場所がGitHubでした。
しかし、ただアカウントがあるだけでは意味がありません。そこで私は、自分のGitHubを「学習記録のポートフォリオ」と位置づけ、戦略的に活用することにしました。
まず取り組んだのは、Udemyの講座で学んだ内容を、ただ写経して終わりにするのではなく、自分なりにコメントを加えたり、小さな機能を追加したりして、毎日コミットを続けることでした。
コミットメッセージも、「Chapter3完了」のような雑なものではなく、「`feat: Add form validation logic`」のように、実際の開発現場で使われるような規約を意識して書くようにしました。

次に、リポジトリのREADME.mdファイルを丁寧に書くことを心がけました。
そこには、このリポジトリが何の学習を目的としているのか、どのUdemy講座を参考にしているのか（リンクも貼る）、そして、この学習を通じて次に何を学びたいと考えているのか、といった「学習の設計図」を記述しました。
これにより、面接官が私のリポジトリを見たときに、単なるコードの羅列ではなく、「この学生は、目的意識を持って計画的に学習を進めているな」と感じてもらえるように工夫したのです。

結果的に、いくつかの企業の書類選考で、このGitHubのプロフィールが評価されました。
面接でも「READMEがしっかり書かれていて、学習意欲が伝わりました」と言っていただける場面があり、完成品がなくても、学習過程そのものが評価の対象になることを実感しました。
これは、ポートフォリオがない初学者にとって、非常に有効な戦略だと思います。

面接で話した「自分だけのストーリー」の作り方

面接で必ず聞かれる「志望動機」や「自己PR」。
ここで、多くの学生がやってしまいがちなのが、どこかで聞いたようなテンプレート的な回答です。
しかし、私には誇れるような技術力も実績もありません。だからこそ、自分にしか語れない「オリジナルのストーリー」で勝負するしかないと考えました。
私のストーリーの軸は、「なぜ、文系の私が、わざわざエンジニアを目指すのか？」という問いに、自分なりの答えを出すことでした。

私が面接で話したのは、経済学部のゼミでの経験です。
統計データを用いて地域経済の課題を分析するという研究をしていたのですが、その中で、複雑なデータもグラフや図で可視化すると、多くの人に問題の本質が伝わるという体験をしました。
この経験から、「難しい情報を、テクノロジーの力でわかりやすく翻訳し、人の行動を変えるきっかけを作ること」に強いやりがいを感じるようになった、と話したのです。

そして、「フロントエンドエンジニアは、まさにその『翻訳者』の役割を担える仕事だと考えています。経済学で培った『物事の本質を捉える力』と、これから身につける技術力を掛け合わせ、ユーザーにとって本当に価値のあるUI/UXを届けたいです」と、自分の過去の経験と、未来の目標を結びつけて語ることを意識しました。
これにより、単なる「エンジニアになりたい学生」ではなく、「ユイさんという個人が、なぜエンジニアになりたいのか」という、説得力のあるストーリーを伝えることができたと感じています。

「経済学部の視点」を武器に変えた逆質問の具体例

面接の終盤にある「逆質問」の時間は、多くの学生が「特にありません」と答えてしまうか、ありきたりな質問をしてしまいがちです。
しかし、私はここを「自分をアピールする最後のチャンス」と捉え、文系学生ならではの質問をぶつけることを意識しました。
技術的な質問では情報系の学生に敵わない。ならば、私はビジネスやプロダクトの視点で質問しようと考えたのです。

私が実際に聞いた質問の一つが、「御社のプロダクトは、現在どのようなKPIを追っていらっしゃいますか？また、エンジニアチームは、そのKPI達成のために、どのような技術的意思決定をされているのでしょうか？」というものです。
この質問には、いくつかの意図を込めました。一つは、私が単にコードを書くだけでなく、プロダクトのビジネス的な成功にも関心があることを示すこと。もう一つは、エンジニアがビジネス指標をどれだけ意識して開発しているのか、その企業文化を知ることでした。

この質問に対して、面接官のエンジニアの方は「お、面白い質問ですね」と少し驚いた様子で、ARR（年間経常収益）やチャーンレート（解約率）といった具体的な指標を挙げながら、それを改善するために現在どんな機能開発に注力しているかを詳しく話してくれました。
この逆質問を通じて、「この学生は、ただの作業者ではなく、プロダクトを一緒に成長させてくれる仲間になり得るかもしれない」という印象を与えることができたのではないかと思います。

SaaS開発の最前線！Next.jsとTypeScriptで挑むリアルな開発現場

takuma

すごい…！スキルがないことを逆手にとって、学習プロセスや独自の視点をアピールしたわけですね。非常に戦略的です。その結果、見事に内定を掴み、現在インターンとして働いているわけですが、実際の現場はどうですか？

ユイさん

正直、入社してからの毎日が勉強と挑戦の連続です。想像以上に学ぶことが多くて、毎日必死にキャッチアップしています。でも、その分すごく充実していますね。

takuma

リアルな声、ありがとうございます！具体的に、どんな業務を担当していて、どんな時に「壁」を感じましたか？

ユイさん

はい。最初は既存コンポーネントの小さな修正から始まり、最近は新規機能のUI実装も任せてもらえるようになりました。特に、初めてコードレビューを受けた時と、TypeScriptの型定義には本当に苦労しました…。

入社初日に圧倒された「コンポーネント設計」とコードレビューの洗礼

インターン初日、メンターの社員さんから「まずはこのボタンコンポーネントの見た目を少し修正するタスクからやってみようか」と、最初のIssue（課題）がアサインされました。
ProgateでHTML/CSSは学んでいたので、「ボタン一つなら簡単だろう」と、正直少し甘く見ていました。
しかし、ローカルに開発環境を構築し、指定されたファイルを開いて、私は愕然としました。

そこにあったのは、私の知っているような単純なHTMLではありませんでした。
`variants`や`size`といったpropsを受け取り、動的にスタイルが変わる、非常に再利用性の高いReactコンポーネント。
そして、そのスタイルはTailwind CSSのユーティリティクラスで記述されていました。
「コンポーネント指向」という概念を、頭ではなく体で理解した瞬間でした。
ただCSSプロパティを当てるのではなく、「このコンポーネントは、将来どんな場面で、どのように再利用される可能性があるか」までを考えて設計されていることに、プロの現場のレベルの高さを痛感しました。

なんとか修正を終え、初めてのプルリクエスト（PR）を提出。
数時間後、GitHubから通知が届き、見てみると、私のコードには15件以上のレビューコメントがついていました。
「この変数名は、より意図が明確な名前にしましょう」「このロジックは、もっとシンプルに書けますね」「このコンポーネントの責務ではない処理が含まれています」…。
一つ一つは丁寧で論理的な指摘でしたが、自分の書いたコードがほとんど全否定されたような感覚に陥り、正直かなりへこみました。これが、プロのコードレビューの洗礼でした。

私が任された初めての機能実装と、TypeScriptの型エラーとの戦い

数々のレビューを乗り越え、小さな修正タスクに慣れてきた頃、メンターさんから「次は、設定画面に新しい入力フォームを追加する機能を実装してみよう」と、初めての機能開発を任されました。
それは、ユーザーが特定の通知設定をオン・オフできるトグルスイッチと、関連するテキスト入力フィールドを追加するというタスクでした。
ここで私の前に立ちはだかったのが、**TypeScriptの「型」という巨大な壁**でした。

そのプロジェクトでは、APIから取得するデータや、フォームの状態、コンポーネントのpropsなど、あらゆるものに厳密な型定義がされていました。
私が書いたコードは、動かす前からエディタ上で真っ赤な波線だらけ。
「`string | undefined` 型を `string` 型に割り当てることはできません」といった、当時は意味すら理解できないエラーメッセージに、何度も頭を抱えました。
JavaScriptなら何となくで動いてしまっていた部分が、TypeScriptでは一切許されない。その厳しさに、何度も心が折れそうになりました。

特に苦労したのは、フォームの状態を管理するライブラリ（React Hook Form）と、UIコンポーネントライブラリ（Chakra UIなど）を連携させる部分の型定義です。
ライブラリが提供する型を正しくインポートし、それを自分のコンポーネントのpropsの型と組み合わせる…。
まるで複雑なパズルを解いているような感覚でした。
エラーを一つ解決するのに半日以上かかったこともありましたが、メンターさんに質問したり、公式ドキュメントを翻訳しながら読み解いたりして、なんとか機能を完成させることができました。
この経験を通じて、型の恩恵と、ドキュメントを読むことの重要性を痛感しました。

ビジネスサイドとの連携で活きた「経済学部での学び」

技術的な壁にぶつかる一方で、意外なところで自分の強みを発揮できる場面もありました。
それは、ビジネスサイドのメンバー、特にプロダクトマネージャー（PdM）やマーケターとのコミュニケーションです。
ある日、私が実装した新機能について、PdMから「この機能の利用率を測るために、特定のイベントログを仕込んでほしい」という追加の依頼がありました。

その依頼内容を聞いたとき、私はただ実装するだけでなく、経済学部のゼミで学んだ知識を活かして、「このイベントログは、A/Bテストを想定したものですか？それとも、単純な利用率を見るためのものでしょうか？もしA/Bテストを行うのであれば、統計的に有意な差を出すためには、こちらの指標も一緒に計測した方が良いかもしれません」と提案しました。
私の発言に、PdMの方は少し驚いた様子でしたが、「面白い視点だね！ぜひその方向で検討しよう」と、前向きに議論が発展しました。

また、新しい機能の仕様を決めるミーティングに参加した際も、エンジニアの視点だけでなく、「この機能は、どの顧客セグメントの、どんな課題を解決するものなのか」「その結果、LTV（顧客生涯価値）はどのように変化すると考えられるか」といった、ビジネス的な視点から質問をすることを心がけました。
こうした経験から、文系出身であることは、決してハンデではなく、多様な視点をチームにもたらす「武器」になり得るのだと、確かな手応えを感じることができました。

「文系だからこそ」を強みに。私が目指すこれからのエンジニア像

takuma

技術的な壁と、文系ならではの強み、両方を実体験として感じているわけですね。非常に濃いインターン生活を送っているのが伝わってきます。そんなユイさんが、この先どんなエンジニアを目指しているのか、ぜひ聞かせてください。

ユイさん

はい。このインターン経験を通じて、自分の目指したい方向性が少しずつ見えてきました。それは、ただコードが書けるだけでなく、ビジネスとプロダクトを繋ぐことができるエンジニアです。

takuma

素晴らしいですね！最後に、これからインターンに挑戦しようと考えている、特に文系の後輩たちに向けて、何かアドバイスがあればお願いします。

ユイさん

もちろんです。昔の自分に伝えるつもりで、お話しさせてください。

技術力だけじゃない。ビジネスとプロダクトを繋ぐ架け橋になりたい

このインターンを通じて私が最も強く感じたのは、優れたプロダクトとは、優れた技術だけで作られるわけではない、ということです。
もちろん、堅牢なアーキテクチャや、パフォーマンスの高いコードは不可欠です。
しかし、それと同じくらい、「そもそも、誰の、どんな課題を解決するのか？」というビジネスの根幹を理解することが重要だと痛感しました。

どんなに美しいコードを書いても、それがユーザーの課題解決に繋がっていなければ、それは自己満足に過ぎません。
逆に、ビジネスサイドの要求を鵜呑みにするだけでも、技術的な負債を生み、将来のプロダクトの成長を妨げてしまう可能性があります。
だからこそ私は、技術的な議論も、ビジネス的な議論も、両方の言語を理解し、その間で「翻訳者」の役割を果たせるエンジニアになりたいと考えています。

将来的には、フロントエンドの技術を極めることはもちろん、プロダクトマネジメントの領域にも挑戦してみたいです。
経済学部で学んだ知識と、現場で培った技術力を掛け合わせることで、「ユーザーにとって本当に価値があり、かつ、ビジネス的にも持続可能なプロダクト」を創り出す。
それが、文系出身の私だからこそ目指せる、ユニークなキャリアパスなのではないかと信じています。

これからインターンを目指す「文系の後輩」へ伝えたい3つのこと

もし、昔の私と同じように、文系学部からエンジニアを目指すことに不安を感じている方がいるなら、3つのことを伝えたいです。
一つ目は、「技術力がないことを、過度に恐れないでほしい」ということ。
企業は、あなたの完成されたスキルではなく、学習意欲と伸びしろを見ています。できないことを正直に認め、学ぶ姿勢を見せることが何よりも大切です。

二つ目は、「自分の専門分野を武器にすること」。
経済学部ならビジネスの視点、文学部なら言語化能力や読解力、法学部なら論理的思考力。
あなたがこれまで学んできたことは、必ずどこかで開発の役に立ちます。
「自分は情報系じゃないから…」と卑下するのではなく、「自分は〇〇学部だから、こんな視点を提供できる」と、自信を持ってアピールしてください。

そして三つ目は、「とにかく早く、小さな一歩でいいから行動すること」。
Progateを始める、技術書を1冊買う、気になる企業のミートアップにオンラインで参加する。何でも構いません。
行動することでしか、次の道は見えてきません。
情報収集ばかりで頭でっかちになる前に、まず手を動かしてみてください。その小さな一歩が、1年後のあなたを全く違う場所に連れて行ってくれるはずです。

私の次なる挑戦と、今後の学習ロードマップ

このインターンも、残すところあと数ヶ月となりました。
今後の目標として、まずは現在担当している機能開発を、最後まで責任を持ってやり遂げることが第一です。
具体的には、コンポーネントのテストコード（Jest, React Testing Library）をしっかり書けるようになること、そして、パフォーマンスを意識した実装（不要な再レンダリングの防止など）ができるようになることを目指しています。

インターン終了後は、この経験を元に、個人開発に挑戦したいと考えています。
テーマは、「経済学を学ぶ学生のための、統計データ可視化ツール」です。
これまで学んだNext.jsやTypeScriptの知識を総動員し、企画から設計、開発、リリースまでを一人でやり遂げることで、開発プロセス全体の解像度を上げたいです。
この経験が、就職活動における最大のポートフォリオになると信じています。

長期的には、フロントエンドの知識だけでなく、バックエンド（Node.js, Prisma）やデータベース（PostgreSQL）の知識もキャッチアップし、フルスタックに動けるエンジニアになることが目標です。
道のりは長いですが、このインターンで得た「学び方」を武器に、これからも楽しみながら成長していきたいです。
文系からでも、ここまでやれる。そのことを、私自身のキャリアを通じて証明していきたいと思っています。

インタビュー後記

ユイさん、本日は貴重なお話を本当にありがとうございました。
文系学部からエンジニアの道へ、という大きなキャリアチェンジに込められた強い意志と、それを実現するための具体的な戦略に、私自身も非常に多くの学びと刺激を受けました。

今回お話を伺って、私が最も強く感じたのは、「弱みは、視点を変えれば最強の武器になる」ということです。
情報系学生との知識差に悩みながらも、それを悲観するのではなく、経済学部で培った「ビジネスの視点」という自分だけの付加価値に変えて面接に挑んだユイさんの姿勢は、多くの学生にとって大きな勇気になるのではないでしょうか。

また、ポートフォリオがなくても、日々の学習プロセスそのものを価値として提示するというGitHubの活用術も、非常に実践的で素晴らしいと感じました。
完成品がないからと諦めるのではなく、努力の過程を見せる。この発想の転換こそ、初学者の一歩目を後押しする鍵だと確信しました。

TechRoidでは、まさにユイさんのような「リアルな体験談」を届けたいと常に考えています。
今日のインタビューが、かつての私やユイさんのように、情報不足や先行きの不安に悩むあなたの背中を、少しでも押すことができたなら幸いです。
ユイさん、本当にありがとうございました。今後のご活躍を心から応援しています！