新人たちが挑んだチーム開発の舞台裏（2025年度新人研修）

本記事について

この記事は、2025年度 デジ戦 新卒研修の一環として実施されたチーム開発演習について、参加した私たち新卒メンバーが自らの視点で振り返り、まとめた記録です。
テーマは「マイナビの既存サービスをさらにグロースさせる」。このテーマのもと、9つのチームがそれぞれ就職、バイト、研修領域に分かれ、約1ヶ月半にわたる開発演習に取り組みました。

本記事では、演習の概要や進め方、研修での苦労した話をはじめ、各職種がどのような視点で初めての開発演習に臨んだのかを、職種別コラムという形でお届けします。

※ 2025年度 4月～7月に行われた新入社員研修 全体を知りたい方はこちら

本記事の目的

この記録は、社内で共に働くデジ戦社員の皆さまに向けて発信するものです。 「今年の新卒はどんな研修をしていたのか？」「どのような視点で仕事に取り組んでいるのか？」「なにを経験したのか？」 そういった問いに対して、新卒の”リアルな言葉”でお伝えできるような構成にしました。

特に、実際の配属先で一緒に仕事をする先輩方にとっては、新卒社員の思考やスタンスを事前に知ることで、関わり方や育成のヒントになればと考えています。
一方で、これから研修に臨む未来の新卒メンバーにとっても、過去の先輩の軌跡を知ることで、研修をより良い体験にする材料となれば幸いです。

チーム開発について

今回の研修テーマと目的：マイナビをさらにグロースさせる

座学中心のインプット期間を経て、「チームでの実践」を軸とした開発演習が一か月半実施されました。 この演習のテーマは、「マイナビの既存サービスを、さらにグロースさせる企画を立案・実装せよ」というもの。単なる新規開発ではなく、「実在するサービス」を、現実的な視点でより良くする”という実務的な課題が与えられました。

具体的には、以下の3サービス群のいずれかを対象とし、チーム開発に取り組みました。

• マイナビ就職
• マイナビバイト
• マイナビにおける研修サービス

また、開発演習には、もう一つの大きな目的がありました。それが、「システム開発の全体を理解し、各職種の役割とスキルを習得すること」、そして「自分の職務範囲を超えた業務への理解と相互理解を深め、チームで円滑に開発を進める力を養うこと」です。

そのため演習は、異なる職種が混在するチームで実施され、各メンバーは自らの専門領域だけでなく、他職種の観点を理解・連携しながら企画と実装に挑む必要がありました。

各チームの開発テーマ：9チームの役割

研修参加者は、職種混在の9チームに分かれて活動しました。チームにはそれぞれの専門性を持つ新卒が割り振られ、少数精鋭でサービスの改善案を企画・実装する体制が組まれました。

対象サービスとチームの割り当ては、以下の通りです。

• 1〜3班：マイナビ就職のグロース企画
• 4〜6班：マイナビバイトのグロース企画
• 7〜9班：マイナビ研修サービスのグロース企画

各チームの基本構成は次のようになっています。

• エンジニア（3名）：フロント・バックエンドの実装を担当
• デザイナー（1名）：UI/UX設計を中心に、チーム内のビジュアル制作を担当（他職種との兼任あり）
• マーケター（1名）：ペルソナ設計・市場分析・PR設計などを担当（他職種との兼任あり）
• データサイエンティスト（1名）：3チーム兼任で、データベース設計やロジック設計に貢献

各職種が自分の仕事に責任をもたなければならないチーム構成のため、専門外の領域に関する会話が日常的に行われ、他職種への理解と越境的な対話が当たり前になるような環境が自然に構築されていきました。

約1ヶ月半のスケジュールと流れ

本演習は、全5回のスプリント（Sprint1〜5）＋成果発表会という構成で進行しました。各スプリントは1週間を単位とし、下記のようなそれぞれに異なる目的とフェーズが設定されています。

この進行により、「仮説を立てて試す → チームで振り返る → 改善する」のサイクルを毎週繰り返しながら、最終的なプロダクトを形にしていきました。
しかし、理想的な目的やフェーズに対して、実際の開発ではトラブルがつきものです。理想的なスケジュールに追いつこうとしても、なかなかうまくいかないというのが現実でした。具体的なエピソードは「ピボットに対する苦悩」をご覧ください。

ピボットに対する苦悩

