アジャイルのプロジェクト計画書｜変化を前提にした書き方

2026年8月1日

＠SOHO編集部

この記事のポイント

✓アジャイル開発のプロジェクト計画書は
✓細部を最初に決め切るのではなく
✓目的と範囲と進め方を決め

アジャイル開発でもプロジェクト計画書は必要です。ただし、従来型の計画書のように機能の細部や日程を最初にすべて決め切るものではなく、「なぜ作るのか」「どこまでを作るのか」「どう進め、どう変えていくのか」を関係者で合意し、状況に合わせて書き換えていく文書になります。「アジャイルなのに計画書を求められた」「どの項目を書けばよいか分からない」という人に向けて、書くべき項目、記入例、更新の仕方、よくある失敗までを順に説明します。計画書そのものは文書作成ソフトで作り、日々の作業の一覧や日程は Pinateca のようなタスク管理の道具で別に管理すると、計画書を書き換える手間を抑えられます。

アジャイル開発で計画書が求められる理由

アジャイル開発は、作るものを小さく区切り、1〜4週間ほどの短い期間（スプリント）で作って確かめることを繰り返す進め方です。途中で作るものが変わる前提なので、「計画書は要らない」と誤解されることがあります。しかし実際には、会社の予算の承認、発注と受注の契約、関係部署への説明のために、プロジェクトの全体像を示す文書はほぼ必ず求められます。

アジャイル開発で計画を立てないわけではない、という点は、公的な資料でもはっきり書かれています。情報処理推進機構（IPA）の「アジャイル開発の進め方」は、作業の一覧（プロダクトバックログ）について次のように説明しています。

プロダクトバックログは、プロダクト(製品)へ追加する要求(ストーリー)のリストをいう。顧客を含むステークホルダーの分かる言葉で書かれている必要がある。このリストはプロダクトオーナー(PO)が管理する。このリストは、優先順位づけされて並んでいることが重要である。また、プロダクトの開発が続く間、変化し続け、維持される。出典: IPA「アジャイル開発の進め方」（2024年5月）

ここで言われているのは、作業の一覧は「変化し続ける」ものだということです。アジャイルの計画書は、この変化し続ける一覧を支える枠組み、つまり目的、範囲の上限、進め方、変えるときの決まりを先に合意しておく役割を担います。細部は変わっても、枠組みが合意されていれば、関係者は安心して変化を受け入れられます。

近年は、Webサービスやアプリの開発会社だけでなく、社内の業務システムを自分たちで作り直す企業、自治体の窓口のデジタル化、医療や介護の記録システムの入れ替えなど、アジャイル開発を取り入れる場面が広がっています。計画型の進め方に慣れた組織にアジャイル開発を持ち込むとき、最初に問われるのが計画書です。従来の形式のまま書くと、アジャイルの利点が消えてしまい、逆に何も書かないと承認が下りません。その間をうまく埋める書き方を知っておくことが、アジャイル開発を組織に根付かせる最初の一歩になります。

従来型の計画書とアジャイルの計画書の違い

従来型（ウォーターフォール型）の計画書とアジャイルの計画書では、決める内容の粒度と、文書の扱い方が違います。

比べる点	従来型の計画書	アジャイルの計画書
範囲	機能の細部まで決める	目的と大きな機能の項目、範囲の上限を決める
日程	工程ごとの開始日と終了日を決める	リリースの目安と区切りの長さを決める
予算	作業量の積み上げで決める	区切りの回数とチームの人数から上限を決める
変更	例外として変更の手続きを取る	変更の決め方を最初に書いておく
文書の扱い	承認後は原則として変えない	区切りごとに見直し、版を重ねる

最も大きな違いは「範囲」と「変更」の扱いです。従来型は範囲を固定して日程と予算を見積もりますが、アジャイルは日程と予算の枠を先に決め、その中で作る範囲を入れ替えます。「予算と期間は守る、そのかわり作るものの中身は優先度の高い順に決めていく」という考え方を、計画書の最初で関係者と共有しておくことが大切です。

