こんにちは、BUYMA TRAVEL Webエンジニア の赤間です。
この記事はEnigmo Advent Calendar 2025の20日目の記事です。
この記事では、転職をきっかけに感じたことを基に、アジャイル／スクラムの基本と、現場で起きがちな"あるある"とその対策について紹介します。
軽く自己紹介になりますが、私は2025年8月に転職してきたエンジニアです。前職でもエンジニアとして開発を行なっており、時期によってはスクラムマスターの役割も担当していました。
その経験から、転職後に「これってアジャイルか？」と戸惑ったことがあり、同じように悩む人のヒントになればと思いこの記事を書いています。
1. はじめに: 同じ「アジャイル」なのに、転職したら別物だった
前職では「スクラム」を実践していました。1週間という短いスプリントで開発・スプリントレビュー・ふりかえりを繰り返し、要件定義も(プロジェクト毎に)持ち回りで実施していました。
ところが転職後、同じく「アジャイル」を実践する現場に入ったものの、運用はスプリントよりも「この機能をいつ出すか」というリリース単位が中心です。参加した当初、実装やリリーススピードは前より速いはずなのに、私自身はどこか噛み合わず、「これってアジャイルなのかな？」と戸惑いました。いま考えると、アジャイルの形が違うというより、最適化している対象が違ったのだと思います。
この記事では、まずアジャイル/スクラムの基本をできるだけわかりやすく整理します。そのうえで、転職前後の現場を例に「同じアジャイルでも会社 (チーム) でこう違う」を簡単に比較し、それぞれの特徴や転職を通して見つけたよくある課題(あるある)と解決策を、アジャイルのことを知らない人にも伝わる形でまとめていきます。
2. そもそもアジャイルとは
アジャイルは一言でいうと、変化を前提に「小さく作って試し、フィードバックを受け軌道修正する」開発の考え方です。
最初に要件を固めて、計画通りに作り切る (いわゆるウォーターフォール) と対比するとイメージしやすいと思います。
ここで大事なのは、朝会・夕会・カンバンのような手段そのものではなく、フィードバックを得て、次に反映するサイクルが回っているかです。
たとえば「作ったものを早めに見せる → 反応をもらう → 次の方針を変える」というループが速ければ速いほど、価値や計画のズレが小さいまま進行できます。
3. スクラムとは
スクラムは、アジャイルの考え方を現場でうまく回すための代表的なフレームワークです。
「アジャイル=考え方」だとすると、スクラムはそれを実践するために、役割・イベント (会議) ・成果物をセットで定義し、チームが迷いにくい形にしたもの、と考えるとわかりやすいです。
スクラムの用語
-
スプリント: 固定期間 (一般に1〜4週間) で区切られた開発サイクル
-
スプリントゴール: そのスプリントで達成したい目的 (「何のためにやるか」の軸)
-
プランニング: 次のスプリントで「何をどれだけやるか」をチームで決める
-
デイリースクラム: スプリントゴールに向けて、進捗確認と調整を行う毎日の短い打ち合わせ
-
スプリントレビュー: 出来上がった成果物を共有し、フィードバックをもらう場
-
レトロスペクティブ (ふりかえり) : やり方のカイゼンを話し合う場
重要: スクラムは儀式ではなく、検証とカイゼンを回す仕組み
スクラムは「イベントをこなすこと」が目的ではありません。
短い周期で 検査 (Inspect) = いま正しい方向に進んでいるかを確かめ、適応 (Adapt) = 必要ならやり方・優先順位・計画を変える、という検証と改善を回すための仕組みです。
つまり、スクラムの各イベントは全て「Inspect / Adapt」のためにあります。
スプリントで区切ることも、スプリントレビューで見せることも、ふりかえりをすることも、全て価値や計画のズレを小さくするためです。
4. 前職スクラムの特徴 (メリット・デメリット)
-
6人チーム/分業なし
-
-
+ 依存が減って、詰まっても助け合いやすい (柔軟に回る）
-
-
-
- 何でも屋になりやすく、社内での育成コストと属人化リスクが上がる
-
-
要件定義・見積もりが持ち回り
-
-
プロダクト理解が深まり、当事者意識が育つ
-
-
-
得意不得意の差が出やすく、ブレや認識差が起きることも
-
-
スプリント1週間/ふりかえり重視
-
-
カイゼンの回転が速く、失敗が小さく済む
-
-
-
追われやすく、レビュー品質が落ちると「忙しいだけ」になりがち
-
-
朝会夕会で進捗確認
-
-
見える化が効き、抱え込みや遅延を早く発見できる
-
-
-
運用次第で報告会・監視っぽくなり、心理的安全性を下げる可能性あり
-
5. 現職アジャイルの特徴 (メリット・デメリット)
-
エンジニア4人＋周辺職種は別チームで参加
-
-
必要な専門性が適切なタイミングで入り、品質が上がりやすい
-
-
-
意思決定や仕様の往復が増えると、スピードが落ちることがある
-
-
半分業 (フロント/サーバ/インフラ)
-
-
専門性が積み上がり、品質とスピードを出しやすい
-
-
-
ボトルネックが固定化すると、待ちが増えてリードタイムが伸びやすい
-
-
要件定義はCSが主導、デザイナーやエンジニアがブラッシュアップ
-
-
顧客の声が仕様の入口にあり、「作ったけど使われない」を減らしやすい
-
-
-
技術制約・実現方法の検討が遅れると、手戻りが増えることがある
-
-
スプリントが長期間
-
-
機能にフォーカスしやすく、リリース目的がブレにくい
-
-
-
フィードバックが遅れると、気づいた時にはズレが大きくなっている
-
-
毎日夕会/週1でふりかえり (乖離確認)
-
-
見える化が効き、抱え込みや遅延を早く発見できる
-
-
-
運用次第で報告会・監視っぽくなり、心理的安全性を下げる可能性あり
-
6. スクラムの「ズレやすいポイント」あるある
ここまでアジャイル/スクラムの概要と、前職・現職それぞれの特徴を書きました。
面白いのは、運用の形は違っていても、実際に現場でつまずきやすい「ズレやすいポイント」には共通点があったことです。
ここからは、スクラムを回すときに起きがちな"あるある"を整理していきます。
1) スプリントが長くなる/ズレ続ける
本来スプリントは固定期間で区切りますが、実際には意外とズレがちです。
祝日やメンバーの休み、突発対応、大きなリリースが重なると、「期間は決めているのに、結局終わらない」という問題が発生します。
この状態が続くと、スプリントレビューやふりかえりのタイミングが曖昧になってしまいます。
2) どうしても納期が先に確定してしまう
色々な要因で、納期が先に決まること自体は珍しくないと思います。問題は、納期が固定なのにスコープも固定になっていることです。この場合、現場がデスマーチになりやすいです。
3) 会議 (夕会) はあるが、スプリントレビューで顧客フィードバックが薄い
夕会などで進捗は把握できていても、スプリントレビューで"価値"を確かめられないと、やっていることはただの「進捗管理」になってしまいます。
その結果、予定通り作ったのに、想定していた価値が出ないというズレが発生しやすくなります。
4) ふりかえりはするが、カイゼンが実験になっていない
ふりかえり自体はやっていても、内容が「反省会」になってしまう。
ふりかえりの狙いは、誰かを責めることではなく、仕組みを少しずつカイゼンすることです。
5) 分業で詰まりが固定化する
分業は専門性を伸ばしやすい一方で、特定領域にタスクが集中すると、そこがボトルネックになってしまいます。
スクラムでは、個人の稼働率よりも、チームとしてのリードタイムが重要になるため、ここがズレの原因になりがちです。
7. 「じゃあどうすれば？」具体的なカイゼン案
では、こうした"あるある"はどう解消すればいいでしょうか。
ここからは、私なりに考えたカイゼン案を紹介します。前職、現職で実際にチームで議論して試した工夫も、一部取り入れています。
スクラムの型に無理やり戻すことが目的ではありません。Inspect / Adapt (検査と適応) がきちんと回る状態に近づけることが目的です。
1) スプリントが長くなる/ズレ続ける
スプリントの価値は"期限内に全部終える"ではなく、"短い周期での検証とカイゼン"にある
- 祝日が多い週は最初からタスク数を減らす (期間は固定)
- どうしても溢れるなら、「終わらせる」ではなくスプリントを中止する
2) どうしても納期が先に確定してしまう
納期固定を成立させる条件は「変更できる何か (スコープ/品質/順序) 」があること
- Must/Should/Could で削れる部分を先に決めておく
- 「この日までにここまで」ではなく「この日までに価値が出る最小形」を合意する
3) 会議 (夕会) はあるが、スプリントレビューで顧客フィードバックが薄い
フィードバックが薄いと、"作ったものが刺さらない"がよく起きる
- スプリントレビューは「説明」より「動くもの」を中心にする
- 参加者が広げづらいなら、CSや営業から顧客の反応を持ち込むだけでもOK
4) ふりかえりはするが、カイゼンが実験になっていない
ふりかえりは反省会ではなく、カイゼンのA/Bテストに近い
- 毎回、カイゼンアクションは1つ程度に絞る
- 次回のふりかえりで「やったかどうか、効いたかどうか」を確認し、効かなければそのカイゼンはやめる
- 見積もりが外れた原因は「前提が変わった」「分割が大きい」など仕組み側として考える
5) 分業で詰まりが固定化する
個人最適より、チームのリードタイム最適を狙う
- 着手しすぎをやめる
- 詰まりやすい領域は、スプリントレビュー待ちを減らすためにペア/モブを試す
8. 今後の展望
転職直後に「同じアジャイルなのに、なんだか噛み合わない」と感じたのは、今思えば当然でした。
前職で体験していたのは、短いスプリントでレビューとふりかえりを回し続ける"スクラム寄りのアジャイル"。一方で現職は、機能リリースを軸に、CSや周辺職種の知見も取り込みながら進める"プロダクト寄りのアジャイル"です。言葉は同じでも、狙っている最適解が少し違っていたんだと思います。
アジャイルやスクラムに"唯一の正解"はありません。会社のフェーズ、プロダクトの性質、チームの人数やスキルで、うまく回る形は変わります。大事なのは「どの型が正しいか」を決めることではなく、いまの自分たちにとって必要なカイゼンを見つけて、小さく試して、調整し続けること。そのプロセス自体が、アジャイルの面白さだと感じています。
今後も現職の強み (専門性・顧客起点・リリース志向) を活かしながら、ズレが大きくなるポイントを修正していきます。