Team4では、当初進めていた企画が、ペルソナである女子大生の課題に本質的にアプローチできていないのではないか、という疑問がチーム内で浮上しました。実際、当初の案には6人中3人が反対しており、全員が納得している状況ではありませんでした。議論を重ねた結果、思い切って企画を白紙に戻し、全員が納得できる新しい方向性を探る「ピボット」を決断しました。決断したその時は大きな葛藤がありました。なぜなら、ピボットをすると、それまでチーム全員で積み重ねてきたアイデアの検討や議論、費やした時間や努力がすべて無駄になってしまうからです。 それでも、最初の違和感や納得できない点を放置して進めてしまうと、後々さらに大きな問題に発展することを全員で認識し、勇気を持って方向転換を決断しました。 結果として、全員が納得できる新しいアイデアに切り替えることができ、チームの雰囲気も前向きになりました。この経験から、初期段階での違和感や課題を見逃さず、早めに軌道修正することの大切さを学び、今となっては良い経験になりました。

スクラム形式で進めたプロダクト開発

この演習では、開発の進め方としてスクラム形式が採用されていました。スクラムとは、1〜2週間の短い期間（＝スプリント）を単位として開発を進め、毎回振り返りと改善を繰り返していくアジャイル開発手法の一つです。

今回の研修では、このスクラムの考え方を参考に、5日間1スプリント、全5スプリントの構成でプロダクト開発に取り組みました。 毎週のスプリントでは、以下の流れで進行しました

レトロスペクティブの多様性
レトロスペクティブは、チームごとにやり方が異なっていました。
各チームのレトロスペクティブを以下に記載しております。

チーム４（2枚目）、チーム6（2枚目）のレトロスペクティブは、付箋形式でまとめていました。

チーム5は、エクセル形式でまとめていました。やり方は、各メンバー間で話し合って決めているため、個性豊かです。

この一連のサイクルを通じて、私たちは単なる「開発作業」ではなく、進め方そのものを改善していくプロセスも学ぶことができました。時間を区切り、仮説を立て、検証し、振り返る。この循環が自然と身につく構成になっていたことが、本演習の大きな特徴です。

スクラム形式独自の役割

スクラム開発では、各チームには以下のような役割が設けられていました。

各役割について

• プロダクトオーナー（PO）
  プロダクトの方向性や価値の最大化に責任を持つ役割です。ユーザー視点の価値を整理し、開発に反映させる役も担いました。
  ※今回の研修では、職種を問わず選出されていました。
• スクラムマスター（SM）
  チームが円滑にスクラムを実践できるようサポートする役割です。進行管理や課題解決のファシリテーションを行い、チームの生産性向上を支援する役です。
  ※今回の研修では、職種を問わず選出されていました。
• テックリーダー（TL）
  技術面での意思決定や開発のリードを担う役割です。設計や実装の方針決定、技術的な課題解決、開発メンバーでのタスク分担などを担当します。
  ※今回の研修では、開発職のメンバーが担当していました。

POとしての苦労

筆者自身は、今回の研修でプロダクトオーナー（PO）を担当しました。 プロダクトオーナー（PO）はエンジニアやWebディレクター、マーケターなど職種を問わず選出されていたため、私自身も「なぜ自分がPOに？」という戸惑いからのスタートでした。 POは本来、プロダクトの方向性や価値の最大化に責任を持ち、開発チームの中でも責任重大な役割です。しかし、私を含め多くのメンバーがPOの経験はなく、「POって何をする役割なの？」というところからのスタートでした。 実際に作業を始めてみても、バックログの管理方法や意思決定の進め方など、全てが手探り状態。「この判断で本当に良いのか？」と不安を抱えながら悶々とする日々が続きました。そのため、PO同士でミーティングを開き、「どんな悩みを抱えているか」「バックログはどう管理しているか」など、役割特有の悩みを率直に共有し合いました。それがきっかけで、バックログ管理では「タスクの粒度を揃える」「優先順位を明確にする」など、他のPOのやり方を参考にしながら少しずつ自分なりの型を作っていきました。こうした横のつながりができたことで、少しずつ自分のやり方を改善でき、自信を持って役割を果たせるようになったのは、今回の研修ならではの大きな学びでした。

毎週のイベントと先輩社員とのやり取り

• 先輩社員による巡回（毎週月曜）
  各チームには職種ごとの先輩社員が週1回（30分）巡回し、進捗や悩みに対して実務視点でのアドバイスをいただきました。
  • マーケター・デザイナー・DSの新卒は、同じ職種の先輩社員と1対1で面談
  • 開発職の新卒は、エンジニアの先輩社員1名と開発3名でグループ面談

それぞれの立場や職種特有の観点に即した助言をいただいたことで、より現場に近い判断軸や工夫のポイントを知ることができました。 “職種別の1on1コーチング” のような位置づけで、毎週の改善と意思決定を後押しする重要な時間でした。

