スクラムチームの未来を照らすラフでライトでシンプルな見通しの立て方 #scrumkanazawa
2.3K Views
June 14, 25
スライド概要
関連スライド
各ページのテキスト
スクラムチームの未来を照らす ラフでライトでシンプルな見通しの立て方 asato Scrum Fest Kanazawa 2025 2025-06-14
asato 株式会社マネーフォワード スクラムマスター 𝕏：@at_946 at-blog Tenkiru
Target Audience アジャイル開発やスクラムでは、見通しは重要ではないと考えている人 アジャイル開発やスクラムでは、見通しは立てられないと諦めている人 アジャイル開発やスクラムでの、見通しのうまい立て方に悩んでいる人 ️Learning Outcome 早期からプロジェクトの見通しを立て続けることの大切さを知り、 見通しを武器にするためのマインドセットを学び、 明日から始められるプラクティスを持ち帰っていただきます。
注意事項 N=1の個人的な実践や実体験 の話をしにきました！ 学術的でも普遍的でもベストプラクティスでもないです。あしからず。
参考図書 Mike Cohn（著）、安井 力（翻訳）、角谷 信太 郎（翻訳） 『アジャイルな見積りと計画づくり ~価値あるソ フトウェアを育てる概念と技法~』 （毎日コミュニケーションズ、2009）
目次 1. 見通しとは 2. 見通しのマインドセット 3. 見通しのプラクティス
見通しとは
見通し vs. 計画 見通し 計画 「このままいくとこうなる」 「こうなるためにこうする」 見積もりを根拠に、未来を予測する 目標から逆算し、作業の予定を立てる 状況に応じて変わり続けるもの 一度決めたら変わらない あくまで現時点の予測 その通りに進むべきもの
スクラムチームの未来を照らす アジャイルなプロジェクトマネジメント 1. 【透】達成したくなる 目標 を設定し、 2. 【透】わかっていることから 見通し を立て、 3. 【検】目標と見通しの ギャップ を見て、驚き、 4. 【適】ギャップを埋めるために なんとかする 、 5. これを 繰り返す 。
見通しの効能 不安を取り除く 早めの適応を促す 見通し < 目標 見通し < 目標 & ゆとりをもって実験しながら 早めに対策を立てて実行できる 安心して仕事を進められる 早いうちは取れる対策も多い マイクロマネジメント不要で 優先順位をよりシビアに考える 安心してチームに任せられる スコープアウトを覚悟し始める 先のロードマップの再設計 = 現実に即した戦略づくり 誰かの仕事を助ける 営業資料、サポートサイト、 プレス、トレーニング、... プロダクトの見通しがわかれば 仕事の計画が立てられる 自分たちにいつ影響ありそう？ 結合テストはいつからできる？
見通しを可視化し共有することで プロダクトチームの内外問わず いろいろな人がいろいろな目的で チームの見通しを活用できます。
見通しマインドセット
最初に知っておくべきこと 未来のことは 誰にもわからない 見通し自体は、 ユーザーに価値を生まない わかったことが増える度、 見通しは変わり続ける
僕の見通しマインドセット ラフに、ライトに、シンプルに。 「頑張る」を当てにしない。楽観視しない。事実（終わったこと）から見通す。 見通しは更新され続けるもの。仕組み化する。自動化する。 見通しの精度にこだわりすぎない。どうせ変わる。簡単に更新できることが肝要。 一つ一つの見積もり精度にこだわりすぎない。全体でトントンになるからいい。
見通しプラクティス - 計算編 -
見通しの公式 : Forecast。見通し。 : Undone Work。未完了の作業の量。 : Throughput。ある期間で完了できる作業の量。
スクラム：プロジェクトの見通しの公式 : スプリント数の見通し。 : Story Points。未完了のPBIのSPの合計。 : Velocity。1スプリントで完成できるSP。 直近3スプリントで完成したSPの平均などで算出。 PBI: Product Backlog Item, SP: Story Points
ストーリーポイントとは、ユーザーストーリーやフィ ーチャ、その他の作業の大きさをあらわす単位であ る。 ストーリーポイントを使った見積もりではそのよう な、ひとまとまりの仕事に対してポイントを付ける。 ポイントの数値そのものはあまり重要ではない。重要 なのは、他の作業との相対値だ。 2ポイントを付けられたストーリーは、1ポイントのス トーリーの2倍の大きさであり、3ポイントのストーリ ーの3分の2の大きさとなる。 Mike Cohn（著）、安井 力（翻訳）、角谷 信太郎（翻訳） 『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』 （毎日コミュニケーションズ、2009）
計算してみよう ID SP Status Sprint ID SP Status Sprint ID SP Status 1 8 Done 1 6 3 Done 3 11 5 Undone 2 5 Done 2 7 3 Undone 12 1 Undone 3 2 Done 2 8 3 Undone 13 2 Undone 4 5 Done 3 9 2 Undone 14 1 Undone 5 2 Done 3 10 5 Undone 15 3 Undone Sprint
ID SP Status Sprint ID SP Status Sprint ID SP Status 1 8 Done 1 6 3 Done 3 11 5 Undone 2 5 Done 2 7 3 Undone 12 1 Undone 3 2 Done 2 8 3 Undone 13 2 Undone 4 5 Done 3 9 2 Undone 14 1 Undone 5 2 Done 3 10 5 Undone 15 3 Undone Sprint
ストーリーポイントは どうやって見積もるの？
プランニングポーカー アジャイル開発においてチームでプロダクトバックログアイテム（PBI）やタスクの 見積りを行う際に使うトランプのようなカード。もしくは、このカードを使って見 積りを行う手法。 プランニングポーカー | Agile Studio (アクセス日: 2025-06-05 21:00)
Tenkiru
プランニングポーカーの進め方 1. Product Ownerが任意のPBIのユーザーストーリーと受入基準を共有。 2. Developersがカードを選ぶ。共有・質問したいことがあればパパっと会話。 3. カードを開く。全員一致ならその値をSPに採用して終わり。そうでなければ次に進む。 4. 一番大きなカードを選んだ人から1人、理由をパパっと共有してもらう。 5. 一番小さなカードを選んだ人から1人、理由をパパっと共有してもらう。 6. カードをリセット。再度カードを選ぶ。追加で共有・質問したいことがあればパパっと会話。 7. カードを開く。最大値または平均値をSPに採用して終わり。 初期はバッファの意味も込めて最大値を採用することが多い。 チームが安定してきたら平均値を採用することで見通しの精度向上を目指す。
見通しのために 見積もりを頑張る話ですか？
プランニングポーカーの目的は「認識の共有」 目的はPBIに対する「知識と認識のズレ」を可視化すること SPに違いがあるということは、 一方が知らない知識や事実を、他方が知っている 一方が想像していない不確実性を、他方が想像している 一方が感じていない不安を、他方が感じている このズレをあらかじめ議論し、解消しておくことが効果的な作業につながる そのときに出てきた数字が見通しに使えるなので再利用しているだけ
ということで、改めてこれ。 スクラム：プロジェクトの見通しの公式
現実はそんなに簡単じゃない！
Q. 直近のPBIしかリファインメントしないじゃん。
Q. 直近のPBIしかリファインメントしないじゃん。 A. SPのないPBIは平均値だとして見通そう！
ID SP Status Sprint ID SP Status Sprint ID SP Status 1 8 Done 1 6 3 Done 3 11 ? Undone 2 5 Done 2 7 3 Undone 12 ? Undone 3 2 Done 2 8 3 Undone 13 ? Undone 4 5 Done 3 9 2 Undone 14 ? Undone 5 2 Done 3 10 5 Undone 15 ? Undone Sprint
ID SP Status Sprint ID SP Status Sprint 1 8 Done 1 6 3 Done 3 2 5 Done 2 7 3 3 2 Done 2 8 4 5 Done 3 5 2 Done 3 ID SP Status 11 4.1 Undone Undone 12 4.1 Undone 3 Undone 13 4.1 Undone 9 2 Undone 14 4.1 Undone 10 5 Undone 15 4.1 Undone Sprint
ID SP Status Sprint ID SP Status Sprint 1 8 Done 1 6 3 Done 3 2 5 Done 2 7 3 3 2 Done 2 8 4 5 Done 3 5 2 Done 3 ID SP Status 11 4.1 Undone Undone 12 4.1 Undone 3 Undone 13 4.1 Undone 9 2 Undone 14 4.1 Undone 10 5 Undone 15 4.1 Undone Sprint
Q. 直近のPBIしか作成しないじゃん。
Q. 直近のPBIしか作成しないじゃん。 A. エピックの相対見積もりでSPを見積もろう！
エピック 大きいユーザーストーリー 比較的未来に検討されているユーザーストーリー リファインメントで小さなユーザーストーリーに分割される 小さなユーザーストーリーを束ねたもの （[^1]ではテーマ） [^1] Mike Cohn（著）、安井 力（翻訳）、角谷 信太郎（翻訳）『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』 （毎日コミュニケーションズ、2009）
Epic ID EP EP: Epic Points Status 1 2 Done 30 30 0 2 3 Done 56 56 0 3 1 Done 12 12 0 4 2 Undone ? 8 ? 5 3 Undone ? 0 ?
EPあたりのSPの平均値を使って、EpicのSPを見積もる Epic ID EP EP: Epic Points Status 1 2 Done 30 30 0 2 3 Done 56 56 0 3 1 Done 12 12 0 4 2 Undone 32.6 8 24.6 5 3 Undone 48.9 0 48.9
Epic ID EP 1 2 Done 30 30 0 2 3 Done 56 56 0 3 1 Done 12 12 0 4 2 Undone 32.6 8 24.6 5 3 Undone 48.9 0 48.9 のとき、 EP: Epic Points Status
Q. スプリント期間より高頻度に見通しを検査したい
Q. スプリント期間より高頻度に見通しを検査したい A. Daily Velocityを使おう！
Daily Velocityを用いたプロジェクトの見通しの公式 : 日数（営業日）の見通し。 : Story Points。未完了のPBIのSPの合計。 : Velocity。1日で完成できるSP。 直近28日以内の営業日に完成したSPの平均などで算出。 PBI: Product Backlog Item, SP: Story Points
計算してみよう ID SP Status 完成日 ID SP Status 完成日 ID SP Status 1 8 Done 5/29 6 3 Done 6/13 11 5 Undone 2 5 Done 6/3 7 3 Undone 12 1 Undone 3 2 Done 6/4 8 3 Undone 13 2 Undone 4 5 Done 6/6 9 2 Undone 14 1 Undone 5 2 Done 6/10 10 5 Undone 15 3 Undone は、14日以内の営業日から計算 今日は6/14なので、5/31 ~ 6/13 の間の10営業日で計算 完成日
ID SP Status 完成日 ID SP Status 完成日 ID SP Status 1 8 Done 5/29 6 3 Done 6/13 11 5 Undone 2 5 Done 6/3 7 3 Undone 12 1 Undone 3 2 Done 6/4 8 3 Undone 13 2 Undone 4 5 Done 6/6 9 2 Undone 14 1 Undone 5 2 Done 6/10 10 5 Undone 15 3 Undone 完成日
Q. まだ開発始まってないけど超概算の見通しがほしい
Q. まだ開発始まってないけど超概算の見通しがほしい A. シニアメンバーのKKD（勘・経験・度胸）を頼る！
KKDで見積もる 1. プロジェクトをエピックに分割する 2. エピックを相対見積もりする 3. 最初のエピックの最初の数PBIを作成する 4. 最初の数PBIを相対見積もりする 5. 最初のエピックのEPと最初の数PBIのSPから、SP/EPを KKD で見積もる 「このPBIでこのSPなら、このエピックはXX SPくらいにはなりそうだなぁ。」 6. 最初の数PBIのSPから、チームのベロシティを KKD で見積もる 「このチームならこれとこれ（YY SP）は1スプリントで完成できるかなぁ。」 7.
見通しプラクティス - 仕組み化編 -
見通しを更新し続ける仕組みをつくる Jira + Google Sheets Jira Cloud for Sheets などを使えば簡単に連携できる あとは Google Sheets で関数を組めば、自動的に見通しを計算し続けてくれる Google Sheets の QUERY 関数と ARRAYFORMULA 関数が便利
見通しを共有し続ける仕組みをつくる GAS: Google Apps Script
とはいえ結局動くソフトウェア ある日のミーティング 見通しと目標に2週間のギャップが... なんだって！どうするんですか！ ちなみに今プロダクトはこんな感じです... もうできてんじゃん！早くリリースしようよ！ 動くソフトウェアこそが進捗の最も重要な尺度です。 アジャイル宣言の背後にある原則 (アクセス日: 2025-05-22 23:00)
Takeaways 見通しはいろいろな人のいろいろな仕事に役に立つ チームにおいては、目標と見通しを可視化 → ギャップを検査 → 早めに適応 見通しは と少しの応用と工夫で計算できる 見通しの計算はラフにライトにシンプルに、そして計算と共有を自動化する とはいえ結局「動くソフトウェアこそが進捗の最も重要な尺度です。」
公式を機能させるためにチームが獲得したいもの ばらつきの小さいPBL 安定したベロシティ タスクを増やさない仕組み INVEST WIP制限/1個流し DoDとACに向き合う Valuable かつ Small スウォーミング 効果的な自動テスト No "That's not my job" DoD: Definition of Done, AC: Acceptance Criteria
PBLの優先順位