日本語

Agile Manifesto: 4つの価値観と12の原則を解説

Agile Manifestoの4つの価値観と12の原則の概要

Agile Manifestoはソフトウェア史上もっとも広く読まれた文書のひとつであり、わずか68語で書かれています。2001年2月、ユタ州スノーバードのスキーリゾートに集まった17人の実務家が、肥大化したプロセスのせいで誰も求めていないソフトウェアを期限遅れで納品し続けることへの不満から、このドキュメントを記しました。

しかしその影響はソフトウェアの枠を大きく超えました。今日、マーケティングチームはSprintを回し、HR部門はRetrospectiveを実施し、オペレーションチームはKanbanボードを活用しています。Agile Manifestoの4つの価値観と12の原則は、これらすべての土台となっています。

このガイドでは、各価値観と原則が何を意味し、実務でどう適用できるかを丁寧に解説します。

Agile Manifestoとは何か

Agile Manifestoは、2001年2月にユタ州スノーバードのスキーリゾートで17人のソフトウェア実務家によって書かれた、短い創設文書です。4つのコアバリューと12の原則を定義し、硬直したプロセスや事前計画より、人、成果、適応性を優先することを宣言しています。

17人の署名者には、ソフトウェアエンジニアリングを代表する人物が名を連ねています。Kent Beck（Extreme Programming創案者）、Jeff SutherlandとKen Schwaber（Scrum共同創案者）、Martin Fowler、Jim Highsmith、Alistair Cockburnら、総勢17名です。彼らの共通の悩みはひとつ、重厚な計画主導プロセスがソフトウェアを遅延・予算超過・陳腐化させるという現実でした。

このドキュメントはagilemanifesto.orgで公開されており、2001年の発行以来一切改訂されていません。

重要なデータ

  • Agile Manifestoは2001年2月にagilemanifesto.orgで公開され、17人のソフトウェア実務家が署名しました。4つの価値観は合計68語で、発行以来変更されていません。
  • 第18回 State of Agile Report（Digital.ai、2024年）によると、Agileアプローチを採用している組織は71%に上り、2011年の37%から大幅に増加しています。
  • Standish Group CHAOS Reportの分析では、プロジェクト規模を考慮した場合、Agileプロジェクトの成功率はWaterfallを大きく上回っています（Agile: 42% 対 Waterfall: 13%、2020年版）。

Manifestoを理解することは、Agileメソドロジー全体の文脈を把握する上でも重要です。主要フレームワーク（Scrum、Kanban、XP）はすべて、このドキュメントに源流を持っています。

Agile Manifestoの4つの価値観

Agile Manifestoの4つの価値観

Manifestoはこう宣言します。「私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしています。この活動を通して、私たちは以下の価値を見出しました」

続いて、4つの価値観の対比が示されます。それぞれ「Xよりも Y を重視する」という形式です。重要な補足として「右側の項目にも価値はある。しかし、私たちは左側の項目をより重視する」と明記されています。

このニュアンスが肝心です。Manifestoは契約を無価値だとは言っていません。顧客との協力関係の方が重要だと言っているのです。ドキュメントを無意味とも言っていません。動くソフトウェアの方が優先されると言っているのです。

価値観 重視するもの 否定しないもの
個人と対話 プロセスやツールよりも 直接のコミュニケーション、人の判断、チームの関係性 プロセスやツール（主役ではないだけ）
動くソフトウェア 包括的なドキュメントよりも ユーザーが反応できる機能するものを届けること ドキュメント（書くべきだが、納品の代替にはならない）
顧客との協調 契約交渉よりも 製品を使う人との継続的な対話 契約（必要だが、北極星ではない）
変化への対応 計画に従うことよりも 納品中に学んだことをもとに調整すること 計画（立てる価値はある、ただし盲目的に従わない）

価値観1: プロセスやツールよりも個人と対話を

本当に課題を共有するStand-upは、誰も読まない美しいプロジェクト管理ツールより価値があります。この価値観は、プロセスは手段であって目的ではないというリマインダーです。

実践上の観点：チームが実際の仕事より、ツールの更新に多くの時間を費やしているなら、本末転倒です。

価値観2: 包括的なドキュメントよりも動くソフトウェアを

これは最も誤解されやすい価値観です。「ドキュメントを書くな」と読まれることがありますが、そうではありません。ユーザーの手元で動くプロダクトの方が、仕様書より多くの学びを生むと言っているのです。2週目に出荷されたプロトタイプは、1ヶ月目に書かれた40ページの要件定義書より多くを教えてくれます。

