この記事はAnthrotech Advent Calendar 2025の21日目の記事です。
昨日は烏龍さんの記事でした。リアルタイム通信 = WebSocketのイメージが強く、SSEについて初めて知れました。EventSourceはJavaScript標準でHTTPのまま使えるというのも使い勝手がよさそうですね。
今日の記事では、私が新卒当時にスクラム導入に挑戦した時の失敗談と、離れてから気づいたスクラムの本質部分についてご紹介します。
よくある予防線ですが、スクラムを貶したり前職批判をするような意図はまったくなく、すべて良い経験だったと考えています。
スクラムとは？
スクラムとは、プロダクト開発チームにおいてチームが自立して効率的に仕事を進めるためのフレームワークです。アジャイル開発の文脈で聞いたことがある人も多いかもしれません。
スクラムガイドでは、次の3つが基本原則として定義されており、これを達成するためのイベント(≒ミーティング)がいくつか存在します。
透明性: 誰もが作業や進捗・問題点を見えるようにすること
検査: 成果物を点検・確認すること
適応: やり方を調整・改善すること
詳しくはぜひ検索してWeb記事を見てみてください。
スクラムどうだったかな
私は新卒から2年ほど、スクラムを自分が参加しているチームに導入しようとしていました。当時はコミュニティに参加したり本を読んだり、楽しい瞬間はいくつかあったものの、結果的にうまくいったとは言えないまま終わってしまいました。
年月が経った今でも、スクラムを積極的に学びなおそうとは思わない一方、熱心に活動していた新卒時代になぜうまくいかなかったのか、その理由がだんだんわかってきました。
新卒時代にうまくいかなかったチーム
さて、今考えると、当時スクラムを導入しようとしていたチームは自分の持っているスキルでは難易度が高かったのかなと思います。
タイミングと状態
当時のチームは、いくつかのビジネス的な要因が重なった結果、(自分自身も含め)プロダクトへの関心がそれほど高い状態ではありませんでした。
プロダクト自体もよく言えば安定しており、運用中心。チームの優先度として粛々と回していくことが求められていました。これにより、スクラムの最終的な目標である「プロダクトを通した価値の提供」そのものの価値が相対的に低くなっている状態でした。
チームを動かす説得力
さらにうまくいかなかった原因として、私自身が新卒そこそこの人間であったというのも挙げられます。「スクラムやってみていいよ」と言ってくれるような現場でしたが、それでも信用や説得力は人に思いを伝えるためには重要です。
スクラムへの理解が少なかったのも原因の一つです。後述しますが、当時はフレームワークに沿ってイベントをこなしていけばより良くなっていくと単純に考えていて、イベントがどのような意味を持つのかをチームに説明することがうまくできていませんでした。
成果とエゴ
当時の私の態度にも問題があります。新卒だった私は「スクラムを導入して、チームが提供できる価値を増やすことができた」「短いサイクルで問題が改善できるようになった」といったような、目に見える成果を得ることを急いでいました。スクラムはチームのためのものですから、基本的にこのような個人的な目標とは相性が悪いものです。
結果として、チームメンバーから見るスクラムイベントは「新卒が謎のミーティングを設定している、よくわからないが付き合ってやるか」くらいの温度感に冷えこんでしまい、スクラムの文化がチームに浸透しなかったのです。
私は自身のスキルのなさを自覚しスクラムの道からしばらく離れることを選びました。
自然とスクラムで求められていることができるチーム
スクラムをやめて3年ほど。今私は場所も仕事のジャンルも異なるチームに所属しています。今はスクラムを導入しようとは思いませんが、それはネガティブな感情ではなく、目指すべき状態がすでにできているからなのだなと最近気が付きました。
スクラムで作りたいのは仕組みではなく状態
今のチームはスクラムを導入していませんが、情報は適切に共有されますし、問題は改善しようとする動きが発生します。スクラムがこの状態を目指すための道具なのであれば、すでに状態が出来上がっています。
スクラムが求めているのは、フレームワークとしてのイベントをただ回すことではなく、透明性・検査・適応が自然に起こるチームの状態なのです。
理想の状態を想像しながらフレームワークを使う
状態がゴールであれば、フレームワークは道具になります。
スクラムを導入してどのような状態にチームをしたいかという理想の状態を想像するのが大切です。言葉で書くと当たり前のように感じますが、新卒当時の私には欠けていた視点です。
理想の状態を先に描いて、それを実現することをまず意識する。その中で、スクラムの学びを試してみるというのが大切だったのかもしれません。
スクラムを学んで得られたこと
では、スクラムを学ぶことが完全に無駄だったのかというと、そんなことはありません。正直に言えば、私はスクラムのほとんどを忘れてしまっていますが、スクラムの文化に影響されて意識し、今でも実践し続けていることがいくつかあります。
例えば、スクラムで定義されているイベントの多くは「話し合う」時間です。プロダクトゴールや進捗、問題について頻繁に話し合います。
今振り返ると、スクラムのイベントは「進捗管理のための会議」ではなく「認識のずれを小さいうちに回収する時間」を、話題と間隔が決まった型として提供するアプローチだったように思えます。
スクラムの型の外に出た今でも、認識のずれを解消するための対話は大切です。対話をしない限り、何が価値を提供して何が問題なのかという前提を共有することができないからです。
上記の対話は一例ですが、スクラムのエッセンスはチームで仕事をスムーズに進めるための基礎部分として働くものが多くあります。
強力なコミュニティ
そして、当時楽しく学びを続けられた要因の一つにRegional Scrum Gathering Tokyo(以下RSGT)というカンファレンスの存在があります。
RSGTは参加者同士の交流が非常に盛んで、登壇する・しないに関わらず多くのスクラム実践者と話す機会に恵まれます。今振り返っても、一日を通して話す機会という点では、RSGTの右に出る技術コミュニティはありません。
ほかの会社のチームが問題をどう解決しているのかを話しあうことができるのも、ほかのコミュニティにはない面白いポイントです。多くの場合相手はスクラムの経験者ですから、ふりかえりについて話すのは慣れている人が多いのも初学者にはありがたいところです。
興味がある方はぜひ参加してみてください。スクラムの知識が無くても十分楽しめますよ。
おわりに
いかがでしたでしょうか。一人のエンジニアの経験談として読者の皆様の役に立ってもらえると幸いです。今は少しだけ冷静にスクラムのことを見ていますが、それでも私が学んでいた二年間はとても充実していたものでした。
チームに合うかどうか、今の状況はどうか。そこは人それぞれだと思いますが、エンジニアでも非エンジニアでもスクラムの要素は学びになり、働き方につながることがあるんじゃないかなと思います。
それでは！