新卒でいきなりスクラムマスターを経験して得た学び

※この記事は「エムティーアイ Blog Summer 2025」の 8/14 分の記事です。

はじめに

こんにちは!スマートコンテンツ事業部の岩本です。
4月にエムティーアイ新卒エンジニアとして入社しました。

今回は研修の一環で行った新卒でのチーム開発で、スクラムマスターを行った経験について振り返ります。

就活の際に実際に研修では何をするのか?研修で技術力だけではなく実際にチームで開発をするために何を学んだか?気になる人のためにまとめようと思います。

研修の概要

  • 4月:総合職・営業職と合同の新卒研修
  • 5~7月:開発職研修(React / C#を用いた開発とチーム開発・AWSやスクラムなど)

※上記の内容は今年度の内容のため、研修期間や内容は毎年変わる可能性があります。

スクラムマスターをすることになった経緯

研修の内容となるので、記述できる範囲内で書いていきます。

まず、今年の研修ではアプリをただ仕様通りに作るだけでなく最近の技術やAI駆動開発の発展とともにエンジニアも単なる技術者視点だけでなく様々な知識や視点・経験を求められるようになってきています。

そうした背景から研修で作るアプリの企画プロセスから自分たちで行うということをしました。
企画ではデザインスプリントというものを行いましたが、それは別途新卒チームでプロダクトオーナーの役割を担ったメンバーが記事にする予定です。

チーム開発の概要

今回の研修では、約1か月で新卒エンジニア全員が1つのプロジェクトチームとなって1つの課題テーマを解決するためのプロダクトを企画~開発~プレゼンまで行うといった内容でした。

といっても常に全員が同じチームとして会議や開発を行うわけではなく、企画チームや開発チームに分かれたり、機能ごとに開発チームを分けたりかなり柔軟なチーム構成での開発でした。

課題と役割設定

その中で、最初はスクラム形式で開発を進めていたものの企画チームが企画を考え、開発チームが設計や開発を行いPOやSMのロールは特に設定せず、各個人が1人のメンバーとして企画・開発を進めていました。

しかし、1週間ほど経ち企画(MVP)を粗方確定させて全員で開発を始めないとスケジュール的に開発が間に合わないかもしれないという状況になってきました。
また、企画と開発チームで分かれて企画はMVPの策定、開発は固まってる要求をもとに設計や環境構築などを行っていてチーム間の情報の分断や認識齟齬などの課題が発生し始めました。

そこで、まずプロダクトの案を考えたメンバーがプロダクトオーナーとして企画の意思決定は行うことをメンバー全員で合意を取り、意思決定のスピードと相談先の明確化を行いました。

また、企画が終了して全員で開発に入る際に、全員で一つの開発チームとすると効率が悪いので三つのチームに分かれて開発をすることになりました。
これまで企画と開発の二つのチームだけでもコミュニケーションで課題が発生していたのに、さらにチームが増えると課題も増えそうという意見がメンバーから出てきました。

そこで、技術面だけでなくスクラムイベントのファシリテーションや各チームリーダー・POとの連携やその他の様々なチームの障害の除去を行うスクラムマスターの役割を自分が務めることになりました。

※もちろん、研修担当の方があらゆる面でサポートをしてくださったので過剰な負担や責任は心配なかったです!

スクラムマスターとして実際にやったこと

スクラムイベントの運営

実際、スクラムを経験したことがない人はスクラムイベントってなに?となると思うので軽く紹介します。

スクラムイベントとは スクラムでは決められた期間(スプリント)でプロダクトを開発し、その中で以下のようなイベント(会議)を定期的に開催します。
今回は3日で1Sprintとかなり短かったのも大変な要因でした。

  • スプリントプランニング: スプリントで何を作るか・行うかをチーム全体で計画する
  • デイリースクラム: 毎日15~30分ほどでチームごとに進捗や課題を全体で共有する
  • スプリントレビュー: スプリント終了時に成果物をレビューする
  • レトロスペクティブ: スプリントを振り返り、改善点を話し合う

これらのイベントを円滑に進行し、チームが効率的に開発できるようサポートするのがスクラムマスターの重要な役割の一つです。

チーム間の調整・コミュニケーション

ぶっちゃけこれが一番大変でした。
開発職は基本フルリモートで、研修も基本的にはオンラインでのコミュニケーションでした。

それゆえに、チャットコミュニケーションや会議の頻度などのオンラインでのコミュニケーションに不慣れなメンバーも多い中でチーム開発を行いました。
さらに、3日1Sprintとスケジュールもかなりタイトだったことから以下のような課題が出ました。

  • 会議が長引いて他の会議やタスク進捗に影響が出る
  • 会議の内容が文字になっておらず参加メンバー以外が知らない・分からない
  • 会議詰めになってしまう
  • 不具合や伝達事項などが発生した際に報告がバラバラになり情報が散乱してしまう

これらの課題を解決するために、以下のような対応を全員で行いました。

  • 会議のファシリテーターと議題は必ず会議設定時に明記する
  • 急な会議も基本10分は開始まで時間を空け、上記を明記して設定する
  • 会議の内容は議題に基づいてかならず議事録を作る
  • チームリーダーやPO・SMなどの意思決定の際のコアメンバーを設定し、コアメンバー連絡用のスレッドを作る
  • バグチケットを起票し、起票したチケットに内容を詳細に記載した上で共有する

これらの対応は一度にまとめてではなく、段階的に試行錯誤をしていった上で進めていきました。

結果として、リリース前なども混乱はあったものの改善前と比べて情報量が増えた際も対応できるようになりました。

また、他にも手が空いた際には各チームの会議で情報があまり出てこないものに顔を出したり状況確認の連絡をするなどして積極的に各チームの状況をキャッチアップして、必要があれば進行などの補助を行ったり課題や不満なところはないかの確認も行いました。

新卒でスクラムマスターをやって感じた課題と学び

実際、メンバーがスクラムもコミュニケーションも、そもそも開発・チーム開発・言語自体も不慣れなものが多かったので高度な技術的課題などというより、うまくいく定番のような動きに全員が慣れるまでが大変でした。

しかし、その過程で仕組みさえある程度作ってインプットしてしまえば案外経験がなくてもすぐに慣れてうまくチームが回りだすということを学びました。

また、実際にチームで開発をしてみると思っていたよりも実際にコードを書いている時間より会議や設計などのドキュメント作成などコーディング以外の作業が多いということに気づきました。

実際、AIも使える環境だったので自分はチーム開発フェーズはほとんど直接的なコーディング自体は行わず、設計や会議・コミュニケーション・クラウドの設定などコーディング以外の開発に必要なことをしている時間が多かったです。
※開発をがっつりしたい人はもちろん開発に集中して時間を取っていました。そういったメンバーが集中できる環境や状況づくりも自分がSMとして意識した点です!

実際のところは、自分の進行能力や技術的知識の不足で研修担当の上司の方に力になっていただく機会もかなり多かったです。

ただ、そこから「現場経験の豊富な人はこうやって進めるんだ」とか「こういうやり方、知識があるんだ」「どの技術も深く理解していてすごい、自分もこうなりたい」と多くの学びと自分のこれから習得していきたいものへの気づきがありました。

今回の1か月にも満たない期間しかスクラムマスターという役割の経験はしていません。
それでも、コミュニケーションやプロジェクトの進行や各メンバーの特性をよく見て強みを活かせるように進めることを一貫して意識し続けました。

それを通して、個々人の経験・学び・モチベーションと全体の進行のバランスを考えながら進め方を考える力、必要に応じて上司や各メンバーに相談する力など多くの経験をすることができたと思います。

おわりに

これまで一人のエンジニアとして技術のことを中心に学んできましたが、今回のチーム開発・スクラムマスターの経験を通じてチームで開発するには技術だけでなく様々なソフトスキルも必要だということを痛感しました。

また、アーキテクチャやGit Flow・スクラムなど一人で開発しているだけでは中々必要と思えなかったり触れる機会の少ない知識に多く触れることができとても貴重な経験ができました。
スクラムという仕組みとその課題についてもより深く理解することができ、今後のチーム開発をする際はこの学びを活用していこうと思います。

新卒でスクラムマスターをいきなり担当した経験なんて、滅多にできることではなく自分としてはただエンジニアとして開発を黙々と進めるより圧倒的に挑戦してみてよかったなと感じています。

エンジニアブログらしく、今後同じような経験をもしすることになった人に向けてメッセージを残すと

  • プロジェクトのために頼れる人は遠慮なく頼ろう
  • メンバーも一緒に成長するもの、自発的に動くとはなにかとその楽しさを共有して良い関係値が構築できれば勝手に嬉しい動きをしてくれることがあるのでまずは信頼してみる
  • 現実的な視点は持ちつつも、まずは前に進めるために発言はポジティブに。ネガティブな発言もポジティブな発言も伝播して全体の雰囲気からプロジェクトの進行にまで影響する
  • AIは使えるならどんどん良い使い方をしていこう

となります!

チームのためってなんだろう?から議論した次の日からものすごく助かる動きが増えたメンバーが居たり、自分に連絡が集中してるのを見て漏れそうなところを対応してくれるメンバーが居たりと上司だけでなくメンバーにもたくさん助けられたとてもありがたい経験でした。

スクラムマスター楽しかったです!閲覧ありがとうございました。