アジャイル開発宣言とは　

「アジャイル開発宣言（アジャイルマニフェスト）」はいつ発表されたのでしょうか。それは2001年に17人のソフトウェア開発者のグループが発表しました。内容は従来型の開発手法に対するアンチテーゼ（反対表明）です。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

米国ユタ州のソルトレイクシティの郊外に集まった開発者たちは、ソフトウェアの開発手法に対する考え方はそれぞれ異なっていましたが、誰もが開発の現状には不満を抱いていました。

開発者たちに共通した問題意識は、企業の論理やプロセスとソフトウェア開発のいわば「反りの悪さ」です。

ソフトウェア開発が大規模になり、大きなプロジェクトが長期間かけて開発に取り組むようになるほど、この反りの悪さが目立つようになってきたと彼らは感じていました。具体的に言うと、「契約」と「計画・管理」を前提にする従来のビジネスプロセスは、時としてソフトウェア開発の障害になると感じたのです。

アジャイル開発宣言は、正式には「アジャイルソフトウェア開発宣言」で、下記のような全文223字（英文68word）の簡潔な「マニフェスト」です。

アジャイルソフトウェア開発宣言

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

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

大規模なソフトウェア開発で重視されてきたプロセス・ドキュメント・契約・計画よりも、チームの対話・ソフトウェアを動かしてみること・顧客満足・変化への対応という4つの価値をより重視すべきだというのです。

【参考】アジャイルソフトウェア開発宣言

アジャイル開発宣言が提唱する開発姿勢

この「宣言」には、「アジャイル開発宣言の背景にある原則」という文書が付属していて、そこには彼らがソフトウェア開発において重要だと考える12の原則（開発姿勢）が列挙されています。

「アジャイル開発宣言の背景にある原則」を要約すると次のようになります。

1.顧客満足を最優先し、ソフトウェアを迅速・継続的に提供する 2.開発後期であっても変更を歓迎し、それによってクライアントの競争力を高める 3.動くソフトウェアをできるだけ短い間隔でリリースする 4.営業と開発は、プロジェクト内で日々一緒に働くべきである 5.意欲のある人を集めて良い環境を提供し、プロジェクト終了まで支援する 6.フェイス・トゥ・フェイスで話をし、情報を伝える 7.動くソフトウェアこそが進捗の尺度である 8.一定のペースを継続的に維持できる、持続可能な開発プロセスが求められる 9.技術的卓越性と優れた設計に対する注意を怠らず、機敏に対応する 10.ムダなく作るシンプルさが開発の本質である 11.自己組織的なチームから最良のアーキテクチャ（設計への発想）が生みだされる 12.チームの効率を定期的に振り返り、やり方を調整する

これらの原則を読んでまずイメージされるのは、革新的な製品を世に送り出したスタートアップ企業の少人数によるプロジェクトの生き生きとした開発の様子です。

この原則や開発姿勢を否定的にとらえる人はいないでしょうが、問題は企業とベンダーが関わる（大規模）ソフトウェア開発で、この柔軟性・創造性・効率性が発揮できるのかということです。

IТエンジニアでアジャイル開発について聞いたことがない人はいないくらい、この言葉は大流行しています。しかし、日々のプロジェクトの業務でアジャイル開発の原則が取り入れられていると感じているエンジニアはごく少数派に留まるでしょう。

IТ企業もアジャイル開発の価値と原則に賛同するところは少なくありませんが、それをソフトウェア開発戦略の中心に据えて本気で取り組んでいる企業は、大企業ではほとんど見当たらないと言ってもよい状況です。

誰しもがアジャイル開発の原則を「ソフトウェア開発の1つの理想形」として受け入れますが、それを現在進行しているプロジェクトにどう結び付けていけばよいのか分からないのです。

アジャイル開発が流行語の域をなかなか抜けられない理由は、アジャイル開発を従来のプロジェクトに存在する問題点のソリューションと捉える間違いにあります。

