はじめに

近年のビジネス環境において、ユーザーニーズやテクノロジーなど、あらゆる移り変わりのスピードはますます速まっています。こうした変化に対応するためには、ソフトウェア開発においてもスピードや柔軟性を高めることが極めて重要です。
このような背景から、アジャイルソフトウェア開発（Agile Software Development）（以下、アジャイル開発）に対する注目が以前にも増して高まっています。

いまやアジャイル開発はソフトウェア開発プロジェクトにおいて一般的に採用される開発手法の一つにもなっているほどですが、その原点となっている「アジャイルソフトウェア開発宣言」（アジャイルマニフェスト）や、「アジャイル宣言の背後にある12の原則」については詳しく知らないという方も多いのではないでしょうか。

そこで本記事では、アジャイル開発という概念を生んだその原典ともいえる「アジャイルソフトウェア開発宣言」および、「アジャイル宣言の背後にある12の原則」について詳しくご紹介します。

なお、アジャイル開発に関する概要や、アジャイル開発とウォーターフォール開発との違いに関しては、以下の記事で詳しくご紹介しています。こちらの記事もぜひ併せてご参照ください。

あらためて、アジャイル開発とは｜その概要から進め方、メリット・デメリット、開発手法について
ウォーターフォール開発とは何か｜メリットやデメリット、アジャイル開発との違いについて解説

アジャイルソフトウェア開発宣言（アジャイルマニフェスト）とは

アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development：アジャイルマニフェスト）は、2001年に当時ソフトウェア開発手法分野で活躍していた17名の専門家によってまとめられた文書です。
一般的には、この宣言がアジャイル開発を公式に定義した文書だと考えられています。

まずはアジャイルソフトウェア開発宣言の本文について、こちらで見てみましょう。

出典：Manifesto for Agile Software Development
出典：アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発宣言では、以下の４つのことがらに特に価値をおくと述べられています。
１．個人との対話（Individuals and Interactions）
２．実際に動くソフトウェア (Working Software)
３．顧客との協調・コミュニケーション (Customer Collaboration)
４．変化への対応 (Responding to Change)　

上の価値をおくことがらと対になる左記の４つのことがら（①プロセスやツール、②包括的なドキュメント、③契約上の交渉、④計画に従う）は、いわゆる従来の開発において特に価値があると考えられていたものであり、かつてはそれらがより重視されていたと考えられます。

しかしながらアジャイル開発では、静的で型にはまった印象を受ける左記の要素にも引き続き価値があるとしつつも、右記で挙げられている「より動的で高い対応力や柔軟性につながる4つの要素」を特に重要視しているというのが大きなポイントとなります。

アジャイルソフトウェア開発宣言における4つの価値とは

上でご紹介したアジャイルソフトウェア開発宣言で挙げられている、4つの価値について1つずつ詳しくみていきましょう。

１．プロセスやツールよりも個人との対話を（Individuals and Interactions over processes and tools）

個人とのコミュニケーションにより重点を置くことにより、開発チームの対応力を上げるという考え方です。アジャイル開発では、決められたプロセスに機械的に従うのではなく、対話によってチームに合ったより良い方法を見つけようとします。
また評判の良いツールを導入したとしても、それが必ずしも開発をよりよく進めるための手段とならないこともあります。
したがって、アジャイル開発ではプロセスやツールに安易に頼るのではなく、個人との対話を重視することで、より柔軟かつ実際的な方法を模索します。

２．包括的なドキュメントよりも動くソフトウェアを (Working software over comprehensive documentation)

従来のソフトウェア開発方法では、ドキュメントの作成や管理に多くの時間を割いてきました。例えば、仕様書や計画書といったドキュメント作成に費やすコストや時間が大きく、その結果として開発の遅延や予算超過、あるいは出来上がったソフトウェアが最新のニーズに適合していないといった問題に繋がることもありました。
一方で、アジャイル開発では動くソフトウェアによりフォーカスし、実際に動くソフトウェアを通じたフィードバックを取り入れて方向性を随時修正しながら、本当に価値のあるソフトウェアを開発できるように工程を進めます。

なお、アジャイル開発においてよく見られる誤解にもつながる「包括的なドキュメントよりも動くソフトウェアを」という主張は、必ずしも「ドキュメントを作成しなくて良い」ということを意味しているわけではありません。詳しくは後述します。