価値観3: 契約交渉よりも顧客との協調を

契約は最初の合意を定義します。顧客が本当に必要なものを理解するのは、最初のイテレーションを見た後です。定期的な協力、Demoやフィードバックループによって、当初の仕様書に書かれたものではなく、顧客が本当に望むものへとプロダクトを進化させることができます。

価値観4: 計画に従うことよりも変化への対応を

市場は変わります。競合はリリースします。ユーザーからのフィードバックは予想外のことを教えてくれます。作業開始前に立てた計画は現実ではなく仮定を反映しています。Agileチームは学びながら計画を更新します。Sprint Planningはこの価値観を具体化する場です。チームは6ヶ月先ではなく、1Sprintずつ計画を立てます。

Agileの12の原則

Agileの12の原則

12の原則は、4つの価値観をそれぞれ実践的なガイダンスに展開したものです。価値観と同時に書かれ、agilemanifesto.org/principles.htmlで公開されています。

# 原則 わかりやすい意味
1 顧客満足を最優先とし、価値あるソフトウェアを早く継続的に提供します。 役に立つものを早く届ける。すべてが完璧になるまで待たない。
2 開発の後期であっても、要求の変更を歓迎します。 遅い変化は失敗ではなく、情報です。それを吸収できるプロセスを作りましょう。
3 動くソフトウェアを、2週間から2ヶ月という短い間隔でリリースします。できるだけ短い方を好みます。 短いサイクルが長いサイクルを上回ります。頻繁に出荷するほど、早く学べます。
4 ビジネス側の人と開発者は、プロジェクトを通じて毎日一緒に働かなければなりません。 ドメインを理解する人と製品を作る人は、サイロで動くべきではありません。
5 意欲に満ちた人々を中心にプロジェクトを構成します。環境と支援を与え、仕事が完成するまで信頼します。 自律性と信頼が、監視とマイクロマネジメントより良い結果を生みます。
6 情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話すことです。 直接会話がドキュメントの連鎖に勝ります（ビデオ通話も含む）。
7 動くソフトウェアこそが進捗の主要な尺度です。 Velocity、完了したチケット数、着手した機能数はすべて代替指標です。唯一の本物の尺度は動くものだけです。
8 Agileのプロセスは持続可能な開発を促進します。スポンサー、開発者、ユーザーは一定のペースを継続的に維持できるべきです。 長期の全力疾走は戦略ではありません。数ヶ月続けた無理なSprintはチームを疲弊させ、バグだらけの成果物を生みます。
9 技術的卓越性と優れた設計への継続的な注意がアジリティを高めます。 粗悪なコードは時間とともに速度を落とします。今日の近道は明日の遅延になります。
10 シンプルさ、つまり行わない作業量を最大にする技術が本質的です。 少なくする。最良の機能は作る必要がないもの。最良のプロセスステップは省けるものです。
11 最良のアーキテクチャ・要求・設計は、自己組織化チームから生まれます。 トップダウンの指令は服従を生みます。自己組織化チームは当事者意識と創造性を生みます。
12 チームは定期的に、もっとうまくやれるかを振り返り、それに従って自分たちのやり方を調整します。 Sprint Retrospectiveは任意ではありません。継続的な改善はリズムに組み込まれています。

ソフトウェア以外のチームに特に重要な原則は3つです。原則2（変化を歓迎する）、原則10（やらない仕事を最大化する）、原則12（定期的なRetrospective）。これらはマーケティング、HR、オペレーションのワークフローにも等しく適用できます。

Agile Manifestoが今も重要な理由

Manifestoは、すべてを事前に予測・仕様化しようとしてソフトウェアプロジェクトが失敗するという、特定の問題に反応して書かれました。この問題は今も変わっていません。むしろ深刻になっています。

Manifestoの重要性が増している理由を挙げます。

仕事はより複雑になっています。 2026年に取り組む課題（AI統合、分散型ワーク、マルチマーケット展開）は、2001年のエンタープライズソフトウェアより事前仕様化が難しいです。反復的な納品と素早い学習ループはますます重要になっています。

フィードバックループはより速く、安価になっています。 2001年当時、機能を出荷するには物理的なリリースや一夜のデプロイメントが必要でした。今やチームは数分でユーザーの10%に機能を届け、数時間で結果を測定できます。素早いフィードバックへのManifestoの賭けは、さらに報われるようになっています。