もう1つの違いは、計画書を1回書いて終わりにしないことです。区切りごとの振り返りで分かったこと（チームが2週間でどれだけ進めるか、利用者の反応がどうだったか）を受けて、リリースの目安や優先順位を書き換えます。計画書の表紙に版の番号と更新日を書いておき、何が変わったかを記録に残すと、関係者が最新の版を見失いません。

アジャイルのプロジェクト計画書に書く12の項目

アジャイルの計画書に決まった書式はありませんが、次の12の項目を押さえておけば、承認する側の疑問にほぼ答えられます。

目的：このプロジェクトで何を実現したいのかを1〜2文で書きます。
背景：今どんな問題があるのかを、数字や具体例で書きます。
成功の物差し：何がどうなれば成功と言えるのかを、測れる形で書きます。
プロダクトゴール：作るものが最終的にどんな状態になっていればよいかを書きます。
範囲：大きな機能の項目と、今回はやらないことを書きます。
リリースの目安：最初に利用者に届ける時期と、その後の見通しを書きます。
体制と役割：誰が優先順位を決め、誰が作り、誰が確認するかを書きます。
進め方：区切りの長さ、定例の会議、確認の場の持ち方を書きます。
完成の定義：作業が「終わった」と言える条件を書きます。
予算と見積もりの考え方：予算の上限と、その根拠を書きます。
リスクと対応：起こりうる問題と、その時の手当てを書きます。
変更の決め方：優先順位や範囲を変えるとき、誰がどう決めるかを書きます。

従来型の計画書にない項目は、4のプロダクトゴール、9の完成の定義、12の変更の決め方の3つです。特に12の変更の決め方は、アジャイルの計画書の要と言える項目です。変更を前提とする以上、「誰の判断で、どの範囲までなら変えてよいか」を最初に決めておかないと、変更のたびに承認の会議が開かれ、短い区切りで進めるという利点が失われます。

各項目の書き方と記入例

ここでは、飲食店向けの予約アプリを作るプロジェクトを例に、主な項目の書き方を示します。

目的・背景・成功の物差し

目的は短く、誰のどんな困りごとを解決するのかが分かるように書きます。

目的：電話でしか受けていない予約をスマートフォンからも受けられるようにし、店の電話対応の負担を減らす。
背景：夕方の仕込みの時間帯に予約の電話が集中し、1日あたり平均40分ほど調理の手が止まっている。電話の取りこぼしで予約を逃すことも月に数件ある。
成功の物差し：リリース後3か月で、予約のうちスマートフォン経由の割合を5割以上にし、電話対応の時間を半分にする。

成功の物差しは、測れる形で書くことが大切です。「使いやすくする」「業務を効率化する」のような書き方では、終わったときに成功したかどうかを判断できません。数字にしにくい場合でも、「店長が予約の一覧を1画面で確かめられる」のように、確かめられる状態で書きます。背景の項目には、今の困りごとをできるだけ具体的な場面で書きます。「いつ、誰が、どんな作業で、どれだけ困っているか」が書かれていれば、承認する側も開発のチームも、作るものの優先順位を同じ物差しで判断できます。背景の数字は、プロジェクトが始まる前に1〜2週間ほど実際に記録を取って確かめておくと、成功の物差しと比べる基準にもなります。

プロダクトゴールと範囲

プロダクトゴールは、作るものの最終的な姿です。スクラムの公式の手引きであるスクラムガイドは、プロダクトゴールを次のように説明しています。

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。出典: スクラムガイド 2020年版日本語訳

記入例は「お客さんが空席を見て自分で予約し、変更や取り消しも電話なしでできる状態」です。範囲には、大きな機能の項目を並べ、あわせて「今回はやらないこと」も書きます。

やること：空席の表示、予約の受付、予約の変更と取り消し、店側の予約一覧、予約の確認メール
やらないこと：事前決済、ポイントの付与、複数店舗の一括管理

「やらないこと」を書いておくと、途中で出てくる要望が範囲の内か外かを判断しやすくなります。範囲の外の要望は、次の段階の候補として記録しておき、今回の予算の中では扱わないと決めておけます。

リリースの目安と進め方