３．契約上の交渉よりも顧客との協調を (Customer collaboration over contract negotiation)

従来のソフトウェア開発では、どちらかといえば開発者は顧客との協調よりも契約上の交渉を重視する傾向がありました。
顧客と開発者の関係性として、ともに価値を生み出すパートナーというよりも、サービスを提供される側とサービスを提供する側というような、ある種対立するような関係性にあったと言い換えることもできます。
一方でアジャイルソフトウェア開発宣言においては、顧客とは協調すべきものであり、一緒により良いものを作るパートナーと考えていると読み取ることができます。
協調の具体的な例としては、顧客とのより深いコミュニケーションを通じて要求や要望に対する理解を深めたり、開発途中のソフトウェアに対するフィードバックを受けてそれを開発に活かしたりといったことが考えられるでしょう。

４．計画に従うよりも変化への対応を (Responding to change over following a plan. )　

アジャイル開発の考えが浸透する前のソフトウェア開発において、基本的には定められた計画を変更することは望ましいことではなく、計画通り開発を進めることに重きが置かれてきました。しかし、当初立てた計画が必ずしも上手くいくとは限らず、また開発途中に前提条件が変わるといったこともあり得ます。
冒頭でも述べた通り、あらゆるスピードが加速するなかで、ビジネスのトレンドも常に変化します。また、顧客やユーザーなどのニーズも絶えず変化していくものです。そういった変化にも迅速に対応できるように、必要に応じて当初の計画にこだわらず、柔軟な姿勢で臨むことがアジャイル開発では極めて重要です。

アジャイル開発宣言が今もなお注目される理由や背景

アジャイルソフトウェア開発宣言が発表されてから約20年が経ちますが、今もなおアジャイル開発における重要な文書として存在感を放っています。
ではなぜ、このように非常に長い期間にわたってアジャイルソフトウェア開発宣言は重要なものとして注目され続けているのでしょうか。こちらでは、その理由や背景として考えられることをご紹介します。

かつては新しい開発手法であったアジャイル開発も、近年では一般的な開発手法として多くのプロジェクトにおいて取り入れられています。
しかしながら、それゆえにアジャイル開発がどのような目的や価値観のもとに生まれたものなのか、どのような原理原則を持つものなのか、このようなことが認識されないまま「アジャイル開発」という名前とその方法論が独り歩きしているようにも見えます。その結果として、エンジニアをはじめとするアジャイル開発に携わる人々のなかでも、アジャイル開発についての誤解が見られることが多くあります。

よくある誤解の一例として、アジャイル開発というと「大人数のプロジェクトには適用できない」「ドキュメントを作成しなくても良い」などと言われることもありますが、必ずしもそうとは限りません。

むしろアジャイル開発宣言で述べられていることを参照すれば、プロセスや手法に縛られることは決して望ましいことではありません。アジャイル開発宣言においては、型にはめて安易にプロセスに従うことよりも、目的に沿って柔軟に開発を進めることが推奨されています。したがって、特に人数や規模について「こうしなければならない」という決まりがあるというわけではありません。

ただし、個人との対話により価値を置くことから、人数が多すぎる場合は個人間の対話が難しくなるという側面は確かにあります。
したがって、大規模のプロジェクトの場合は、一定の人数以下の比較的小規模のチームに分割してアジャイル開発を行うことが望ましいと考えられます。

またドキュメントについても、アジャイル開発では「ドキュメントを作らなくても良い」と言われることもありますが、これについても必ずしもそうとは限りません。
例えば開発対象のソフトウェアの仕様が複雑で、ドキュメント化した方が理解や記憶、共有がしやすく、開発を進める上で有効であればドキュメントを作成すべきです。
アジャイル開発では、何事も型にはめてそれ通りに行うことよりも、より本質的に価値があることを柔軟に取り入れることに価値を置いているとも言えます。
アジャイル開発におけるドキュメントに関する誤解は、おそらく「包括的なドキュメントよりも動くソフトウェアを」という主張に対する誤解から生まれているのではないかと思われますが、この主張はあくまでも「ドキュメントと比べて動くソフトウェアにより価値を置く」と述べているだけで、ドキュメントが不要とは述べていません。
より価値を置く「動くソフトウェア」をより効率的に作るために「ドキュメントを作成した方が良い」とチームが判断したならば、ドキュメントを作るべきでしょう。

