研修の概要
本記事ではディップの26年新卒の新卒研修プログラムをご紹介します！ディップでは新卒研修として2週間のブートキャンプ＋OJTという形のプログラムを実施しました！今回はその設計思想と内容、そしてこの研修を通じて何が身につくのかを紹介します。
※掲載可能な講義資料のみ掲載しています。
なぜこの研修をするのか
入社前に内定者インターンを開催し、基礎を固め入社した26年新卒。インターンを経て、すでに実務に近い技術スタックを持つメンバーが、その力をチームの現場で使える形に整えることが研修の目的です。
※内定者インターンは任意のため、欠席でもキャッチアップができる仕組みを作っています。
【26年新卒の動き】
- 10/1~2/28：入社前に内定者インターンを実施し基礎を身につける
- 4/1：入社
- 4/1~4/8：社会人基礎などを学ぶディップの全体研修
- 4/8~14/13：企画・開発・データサイエンティスト・デザイナーなどの専門職で『バイトル』や『スポットバイトル』などのサービス基礎、人材業界について学ぶ研修
- 4/14~4/24：開発本部での技術研修
- 5/1~：配属
インターン期間3ヶ月での成長とさらに伸ばしたい部分はこちら。
「配属先でFirst Issueを即切れる」状態を目指す
この研修のゴールは「入社2週間後に、配属先チームのコードに触れてPRを出せる状態になっていること」。
そのために必要な共通言語と実践経験を、濃縮した2週間で提供します。
研修の全体構成
基本的には午前中に座学でインプット、その後はエンジニア社員がそれぞれつきながらハンズオンで実践という形になっています。
1日の終わりには皆で難しかったこと、できるようになったことなどを振り返り次のアクションに活かします。
Week 1：ブートキャンプ
Day 1：ディップのシステム全体像を知る
ディップでは顧客の採用課題・募集ニーズに合わせて、従来の「掲載課金」に加え「CPC（Cost per click）型」を本格導入予定です。初日はディップのシステムがCPCをどう実現していくかを技術視点で理解し、配属先の先輩と技術の話が成立する共通言語を入れることがゴールです。
午後にはOpenAPI演習（120分）として、Swagger UIを使った仕様の書き方を実際に手を動かしながら学びます。
【CPC×システム全体像】
- 課金種別説明＋ CPCがシステム上どう実装されているか
- ディップの主要システム群：『バイトル』『はたらこ』等の技術的な関係性
- CPCの計測・課金がどのシステム間をどう流れるか（データフロー図）
- 各システムの技術スタック概要
【ディップで使っているAWSサービス + インフラ構成】
- ディップが利用しているAWSサービス一覧と用途（EC2/ECS/Lambda/S3/RDS/CloudFront/SQS/EventBridge等）
- バイトルリニューアル基盤のインフラ構成図説明
- ステージング/本番/開発環境の分離と接続方法
- SSMで接続を試してみる
【技術方針 + アーキテクチャ詳細】
- SoE/SoR分離の思想と実装上の影響（なぜ分けるのか、分けないと何が起きるのか）
- OpenAPI + REST統一の背景と実際の仕様書を見る
- DDD入門（ユビキタス言語、境界づけられたコンテキストの考え方）
- 各チームの担当領域と技術スタックの紹介
【ハンズオン：API仕様を読む】
- swagger.yaml / openapi.yaml を実際に読む
- Swagger UIでAPIを叩いてみる（ステージング環境）
【OpenAPI演習】
- 簡単なAPI仕様をOpenAPIで書いてみる演習
- 書いた仕様をSwagger UIで表示して動作確認
- わからなかったことの共有や振り返り
目指す姿：ディップのCPC実装とシステム全体像を自分の言葉で説明できる
CPC課金モデルへの挑戦はこれまでのビジネスの根幹を覆す施策になるので社内でのスタートラインは新卒も含めた全社員同じ立ち位置になります。新卒でもこの領域でバリューを発揮できると社内でもスターになれる領域です。
新卒の声
・SoRとかSoEとかがまだ難しい！
・実際に開発の現場で活かせる内容をどんどん学べるので楽しい。
・CPC が私たちの顧客企業様にとってなぜ必要なのか、そしてAND条件を極限まで増やす戦略が「高効率な多売チャンス」を生み出す理由についてわかりました。
Day 2：Docker ＋ ローカル開発環境構築
docker-compose up で配属先の開発環境が立ち上がる。コンテナが何を解決するかを説明できる——この状態を目指します。24年新卒のインフラエンジニアが講師を担当し、実際の配属先に近い環境を使ったハンズオンを実施します。
【座学：コンテナ基礎】
- コンテナとは何か（VMとの違い、なぜ開発で使うのか）
- Dockerの基本概念（Image, Container, Volume, Network）
- Dockerfileの読み方（配属先の実際のDockerfileを使う）
【ライブデモ + compose.yaml読解】
- compose.yamlの読み方（ 実際のcomposeファイルを使用）
- 「docker compose up → 壊す → 直す」で体感するライブデモ
- なぜローカルにDBを直接入れないのかを知る
【ペアハンズオン：環境構築】
- リポジトリをcloneしてdocker compose upで環境を立てる
- 意図的に壊して復旧する演習
→壊してもdocker compose down/upで戻る
※フロントエンド志望者はバックエンド志望者とペアを組み、詰まったらいつでも聞けるようにしています。
【トラブルシューティング + フォロー】
- 環境構築でつまった箇所の解消
- docker logs、docker exec の使い方
- わからない部分のQ&A
【Claude Code + AWS CLI 環境構築入門】
- Claude Codeのセットアップ
- AWS CLIのセットアップ
- Claude Codeによるリソース確認デモ
- 環境への接続とデバッグ演習
- わからなかったことの共有や振り返り
目指す姿：配属先の開発環境を自力で起動できる
この時点では全部理解しなくて大丈夫。docker compose up/downができれば合格です。
Dockerfileの中身も「読めるといいね」レベルでOK！
新卒の声
・dockerfile実行順でimageの重さが変わってくるとか持ってなかった視点なので面白い。
・ハンズオン面白い！トラブルもありましたが、自分の手元で実際に操作して動きを見れるのは楽しい。
・オフィスの書籍の中にブルーベリー本があるのを発見。過去に先輩におすすめされたので時間見つけて読みたいところ。
Day 3：Git/GitHub ＋ CI/CD
GitFlowとTrunk Based Developmentの違い、Conventional Commitsによるコミットメッセージの作法、PRの粒度の判断基準——dipの標準を体系的に習得します。午後にはメンターによる実際のレビューを受け、「PRを出す→修正→再レビュー→Approve」のサイクルを体験します。
【Git/GitHub運用】
- ブランチモデル：GitFlow / Trunk Based どちらを使うか（dipの標準と各チームのアレンジ）
- コミットメッセージの作法（Conventional Commits等）
- PRの粒度：「何を1つのPRにするか」の判断基準
- 配属先のルール確認：PRテンプレート、レビュアー選定の慣習など
【セルフレビュー演習】
- 自分のPRを出す前に「自分でレビューするポイント」を習う
- 差分の見方：GitHub diff画面の読み方演習
- 「バグを自分で見つけるテクニック」演習
→具体例：変数名、ロジック、エラーハンドリング
【CI/CD入門】
- CI/CDパイプライン全体像講義：なぜ自動化するのか、何を自動化するのか
- 配属先の実際のGitHub Actions / CI設定を読む演習
- ローカルでテスト・リントを実行する方法（pre-commit hookの紹介）
- CIが失敗する典型的な理由と対策（フォーマット、テスト失敗、ビルドエラー）
【ハンズオン：PRを出して修正まで】
- 簡単なテスト+実装をして、Pull Requestを出す
- 講師がレビュー → 修正 → 再レビュー → Approve のサイクルを体験
- 「なぜこの指摘か」を理由とともに説明します
目指す姿：チーム開発でのGit運用ルールを理解し、PRを配属先のルールで出せる
この日は開発本部全体で開催している本部会にも参加。
本部会では議論に参加しつつ、ハンズオンも行う実践の日です。
新卒の声
・GitFlowは普段使っている戦略に近いが、TrunkBasedは初めて聞いた。mainが頻繁に変わるというのはなかなかに抵抗があるが、面白そうな戦略なので実際に試してみたい。
・GO言語とても癖が強い！最初の慣れるまで、初期知識を入れる部分のハードルが非常に高く、慣れれば簡単らしいがそのハードルが高いらしい。
Day 4：ディップ流AI-DLC実践
Claude Codeを活用しながら実装し、そのAI出力を自分でレビューしてテスト付きのPRを出す——「AIと一緒に開発する」のではなく「AIの出力に責任を持てる」エンジニアになることを目指します。
【座学：AI-DLCの流れと心構え】
- 「AI-DLC」とは：Design → LLM → Check の3ステップ
- Design：「何をAIに書かせるか」を設計する重要性
- チェック項目：セキュリティ、パフォーマンス、テストカバレッジ、可読性
- 「AIが100%正しい」という思い込みを捨てる（デバッグ力が必須）
【テスト駆動の実装演習】
- 小さなタスクでAI-DLCを回してみる
- テストを先に書く → AI に実装させる → テストが通るか確認
- 通らない場合のAIへの指示し直し方を学ぶ演習
【ハンズオン：実コードでAI活用】
- リアルなタスクで、AI-DLCを回してみる
- Claude Code / GitHub Copilot / Gemini等のツールを実際に動かす
- AI出力 → 自分でテスト実行 → バグを発見 → 修正指示 のループ
【レビュー演習】
- AI生成コードを「本当に正しいか」セルフレビューする
- チェックリスト：メモリリーク、SQLインジェクション、エッジケース対応
- 「簡潔だが不正確」vs「冗長だが安全」のトレードオフ判断
【わからないことリスト作成】
- 今の時点でわからないことをまとめ、翌日の1on1で解消できるように準備
目指す姿：AI出力をレビューして、テスト付きのPRを出せる
新卒の声
・AI-DLCでオカンが小言を言うCLIアプリを作った。
・今日は今までの研修の中で体感一番難しかったかもしれない、これまでなんとなくでやっていたTDDとそれをAIに任せっきりにしていた部分があるので「テストが実装の鏡面になっていないか」や Inception を如何に厚く、強固なものにするかそのやり方や経験則を積んでいきたい。
・AIと全力で対話し、アプリを作成した。今までのバイブコーディングとの違いを全力で感じた。
Week 2：ガイド付きOJT
Week 2からは配属先に入り、メンターの隣に席を構えて実際のコードに触れます。First Issueを切ってもらい、実装→PR→レビュー→マージのサイクルを回します。
Day 5：First Issue実装
【メンター1on1】
- 「わからないことリスト」をベースに今後のキャッチアップ計画を話す
【開発環境セットアップ確認】
- Week 1で構築した環境が最新か確認
- 配属先固有のツール・サービスへのアクセス権限確認
- ローカルで動作確認（動かなければメンターと一緒に解決）
【メンター解説付きコードリーディング】
- メンターが配属先リポジトリの構造を解説
- 「なぜこの設計になっているか」の背景を聞く
- 主要なドメインモデル・エンティティの理解
【First Issue選定 + 着手準備】
- メンターが用意した3つのFirst Issueから1つ選ぶ
- Issueの要件を理解し、どこを修正するか特定する
- 作業ブランチの作成
目指す姿：First Issueに着手する準備が完了
Day 6：First Issue実装
【テスト設計】
- First Issueに対するテストケースを設計
- メンターに「このテストで十分か」を確認
【AI-DLC実装】
- テストを書く → Claude Codeで実装 → テスト実行
- Week 1 Day 4で学んだフローを実コードで再現
- 「動くけど正しくない」箇所をセルフレビュー
【メンターレビュー】
- テストが通るまで修正
- メンターにコードを見せて初期フィードバック
【PRの準備】
- PRテンプレートに沿ってdescriptionを書く
- CIが通る状態にする
- Week 1 Day 3の学びを活かしてセルフレビュー
目指す姿：テスト付きの実装が完了し、PRを出せる状態
Day 7：First Issue PR + レビューサイクル
【PRの最終確認 + 提出】
- PRを提出
- CIの実行を確認
【レビュー待ち + 他の新卒のPR相互レビュー】
- メンターがレビュー中の間、他の新卒のPRを相互レビュー
- 配属先のドキュメント読み込み
【レビュー指摘の対応】
- レビューコメントを読み、修正する
- 「なぜこの指摘なのか」をメンターに質問して理解する
【修正 → 再レビュー → Approve】
- 修正をpush
- CIが通ることを確認
- 再レビュー → Approveを目指す
【振り返り + 2本目のIssue選定】
- First Issue PRの振り返り
- 2本目のIssueの選定
目指す姿：PRのレビューサイクルを1回完走。レビュー指摘を理解し対応できている
Day 8：2本目のIssue + チーム開発体験
【2本目のIssue実装】
- 1本目で学んだフローを自力で回す
- テスト設計 → AI実装 → セルフレビュー → PR作成
- 困ったら15分考えて → Slackで質問 → それでもダメならメンターに聞く
【チームの定例MTG参加】
- 配属先チームのスタンドアップや定例に参加
- チームの仕事の進め方を観察する
【2本目PR提出 + 残り作業】
- 2本目のPR提出
- First Issueがまだマージされていなければ対応
- 配属先のコードで気になった箇所のメモ
目指す姿：2本目のPRを自力で出せている。チームの仕事の進め方を理解している
Day 9：統合演習
【メンター1on1】
- 2週間の振り返り
- 「できるようになったこと / まだ不安なこと」の棚卸し
- 4/27以降の1on1のリズムを決める
【Day 1-4で学んだ内容を使った統合演習】
- 「配属先のシステムをCPC→アーキテクチャ→リポジトリの順で説明する」を1人ずつ発表
- 講師からフィードバック
【LT準備】
- 週明けの振り返りLT会に向けて資料作成
Day 10：本配属！LT大会 ＋ クロージング
5/1から本配属がスタート。
研修の集大成として、新卒6名と開発本部のメンバーで2週間の学びを共有するLT大会を開催し、一番良かったLTを決めるベストLT賞と一番楽しかった、勉強になった研修プログラムを決めるベストプログラム賞を選定しました。
最後はCTOからの一人一人へのGOOD & NEXTのFBでクロージングとなりました！
※ちなみに今回の研修は開発本部のエンジニア社員30名以上が関わり一つ一つ本気で作成したプログラムになります！
この研修で身につく力
2週間を通じて、次の力が段階的に身につきます。
技術的なスキルとして、ディップのシステムアーキテクチャへの理解、Dockerを使ったローカル開発環境の構築と操作、チームの標準に沿ったGit/GitHubの運用（ブランチ戦略、PR、CI/CD）、AI出力をレビューしてテストとセットで提出するAI駆動開発のサイクルが身につきます。
現場で動くための基盤として、配属先チームとの共通言語の獲得、メンターへの相談の仕方、日報・振り返りによる自己成長の習慣、「わからないことリスト」を使った能動的な学習サイクルが身につきます。
研修後は・・・
ただ研修を受けて終わりではありません。配属後も継続的にスキルアップやアウトプットの場を設けています。
- メンター1on1
配属後最初の1ヶ月は週2回、その後は週次1回で技術的なことだけでなく仕事やキャリアについても壁打ちできる場です。 - 週次横断ランチ会
同期のエンジニア全員でそれぞれの配属先での学びやわからなかったこと、心配事などを共有します。開発本部の中で所属部署以外の先輩が各回に参加。上司には言いにくいことがあっても、ここでラフに相談することができます。 - 書籍輪読・座談会プログラム：「スクラムガイド」「リーダブルコード」「イシューからはじめよ」「ドメイン駆動設計をはじめよう」「Webを支える技術 + 達人プログラマー」の順で週に1回、書籍の輪読会を行いインプットを継続します。
- CTO研修
CTO協会が主催している研修に参加します。様々な会社のCTOやエンジニア社員の講義を聞き、他社から知見を学んだり、他社の新卒と交流し仲間を増やす場です。
他にもアジャイル開発の基礎とAI時代における実践を学ぶ研修や、既存社員も含めたイベントや勉強会、様々な世代と関われるラフな交流会を定期的に開催しています。
入社1ヶ月が終了した今、何をしているのか
入社して2ヶ月目に入る手前の今、26年新卒メンバーは既に新規プロジェクトでCTOと議論をしたり、バイトルのリニューアルに携わるなど最前線で活躍しています。
実際の26年卒、5月の業務内容を少しご紹介します。
担当領域: 『スポットバイトル』 クライアント（企業側）領域。新体制のチーム。
業務内容 : クライアント管理画面 FEではNext.js、BE ではGoを使用し、FE / BE / インフラ を横断して、AI-DLC に参画。新機能に関しては、事前調査から仕様設計、OpenAPI(proto) から FE / BE の実装とテストまで行なっています。
担当領域 : CTO室認証基盤ユニット。新規サービスの立ち上げチーム。
業務内容 : 要件やフローの整理など。新規サービスなので実装手前段階を担当し、毎日CTOとデイリーを行っています。
担当領域 : SRE/ AI
業務内容 : AWSアーキテクチャ（CloudFront + WAF + ALB、ECS等）のディープダイブとインフラ設計のキャッチアップを行い、今は大規模本番インフラの監視設計・構築に参加。New Relicを用いて本番環境のアクセスログを自ら解析し課長陣へ直接提案し仕様確定を進めたり、運用負荷軽減のためにTerraformおよびTerragruntへの高度なリファクタリングなども行っています。
担当領域 : 『バイトル』のWebフロントエンド
業務内容 : 『バイトル』のフルリニューアルプロジェクトに参画。使用している言語・フレームワークはReact Router v7(TypeScript)。細かい修正や新規コンポーネントの作成、コードレビューなどを行い、週に1~2回リファインメントに参加など、スクラムイベントにも参加しています。
おわりに
ディップの開発組織には「新卒が組織を作る」文化があります。
バイトルリニューアルやCPCへの移行など、現在ディップは、第二変革期と言われるほど事業や体制が変わり始めているフェーズ。全員正解のない中で0から型や仕組みを作っています。
変革の中で挑戦し続け、チームとしてアウトカムを出し続けられるエンジニアを育てていきたい——学生から社会人(プロ)になるための最初の2週間がこのプログラムです。
この記事が少しでもディップに興味を持ってもらうきっかけになれば嬉しいです。
