TL;DR（3行まとめ）

ベロシティは「速さ」ではなく「完了時期とコストの幅」に翻訳して CFO に伝える

プロジェクト単位の年次予算から、常設チーム単位の四半期見直しへシフトする

FP&A はチームの外から「事業インパクト（売上・損益）」の判断材料を提供する

Executive Summary

問い：スクラムで動く開発チームの進捗を、FP&A（Financial Planning & Analysis、財務計画・分析。予算・予測・差異分析を担う財務の機能）担当者は、どうやって事業戦略の KGI・KPI の言葉に翻訳し、CFO に報告すればよいのか。
結論 1：スクラムの指標（ベロシティ、バーンダウンチャート、スプリントバックログ）は、そのままでは財務の数字になりません。
FP&A は、これらを 「完了時期の幅」「残りコストの幅」「売上計上開始時期のずれ」 という3つの財務的な量に変換して使います。
結論 2：ベロシティは 予測の道具であって、生産性の評価指標ではありません 。「1ポイント」の意味はチームごとに違う相対単位なので、チーム A の 1,020 ポイントとチーム B の 760 ポイントを引き算しても意味を持ちません。チーム間比較や目標値化をすると、数字そのものが壊れます（Scrum.org [2][3][4]、Atlassian [34]、発案者ジェフリーズ氏 [32]）。FP&A は「速さ」ではなく「予測の幅」として扱います。
結論 3：スクラムと FP&A を両立させている欧米企業は、 年次の「プロジェクト予算」をやめ、常設チーム（またはバリューストリーム）に資金の枠を与え、四半期ごとに見直す 方式に移っています。
ING の四半期ビジネスレビュー（QBR）[6][7]、Equinor の「Ambition to Action」と動的予測 [8][9][10]、John Deere の製品別原価管理（TBM）[12] が代表例です。
結論 4（FP&A の計画サイクル）：FP&A は「年次で動く」のでも「四半期で動く」のでもなく、 年次予算（目標と責任の基準）を固定したまま、少なくとも四半期、多くは月次で予測を更新する二層構造 で動くのが実務の多数派です。
AFP（米国財務専門職協会）の2017年調査では、回答者の73%が少なくとも四半期ごとに再予測を行い、81%が月次または四半期の業績会議を開いています [25]。2026年の AFP 調査では、ローリング予測を使う組織は43%にとどまり、多くは当年度予測の更新で運営しています [26]。
本稿は、この二層構造を前提に、スクラムの2週間サイクルを「月次の予測更新」と「四半期の配分見直し」に接続します。
結論 5（可視化ツールと役割分担）：スクラムボード（Scrum Board）からは投資の配分を、スプリントボード（Sprint Board）からは「完成の定義を満たしたもの」だけを、リリースバーンダウンチャート（Release Burndown Chart）からは完了時期とコストの幅を読み取ります。
役割分担では、FP&A はスクラムチームの外にいる関係者であり、バックログの順番はプロダクトオーナーが決め、投資枠は CFO が承認します。
ING（PO と予算を配るトライブリードを分離、財務は QBR で関与）[6][43]、SAFe 採用企業（FP&A はビジネスオーナーの席）[42]、McKinsey が報告する銀行・保険会社の QBR 運営 [44][46] がその実例です。
結論 6：CFO への報告は、「KGI の到達見込み」「KPI の先行指標」「投資枠の消化」「リリース予測が P&L 予測に与える影響」「CFO に求める意思決定」の5点を1枚にまとめるのが実務的です。
結論 7（本稿の立場：統合は「完成」ではなく「試行錯誤の途中」）：本稿で取り上げた ING（銀行）、Equinor（エネルギー）、John Deere（農業機械）は、スクラムチームの実践と FP&A の経営管理が すでにうまく統合できている企業 として紹介しているのではありません。
3社はそれぞれ別の入口（ING は組織と四半期レビュー、Equinor は目標・予測・配分の分離、John Deere はプロダクト別原価）から、 「2週間の現場」と「年次・四半期の経営」をつなぐ問題に、まだ試行錯誤しながら取り組んでいる段階 です。
共通する論点は、①資金を付ける単位（プロジェクトか常設チームか）、②見直しの周期（年次か四半期か月次か）、③現場指標を経営の数字に翻訳する方法、の3つで、異なる論点は各社の業種・規模・会計制度に由来します。
本稿の翻訳手順や CFO 報告書は、公開資料からこの3つの論点に対する示唆を抽出して組み立てたものであり、どこかの企業がそのまま実装している完成品ではありません（第9章末尾のコラム参照）。
結論 8（日本企業へのインプリケーション）：日本企業は、スクラム開発の全社展開も、FP&A という職能の確立も、欧米企業に比べて道半ばだと言われます。
しかし本稿の立場では、それは「遅れ」であると同時に 「両方を同時に設計できる機会」 でもあります。
製造業では、スクラムの源流である自社の生産管理の知恵（後述）を開発部門と財務部門の共通言語にできます。金融業では、ING のように四半期ビジネスレビューを既存の月次・四半期の与実管理会議に重ねる形が現実的です。エネルギー・インフラ業では、Equinor のように事業ごとに予測の期間と頻度を変える設計が参考になります。小売・エンターテインメント業など変化の速い業種では、常設チームへの投資枠と月次の予測更新を先に整えるのが近道です。
いずれの産業でも、最初の一歩は、年次予算をなくすことではなく、「予算は固定・予測は更新」の二層構造を明文化し、KGI からプロダクトゴールまでの翻訳ツリーを財務と開発が一緒に書くことです（第4章、第10章）。
前提（スクラムの源流は日本の製造業にあり、適用範囲はソフトウェアに限らない）：スクラムは「欧米発祥の手法」と思われがちですが、その名前と発想は、1986年に竹内弘高氏と野中郁次郎氏が『ハーバード・ビジネス・レビュー』に発表した論文「The New New Product Development Game」に由来します。
この論文は、ホンダ、キヤノン、富士ゼロックスなど日本の製造業（および3M、HPなど米国企業）の新製品開発を分析し、部門横断の自己組織的なチームが段階を重ね合わせて開発を進める様子を、ラグビーのスクラムにたとえました [54]。ジェフ・サザーランド氏とケン・シュエイバー氏は、この論文の発想をソフトウェア開発に適用して1990年代に Scrum を枠組み化し、1995年に発表しました [56]。また、アジャイルの姉妹手法であるリーン開発とカンバンは、トヨタ生産方式（ジャスト・イン・タイム、かんばん、自働化）に直接の源流を持ちます [55]。
つまり、 日本の産業界の成功事例に米国が学び、枠組み化したものが、いま日本に「輸入」されている という歴史です。そして、スクラムやアジャイルの適用範囲はソフトウェア開発に限りません。
本稿で取り上げた企業の業種は、銀行（ING）、エネルギー（Equinor）、農業機械（John Deere）であり、 ソフトウェア開発業は1社もありません 。製造業、金融業、小売業、エンターテインメント業、エネルギー産業まで、「不確実なものを、短い周期で作って学ぶ」仕事であれば、同じ考え方が適用できます。
補足：米国会計基準では、2025年9月の ASU 2025-06 によって、社内利用ソフトウェアの資産計上ルールから「プロジェクト段階」の考え方が外され、アジャイル開発に合わせた判定に変わります [17][18]。
FP&A にとって、スクラムのデータを資産計上・費用処理の判断に使う場面が増えます。

本稿のテーマと論旨展開

本稿のテーマは、 「スクラムの現場の数字」と「経営の数字」をつなぐ翻訳の仕組み です。

基礎知識から始め、指標の翻訳方法、CFO（最高財務責任者）への報告様式、欧米企業の事例、導入手順の順に進みます。

想定読者

スクラム という言葉は聞いたことがあるが、中身を知らない 経営企画・財務・経理の方
FP&A という職種名は知っているが、何をする人か説明できない 開発チームのメンバー、プロダクトオーナー、スクラムマスター
DX 投資やソフトウェア開発投資の効果を、経営会議で数字で説明する必要がある 事業部長・管理職
「アジャイルは予算管理と相性が悪い」と感じている CFO・財務責任者

前提知識は求めません。スクラムと FP&A の両方を、基本から説明します。

本稿を読む価値

スクラム と FP&A の基本を、それぞれ1章で押さえられます。
SCRUM の ベロシティ や バーンダウンチャート といったプロジェクトの進捗状況を要約した可視化情報を、財務の数字（完了時期・残コスト・売上計上時期）に変換する具体的な計算方法 がわかります。

3. ベロシティ を 経営指標 に使うと何が壊れるのか、 避けるべき使い方 がわかります。
特に 「なぜ1ポイントの意味はチームごとに違うのか」 を、発案者の回想と企業の実例から理解できます。

4. CFO に出す 1枚の報告書のひな形 と、報告のリズム（スプリント・月次・四半期）が手に入ります。

5. 「FP&A は年次で動くのか、四半期で動くのか」という、入門者が最初につまずく疑問に、AFP と APQC の調査データで答えます。

6. 「予算は固定、予測は動く」という二層構造と、ローリング予測の仕組みを、時系列の図で視覚的に理解できます。

7. スクラムボード・スプリントボード・リリースバーンダウンチャートの英語名と概念、FP&A がこれらの情報から何を読み取るのか がわかります。

8. FP&A・プロダクトオーナー・スクラムマスター・CFO の役割分担 を、欧米企業の運用例から整理できます。

9. ING、Equinor、John Deere という、業種の異なる3社の取り組みを、出典付きで確認できます。

10. 本稿と近いテーマの英文・和文の先行記事（Scrum.org、BCG など）との共通点と相違点を、第12章で確認できます。

第1章　スクラムの基礎

1.1 スクラムとは何か

スクラム は、変化の大きい仕事を、 短い期間（スプリント、通常1〜4週間）で区切って、少しずつ使える成果物を作りながら進める ための枠組みです。

公式の定義は、ケン・シュエイバーとジェフ・サザーランドが公開している「スクラムガイド」にあります。最新版は2020年版です [1]。

計画を最初に全部決めてから順番に作る方式（ウォーターフォール）と違い、スクラムは「作って、見せて、学んで、次の計画を直す」を繰り返します。

1.2 3つの役割

役割	何をする人か
プロダクトオーナー	何を作るか、どの順番で作るかを決める。価値の最大化に責任を持つ
開発者（Developers）	実際に作る人たち。各スプリントで使える成果物を作る
スクラムマスター	スクラムがうまく回るように、チームと組織を支える

2020年版では、チームは原則10人以下とされています [1][19]。

1.3 5つのイベント

イベント	内容
スプリント	1〜4週間の固定期間。下の4つはすべてこの中で行う
スプリントプランニング	「なぜこのスプリントに価値があるか」「何をやるか」「どうやるか」を決める
デイリースクラム	毎日15分、スプリントゴールに向けた進み具合を確認する
スプリントレビュー	できた成果物を関係者に見せ、次に何をすべきかを話し合う
スプリントレトロスペクティブ（振り返り）	チームの進め方を振り返り、改善する

FP&A 担当者が参加すべきなのは、 スプリントレビュー です。
成果物と、プロダクトの今後の見通しが関係者に示される場だからです。

【上級者向けコラム】FP&A とスプリントレビュー

スクラムガイドは、FP&A 担当者を必須の参加者として定めているわけではありません。

本稿でスプリントレビューへの参加を勧めるのは、完成した成果物や今後の見通しを直接確認できるためで、本稿の運用上の推奨です。

組織によっては、毎回参加する代わりに、レビュー後の成果・リリース予測・リスクを所定の様式で共有する運用も考えられます。

たとえば、Jira のダッシュボード（スプリントゴールの達否、完了項目、バーンアップ）を FP&A が閲覧できるようにし、月次の予測更新の前にプロダクトオーナーと15分の確認を置く、といった非同期の運用です。

大切なのは参加そのものではなく、予測と意思決定に必要な情報が適切なタイミングで届くことです。

1.4 3つの作成物と、3つの約束

2020年版のスクラムガイドは、3つの作成物それぞれに「約束（コミットメント）」を対応させました [1][19]。

作成物	中身	対応する約束
プロダクトバックログ	これから作るものの一覧（優先順）	プロダクトゴール（プロダクトの将来の目標）
スプリントバックログ	このスプリントでやるものと、その計画	スプリントゴール（このスプリントの目的）
インクリメント（Increment、増分）	完成した、使える成果物。スプリントごとに積み上がる	完成の定義（Definition of Done、品質の基準）

FP&A の視点で大事なのは、 プロダクトゴールが KGI・KPI に最も近い位置にある ことです。

スプリントゴールはその途中の一歩、インクリメントは実際に積み上がった成果です。

1.5 スクラムガイドに書かれていないもの

意外に思われるかもしれませんが、 ベロシティもストーリーポイントも、スクラムガイドには出てきません 。

これらはスクラムを補う実践として広く使われているものです [3]。

この点は、第5章で FP&A がベロシティを扱う際の注意点につながります。

1.6 スクラムの源流は日本の製造業にある ― そして適用範囲はソフトウェアに限らない

スクラムを「欧米から来た新しいソフトウェア開発手法」と理解している読者は多いと思います。
半分は正しく、半分は違います。

年	出来事	どこで
1950〜70年代	トヨタ生産方式（TPS）が体系化される。ジャスト・イン・タイム、かんばん（後工程が前工程から必要な分だけ引き取る仕組み）、自働化（異常があれば止める）	日本・製造業
1986年	竹内弘高・野中郁次郎「The New New Product Development Game」（ハーバード・ビジネス・レビュー）。ホンダ、キヤノン、富士ゼロックスなど日本の製造業（および3M、HPなど米国企業）の新製品開発を分析。部門横断の自己組織的なチームが、段階を順番ではなく重ね合わせて進める様子を、ラグビーのスクラムにたとえる [54]	日本・米国の製造業の研究
1993〜95年	ジェフ・サザーランド氏が Easel 社で上の論文の発想をソフトウェア開発に適用。ケン・シュエイバー氏と共同で1995年の OOPSLA 会議で「SCRUM Development Process」を発表 [56]	米国・ソフトウェア
2001年	アジャイル宣言	米国
2003年〜	リーンソフトウェア開発、カンバン（ソフトウェア版）が、TPS の考え方を明示的に引き継いで体系化される [55]	米国
2010年〜	スクラムガイド公開。以降、銀行、保険、エネルギー、製造、小売、メディアなど非ソフトウェア産業へ広がる	世界