• スプリントレビュー（毎週木曜）
  各スプリントの終わりには、全職種（マーケ・開発・デザイン・DS）の先輩社員が集まるレビュー会が実施されました。 各チームがその週に取り組んだ成果や課題、プロダクトのデモを共有し、多角的なフィードバックを受ける機会です。
  

“単なる進捗確認”ではなく、ユーザー視点・技術的妥当性・PR効果・UIの納得感など、あらゆる視点でプロダクトの意義を問い直す場として機能しました。
また、実務レベルの鋭い指摘をいただけるからこそ、「一週間で成果を出す」というスピード感を強く意識できる、非常に重要な機会となっていました。

このように、先輩社員との定期的な対話は、学習的な演習でありながら、実務と地続きの感覚を持てる設計になっており、チームの自律性と視座の向上を後押ししてくれました。

職種別リアル体験記

開発エンジニア＆TL M.Hさん

主な業務

• 開発チームのタスク切り分け、管理
• フロントエンド
  画面遷移、リクエスト、leafletを用いた地図コンポーネント作成、アニメーション
  

バックエンド
確率算出関数作成、APIの作成

チーム連携で意識したこと

開発タスクの振り分け
開発チームとして私のほかに二人SEがアサインされましたが、それぞれ経験が浅いことを踏まえ、フロントエンドとバックエンドに注力して頂きました。
終盤では各々の担当領域において大きく成長し、自らタスクの発見をしたり、私が細かい指示などを行わずともスムーズに開発業務が進む環境となりました。

振り返っての学び・気づき

• 反省点
  バックエンドのタスク量を甘く見積もっていました。
  DB周りと、API周りに区切ってタスクを切るべきでした。
  また、前半ではPRのレビューがかなり曖昧でした。
  何をレビューしていいのかわからなかったという点も大きかったですが、私の環境で動作するかも確認せずにマージしてしまったこともありました。（PR提出者の環境で動作することは確認していましたが）
• 良かった点
  ピボットが発生しなかった点が私のチームの最大の強みでした。
  企画面に不安があったとしても、ピボットは慎重に、もし行う場合は迅速に行うべきであると感じました。
  また、早めに「デモをつくり、見てもらった人に価値を感じてもらう」という意識を持てた点も強みの一つでした。
  フロントエンドに多くの工数を割き、私たちの頭の中にあるサービスを可能な限り目で見られる形にすることを重要視しました。

WEBマーケター S.Aさん

主な業務

市場調査、コンセプト立案、施策案、KPI設定、ユーザーヒアリング、PR計画、各Sprintでの発表準備

チーム連携で意識したこと

チーム連携において私が最も意識したのは、「各職種が作業に取り組みやすいように引き継ぐ」ということです。

私のチームでは、既存サイトのUI/UX改善が大きなテーマでした。施策を実装してくれる開発担当に対しては、実装しやすい方法をあらかじめ確認したうえで、必要なデータを整理し、スムーズに引き継ぐよう努めました。

また、私たちのチームのデザイナーは3つのチームを掛け持ちしており、他のデザイナーと比べて圧倒的に業務量が多いように感じられました。そのため、デザインやスライド資料の作成を依頼する際には、ゼロからお願いするのではなく、まず自分でたたき台を用意してから依頼するよう心がけていました。

このように、各職種への配慮を意識した結果として、私自身も仕事を進めやすい環境が自然と整っていたと感じています。

振り返っての学び・気づき

1. 課題を見つけるために現状把握が大切
マーケターとして学べたことは「現状把握の大切さ」です。ピボットをした際には何日も施策が定まらない期間がありました。大きな要因は、根拠のないまま想像で課題のアイデアを発散させてしまっていたことにあります。実際に、市場調査や自社サービスの分析を行うことで本質的な課題が浮かび上がりました。この経験を通じて、自らフレームワークの重要性を実感できたことは、非常に貴重だったと感じています。
2. 認識の齟齬をなくすために報連相が大切
私たちのチームでは、毎日の進捗共有の時間を特に重視していました。さまざまな職種のメンバーが集まる中で、職種によって考えや認識が異なることを初期段階で実感したためです。進捗共有の時間は、単に作業の進行状況を報告する場にとどまらず、各職種の視点や意見を交換し合う貴重な機会にもなっていました。こうした対話を継続的に行ったことで、大きな認識の齟齬が生まれることなく、計画通りに開発を進めることができたと考えています。

システムエンジニア＆PO O.Aさん

主な業務

SEとしては、フロントエンドからバックエンドまで広く担当しました。
また、POとしての役割も兼任しており、チームの最終的な意思決定。GithubProjectsでのバックログ管理を担いました。

