14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 10

ウェブクルー Advent Calendar 2025

@tatsuyanamikiin株式会社ウェブクルー

新卒総合演習メンター記録 — 2ヶ月で完走させるための実務ログ

14
Last updated at Posted at 2025-12-12

この記事はウェブクルー Advent Calendar 2025 の10日目の記事です。
昨日は@ysawaさんの「 Scalaのコンパニオンオブジェクトとは 」でした。

はじめに

本記事は、私が新卒向け総合演習において、
フロントエンド側メンターとして約2ヶ月間伴走した記録をもとにしています。

  • 立場
    新卒3名（フロントエンド1名・バックエンド2名）に伴走したフロントエンドメンター

そのとき実際にやったこと・考えたことを時系列でまとめ、どのようにして研修を進行したのかをご紹介いたします。

研修の概要

本記事で扱う「総合演習」は、
新卒社員3名で1つのWebアプリケーションを開発する研修です。

チーム構成

  • 新卒メンバー：3名
    • フロントエンド：1名
    • バックエンド：2名
  • メンター：2名
    • フロントエンド担当（筆者）
    • バックエンド担当

研修内容

  • 企画・設計・開発・テスト・リリースまでを一気通貫で実施
  • 最終日に成果発表を行う

フェーズ構成と期間

  • フェーズ1：オープニングオリエンテーション（1日）
  • フェーズ2：アイデア発表会（1日）
  • フェーズ3：企画（5日）
  • フェーズ4：設計（8日）
  • フェーズ5：開発（28日）
  • フェーズ6：成果発表準備（3日）
  • フェーズ7：成果発表（1日）

全体で 約2ヶ月間 の研修です。

研修の目的

この総合演習の主な目的は、
開発現場で求められる基礎的な業務能力の向上 です。

単に個人の技術力を伸ばすことだけではなく、
「他者と協働してアウトプットを出す経験」 を重視しています。

総合演習を通じて習得してほしいスキル

技術・ツール面

  • エディタ / 開発支援

    • VSCode / IntelliJ IDEA

      • ソース作成、デバッグ
      • AI開発補助ツール（GitHub Copilot等）の利用

  • コンテナ

    • Docker

      • 基本コマンドの理解
      • 既存イメージの利用
      • MySQLを使用できる状態まで

  • バージョン管理

    • Git

      • 基礎コマンド
      • push / pull / merge
      • ブランチ運用
      • コンフリクト解消

    • GitHubによるソースレビュー

セルフマネジメント

  • タスクの優先順位付け
  • 期限を意識した進行
  • 朝会・夕会など、定期的な進捗共有

自律的な学習姿勢

  • 調査力・質問力の強化

  • 不明点が出た際の基本プロセスの徹底

    1. 自己解決の試行
    2. チーム内での相談
    3. メンターへの相談

この研修では、
「分からない状態をどう扱うか」そのものも学習対象になっています。

フェーズ1：オープニングオリエンテーション

やったこと

  • 自己紹介

  • 総合演習の目的・全体像の共有

  • 使用する技術要素・ツールの共有

  • 全体スケジュールの共有

  • 次のアクションとして「まず企画を作る」ことを明示

  • 企画立案のポイントとして以下を提示

    • 目的・解決したい課題
    • 期待する効果
    • MVP（最低限成立させる範囲）

  • 上記内容をまとめたオリエンテーション資料をパワポで作成し、自己紹介から企画立案のポイントまで順序立てて説明

フェーズ2：アイデア発表会

やったこと

  • 新卒が持ち寄ったアイデアをすべて共有

  • 以下の観点でディスカッションを実施

    • 期間内に実装できそうか
    • スキルアップにつながる内容か
    • 作っている間のモチベーションが維持できそうか

  • ディスカッションの結果、
    「複数チャンネルで自由に投稿・閲覧できるサイト」 を開発テーマとして決定
    （イメージとしては某巨大掲示板のようなもの）

  • 仕様としてアカウント登録・ログイン機能を含めることで、

    • 業務で頻出する認証機能の実装経験が積める
    • フロント／バック双方に実装ポイントがあり、学習効果が高い

    と判断しました。

悩んだ点

面白そうなアイデアは多く出たものの、
2ヶ月という期間で本当に完成できるかどうかは、メンター側でも判断が難しい状態でした。

新卒の「やってみたい」という気持ちを尊重しつつも、
メンターの立場としては 「確実に完走できるか」 という視点を持つ必要があります。

そこで最初に、

  • MVPに明確な線を引く
  • 拡張案は「後半に余力があれば対応する」

という合意形成に、しっかり時間をかけました。

フェーズ3：企画

やったこと

  • 企画発表用の資料作成を依頼

    • 企画書
    • 機能優先順位表

  • フィードバックは以下に集中

    • 課題が具体的か
    • 「このサイトでどうなっていてほしいか」が想像できるか
    • MVPが明確か

悩んだ点

企画書や発表資料に書かれる
課題・目的・効果の表現が、どうしても抽象に流れがちでした。

具体例をそのまま出すと答えを渡してしまうため、

  • 「どのような課題があるのか」
  • 「作成したアプリケーション使った後に何が変わるか」

といった切り口だけを渡し、
表現自体は本人たちの言葉で詰めてもらいました。

フェーズ4：設計