つまり、 発想の源流は日本の製造業にあり、それを米国がソフトウェアの枠組みとして体系化し、いま日本の企業がその枠組みを「輸入」している 、という往復の歴史です。

本稿の第5章・第6章で扱うスクラムボードやカンバンボードも、工場の「かんばん」の考え方（仕掛かりを見える化し、後工程の引き取りで流す）の直系の子孫です。

適用範囲も、ソフトウェア開発に限りません。

本稿で取り上げる欧米企業の業種は次のとおりで、ソフトウェア開発業は含まれていません。

企業	業種	本稿で扱う章
ING	銀行（オランダ）	第7章、第9章
Equinor	エネルギー（ノルウェー）	第9章
John Deere	農業機械・建設機械（米国）	第9章
McKinsey が報告する北米の金融機関・保険会社	金融・保険	第3章、第7章

製造業（製品開発、生産技術）、金融業（商品開発、業務改善）、小売業（店舗運営の改善、EC）、エンターテインメント業（コンテンツ制作、ゲーム運営）、エネルギー産業（設備投資案件、脱炭素事業）まで、 「正解が事前にわからないものを、短い周期で作り、見せ、学び、直す」仕事 であれば、スクラムの考え方は適用できます。

FP&A が関わるべき範囲も、したがってソフトウェア部門に限りません。

第2章　FP&A の基礎

2.1 FP&A とは何か

FP&A は Financial Planning & Analysis（財務計画・分析）の略で、企業の財務部門のうち、 予算づくり、業績予測、実績と計画の差の分析 を担う機能です [5][20]。

米国の財務専門職団体 AFP（Association for Financial Professionals）は、FP&A の目的 を、事業の意思決定を支えることで資本と資源の使い方を最適化すること、と説明しています [5]。

2.2 欧米企業の経営組織の中での FP&A の位置 ― CEO・CSO・CFO・CRO

企業組織の中で、FP&A がどこ位置付けられる組織（機能）なのかを理解するために、欧米企業の経営組織の典型的な姿を、まず図でお示しします。

CEO と CSO ― 戦略を「作る」側

経営戦略の立案そのものは、CEO が主導する仕事であり、CFO 傘下の機能ではありません。

多くの欧米大企業では、CEO 直属に CSO（Chief Strategy Officer、最高戦略責任者） が置かれ、CEO の戦略立案を支えます。CSO の役割は、HBR の調査（2007年）で次のように整理されています [58]。

CSO の主な役割	内容
戦略の立案	市場・競合・技術の分析に基づき、中期の方向性の選択肢を CEO と取締役会に示す
戦略の実行の調整	戦略が各事業部門の計画に落ちているか、部門間で矛盾がないかを調整する
大きな意思決定の推進	M&A、新規事業、撤退、提携など、既存の事業部門の枠に収まらない案件を進める
CEO の分身	CEO に代わって各部門と対話し、戦略に関する CEO の意図を組織に伝える

CSO は「戦略を作る人」であり、FP&A は「戦略を数字に翻訳し、執行を監視する人」です。

両者は補完関係にあり、中期経営計画の策定では、CSO が方向性と施策を、FP&A が財務モデルと予算を担当する、という分業が一般的 です。

企業によっては CSO を置かず、CEO 直属の戦略部門や、CFO 傘下のコーポレート・ディベロップメント部門がこの役割を担うこともあります。

CFO 傘下の3つの中核機能 ― 数字を「守り、回し、見通す」側

CFO の傘下には、次の3つの中核機能 が置かれるのが典型です [57]。

機能	英語名	何をするか	時間の向き
経理	Controller（コントローラー）	財務会計（決算、開示、内部統制）と管理会計（原価、部門別損益）	過去〜現在
財務	Treasurer（トレジャラー）	資金調達、資金繰り、資本構成、為替・金利リスク	現在〜将来
計画・執行管理	FP&A	予算、予測、差異分析、投資評価、事業部門への財務的助言	将来

大企業では、これに税務、IR、内部監査、M&A の財務評価などが加わりますが、本稿では3本柱に絞ります。

FP&A は、この3本柱の中で唯一「未来」を向いている機能 であり、本稿の主役 です。

CRO とリスクオフィサー ― 全社リスク管理の側（本稿では簡単に）

欧米企業、特に金融機関では、CFO と並んで CRO（Chief Risk Officer、最高リスク責任者） が置かれます。

CRO は、信用・市場・流動性・オペレーショナル・コンプライアンス・サイバーなど全社のリスクを横断的に管理し、CEO 直属または取締役会（リスク委員会）直属とされることが多い役職です。

リスク管理の国際的な標準モデルである「3つのライン・モデル」（内部監査人協会、2020年）では、役割が次のように分かれます [59]。

ライン	誰か	役割
第1ライン	事業部門（現場）とその責任者	リスクを日々取り、管理する当事者
第2ライン	CRO と、各事業部・各拠点に配置されたリスクオフィサー、コンプライアンス部門	第1ラインのリスク管理を支援し、監視し、全社の方針を適用する
第3ライン	内部監査	第1・第2ラインから独立して、仕組み全体の有効性を評価する

各事業部や支社に配置されたリスクオフィサー（CRO にレポートする第2ライン）は、FP&A と似た立場 にあります。

どちらも本社の機能（CRO／CFO）に属しながら、事業現場（世界各国の支社・工場・研究所、本社の各部門）に入り込み、支社長や事業部門責任者の右腕として働きます。

違いは「何を見るか」です。
FP&A は投資対効果・予測・損益を、リスクオフィサーは損失の可能性・規制・統制を見ます。

この「FP&A が見る数字」と「リスクオフィサーが見る数字」が、別々のシステムと別々の会議で動いていて、リスク情報が財務予測に反映されるまで数十日かかる、という問題 は、本稿とは別の連載で扱っています。

本稿が スクラムの「2週間」と FP&A の「月次・四半期」の接続 を扱うのに対し、上記の記事は ERM（全社的リスク管理）と FP&A の接続 を扱っています。

経営者・経営企画の方向けには、FP&A と ERM の役割の違い、CFO と CRO の指揮系統、両者の「致命的な断絶」の正体を、組織図と実例から解説した note の記事があります。

本稿の 2.2 で簡単に触れた内容を、より丁寧に書いたものです。

その前提となる「リスク・リターン・資本」の三角形と、FP&A が担う「リターン」と ERM が担う「リスク」を1つの数字に束ねる RAROC については、同じ連載の1つ前の回で解説しています。

技術者向けには、この断絶をデータパイプラインと形式手法で解消する Qiita の連載があります。

スクラムの現場での役割分担 ― プロダクトオーナー、スクラムマスター、リスクオフィサー、FP&A

スクラムで動く開発チームの現場では、この4者の分担は次のようになります。
詳しくは第7章で扱い、ここでは関係だけを示します。

役割	所属	現場で何を決めるか	何を決めないか
プロダクトオーナー	スクラムチームの中	バックログの中身と順番、プロダクトゴール	投資枠、リスクの受容可否
スクラムマスター	スクラムチームの中	スクラムが機能するようチームと組織を支える	何を作るか、投資、リスク
FP&A	CFO 組織（チームの外）	投資枠の提案、予測の幅、損益への影響額を示す	バックログの順番、スプリント内の進め方
リスクオフィサー	CRO 組織（チームの外）	リスクの識別と評価、規制・統制上の要件を示す。受容できないリスクには異議を唱える	バックログの順番、スプリント内の進め方

共通する原則は、 FP&A もリスクオフィサーも「スクラムチームの外にいる関係者」であり、プロダクトオーナーに判断材料を渡すことはできるが、バックログの順番を直接決めることはできない、という点です。

FP&A は「この項目は年度売上に2,000万円効く」という材料を、
リスクオフィサー は「この項目は規制上、リリース前に第2ラインのレビューが必要」という材料を、

それぞれスプリントレビューや四半期レビューで示します。

両者の材料をもとに、プロダクトオーナーが順番を決め、投資枠とリスク受容の最終判断は CFO と CRO（および事業責任者）が行います。

2.3 日本企業の「経営企画部」との違い

日本企業で、上の図の「CSO の戦略機能」と「FP&A の計画管理機能」に近い仕事を担ってきたのは、多くの場合 経営企画部 です。ただし、両者は同じではありません。

	日本企業の経営企画部（伝統的）	欧米企業の CSO と FP&A
所属	社長（CEO）直属が多い	CSO は CEO 直属、FP&A は CFO 傘下
担う範囲	中期経営計画の立案、経営戦略の検討、予算の取りまとめ、取締役会・経営会議の事務局、新規事業や M&A の検討など、戦略立案と計画管理の両方	CSO が戦略立案、FP&A が予算・予測・差異分析・投資評価・事業部門への助言という計画管理と分析を分担
数字の専門性	企業により差が大きい。経理と別組織のことが多い	FP&A は会計・ファイナンスの専門職。経理・財務と同じ CFO 組織の中にいる
事業部門との関係	本社の調整役	FP&A は事業責任者の「ビジネスパートナー」として伴走する

つまり、 日本の経営企画部は、欧米の「CEO 直属の CSO」と「CFO 傘下の FP&A」の両方を兼ねてきた と言えます。

本稿で「FP&A」と書くときは、このうち 計画管理と分析の部分（予算・予測・差異分析・投資評価・事業部門への助言） を指しています。

日本企業の読者は、「自社では経営企画部（または財務部・経理部の計画担当）がこの役割を担っている」と読み替えてください。

リスク管理についても、日本企業では専任の CRO を置かず、経営企画部や総務部、内部統制部門が分担していることが多く、第2ラインのリスクオフィサーに当たる人が誰なのかを、自社の組織図で確認しておくと、第7章の役割分担が読みやすくなります。

2.4 経理と FP&A の違い

	経理（財務会計）	FP&A（管理会計・経営計画）
時間の向き	過去（起きた取引を正しく記録）	未来（これから起きることを予測）
主な成果物	決算書	予算、予測（フォーキャスト）、差異分析、シナリオ分析
主な相手	株主、税務当局、監査人	CFO、CEO、事業部長

経理が「帳簿を正しく締める」のに対し、FP&A は「予測を正しく保つ」役割を担う、と整理されます [20]。

2.5 FP&A の基本サイクル ― 年次・月次・四半期の三層

FP&A の仕事は、1つのサイクルではなく、周期の違う3つの層が重なって動いています。

年次の層：戦略計画を年度の数字に落とし、予算として固定します。予算は、各部門の目標と責任の「基準線」として使われます。
月次の層：月次決算のたびに、実績を予算・前回の予測・前年と比べ、差の原因を説明します（与実管理＝予算と実績の対比管理、差異分析）。
四半期（または月次）の層：差異分析の結果を受けて、年度の着地見込み（予測）を更新し、必要なら資源配分を変えます。 予算は変えず、予測を変える のが一般的です。

2.6 時系列で見る二層構造 ― 予算は固定、予測は動く

前節の三層を、1年のカレンダーの上に並べると次のようになります（4月始まりの年度を例にしています）。

1行で読むなら：上の帯は1年間動かない「約束」、ひし形は3か月ごとに書き換える「見通し」です。

読み方は次のとおりです。

一番上の帯（予算）は、年度が始まったら動きません。 目標と責任の基準線だからです。
真ん中の帯（与実管理）は、毎月くり返します。 実績と予算・前回予測との差を説明します。
ひし形（予測更新）は、四半期ごとに置かれます。 ここで年度の着地見込みを書き換えます。月次で更新する企業では、このひし形が毎月になります。
一番下の帯は、次年度の予算編成 です。第3四半期後の予測（F3）が、次年度予算の土台になります。「予算は予測から生まれ、予測は予算と比べられる」という循環です。

数字で見ると、こうなります（架空の例、単位：億円）。
予算は固定されたまま、予測だけが実績に近づいていきます。

版	作成時点	年度売上の見込み	予算との差
年度予算（固定）	3月	30.0	―
予測 F1	7月	29.6	−0.4
予測 F2	10月	29.2	−0.8
予測 F3	1月	29.0	−1.0
実績	翌4月	28.9	−1.1

図：年度予算（アンバーの水平線）は動かず、四半期ごとの予測（ティールの線）だけが実績に近づいていく。

2.7 FP&A は年次で動くのか、四半期で動くのか ― 一次資料で確認する

「FP&A は四半期ごとに与実管理をもとに計画を更新する」という教え方と、「FP&A は年次予算で動く」という説明は、どちらも半分だけ正しく、 実務では両方が同時に動いています 。

調査データで確認します。

出典	調査の規模	わかること
AFP「How Relevant is Your Budget?」2017年調査 [25]	FP&A 実務者 606人、2017年8月	74%が予算は価値のある道具だと回答。 73%が少なくとも四半期ごとに再予測を実施。81%が月次または四半期の業績会議を開き、会議時間の69%が業績レビューで、そのほぼ半分が予算との比較、残りが前回予測・前年との比較。22%は予算づくりに12週間超をかけている
AFP「2026 FP&A Benchmarking Survey」[26]	54か国 332人、2025年8〜9月	ローリング予測を使う組織は43% で、多くは当年度の予測更新に依存。構造化されたシナリオプランニングを行う組織は予算編成に平均8.1週間、行わない組織は9.2週間
AFP「Implementing a Rolling Forecast」ガイド（2015）[27]	実務者インタビュー	「18か月の見通しは四半期ごとに、年度予測は月次で更新する」など、年次・四半期・月次の組み合わせが実例として示されている。ローリング予測を年度予算の「種」として使う運用も紹介
APQC Open Standards Benchmarking [28][29]	3,900超の事業体	年度予算の編成に、上位25%は25〜28日以内、下位25%はその約2倍。財務予測の作成は中央値12日。調査票自体が、ローリング予測の更新頻度を「月1回超／月次／四半期」の選択肢で尋ねており、月次か四半期かが標準的な選択肢であることがわかる
AFP「Adopting Agile Forecasting and Budgeting Techniques」2017 [30]	AFP 2016年ベンチマーク調査の解説	ローリング予測は18〜24か月先を見て、通常は毎月または四半期ごとに更新される。従来型では、毎月、月末予測と実績を比べ、年度末までを再予測していた

