
入社1ヶ月でスクラムマスターやってみた
23卒サーバサイドエンジニアとしてゆめみに入社した際に
経験した研修プロジェクトで,エンジニア兼スクラムマスターを務めた時の活動と感想をまとめてみました!
入社1ヶ月でスクラムマスターってどういうこと?
ゆめみではこんな研修が実施されています!
この note では詳細は省きますが(誰か書いてくれないかな〜〜),ゆめみでは,新卒メンバーでチームを組んでプロダクト開発を行う研修が行われています(全員参加ではない・変更の可能性はあり).
そこで私は,社内において notion で運用されている案件の掲示板(ジョブボード)を新規 Web アプリケーションとして開発するプロジェクトに,サーバーサイドエンジニア兼スクラムマスターとして参加しました!
プロジェクトについての情報
メンバー
プロダクトオーナー:1名
スクラムマスター:1名(メンター1名)
デザイン:2名(メンター2名)
フロント:3名(メンター2名)
サーバー:4名(メンター2名)
(ナウでヤングな)開発環境
フロント:Next.js 13
サーバー:Rust
このプロジェクトで起こった主なイベント(一部)
ジョブボードのことを知るためのワークショップ
デザインのメンバーが主催してくれました!スギョイ
MVP(Minimum Viable Product) に必要な機能精査
miro を使って,やいのやいの言いながらやりました
ドメインモデル図づくり
案件参画のためメンバー卒業 and 新メンバー加入
ちゃぶ台返し
ユーザーが求めているのは案件一覧ではなく,求人一覧なのでは?
インターン生の参加
スクラムマスターとしての振り返り
スクラムイベントの設計・進行
デイリースクラム
毎日10:00に集まって,約15分間で進捗の共有や課題の相談を行いました!
デイリースクラムは毎朝やるスクラムイベントなので,進め方やフォーマットは何回も試行錯誤を繰り返しました.
タスク管理・議事録・仕様整理も notion で行っていたため,リンクを貼って情報の共有がしやすいところが,個人的にはお気に入りポイントです.

スプリントレビュー
成果物のプロダクトオーナーに共有して,進捗の報告やデモを行いました!
このイベントはお祭りの要素を強くして,テンションもかなり上げて進行しましたね〜

スプリントレトロスペクティブ
スプリントを振り返る,このレトロスペクティブが最も紆余曲折があったかもしれません.最初は parabol というサービスを使ったですが途中で有料になって,頑張って1から設計し直したので..
議題を発散して,類似のものはまとめて,議論すべき議題に優先順位をつけて,そして議論を行う.
このフローを notion で作るのが結構大変でした.

反省点
進捗管理の委譲が上手くいかなかった
このプロジェクトを進めていく中で,スプリントレビューの直前でデモを行いたいのに,実はサーバーとフロントの結合ができない状態になっていたり,プロジェクト後半で各エピックにオーナーがついたが,進捗管理まで手が回っていなかったり,「あれ,これ終わってないんだ」ということが何回かありました.
このプロジェクトには明確に進捗を管理するロールがいなかったので,メンバーそれぞれで進捗を管理できる仕組みづくり必要だったのですが,上手くいかず,「メンバーそれぞれにエピックの進捗を管理してもらって,進捗が危ういなら,そのための行動をとってもらう」というところまで持っていくことはできませんでした.
上手くいかなかった理由としてはプロジェクト序盤と終盤で,やり方を変えなかったことにあるのかなぁと考えています,
プロジェクト序盤はやれることが少ないので,自分が全体の進捗をなんとなく見ていたのですが,プロジェクトが進行して考慮すべきことが増えると,自分の作業も増えて進捗を見られなくなるので,プロジェクトの段階によって明確にやり方を変える必要があるなぁと感じました.
スクラムマスターとしての動きがプロジェクト終盤は鈍かった
サーバーサイドの実装タスクが大量に溜まり,締切にも間に合わせないといけなかったので,終盤はスクラムマスターとしてスプリントレビューやレトロスペクティブの改善に手が回らなかったことは反省ですね・・
スクラムマスターとは別に,リードする立場のメンバーを増やすなり,スクラムマスターの役割を一部委譲することも必要だったかなと感じました.