この記事はラクス Advent Calendar 2025の11日目の記事です
はじめに
今年、私たちの開発チームでは、「ちゃんとしたアジャイル開発組織になりたい」という思いから、チーム全員の認識をそろえる目的でアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を輪読しました。
本記事では、輪読会で出てきたリアルな議論や気づきを中心にまとめていきます。
書籍のまとめというより、「現場でどう感じ、どう適用しようとしたか」に重きを置いています。
本書では大きく「第1部〜第6部」の構成になっており、本記事でもそれに沿って振り返っていきます。
輪読会の進め方
輪読会は毎週担当者を決め、次のような流れで進めました。
- 各自が予定範囲を読み、まとめと「話し合ってみよう」への自分の考えを事前に記載
- 当日は担当者がファシリテーションを担当
- 意見の違うポイントをディスカッション
- 最後に「自分たちのプロジェクトではどう取り入れる？」を決める
ただ読むだけではなく、「自分たちの開発にどう適用できるか」を常に意識した点が良かったところだと感じています。
第1部：問題とゴール ─ なぜ計画が必要なのか
良い計画とは何か
本書では、見積もりや計画づくりは誤りやすい作業だと認めたうえで、「それでも避けて通ってはいけない」と強調されています。
良い計画とは、意思決定の根拠として“信頼できる”もの です。
ここでいう「信頼」とは、「見積もりにコミットすること」ではありません。
- 不確実性コーン（プロジェクト初期は見積もりの誤差が大きいことを示すモデル）が示すように初期のブレは避けられない
- だからこそ最初は幅を持たせたスケジュールを出す
- そのほうが事業判断に役立つ
という考え方が腑に落ちました。
チームでの議論：計画しすぎることの危険性
輪読会で盛り上がったテーマがこちらです。
「計画しすぎることは、計画しないのと同じくらい危険」
これについてチームからは、次のような意見が出ました。
- 変更に弱くなる
- 管理コストばかり増える
- 見積もりに余計な時間がかかる
結局のところ、 大事なのは計画そのものではなく「計画づくりのプロセスそのもの」 だと改めて感じました。
第2部：規模を見積もる ─ ストーリーポイントと理想日
ストーリーポイントの本質
ストーリーポイント（開発規模の大きさを相対的に表すポイント）で大事なのは、相対的な大きさを測ることです。
- 期間ではなく規模を見積もる
- ベロシティ（1回のイテレーションで完了したストーリーポイントの合計）で初めて期間に変換される
- チーム全体で見積もることに価値がある
ここでいうイテレーションは、一定期間ごとに区切って反復的に開発するサイクルを指しています（スクラムでいうスプリントとほぼ同じイメージです）。
輪読会では、「犬種見積もり（ドッグポイント）」の例や「象は何ドッグポイント？」のたとえがやっぱり話題になりました。
どんなに複雑な見積もりの話でも、測る“軸”が揃っていて定量化できればシンプルになるということがよく分かります。
理想日との違い
理想日とは、「中断も割り込みもなく、その作業だけに集中できた場合にかかる日数」を基準に見積もる考え方です。
| ストーリーポイント | 理想日 | |
|---|---|---|
| メリット | 規模の比較がしやすい / 能力差を持ち込まない / 早く見積もれる | 説明しやすい / 導入しやすい |
| デメリット | 最初の理解コストがある | 実作業時間との差が出やすい / メンバー間でズレやすい |
うちのチームでは自然とストーリーポイント派が多数でした。
利用経験のあるメンバーが多く、導入しやすかったのも理由です。
プランニングポーカーの価値
プランニングポーカーとは、カードを使って複数人で見積もりを行う手法です。
「専門家が見積もる」従来の文化と違い、チーム全員で合意して見積もるのがプランニングポーカーの本質です。
見積もりは早ければ早いほど良いですが、議論するコストと得られる精度のバランスを取る必要があると改めて理解しました。
第3部：価値のための計画づくり ─ ユーザーストーリーの分割
ここで出てくるユーザーストーリーとは、「ユーザーが何をしたいか」「どんな価値を得たいか」を短い文章で表現した要求のことです。
分割の難しさと、私たちの現実的な結論
大きすぎるストーリーは分割が必須ですが、細かくしすぎるとユーザー価値が見えなくなるというジレンマがあります。
特に話題になったのがシステム刷新案件の分割の難しさです。
新規開発ならユーザー価値ごとに切りやすいですが、既存機能の再実装だと “価値の粒度” が把握しづらいと感じています。
議論の結果、業務フローや操作単位で分割するのが最も現実的という結論に落ち着きました。
タスクとストーリーの違いを誤らない
ここでいうタスクは、「API 実装」「テストコード追加」のような作業単位のことです。
タスク基準で考え始めると、「作業を終わらせること」が目的化してしまいます。
その結果、
- 顧客価値を優先できない
- 優先順位の判断基準がずれる
- チーム内での価値共有が弱まる
といった問題につながります。
“アジャイルの根本がここにある” と感じたポイントでした。
第4部：スケジュールを立てる ─ イテレーションとベロシティ
イテレーションの長さをどう決めるか
次の観点で議論しました。
| 観点 | イテレーションを… |
|---|---|
| リリースが頻繁 | 短くする |
| 不確実性が高い | 短くする |
| フィードバックが得やすい | 短くする |
| 優先順位が揺れる | 短くする |
| 回帰テストが重い | 長くする |
現場の状況を踏まえ、私たちのチームでは2週間が最適という結論にしました。
もし2ヶ月イテレーションにしたら？
思考実験として「2ヶ月スプリント（※スプリント＝イテレーションと同じ意味で使っています）」を検討しましたが、デメリットがかなり目立つ結果になりました。
- プランニングが長くなる
- レビューで“2ヶ月前の成果”をデモするはめになる
- 記憶が持たず効率が下がる
- もはやウォーターフォールに近づく
結果として、やってはいけない未来が見えました…。
ベロシティの見積もり方法
ベロシティの見積もり方法としては、次の3パターンが紹介されています。
- 実績値を使う
- 実際に1イテレーションやってみる
- 最終手段として予想する
実績が揃っていないなら、1イテレーション回してみるのが最も合理的で、チームの納得感も高いという点に共感しました。
第5部：トラッキングと情報共有 ─ モニタリングの実践
ベロシティは“オール・オア・ナッシング”
ベロシティに含めるのは、完了したストーリーのみです。途中のストーリーを含めない理由は、「途中になった要因分析が大事だから」です。
リリースバーンダウンが強い
ここでいうリリースバーンダウンチャートとは、リリースまでに残っている作業量の推移をグラフ化したものです。
折れ線で推移を可視化することで、
- どれだけ残っているか
- 完了の傾向がどう変化しているか
がよく分かります。
チーム内でも「一番使えそう」と評判でした。
見積もり vs 実績を比較しない
本書で明確に否定されているのが、
- 見積もりと実績の比較で人を評価する
- 個人のベロシティを測る
といった考え方です。
見積もりがズレたときに大事なのは「責めることではなく学び」であり、これは私も強く共感したポイントです。
第6部：アジャイル計画づくりがうまくいく理由
まとめると、アジャイル計画は次の特長によってうまく回るのだと感じました。
- 異なるレベルで計画を立てる（リリース / イテレーション / 日次）
- 計画を頻繁に見直す（不確実性を前提にする）
- フィーチャー基準で考える（ここでは「ユーザーにとって意味のある機能単位」というニュアンス）
- 規模から期間を導く（ベロシティで割る）
- 仕掛かりを小さく保つ（サイクルタイムを短くする）
- チーム全体でトラッキングする（属人化を防ぐ）
また、チームから出た本書には書かれていない気づきも印象的でした。
心理的安全性が高いからこそ、問題が早く顕在化する。
密なコミュニケーションとチーム単位の姿勢がアジャイルの前提になっている。
これは、実務の現場でしか見えない “本質” だと感じています。
輪読会を経て、実際に決めたアクション
優先度「高」として決定した改善策は次のとおりです。
1. ストーリーポイント見積もりの導入
まずは自分たちの裁量で動けるプロジェクトから導入し、外部チームに対してはフィーチャー単位での依頼をリクエストする方針にしました。
2. スプリントゴールの明確化
価値を届けられるイテレーションにするため、毎スプリントで明確なゴールを定めることにしました。
3. 定期的なリリースプランニング
リリースプランニングは、「どのタイミングでどの機能をリリースしていくか」をチームで整理する場のイメージです。
現在はざっくりとしたWBSで済ませている部分が多いため、スプリントプランニングと合わせてリリースプランニングを定例化することにしました。
4. レトロスペクティブの改善
レトロスペクティブ（ふりかえり）では、よく「Keep / Problem / Try」のように整理して議論しますが、「Keep が続かない問題」がありました。
「Keep が続かない問題」を解消するため、外部ツール（例：Findy Team+など）の活用も含めて検討することにしました。
まとめ：輪読会で得られた 3 つの学び
1. アジャイルでも計画は必須
「アジャイルだから計画なし」は誤解です。
ただし、更新される前提で運用する計画です。
2. フィーチャー視点で考える
タスクではなく、価値単位で考える必要があります。
「◯◯API を開発する」はタスクであって、フィーチャーではないという意識が重要です。
3. チーム全体で価値を届ける
心理的安全性、密なコミュニケーション、属人化させない計画。
個人の責任がなくなるわけではありませんが、「チーム全体で価値を届ける」という姿勢が根底にあると感じました。
おわりに
輪読会を通じて、ただ本を読むだけでは得られない“現場の議論”が多く生まれました。
特に印象に残ったのが、この対比です。
| 従来のマネジメント | アジャイルのマネジメント |
|---|---|
| 人を制御する（Control） | 環境を整え、成果が出る状態をつくる（Enablement） |
この意識の転換こそが、アジャイル計画づくりの本質だと感じています。
「どう適用するか」を議論することこそ、最大の学びになると思います。