ここから言えることは 次の3点 です。

予算は年次で固定 されます。
これは目標設定、責任の明確化、取締役会の承認、外部への業績見通しの基礎になるためです。
予測は少なくとも四半期、多くは月次で更新 されます。
「四半期ごとに与実管理をもとに計画を更新する」という教えは、この予測の層を指しています。
ローリング予測（常に12〜18か月先まで見る方式）は、まだ少数派 です。
2026年時点で43%です [26]。「年次予算をやめて、予測だけで経営する」のは、第9章の Equinor のような Beyond Budgeting の実践企業に限られます。

本稿では、FP&A の既存のリズムを「年次予算＋月次の与実管理＋四半期（または月次）の予測更新」として扱い、スクラムの2週間スプリントの情報を、月次の予測更新と四半期の配分見直しに流し込む設計をとります。

この設計のうち、どこまでが欧米企業の実例で、どこからが本稿の独自の見解かを明記しておきます。

設計の要素	根拠	位置づけ
FP&A のリズムが「年次予算＋月次の与実管理＋四半期（または月次）の予測更新」であること	AFP 2017年調査（73%が少なくとも四半期ごとに再予測、81%が月次または四半期の業績会議）[25]、AFP 2026年調査（ローリング予測の採用率43%）[26]	実務の多数派を示す調査データ（特定企業の事例ではなく、実務者調査）
四半期ごとに、チーム（トライブ）単位で成果を振り返り、配分を見直すこと	ING の四半期ビジネスレビュー [7][43]、McKinsey が報告する銀行の QBR（予算の消化状況と事業成果の突き合わせ）[44]、同「QBR を動的な資金配分のエンジンとして使う企業」[13]	欧米企業の実例あり
スプリントごと（2週間）に成果をレビューすること	ING のスクワッドが2週間ごとに仕事をレビュー [43]、スクラムガイドのスプリントレビュー [1]	欧米企業の実例あり（ただし財務との接続は明示されていない）
2週間のスプリントレビューの情報を、月次の予測更新に流し込み、四半期の配分見直しに集約すること	―	本稿の独自の設計。上の3つの要素を接続したもので、「スプリントレビューの結果を月次の財務予測に取り込んでいる」と明示した企業の一次資料は、本稿の調査では見つかっていない

つまり、三層のリズムそのものと、四半期の配分見直しは実例に基づきますが、 「2週間 → 月次 → 四半期」という接続の仕方は、本稿が公開資料から組み立てた提案 です。

読者の皆様の企業で採用する際は、月次の予測更新の会議にスプリントレビューの結果（完了したインクリメント、リリース予測の幅）を1項目として加えるところから始めるのが、最も小さな一歩です。

2.8 ローリング予測とは何か ― 「年度末までの予測」との違い

FP&A の教科書には 「ローリング予測（rolling forecast）」 がよく登場します。

前節の表で、採用率が43%だったものです [26]。
ここで、ふつうの「年度末までの予測」との違いを図で押さえます。

ふつうの年度末予測は、年度が進むにつれて 見ている先が短くなります 。
4月には12か月先まで見ていたのに、1月には3か月先しか見ていません。

Equinor でこの問題に取り組んだボグスネス氏は、これを「アコーディオンのような予測期間」と呼び、奇妙だと指摘しています [31]。

予測を更新する時点	年度末予測が見る範囲	ローリング予測（常に12か月）が見る範囲
4月	4月〜翌3月（12か月）	4月〜翌3月（12か月）
7月	7月〜翌3月（9か月）	7月〜翌6月（12か月）
10月	10月〜翌3月（6か月）	10月〜翌9月（12か月）
1月	1月〜翌3月（3か月）	1月〜翌12月（12か月）

ローリング予測 は、更新のたびに 新しい期間を1つ足して、過ぎた期間を1つ落とす ので、常に同じ長さ（12か月、18か月など）の先を見続けます 。

更新の頻度は、月次か四半期が標準です [27][30]。

ローリング予測を採用しても、 年次予算を捨てるとは限りません 。

AFP のガイドは、ローリング予測の最新版を年次予算の「種」にして、予算編成の時間を短くしている企業を紹介しています [27]。

本稿の立場も同じで、年次予算と、四半期または月次の予測更新の二層構造を前提にします。

図：年度末予測（上、アンバー）は先に進むほど縮む。ローリング予測（下、ティール）は常に同じ長さの窓が右にずれていく。

2.9 KGI と KPI

日本の実務でよく使われる言葉なので、ここで整理します。

用語	意味	例
KGI（Key Goal Indicator、重要目標達成指標）	最終的に達成したい結果	新規デジタル事業の年間売上 30億円
KPI（Key Performance Indicator、重要業績評価指標）	KGI に至る途中の、管理できる指標	有料会員数、解約率、顧客1人当たり売上
先行指標	結果より先に動く指標	新機能のリリース時期、無料から有料への転換率
遅行指標	結果として後から確定する指標	売上、利益

FP&A がスクラムチームから受け取りたいのは、先行指標です。

売上が確定してから「遅れていました」とわかっても、手を打てないからです。

第3章　なぜスクラムと FP&A は噛み合わないのか

3.1 時間の刻みが違う

	FP&A の伝統的なやり方	スクラム
計画の単位	予算は年次で固定。予測は四半期（または月次）で更新	1〜4週間（スプリント）
計画の変更	予算は変えず、予測で吸収する	前提として扱う。バックログの中身が毎スプリント変わる
お金を付ける対象	プロジェクト（始まりと終わりがある）	プロダクトと常設チーム
進捗の測り方	予算の消化率、マイルストーン	完成した成果物、プロダクトゴールへの接近

第2章で見たとおり、FP&A は四半期または月次で予測を更新しています。
したがって、スクラムとの不一致は「FP&A が年に1回しか動かない」ことではありません。

不一致の本当の原因 は、

① 予算が年次で固定され、その単位が「プロジェクト」であること

②予測の更新が2週間のスプリントより粗いこと

の2つ です。

①は次の 3.2 で、②は第5章、第6章、第8章で扱います。

3.2 「プロジェクト予算」の問題

伝統的な予算管理では、案件ごとに事業計画書を作り、承認を受けてから資金が付きます。

しかし、スクラムでは、作りながら優先順位を変える ため、年初に承認した範囲がそのまま残ることはまれ です。

McKinsey は、北米のある金融機関の例を紹介しています [13]。

この会社では、年初にプロジェクトごとに予算を付けていました。

ところが年が進むと、年初には想定していなかった仕事（システム障害の対応、規制対応、経営陣からの急な依頼など）が次々と発生します。

これらの仕事には予算が付いていないので、プロジェクトに割り当てられていた人を引き抜いて対応するしかありません。

その結果、 年初に付けた資金の最大5割が、計画外の仕事や優先度の低い仕事に使われてしまい、本来の重点施策の多くは、人が足りずに立ち上がらなかった 、というのです。

問題の根本は、「お金をプロジェクトに付けていた」ことにあります。

プロジェクトには始まりと終わりがあり、年初に決めた範囲でしか人と予算を確保できません。
当初の想定の範囲外で仕事が発生したとき、それを受け止める仕組みがないのです。

そこで同じ記事は、 お金を付ける単位を、プロジェクトからチームに変える ことを勧めています。

具体的には、「顧客の口座開設の体験を良くし続ける」といった決まった使命を持ち、プロジェクトが終わっても解散しない常設のチーム群（記事はこれを「ポートフォリオ」と呼びます）に、年間の人員枠を付けます。

計画外の仕事が来たら、そのチームが自分たちの作業一覧の中で優先順位を入れ替えて対応します。

人を引き抜かれるのではなく、「何を後回しにしたか」が見える形で吸収されるので、重点施策が黙って消えることがなくなります [13]。

Bain も、多数のアジャイルチームを抱える企業では、計画と予算を頻繁かつ柔軟に見直す仕組みが必要 で、チームは入れ替わるプロジェクトではなく、長く続くプロダクトに結び付けるべきだ と述べています [14]。

Thoughtworks も同様に、常設のプロダクトチームに資金を付け、少なくとも四半期ごとに優先順位を見直すことを勧めています [15]。

3.3 ここから導かれる FP&A の役割の変化

常設チームの費用は、人件費が中心なので、 1スプリントあたりほぼ一定 です。

すると、FP&A が問うべきは「いくら使ったか」ではなく、 「同じ費用で、どの成果が、いつ出るのか。それは KGI にどう効くのか」 に変わります。

【上級者向けコラム】チーム費用のモデル化

本稿の計算例では、チーム構成と稼働率が大きく変わらず、1スプリント当たりの費用がほぼ一定であると仮定しています。

実務では、外部委託費、クラウド利用料、ライセンス料、採用・異動、共通費の配賦などにより費用が変動することがあります。

その場合は、人員に連動する費用と変動費・共通費を分け、どの費用をチームやプロダクトに配賦しているかを明示してから、残コストのレンジを計算します。

クラウド利用料については、FinOps（クラウド費用の可視化・最適化の実務）のタグ付けをプロダクトやチームの単位と揃えておくと、変動費をチーム原価に乗せやすくなります。

第4章　KGI → KPI → スクラム指標の翻訳ツリー

FP&A が最初にやるべきことは、事業戦略の KGI から、スクラムチームのプロダクトゴールまでを、1本の木でつなぐこと です。

（数値は説明用の架空のものです）

この木の 上半分（KGI・KPI）は FP&A と事業部 が、下半分（プロダクトゴール以下）はプロダクトオーナーとチームが 持ちます。

FP&A とプロダクトオーナーが合意すべき接点は、「プロダクトゴール」と「リリース計画」の2つ です。

第5章　3つのスクラム指標を、FP&A はどう使うか

5.1 スプリントバックログの可視化

概要：スプリントバックログは、そのスプリントで取り組む項目と作業の一覧です。多くのチームは、カンバンボード（「未着手」「作業中」「完了」の列にカードを並べた板）や Jira などのツールで見える化しています。

FP&A はどう使うか：

見るもの	目的
スプリントゴールが達成されたか	計画どおり前進しているかの最も単純な信号
完了の定義を満たしたインクリメントの中身	「作業した」ではなく「使えるものができた」かを確認する
項目の種類の比率（新機能・保守・技術的負債の返済など）	投資の配分が戦略どおりかを確認する。資産計上と費用処理の区分の根拠にもなる

避けるべき使い方：タスク1枚ずつの進捗や個人別の作業時間を、FP&A が追いかけることです。
チームの自己管理を損ない、FP&A にとっても情報量が多すぎて判断に使えません。

5.2 ベロシティ（velocity）

概要：1スプリントで完成させた作業量の合計です。作業量は多くの場合、ストーリーポイント（Story Point、作業の大きさを「あの作業の何倍か」という相対値で見積もった点数。時間ではありません）で表します。

ポイントについての注意：ポイントを付けるのは、その作業を行う開発者たち（スクラムチーム）自身です [1]。スクラムマスターは見積もりの場を整えますが、点数は付けません。各チームは、自分たちの過去の作業の中から「これを 1 とする」という基準を選び、ほかの作業をそれと比べて点数を付けます。

基準がチームごとに違うので、 同じプロダクトの同じ作業項目でも、チームが異なれば異なるポイント数が付きます 。

つまり、 「ポイント数の大きさ」と「作業量」の比例関係の定義が、スクラムチームごとに異なる のです。

したがって、 ポイントの合計やベロシティで、複数のスクラムチームの仕事のパフォーマンスを比較してはなりません 。この点は 5.3 節で、発案者の回想と企業の実例をもとに詳しく説明します。

最も大事な注意点：Scrum.org の解説記事は、ベロシティは チームが計画に使う道具であり、成功の尺度ではない こと、 チーム同士の比較に使ってはならない ことを繰り返し指摘しています [2][4]。

また、ベロシティに目標値を設けると逆効果になりやすく、上がっても下がってもそれ自体に良し悪しはない、とも述べています [3]。

ある組織で「毎スプリント60ポイント」を契約で約束させたところ、チームが無関係な項目でバックログを埋めて数字を合わせ始めた、という例も報告されています [21]。

これは、「指標が目標になると、良い指標ではなくなる」という、いわゆるグッドハートの法則そのものです。

FP&A はどう使うか：ベロシティを「速さ」として使うのではなく、 残りの仕事が終わるまでのスプリント数の「幅」 を出すために使います。平均値1つではなく、直近数スプリントの低い値と高い値を使うのが要点です。

計算例（架空の数値）：

残りの作業量：240ポイント
直近6スプリントのベロシティ：低いほうで30、高いほうで40
スプリントの長さ：2週間
チームの費用（人件費など）：1スプリントあたり 600万円

（Google Colab やローカルの Python にそのまま貼り付けて試せるミニコードです。コード中の 30 と 40 は、計算の流れを示すための説明用の値です。実データを使う場合は、同じチームの完了済みスプリントの履歴から集計します。）

import math

remaining_points = 240          # 残りの作業量（ポイント）
velocity_low, velocity_high = 30, 40   # 直近6スプリントの低い値と高い値
cost_per_sprint = 6_000_000     # 1スプリントあたりのチーム費用（円）
sprint_weeks = 2                # スプリントの長さ（週）

n_best = math.ceil(remaining_points / velocity_high)   # 楽観ケース
n_worst = math.ceil(remaining_points / velocity_low)   # 悲観ケース

for label, n in [("楽観", n_best), ("悲観", n_worst)]:
    print(f"{label}: {n}スプリント（{n * sprint_weeks}週間）, "
          f"残りコスト {n * cost_per_sprint / 1e6:.0f}百万円")

実行結果：

楽観: 6スプリント（12週間）, 残りコスト 36百万円
悲観: 8スプリント（16週間）, 残りコスト 48百万円

自分のチームの数字を入れるときの着眼点は、velocity_low と velocity_high を「平均 ± 何か」ではなく、 直近の完了済みスプリントの実際の最小値と最大値 にすることです。