リリースの目安は、日付を1つに決め切るのではなく、「最初に予約の受付だけを使える形で届ける時期」と「全機能がそろう時期の見通し」に分けて書きます。進め方には、区切りの長さ（例：2週間）、毎朝の短い打ち合わせ、区切りの終わりの確認の場と振り返りの日時を書きます。確認の場に店長や実際に使うスタッフが参加することを、計画書の段階で明記しておくと、後から日程が取れないという事態を防げます。

完成の定義と変更の決め方

完成の定義は、作業が終わったと言える条件の一覧です。例として「テストが済んでいる」「スマートフォンの主要な機種で表示を確かめている」「店長が試して問題がないと確認している」を挙げます。変更の決め方には、「区切りの中で作る機能の入れ替えはプロダクトオーナーが決める」「範囲の外の機能を加える、または予算の上限を超える場合は、発注側の責任者の承認を取る」のように、判断する人と範囲を分けて書きます。

予算と日程の見積もり方

アジャイルの計画書で承認する側が最も気にするのが、予算と日程です。アジャイル開発では、作る範囲を最初に固定しないので、作業の積み上げで見積もる従来の方法はそのままでは使えません。代わりに、次の考え方で枠を決めます。

まず、チームの人数と区切りの長さから、1回の区切りにかかる費用を出します。 5人のチームが2週間の区切りで動くなら、1回の区切りの費用は「5人の2週間分の人件費や委託費」です。次に、作りたい機能の項目を大まかに見積もり、何回の区切りで主な機能がそろいそうかを見通します。たとえば主な機能がおよそ8回の区切りでそろう見通しなら、予算は「1回あたりの費用×8回」に、見通しの外れに備えた余裕を加えた額になります。

見通しの精度は、最初の数回の区切りを終えると上がります。チームが1回の区切りでどれだけの作業を終えられるかという実績（ベロシティと呼ばれます）が分かってくるからです。計画書には「3回目の区切りを終えた時点で、残りの見通しを見直して報告する」と書いておくと、最初の見積もりの不確かさを承認する側に正直に伝えられます。

予算の上限を決めておき、その範囲で優先度の高い機能から作る、という約束をすると、予算は守られ、作られる機能の中身が変わる、という形になります。承認する側には「予算を超えない代わりに、優先度の低い機能は次の段階に回ることがある」とはっきり伝えておくことが大切です。

計画の3つの層と計画書の関係

アジャイル開発の計画は、期間の長さが違う3つの層に分けて考えると整理しやすくなります。計画書がどの層を受け持つのかを理解しておくと、何を書き、何を書かないかの判断に迷わなくなります。

層	期間の目安	決めること	主に決める人
プロダクトの計画	半年から数年	目的、プロダクトゴール、範囲の上限、予算	発注側の責任者とプロダクトオーナー
リリースの計画	1か月から数か月	次に利用者に届ける機能のまとまりと時期	プロダクトオーナーとチーム
区切り（スプリント）の計画	1〜4週間	その区切りで作る作業と目標	開発者

計画書が主に受け持つのは、いちばん上のプロダクトの計画と、2番目のリリースの計画の見通しです。いちばん下の区切りの計画は、区切りの初めの計画の会議でチームが決めるもので、計画書には書きません。スクラムガイドも、区切りの中の作業の一覧（スプリントバックログ）を「開発者による、開発者のための計画」と位置づけています。

この3つの層を混同すると、計画書に区切りごとの作業まで書き込んでしまい、更新が追いつかなくなります。反対に、プロダクトの計画が抜けていると、区切りごとの判断の拠り所がなくなり、目先の要望に振り回されます。計画書には上の2つの層を書き、下の層は作業の一覧で管理する、という役割分担を最初に決めておくと、文書の量も更新の手間も適切な範囲に収まります。

リリースの計画は、プロダクトの計画と区切りの計画をつなぐ層です。「最初のリリースでは予約の受付と店側の一覧だけを届け、2回目のリリースで変更と取り消しを加える」というように、機能のまとまりと時期の見通しを示します。この見通しは区切りの実績に合わせて変わるので、計画書の中でも更新の頻度が最も高い部分になります。計画書の本文に詳しく書くより、リリースの見通しを1枚の線表にまとめて計画書に添え、線表だけを差し替える形にすると更新しやすくなります。

