はじめに
こんにちは。UPSIDER でカードチームに所属している Nagai Takumi です。
私たちのチームは、既存サービスの運用と複数の新規開発を並行しながら、限られた人数で ETC カード機能を開発していました。ちょうどこのころ、チームリーダーが育休に入りました。
私は当初、その穴を埋めるために進捗を管理し、指示を出そうとしました。しかし、管理を強めるほど判断が自分に集まり、メンバーの自律性を損なうことに気づきました。
そこで、独自の管理方法を増やすのではなく、チームとともにスクラムの基本へ立ち返ることにしました。
本記事では、スクラムを立て直すために行った実践を、「課題・実践内容・効果」の順に紹介します。
背景と制約
プロジェクトの前提
UPSIDER はこれまで法人カードを提供してきましたが、ETC カードは扱っていませんでした。これを新たに提供することになったのが、今回のプロジェクトです。
ETC カード機能は、カードの発行から利用明細の反映までの一連の流れで、外部 2 社のシステムとの結合が前提になります。自チームだけでは仕様や試験環境をコントロールできない領域が広く、手戻りのコストが大きいプロジェクトでした。
チームの実態
チームの在籍は 10 名前後。そのうち、ETC カード機能の開発に並走できたのは実質 3〜4 名でした。運用や他プロジェクトを止められないなかで、ETC に割ける人数は限られていたのです。
当時は、外部システムへの依存、ETC カード開発に割ける人数の少なさ、リーダーの不在という三つの制約が重なっていました。
その結果、期待とのズレを早期に検知できない、割り込み時の優先順位や担当が見えない、判断や調整が一部のメンバーに集中する、といった問題が起きていました。
なぜ基本に立ち返ることにしたか
例外や割り込みが多い現場ほど、判断の基準となる共通言語が必要です。私たちに足りなかったのは、まさにこれでした。
ふりかえりで出てきたのは、「アジャイルっぽい何か」になっているという自覚でした。デイリースクラムやスプリントレビューは実施していましたが、それぞれが何のための場なのかを言葉にできる人は少なくなっていました。
問題は、例外そのものではありません。忙しくなれば「今回は確認を飛ばす」といった例外が増えるのは自然なことです。まずいのは、共通の判断基準がないまま例外を重ねることでした。一つひとつは合理的に見えても、全体として進め方はつぎはぎになり、判断できる人が特定の誰かへ偏っていきます。
だからこそ、守破離の「守」に立ち返ることを選びました。制約が強い状況では、この偏りが致命的になります。判断できる 1 人が抜けた瞬間に、チームが止まってしまうからです。
戻る先は、スクラムの原則そのものでした。とりわけ、経験主義を支える 3 本柱です。
- 透明性 — 重要なことを隠さず、全員が同じものを見られる状態にする。
- 検査 — 作っているものや進め方を、こまめに確かめる。
- 適応 — ずれに気づいたら、できるだけ早くやり方を変える。
新しい手法を足したのではなく、スクラムが元から持っている原則を、日々の動きへ落とし直しただけです。
目指したゴールは一つです。全員が自律的に判断できる状態を作ることでした。
スクラムをどう立て直したか
ここでやったのは、背景で挙げた 3 本柱（透明性・検査・適応）に立ち返ることです。まず 1 つの施策で火をつけ、次に形だけになっていたスクラムの構成要素やイベントを見直し、最後に自分たちの制約に合わせて足りないところを補いました。
朝のライトニングトーク（起点）
課題
背景で触れたとおり、イベントの目的を言葉にできない状態でした。加えて、代役として管理しようとしていた私自身が、チームの空気を「指示待ち」に固めかけていました。ここで難しいのは、最初の一歩です。ルールを作って配っても、「決められたこと」が増えるだけで、判断の基準は共有されません。まず、私を含めた全員の認識をそろえ直す必要がありました。
実践内容
朝の時間を使ったライトニングトークを、2 回実施しました。毎日の習慣ではなく、チームの認識をそろえるための単発の場です。
1 回目の内容は、チームの再定義でした。「歯車であることをやめ、生命体になろう」という問いかけです。決められた動きしかできず、一箇所が壊れれば全体が止まる「歯車」ではなく、自ら形を変え、欠損があれば仲間が補って再生する「生命体」を目指す。そういう絵を、チームで共有しました。
あわせて、私自身の立ち位置も宣言しました。リーダーの代役として管理する立場をやめ、障壁を取り除く側に回る——その手段として、スクラムを本気で実践しよう、と。管理する人がいなくなるのではなく、全員が自ら律するチームへ移る、という意思表示です。
2 回目のライトニングトークでは、スクラムガイドにおける、3 本柱と 5 つの価値基準、スクラムイベントの意味について改めて説明しました。
効果
この 2 回をきっかけに、スクラムイベントの目的を問い直す動きや、チーム編成の見直しといった議論が、チーム主導で始まりました。
重要なのは、施策を上から配ったわけではないという点です。きっかけは私の宣言でしたが、以降の実践はチーム自身の議論から生まれました。たとえばスプリントレビューは、リリースした本人と実装レビュアーしか中身を知らない場から、チーム全員がリリース物を把握できる場へ変わりました。ほかの変化は、このあとの各実践で紹介します。
スプリントゴールと PBI の言語化
課題
そもそも、一言で表せるスプリントゴールがありませんでした。あったのは「このチケットを終わらせる」というタスクの羅列です。これでは達成の基準が曖昧になり、各自で優先順位をつけられません。
実践内容
スプリントゴールは、そのスプリントを通じて実現したい一つのアウトカムとして言語化しました。各 PBI については、そのゴールにどう寄与するのか、ユーザーが何をできるようになるのかを書くようにしました。
判断に迷わないよう、PBI の良い例と悪い例をセットで共有しました。
- ✕ 作業の言い換え: 「ETC カード対応」「請求画面の修正」
- ✓ 届ける価値: 「カード保有者が、ETC カードの発行リクエストを通知で把握できる」「一般ユーザーが、自分の保有カードの ETC 明細を CSV で出力できる」
書き出しを「ユーザー」の主語にすると、完了時点で何ができるようになるのかが明確になります。優先順位も、この基準で判断できるようになりました。
ただ、複数のアウトカムが混じるスプリントや、リファインメントが終わり切らないまま着手する場合には、ゴールを一言で表せず、PBI 側にアウトカムを書くこともあります。ここはいまも整えている途中です。
効果
スプリントゴールが「誰の、どんな価値か」で書かれるようになり、割り込みが入ったときも、各自が「それはいまゴールに近づける仕事か」で優先順位を判断できるようになりました。ゴールの言葉が、そのまま日々の判断基準になっています。
この取り組みに関連して、チームで品質を作った挑戦を QA エンジニアの Tera さんが別の記事に詳しく書いているので、ぜひそちらもご覧ください。
スプリントプランニング
課題
以前のプランニングは、PdM と QA エンジニア、そして私の 3 人でリファインしたタスクを割り当てる場になっていました。つまり毎サイクル、この 3 人で ETC を含むカードチーム全体のタスクをほぼ完璧に把握し、誰に振るかまで決めきらなければなりません。負荷が一部に集中するうえ、割り当てられる側の主体性も生まれにくい状態でした。
実践内容
ETC の開発は、カードチームを ETC 担当と守り担当の 2 つのサブチームに分けて進めていました。そのうえで、3 人で割り当てる形をやめ、プランニングはサブチーム全員で行うようにしました。
見積もりは、プランニングポーカーを使いました。参加者が「せーの」で同時に出す、あのやり方です。同時に出すと、コスト感のズレや前提の食い違いがその場で表に出ます。あわせて、その時点で判明している不明点も洗い出しました。「まだ分かっていないこと」を早いうちに並べておくためです。
もう一つの工夫は、PBI に担当者（assignee）をあえて固定しなかったことです。手が空いた人から、その時いちばん重要な PBI を取る形にしました。
効果
担当を固定しなくても、計画は自走しました。鍵になったのは、次に紹介するデイリースクラムです。持ち回りのファシリテーターが「スプリントゴールを達成できそうか」を毎日検査したことで、誰かの指示を待つのではなく、メンバー自身がタスクの状況を相談し、進めていきました。
デイリースクラム — 付箋とファシリテーター輪番
課題
人数が限られ、割り込みも多いと、その日に誰が何をやるのかが互いに見えなくなります。加えて、その日の段取りを「これでいいのか」と判断する役割が、当時代役をしていた私のような特定の人に偏りがちでした。
実践内容
デイリースクラムに、チームから出てきた 2 つのルールを持ち込みました。
1 つは、その日にやることを各自が付箋に書き出すこと。頭の中にあった予定が場に並び、誰が何を持っているかが一目で見えるようになりました。
もう 1 つは、ファシリテーターを毎日輪番で入れ替えること。進行役を回すことで、進め方を全員が自分ごととして考えるようになりました。
大事にしたのは、付箋の共有そのものを目的にしないことです。スプリントゴールを達成するうえで今日の分担が妥当か、詰まりや偏りがないかを全員で確かめ、必要ならその場で組み替えました。単なる進捗報告の場にはしない、という意識です。
効果
その日の計画が場に並ぶことで、進め方の判断が特定の人へ集中しなくなりました。ファシリテーターを全員が担うことで、「回してもらう会議」から「自分たちで回す会議」へ変わりました。
レトロスペクティブの磨き込み
課題
ふりかえりで改善案は数多く挙がるのに、次のスプリントで実際に変わることは多くありませんでした。案の出しっぱなしで終わり、場そのものも少しずつ形だけのものになりかけていました。
実践内容
やり方は、あえて固定していません。むしろ毎回いろいろな形式を試し、自分たちに合う形を探り続けています。試すこと自体が、検査と適応の練習になるからです。
そのなかで、効果が大きく、続けているものが 2 つあります。
1 つは、最後に必ず「次のスプリントを変えるための 1 アクション」を 1 つだけ決めること。たくさん挙げるより、確実に 1 つ実行することを優先しました。
もう 1 つは、冒頭の 10 分を、メンバーが互いに感謝を伝え合う自由発言の時間にあてること。改善の議論へ入る前に、安心して発言できる空気をつくる狙いで、これはチーム内でも好評でした。
効果
前回の「1 アクション」が次のふりかえりで追跡されるため、改善が単発で終わりにくくなりました。
スプリント中間での進捗共有
課題
作っているものと、チームやレビュアーが期待しているもののズレが、スプリントレビューまで表面化しない状態でした。外部結合が絡む領域では特に、完成間際まで認識の食い違いに気づけません。レビューで初めてズレが判明すると、その手戻りは次サイクルの追加課題として持ち越されます。
実践内容
スプリント中盤以降、意味のある動きを見せられる状態になった時点で、動いているものをチームで共有する場を設けました。完成を待たずに見せることで、認識のズレに気づくタイミングを前倒しする狙いです。完璧なデモである必要はありません。動くところまでを見せ、期待とずれていないかを確かめます。
効果
中間共有で認識のズレを前もって解消でき、スプリントレビューの位置づけも変わりました。完成物を初めて見せて認識を合わせる場ではなく、得られた成果を確かめ、その先の取り組みを話し合う場になりました。レビューの場で初めて大きなズレが見つかり、手戻りを次サイクルへ持ち越す、ということも減らせました。
デイリー直後のブロッカー解消枠
課題
ブロッカーは出ても解消が後回しになりがちで、その日はそこで止まってしまいます。
実践内容
デイリー直後の 1 時間を「ブロッカー解消枠」として常に確保しました。デイリーでファシリテーターが見つけたブロッカーについて、必要なメンバーをその場で集めて片づけます。解消すべきことがなければ、枠はそのまま解散します。
効果
ブロッカーが、その日のうちに動き出します。たとえば請求画面の表示仕様で判断に迷ったときは、ファシリテーターが PdM と QA エンジニアを呼び、その場ですり合わせの場を用意しました。リーダーが不在でも、こうした判断はメンバーの手で前に進みました。
立て直して得られたもの
個々の実践がかみ合い、チームの動き方が変わりました。認識のズレを早い段階で見つけられるようになり、優先順位や担当を、チームの中で調整できるようになりました。
そして、運用と新規開発を止めることなく、ETC カード機能をパブリックリリースまで届けきりました。動いているサービスの手を緩めずに、もう一つの大きな機能をやり切る。これが、今回の取り組みでいちばん誇れる成果です。
この取り組みが機能した背景
同じやり方をそのまま持ち込めば機能する、とは考えていません。振り返ると、いくつかの前提がそろっていました。
- スクラムの目的を学び直す土台があった — 「守」に戻る先を、全員で共有できました。
- 進め方をチーム自身が決められた — ルールを上から配るのではなく、変えることをチームが選びました。
- 役割を越えて助け合える信頼があった — 「これは自分の担当ではない」で止まらず、必要なら誰かが拾う。この信頼関係が、仕組みを実際に動かしました。
- 小さく試せた — すべてを同時に入れたわけではありません。1 つずつ試し、続いたものを残しました。
正直に言えば、なかでもメンバー間の信頼がいちばん効いたと思っています。今回の実践は、この土台があったからこそ回りました。実践は、もともとある力を引き出す装置であって、ゼロから生み出す魔法ではありません。
次の課題と展望
うまくいったことばかりではありません。現時点で残っている、大きな課題を挙げます。
意思決定の移譲とドライブのバランス
チームへのオーナーシップの移譲は進みました。一方で、リリース期日を強くドライブする役割が薄くなったという副作用がありました。
ここをどう設計するかは、まだ答えが出ていません。特定の 1 人に判断を戻せば、せっかく分散させた意思決定が、また一点に集まってしまいます。いま考えているのは、期日とリスクを継続的に可視化し、必要な判断やエスカレーションを促す役割を、チームの中で明確にすることです。
決めた改善アクションをやり切ること
レトロスペクティブでは、次のスプリントを変えるための 1 アクションを 1 つだけ決めるようにしています。ただ、それを決め切るには時間が足りないことも多く、議論の途中で時間切れになる回もありました。さらに、日々の開発や運用に追われ、決めたアクションをやり切れないサイクルも何度かありました。回し方は磨けてきましたが、やり切る余力をどう確保するかは、いまも課題です。
フロー効率を高める仕組みづくり
スクラムのイベントは、目的に沿って整理できました。次は、複数のタスクをフロー効率高くこなすことに挑んでいきたいと考えています。
とくにビジネスの要求へ応え続けるうえで鍵になるのが、緊急かつ重要なタスクが重なる場面です。コンテキストスイッチの少ない進め方を磨くほど、要求にもっと速く応えていけるはずで、ここはまだまだ伸ばせる余地があります。
おわりに
自律したチームをつくるために必要だったのは、管理をなくすことではなく、誰もが判断できる基準と、ズレを早く見つけられる仕組みを整えることでした。
限られた人数で、止められない運用を抱えながら挑戦しているチームに、この記事の実践が一つでも届けばうれしいです。最後まで読んでいただき、ありがとうございました。
We Are Hiring
UPSIDER Engineering Deckはこちら📣