幅を狭く見せたくなる誘惑に負けないでください。

図：ベロシティの低い値と高い値から、完了時期とコストの「幅」を導く。

FP&A は、この結果を次の3つの財務の量に変換します。

スクラムの量	FP&A の量	使い道
残りスプリント数の幅（6〜8）	完了時期の幅（12〜16週間後）	予測の前提条件
残りスプリント数 × 1スプリント費用	残りコストの幅（3,600万〜4,800万円）	完成までの見込み総額（EAC）、投資枠の消化予測
完了時期のずれ	売上・効果の計上開始時期のずれ	P&L（Profit and Loss、損益計算書）予測、KGI 到達見込みの更新

たとえば、新機能のリリースが4週間遅れ、その機能が月2,000万円の追加売上を生む想定なら、年度の売上予測は約2,000万円下がります。

ベロシティそのものではなく、この「売上予測への影響額」が CFO に届けるべき数字 です。

【上級者向けコラム】予測レンジの意味

本節の「6〜8スプリント」は、説明を簡単にするため、残作業量を直近のベロシティの低値・高値で割った簡易レンジです。統計的に校正された予測区間ではなく、「この範囲に何%の確率で収まるか」を示すものでもありません。

実務では、スコープの追加・削除、チームの稼働可能日、外部チームへの依存、リリース条件などが予測に影響します。より確率的な見通しが必要な場合は、完了件数やサイクルタイムの履歴を使ったモンテカルロ・シミュレーションなどを検討します（この節の末尾のコラム「ベロシティとフロー指標」を参照）。

【上級者向けコラム】ベロシティの集計

コード中の 30 と 40 は、計算の流れを示すために設定した説明用の値です。直近6スプリントの実データから自動集計しているわけではありません。

実務で使う場合は、同じチームについて、完了の定義を満たした項目だけを一貫したルールで集計します。

チーム構成や見積もり方、作業の種類が大きく変わった場合は、過去のベロシティがそのまま将来の予測に使えるかも確認します。

祝日や急な欠員で稼働日が減るスプリントについては、稼働可能日数で割った「1稼働日当たりのベロシティ」に直してから幅を取ると、見かけの落ち込みに引きずられにくくなります。

【上級者向けコラム】リリース遅延と売上予測

「4週間の遅延で売上予測が約2,000万円下がる」という例は、リリースが1か月遅れることで、年度内に計上できる売上が1か月分失われると仮定した単純化した試算です。

実際の影響額は、段階リリースの有無、顧客への展開期間、利用率、有料転換率、売上認識の条件などによって変わります。

SaaS のようなサブスクリプション事業では、リリース月に売上が一度に立つのではなく、月次経常収益（MRR）が獲得コホートごとに積み上がるため、1か月の遅れは「1か月分」ではなく「立ち上がり曲線全体の後ろ倒し」として効きます。

FP&A は開発側のリリース見込みだけで金額を決めず、事業部門の売上モデルと会計上の計上時点を接続して試算します。

なお、Scrum.org の記事は、ベロシティの代わりに、完了件数（スループット）や1件あたりの所要日数（サイクルタイム）といった「フロー指標」を使う方法や、モンテカルロ法による確率的な予測も紹介しています [4][22]。

予測の精度を上げたい FP&A にとって、これらは有力な選択肢です。

【上級者向けコラム】ベロシティと「フロー指標（Flow Metrics）」：なぜモンテカルロ法が勧められるのか

ストーリーポイントによるベロシティ予測は直感的で導入しやすい反面、「見積もり自体のばらつき」と「実績ベロシティのばらつき」という二重の不確実性を抱えています。

そのため、近年のアジャイル・メトリクスの実務では、見積もりを介さない「フロー指標（Flow Metrics）」への移行が進んでいます。

具体的には、①スループット（単位期間あたりに完了した作業項目数）、②サイクルタイム（着手から完了までの実経過日数）、③WIP（仕掛かり中の項目数）、④作業項目の経過日数、を定常的に計測します。

これらは主観的な「ポイント」ではなく、Jira などのログからタイムスタンプとして客観的に取得できます。

予測では、過去のスループット実績を母集団として数千〜数万回のモンテカルロ・シミュレーションを行い、「85%の確率で○月○日までに完了する」「5,000万円の投資枠に収まる確率は72%」といった、確率分布としての予測レンジを CFO に提示できます。

FP&A が普段使うリスク分析のモデルと相性のよい手法 です。

Scrum.org の解説 [4][22] でも、ベロシティの代替としてこれらが紹介されています。

5.3 なぜ「1ポイント」の意味はチームごとに違うのか ― チーム間比較ができない理由

ここは、FP&A 担当者が最もつまずきやすいところなので、節を分けて説明します。

5.3.1 よくある誤った計算

次のような報告を見たことがないでしょうか（数値は架空）。

チーム A は開始後1週間で 1,020 ポイント、チーム B は 760 ポイントを完了した。
したがって、A のパフォーマンスは B より (1,020 − 760) ÷ 760 × 100 ≒ 34% 高い。

この計算は、 数式としては正しくても、意味を持ちません 。

理由は単純で、 チーム A の「1ポイント」とチーム B の「1ポイント」は、同じ量を表していない からです。

たとえ話で言えば、「A さんの財布には 1,020 円、B さんの財布には 760 ドルが入っている。だから A さんのほうが 34% 金持ちだ」と言っているのと同じです。

単位が違うのに、数字だけを引き算しています。しかも、円とドルには為替レートがありますが、

チーム A のポイントとチーム B のポイントの間には、為替レートに当たるものが存在しません 。

5.3.2 そもそもストーリーポイントとは何か ― 起源から

ストーリーポイントは、1990年代後半にエクストリーム・プログラミング（XP）の実践の中で生まれました。

発案者とされるロン・ジェフリーズ氏自身の回想によれば、最初は「理想日（邪魔が入らなければ何日かかるか）」で見積もっていたのが、実際には理想日1日分の仕事に3日かかることが常だったため、「日」と呼ぶのをやめて単に「ポイント」と呼ぶようになったのが始まりです。

3ポイントの話は、およそ9日かかる、という具合でした [32]。

つまり、ポイントは 最初から、そのチームの実績に結び付いた、そのチーム固有の単位 でした。

ジェフリーズ氏は同じ記事で、ポイントを複数チームで標準化する動きに対して否定的な見方を示し、「自分が発明したのなら、少し申し訳なく思う」とまで述べています [32]。

その後、ストーリーポイントを広めたマイク・コーン氏の『アジャイルな見積りと計画づくり』（2005）は、ポイントを 単位のない相対値 として定義しています。

「この話はあの話と同じくらいだから、同じ点数」という比較で決めるもので、重要なのは絶対値ではなく相対値だ 、と説明されています [33]。

5.3.3 違いが生まれる4つの理由

理由	説明	出典
① 基準となる話がチームごとに違う	各チームは、自分たちの過去の作業から「これを 1（または 2、3）とする」という基準を選び、ほかの作業をそれと比べて点を付けます。基準が違えば、全体の尺度が違います	コーン [33]、Atlassian [34]
② ポイントには、そのチーム固有の事情が織り込まれる	ポイントは作業の大きさだけでなく、複雑さ・不確実さ・リスクを含んだ「労力」の見積もりです。同じ機能でも、コードベースの慣れ、技術スタック、チームの経験によって労力は変わります	コーン [33]、InfoQ [35]
③ 見積もりの主体がチーム自身である	スクラムガイドは、プロダクトバックログの項目の大きさを見積もるのは開発者の責任だと定めています。外部の誰かが全チーム共通の尺度を押し付ける仕組みがありません	スクラムガイド [1]
④ 比較すると、尺度が歪む	ポイントをチーム間で比べ始めると、チームは自分たちの見た目をよくするためにポイントの尺度を変え始めます。比較が成立しないだけでなく、比較しようとする行為そのものが数字を壊します	InfoQ（ボブ・ハートマン氏の指摘）[35]、Scrum.org [21]

5.3.4 実際の現場ではどうなっているか ― 企業の実例

Atlassian（Jira の開発元、オーストラリア）：Jira の公式ドキュメントは、ポイントの尺度はスクラムチームごとに異なる、と明記したうえで、大事なのは「同じチームの中で」同じ尺度を使い続け、ベロシティを一貫して計算することだ、としています。

Atlassian 自身も社内でストーリーポイントを使っていると述べています [34]。

同社のコミュニティフォーラムには、ヨーロッパとインドの2チームが1日あたりのポイント数を別々に決めていたために、2チームの合計が意味をなさなかった、という相談も投稿されています [36]。

マイク・コーン氏の実験：コーン氏は、複数チームにまたがる46人を集め、同じ12個のバックログ項目を見積もらせて共通の基準を作ろうと試みました。

InfoQ の記事はこの試みを紹介しつつ、参加者の間で同じ項目に 8 と 13 のように異なる点が付く様子を伝え、ほとんどの場合、チーム間でのベロシティ比較は無駄な試みになると結論づけています [35]。

Scrum.org に報告された事例：ある企業では、業務委託契約（SOW）で「スクラムチームは毎スプリント 60 ポイント分を納品する」と定めました。その結果、チームは 60 ポイントの帳尻を合わせるために、無関係な作業項目でバックログを埋め始めました [21]。

ポイントが目標や契約の単位になった瞬間に、ポイントの意味が変わってしまった例です。

SAFe（大規模アジャイルの枠組み）の「正規化」：複数チームでプロダクトを作る企業向けの枠組み SAFe は、第9章で紹介した Lean Budgets と同じ発行元のものです。

SAFe は、チーム間でポイントを「おおむね正規化する」手順を提案しています。

各チームが「開発に半日、テストと検証に半日かかる小さな話」を基準の 1 とし、最初のイテレーションの能力を「開発者1人につき 8 ポイント（2週間）」から出発させる、というものです [37]。

しかし、SAFe の解説者自身が、これはあくまで出発点のための一つのやり方であり、 正規化した後でも各チームは自分の尺度を持ち続け、ポイントはチーム間の比較や評価のためのものではない と強調しています [37]。

ポイントを揃えようとした枠組みですら、比較に使うことは否定しているわけです。

大規模スクラムの教科書（LeSS）：クレイグ・ラーマン氏とバス・ヴォッデ氏の『大規模スクラム』の見積もりの章は、「5」には独立した絶対的な意味がなく、2つのチームは「5」を別々に定義しうる、と述べたうえで、プロダクト全体の進捗を追うためにチーム間でポイントを同期させる方法を論じています [38]。

ここでも目的は プロダクト全体の予測 であって、チームの優劣の比較ではありません。

PMI（プロジェクトマネジメント協会）の見解：PMI の『アジャイル実務ガイド』（2017）に基づく解説では、ストーリーポイントの大きさはチームごとに固有であり、チームの見積もりは互いに独立しているため、ベロシティだけで2チームの生産性を比べることはできない、と整理されています [39]。

5.3.5 では FP&A は何を比べればよいのか

比べてはいけないもの	代わりに比べるもの
チーム A と B のベロシティ	各チームの自分自身の過去との比較（予測の安定性）
ポイント当たりの費用（「1ポイント＝○万円」）	チーム当たり・スプリント当たりの費用（ほぼ固定）と、そのチームが担う KPI への効果
ポイントの合計	完了した項目数（スループット）や 1件の所要日数（サイクルタイム）など、実際の時刻に基づく指標 [4][22]
「どちらのチームが速いか」	「どちらの投資が KGI に効いているか」

冒頭の例に戻ると、FP&A が CFO に伝えるべきは「A は B より 34% 高性能」ではなく、たとえば「A は直近6スプリントで 30〜40 ポイントの幅で安定しており、残り作業の完了は 6〜8 スプリント後。B は幅が 15〜45 と広く、予測の不確実さが大きい」という、 各チームを自分自身の履歴と比べた予測の質 です。

図：チーム A の小さなコインとチーム B の大きなコイン。枚数は違っても、積み上げた高さは同じかもしれない。

5.4 リリースバーンダウンチャート

概要：縦軸に「リリースまでに残っている作業量」、横軸に「スプリント」をとり、残りの作業量が減っていく様子を描いたグラフ です。線がゼロに届いたところがリリースの見込み時期 です。

FP&A はどう使うか：バーンダウンチャートで FP&A が読み取るべきなのは、線の「傾き」と「上振れ」 です。

チャートの形	意味	FP&A の対応
一定の傾きで下がる	計画どおり	予測を維持
傾きがゆるくなる	進みが遅い	完了時期・残コストの予測を更新
線が途中で上がる	作業量（スコープ）が増えた	増えた分が KGI に効くのかをプロダクトオーナーと確認。効かないなら優先度を下げる提言

「進みが遅い」のか「やることが増えた」のかを区別するには、完了した量と全体量を別々の線で描く バーンアップチャート のほうが向いています。

FP&A が報告に使うなら、バーンアップのほうが誤解が少なくなります。

図：バーンダウン（左）では「遅れ」と「追加」が1本の線に混ざる。バーンアップ（右）では2本に分かれる。

バーンダウンチャートとバーンアップチャートの違い

どちらも横軸はスプリント、縦軸は作業量で、リリースまでの進み具合を折れ線で描きます。
違いは「何を線にするか」です。

	バーンダウンチャート（Burndown Chart）	バーンアップチャート（Burnup Chart）
描く線	「残っている作業量」の1本	「完了した作業量」と「全体の作業量」の2本
線の向き	右下がり。ゼロに着いたらリリース	右上がり。完了の線が全体の線に届いたらリリース
作業量（スコープ）が増えたとき	残り作業の線が途中で跳ね上がる。「進みが遅かった」のか「仕事が増えた」のかが、1本の線では区別できない	全体の線が段差で上がり、完了の線はそのまま。「仕事が増えた」ことと「完了のペース」が別々に見える
読みやすい相手	チーム内（残りがいくつかを毎日見る）	経営・財務（スコープ変更の履歴と、完了のペースを分けて説明したい）

たとえば、残り作業が減らなかったスプリントがあったとき、バーンダウンでは「サボったのか、仕事が増えたのか」が線だけではわかりません。

