1. はじめに
今回は就職活動の選考を通して新しく広がった知見と、これからどうしていこうと考えているかを以下に示す。
1.2 背景
大学院の院試免除もいただき、大学院に進学する予定だったが、家庭の経済的な理由で厳しくなり、急遽、6月中旬から就職活動を行った。1社だけ行きたい企業がまだエントリーを受け付けており、内定をいただけるかわからないが、選考を進んでいる最中である。もし、実力不足でご縁がなかったら、キーエンス財団の奨学金などが申し込めるので、頑張って大学院に進学しようと思っている。今までの経歴を以下に示す。
1.3 経歴
大学1年
大学の授業でPythonを用いた簡単なプログラムを学ぶ。化学など一度理論や構造が確立するとなかなか覆ることのない内容よりも、数年で新しい技術が出て、今までの技術がレガシーになっていくITの常に変化し続けている点に面白みを感じ、専攻を情報系に選択する。
大学2年
C言語やJava、Pythonを授業で使って、メモリ管理、オブジェクト指向、数値計算などを学ぶが、授業をこなしている状態だった（高校までのテスト勉強みたいな感じ）。
大学3年
授業を通して、始めてチーム開発を経験する。アプリを開発する面白さと難しさを知る。これをもっと極めて知りたいと思い、課外活動でしていた社会人バスケットボールチームをやめて、インターンに参加する。インターンではオンプレの企業の研修資料を
大学4年
アプリの運用（インフラ面）について学ぼうと思っていた時に、Googleが主催するハッカソンで Google Cloud を触ることができると知って、GDGoCハッカソン2026に参加する。全く GCP ( Google Cloud Platform )に関する知識がなかったので、新鮮で面白い体験だった。しかし、チームメンバーには迷惑をかけた。
2. 現在地
今まで活発に活動をしてきたものの、授業のアプリ開発やハッカソンなど一定の期間で終わってしまうものが多かった。継続的に活動できる場所（アルバイト雇用のエンジニア）に身を置くため、フロントエンドの学習を行っていた。Udemyの動画教材も終わって、 Vitest・React Testing Library を用いたGHAのCI/CDも終わった。
そんな中就職活動を始めた。（中途半端！！）
HTML・CSS・JavaScript・React・TypeScriptの基礎を学び、これから実践（個人開発）を通じて実力をつけていこうという段階。よって選考のコーディングテストはずたずた。しかし、面接は決まっていたので、現場の方と面接をさせていただく機会を得た。
3. これまで選考を通じて感じたこと
コーディングテストなどを受けて、自分には基礎力が足りないと感じた。（もちろん、6月中旬から就活を始めたので、対策をしていなかったのもあるが、、）そこで、入社までにするべきだと感じたことを以下にまとめた。
基礎力強化ロードマップ（2026年7月 → 2027年3月）【更新版】
目的：CSの基礎知識 と データ構造・アルゴリズムの「実装力」をメインに固め、あわせて React + TypeScript のアプリ開発基礎力をつける。 使用言語：JavaScript / TypeScript（アルゴリズムも React も TS で書く） 背骨：データ構造・アルゴリズムの実装を週次で途切れさせない（複利で効くため最優先）。 学習枠：火・木・土・日（各2h）
3本柱：
【A】データ構造とアルゴリズム（TypeScriptで実装）
【B】CS基礎知識（読書＋FEで体系化）
【C】React + TypeScript アプリ開発
週の回し方（テンプレ）
火：A（アルゴリズム実装／LeetCode・過去問）
木：A（アルゴリズム実装／LeetCode・過去問）
土：B（CS本 or FE）
日：C（React開発）＋ AtCoder ABC 参加（習慣化枠）
7〜8月｜TSの土台＋アルゴリズム習慣化
【A】データ構造・アルゴリズム
TypeScript基礎（型 / ジェネリクス / ユーティリティ型 / tsconfig）
計算量（O記法）を理解
基本データ構造を TS でスクラッチ実装：動的配列 / ハッシュ（Map・Set）/ スタック / キュー / 連結リスト
LeetCode Easy を TS で（配列・文字列・ハッシュ中心）
AtCoder ABC を TS(Node.js) で毎週参加（まず「毎週出る」を固定）
練習ログを1つ用意（解いた問題＋詰まった型を記録）
【B】CS基礎
プログラムはなぜ動くのか（コンピュータの仕組み）
9〜11月｜アルゴリズム実装力の核＋CS体系化
【A】データ構造・アルゴリズム（TSで自力実装できる状態に）
木 / 二分探索木（BST）
グラフ（隣接リスト）＋ BFS / DFS
ヒープ（優先度付きキュー）
二分探索 / 累積和 / しゃくとり法
動的計画法（DP）
貪欲法
LeetCode をトピック別に TS で（NeetCode 150 を目安）
AtCoder ABC 週1継続（A〜C安定 → D射程）
【B】CS基礎（この順で読むと繋がる）
ネットワークはなぜつながるのか
Linuxのしくみ
Webを支える技術
安全なWebアプリケーションの作り方（徳丸本）
基本情報技術者試験(FE) を「締め切り」として受験（10〜11月）→ 合格
SQL / DB（1〜2週集中）
JOIN / インデックス / トランザクション / 正規化
『SQLアンチパターン』で自分の過去クエリを見直し・修正
12〜1月｜React + TypeScript アプリ開発
【C】React 基礎（TSで書く）
中核：コンポーネント / props / state / 条件・リスト描画
フック：useState / useEffect / useRef / useMemo / カスタムフック
TS×React：型付き props・イベント型・API レスポンスの型
ルーティング（React Router）
データフェッチ＋状態管理（TanStack Query など）
フォーム・バリデーション
アプリを1本：設計 → 実装 → デプロイ（Vercel / Firebase）
テスト：Vitest ＋ React Testing Library
CI/CD：GitHub Actions
【A】継続
アルゴリズム 週2〜3問（維持）
2〜3月｜フルスタック統合・仕上げ
フルスタック1本：React(TS) フロント ＋ API（Hono/Express, TS）＋ DB ＋ デプロイ
認証（Firebase Auth など）を実装
既存作品（Tidy / GDGoC）を「設計・アーキテクチャ視点」で言語化
GCP構成（Firestore＝正本 / Cloud Storage＝元データ / Pub/Sub＝処理分離）を「なぜこう分けたか」で説明できる
アルゴリズム維持（週1〜2）
進捗マイルストーン
【7〜8月末】TS基礎OK・ABC習慣化・基本データ構造を自力実装できる
【11月末】主要データ構造/アルゴリズムを TS で実装できる・FE合格・CS本読了・SQL基礎完了
【1月末】React(TS) でアプリを1本デプロイ・テスト/CI導入済み
【3月末】フルスタック1本完成・既存作品を設計視点で語れる
バックログ（余裕があれば／入社前の+α）
Next.js 学習（App Router）
ポートフォリオサイト（Next.js）
テックブログ（Zenn / Qiita で学習アウトプット）
3.2 面接を通じていただいた現場の方からの意見
このような基礎力も大事だし無駄にはならない。また、選考を通じて感じた課題を解決しようとする姿勢は素晴らしいが、目的をしっかり明確にした方が良いという意見をいただいた。具体的には、実際の現場ではアルゴリズムで最適化するより、そもそもアルゴリズムを考えさせない設計をすると言っていた。N+1の問題をインデックスとJOINで潰す、必要なカラムだけ取る、キャッシュ層を置くなど実務でパフォーマンスを決めるのは大半がここで、自前のDP実装が効く場面はまず来ない。また、大量のデータがある前提なので、まずそれに耐えうるスペックを用意するという方法も取る。この貴重な意見を聞いて、目的を「データ構造とアルゴリズムの実装ができる（早いコードを書く）」から計算量を見積もって、AIや自分のコードの遅さの原因を切り分けられることに変えた。また、競プロ的な深追い（DP最適化、複雑なグラフアルゴリズム）は削り、DB設計・API設計・テスト・運用に時間を回すようにしようと感じた。
4. 全体を通じて考えた最終プラン
基礎力強化ロードマップ（2026年7月 → 2027年3月）【v4・入社1年目の先取り】
このロードマップの目的（先に決める）
「----入社時に、1年目の到達目標を先取りした状態で立つ」
到達したい状態＝
与えられた機能を 設計 → 実装 → テスト → リリース まで一人で回せる
レビュー指摘を理解し、自分で改善できる
既存コードを読んで、小〜中規模の改修を安全にできる
学習項目は、この3つに効くかどうかで採否を決める。
使用言語：TypeScript（フロント・バック共通） 学習枠：火・木・土・日（各2h）
方針の転換（面接フィードバックの反映）
データ構造とアルゴリズムの目的を再定義する。 Webの業務システムでは、アルゴリズムで最適化するより「必要なデータだけを取る設計（テーブル設計・インデックス・クエリ）」や「そもそも重い処理を発生させない周辺設計」の方が効く。 → よってDS&Aは 「計算量を見積もり、遅さの原因を切り分けられる」ことを目的に、最低限を確実に。競プロ的な深掘り（複雑DP・高度グラフ）はやらない。 → 浮いた時間を DB設計 / API設計 / テスト / 運用・監視 に振り分ける。
AIには先に自分で書いてから添削・壁打ちさせる（AIの出力を評価できる目利きを養う）。
既存経験（GCP / デプロイ / CI / 認証 / Linux実務）は再学習せず、"なぜそうしたか"を言語化して武器化する。
学習の5本柱（すべて1年目の到達目標に紐づく）
柱
目的（何のために）
1. データ設計・SQL
必要なデータだけを取る設計ができる（＝性能問題の根本を潰す）
2. Web開発の実装力（TS / React / API）
担当領域を業務レベルで実装できる
3. テストと品質担保
「一人で回す」の"テスト"を担保する
4. リリース・運用・監視
「一人で回す」の"リリース"と障害対応の初動
5. チーム開発の作法・言語化
レビュー指摘を理解し、既存コードを安全に触れる
補助：計算量とデータ構造の基礎（柱1・2の判断材料として最低限）
週の回し方（テンプレ）
火：実装（TS / React / API）
木：実装 or データ設計・SQL
土：CS基礎（読書 / FE）
日：個人開発を進める（テスト・CI・デプロイ込み）
毎日5分：学んだこと・詰まったことを Markdownで日報（要件定義力の訓練）
7〜8月｜土台：TypeScript ＋ 計算量 ＋ Webの仕組み
柱2（実装）
TypeScript基礎（型 / ジェネリクス / ユーティリティ型 / tsconfig / strict）
既存の自作アプリを TS でリプレイス（型を後付けする経験）
補助（DS&A：目的＝計算量の目利き）
計算量（O記法）を理解し、口頭で説明できる
基本データ構造を TS で実装：動的配列 / Map・Set（ハッシュ）/ スタック / キュー
探索：線形探索 / 二分探索、ソートの計算量の違い
「配列の線形探索 vs Map の O(1) 参照」を自分のコードで比較・体感する
LeetCode Easy を TS で30問程度（配列・文字列・ハッシュのみ）※ここで打ち止め、深追いしない
柱1（Webの仕組み）
Webの仕組み：URL入力 → 画面表示までを全部説明できる（DNS / HTTP / ステータスコード）
Chrome DevTools でリクエスト・レスポンスを実際に確認する
CS本①：プログラムはなぜ動くのか
柱5（言語化）
日報習慣スタート
AI運用ルールを決める（自分で書く → 添削させる → 提案の理由を説明させる）
9〜10月｜柱1：データ設計とSQL【最重点】
面接で指摘された「本丸」。ここが性能と設計の質を決める。
SQL基礎：SELECT / JOIN / GROUP BY / サブクエリ
テーブル設計：正規化（〜第3）／リレーション／主キー・外部キー
インデックス：なぜ速くなるか、いつ効かないかを説明できる
トランザクションと分離レベル
N+1問題を自分のアプリで再現 → 検出 → 解消する
EXPLAIN で実行計画を読む（遅いクエリの原因を切り分ける）
「必要なカラム・行だけ取る」クエリに書き換える練習
『SQLアンチパターン』で自分の過去設計をレビュー
AIが出したテーブル設計の妥当性を、自分で判断・指摘できる
並行：CS基礎＋資格
ネットワークはなぜつながるのか
Linuxのしくみ
基本情報技術者試験(FE) を「締め切り」として受験 → 合格
11〜12月｜柱2：React(TS) ＋ バックエンド ＋ API設計
フロント（React + TypeScript）
型付き props / イベント型 / API レスポンスの型定義
フック：useState / useEffect / useMemo / カスタムフック
ルーティング（React Router）／データフェッチ（TanStack Query）／フォーム
状態管理の設計（どこに状態を置くか、を説明できる）
バックエンド（TypeScript で統一：Hono or Express）
CRUD を1本実装（層の分け方＝責務分離を説明できる）
RESTful API 設計：リソース設計 / HTTPメソッドの使い分け / ステータスコード
認証と認可を自力実装（違いを言葉で説明できる）
徳丸本（安全なWebアプリケーションの作り方）→ XSS / CSRF / SQLi を自分のアプリで再現・修正
柱1（設計を先に書く）
実装前に ER図とAPI仕様を先に書く（＝要件定義の訓練）
1〜3月｜柱3・4・5：一人で「設計→実装→テスト→リリース」を回す
仕上げ課題：フルスタックアプリを1本、業務と同じ流れで作る
柱3（テストと品質担保）
テストケースを自分で言語化してから書く（AIに書かせる前に）
単体テスト（Vitest）／ React Testing Library
結合テスト（APIとDBを通した検証）
カバレッジではなく「何を確かめたいか」で設計する
柱4（リリース・運用・監視・障害対応）
Docker：開発環境を1から Dockerfile / compose で構築し、"なぜ使うか"を説明できる
CI/CD：GitHub Actions で テスト → ビルド → デプロイを自動化
デプロイして公開する（Cloud Run など。GCP経験を活かす）
ログ設計：何を、どのレベルで出すか
監視・エラー検知：エラー発生時に検知し、ログから原因を追える状態にする
意図的に障害を起こし、切り分け → 原因特定 → 恒久対策を一周する（障害対応の初動練習）
柱5（チーム開発の作法）
一人開発でも必ずブランチを切り、PRを出してマージする
コンフリクトを自力で解消できる
PRに「背景 / 変更内容 / 確認方法」を書く習慣
セルフコードレビュー：自分のPRをレビュー観点で見直す（AIをレビュアー役に）
既存コードを読む訓練：OSSか自作の古いコードを読み、小さな改修をテスト付きで入れる
チケット管理（GitHub Issues で機能を分割して進める）
事業ドメインの理解（入社準備）
----の主要プロダクトと、HR / 就活メディア領域のビジネスモデルを整理
公開されている技術ブログ・技術スタックを調べ、使われている技術の"なぜ"を推測する
既存作品の言語化
Tidy / GDGoC を「設計・アーキテクチャ視点」で語れるようにする
GCP構成（Firestore＝正本 / Cloud Storage＝元データ / Pub/Sub＝処理分離）を「なぜ」で説明
当時の技術選定を、今の知識で再評価する（何を変えるか）
進捗マイルストーン
【8月末】TSで書ける・計算量を説明できる・Webの仕組みを一通り説明できる
【10月末】テーブル設計とインデックスの"なぜ"を説明でき、N+1を自力で解消できる／FE合格
【12月末】React(TS)＋APIでCRUDを実装し、ER図とAPI仕様を先に書ける
【3月末】フルスタック1本を、設計→実装→テスト→リリース→監視まで一人で回せた
【3月末】既存コードを読んで安全に改修できる／PRとレビュー観点を語れる
やらないこと（意図的に切る）
競技プログラミングのレート上げ（AtCoder常時参戦）
複雑DP・高度なグラフアルゴリズムの深掘り
新しいフレームワークの横展開（Next.js等はバックログへ）
理由：1年目の到達目標に直結しないため。計算量の目利きは確保しつつ、時間は設計・品質・運用に回す。
バックログ（余裕があれば）
Next.js（App Router）
学習アウトプットを Zenn / Qiita に記事化
ポートフォリオサイト
入社後キャリアロードマップ【v2】
フルスタックエンジニア → アーキテクト / システムデザイン → （その先に）プロダクトへの意思決定
ゴールの再定義
プロダクトに対して アーキテクチャ設計・ソフトウェアデザイン ができるようになり、 その上でプロダクトに対する意思決定ができる人材になる。
進み方：技術的な意思決定の責任範囲を段階的に広げる。 実装 → 機能設計 → システム設計 → プロダクト全体の技術意思決定
前提：2027年4月入社を想定。配属で順序は変わるため、各期の「できるレベル」を軸に読み替える。
全体像
期間
ロール
意思決定の範囲
1年目
自走できる開発者
与えられた機能の実装方法
2〜3年目
フルスタックエンジニア
機能の設計・技術の使い方
4〜6年目
アーキテクト / システムデザイン
システム全体の構造・技術選定
その先
プロダクトへの意思決定（PdM/テックリード等）
何を作るか・なぜ作るか
1年目（2027.4〜2028.3）｜自走できる新人
※入社前の基礎力強化ロードマップで先取り済みの状態で入る想定。実務で"本物"にする1年。
学ぶこと
チーム開発の実務（Git運用 / PR / コードレビュー / チケット管理）
担当領域（フロント or バック）の実装を業務レベルで
実務のテスト（単体・結合）と品質担保
リリース・運用・監視の初歩、障害対応の初動
社内の技術スタックと事業ドメイン（HR / 就活メディア）の理解
できるレベル
与えられた機能を 設計 → 実装 → テスト → リリース まで一人で回せる
レビュー指摘を理解し、自分で改善できる
既存コードを読んで、小〜中規模の改修を安全にできる
2〜3年目（2028.4〜2030.3）｜フルスタックエンジニア
「両方書ける」ではなく「両方の制約を理解して設計できる」を目指す。
学ぶこと
もう一方の領域（フロント担当ならバック、逆も）
データモデリング / DB設計を業務規模で（性能・整合性・拡張性）
API設計・認証認可・パフォーマンス改善（計測 → 特定 → 改善）
インフラ実務（CI/CD・クラウド運用・監視・IaC）※GCP経験を実務レベルへ
非機能要件（セキュリティ / 可用性 / コスト / 運用性）
レガシーコードとの向き合い方（リファクタリング・移行）
できるレベル
フロント・バック両方で中規模機能を設計から任される
障害対応で、切り分け〜恒久対策まで主体的に関与できる
「なぜこの設計にしたか」をトレードオフで説明できる
設計レビューで、他人の設計に指摘ができる
4〜6年目（2030.4〜2033.3）｜アーキテクト / システムデザイン
ここが今の第一目標。「技術で何を選び、何を捨てるか」に責任を持つ。
学ぶこと
ソフトウェアデザイン
設計原則・設計パターン（凝集度と結合度、責務分離）
ドメイン駆動設計（DDD）／モデリング
リファクタリングと進化的設計
システムアーキテクチャ
システム設計（可用性 / スケーラビリティ / 一貫性のトレードオフ）
モノリス vs マイクロサービス、境界の引き方
データ基盤・非同期処理・イベント駆動（※GDGoCのPub/Sub経験の延長線）
移行戦略（動いているものを止めずに変える）
技術選定と組織
技術選定を「事業 × コスト × チームの力量 × 運用負荷」で判断する
ADR（設計判断の記録）を書き、判断の根拠を残す
横断的な設計レビュー / 技術標準の整備
メンタリング・技術的な合意形成
できるレベル
システム全体のアーキテクチャを設計し、技術選定の根拠を説明・防衛できる
非機能要件から逆算して構造を決められる
「作らない」「捨てる」判断ができる
他チーム・非エンジニアに設計意図を説明し、合意を取れる
その先（6年目〜）｜プロダクトに対する意思決定へ
アーキテクトとして「どう作るか」に責任を持った上で、「何を、なぜ作るか」へ範囲を広げる。 ロール名（PdM / テックリード / エンジニアリングマネージャ）は組織によるので、責務で捉える。
学ぶこと
要件定義・ユーザーヒアリング・課題の言語化
※「現場に足を運び、人と直接対話して課題の本質を掴む」あなたの実行力が最も活きる領域
プロダクト指標（KPI）と技術投資の接続
優先順位付け・ステークホルダー調整・ロードマップ策定
新規開発の進め方（企画 → PoC → 開発 → グロース）
できるレベル
課題起点で、技術的に実現可能な解を描ける
技術的負債と事業スピードのトレードオフを経営レベルで説明できる
新規プロダクトを企画〜技術選定〜体制まで描ける
全期間で継続する土台
設計判断を必ず言語化して残す（ADR / 日報 / 記事）← 1年目からの日報習慣の延長
CS基礎の維持（性能・分散・データベース）
アウトプット（Zenn / Qiita・登壇・OSS）
事業ドメイン（HR領域）の解像度を上げ続ける
この道が自分に合っている理由（軸の確認）
アーキテクト志向の根拠：Tidy（Tauri/Rust の技術選定理由）や GDGoC（責務分離したGCP構成）で、すでに「なぜこの構成か」を設計意図から語れている。適性はここに出ている。
現場理解：空き家みっけでの「課題ヒアリング → IT で解決」の実践は、要件定義そのもの。
希少性：アーキテクチャで語れる × 現場から課題を掴める、の両輪を持つエンジニアは希少。