例えば、クライアント企業とベンダー企業が、プロジェクトにアジャイル開発の手法を取り入れようと話し合ってプロジェクトマネージャーに指示したとしても、それが上手くいくとは考えられません。

なぜなら、アジャイル開発は「契約」のあり方から考え直さないと機能しないからです。アジャイル開発の原則がソフトウェア開発に携わる人々の「マインドセット」であることは確かですが、従来の契約・計画・管理の枠組みでエンジニアたちにマインドセットを求めても難しく、理不尽なダブルバインドになるだけです。

そもそも「ソフトウェア開発に携わる人々」の枠をプロジェクト内部に限定したのでは、アジャイル開発の原則は維持できません。企業戦略を策定する経営トップ・営業部門・システム運営部門・ベンダー企業のトップなど、あらゆるステークホルダーを巻き込んだ検討や支援が必要となります。

アジャイル開発が流行することで、というよりアジャイル開発という「言葉」が流行することで出現したのが「ダークアジャイル」と呼ばれるものです。これは、手っ取り早いアジャイル開発のマニュアルやそれをコーチする人たちを指し、それによって苦しめられたエンジニアたちは少なくありません。

このようなダークアジャイルを生むのも、アジャイル開発をソリューションあるいは特効薬と考える管理サイドの誤解です。よく言われるような「大規模プロジェクトはウォーターフォール開発で、小規模プジェクトはアジャイル開発で」という考えは、ソフトウェア開発に内在する問題の矮小化あるいはすり替えに過ぎない場合があります。

開発関係者のすべてが「アジャイル開発の哲学」を理解する必要がある

アジャイル開発の原則を受け入れ、その良き成果を手に入れるには、広い意味での開発関係者のすべてがアジャイル開発の原則を貫く哲学を理解する必要があります。

「宣言」で太字で強調されている個人と対話は「個人と対話する」という意味ではなく、「個人＆対話」です。「プロセスやツールよりも個人が重要であり、対話が重要である」と述べられています。個人（Individuals）は、分割できない全人格としての人というニュアンスで、その個人間の相互作用（interactions）つまり対話が重要だというのです。

これは、エンジニアをプロセスの中の「駒」として捉えるのではなく、あくまで「人」として捉えようということです。それを示しているのが、12の原則にある次の言葉です。「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」

「このプロセスに従え」「このツールを使え」というのは管理には好都合ですが、そういう硬直した姿勢が、意欲に満ちた人々の創造性を棄損する恐れがあります。また、大規模プロジェクトの多重請負構造と「IТ土方」と呼ばれる単純作業の現状を、個人と対話の尊重の哲学にどう調和させるかは難しい問題ですが、アジャイル開発の実をあげるには目を背けるわけにはいかないテーマです。

「要件定義書」「詳細設計書」「運用マニュアル」などのドキュメントをプロセスに従って作成・提出するのはシステム開発の常道であり、「仕事が進捗している」アリバイでもあります。

しかし、プロジェクトの目的は「ちゃんと動作するソフトウェアを作ること」で、ドキュメントを揃えることではなく、まして炎上したときのためのアリバイ作りでもありません。「宣言の背景にある原則」で述べられているように「動くソフトウェアこそが進捗の最も重要な尺度」なのです。

プロセスに従ってドキュメントを作成することに注意を払うあまりに、ドキュメントの作り直しが必要なアイディアを無視するようなことがあっては本末転倒になります。

「宣言」にある「契約交渉よりも顧客との協調を」と「計画に従うことよりも変化への対応を」は密接に関係している、というより同じことの言い換えです。「開発」に未知数があるのは自明で、初めの契約や計画の絶対化や固執は、実り多い成果への障害というしかありません。

しかし、一方でシステム開発も企業の論理の外にあるものではなく、お金が絡む問題なので、契約・計画・管理を軽視することはできません。「契約」「計画」「柔軟な対応」のトレードオフ関係を解決する簡単な処方箋はありませんが、アジャイル開発の原則が述べている次の言葉が解決への道を示唆しているのではないでしょうか。

