「アジャイル＝無計画」は誤解？変化に対応し続ける「登山型」計画術

アジャイル

スクラムマスター

レトロスペクティブ

小島啓輔

2025年11月20日

はじめに：「アジャイル＝計画しない」は誤解

「アジャイルだと計画を立てない」
「ウォーターフォールのようにきっちり計画せず、行き当たりばったりで進める手法だ」

こうした誤解を耳にすることがよくあります。しかし、それは大きな間違いだと思っています。

無計画に目の前の作業をこなし続けるだけでは、価値あるプロダクトは生まれません。アジャイルは、計画を重視するウォーターフォールと、計画をしない無秩序な開発の「中道」を行く、あるいは両者の課題を乗り越えた（アウフヘーベンされた）アプローチだと私は考えています。

結論から言うとアジャイルでも計画は立てます。ただし、その「立て方」と「付き合い方」が、ウォーターフォールとは根本的に異なるのです。

アジャイルの計画は「登山の計画」に似ている

アジャイルにおける計画を登山に例えてみようと思います。

登山をするときは必ず「登山計画」を立てるはずです。まずどの山に登るのか、どのルートを通るのか、どのくらいの時間がかかるのか、何を持っていくのか。

しかし、実際に登り始めると、不測の事態が起こり得ます。

「登ろうとしていた道が、昨日の雨で崩れていて通れない...」
「急に天候が悪化し、このまま進むのは危険だ...」

こんな時、あなたならどうするでしょうか
「最初にたてた計画は完璧なはずだ！」「計画通りに進まないとおかしい！」と、通れない道を進もうとしたり、嵐の中で無理やり進んだりはしませんよね。

実際に山を登ったからこそ手に入った最新の情報に基づき、「計画を修正」するはずです。例えば「別のルートを探そう」「今日はここでビバークしよう」のように。

重要なのはちゃんと最初に登山計画を立てている点です。

登山計画があるからこそ、「計画通りではない」という不測の事態を把握することができ、安全に目的地に到達するための最善の判断（計画修正）ができるのです。

アジャイルもまさにこれと同じ考え方だと考えています。最初に計画を立て、開発を進める中で得られた新しい情報（不測の事態、仕様の変更、技術的な問題）に基づき、その時点で最善の計画を立て続けるのです。

なぜ「継続的な計画立案」が必要なのか？

アジャイルがなぜこのような計画の立て方をするのかを「不確実性」という観点から整理してみます。不確実性とは「わからないこと」です。プロダクト開発においては「市場の不確実性（何が求められているか？）」と「技術の不確実性（どう作ればいいか？どのくらいかかるか？）」のような不確実性が存在します。エンジニアリングはこれらの不確実性を削減し、ユーザーにとって価値のある機能を技術的に実現していく営みと捉えることができます。（エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングより）

ウォーターフォールのアプローチ

ウォーターフォール型は、開発を始める前に「不確実性」をできるだけゼロにしようと試みます。計画フェーズで要求や仕様、実装方法などをすべて固め、「何を作るか？」「どうやって作るか？」の不確実性を0にしてから開発フェーズに移るイメージです。

これは、作るものが明確な「煩雑（complicated）系」（クネビンフレームワークより）の問題には有効です。しかし、答えが一つではなく、やってみないとわからないことが多い「複雑（complex）系」の問題に対してこのアプローチを取ると、以下のような問題が起こりがちです。

不確実性を0にするための計画フェーズに、膨大な時間がかかる。
無理やり0にしたつもりでも、実際には不確実性が残っており、開発フェーズで「計画と違う」となり、大きな手戻りが発生する。

計画しないアプローチ（ウォーターフォールの対極）

計画を一切立てず、目先の作業をとにかく潰し続けるアプローチです。これでは、不確実性をコントロールできず、今どこにいるのか、目的地に向かっているのかさえ分かりません。

アジャイルのアプローチ

アジャイルはこれら二つのアプローチに中道的な位置にあると思ってます。

