みなさん初めまして！清水翔太（@_smzst）と申します。普段はソフトウェアエンジニアとして、調剤薬局のDXを推進する「Musubi AI在庫管理」というプロダクトの開発に携わっています。
7/19に行われたスクラムフェス大阪2025で「スプリントゴール未達症候群に送る処方箋」というテーマで登壇させていただきました。以前参加したスクラムフェス新潟2025で刺激を受け、今回が初めてのプロポーザル、そして初めての登壇でした。
この記事の目的は登壇内容の紹介とフォローアップです。ぜひ資料と合わせてお読みください！また、気になるセクションだけ読んでいただくでもまったく問題ありません。
目次:
- そもそもの動機
- 発表の概要
- 拾いきれなかった疑問について
- Googleスライドを全画面表示して共有しながらスピーカーノートを見る方法
- 初登壇を終えて、そしてこれから登壇を目指すあなたへ
- 最後に
そもそもの動機
今回このテーマを選んだのには、明確なきっかけがありました。
スクラムフェス新潟2025に参加した際、ブースで他社のエンジニアの方々とお話しする機会がありました。その中で、「リファインメントがなかなかうまくいかない」「リモート環境で緊密なコミュニケーションを取るのが難しい」といったお悩みを聞き、ハッとさせられました。それは、まさに私たちのチームが悩み、試行錯誤しながら乗り越えてきた課題そのものだったからです。
ひょっとすると、私たちのチームの具体的な取り組みが、同じように悩んでいる方々のヒントになるかもしれない。需要があるのかもしれない…！
この出来事が背中を押してくれ、物語としてまとめてみようと思い立ちプロポーザルを出すことを決意しました。
また、私たちのチームは日頃から様々なトライを重ねており、私自身、学びの多いこのチームで働けていることに常々感謝しています。その感謝の気持ちを込めて、チームの取り組みを一つの物語として形にしたい、という想いもありました。
発表の概要
私たちのチームを蝕んでいた「病」とその正体
みなさんのチームでは、こんな「症状」に心当たりはないでしょうか？
- 目的意識の漂流: スプリントゴールがチケットの単なる要約になったり、何のために頑張っているか分からなくなる。
- 仕事の停滞: リファインメントが迷走したり、バーンダウンチャートが燃え尽きない。
- チームの消耗: 特定の人に仕事が集中したり、コンテキストスイッチで疲弊する。
私たちのチームは、まさにこれらの症状に悩まされていました。そして分析を進めると、これらの症状はすべて「属人化」と「フロー管理不全」という2つの根本原因から生じており、最終的に「スプリントゴール未達」という一つの結果に繋がっていることが分かりました。
これら根本原因に対処するために私たちのチームが実践したのが「Epic担当制」「情報共有文化」「1 WIP制限」という3つの処方箋です。これらの処方箋は、それぞれが異なる観点でスプリント運営を支える要素です。これらが互いに補完し合うことで責任の明確化と属人化防止、集中と柔軟性、透明性と判断力を同時に成立させるバランスの取れた仕組みになります。
| 要素 | 主な役割 | 潜在的な弱点 | 他の要素による補完 |
|---|---|---|---|
| Epic担当制 | 仕様の明確化と仮説検証の設計を一貫して担う | 属人化や情報の偏在 | 情報共有文化が補完 |
| 情報共有文化 | 属人化防止とチームの認識合わせ | 起点がないと情報が発散・形骸化する | Epic担当制が起点となり背景や設計を共有することでチームの知識と意思決定の健全性向上 |
| 1 WIP制限 | 集中と完了重視によるフロー効率の向上 | 作業の遅延リスク・計画の柔軟性の低下 | Epic担当制による見通しのよい設計 |
これら3つの処方箋を通じて以下のような課題をチームは乗り越えます。
- 属人化の解消: 各Epicごとに担当者をローテーションしながら割り当てる「Epic担当制」により責任を明確にし、「情報共有文化」で知識の偏りを防ぐことでチームの属人化を解消
- フローの改善: 「1 WIP 制限は結果である」という考えに基づき、チケットの細分化や依存関係の可視化によってチームの流れを改善
- 目的意識の醸成: スプリントゴールを「価値仮説の観測点」と定義し、チームを「タスクの作業員」から「価値の設計者」へと変革
私たちのチームはどのようにして乗り越えたのか？そして乗り越えた先にチームを待っていたものとは？…その答えをぜひ登壇資料の中で見つけてください！
拾いきれなかった疑問について
登壇を聞いてくださった方・スライドを見てくださった方の中には以下のような疑問をお持ちの方もいらっしゃるのではないでしょうか？その疑問についてこの場でお答えいたします。
- Epic担当者がスクラムのPOの役割と重なっているが、POは何をやっているの？
- 全体マップやロードマップは誰が最初に作成し、誰がメンテナンスするの？
- スプリントゴールはどのようなテンプレートを用いているの？
- 常時モブワークはどうやって実現したの？
- Gatherってなに？
- どんなチーム構成？
もしこれ以外にも疑問が浮かぶようでしたら、SNSやどこかのコミュニティでぜひ議論させてください！
Epic担当者がスクラムのPOの役割と重なっているが、POは何をやっているの？
私たちのチームには、スクラムで定義される単一のプロダクトオーナー（PO）という役割は存在しません。
POが担う責務を、プロダクトの価値に責任を持つPdM、顧客体験の設計に責任を持つデザイナー、そして仕様のオーナーであるエンジニアが三位一体で連携し、分担しています。
この体制の強みは、特定の誰かが仕様を決定するのを待つ、といった状況に陥りにくい点です。PdMが定義した事業課題（Why）を元に、デザイナーが具体的な顧客体験（What）を設計し、それをエンジニアが持続可能な仕様（How）に落とし込んで実装します。それぞれの専門家が自律的に動き、合意形成を行うことで、開発プロセスが円滑に進みます。
| 観点 | PdM | デザイナー | エンジニア |
|---|---|---|---|
| 責任範囲 | プロダクト全体の事業価値・将来価値 | 顧客体験、情報設計、デザインの一貫性 | すべての仕様、技術的実現性、保守性 |
| 主な問い | Why（なぜ、何を作るのか） | What（どのような体験が最適か） | How（どうすれば要求を満たし、価値を届けられるのか） |
| 所有権 | プロダクトバックログ、事業目標、運用要求 | デザインシステム、UI/UX設計、プロトタイプ | すべての仕様、スプリントバックログ |
| 関係性 | 仕様に対して助言、確認・否認 | 事業要求を具体的なUI/UXに落とし込み、エンジニアにインプットする | 仕様を定義し、PdM・デザイナーと合意を得る |
全体マップやロードマップは誰が最初に作成し、誰がメンテナンスするの？
Epic担当者が叩きを作成します。
リファインメントまでに全体マップやロードマップを整備し、リファインメントでどのように実現していくかを協議します。
リファインメント以降ではみんなでメンテナンスします。全体マップはデイリーで、ロードマップはプランニングで進捗と照らし合わせ、やることの抜け漏れや進捗の遅れがないかを定期的にチェックします。
スプリントゴールはどのようなテンプレートを用いているの？
以下のような観点でスプリントゴール設計を行っています。
- 誰が？ (ユーザーは誰か？)
- 具体的なペルソナやユーザーセグメントを定義します。開発チームから距離のある、実際の価値の受益者を設定することで「誰のために作るのか」という目的意識を明確にします。
- 何が提供され、ユーザーは何ができるようになるか？ (提供価値とユーザーの次の行動)
- 私たちが何を提供し、その結果ユーザーが次に何ができるようになるのか、という具体的な状態を記述します。これにより、チームのアウトプットがユーザーにどう利用されるのかまでを具体的にイメージできます。また、「達成条件」として完了の定義を明確にし、メンバー間の認識齟齬を防ぎます。
- なぜならば？ (なぜ今やるのか？)
- 「なぜ今、他の何よりも優先してこの不確実性に取り組むのか」という理由を言語化します。これにより、プロダクト価値がどう向上するのか、その具体的な根拠をチーム内外に示せます。
- 何をスプリントレビューで見せるべきか？ (デモの内容)
- スプリントの最後に何をデモするのかを事前に考えます。これにより、単なる作業報告ではなく、「価値」そのものをステークホルダーに感じてもらうための準備ができます。
- 誰に体験してもらうと良いか？ (レビューの参加者)
- このスプリントの価値を最も的確に評価してくれるのは誰かを考え、レビューに招待します。
- フィードバックで、何の不確実性が減るか？ (得たい学び)
- レビューでどのような意見や感想が欲しいかを具体的に記述します。これにより、次のスプリントにつながる具体的な「学び」を得ることを目指します。
常時モブワークはどうやって実現したの？
実現の経緯としては、職能横断から機能横断にシフトするために、フロントエンド⇔バックエンドの技術伝達のためにこれまで以上にモブワークに力を入れました。
その過程で以下のような気付きがありました:
- 相談や共有が必要なタイミングでアドホックに集まっていたが、結局そこがボトルネックになる
- 最初からモブワークをしていればわざわざ共有のコストを払う必要がない
- 最初からモブワークをしていれば「相談を持ちかけるぞ」という活性化障壁が発生しない
基本的にはモブワークを実施、タスクの属性に応じてもくもく形式に切り替えるなど柔軟に開発の進め方を工夫しています。
Gatherってなに？
コミュニケーションツールです。Gatherの気に入っている点を紹介します:
- ロールプレイングゲームのようなUIで、アバターを近づけるだけで会話が始まり、予約不要の気軽な相談や雑談が発生しやすい
- 誰が何をしているか一目でわかるため、チームの状況把握が容易
- カーレースができる（重要）
どんなチーム構成？
PdM 1名、デザイナー 1名、エンジニア 3名の構成です。
エンジニアは基本的にフルスタックで、フロントエンド〜インフラまで幅広く触れることが求められますが、各々の専門領域を持ち、苦手領域を補いながら機能開発を進めています。
Googleスライドを全画面表示して共有しながらスピーカーノートを見る方法
登壇当日、1台のディスプレイ（Mac標準のモニター）でGoogleスライドのスピーカーノートを見ながら全画面表示のスライドをZoomで共有しようとしたところ、うまくいかず発表を始めるまでに5分ほど手間取ってしまいました。
どういうことかというと、Googleスライドを全画面表示にするとスライドとスピーカーノートがそれぞれ別のデスクトップ画面として表示されます。スライドの画面をZoomで共有している状態で、スピーカーノートを見るために別のデスクトップへ切り替えると、Zoomの画面共有が停止してしまうという状況でした。
この状況に陥らないための対処方法を紹介します。それは、DeskPadやBetterDisplayを用いて仮想デスクトップを作成する方法です。
以下の手順で画面共有を行うと画面共有が停止せずにスピーカーノートを見ながら発表することができます！
- スピーカーノートつきでGoogleスライドのスライドショーを開始する
- 仮想デスクトップにスライドを移動し、全画面表示する
- 仮想デスクトップの解像度は1920×1080が推奨
- Zoomで仮想デスクトップを画面共有する
- スピーカーノートを前面に表示する
他にもっとよい方法があればぜひぜひ教えて下さい🙏
初登壇を終えて、そしてこれから登壇を目指すあなたへ
今回の初登壇の経験は私にとって大きな学びと成長の機会となりました。この経験を通して得た「これから登壇を目指す方の背中を少しでも押すためのTips」を感謝を込めて共有します。
「うちのチームなんて…」と思わずに、プロポーザルを出してみよう
「発表するような、特別な取り組みはないし…」と感じるかもしれません。しかし、スクラムフェス新潟での経験から現場でのリアルな試行錯誤にこそ需要があると確信しました。リファインメントの小さな工夫やコミュニケーションの試みなど、少しでもチームで取り組んでいることがあればぜひプロポーザルとして出してみることを強くおすすめします。
プロポーザルを出すメリットは採択されるかどうかだけではありません。「チームのこれまでの歩みを俯瞰し、構造化する」という絶好の機会になるのです。それだけでも、チームにとって、そしてあなたにとって大きな価値があります。
プロポーザルを書く際は奇を衒ったキャッチーな内容は不要です。むしろ、ネタバレになるくらい詳細に、どんな学びが得られそうかを具体的に書きましょう。参加者や選考者が「この話を聞きたい！」と思えるような誠実で堅実な内容が一番です。
データは雄弁に語る。日々の記録が武器になる
アジャイルやスクラムの現場の話はどうしても定性的な内容になりがちです。だからこそ定量的なデータは強力な武器になります。
今回、私も改めてデータ収集の重要性を痛感しました。たとえば日頃から以下のようなデータを記録しておくことを意識してみてください。
- トライの開始・終了日、始めた・やめたきっかけ
- ベロシティの推移
- リファインメントの所要時間
- バーンダウンチャート
- スプリントゴールの達成頻度と未達の理由
- リードタイム
もちろん、これは登壇のためだけではありません。データを残すことはチームの状態を客観的に見るきっかけになります。良くない指標に気づけばそこから改善のための振り返りにも繋がります。チームを俯瞰しようと思ったそのときからあなたは成長しているのです。
プロポーザルが通ったら。地道な練習が本番の自分を救う
プロポーザルが通ったらそこからは気合です。本当に、本当に、頑張るしかありません。
私が実践した練習方法は、とにかく声に出して、客観的にレビューすることです。私自身まったく喋りに自信がないため、以下のような地道な練習でカバーしました。
- 練習は20回以上。Meetで録画しながら見返し、改善点を探す。
- 10回超えたあたりから録画する手間を手間と感じなくなります。そのくらいやりましょう。
- 聴衆の視点で徹底的にレビュー。
- スライドのペースは適切か？（話が長い、すぐ次に移ってしまうなど）
- スライドは一目見て3秒で主張が伝わるか？
- 音声だけ聞いて、抑揚や接続詞に違和感はないか？
この練習のおかげで本番では「ナレーションのように聞きやすい」「すっと話が頭に入ってくる」というコメントをいただけました。
ちなみに、発表内容を丸暗記する必要はありません。当日はスピーカーノートを見ることができます。覚えることに脳のリソースを使うより何度も声に出す練習をすれば自然と話す内容が頭に定着してきます。
最高のフィードバックを得るための「社内講演」
本番前には一度社内で発表練習をすることを強く推奨します。特に、あなたのチームのコンテキストを全く知らない人に聞いてもらうのがベストです。
「何も知らない人が、すっと理解できるか？」その視点からのフィードバックは発表の質を劇的に向上させます。私は以下のようなアンケートを取り客観的な意見を集めました。
- プレゼン全体の満足度（5段階）
- 最も伝えたかったメッセージは伝わったか？（5段階）
- 受け取ったメッセージは何か？（自由記述）
- ここがブレていたら「結」の再考必須！
- 話の流れやデザインは分かりやすかったか？
- 特に分かりにくかった箇所とその理由（自由記述）
- 内容への納得感や共感はあったか？（5段階）
- 疑問点やもっと知りたい点（自由記述）
- プレゼンで最も良かった点（自由記述）
- 自分が発表者ならどこを改善するか？（自由記述）
- その他、自由なアドバイス（自由記述）
アンケートの結果として以下のようなことが分かり、スライドの見た目や構成の改善および発表練習の仕方に問題がないことを客観的に把握できました。
- バーンダウンチャートを一目で見て主張を捉えるのが難しい
- → もともと10スプリントの結果もプロットしていましたが、ノイズになることが分かったため平均と分散のみに削ぎ落としました。また、スライドに分かりやすく「達成率50%…」「達成率90%！」のように表示することでスライドだけで主張が伝わるようにしました。
- 伝えたいメッセージがブレている
- → Epic担当制や1 WIP制限といった具体の処方箋そのもの以上に、ものごとを俯瞰して問題を構造化して捉えることがチーム独自の処方箋の発見につながるということが主張したいのですが、そこにバラつきがあったため構成を見直しました。
- テレビのナレーションのように綺麗でスムーズ
- → 発表練習に問題がないことの再確認
最後まで粘り抜く
良い資料は最後まで練り上げた資料です。プロポーザルは採択後も編集可能ですし、内容が変わることを恐れずにどんどん改善していきましょう。
何を隠そう私自身も登壇2日前に「結」のパートがどうしても気に食わなくなり、全て書き直しました。
発表を楽しみにしてくれている人がきっと一人でもいるはずです。その人を心の支えにして最後まで粘り抜いてください。
最後に
この度の登壇は、チームの歩みを客観的に振り返る貴重な機会となり、私にとって大きな財産となりました。なぜなら、これまで点在していた課題や取り組みが、チームにどのような影響を与え、何をもたらしたのか、その因果関係を解き明かす絶好の機会となったからです。
以前は、感覚的に「チームはいい方向に向かっている」と感じつつも、具体的な変化を定量的に把握できていませんでした。しかし、チームの歩みを俯瞰し問題を構造的に捉え直したことで、点と点が線で結ばれ、「この課題に対し、この施策を打った結果、このような定量・定性的な変化が生まれた」という明確な気付きを得ることができました。
この経験を通じてチームへの理解が深まるとともに、学びの多いこのチームで働けていることへの感謝の気持ちがより一層強くなりました。 今後はこの学びを活かし、日頃の小さな問題に「なぜ起きたのか」「根本原因は何か」を深く探求する姿勢を大切にします。そして定量的指標を収集・観察することでチームの変化を捉え、改善と成長の兆しを積極的にチームへ発信していきます。
また、登壇には副次的な効果もありました。「次はどんなテーマで話そうか」と、日頃から改善の種を探す視点が身についたのです。これにより、課題解決という守りの姿勢から、チームの現状をさらに良くし、新たな価値を創造していくという攻めの姿勢へと意識が大きく変化しました。
現在、私たちは「エンジニアが自らPRD（製品要求仕様書）を定義する」という新たな取り組みを始めています。この取り組みをさらに実りのあるものへと発展させ、またみなさんの前でその成果を発表できる日を心待ちにしています。
最後になりますが、本稿をお読みいただいた方、そしてご清聴くださった方々に改めてお礼申し上げます。
株式会社カケハシでは現在採用強化中です。以下では、この度の採用に掛ける弊社の意気込みをまとめています。ぜひ読んでみてください！