バーンアップでは、全体の線が上がっていれば「仕事が増えた」、上がっていなければ「ペースが落ちた」と、一目で区別できます。

FP&A が CFO に説明するときは、この区別が重要です。

「完了時期が遅れる」という同じ結論でも、原因が「ペースの低下」なら投資枠の見直し、「スコープの追加」ならプロダクトオーナーへの優先順位の確認、と打つ手が違うからです。

本稿がバーンアップを勧めるのは、この理由 によります。

5.5 3つの指標から CFO 報告までのデータの流れ

5.6 会計処理との接点：ASU 2025-06

米国会計基準（US GAAP）では、社内利用ソフトウェアの 開発費を資産に計上するか費用にするか を、これまで「予備段階」「開発段階」「導入後段階」というプロジェクト段階で判定していました。

しかし、アジャイル開発ではこれらの段階が同じスプリントの中で入り混じるため、運用が難しくなっていました。

FASB（米国財務会計基準審議会）は2025年9月18日に ASU（Accounting Standards Update、会計基準更新書）2025-06 を公表し、この段階の考え方を廃止しました [17]。

新しいルールでは、 経営者が資金を付けることを承認・確約し、かつ、そのソフトウェアが完成して意図どおりに使われる可能性が高いこと の2つがそろった時点から資産計上を始めます [18]。適用は2027年12月15日より後に始まる事業年度からです [18]。

FP&A にとっての意味は、 スプリントバックログやリリース予測が、「完成の可能性が高いか」を判断する根拠資料として使われる ようになることです。

スクラムのデータの質が、財務諸表の数字に直接響くようになります。

【上級者向けコラム】会計基準の適用範囲

ASU 2025-06 は、米国財務会計基準審議会（FASB）が定める米国会計基準上の変更です。この変更をもって、日本基準や IFRS でも同じ扱いになったという意味ではありません。

実際の資産計上・費用処理は、企業が適用する会計基準、適用時期、会計方針、内部統制に従って判断する必要があります。本稿で扱うスクラムのデータは判断材料になり得ますが、ベロシティやタスクの状態だけで資産計上の可否が自動的に決まるわけではありません。日本基準・IFRS での論点は、次のコラムにまとめました。

【上級者向けコラム】日本基準・IFRS におけるソフトウェア資産計上とアジャイル開発の実務論点

本文では 米国の ASU 2025-06 を取り上げましたが、日本基準（J-GAAP） と 国際財務報告基準（IFRS） の実務にも留意が必要です。

日本基準（「研究開発費等に係る会計基準」および日本公認会計士協会会計制度委員会報告第12号）では、自社利用ソフトウェアについて、将来の収益獲得または費用削減が確実と認められる段階の費用を資産計上します。

アジャイル開発では「仕様の検討（研究・調査に近い作業）」と「実装（開発）」が同じスプリントの中で反復されるため、どの作業が要件を満たすかの線引きが難しくなります。

実務では、Jira のエピックやチケットに「資産計上対象」のフラグを付け、工数実績と、完成の定義を満たしたインクリメントに連動させて按分する内部統制が求められます。

IFRS（IAS 第38号「無形資産」）でも、技術的な実現可能性や将来の経済的便益の創出などが実証された時点以降の開発費だけが資産化の対象です。

米国がプロジェクト段階の判定を撤廃した流れが、日本基準や IFRS の今後の議論にどう影響するかは未定です。

いずれの基準でも、FP&A と経理・監査法人の間で「スクラムの作成物（インクリメント、プロダクトゴール）をどう客観的な証憑として扱うか」を事前に合意しておくことが重要です。

第6章　スクラムボード・スプリントボード・リリースバーンダウンチャート ― 概念と、FP&A の参照の仕方

第5章では「指標」を扱いました。

この章では、現場が毎日見ている 3つの可視化ツール を、英語の正式名称とあわせて整理し、FP&A が CFO への進捗報告のためにそれぞれをどう参照するか を、企業の一次資料に基づいて説明します。

【上級者向けコラム】ボードは公式の作成物そのものではない

「スクラムボード」「スプリントボード」は、チームの仕事を可視化するために現場で使われる呼び方です。スクラムガイドが定める作成物は、プロダクトバックログ、スプリントバックログ、インクリメントの3つです。特定のボード形式や列の名前が、すべてのスクラムチームに共通して定められているわけではなく、ツールの形や列の構成はチームごとに異なります。

そのため FP&A は、ボードの見た目を標準化することよりも、完成の定義を満たした成果、スプリントゴール、スコープの変化など、意思決定に必要な情報を一貫したルールで確認することが重要です。

6.1 3つのツールの英語名と概念

日本語	英語フルスペル	何を見える化するか	時間の範囲
スクラムボード	Scrum Board（タスクボード Task Board とも）	プロダクトバックログからスプリントバックログまで、仕事の全体の流れ。 Jira などのツールでは「バックログ」と「アクティブなスプリント」の2画面を持つ板全体を指す	プロダクト全体（数か月〜年）
スプリントボード	Sprint Board（スプリントバックログボード Sprint Backlog Board）	今走っているスプリントの項目を「未着手（To Do）」「作業中（In Progress）」「完了（Done）」の列で並べた板。スクラムボードの「今のスプリント」の部分	1スプリント（1〜4週間）
リリースバーンダウンチャート	Release Burndown Chart	リリースまでに残っている作業量が、スプリントごとに減っていく折れ線。類似のものに、1スプリント内の残作業を日単位で描く Sprint Burndown Chart、完了量と全体量を別々に描く Burnup Chart、各状態の滞留を帯で描く Cumulative Flow Diagram（累積フロー図）がある	リリース（数スプリント〜数か月）

3つの関係を図にすると次のようになります。

スクラムガイドでの位置づけ：スクラムガイド 2020 は、進捗を予測する実践としてバーンダウン、バーンアップ、累積フローを名指ししたうえで、それらは有用ではあるが経験主義（実際に起きたことに基づいて判断すること）に取って代わるものではない、と釘を刺しています [40]。

つまり、 ツールはスクラムの必須要素ではなく、補助的な道具 です。

Scrum.org の解説では、これらの道具を使って予測を作り、関係者に伝える責任はプロダクトオーナーにある、と整理されています [41]。

6.2 スクラムボード ― FP&A は「配分」を読む

スクラムボードの価値は、 プロダクトバックログの上のほうに何が並んでいるか が見えることにあります。

FP&A はここから、次の2つを読み取ります。

読み取るもの	意味	CFO 報告のどの欄に使うか
バックログ上位の項目が、プロダクトゴール（第4章の翻訳ツリー）に沿っているか	戦略どおりの投資になっているか	① KGI 到達見込みの前提
新機能・保守・技術的負債の返済・規制対応の比率	投資の中身。資産計上と費用処理の区分の根拠にもなる（5.6節）	③ 投資枠の消化

企業の実例：SAFe を採用する企業では、この「配分を読む」役割が ビジネスオーナー（Business Owners） という役割に制度化されています。

SAFe はビジネスオーナーを、特定のアジャイルリリーストレイン（複数チームの集まり）が生む事業価値に共同で責任を負うリーダーと定義し、計画イベント（PI プランニング）で各チームの目標に事業価値を点数で割り当て、計画を承認する責任を与えています [42]。

FP&A が事業責任者とともにこの席に座るのが、SAFe 企業での典型 です。

【上級者向けコラム】キャパシティ配分：技術的負債・障害対応と新機能投資のトレードオフ

経営陣や営業部門からの要求が強まると、バックログは新機能で埋め尽くされ、リファクタリングやアーキテクチャ刷新などの「技術的負債の返済」が後回しにされがちです。

財務の言葉で言えば、高い金利の借入を重ねて短期の売上を買い、将来の営業利益率を圧迫している状態に近いものです。

FP&A は、スクラムボードの項目分類（新機能／技術的負債の返済／不具合修正／基盤運用）の比率を監視し、技術的負債の放置が将来のベロシティ低下や障害対応コストを招くリスクを、CFO に定量的に報告します。

たとえば「技術的負債への投資比率を最低20%確保する」というキャパシティ配分の方針を、財務と開発の合意事項（ガードレール）として設定すれば、エンジニアリング組織の健全性を経営レベルで守れます。

SAFe のガードレールにある「キャパシティ割当」[23] と同じ考え方です。

6.3 スプリントボード ― FP&A は「完了の定義を満たしたか」だけを読む

スプリントボードは、チームが毎日動かす作業の板です。

ここで FP&A が注意すべきは、 読む粒度を間違えない ことです。

見てよいもの	見るべきでないもの
スプリントレビューで示された「完了（Done）」列の中身と、スプリントゴールが達成されたか	個々のカードの担当者、作業時間、途中経過
完了したインクリメントが、ユーザーに使える状態か（完成の定義）	「作業中」が多い・少ないといった日々の変動

スクラムガイドは、完成の定義を満たさない項目はリリースも、スプリントレビューでの提示もできない、と定めています [1]。

したがって、FP&A にとっての「進捗」は、 完成の定義を満たした項目だけ です。
90%できた項目は、財務的には 0% です。

企業の実例：ING では、スクワッドが2週間ごとに自分たちの仕事をレビューし、顧客のために製品をどう改善し続けるか、あるいは早く失敗を認めて方向転換するかを決めます [43]。

FP&A が参照すべきは、この2週間ごとのレビューの結果であり、日々の板ではありません。

6.4 リリースバーンダウンチャート ― FP&A は「傾き」と「上振れ」を読む

5.4節で述べたとおり、FP&A がこのチャートから読むのは、線の傾き（進む速さ）と、線の上振れ（作業量の追加）です。CFO 報告では、次のように変換します。

チャートの読み	FP&A の変換	CFO 報告の欄
現在の傾きのまま進むと、残り作業がゼロになるスプリント	完了時期の幅（第5章の計算）	④ リリース予測
残りスプリント数 × 1スプリント費用	完成までの見込み総額（EAC）	③ 投資枠の消化
線が上振れした（スコープが増えた）	増加分が KGI に効くかをプロダクトオーナーに確認。効かないなら優先度を下げる提言	⑤ 求める意思決定

Scrum.org のフォーラムでは、リリースバーンダウンが「最初に全部を見積もった総ポイント」から始まる形になっていることへの疑問に対し、それはスクラムの経験主義を理解していない作り方だ、という回答が示されています [40]。

FP&A が自社のチャートを見るときも、 最初の総量が固定されたままになっていないか（本当は作りながら増減するはず）を確認してください。固定されたままのチャートは、見積もりを更新していない兆候です。

企業の実例：McKinsey の記事によれば、ある大手銀行は四半期ビジネスレビュー（QBR）で、予算の消化状況を、実際に届けられた事業成果と突き合わせて点検し、必要があればその場で透明かつ迅速に調整しています [44]。リリースバーンダウンから導いた「完了時期の幅」と「見込み総額」は、まさにこの突き合わせの材料になります。

6.5 3つのツールと CFO 報告の対応

図：3つの可視化ツールが、CFO 報告書のどの欄に流れ込むか。

第7章　役割分担 ― FP&A、プロダクトオーナー、スクラムマスター、そして CFO

FP&A は、事業責任者の右腕として、CFO とやり取りしながら、現場の軌道修正や改善に関わります。

一方、スクラムにも、現場の優先順位を決める人（プロダクトオーナー）と、チームの働き方を整える人（スクラムマスター）がいます。

役割が重なるように見えるこの3者を、スクラムと FP&A を両方使う欧米企業はどう分けているのか を見ていきます。

7.1 出発点：スクラムガイドが定める3つの責任と、「外」にいる関係者

スクラムガイド 2020 は、スクラムチームの中に3つの責任（accountability）だけを置きます [1][19]。

責任	何に責任を持つか	FP&A との関係
プロダクトオーナー（Product Owner）	プロダクトの価値を最大化すること。プロダクトゴールを定め、プロダクトバックログの中身と順番を決める	FP&A の最も重要な対話相手。「何を先に作るか」はこの人が決める
開発者（Developers）	毎スプリント、使えるインクリメントを作ること。項目の大きさの見積もりも開発者が行う	FP&A が直接指示することはない
スクラムマスター（Scrum Master）	スクラムが機能していることに責任を持つ。チームと組織に仕える	FP&A の対話相手ではなく、FP&A がスクラムを誤用しないよう助けてくれる人

FP&A は、この3つのどれでもありません。

スクラムガイドの言葉では ステークホルダー（関係者） です。

2020年版では、関係者への言及が2017年版の約2倍に増え、スクラムの価値観と経験主義は、チームが関わる関係者にも及ぶ、と書かれています [45]。

ここから最初の原則が出ます。

FP&A は、スクラムチームの中の仕事（何をどの順で、どうやって作るか）を指揮しません。

FP&A が影響を与えるのは、チームの「外」にある2つのこと、すなわち ①投資の枠と配分（CFO と事業責任者の決定） と、 ②プロダクトオーナーが優先順位を決めるときの判断材料（KGI への効果、コスト、期限） です。

Scrum.org は、プロダクトオーナーが関係者の要求に対して「ノー」や「今はやらない」と言える力を持つほど、プロダクトの価値は高まる、と述べています [41]。

FP&A の提案も、プロダクトオーナーに断られうる「要求」の一つです。これは欠陥ではなく、設計どおりです。

7.2 企業の実例：役割をどこに置いたか

ING（オランダ）：ING では、プロダクトオーナーはスクワッドのメンバーであってリーダーではなく、活動の調整とバックログ・優先順位の管理に責任を持ちます [6]。

一方、各トライブにはトライブリードがいて、優先順位を定め、 予算を配分し 、知見がトライブ内外で共有されるようにします [43]。

財務などの支援部門は、当初スクワッドの外に置かれ、別の形でアジャイルを取り入れました [6]。

つまり ING では、 「順番を決める人（PO）」と「お金を配る人（トライブリード）」を分け、財務はその外から、四半期ビジネスレビュー（QBR）を通じて関わる 設計です。

QBR では、各トライブが四半期の成果、最大の学び、次の四半期の目標、他のトライブに求めることを文書にします [43]。