まず、計画時点でできるだけ不確実性を減らす努力をします。
- しかし、「すべてをゼロにすることは不可能」であり、「やってみないとわからないことがある」ことを前提とします。
スプリント（短い開発サイクル）を回しながら、徐々に不確実性を減らしていきます。
途中で発生する状況の変化（市場のニーズ変化、技術的な発見）は「不確実性の増大」と捉え、それも計画に反映していきます。

クネビンの「複雑系」の問題は、まさに「実際にやってみる中で新たな発見がある」領域です。アジャイルは、この未知の不確実性を適切に取り扱い、真に価値を生み出すための手法だと考えています。

具体的にどう計画し、どう見直すのか？

では、アジャイルでは具体的にどのように計画を立て、見直していくのでしょうか。

最初の計画

登山計画と同じように、まずは大きな方針を決めます。

プロダクトゴールを決める（最終目的地）
- このプロダクトで最終的に何を達成したいのか、登山の「最終目的地（山頂）」を明確にします。
エピックを整理し、優先順位を決める（中継地点）
- 目的地に到達するために通らなければならない「中継地点（経由する山小屋や分岐点）」を整理し、どの順番で通過するかを決めます。
プロダクトバックログを作成する（タスク）
- 最初の中継地点に行くために必要なこと（具体的な機能や作業）を「プロダクトバックログ」として洗い出します。山頂に登るまでの全てのタスクを洗い出す必要はないことがポイントです。山を登る中で計画が変更されると、最初に立てた詳細なタスク整理は無駄になってしまう可能性が高いからです。
見積もりと見通しを立てる（所要時間）
- 全体でどのくらいかかりそうかをざっくり見積もります。これも先ほどと同じ理由で精緻に見積もりをする必要はありません。計画を立てるコストを可能な限り最小化し、あとは登りながら計画を立てていくのです。

アジャイルな計画づくり＝継続的な計画立案

アジャイルな計画の核は、この「途中の計画の見直し」にあると考えています。

スクラムではスプリントレビュー、レトロスペクティブ（振り返り）、次のスプリントプランニングといった定期的なイベントのタイミングで必ず計画を見直します。

「実際にやってみたら、思ったより時間がかかった」
「ユーザーからのフィードバックで、こちらの機能が優先だとわかった」
「新しい技術的課題が見つかった」

これらの「変更」や「新しい発見」を、プロダクトゴール、プロダクトバックログ、バーンダウンチャート（見積もり）に反映させることで常にその時点で最善の計画を立て続けます。

アジャイル計画を成功させるコツ

最後に、この「継続的な計画立案」をうまく機能させるための個人的に意識していることをいくつかご紹介します。

関係者全員で話す
計画は一部の人が立てるものではなく、開発者、プロダクトオーナー、ステークホルダーなど関係者全員で対話し、進めるプロセスが重要です。言葉（ドキュメント）だけでは完璧に伝わりません。共に検討するプロセス自体が、強力な「共通認識」を形成します。
目的地から逆算する（バックキャスト）
常に「プロダクトゴール（山頂）」はどこかを意識し、そこから逆算して「今やるべきこと（次の中継地点）」を考えることが重要です。積み上げ（フォアキャスト）も重要ではありますが、それだけで計画を立ててしまうととりあえず目の前のタスクを潰し続ける「計画しないアプローチ（ウォーターフォールの対極）」に陥るリスクがあります。
目的地・中継地点の解像度を高める
なぜそれが必要なのか、それによってどんな価値が生まれるのか、関係者間での「解像度」を高めておくことで、予期せぬ事態が起きても判断がブレにくくなります。「山頂（ゴール）に辿り着いた時に我々はどんな状態なのか？」「プロダクトはどんな状態か？」「ユーザーはどんな状態か？」などの問いかけをしながら関係者内で解像度を高めていきます。
計画しすぎない（割り切る）
これが最も重要かもしれません。不確実性はゼロにはできません。「わからないことは、やってみないとわからない」と割り切って先に進む勇気も、アジャイルな計画には必要です。