アジャイルソフトウェア開発宣言とは？どうやって生まれた？
アジャイルソフトウェア開発宣言は、アジャイルな開発で大切にする価値観を短くまとめた宣言です。原題は Manifesto for Agile Software Development です。「アジャイルマニフェスト」とも呼ばれます。
宣言は2001年2月、アメリカ・ユタ州のスノーバードに集まった17人のソフトウェア開発者がまとめました。当時は、重い手続きに頼らない開発手法がいくつも生まれていました。スクラム、XP（エクストリーム・プログラミング）、DSDM、クリスタルなどです。その考案者や実践者が、手法の違いを超えて共通する価値観を言葉にしたのが、この宣言です。
宣言は公式サイトで各国語に訳されており、日本語訳もあります。原文は短いので、一度は出典のリンクから全文を読んでおくことをおすすめします。この記事では宣言の文を写さず、当サイトの言葉で趣旨を要約しています。
4つの価値とは？
宣言の中心は、次の4つの価値です。どれも「右側にも価値はあるが、左側をより重んじる」という比較の形になっています。
| より重んじるもの | それよりは後に置くもの | 当サイトの解釈（要約） | PMPの場面での例 |
|---|---|---|---|
| 個人と対話 | プロセスやツール | 手順や道具より、人どうしが直接話して協力することを大切にする | 分散チームの誤解は、ツールを増やすより話す場を増やして解く |
| 動くソフトウェア | 包括的なドキュメント | 分厚い文書より、動いて確かめられる成果物で価値と進みを示す | 進捗は文書の完成度ではなく、完了したインクリメントで示す |
| 顧客との協調 | 契約交渉 | 契約の条文で争うより、顧客と同じ側に立って一緒に良いものを作る | 仕様の追加を条文で争わず、優先順位を顧客と一緒に決める |
| 変化への対応 | 計画に従うこと | 最初の計画を守るより、学んだことや状況の変化に合わせて変える | 新しい要望はバックログに入れて並べ直す |
最も誤解されやすいのは、「アジャイルは文書も計画も契約もいらない」という読み方です。宣言は右側の価値も認めています。文書も計画も作りますが、それが目的になって、動くものや顧客との協力が後回しになることを避けます。つまり、優先順位の宣言です。
12の原則は何を言っている？
宣言には、4つの価値を支える12の原則が付いています。以下は当サイトによる要約で、原文の訳ではありません。まず4つのまとまりで全体を見てから、1つずつ確かめます。
12の原則
顧客と価値
1 早く継続的に届ける／2 変化を歓迎／3 短い周期で届ける／7 動くもので測る
協力と対話
4 事業と開発が毎日一緒に／6 顔を合わせて話す
チームと人
5 意欲のある人を信頼／8 持続可能なペース／11 自己組織的なチーム
技術と改善
9 技術的卓越と良い設計／10 シンプルさ／12 定期的なふりかえり
- 価値のあるソフトウェアを早く、継続的に届けて、顧客を満足させることを最優先する
- 開発の後半であっても、要求の変更を歓迎する。変化を顧客の競争力に生かす
- 動くソフトウェアを、数週間から数か月の短い間隔で、なるべく短い周期で頻繁に届ける
- 事業の担当者と開発者は、プロジェクトを通して毎日一緒に働く
- 意欲のある人を中心にプロジェクトを組み、環境と支援を与え、仕事をやり遂げると信頼する
- チームの中で情報を伝える最も効率的で効果的な方法は、顔を合わせて話すことである
- 進み具合を測る一番の物差しは、動くソフトウェアである
- 持続可能な開発を促す。関係者全員が一定のペースを無理なく続けられるようにする
- 技術的な卓越と良い設計に、絶えず注意を払うことが機敏さを高める
- シンプルさ、つまり「やらずに済む作業を最大にすること」が本質である
- 最も良い設計や要求は、自己組織的なチームから生まれる
- チームは定期的に、もっと効果的になる方法を振り返り、それに合わせて自分たちの行動を調整する
今も大事にされる理由は？
宣言は20年以上前のものですが、今もアジャイルを学ぶときの出発点として読まれています。特定の手法ではなく、どの手法にも共通する考え方を短く示しているからです。
PMI と Agile Alliance は、2017年に『アジャイル実務ガイド』をまとめました。このガイドも、第2章で宣言の4つの価値と12の原則を取り上げています。付録では、宣言の価値や原則とガイドの内容の対応も示しています。
新ECO（2026年版）では、出題の約6割がアジャイルとハイブリッドの場面です。宣言の価値観は、そうした状況問題で行動を選ぶ物差しになります。
原則は試験でどう使われる？
PMP の対策では、原則の番号を覚えるより、状況問題で原則に沿った行動を選べることが大切です。対応の例は次のとおりです。
| 場面 | 正解になりやすい行動 | 関係する原則（要約の番号） |
|---|---|---|
| 顧客が途中で要望を変えた | 歓迎し、バックログに入れて並べ直す | 2 |
| 進み具合を報告する | 完了した動く成果物で示す | 7 |
| 納期のために残業が続いている | ペースを見直し、範囲を調整する | 8 |
| 作り方でチームが迷っている | チームが自分たちで決められるよう支える | 5・11 |
| 分散したチームで誤解が多い | ビデオ会議など、顔を合わせて話す機会を増やす | 6 |
| 使われない機能を作り込もうとしている | 価値の低い作業はやらない選択をする | 10 |
| 同じ問題が繰り返し起きる | ふりかえりで原因を探り、改善を実行する | 12 |
特に、原則11の自己組織的なチームは、PMP の問題で「PMが指示しない」選択肢の根拠になります。詳しくは自己組織化チームとは？で扱います。アジャイル問題全体の判断の原則は、PMPのアジャイル対策にまとめています。
誤解されやすい点は？
- 「計画しない」： 計画は作ります。短い周期で何度も見直すことを大切にしています。
- 「文書を作らない」： 必要な文書は作ります。動くものより文書を優先しない、という意味です。
- 「品質より速さ」： 原則9は技術的な卓越を求めています。速く出すことと品質は対立しません。品質の基準は完了の定義（DoD）で守ります。
- 「ソフトウェア開発だけのもの」： 宣言はソフトウェア開発の言葉で書かれていますが、考え方は他の分野にも応用されています。
- 「リーダーは不要」： チームを支え、障害を取り除くリーダーは必要です。指示と統制の形ではない、ということです。
確認問題1
顧客が後半で要求を変えた
（当サイトの独自問題）アジャイルで進めている開発の後半です。顧客が競合の新サービスを見て、「一覧画面の並べ方を変えたい」と言ってきました。チームの一人は「今さら変えるのは面倒だ」と不満を述べています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。開発の後半でも変更を歓迎し、顧客の競争力に生かすのがアジャイルの原則です。要望はプロダクトバックログに入れ、プロダクトオーナーが価値で並べ直します。チームとは、変更を歓迎する理由を共有します。
1：顧客の価値を後回しにしています。2：契約交渉より顧客との協調を重んじる価値に反します。4：チームの都合で顧客の要望を退けるのは誤りです。
確認問題2
長時間の残業が続くチーム
（当サイトの独自問題）リリースの日付に間に合わせるため、アジャイルのチームが3スプリント続けて深夜まで残業しています。ベロシティは一時的に上がりましたが、不具合が増え、体調を崩すメンバーも出始めました。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。持続可能なペースを保つことは、アジャイルの原則の1つです。ペースを戻し、日付に合わせて届ける範囲を価値の順に見直します。
1：期間を区切っても、品質と健康の悪化は続きます。3：根本の原因（無理な作業量）を解決していません。4：技術的な卓越を軽んじ、負債を増やします。
確認問題3
分厚い仕様書を求められた
（当サイトの独自問題）アジャイルのプロジェクトで、品質保証部から要求が届きました。「すべての機能の詳しい仕様書を、開発を始める前に作って提出せよ」という内容です。チームは、毎スプリント動くものを見せて確かめる進め方をとっています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。アジャイルでも必要な文書は作ります。まず、品質保証部が本当に確かめたいこと（品質の基準・監査の証拠など）を聞きます。そのうえで、動くものと必要十分な文書の組み合わせで応える方法を一緒に決めます。
1：宣言は右側の価値（文書）も認めており、「文書は不要」は誤解です。2：動くもので確かめる利点を捨てています。3：本人たちと話す前に上へ持ち込むと、関係者との協力を損ないます。
原則を土台にした状況問題は、無料模試30問で試せます。