スクラム導入から1年、うちの開発チームで本当に変わったこと — エンジニアリングマネージャーの振り返り

こんにちは。あるSaaSプロダクトの開発チームで、エンジニアリングマネージャーをしている者です。

「うちもスクラムを導入しよう」— こう決めたのがちょうど1年前。当時のチームは、ウォーターフォール的な進め方をしていて、リリースサイクルが4〜6ヶ月と長く、「作ってみたら想定と違った」という手戻りが慢性化していました。

そこからスクラム開発を導入して1年、振り返ってみると フレームワーク以上に、チームの中で何が変わったか が、正直な学びだったなと感じています。今回はWantedlyという場をお借りして、その1年の変化を素直に共有します。

これからスクラム導入を検討している方や、スクラムを回しているけれど手応えがない方の参考になれば嬉しいです。

なぜスクラムだったのか

正直に書くと、最初は「アジャイルっぽくやりたい」くらいの動機でした。

ただ、社内で議論を重ねる中で見えてきたのは、私たちが本当に困っていたのは "開発速度"ではなく、"軌道修正のタイミング" だったということ。「作ってからじゃないと気づけない」を減らすには、短いサイクルでレビュー・振り返りを回し続ける仕組みが必要でした。

スクラムはこの目的にフィットしていたので、スプリント2週間・PO＋SM＋開発5名の小さな体制からスタートしました。

1年で本当に変わった3つのこと

1. 「今週何が完成したか」を全員が言えるようになった

一番大きな変化はこれです。

導入前は、進捗を聞いても「〇〇に取り組んでいる」「大体半分くらい」といった曖昧な回答が中心でした。スプリントレビューで「動くもの」を毎回デモする文化ができてから、"完成したもの"を全員が同じ言葉で語れる ようになりました。

Definition of Done（完成の定義）を明文化したことも効いていて、「レビュー通過・テストカバレッジ・ドキュメント更新」までがセットで完成、という認識が揃ってからは、リリース後のトラブルも目に見えて減りました。

2. レトロスペクティブでチームが自分を語り始めた

これは想定していなかった変化です。

導入当初、レトロ（振り返り）は形だけになりがちで、「特に問題ないです」で終わる週もありました。それが変わったのは、スクラムマスターが 「小さな不満でも出していい場」 を意識的に作り始めてからです。

半年経った頃には、「このミーティング多くない？」「レビュー依頼が滞留してる」といった、チーム内の"言いにくいこと"がちゃんと言葉になるようになりました。心理的安全性という言葉、実感を持って理解できたのはこの時期です。

3. POが「決める人」に育った

これは組織側の変化でもあります。

最初、うちのPOは他業務との兼任で、意思決定が遅れがちでした。スプリントプランニングで優先順位が定まらず、開発チームが「じゃあこっちからやります」と勝手に判断する場面もありました。

半年ほどして、経営層と話し合ってPOの稼働を80%以上確保する体制に変えたところ、プロダクトの意思決定スピードが劇的に上がりました。「スクラムを回す」の前に、「POの時間を確保する」だった んですね。これは今後スクラム導入する方に一番伝えたいポイントです。

それでも難しかったこと

正直に書くと、うまくいったことだけではありません。

• 見積もりに時間をかけすぎた時期 があり、プランニングポーカーで1タスク15分議論するような事態も
• レビューにステークホルダーが来なくなった時期 もあり、フィードバックループが一時的に断絶
• 何より、イベントは回っているのに価値創出感が薄い"形だけスクラム" に片足を突っ込みかけたことも

これらは、スクラムの世界で Zombie Scrum と呼ばれる典型的な落とし穴だと、後で知りました。定期的にスクラムマスターが「うちは本当に価値を出せているか？」と問い直す場を作ることで、なんとか脱出できた気がします。

参考にした資料

今回の振り返りをまとめるにあたって、私たちがチームで読み込んだ資料があります。

スクラム開発の解説記事 は、3つの役割・5つのイベント・3つのアーティファクトといった基礎から、7つの失敗パターン、オフショア開発でスクラムを回す時のポイントまで、1本にまとまっていて、新メンバー向けのオンボーディング資料としても使いやすかったです。特に「Zombie Scrum」のところは、私たちが1年間もがいた話とほぼ同じことが書かれていて、「あるあるだったんだ…」と正直救われました。

書いている Kaopiz さんはラボ型開発 × スクラムの体制構築も支援されているようで、外部リソースを組み込みながらスクラムを回している方には、実装の下敷きになる情報が多いと思います。

チームで大事にしていること

最後に、この1年でうちの開発チームで新しく共有した価値観を書いておきます。

• 完成の定義を、最初から曖昧にしない
• 振り返りは、"問題ない週"を作らない（1つでもtryを出す）
• POの時間確保は、開発チームの生産性より先に整える

スクラムは、ドキュメント通りにイベントを並べれば回るものではなく、チームと組織の"関わり方"が伴って初めて機能する アプローチだと、この1年で実感しました。

同じような立ち上げに取り組まれている方の、何か1つでもヒントになれば幸いです。