SAFe を採用する企業：SAFe は、プロダクトオーナーとは別に ビジネスオーナー（Business Owners） という役割を定義しています。

ビジネスオーナーは、事業部門の責任者や部門長など、複数チームの成果物の事業価値に共同で責任を負うリーダーで、計画イベントで各チームの目標に事業価値を割り当て、計画を承認し、期の終わりの「検査と適応（Inspect & Adapt）」で実際に届けられた価値を評価します [42]。

また、SAFe はポートフォリオの予算配分を、参加型予算編成とガードレールで運営します（第9章）[16][23]。

FP&A は、ビジネスオーナーの席に事業責任者と並んで座り、参加型予算編成を運営する側 に位置づけられます。プロダクトオーナーは、その下でチームのバックログを決めます。

McKinsey が報告する金融機関・保険会社の例：McKinsey のアジャイル資金配分の記事では、ポートフォリオのリーダーがプロダクトオーナーと協働して、次の90日間の目標（OKR）を作り、それが全社の OKR につながる、という構造が示されています。

企業は四半期ビジネスレビューを、資金と人材の動的な配分のエンジンとして使っています [13]。

別の記事では、QBR を機能させるには、アジャイル・IT・財務と予算・戦略の専門性を組み合わせた専任のチームと、尊敬されるリーダーが必要だ、と述べられています [44]。

さらに、ある保険会社は予算の一部を四半期ごとに配分する枠として取り置き、アジャイルチームが新しいアイデアのために資金を申請し、複数部門の事業リーダーが集まる四半期の計画会議で OKR に対する成果と計画を聞いて決める、という運用をしています [46]。

ここで財務（FP&A）は、QBR の運営側と、資金申請を審査する側 にいます。

Equinor（ノルウェー）：Equinor の「Ambition to Action」は、財務部門主導で作られた業績管理の枠組みです。

目標・予測・資源配分を分け、予測は出来事に応じて各部門が必要な期間だけ先を見る、という運営でした [8][9]。

開発チームが何を作るかを財務が決めるのではなく、 財務は「どのくらい先まで、どの頻度で見通すか」という枠組みの設計者 に徹しています。

7.3 整理：誰が何を決めるか

決めること	プロダクトオーナー	スクラムマスター	FP&A	事業責任者（トライブリード・ビジネスオーナー）	CFO
バックログの中身と順番	決める	助言	判断材料を出す（KGI への効果、コスト、期限）	優先順位の方向を示す	―
スプリントの中の進め方	―	チームを支える	関与しない	―	―
チーム（バリューストリーム）への投資枠	要求する	―	案を作り、幅と影響額を示す	配分する	承認する
四半期の配分見直し	成果と次の計画を説明する	―	運営し、数字を揃える	提案する	決める
KGI・KPI の設定	プロダクトゴールに翻訳する	―	翻訳ツリーを作る（第4章）	合意する	承認する
続ける・止める・方向転換の判断	提案する	―	幅と影響額で材料を出す	提案する	決める

7.4 FP&A が「軌道修正を指揮する」の正しい意味

冒頭の問いに戻ります。

FP&A は事業責任者の右腕として現場の軌道修正に関わりますが、スクラムの現場での「指揮」は、 スプリントの中に手を入れることではありません 。

欧米企業の運用から読み取れる、FP&A の軌道修正の3つのレバーは次のとおりです。

プロダクトオーナーへの判断材料：「この機能の遅れは年度売上を2,000万円押し下げる」「この項目は KGI に効かない」という数字を、スプリントレビューと四半期レビューで示す。決めるのはプロダクトオーナー。
配分の提案：チーム間・バリューストリーム間での人員や投資枠の移動を、幅と影響額を付けて事業責任者と CFO に提案する（第8章の報告書の⑤）。決めるのは CFO。
枠組みの設計：どのくらい先まで、どの頻度で予測するか、何を KGI・KPI とするか、QBR をどう運営するか、という「ルール」を設計する（Equinor の例）。

スクラムマスターは、この3つのいずれにも「指揮系統」としては登場しません。

しかし、FP&A がベロシティをチーム比較に使おうとしたり、スプリントの途中で優先順位を変えさせようとしたりしたときに、それがスクラムを壊すことを説明してくれる、 FP&A にとっての安全装置 です。

図：FP&A はチームの境界の外から、判断材料と配分の提案で軌道修正に関わる。

第8章　CFO への報告

8.1 1枚の報告書のひな形

以下は架空の例です。

項目	内容	状態
① KGI の到達見込み	新規デジタル事業売上：計画 30億円 → 現在の予測 28.5〜29.5億円	黄
② KPI（先行指標）	有料転換率 3.1%（計画 3.5%）。新決済機能のリリース後に改善を見込む	黄
③ 投資枠の消化	年間投資枠 4.8億円のうち 2.6億円を消化。うち資産計上 1.5億円	緑
④ リリース予測と P&L への影響	新決済機能：完了まで6〜8スプリント（12〜16週間）。悲観ケースでは年度売上 −2,000万円	黄
⑤ CFO に求める意思決定	別チームの優先度の低い項目を止め、決済チームに人員を1名移すことの承認	―

図：CFO に出す1枚の報告書のイメージ。ベロシティの値は載せず、幅と影響額だけを載せる。

ポイントは3つです。

ベロシティの値は書かない 。書くのは、そこから導いた「時期の幅」と「金額の幅」です。
点ではなく幅で示す 。予測の不確かさを隠さないことが、CFO の信頼につながります。
最後に意思決定を求める 。報告は、資源配分を変えるための材料です。

8.2 報告のリズム

このリズムは、FP&A が既に持っている「月次の与実管理」と「四半期（または月次）の予測更新」[25][26] に、スプリントレビュー（2週間）を1段足しただけです。第2章の時系列チャートに、2週間ごとの刻みを重ねると次のようになります。

1行で読むなら：6つのひし形（スプリントレビュー）の情報が、3つの月次更新に流れ込み、四半期末の1回の配分見直しに集まります。

図：2週間ごとのスプリントレビューの情報が、月次の予測更新に流れ込み、四半期の配分見直しに集まる。
新しい会議体を作るのではなく、既存の月次・四半期の会議に、リリース予測の幅と P&L への影響額を持ち込むのが現実的です。

第9章　欧米企業の事例

この章で取り上げる3社の業種は、銀行、エネルギー、農業機械です。ソフトウェア開発業ではない企業が、スクラムと財務管理の接続にどう取り組んでいるかを見ます。なお、3社を「すでに統合に成功した企業」として紹介するのではなく、 それぞれ別の入口から試行錯誤している途中の企業 として読んでください（章末のコラム参照）。

9.1 ING（オランダ・銀行）：スクワッドとトライブ、四半期ビジネスレビュー

何をしたか：ING は、オランダ本社で、約350の9人チーム（スクワッド）を13のトライブにまとめる組織へと移行しました。McKinsey のインタビューによれば、この取り組みで市場投入までの期間の短縮、従業員エンゲージメントの向上、生産性の向上が見られたとされます [6]。

同じインタビューでは、当初、人事・財務・リスクなどの支援部門は、スクワッドとトライブへの移行の対象外とされたこと、ただしそれらの部門も別の形でアジャイルを取り入れていることが語られています [6]。

FP&A との接点：ING の事例研究によれば、ING は四半期ビジネスレビュー（QBR）を用い、各トライブが文書を書いて他のトライブと共有し、互いに意見を述べ、スクワッド間の依存関係を洗い出しています [7]。トライブは150人以下の規模に抑えられています [7]。

FP&A への示唆：スプリント（2週間）と年次予算の間に、 「四半期」という中間の刻み を置き（これは第2章で見た FP&A の四半期の予測更新と同じ周期です）、そこで目標と資源配分をすり合わせる、という設計です。第8章の報告リズムの「四半期」に当たります。

9.2 Equinor（ノルウェー・エネルギー、旧 Statoil）：伝統的な予算をやめ、動的予測へ

何をしたか：Equinor は「Beyond Budgeting（予算を超えて）」の考え方に基づき、「Ambition to Action」というモデルを作りました。
業績評価を全体的なものに改め、動的な予測と資源配分を使うことで、伝統的な予算をなくし、出来事に応じて判断する仕組みに移っています [8]。
この取り組みを率いたビャルテ・ボグスネス氏は、Beyond Budgeting Roundtable の会長でもあります [8][10]。

予測のやり方：ボグスネス氏のインタビューによると、Equinor は、全社一律の頻度と期間で行うローリング予測も検討したうえで、 カレンダーではなく出来事をきっかけに、各部門に必要な期間だけ先を予測する「動的予測」 を選びました [9]。

たとえば、石油トレーディング部門にとっては3週間より先は見通しにくく、一方で新しい油田・ガス田の開発部門にとっては3年でも短い、という違いがあるためです [9]。

また、「動的」とは頻度を上げることではなく、適切な時期に行うことであり、部門によっては頻度が下がることもある、とも述べています [9]。

BCG の調査：BCG は、Beyond Budgeting では目標を事業部門自身が設定する方向性のある相対的なものにし、予測は現実的な見通しを出すための独立した工程とすべきだと述べ、Equinor を動的予測の例に挙げています [11]。BCG が2020年12月に行った調査では、財務幹部174人のうち59%が売上増を報告しています [11]。

FP&A への示唆：Equinor の要点は、 「目標」「予測」「資源配分」を1つの予算にまとめず、別々の工程に分けた ことです。

スクラムで言えば、プロダクトゴール（目標）、ベロシティから導いた予測（予測）、四半期の配分見直し（資源配分）を混ぜない、ということです。ベロシティを目標にしてはならない理由とも一致します。

【上級者向けコラム】Beyond Budgeting における「目標・予測・資源配分」の分離と相対的ターゲット

伝統的な予算管理が機能不全に陥る根本原因は、「目標（Target）」「予測（Forecast）」「資源配分（Resource Allocation）」という性質の違う3つの機能を、1つの年度予算書に詰め込んでいる点にあります。

①目標は達成したい野心的な水準であるべきですが、②予測は現時点で最も客観的な見通しでなければならず、③資源配分は状況の変化に応じて最適な場所へ投じる動的な枠であるべきです。これらを1本の数字に統合すると、部門長は「目標を低く設定して達成しやすくする」と同時に「資源を過剰に確保する」行動をとり、予測の客観性が失われます。

Equinor などの実践企業は、目標を絶対額ではなく「同業比での相対的な位置」などの相対的ターゲットに切り替え、資源配分を事前の包括枠ではなく「必要な時点で都度判断する仕組み」へと分離しました [8][11]。これにより、チームは予算消化の行動から解放され、顧客価値の創出と迅速な方向転換に集中できます。

9.3 John Deere（米国・農業機械）：プロジェクトからプロダクトへ、製品別の原価管理

何をしたか：TBM Council の事例紹介によれば、John Deere は2019年、取締役会が承認した投資のもとで、アジャイル型の運営モデルへの移行と、プロジェクトからプロダクトへの転換を始めました [12]。

FP&A との接点：John Deere は、IT 費用管理を長年行ってきたものの、新しいアジャイル運営モデルに合う仕組みが必要になり、TBM（Technology Business Management）の手法で製品別の原価計算を整えました [12]。

その結果、10億ドル規模の固まった費用を、450を超える管理されたデジタルプロダクトへと組み替えたと報告されています [12]。また、プロダクトチームへの資金配分と投資の監視をより柔軟に行うアジャイル型の資金配分を取り入れつつあるとされます [12]。

FP&A への示唆：常設チームの費用を プロダクト単位に正しく配賦する仕組み がなければ、第5章の「1スプリントあたり費用」も「プロダクトごとの投資対効果」も計算できません。

原価の基盤づくりが、スクラムと FP&A をつなぐ前提条件です。

【上級者向けコラム】TBM（Technology Business Management）とアジャイル原価計算：標準単価法と実費累積法

John Deere が採用した TBM は、IT 費用を勘定科目の視点から、ビジネスサービスやプロダクトの視点へと組み替える管理会計の枠組みです [12]。

アジャイル開発におけるチーム原価のモデル化には、大きく分けて「標準スプリント単価法（ブレンデッド・レート）」と「実費累積法」の2通りがあります。

標準スプリント単価法では、チームの人員構成（シニアエンジニア、QA、スクラムマスターなど）に応じた標準人件費にインフラ・共通費の配賦率を乗せ、「1スプリント＝一律600万円」といった固定レートを設定します。

これにより、FP&A は複雑な工数入力を排し、スプリント数に応じた迅速なバーンレート予測と製品別損益の把握ができます。本稿の計算例はこの方式です。

一方で、外部パートナーの単価差が大きい場合や、クラウド利用料が機能ごとに大きく変動する場合は、FinOps のタグ付けと連携させた多段階の配賦モデルが必要になります。

スクラムの機敏さを損なわないためには、個人別のタイムトラッキングを避け、「チーム単位の標準レート＋変動インフラ実費」で管理するのが現実的な落としどころです。

9.4 業界の標準的な枠組み：SAFe の Lean Budgets

個別企業ではありませんが、大規模なアジャイル組織で広く使われている SAFe（Scaled Agile Framework） は、 プロジェクトではなくバリューストリーム（価値を生む一連の流れ）に資金を付ける「Lean Budgets」 を提唱しています [16]。

関係者が集まって予算の配分を話し合う「参加型予算編成」と、支出の方針を定める「ガードレール」を組み合わせ、チームの自律と財務の統制を両立させる設計です [16][23]。

SAFe 第5版では、バリューストリームの予算は通常、年に2回程度見直すとされています [24]。

図：ING は四半期の刻み、Equinor は目標・予測・配分の分離、John Deere はプロダクト別原価。

【上級者向けコラム】参加型予算編成（Participatory Budgeting）のガバナンスとガードレール

SAFe の Lean Budgets で用いられる参加型予算編成は、複数のバリューストリームやエピックの優先順位を、現場のリーダーと財務幹部が協働して決める場です [23]。しかし、十分な統制がないと「声の大きい部門への予算分配」に堕するリスクがあります。