このように、思考を停止して「こうすることになっているからやる」（＝計画に従うこと）ではなく、「より価値を生み出すためにはこうすべきだからこうしよう」（＝変化への対応）という姿勢こそが本来のアジャイル開発的な考え方であり、アジャイル開発宣言で語られていることであると考えられます。

このように、アジャイル開発における原理原則をその原典であるアジャイル開発宣言から学ぶことは、アジャイル開発に対する新たな知見の獲得やさらなる理解にもつながります。
もちろん、原理原則と実際の運用は異なるもので、それだけを知っていれば十分というものではありません。しかしベースの知識として原理原則を知っておくことで判断に迷う時の参考となったりと、実際の運用においても役立つことがあります。
このような理由から、アジャイル開発宣言は今もなお多くのエンジニアやアジャイル開発に関わる人々に広く読まれており、それこそが長年に渡って注目され続けている背景と考えられるでしょう。

アジャイルソフトウェア開発宣言の背後にある１２の原則とは

アジャイルソフトウェア開発宣言には、その背後にある原則として１２の原則が挙げられています。
この１２の原則は、アジャイル開発についての理解をさらに深めるための示唆に富んでいることから、本記事でも詳しくご紹介します。
アジャイル宣言の背後にある原則は、以下の通りです。

出典：Principles behind the Agile Manifesto
出典：アジャイル宣言の背後にある原則

これらの１２の原則について、具体的にどのようなことを意味しているのか、１つずつ紐解いていきましょう。

１．顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する

何よりもまず「顧客満足を最優先すること」「価値のあるソフトウェアを早く継続的に提供すること」が12の原則の冒頭で述べられていることから、こちらの原則がアジャイル開発における最も重要な原則と考えても差し支えないでしょう。
顧客満足を最優先するということは、顧客が真に何を求めているのかを明らかにすることがその前提となります。
顧客は何を実現したいのか、何がどうなったら顧客が満足するのかを徹底的に掘り下げた上で、そのためのソリューションであるソフトウェアを迅速かつ継続的に提供していくことがアジャイル開発における本懐と言えるでしょう。
なぜ早さと継続性が重要視されるかと言えば、上でも紹介した通り、変化し続ける外部環境や顧客ニーズに対応するためにはスピードとフィードバックを通じた継続的な改善が必須であるからと考えられます。

２．要求の変更を歓迎し、変化を味方につけることでお客様の競争力を引き上げる

要求の変更は、基本的に何らかの目的や狙いをともなって行われるものです。
つまり、そこには開発中のソフトウェアの価値を高める要素が含まれている可能性が高いと言えます。（当然ですが、意図の無いむやみやたらな要求変更ではなく、明確な理由や目的をもった要求変更であることが前提となります）

したがって開発側としては、要求変更に対して、開発中のソフトウェア価値やお客様の競争力、顧客満足を高めるきっかけとして歓迎する態度が望ましいと言えます。

３．動くソフトウェアを、2-3週間から2-3ヶ月の短い間隔でリリースする

変化の速い現代のビジネスにおいて、開発を進めている間にも環境はニーズは変わり続けています。それにともなってソフトウェア開発の目的にも変化が生じることもあります。
したがって、2-3週間から2-3ヶ月という短い間隔で動くソフトウェアをリリースし、それに対するユーザーや顧客からのフィードバックを得ながら開発を進めていくことによって、よりニーズに合致した価値の高いソフトウェアを開発しやすくなると言えます。
またリリースまでの期間を短くし、その規模を比較的小規模にすることで、何らかの変更やミスが生じたとしても手戻りが小さく済むと言うのも大きなポイントです。

４．ビジネス側と開発者は、プロジェクトを通して日々一緒に働かなければならない

ソフトウェア開発は、それ自体は目的ではなく、ビジネスにおいてはそのゴールを達成するためソリューションです。
したがって、ビジネス側と開発者は共通のゴールの達成に向けて協業することが望ましいと言えます。

具体的には、ビジネス側と開発者はともに常に変化する状況に合わせて方針や要求、要件などを修正しながら開発を進め、短期間のリリースを通じてフィードバックを取得し、さらにソフトウェアをブラッシュアップしていくという一連の工程を円滑に行うことで、ソフトウェアの価値を最大化することを目指します。