Agileはソフトウェアを超えました。 マーケティング、HR、財務、オペレーションのチームがSprintを回しています。12の原則はドメインに依存しません。原則8（持続可能なペース）はどのチームにも適用できます。原則10（やらない仕事の最大化）はあらゆるプロセスに適用できます。原則12（定期的なRetrospective）は改善を目指すすべてのグループに適用できます。

Agile vs Waterfallの選択は、新しい取り組みを始める際にチームが直面する最も一般的な戦略的判断であり、Manifestoはそれに対してAgileが何を意味するかを最も明確に示したドキュメントです。

Agileに関する一般的な誤解

Manifestoは絶えず誤読されています。最も多い誤解と、文書が実際に何を述べているかを確認しましょう。

誤解1: 「Agileは計画を立てないことだ」

違います。Manifestoは「計画に従うよりも変化へ対応する」と言っており、「計画を立てるな」とは言っていません。すべてのSprintはSprint Planningから始まります。すべての四半期は目標設定から始まります。Agileの計画と従来の計画の違いは、新しい情報が入るたびに更新されるという点です。

誤解2: 「Agileはドキュメントを書かないことだ」

Manifestoは、包括的なドキュメントよりも動くソフトウェアを重視します。「包括的」が重要なキーワードです。役に立つドキュメントは書きましょう。ただし、何かを出荷する代わりにドキュメントを書くのは本末転倒です。

誤解3: 「Agileはソフトウェアチームのためだけのものだ」

Manifestoはソフトウェア実務家が書きましたが、価値観はソフトウェア固有ではありません。原則1（価値の早期提供）、原則2（変化を歓迎する）、原則12（定期的なRetrospective）は、複雑な作業を行うどのチームにも適用できます。

誤解4: 「Agileには納期がない」

Agileチームにも納期はあります。Sprint Reviewは固定された日程で行われます。製品リリースには公開日があります。違いは、日程を守るために範囲を調整するのがAgileだという点です。Waterfallは範囲に合わせて日程を調整します。

誤解5: 「ScrumはAgileだ」

ScrumはAgileの価値観を実装したものの一つです。Kanbanもそうです。Extreme Programmingもそうです。AgileはPhilosophyであり、Scrumはそれに従うレシピのひとつです。Scrumを実施せずにAgileであることは可能です。Scrumのセレモニーをこなしながら実際にはAgileではないことも可能です（これは「カーゴカルトAgile」と呼ばれ、多くの組織が認めたくないほど一般的です）。

チームでAgile Manifestoを実践するには

正式なフレームワークを採用しなくても、Agileの価値観を実践し始めることはできます。Manifestoの原則から実際の行動へと移すためのステップを紹介します。

ステップ1: 現在の「無駄」を特定する

チームが価値を直接生み出さないことに費やしている時間を見つけましょう。長い承認チェーン、誰も読まないステータスレポート、メッセージで済む会議。原則10（やらない仕事の最大化）はここから始まります。

ステップ2: 納品サイクルを短縮する

実際のユーザーが反応できる最小のものとは何でしょうか？現在のサイクルが四半期なら、月次を目指しましょう。月次なら隔週を目指しましょう。Burndown Chartを活用すると、各サイクルで納品される作業が実際に完了しているかを視覚化できます。

ステップ3: 顧客をより早く引き込む

あなたの「顧客」は外部クライアント、社内ステークホルダー、またはエンドユーザーかもしれません。誰であれ、完成品ではなく進行中のものを見せる機会を作りましょう。早い段階のフィードバックは安価です。遅い段階のフィードバックは高コストです。

ステップ4: Retrospectiveの習慣を始める

各作業サイクルの終わりに30〜60分を確保して、3つの質問を問いかけましょう。うまくいったことは？うまくいかなかったことは？変えることは？原則12はAgileの複利リターンです。定期的にRetrospectiveを行うチームは、行わないチームより速く改善します。正式版はSprint Retrospectiveですが、シンプルな共有ドキュメントから始めることもできます。

ステップ5: WIP制限を試してみる

ワークフローのある段階（進行中、レビュー中など）を選んで、そこに積める作業数の上限を設定しましょう。ScrumとKanbanは一点で一致しています。進行中の作業を終わらせることが、新しい作業を始めることより重要だという点です。WIP制限はその行動を促します。

ステップ6: チームにより多くの自律性を与える