承認する側に計画書を説明するときのコツ

アジャイルの計画書は、従来型の計画書に慣れた承認者から見ると、決まっていないことが多い文書に見えます。「なぜ機能の細部が決まっていないのか」「本当に予算内に収まるのか」と問われるのは自然なことです。説明の際は、次の3点を押さえておくと理解を得やすくなります。

1つ目は、決まっていないのではなく、決める時期と決め方を決めている、と伝えることです。機能の細部は区切りごとに利用者の反応を見ながら決めること、その判断は誰が行うかを計画書の変更の決め方の項目で示します。

2つ目は、予算の上限は動かないことを強調することです。アジャイルの計画書では、範囲を入れ替えることで予算と期間を守ります。「予算と期間を守る代わりに、優先度の低い機能は次の段階に回ることがある」という約束を、承認する側と最初に結んでおきます。

3つ目は、途中で止められることを伝えることです。区切りごとに動くものができあがるので、数回の区切りを終えた時点で成果を確かめ、続けるかどうかを判断できます。従来型のように最後まで作らないと何も使えない、という状態にならないことは、承認する側にとって大きな安心材料になります。「3回目の区切りが終わった時点で中間の報告をし、続けるかどうかを判断する」という節目を計画書に書いておくと、承認の判断がしやすくなります。

IT以外の業務改善で計画書を書くときの工夫

アジャイルの進め方は、ソフトウェアの開発以外の業務改善にも使われています。店舗の接客の手順の見直し、社内の申請の流れの改善、営業資料の作り直しなど、やってみないと正解が分からない仕事に向いています。こうした取り組みで計画書を書くときは、開発の用語を業務の言葉に置き換えることが大切です。

「プロダクトゴール」は「改善が終わったときの職場の姿」、「区切り」は「2週間ごとの試行の期間」、「完成の定義」は「新しいやり方を現場で1週間試して問題がないこと」というように言い換えます。成功の物差しは、業務の時間や手戻りの件数のように、現場の人が日々の仕事の中で実感できる数字にします。「申請の差し戻しの件数を月20件から10件以下に減らす」といった書き方です。

業務改善では、試したやり方を現場で使い続けてもらうことが最も難しい部分です。計画書の体制の項目に、試行に参加する現場の担当者を書き、その人の業務時間の一部を試行に充てることを、上司の承認とともに明記しておきます。現場の協力が得られる時間を最初に確保することが、IT以外の業務改善をアジャイルで進めるときの成功の鍵になります。

インセプションデッキで計画の前提をそろえる

計画書を書く前に、関係者の認識をそろえる方法として知られているのが「インセプションデッキ」です。プロジェクトの始まりに、決まった10個ほどの問いに関係者で答え、その答えをスライドにまとめるやり方で、IPAの資料でもアジャイル開発を進めるうえでのスキルの例として挙げられています。

よく使われる問いは、次のようなものです。

なぜここにいるのか（このプロジェクトの目的は何か）
エレベーターピッチ（30秒で説明するとどうなるか）
やらないことリスト（今回はやらないことは何か）
ご近所さんを探せ（関わる部署や人は誰か）
夜も眠れなくなるような問題は何か（いちばん心配なことは何か）
トレードオフスライダー（予算、期間、範囲、品質のうち、何を優先するか）

インセプションデッキの答えは、そのまま計画書の目的、範囲、リスク、優先順位の項目の下書きになります。特に「トレードオフスライダー」は、予算と期間と範囲と品質のうち、どれを守り、どれを動かしてよいかを関係者で決める作業で、変更の決め方の項目を書くときの拠り所になります。計画書を1人で書き上げてから関係者に見せるより、インセプションデッキで先に認識をそろえてから書くほうが、承認までの手戻りが少なく済みます。

リスクと対応の項目の書き方

リスクの項目は、従来型の計画書でも書かれますが、アジャイルの計画書では「区切りごとに見直す」ことを前提に書く点が違います。リスクを並べるだけでなく、それが起きたときに誰が何をするか、どの時点で確かめるかまでを書いておくと、実際に役立つ項目になります。

予約アプリの例では、次のように書けます。

