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

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

傳  知輝傳 知輝公開日:2025/08/294分

目次

未経験から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で一緒に挑戦してくれる仲間に出会えるきっかけになれば嬉しいです。