・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 ・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

アジャイル開発のメリット・デメリット

ここでは、アジャイル開発のメリットとデメリットについて解説します。プロジェクトによってはアジャイル開発に向いていない場合があるため、すべてにアジャイル開発を取り入れるのは危険です。メリットとデメリットを理解し、担当するプロジェクトに合わせて計画を立ててください。

アジャイル開発のメリットは、開発のスピードが早いことと臨機応変な対応が可能なことです。従来の開発方法であるウォーターフォール開発の場合、あらかじめ決まっている計画や設計に沿って開発を進めます。そのため、スケジュールの後半で発生したトラブルが開発の前半での不備が原因の場合、大きな後戻りが発生します。

一方アジャイル開発の場合、機能単位で細かいスケジュールを組んでいるためトラブルが発生しても後戻りが少なく、すぐに修正が可能です。また、開発の途中で要件や仕様の変更があっても柔軟に対応できるため、顧客の要望に沿った開発ができます。

さらに、アジャイル開発は最近注目されているDX（デジタルトランスフォーメーション）との相性も良いです。DXとは日々変化するテクノロジーや人々の生活が変化するのに合わせて、ビジネスの形を変えていくこと。アジャイル開発では開発の途中での仕様・要求の変更を受け入れることができるため、顧客のニーズに合った開発方法とDXの組み合わせは最適だといえます。

アジャイル開発は臨機応変な対応ができることがメリットですが、その分進捗状況の管理やリスケジュールの対応が困難な場合があります。顧客の要望や開発途中で出てきた課題に細かく対応し過ぎて、納期に間に合わないといったことになっては本末転倒です。

全体のスケジュールや納期も意識しつつ、その都度出てくる要望や課題に対応することが大事です。また、顧客ニーズを何でも取り入れようとすると開発の方向性がブレてしまうこともあります。最終的な完成物のイメージを開発者や関係者と共有し、全員が同じ目標に向かって開発することを意識しましょう。

アジャイル開発の手法

アジャイル開発には2つの手法があります。ここでは、アジャイル開発の手法である「スクラム」と「エクストリーム・プログラミング（XP）」について解説します。

スクラムとはチームで開発をする上で効率の高さを重視したフレームワークのことです。チームでプロジェクトに取り組む姿勢から、ラグビーのスクラムが名前の由来となっています。スクラム開発ではメンバーそれぞれがイテレーションの計画を立て、設計から実行までを担当します。イテレーションごとに進捗確認・成果物の動作テストなどをチームで共有する必要があり、チームのコミュニケーションが重要となります。

そのため、コミュニケーション不足はスケジュールの遅れ・バグの見落としなどに繋がります。小さなミスやバグを放置するとあとから大きな問題に発展することもあるため、その都度柔軟に対応することが大切です。

DX時代に脚光を浴びる「アジャイル開発」の本命「スクラム」とは？

エクストリーム・プログラミング（XP）とはスクラムよりもプログラマー中心の開発技法で、顧客の要望や開発段階での課題を柔軟に取り入れることができます。開発途中で仕様を変更できるため、より顧客の要望に沿った開発が可能です。

主な手法として2人1組でプログラミングを行うペアプログラミングや、ソースコードや用語のメンバー共有、コードの改善、機能の実装の前にテストを作成するテストファーストといったものがあります。これらはプログラマーにとってプログラミングのしやすさにアプローチした方法と言われており、失敗やバグの防止につながります。

ダークアジャイルに踊らされず悩まされないシステム開発を

ここまで述べてきたように、「アジャイル開発宣言」の原則・精神をプロジェクトに活かすのは、そう簡単なことではありません。エンジニアとしては、スクラム開発などのアジャイル開発の手法に取り組む前に「宣言」を読み返して、その原則と哲学を確認してみる必要がありそうです。

アジャイル開発のメリット・デメリットや代表的な手法について解説！