SAFe はこのリスクを抑えるために「ガードレール」を定めています [23]。①投資地平線（Horizon）ごとの配分（既存事業の維持、成長事業の拡大、将来の探索への比率を定める）、②キャパシティ割当（新機能、技術的負債の返済、保守運用へのチーム工数の比率を管理する）、③大型投資の承認閾値（一定規模以上の投資のみポートフォリオで承認し、小規模な投資はチームに委ねる）、④ビジネスオーナーの継続的な関与（四半期ごとのレビューでの評価）です。

FP&A は、このガードレールが健全に機能しているかを監視する「ルールの設計者と審判」の役割を担うことで、チームの自律性を奪うことなく全社的な資本規律を維持します。

9.5 4つの取り組みの比較

	資金を付ける単位	見直しの頻度	FP&A の主な役割
ING	トライブとスクワッド	四半期（QBR）	目標と依存関係のすり合わせを支える
Equinor	部門ごとの目標と動的な資源配分	出来事に応じて	目標・予測・配分を分けて運営する
John Deere	450超のデジタルプロダクト	柔軟な資金配分へ移行中	プロダクト別の原価を見える化する
SAFe（枠組み）	バリューストリーム	年2回程度（第5版）	参加型予算とガードレールを運営する

【上級者向けコラム】3社の事例をどう読むか

ING、Equinor、John Deere は、同じ仕組みを導入した3社という位置づけではありません。ING は組織設計や四半期ビジネスレビュー、Equinor は目標・予測・資源配分の分離、John Deere はプロダクト単位の原価可視化に、それぞれ異なる特徴があります。

本稿では、公開資料から「短い開発サイクルと経営の意思決定をどう接続するか」という観点の示唆を抽出しています。各社が、本稿で提案するベロシティからのレンジ計算や CFO 報告書の全項目を、そのまま採用しているという意味ではありません。

第10章　導入の手順と落とし穴

10.1 導入の5段階

10.2 よくある落とし穴

落とし穴	何が起きるか	対策
ベロシティを KPI にする	ポイントの水増しが起き、予測に使えなくなる [3][21]	報告には時期と金額の幅だけを載せる
チーム間でベロシティを比べる	ポイントの尺度はチームごとに違うので比較は無意味（5.3節）[2][4][34][35]	比べるなら成果（KPI への効果）で比べる
「ポイント単価」で生産性を測る	見積もりが膨らむ	費用はスプリント単位で固定として扱う
年次予算を一切変えずに上に載せる	二重管理になり、現場が疲れる	既存の年次・四半期の仕組みを作り替えて使う [15]
FP&A がタスクの細部まで追う	チームの自律が損なわれる	FP&A はスプリントレビューとリリース予測に集中する

第11章　まとめ

図：スクラムの指標を「幅」に翻訳し、既存の月次・四半期のリズムに乗せて CFO に届ける。

スクラムの指標は、そのままでは財務の数字になりません。FP&A は、それを 完了時期の幅、残りコストの幅、売上計上時期のずれ に翻訳します。
ベロシティは 予測の道具 です。目標にしたり、チーム間で比べたりすると、予測にも使えなくなります。
3つの可視化ツールからは、配分（スクラムボード）、完成したもの（スプリントボード）、時期とコストの幅（リリースバーンダウン）を読みます。
FP&A はスクラムチームの外から、判断材料と配分の提案で軌道修正に関わります。バックログの順番はプロダクトオーナー、投資枠は CFO が決めます。
CFO への報告は、 幅で示し、P&L への影響額に直し、最後に意思決定を求める 形にします。
ING は四半期の中間の刻み、Equinor は目標・予測・配分の分離、John Deere はプロダクト別原価という、それぞれ異なる角度から、スクラムと財務管理をつないでいます。
ASU 2025-06 により、スクラムのデータが資産計上の判断にも使われるようになり、FP&A とスクラムチームの協働はさらに重要になります。
欧米企業も「統合が完成した」わけではなく、資金を付ける単位・見直しの周期・指標の翻訳という3つの共通論点に、業種ごとに違う入口から取り組んでいる途中です。
スクラムの源流は日本の製造業にあり、適用範囲はソフトウェアに限りません。日本企業にとっては、スクラムと FP&A を同時に設計できる機会であり、最初の一歩は「予算は固定・予測は更新」の明文化と、財務と開発が一緒に書く翻訳ツリーです。

第12章　関連記事 ― 先行する議論との共通点と相違点

本稿のテーマに近い英文・和文の記事を、「本稿との距離が近い順」に並べます。

各記事について、概要、本稿との共通点、相違点をできるだけ対等に書きました。

本稿の主張が唯一の正解ではなく、別の切り口から同じ問題に取り組んだ先行例がある ことを示すためです。

12.1 Scrum.org「Small batch delivery & big batch finance: how to speak the language of forecasting」（Robert Pieper、2017年2月）

概要：スクラムやカンバンで短いサイクルの納品ができるようになったチームが、それでも毎年12月に「年間の施策を見積もれ」と財務から求められる、というずれを扱った記事です。

筆者は、ソフトウェア開発は複雑系であり、株価予測やハリケーンの進路予測と同じく、長期になるほど不確実性が指数的に広がる「不確実性のコーン（cone of uncertainty）」で考えるべきだと説きます。

処方は「増分的な財務（incremental finance）」で、大きな施策を3か月程度で完全に終わる単位に分割し、その単位で資金を付け、定期的に予測を点検して更新することを勧めています [47]。

共通点：①年次予算と短い開発サイクルの「時間の刻みの違い」を問題の中心に置く点、②予測を点ではなく幅（コーン）で示す点、③定期的に予測を更新する点は、本稿の第3章・第5章と同じです。

相違点：Pieper 氏の記事は開発側から財務に向けて書かれており、提案の中心は「資金を付ける単位を小さくする」ことです。

本稿は財務側（FP&A）から書いており、資金単位の分割ではなく 常設チームに資金を付け、予測を四半期・月次で更新する 側を主に扱います。

また同記事はベロシティを金額に変換する手順や、CFO への報告様式には踏み込んでいません。

一方で、本稿が十分に扱っていない「大きすぎる施策をそもそも小さくする」という論点は、同記事のほうが明確です。

12.2 Scrum.org「The Art of the Agile Forecast: 4 Core Practices」（2025年）

概要：投資判断に使える予測と、学習と方向転換を許す俊敏さを、どう両立させるかを4つの実践にまとめた記事です。

第1の実践は「再予測（re-forecasting）をアジャイルのリズムにする」ことで、固定した予測の中では俊敏さがほとんど残らない、と述べます。

予測の粒度についても、日程は週や日ではなく月・四半期・幅で、予算は個別プロジェクトではなくチーム単位で、スコープは作業ではなく成果で、と勧めています。

さらに、予測は実績データに基づく経験的なものであるべきで、最善・最尤・最悪（例：30日・45日・80日）のように括弧で示し、遠い予測ほど括弧を広くする、としています [48]。

共通点：「予算はチーム単位」「予測は幅で」「頻繁に再予測」という3点は、本稿の結論とほぼ一致します。本稿の第2章で示した FP&A の四半期・月次の予測更新は、同記事の言う「再予測のリズム」の財務側の実装と言えます。

相違点：同記事は予測の「作り方」の原則を扱い、FP&A や CFO という財務の役割、年次予算との関係、会計処理には触れません。本稿は、その予測を 誰が、どの会議体で、どの様式で経営に届けるか に重点を置いています。逆に、同記事の「最善・最尤・最悪の3点」は、本稿の「低値・高値の2点」より情報量が多く、CFO 報告に取り入れる価値があります。

12.3 BCG「Agile Meets Beyond Budgeting」（Martin Danoesastro、Bjarte Bogsnes、Sebastian Stange、2021年3月）

概要：大企業がアジャイルを全社に広げても予算編成だけは手つかずのまま残りがちで、アジャイルの成果が旧来の資金承認プロセスにぶつかって失速する、という問題提起から始まります。

アジャイルは現場のチームから上へ、Beyond Budgeting は経営の中核プロセスから下へ変化を広げる、という対比を示したうえで、伝統的予算が「目標」「予測」「資源配分」の3つの目的を1つの数字で兼ねていることを問題の根本とし、3つを分離することを勧めます。

事例として、1970年以来予算を持たない Handelsbanken と、2005年に伝統的予算を廃止し、設備投資を年次予算ではなく随時の案件承認で決める Equinor を挙げています [49]。

共通点：目標・予測・資源配分の分離、Equinor の事例、「予算が年に1回しか開かない銀行の窓口」になっている問題意識は、本稿の第2章・第9章と重なります。本稿の Equinor の記述は、この記事と同じ著者（ボグスネス氏）の資料に多くを負っています。

相違点：BCG の記事は、組織運営モデルとしてのアジャイルと Beyond Budgeting の接続を論じる戦略論であり、スクラムの指標（ポイント、ベロシティ）を扱いません。

本稿は、Beyond Budgeting を全面採用しない企業（年次予算を残す多数派）でも使える、 指標レベルの翻訳手順 に焦点を当てています。

また、同記事が挙げる Handelsbanken（予算も個人目標もない）は、本稿の「年次予算＋四半期予測」の二層構造より急進的なモデルであり、本稿ではあえて扱っていません。

12.4 Medium「Scrum in FP&A: Unleashing Agility in Financial Planning and Analysis」（Christian Martinez、2023年5月）

概要：FP&A チーム自身の業務（予算編成、予測、分析プロジェクト）に、スクラムのスプリント、プランニング、デイリースタンドアップ、レビューを適用する、という趣旨の記事です。

FP&A やファイナンス・トランスフォーメーションのプロジェクトを、より柔軟に、協働的に進めることを目指しています [50]。（有料会員向け記事のため、本稿では冒頭の公開部分に基づいて要約しています。）

共通点：「スクラム」と「FP&A」という同じ2つの言葉を扱い、財務部門がアジャイルの考え方を取り入れる必要性を認める点は共通です。

第9章の ING で、財務などの支援部門が別の形でアジャイルを取り入れたこととも通じます。

相違点：方向が逆です。同記事は FP&A の仕事の進め方をスクラムにする 話で、本稿は スクラムで動く開発チームの進捗を FP&A が読み、CFO に報告する 話です。

両者は補完関係にあります。

FP&A 自身がスプリントで予測を更新する運用（同記事）は、本稿の月次・四半期の予測更新を、より短いリズムで回す一つの方法になりえます。

12.5 その他の関連記事

記事	概要	本稿との関係
Forbes JAPAN「CFOの新たな役割：アジャイルプロセスによる価値創造」（Bryan Lapidus（AFP）、2025年12月）[51]	年次予算や硬直した報告サイクルは安定性のために設計されたもので、変化への対応を遅らせうる。財務部門はコンプライアンス主導からアジリティを可能にする存在へ転換すべきとし、統合計画プロセスなど4つの実践テーマを示す	AFP の実務者育成責任者による和文記事。本稿の第2章で引いた AFP 調査と同じ組織の立場から、財務側の変化を説く。スクラム指標には触れない
Scrum.org「How Do You Make a Good Forecast?」（Martin Hinshelwood、2019年10月）[52]	「バーンアップでは経営に受け入れられない。追加予算400万を得るための予測はどう作るか」という質問に答える記事。ベロシティとポイントは未成熟なチームには有効としつつ、予測可能性のためにはフロー指標（Vacanti 氏の Actionable Agile Metrics for Predictability）を勧める。チームの運営費用は財務に聞けばわかる、とも述べる	本稿 5.2 のコラム「フロー指標」と同じ立場。「チーム費用は既知」という前提も本稿 3.3 と一致
InfoWorld「Let's talk about devops, CFOs」（2017年11月）[53]	開発側から CFO への「公開書簡」の形式で、予算提案が肥大化し、誰もが必要以上の金額を取り合い、資源配分の方法が事業の働き方と根本的に食い違っている、と訴える	本稿第3章の問題意識を、開発側の言葉で率直に述べた記事。処方は本稿ほど具体的ではない
McKinsey「Agile funding」[13]、Thoughtworks「Funding agility」[15]、Bain「Funding Agile」[14]	いずれも本稿第3章・第9章で引用済み。プロジェクトから常設チーム（プロダクト、ポートフォリオ）への資金配分の転換を説く	本稿の「資金を付ける単位」の議論の土台。指標の翻訳や CFO 報告様式は扱わない

12.6 関連記事から見た本稿の位置

本稿は、これらの先行議論の「あいだ」を埋めることを狙っています。

開発側の記事は財務の様式に踏み込まず、経営モデルの記事はスクラムの指標に踏み込まず、財務側の記事は開発チームの進捗データを扱っていません。

その三者をつなぐ、指標レベルの翻訳手順と役割分担が、本稿の付け加えたい部分です。

おわりに — 数学・ソフトウェア・データサイエンス・経営をつなぐ問題意識

今回の記事では、スクラムによる開発現場の進捗や予測を、FP&Aを通じて財務計画・コスト・売上・経営判断へとつなぐ方法を考察しました。

異なる立場から得られる情報を構造化し、組織全体の意思決定に結びつけるという問題意識は、筆者が数学・ソフトウェア・データサイエンス・経営を横断して取り組んでいるテーマにも通じています。

今後も、筆者は次のような問題意識を軸に、数学・ソフトウェア・データサイエンス・経営を横断する記事を書いていきたいと考えています。

圏論・定理証明支援系：数学的構造をプログラミング言語や証明の世界につなぐ。
トポス理論・圏論論理学：論理と数学的構造の関係を探り、異なる対象を統一的に捉える視点を考える。
層（Sheaf）とリスク・異常管理：局所的な情報をどう整合させ、組織全体のリスクを捉えるか。
幾何学的データサイエンス：微分幾何学や位相的データ解析（TDA）などを通じて、複雑な社会・経済データを幾何学的・位相的な構造として扱う。
FP&A × ERM：現場の進捗や予測を、財務計画・全社的リスク管理・経営判断につなぐ。

これらのテーマを横断する筆者の関心は、数学の抽象的な構造を探究し、それをソフトウェアやデータの理解に生かし、さらに企業や社会の問題を考えるための道具にできないか探ることにあります。

数学・ソフトウェア・データサイエンス・経営は、一見すると別々の世界です。