原則11は、最良の結果は自己組織化チームから生まれると述べています。つまり、仕事をする人が仕事のやり方にも発言権を持つべきということです。小さなことから始めましょう。チームに自分たちのStand-upの進め方を決めさせる、あるいはマネージャーが目標を設定する代わりに各Sprintで自分たちのキャパシティを見積もらせるなど。

役割・機能別のAgile Manifesto実践例

4つの価値観は、作業する人によって見え方が異なります。

機能 実践する価値観 具体例
エンジニアリング 包括的ドキュメントよりも動くソフトウェアを 1ヶ月のレビューサイクルのために30ページの仕様書を書くのではなく、2週目にベータユーザーへ動くプロトタイプを届ける。
マーケティング 計画に従うよりも変化への対応を 2週間SprintでキャンペーンをLaunch。最初の広告セットのパフォーマンスが低ければ、予算を全額使う前にメッセージを修正する。
プロダクト 契約交渉よりも顧客との協調を 最初に一度だけ要件を収集するのではなく、開発全体を通じて隔週でユーザーインタビューを実施する。
HR / People Ops プロセスやツールよりも個人と対話を 年次レビューシステムのみに頼るのではなく、1on1の会話と直接フィードバックで業績課題を早期に発見する。
オペレーション 計画に従うよりも変化への対応を 受信した依頼をMoSCoW優先付けボードで管理し、計画された仕事を崩さずに緊急案件に対応する。
デザイン 契約交渉よりも顧客との協調を 完成品を待たずに、毎Sprintで粗いワイヤーフレームをエンドユーザーと共有し、フルビルド前にフィードバックで修正する。

ユーザーストーリーは、顧客ニーズとチームの作業項目の橋渡しをする最も実践的なツールのひとつです。価値観3（顧客との協調）を具体化するAgileの成果物です。

よくある質問

Agile Manifestoを書いたのは誰ですか？

Agile Manifestoは、2001年2月にユタ州スノーバードのスキーリゾートで集まった17人のソフトウェア実務家によって書かれました。Kent Beck、Jeff Sutherland、Ken Schwaber、Martin Fowler、Jim Highsmith、Alistair Cockburn、Ward Cunningham、そのほか9名が名を連ねています。彼らは共同著者として文書に署名しましたが、「Agile」という用語自体は会議中に提案されました。

Agile Manifestoはいつ発行されましたか？

Agile Manifestoは2001年2月、具体的には2001年2月11〜13日、ユタ州スノーバードリゾートでの3日間のリトリート中に発行されました。ドキュメントはagilemanifesto.orgでオンライン公開され、以来改訂されていません。

Agile Manifestoの4つの価値観とは何ですか？

4つの価値観は次のとおりです。(1) プロセスやツールよりも個人と対話を、(2) 包括的なドキュメントよりも動くソフトウェアを、(3) 契約交渉よりも顧客との協調を、(4) 計画に従うよりも変化への対応を。各価値観のペアは、左側が優先されるという意味ですが、右側にも価値があります。

4つの価値観と12の原則の違いは何ですか？

4つの価値観は哲学的な基盤です。Agileチームが何を優先するかを述べています。12の原則は実践的な展開です。それらの価値観をどう行動に移すかを説明しています。例えば、価値観4は「変化に対応する」と言います。原則2は「開発の後期であっても要求の変更を歓迎する」と言います。原則3は「動くソフトウェアを頻繁に提供する」と言います。いずれも同じ価値観を支えていますが、詳細度が異なります。

Agile Manifestoは2026年でも関連性がありますか？

はい。4つの価値観は、過度に仕様化された計画重視のプロセスへの反応として書かれました。2026年においても、AI支援による開発、大規模なデジタルトランスフォーメーション、分散型チームで同じ問題が現れています。Manifestoはツールや技術を説明しているのではなく、優先事項を説明しています。プロセスより人を、ドキュメントより成果物を、予測より学習を優先するというその方向性は、2001年と変わらず今日でも適用できます。第18回 State of Agile Report（Digital.ai、2024年）では、組織の71%がAgileアプローチを使用していると報告されています。

Agile Manifestoは歴史的な遺物ではありません。意思決定のレンズです。チームがドキュメントを完成させることとプロトタイプを出荷すること、元の計画に従うことと新しいデータに基づいて調整することの間でトレードオフに直面するたびに、Manifestoはどちらに傾くべきかを示してくれます。その導きは期限切れになりません。