５．モチベーションの高いメンバーでプロジェクトを立ち上げ、チームを信頼し続ける

ソフトウェア開発プロジェクトを成功に導く要因の一つは「チームの体制」にあります。
優れたスキルを持つメンバーを集めることも重要ですが、本原則では「意欲に満ちた」モチベーションの高い人々を集めることが重要としています。
アジャイル手法の一つであるスクラムの考え方として、開発者は開発プロジェクトを通じて学習し成長するというものがありますが、そのためには何よりも意欲の高さが必要とされるということなのではないでしょうか。
また、意欲の高い人を集めてプロジェクトが始まったら、支援はしつつも基本的にはチームを信頼し任せきるということが重要です。
信頼され任されているという実感はさらにチームの意欲を高め、ソフトウェアの価値を高めることにも繋がります。

６．直接顔を合わせてコミュニケーションをとる

現代ではチャットやメール、電話、WEB会議などさまざまなビジネスコミュニケーションツールがあり、かつてに比べて直接顔を合わせてコミュニケーションをとる機会が減少しています。
しかしながら、人対人のコミュニケーションにおいては、やはり同じ空間で直接顔を合わせたフェイス・トゥ・フェイスの会話が最も効率的かつ効果的な方法であると、本原則では述べられています。
人と人のコミュニケーションにおいては微妙なニュアンスが重要な意味を占めることも少なくありませんが、そのようなニュアンスは直接顔を合わせて初めて読み取ることが可能となります。
また実際に顔を合わせてのコミュニケーションはチームに一体感をもたらし、本当に考えていることをより伝えやすいという効果もあります。特に重要なテーマについての話し合いが必要な場合などは、可能な限り同じ場所に集まってフェイス・トゥ・フェイスで会話をすることが重要と言えるでしょう。

７．動くソフトウェアこそが進捗の最も重要な尺度である

プロジェクトの進捗を把握するための方法として、工数やタスクの消化状況を計画と照らし合わせることでその進行度合いを計測するという方法がよく用いられます。
しかしながら、開発中のソフトウェアがどのような状況にあり、目指している提供価値をどの程度実現できるものになっているのかは、動くソフトウェアを通じてしかわかりません。
したがって本原則では、「実際の動くソフトウェアこそが最重要な進捗の尺度である」と述べられています。
一般的な進捗管理では、表面的な作業の進行度合いを計測することができても、実際にソフトウェアが価値を生み出すものになっているのかどうかを計測することは極めて困難です。
また動くソフトウェアを通じて進捗を把握することで、実際にソフトウェアを動かした際に想定外の問題が発生するというリスクを早期にヘッジすることが可能となるという点も大きなポイントの一つです。

８．開発は持続可能なものとして、一定のペースを維持し続けなければならない

開発プロジェクトにおいて、持続可能な状態を維持することは非常に重要です。
もし一時的にペースを上げたとしても、それが続かなければ意味がないばかりか、逆効果にもなり得ます。
高い負荷がかかった状態が続くと、開発者の疲弊を招き、パフォーマンスの低下につながります。
またソフトウェア開発の目的は価値を生み出すことにありますが、疲弊すると目の前の作業を終わらせることに目が向いてしまいがちで、開発を終わらせること自体が目的にすり替わってしまうというリスクもあります。
結果として、作業は終わったものの本当に達成したかったことが達成されないというケースもよく見られます。
したがって、開発者にとって持続可能かつ、一定のペースで無理なく維持し続けることができる環境を整えることが極めて大切です。

９．優れた技術や設計が、機敏さ（アジリティ）を高める

本原則では、優れた技術や設計が機敏さを高め、状況に応じてより素早く対応することを可能にするということが述べられています。
これは、技術や設計がしっかりしていることがソフトウェアの高い品質や保守性につながり、結果として変更を行う時のスピードが速まるということを意味していると考えられます。
スピードを優先するために技術や設計をおろそかにしてしまうというのはよく見られる例ですが、それはかえって逆に機敏さを失うリスクもあるということを認識するようにしましょう。

１０．シンプルさこそが本質