やったこと

  • 設計フェーズとして、以下の設計資料の作成を新卒に依頼

    • ユーザーフロー図
    • ER図
    • 設計書
    • 要件定義書
    • 総合演習用の開発ルールドキュメント

  • これらの資料の作成・レビューはすべて
    総合演習用の GitHub リポジトリ上で Issue を使って実施

  • 各設計資料について、Issue 上でレビューを行い、
    指摘内容をもとに修正 → 再レビュー、という形で進行

  • 企画〜設計フェーズ全体のスケジュール管理として

    • 当初は GitHub Project を利用
    • 途中から、スプレッドシートでの WBS 管理に切り替え
    • WBS の雛形はメンター側で作成し提供

悩んだ点

設計資料そのもの以上に、
レビュー時のやりとりの進め方に悩みました。

当初はレビュー依頼が
「レビューお願いします」で止まることが多く、

  • どこを見てほしいのか
  • どの観点で意見を求めているのか

が共有されていない状態が続きました。

結果として、レビューの往復に時間がかかり、
確認の粒度もばらつきが出てしまいました。

その時に意識したこと・対応

そこで、レビュー依頼時には

  • 「どこを特に見てほしいか」
  • 「どの観点でコメントしてほしいか」

を一言添えることを、明文化して伝えました。

また、レビューコメントでは設計内容の指摘だけでなく、

  • 依頼内容が具体的か
  • 相手が確認しやすい書き方になっているか

といった テキストコミュニケーション面についても
フィードバックを行いました。

この運用を定着させるまでに何度かリマインドが必要で、
どこまで求めるかには悩みましたが、
結果的に後半のレビューはかなりスムーズになりました。

フェーズ5：開発

やったこと

  • 開発期間中は、毎朝簡単な朝会を実施

    • 進捗
    • 詰まっている点
    • 相談したいこと
      を共有する場として運用

  • フロントエンドの開発環境構築は、メンター側で事前に対応

  • 実行環境の構築についても、メンター側で対応

  • 実装は段階的に進行

    • フェーズ1：
      ユーザー認証・アカウント機能
      （新規登録、ログイン画面など）

    • フェーズ2：
      コア機能の構築
      （チャンネルの作成・閲覧、コメント投稿画面など）

  • API のつなぎ込みや画面実装は新卒主体で進行

  • 以下のような、開発を進める上で必要な基礎知識をレクチャー

    • ブランチ運用
    • プルリクエストの作成手順
    • コンフリクト発生時の対応方法

反省点

開発に入るまでの準備部分に想定以上の時間がかかった点が、今回の大きな反省点でした。

  • 開発環境の構築に時間がかかり、なかなか実装に着手できなかった
  • 実行環境の構築完了にも時間を要してしまった

結果として、

  • MVPの実装で精一杯
  • 付加価値機能の構築まで手が回らなかった
  • より多くの技術に挑戦したり、テストを行って品質を高める余地を十分に確保できなかった

という状況になりました。

環境構築は新卒に任せづらく、どうしてもメンター側のタスクになりがちです。
そのため今回の経験から、

可能であれば、総合演習のキックオフ前に
開発環境・実行環境の準備を済ませておくのが理想的

だと強く感じました。

初動がスムーズであれば、
開発フェーズ後半をより「挑戦と改善」に使えた可能性が高く、
今後同様の研修を担当する際には、最優先で改善したいポイントです。

フェーズ6：成果発表準備

やったこと

発表資料の構成は以下を依頼：

  • 背景
  • 概要
  • 使用技術
  • スケジュール
  • 実装機能
  • 担当
  • 学び・反省
  • デモ
  • まとめ

フィードバックでは

  • 表現の統一
  • 具体例の追加
  • 今後の改善案の明記
    を重視。

社内リハーサルを複数回行い、

  • 冗長な箇所の削減
  • 質疑応答の想定
    を行いました。

悩んだ点

「学び・反省」が抽象になりがちでした。

最終的に
「1つの具体エピソード＋改善策」 に絞り、
深く掘る構成にしてもらうよう、依頼しました。

フェーズ7：成果発表

やったこと

進行は事前に以下の流れで設計しました。

  • 前説（メンターが担当）
  • 新卒による発表
  • Q&A
  • メンターコメント
  • 上長コメント

初回リハーサルで所要時間を把握し、
本番では内容の密度を上げる形で構成を調整しました。

振り返り

当日はメンター側としてかなり緊張していましたが、
新卒の方々が落ち着いて発表を進めてくれたおかげで、
結果として良い成果発表になったと感じています。

おわりに

これまで新卒研修を数日間担当した経験はありましたが、
約2ヶ月間、メンターとして伴走するのは今回が初めてでした。

その中で、教える立場として多くの学びがありました。
特に、

  • どうすれば新卒に正しく理解してもらえるか
  • どこまで教え、どこからは任せるべきか

といった「教え方の匙加減」には、常に悩まされました。

答えをそのまま伝えたり手伝えば一時的には解決しますが、
それが必ずしも成長につながるとは限りません。
あえてヒントだけを出し、最終的には見守る判断をすることも多く、
そのもどかしさを感じる場面もありました。

大変なこともありましたが、振り返ると非常に学びが多く、
個人的にはとても充実した2ヶ月間だったと感じています。

この記事が、これから新卒研修のメンターを担当される方の
参考になれば幸いです。

明日は@wc-nakayamaさんの投稿になります。お楽しみに！

ウェブクルーでは一緒に働いていただける方を随時募集しております。
お気軽にエントリーくださいませ。
https://www.webcrew.co.jp/recruit/

14
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?