しかし、複雑な対象を構造化し、局所的な情報から全体像を捉え、意思決定に役立つ形へ変換するという問題意識で、私の中ではつながっています。

もちろん、数学的な層と企業のリスク管理が、そのまま同じ構造を持つという意味ではありません。

数学の概念が実務のどこに適用でき、どこに限界があるのか。
その接点を探ること自体が、取り組みたい研究テーマの一つです。

圏論やトポス理論の記事を読んでくださった方が、次にはスクラム・FP&A・ERMの記事に出会う。
そんな分野横断的な発信も、これから続けていきたいと思います。

なお、最後から２番目の視座については、この視座（問題意識）を企業経営に応用する構想として、微分幾何学・TDA（位相的データ解析）・Geometric Data Scienceを活用し、社会経済データから企業を取り巻く経営環境の構造を捉え、経営環境分析、さらには統合リスク環境分析へとつなげる研究にも取り組んでいます。

関連する構想や理論的検討については、以下の記事・リポジトリで紹介しています。

Geometric Data Science × VAE で社会データから立体戦略地形図を作る（Python環境想定）

社会経済データは微分可能多様体だった：Geometric Data Scienceによるリスク曲率解析

Geometric Intelligence Saga — Theory

今後とも、どうぞよろしくお願いいたします。

参考文献

本文中の [番号] は、以下の文献に対応しています。

スクラム

[1] Ken Schwaber, Jeff Sutherland. The Scrum Guide (2020). https://scrumguides.org/scrum-guide.html ／改訂点の解説：https://scrumguides.org/revisions.html
[2] Scrum.org. "Velocity Is Not a Measure of Success." https://www.scrum.org/resources/blog/velocity-not-measure-success
[3] Scrum.org. "Moving Beyond Velocity." https://www.scrum.org/resources/blog/moving-beyond-velocity
[4] Scrum.org. "Don't Confuse Velocity with Success." https://www.scrum.org/resources/blog/dont-confuse-velocity-success
[19] Applied Frameworks. "Scrum Guide 2020 Update: An Impact Summary for Leaders." https://agile.appliedframeworks.com/applied-frameworks-agile-blog/scrum-guide-2020-update-an-impact-summary-for-leaders
[21] Scrum.org. "Scrum Masters, What Are You Measuring in 2025?" (2025年1月9日). https://www.scrum.org/node/92912
[22] Scrum.org Forum. "Is Sprint Velocity meaningful?" https://www.scrum.org/node/70609
[32] Ron Jeffries. "Story Points Revisited" (2019). https://ronjeffries.com/articles/019-01ff/story-points/Index.html
[33] Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2005. ／講演資料 "Introduction to Agile Estimating and Planning" (XP Days Oslo, 2008). https://www.mountaingoatsoftware.com/uploads/presentations/Introduction-Agile-Estimating-Planning-XP-Oslo-2008.pdf
[34] Atlassian. "Estimate in story points." Jira Software Server documentation. https://confluence.atlassian.com/jirasoftwareserver/estimate-in-story-points-938845204.html
[35] Vikas Hazrati. "Comparing Velocity Across Teams." InfoQ (2010年2月). https://www.infoq.com/news/2010/02/comparing-velocity-across-teams
[36] Atlassian Community. "How to handle teams with different ways of estimating." https://community.atlassian.com/forums/Agile-discussions/How-to-handle-teams-with-different-ways-of-estimating/td-p/892667
[37] wibas. "Estimation with Normalized Story Points? Really?"（SAFe の Iteration Planning の解説）. https://www.wibas.com/en/blog/articles-1/estimation-with-normalized-story-points-really-343 ／同 "Agile Estimation in SAFe: Debunking Myths and Clarifying Practices." https://www.wibas.com/en/blog/artikel-1/schatzen-in-safe-mythen-und-gute-praktiken-345
[38] Craig Larman, Bas Vodde. Practices for Scaling Lean & Agile Development. Addison-Wesley, 2010.（見積もりの節の抜粋）https://www.craiglarman.com/wiki/downloads/misc/book%20-%20practices%20for%20scaling%20lean%20and%20agile%20development%20-%20larman%20and%20vodde%20-%20chapter%20planning%20-%20section%20estimation.pdf
[39] Project Management Institute. Agile Practice Guide, 1st ed., 2017, §5.4.1「アジャイルチームは結果を測る」（PM PrepCast による解説）. https://www.project-management-prepcast.com/kunena/free-pmi-acp-exam-questions/14584-free-pmi-acp-exam-sample-question-of-the-week
[40] Scrum.org Forum. "Release burndown chart starting story points"（スクラムガイド 2020 の該当文を引用した回答を含む）. https://www.scrum.org/node/83978
[41] Scrum.org. "Scrum Is No Excuse"（プロダクトオーナーが予測に責任を持つこと、関係者の要求に「ノー」と言えること）. https://www.scrum.org/resources/blog/scrum-no-excuse ／同 "Part II: When will we get there? Forecasting for Scrum teams." https://www.scrum.org/resources/blog/part-ii-when-will-we-get-there-forecasting-scrum-teams
[42] Scaled Agile, Inc. "Business Owners." SAFe. https://scaledagileframework.com/business-owners
[43] Dominic Barton, Dennis Carey, Ram Charan. "One Bank's Agile Team Experiment." Harvard Business Review, March–April 2018. https://hbr.org/2018/03/one-banks-agile-team-experiment
[44] McKinsey & Company. "Quarterly Business Review: How to extract benefits beyond transparency." The Organization Blog. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-organization-blog/quarterly-business-review-how-to-extract-benefits-beyond-transparency
[45] Scrum.org. "What's different in the 2020 Scrum Guide?" https://www.scrum.org/resources/blog/whats-different-2020-scrum-guide
[46] McKinsey & Company. "Planning in an agile organization." https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/planning-in-an-agile-organization
[47] Robert Pieper. "Small batch delivery & big batch finance: how to speak the language of forecasting." Scrum.org Blog, 2017年2月9日. https://www.scrum.org/resources/blog/small-batch-delivery-big-batch-finance-how-speak-language-forecasting
[48] Scrum.org. "The Art of the Agile Forecast: 4 Core Practices." Scrum.org Blog, 2025年. https://www.scrum.org/resources/blog/art-agile-forecast-4-core-practices
[49] Martin Danoesastro, Bjarte Bogsnes, Sebastian Stange. "Agile Meets Beyond Budgeting." Boston Consulting Group, 2021年3月19日. https://www.bcg.com/publications/2021/beyond-budgeting-agile-benefits
[50] Christian Martinez. "Scrum in FP&A: Unleashing Agility in Financial Planning and Analysis." Medium, 2023年5月26日. https://christianmartinezfinancialfox.medium.com/scrum-in-fp-a-unleashing-agility-in-financial-planning-and-analysis-f151deac778e
[51] ブライアン・ラピダス（AFP）. 「CFOの新たな役割：アジャイルプロセスによる価値創造」. Forbes JAPAN, 2025年12月16日. https://forbesjapan.com/articles/detail/87224
[52] Martin Hinshelwood. "How Do You Make a Good Forecast?" Scrum.org Blog, 2019年10月9日. https://www.scrum.org/resources/blog/how-do-you-make-good-forecast
[53] "Let's talk about devops, CFOs." InfoWorld, 2017年11月29日. https://www.infoworld.com/article/2259981/lets-talk-about-devops-cfos.html
[54] Hirotaka Takeuchi, Ikujiro Nonaka. "The New New Product Development Game." Harvard Business Review, January 1986. https://hbr.org/1986/01/the-new-new-product-development-game
[55] トヨタ自動車. 「トヨタ生産方式」（企業サイト）. https://global.toyota/jp/company/vision-and-philosophy/production-system/
[56] Ken Schwaber. "SCRUM Development Process." OOPSLA '95 Workshop on Business Object Design and Implementation, 1995. http://www.jeffsutherland.org/oopsla/schwapub.pdf
[57] Oracle. "What is a chief financial officer (CFO)?"（CFO 傘下のコントローラー、トレジャラー、FP&A の役割）. https://www.oracle.com/erp/cfo/what-is-a-cfo/
[58] R. Timothy S. Breene, Paul F. Nunes, Walter E. Shill. "The Rise of the Chief Strategy Officer." Harvard Business Review, October 2007. https://hbr.org/2007/10/the-rise-of-the-chief-strategy-officer
[59] The Institute of Internal Auditors. The IIA's Three Lines Model: An update of the Three Lines of Defense (2020). https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/

FP&A

[5] Santa Clara University. "Financial Planning and Analysis in Corporate Finance"（AFP による FP&A の定義を引用）. https://onlinedegrees.scu.edu/media/blog/financial-planning-and-analysis-in-corporate-finance
[20] Wall Street Prep. "Financial Planning and Analysis (FP&A)." https://wallstreetprep.com/knowledge/financial-planning-and-analysis-fpa
[25] Association for Financial Professionals. "Surprise: Most Firms Still Do Traditional Budgeting"（2017 AFP FP&A Survey "How Relevant is Your Budget?" の結果発表、2017年12月5日）. https://www.financialprofessionals.org/training-resources/resources/articles/Details/surprise-most-firms-still-do-traditional-budgeting
[26] Association for Financial Professionals. "AFP Survey Reveals Structured Scenario Planning Separates Top-Performing Corporate Finance Teams"（2026 AFP FP&A Benchmarking Survey のプレスリリース、2026年1月20日）. https://www.financialprofessionals.org/about/learn-more/press-releases/Details/afp-survey-reveals-structured-scenario-planning-separates-top-performing-corporate-finance-teams ／報告書本体：https://www.financialprofessionals.org/training-resources/resources/survey-research-economic-data/Details/afp-fpabenchmarking-survey-report-integrated-planning
[27] Association for Financial Professionals. AFP Guide to Implementing a Rolling Forecast: Success Factors and Pitfalls (2015). https://www.financialprofessionals.org/docs/default-source/default-document-library/pub/2015-fp-a-guide-to-implementing-rolling-forecasts-1.pdf
[28] APQC（Perry D. Wiggins）. "Cycle Time to Complete the Annual Budget: Metric of the Month." CFO.com. https://www.cfo.com/news/cycle-time-to-complete-the-annual-budget-metric-of-the-month/655292/ ／APQC. "4 Tips for a Faster and More Effective Budgeting Process." https://www.apqc.org/blog/4-tips-faster-and-more-effective-budgeting-process
[29] APQC. "Metric of the Month: Cycle Time to Prepare the Financial Forecast." CFO.com. https://www.cfo.com/news/metric-of-the-month-cycle-time-to-prepare-the-financial-forecast/658559/ ／調査票（Planning and Management Accounting Open Standards Benchmarking）：https://www.apqc.org/sites/default/files/osb/6735_pma_preview.pdf
[30] Association for Financial Professionals. "Adopting Agile Forecasting and Budgeting Techniques"（2017年1月11日）. https://www.financialprofessionals.org/training-resources/resources/articles/Details/adopting-agile-forecasting-and-budgeting-techniques
[31] Bjarte Bogsnes. "Beyond Budgeting – an agile management model for new business and people realities"（Agile Alliance での講演記録。「アコーディオン型の予測期間」の指摘を含む）. https://www.agilealliance.org/?p=8005143

アジャイル型の資金配分

[13] McKinsey & Company. "Agile funding: An investment management approach to funding outcomes." https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/agile-funding-an-investment-management-approach-to-funding-outcomes
[14] Bain & Company. "Funding Agile." https://www.bain.com/funding-agile/
[15] Thoughtworks. "Funding agility: Moving beyond project budgets." https://www.thoughtworks.com/insights/blog/leadership/funding-agility-moving-beyond-project-budgets
[16] Scaled Agile, Inc. "Lean Budgets." SAFe. https://www.scaledagileframework.com/budgets/
[23] Scaled Agile, Inc. "Participatory Budgeting." SAFe. https://framework.scaledagile.com/participatory-budgeting ／"Lean Budget Guardrails." https://framework.scaledagile.com/guardrails
[24] Scaled Agile, Inc. "Participatory Budgeting." SAFe 5.0. https://v5.scaledagileframework.com/?p=49569

企業事例

[6] McKinsey Quarterly. "ING's agile transformation"（Bart Schlatmann、Peter Jacobs へのインタビュー）. https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation
[7] "An Agile Blueprint for Effective Strategy Execution at ING Group"（事例研究、サンパウロ大学の講義資料として公開）. https://edisciplinas.usp.br/mod/resource/view.php?id=3297761
[8] FP&A Trends. "Beyond Budgeting in Statoil"（Bjarte Bogsnes）. https://fpa-trends.com/tv-series/beyond-budgeting-statoil
[9] Elizabeth Harrin. "Beyond Budgeting: an interview with Bjarte Bogsnes (part 2)." A Girl's Guide to Project Management. https://rebelsguidetopm.com/?p=6092
[10] Bjarte Bogsnes. "Beyond Budgeting – an agile management model for new business and people realities: Ambition to Action – the Statoil journey"（講演資料）. Agile Alliance. https://www.agilealliance.org/wp-content/uploads/2016/09/2263_BeyondBudgeting.pdf
[11] Sebastian Stange, Bjarte Bogsnes, Hardik Sheth. "The Future Is Beyond Budgeting." Boston Consulting Group (2021). https://www.bcg.com/publications/2021/the-future-is-beyond-budgeting
[12] TBM Council. "How TBM & Product Costing Helped John Deere Accelerate their Agile Transformation"（2022 TBM Council Award Winner）. https://www.tbmcouncil.org/case-studies/how-tbm-product-costing-helped-john-deere-accelerate-their-agile-transformation/

会計基準

[17] EisnerAmper. "Modernized Accounting Guidance for Internal-Use Software Costs"（ASU 2025-06 の解説）. https://www.eisneramper.com/insights/pcs/internal-use-software-costs-accounting-guidance-1025/
[18] Pease Bell. "ASU 2025-06: How It Changes Your Internal Control Assessment." https://www.peasebell.com/insights/asu-2025-06-internal-use-software/

本稿の数値例（売上30億円、1スプリント600万円など）はすべて説明のための架空のものです。
企業事例の記述は、上記の公開資料に基づいており、各社の現在の運用とは異なる可能性があります。