本原則の原文には、以下のようにあります。
Simplicity–the art of maximizing the amount of work not done–is essential.
“the art of maximizing the amount of work not done”は直訳すると「未完了の仕事の量を最大化する技術」となります。
これはどういうことを指しているのかというと、たとえ開発に着手した機能であっても、それが価値を生み出さない不要な機能だと考えられる場合は開発を途中でやめるべきであり、その結果として未完了の仕事の量が最大化するというように解釈ができます。
つまり、ここで述べられている「シンプルさ」とは、本当に価値があるものだけが含まれている状態を指すと考えられます。
そしてその「シンプルさ」を実現するためには、仕掛中のものであっても、「勇気をもって不要なものを捨てる」ということが必要となるのです。

１１．最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される

良いソフトウェアは自律型のチームから生み出される、と言い換えることもできるでしょう。
自律型のチームとは、リーダーがメンバーを支配するような従来のヒエラルキー型のチームとは異なり、それぞれのメンバーが価値を創出するために必要な行動を自ら行うようなチームです。
例えばタスクに関しても、リーダーがタスクを考えメンバーは命令されたことを作業として行うのではなく、チームで必要と思われるタスクを洗い出した上で、その進行に関してはそれぞれのメンバーが責任をもって進めます。
また時には現在の自分の能力では遂行が難しい仕事もあるでしょう。そのような場合でも各メンバーが自ら学習し、また時にはメンバー同士が協力しあいながらお互いを高めることで、チーム全体が自ら成長していくような集団、それが自律型のチームと言えます。
このような自律型のチームからこそ、最良のソフトウェアが生み出されるのです。

１２．定期的な振り返りを通じて、チームのやり方を最適に調整する

振り返りは、チームにとって重要な適用や成長の機会を提供します。
もしプロジェクト運営のなかで適切なタイミングでの振り返りを行わない場合、改善の機会が失われ、プロジェクトをより良いものにしていくことが難しくなってしまいます。
しかしながら、振り返りというと、プロジェクトが終わったタイミングのみ実施するというケースが多く見られます。これでは次のプロジェクトの改善にはつながるかもしれませんが、進行中のプロジェクトに良い影響を与えるには実施タイミングが遅すぎると言えるでしょう。
目安としては、1~2週間に一回程度の頻度で定期的に振り返りを行うことにより、プロジェクトの課題の発見やその改善を素早く、かつ繰り返し行うことができるようになります。
このような振り返りを通じた改善の繰り返しによってプロジェクトにリズムが生まれ、チームのパフォーマンス向上がよりはかりやすくなります。

振り返りのフレームワークにも色々なものがありますが、最もメジャーなフレームワークとして「KPT法」があります。KPT法については以下の記事でも詳しく紹介していますので、宜しければ併せてご参照ください。

振り返りのフレームワーク「KPT法」とは｜そのメリットや進め方、実施のポイントについて

おわりに

アジャイル開発は、その高い柔軟性と適応力から、変化が激しい現代社会に対する有効な開発手法の一つとしてますます採用が進んでいます。

その結果として、アジャイル開発がより一般的な開発手法となりゆく中で、アジャイル開発に対する誤解や都合の良い解釈といったものも多く見られるようになっています。
もちろん、実際の運用におけるテクニックも重要であることは間違いありませんが、アジャイル開発の表面的な部分に限らず、より本質に対する理解を深めることによって、アジャイル開発を通じたさらに高いバリューの発揮につながるのではないでしょうか。
そのためにも、アジャイル開発の原典である「アジャイルソフトウェア開発宣言」と、「アジャイル宣言の背後にある原則」は常に心にとめておくべきと言えるでしょう。

本記事では、アジャイル開発宣言とその背後にある12の原則についての解説をしましたが、その解釈には必ずしも絶対的な正解があるというわけではありません。
これをきっかけに、あらためてアジャイル開発宣言とその原則について目を通し、自身なりに解釈をしてみてはいかがでしょうか。

SHIFT ASIAについて

私たちSHIFT ASIAは、ソフトウェア品質保証・第三者検証のリーディングカンパニーである 株式会社SHIFT（プライム市場上場）の海外戦略拠点として、ベトナム・ホーチミンにてソフトウェアテスト事業を手掛けながら、近年はソフトウェア開発にも事業領域を拡大させてきました。長年に渡り培ってきた品質保証のナレッジとハイレベルなエンジニアの技術力を背景とした、高品質かつスピーディな開発をその特長としています。

アジャイル開発やスクラムを採用した多数の開発実績もございますので、ソフトウェアの開発やテストでお困りのことがありましたら、ぜひお気軽にお問い合わせください。