はじめに

私は、人事システムの開発に従事している開発者です。
2025年9月から新機能開発するにあたり、私合わせた4名のメンバーで開発することになりました。
その際、上司の勧めもありスクラムを導入することを決定。
私が主導する立場で開発を進めることになりました。
過去にスクラムを運用している部署に所属していた経験はありましたが、あくまで「なんとなくの理解」がある程度。
本記事では、そんな状態でスクラムを導入したことによる失敗談と、そこから研修を経て得た学び・変化について、振り返りを込めて共有します。

この記事の対象者

スクラムの知識が浅い状態で、スクラムマスターや推進役を任された方
チーム開発において「なぜかうまくいかない」と悩んでいる方
認定スクラムマスター（CSM）研修で得られる視点を知りたい方

そもそもスクラムって？

スクラム実践者のバイブルとして、スクラムガイドが存在します。
スクラムの提唱者であるKen SchwaberとJeff Sutherlandによって2010年に最初のバージョンが公開され、現在「スクラムガイド2020」が最新版で、日本語を含む多くの言語に翻訳されています。
ガイドの中で、スクラムの定義は以下と説明されています。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

引用：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

ウォーターフォール・モデルみたいに最初に決めた計画通り進めるのではなく、目的地（プロダクトゴール）は決まっているが柔軟に変更して、価値を生み出すところが大きな違いだと認識しています。

スクラム知識がほとんどない私がスクラムを運用する

初期のチーム状況

私以外の3名は、新機能開発以外の業務をメインで担当している状況でした。
そのため、私以外の開発者は部分的にしか開発に関われず、さらにそのうち2名は今回のサブシステムに関するドメイン知識が少ない状態でした。

この状況下で、私の知識不足も相まって開発はスムーズに進みませんでした。

発生した問題

当時の問題を振り返ると、以下のような状況に陥っていました。

個人の観点（私自身）

当初はスクラムマスター専任の予定が、結果的にプロダクトオーナーや開発者も兼務してしまった
「メンバー全員の合意」を意識し過ぎた結果、会議で無駄な時間を費やしてしまった
スクラムへの理解が浅いため、メンバーから意見をもらっても「そうですね」と同意することしかできず、指針を示せなかった

チームの観点

他メンバーが新規機能開発の集中できず、実質的に「私がメインで開発している」状況になってしまっていた
スクラム運用が「効率重視」になり、本来最も重要であるはずのレトロスペクティブ（振り返り）を省略してしまった
プロダクトバックログアイテム（PBI）を起票しても、概要や粒度が不明瞭で、メンバーが着手しづらい状態になっていた

その結果

スクラムのメリットである「チームの相乗効果」や、状況に応じた「柔軟な軌道修正」が、まったくできていない状態でした。
形だけスクラム用語を使っているものの、実態は「実質、ひとりで抱え込んでしまっている状態」という悲しい状況になってしまいました。

このままではだめだ

本を読んで独学で勉強してはいたものの、断片的な理解に留まっていました。
そのため、スクラムの原則やベストプラクティスを学ぶために、
10月29日から3日間、株式会社アトラクタ主催の認定スクラムマスター研修を受講しました。

受講して

体系的なことを知識として身につけられこともそうですが、
何よりチームとして成果をだすために、何をするべきかという視点で考えられるようになったのが大きかったです。

その後どうしたか

研修で学んだからといって、「明日からやり方を全部変えます！」と急に現場へ持ち込まないようにしました。
急激な変化はチームの反発を招く、という点も研修での学びの一つだったからです。

そのため、まずは以下の4点を意識して小さく変化を起こしました。

言葉遣いの変更
- 「私がやります」ではなく、「チームでどう解決するか？」「チームとしてどう取り組むか？」という主語に変えて問いかけるようにしました
委譲と信頼
- 開発者自身にバックログアイテムを任せ、こちらから不用意に口出し（マイクロマネジメント）をしないように気をつけました
積極的な声掛け
メンバーが不明点や課題をひとりで抱え込んでしまわないよう、私から積極的に「困っていることはないか？」と聞きに行ったり、声をかけるように変えました
プロダクトオーナーとの連携強化
プロダクトオーナーへ毎週1回、成果物を確認してもらう時間を設け、認識のズレによる大きな手戻りを防ぐようにしました

最終的な結果

メンバーがある程度スクラムの前提知識を持っていたこと、そして何より前向きに取り組んでくれたおかげで、チームは徐々に機能し始めました。

当初予定していた機能を「すべて」出荷することはできませんでしたが、「価値の高い、最低限必要な機能」を出荷することができました。
すべてを作りきることが目的ではなく、価値を届けることが目的であると考えれば、これはスクラムとして一つの成功だったと感じています。

おわりに

知識不足や空回りの失敗もありましたが、認定スクラムマスター研修での学びと、チームメンバーの協力のおかげで、期限内に価値ある機能を届けることができました。

スクラムに「完璧な正解」はありませんが、「昨日より今日、チームが良くなっているか？」を問い続けることが、スクラムマスターとしての第一歩だと感じています。
まだまだ道半ばですが、これからもチームと共に「検査」と「適応」を繰り返していきたいと思います。

最後まで読んでいただき、ありがとうございました！