チーム開発での課題に対する取り組み

• 特定の人にタスクが偏る
  私のチームは、思いやりのあるメンバーが多かったため、スプリント前半では「他のメンバーにタスクを頼むことに遠慮してしまい、特定の人にタスクが集中してしまう」という問題が発生しました。そこで、ギブリーの講師の方からのアドバイスを受け、Github Projectsを用いたバックログ管理を導入しました。これにより、各メンバーが現在のタスク状況を把握しやすくなり、手が空いた人が自発的に仕事へ取り組める環境を整えることができました。
  
  
• 開発経験がないメンバーが多く、成果発表まで工数が厳しい
  開発担当の3名中2名が開発未経験だったため、限られた期間で完成させるには、やるべきことの取捨選択が不可欠でした。スプリント前半では、完璧な成果物を目指すのではなく、デモに必要な最低限の機能に絞って実装する方針を決定しました。具体的には、データベース設計や、実装する機能をデモで使用するもののみに限定し、既存サービスの機能は実装せず、私たちの班独自の新機能に集中しました。こうした工夫により、短期間でも無理なく開発を完了させることができました。
  

私たちのチームが実装した機能の絞り込みページ
工数を加味して、デモで使用する絞り込み条件「地区・都道府県・市区町村・ネイルOKタグ」に限定して実装しました。

振り返っての学び・気づき

• ”タスクの可視化”、”タスクの取捨選択”を行うことがチームの結束を強くするということです。はじめは優しいからこそ、進みの遅いチームでしたが、環境を整えてからは、優しさとスピード感を兼ね備えた、メンバー間の連携が取れた素晴らしいチームとなりました。

データサイエンティスト I.Yさん

主な業務

DS職は3名なので、各自が1サービスの3チームを兼任していました。
演習の制約上、サービスのデータ使用やAIの組み込みは不可。「データのないDSは、食材のないシェフのようなもの」。つまり、データサイエンティストとしての役割を果たすことが難しい状況でした。そんな中、私は専門性にこだわらず、他職種のアシスタントとして動くことを選びました。DB設計、KPI・KGI策定補助、ダミーデータ作成など、できることをできるだけやる。それが私の選んだスタンスです。

チーム開発での課題に対する取り組み

最も悩んだのは、「DSとして何をすべきかがわからない」という問題です。講師やメンターに相談しても、悩みは晴れませんでした。
その背景には、他職種との視点の違いがありました。

• ゴールの違い：
  DSは開発後に分析しやすい開発設計
  開発職はデモが動くことを重視
• 範囲の違い：
  DSは1サービスを横断的に担当し、複数システムが共存する前提で設計
  開発職は自チームに最適化された設計
  この価値観の違いで衝突することが予想できたため、私はより葛藤を深めました。

悩んだ末に、私はDSを捨てることにしました。自分の視点がチームにとっての価値を示せないと感じたからです。理解されにくい価値観に固執するよりも、ただのヒトとしてできることをすると心が楽になりました。
専門性にこだわらず、柔軟に動くことで、チームに貢献できる場面も増えました。

振り返っての学び・気づき

自分がやるべきこと≠チームが求めていること
このギャップにどう向き合うか、今でも正解はわかりません。
ただ、1つ気づいたのは諦めることは悪ではないということ。他者を変えるより、自分を変える方に割り切ることで、前に進む力が生まれます。
また、反省点として、チーム内で目的やゴールを共有しておくことの重要性も痛感しました。意見が衝突したときの判断基準になるからです。
この演習で、人としての柔軟さや共感力の大切さを学びました。DSとしての理想と現実の間で揺れながらも、できることを模索した時間は、私にとってよい学びとなりました。

まとめ

開発演習の体験談はいかがだったでしょうか。

約1ヶ月半にわたって、私たち新卒メンバーはそれぞれが多くの壁にぶつかりながらも、試行錯誤を重ねてきました。
初めての実践的な開発、限られた時間の中でのタスク管理、メンバー間のコミュニケーションの難しさなど、日々が挑戦の連続でした。
そんな私たちの奮闘の記録が、少しでも皆様に伝わっていただけると幸いです。

下記、最終成果発表の様子

最後に、ご協力いただいた事業部の皆様、アドバイスとFBをしてくださった講師やメンターの先輩方、企画運営や相談、ユーザーヒアリングまで受けていただいた教育担当の方々など、この開発演習を走り切ることができたのは多くの方のご支援があればこそでした。
この場をお借りしてお礼申し上げます。
本当にありがとうございました。