リスク	起きたときの影響	対応	確かめる時期
店長が忙しく確認の場に出られない	利用者の声が反映されない	確認の代理をスタッフ1人に決めておく	毎回の区切りの前
予約の重なりを防ぐ処理が想定より複雑	主な機能のそろう時期が遅れる	最初の2回の区切りで先に試作する	2回目の区切りの終わり
外部のメンバーが途中で交代する	進む速さが一時的に落ちる	作業の一覧と判断の理由を記録に残す	体制が変わったとき
既存の電話予約との二重予約	店の信用を損なう	切り替えの期間は店側の一覧で必ず照合する	リリースの前

アジャイルの進め方では、技術的に不確かな部分を早い区切りで先に試すことが、最も効果のあるリスクの対応です。「難しそうな部分は後回し」にすると、終盤で問題が見つかったときに取れる手がなくなります。計画書のリスクの項目に「最初の区切りで試す部分」を明記しておくと、優先順位を決めるときの拠り所にもなります。

リスクの一覧は、区切りの終わりの振り返りで毎回見直し、起きなくなったものは消し、新たに見えてきたものを加えます。一覧の行数が増え続けるようなら、プロジェクトの範囲が広すぎるという合図なので、範囲の見直しを関係者に提案する時期です。

計画書を更新するタイミングと方法

アジャイルの計画書は、書き換えることが前提です。ただし、思いつきで書き換えると、関係者がどの版を見ればよいか分からなくなります。更新のタイミングと方法を決めておきます。

更新するタイミング

区切りの終わりの振り返りで、リリースの目安や優先順位に影響する発見があったとき
3回目ほどの区切りを終え、チームの進む速さの実績が分かったとき
範囲の外の機能を加える、または予算の上限を変える承認が下りたとき
体制が変わったとき（メンバーの交代、確認を担当する人の変更）

更新の方法

表紙に版の番号と更新日を書き、最後のページに「変更の記録」の表を設けて、いつ、何を、なぜ変えたかを1行ずつ記録します。変更の記録があれば、承認する側は前の版との違いだけを確かめれば済みます。計画書の本体には、目的、範囲、進め方のように頻繁には変わらない枠組みだけを書き、日々変わる作業の一覧や担当は、別の道具で管理するのがおすすめです。作業の一覧まで計画書に書き込むと、毎回の区切りのたびに計画書を書き換えることになり、更新が追いつかなくなります。

よくある失敗と対策

アジャイルの計画書で起きやすい失敗を4つ挙げます。

従来型の書式で細部まで書いてしまう

社内の決まった書式に合わせて、画面の細部まで計画書に書いてしまう失敗です。承認された細部が「約束」になり、区切りごとに直すことができなくなります。対策は、画面や機能の細部は「別に管理する作業の一覧で決める」と計画書に明記し、計画書には大きな機能の項目までを書くことです。

成功の物差しがない

目的は書いてあるのに、何をもって成功とするかがないと、区切りごとの優先順位を決める拠り所がなくなります。機能を作ること自体が目的になり、利用者の困りごとが解決したかどうかを誰も確かめなくなります。

確認の場に出る人が決まっていない

区切りの終わりに動くものを確かめる人が決まっていないと、確認の場が開発側だけの報告会になります。計画書の体制の項目に、確認を担当する人の名前と、その人が確認に使える時間を書いておきます。

変更の決め方がない

変更のたびに上層部の承認を求めることになり、短い区切りで進める利点が消えます。「区切りの中の入れ替えは現場で決め、予算と範囲の上限を超えるときだけ承認を取る」という線引きを最初に書いておきます。

計画書と作業の一覧を分けて管理する道具

計画書の本体は、WordやGoogleドキュメントなどの文書作成ソフトで作るのが一般的です。版の管理や承認の記録が残しやすく、社外の関係者にも渡しやすいからです。一方、計画書から分かれた作業の一覧、つまり機能の項目ごとの担当、期限、優先順位、進み具合は、日々変わるので、更新しやすい道具で管理します。

