
未経験からUHDエンジニアへ 1ヶ月研修のリアル体験記

目次
未経験からUHDエンジニアへ —— 1ヶ月研修のリアル体験記
この記事でわかること
- 未経験からエンジニアを目指すときの不安と乗り越え方
- UHDの研修で学べること(環境構築〜設計・実装まで)
- 研修を経て感じたUHDの魅力と文化
私はサービス業からエンジニアに転職しました。
スクールで少しPHPを学んだだけで実務経験はゼロ。
それでも、UHDの研修で 環境構築 → 仕事の進め方 → Git → TypeScript → NestJS → 設計〜テスト〜実装 を 1ヶ月で実務の流れに沿って 学び、今は開発案件に入っています。
研修内容
環境構築
所要時間 1時間
まずは開発における"土台づくり"から。
項目 | 実践内容 | 気づき | ツール |
---|---|---|---|
エディタ導入 | Cursor をセットアップ | AI補完やリファクタの助けに | Cursor |
Node.js導入 | Voltaでバージョン固定 | 誰のPCでも同じ動作に | Volta, Node.js |
補足:基礎研修中は外部AI(ChatGPTなど)は原則制限。Cursorはエディタとしてのみ使用。
仕事の進め方
所要時間 3時間
UHDで最も重視しているのは「仕事の進め方」です。
ここでは概念のインプットと「この時はどうするか?」といった例題に答えるアウトプットを行いました。
実践的なアウトプットに関しては研修期間の1ヶ月を通して指導してもらいました。
項目 | 実践内容 | 効果/目的 | ツール |
---|---|---|---|
報連相をする | 報連相のメリット/コツ<br>なぜ報連相をすべきかといった概要説明 | 情報共有・問題解決・トラブルの防止 | Slack |
メモを取る | メモの取り方/取った後にすべきこと | 学びを蓄積し、思考を整理できる | Obsidian |
PDCAサイクルの徹底 | 反省点・翌日の改善アクションを記録 | 学びが残り、翌日につながる | 日報(自社サービス Kizuki) |
時間管理 | スケジュール報告/見積もりの計算 | 遅延の早期検知 | タイマー |
なぜUHDでは「仕事の進め方」を重視しているのか?
エンジニアにとって技術力はもちろん大切ですが、同じくらい重要なのが コミュニケーション能力 です。
チームで開発を進める以上、認識のズレを防ぎ、信頼関係を築けるかどうかが成果に直結します。
その中核にあるのが「報連相」です。
報連相を徹底することで、
- 情報共有
- 問題解決
- トラブル防止
に加えて、信頼関係の構築 につながります。
「そんなの当たり前だ」と思う方もいるかもしれません。実際、私自身も同じように考えていました。
しかし振り返ると「あなたはここができていない」と具体的に指摘された経験はなく、その重要性を深く理解できていませんでした。
エンジニアに限らず、初めての仕事ではスキルや経験がないのは当然です。
そのうえで「この人は信頼できる」と評価されるための土台こそが、当たり前に見える 報連相の徹底 なのです。
実体験からの学び
躓きポイント
- 見積もりが甘く予定遅れ
- 課題理解が不十分で成果物に手戻り
アドバイス
タスクを細分化し、5〜10分刻みで進捗を可視化
「〇〇は△△という認識で合っていますか?」と具体的に確認する
結果として学んだこと
エンジニアとしての技術的なスキルやレベルは劣っていても仕事の進め方を理解し、実践することで"この人はできる人だな"という信頼感を得ることができました。この信頼感は実は技術的なスキルやレベルよりも大事で、プロジェクトを円滑に進める上での土台となることに気づきました。
Git研修
所要時間: 2時間45分
GUIツール Git Fork を使って実務操作を叩き込み。
GitはCLIでも使えますが、GUIならコマンドを覚えなくても直感的に操作できるのがメリットです。
学習項目 | 到達点 | 補足 |
---|---|---|
Git Fork | コミット・ブランチ・差分を可視化 | 履歴を直感的に追える |
基本操作 | push / pull / merge | 失敗時のリカバリ含め練習 |
最新化 | fetch/pull を徹底 | コンフリクトを回避 |
差分確認 | 競合時の手動解決 | ファイル単位で安全に解消 |
躓きポイント
- PR後に別ブランチで作業→元ブランチにレビューが来て修正→また作業ブランチへ…の流れで、修正取り込みを忘れたまま作業続行。
- 結果、同じ修正の二度手間や逆方向の修正、コンフリクト増。
- ブランチは独立スナップショットで自動反映されないという前提理解が浅かったことが原因。
アドバイス
- 不安なら「こうしたいのですが合っていますか?」と早めに相談
- 質問すること自体は恥ずかしいことではなく、何度も指摘される方が信頼獲得につながらないよ。
結果として学んだこと
- SlackやGPTに対して質問の仕方を工夫するようになり、返答の質が以前より向上。
- 自分の理解不足を早期に可視化できるようになり、手戻りやコンフリクトを減らせた。
- 結果的にレビューの効率も上がり、時間の無駄を大幅に減らすことができた
TypeScript基礎
所要時間: 28時間
TypeScriptは、JavaScriptに「型」を加えた言語です。
型をつけると「この変数は数値だけ」「この関数は文字列を返す」とルールを決められるので、間違いを早めに発見できるのが強みです。
UHDではTypeScriptを使った開発に携わることが多いのでこの言語を使用して実装の基礎学習として研修しました。
学習項目 | できるようになったこと | 具体例 |
---|---|---|
基本構文・型 | 関数/クラスに型付け | function add(a:number,b:number):number |
モジュール化 | export/import による分割 | product.ts を main.ts から利用 |
オブジェクト指向基礎 | メソッドで状態管理 | Product.decreaseStock() |
配列/文字列 | 組み込みメソッドで処理 | map/filter/reduce、大文字化 |
例外/分岐 | エラーを投げる・握り分ける | 在庫切れは例外、0除算対応 |
テスト(Jest) | 分岐の棚卸しと境界値 | メール検証:長さ超過/形式不正 |
躓きポイント
- 正常は書けても、異常や境界を漏れなく設計するのに苦戦。
アドバイス
「なぜこのテストが必要か」といった目的を考えてから設計すること。
結果として学んだこと
-
目的を考える習慣は、他の業務にも応用できた。
-
タスク管理においても同様で、例えば「APIテストの自動化」を任された場合、
- 目的が 品質保証 なのか
- 目的が 工数削減 なのか
によって優先度や進め方が変わる。
-
目的を理解してから動くことで、効率的にタスクを進められると実感した。
バックエンド研修(NestJS)
所要時間: 35時間30分
基礎のあとは、NestJSでバックエンドの実装へ。
NestJSは、TypeScriptでバックエンドを構築するフレームワークです。
学習項目 | できるようになったこと | 具体例/キーワード | 関連ツール |
---|---|---|---|
基本構造 | Modules/Controllers/Providers を設計 | レイヤ分離/依存注入 | Nest CLI |
バリデーション/例外 | DTO+Exception Filter で統一 | class-validator/統一エラー | NestJS |
DB連携 | リポジトリ/サービス層の分離 | CRUD・トランザクション | Prisma Studio |
セキュリティ | JWT認証 と 認可(Role) | Guard/Decorator/権限制御 | JWT, Guard |
テスト | ユニットテストの基本 | 依存の分離・ケース設計 | Jest |
実演課題 | ユーザー管理/商品DB統合/認証・認可/バッチ処理 | 実務を意識した一連の実装体験 | node-cron |
動作確認 | エンドポイント検証 | リクエスト/レスポンス確認 | Insomnia |
躓いたポイント
- 異常系テストを分ける設計に再び苦戦。
アドバイス
品質を保つ上で必要不可欠な要素なので、過去のレクチャーを見返したり、GPTツールでの質問履歴を振り返ったりして知識を定着させることを意識しよう。
結果として学んだこと
- 振り返りの重要性
一度学んだ内容は時間が経つと忘れてしまうため、過去のレクチャーや質問履歴を繰り返し見直すことで知識を定着させられる。 - ツール活用の継続性
GPTなどのツールを活用して質問・回答の履歴を確認することで、理解不足の部分を補強でき、同じミスを繰り返さないようにできる。 - 品質維持の習慣化
「学びを振り返り定着させる」こと自体が、品質を安定して保つための仕組みになり、結果的に効率的な業務進行や成果物の精度向上につながる。
現場研修(LMS開発)
所要時間: 57時間15分
配属が設計フェーズからと決まっていたため、その流れに合わせて研修してもらいました。
題材は LSM(講師・生徒・保護者が使う学習支援)。
実際のプロジェクトの流れである要件定義 → 基本設計 → 詳細設計 → テスト設計 → 実装(Go) を通しでやりました。
現場研修 成果物マップ
フェーズ | 成果物 | 主な内容 | 使用ツール/形式 |
---|---|---|---|
要件定義 | 要件概要・機能一覧 | 役割/権限・ユースケース整理 | Markdown(Obsidian) |
基本設計 | 画面項目定義・ER図 | 入出力項目・関連・制約 | Markdown + Mermaid |
詳細設計 | API定義書 | エンドポイント/DTO/例外 | Markdown |
テスト設計 | パターン表・シナリオ | 正常/異常/境界・手順書 | Markdown |
実装 | API実装 | Go/NestJS、JWT/Guard | エディタ + Insomnia |
成果物
- 要件定義:要件概要/機能一覧
- 基本設計:画面項目定義・ER図
- 詳細設計:API定義書
- テスト設計:パターン表・シナリオフロー
- 実装:定義書通りにGoでAPI開発、Insomniaで検証
作成したAPIの種類
- 授業登録
- 授業更新
- 小テスト一覧取得
- 成績詳細取得
授業更新の場合
cmd/app/main.go
e.PUT("/courses/:course_id", courseHandler.UpdateCourseHandler)
internal/handlers/course_handler.go
func (c CourseHandler) UpdateCourseHandler(ctx echo.Context) error
internal/services/course_service.go
func (s CourseService) UpdateCourse(courseID int, course models.Course) error
internal/services/course_service.go
func (r CourseRepository) UpdateCourse(courseID int, course models.Course) error
躓きポイント
-
リレーション設定のあいまいさ
最初の段階で「どのテーブルにリレーションを持たせるか」を明確に決めきれなかったため、後から冗長な構造を生んでしまった。例えばtestsとanswers、gradesの関係で、成績をテストに直接紐づけるのか、それともanswerを経由させるのかを曖昧にしてしまった結果設計が複雑化。
結局「成績テーブルに必要な情報が足りない」「解答テーブルだけでは点数を計算できない」といった不足が発覚し、テーブルの追加・修正が必要に。
-
必要データの洗い出し不足
当初は「userID」と「解答内容」だけで十分だと考えていましたが、採点や結果表示を想定すると「問題ID」「正誤判定」なども必要に。実装を進める中で不足に気づき、テーブル構造を修正せざるを得なかったため、余計な工数が発生。
アドバイス
最初はどうしてもうまくいかないもの。大事なのはその時に「なぜ躓いたのか」をしっかりメモに残しておき、経験を重ねる中で前回の反省や知見を次にどう活かすかを考えること。
結果として学んだこと
- 躓きを記録し、改善に活かす習慣が設計の精度を高める。
- 設計の精度が上がることで、開発全体のスピード感を担保できるようになる。
AIツール利用方針
"AIに強い会社なのに、なぜ制限しているのか?"の答えです。
フェーズ | 利用方針 | 補足/ねらい |
---|---|---|
基礎編〜バックエンド研修終了まで | ChatGPTなどの外部AIは原則制限/Cursorはエディタとして可 | まずは文法・設計・テストの基礎体力を自分の手で。AIの出力を評価できる"物差し"を育てるため。 |
現場研修以降 | 制限を緩和して積極活用(ただし問題文の丸コピーは禁止) | 目的・前提・制約を伝え、AIは補助輪として活用。要約・設計比較・テスト観点出し・エラー言語化などで生産性と理解を同時に底上げ。 |
AIツールの使い方(OK例)
- 仕様・エラーログの不明語の確認、要約
- リファクタの方向性検討、正規表現や型定義の疑問解消
NG・注意
- 問題文の丸コピー禁止
結論:AIを活かすには、まず自分の理解が必要。
"比較と検証の相棒"として使うと速さと品質が両立し、より良いものを生み出せる。
研修後に感じたUHDの魅力
- プロダクト開発に集中できる(派遣・請負なし)
- 上流から関われる(要件定義・設計にも参加)
- メリハリある文化(雑談と集中の切り替えが上手い)
まとめ
未経験からでも、基礎を固める → 進め方を学ぶ → 小さく作って検証する → 設計から実装まで体験する。
この流れを1ヶ月で経験できたことが、私にとって大きな財産になりました。
特に「仕事の進め方」を徹底的に学んだことは、技術以上に信頼を得る力につながり、今の現場でも大きく役立っています。
UHDには、
- 信頼される仕事の進め方を身につけられる
- すぐ聞けて、すぐ返ってくる環境がある
- 個人に合わせた柔軟な学び方・成長支援がある
- 学んだことをすぐ試せる文化がある
そんな環境が整っています。
当たり前を徹底して積み上げる。
それが未経験から技術力だけでなく真のプロフェッショナルなエンジニアとして成長する最短の道だと実感しました。
この記事が、エンジニアを目指す方にとっての一歩のヒントになり、そしてUHDで一緒に挑戦してくれる仲間に出会えるきっかけになれば嬉しいです。