小さなチームなら、ExcelやGoogleスプレッドシートで作業の一覧を作り、優先順位の列で並べ替える方法でも始められます。費用がかからず、誰でも中身を確かめられます。ただし、メンバーが増えると、誰がどの行を更新したのか分かりにくくなり、担当者への連絡も別のチャットで行うことになります。

複数人で担当と期限と進み具合を共有したい場合は、タスク管理の道具が向いています。 Pinatecaは、カンバンボード、ガントチャート、カレンダー、リストなど8種類のボードとチャットを備えたタスク管理の道具で、5人までなら無料で全種類のボードを使えます。計画書のリリースの目安はガントボードで期間として並べて締切の重なりを確かめ、作業の一覧はカンバンボードやリストボードで優先順位の順に並べて進める、という使い分けができます。カードに優先度や見積もりなどの項目を自由に追加できるので、計画書の機能の項目の番号をカードに持たせておけば、計画書と作業の一覧の対応も追いやすくなります。社外のゲストを招待できるので、発注側の確認担当者にも同じボードを見てもらえます。有料のスタンダードプランは1人あたり月額500円（税抜、年払いなら月額400円）で、人数とボードの上限がなくなります。計画書の文書そのものを作る機能ではないので、文書は文書作成ソフトで作り、作業の管理に使う形になります。最新の料金と機能は、Pinateca の掲載ページと公式サイトで確かめてください。 Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

業務委託のメンバーと計画書を共有するときの注意

アジャイル開発のプロジェクトには、業務委託のエンジニアやデザイナーが加わることがよくあります。計画書は、社内の承認のためだけでなく、外部のメンバーがプロジェクトの目的と進め方を理解するための資料にもなります。

外部のメンバーに渡すときは、計画書の目的、範囲、進め方、完成の定義の項目を最初に読んでもらいます。特に完成の定義は、外部のメンバーの成果をどう確かめるかに直結するので、契約の前に合意しておくと後のもめごとを防げます。アジャイル開発の工程は、成果物の完成を約束する請負ではなく、作業そのものを約束する準委任の形で契約されることが多くなっています。計画書の予算と範囲の考え方が契約の形と合っているかは、契約書の内容や事情で変わるので、必要に応じて専門家に確認してください。

外部の立場で参加する人にとっては、計画書を読み解き、自分の担当がどの機能の項目に当たるのかを把握する力が重宝されます。アプリ開発の仕事の中身と必要なスキルは、アプリケーション開発のお仕事で紹介しています。画面の設計を担当するデザイナーとして関わる場合の報酬の目安は、デザイナーの年収・単価相場で確かめられます。

運営者として見てきたアジャイル案件の計画書の傾向

在宅ワークとフリーランスの仲介を2004年から続けてきた立場から見ると、アジャイル開発の案件で外部の人材がうまく力を発揮できるかどうかは、計画書の出来に大きく左右されます。

目的と成功の物差しがはっきり書かれた計画書がある案件では、外部のメンバーも優先順位の判断に自分から加わり、「この機能は成功の物差しに効かないので後回しにしてはどうか」と提案できます。反対に、計画書が機能の一覧だけの案件では、外部のメンバーは言われた作業をこなすだけになり、長い関係になりにくい傾向があります。計画書は承認を得るための書類であると同時に、チームの全員が同じ方向を向くための道具でもあります。

また、発注側と受ける側の間に入る会社が少ないほど、計画書の更新が速く関係者に伝わります。区切りごとに優先順位が変わるアジャイル開発では、変更の意図が伝わるまでの時間が短いことが成果に直結します。中間のマージンが乗らない直接の取引なら、同じ予算で発注側はより多くの区切りを回せ、受ける側も手取りが厚くなります。手数料0%で直接やり取りできる仕組みは、金額の面だけでなく、計画の変更を素早く共有できるという点でも、アジャイル開発と相性がよいと言えます。

計画書づくりや業務の見直しを外部の立場で支援する仕事は、AIや業務ツールの導入の広がりとともに増えています。その仕事の中身はAIコンサル・業務活用支援のお仕事で、経営の助言を体系立てて学べる国家資格については中小企業診断士で紹介しています。開発の現場で計画書を読み解きながら働きたい人は、アプリケーション開発のお仕事で求められるスキルを確かめるところから始めてください。