アジャイル開発とは？他の開発手法とどう違うの？

アジャイル開発とは、個人との対話・動くソフトウェア・顧客との協調・変化への対応を重視するソフトウェア開発です。

2000年代初頭に、当時軽量ソフトウェア開発と呼ばれた分野で著名であったエンジニアたちが、それぞれの開発手法・価値観を議論し、共通する概念を定義しました。それをまとめた文章がアジャイルソフトウェア開発宣言です。

アジャイルソフトウェア開発宣言は、4つの価値とそれを実現しやすくする12の原則から構成されます。4つの価値の説明文を引用します。

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

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

ここで「左記のことがら」とされるもの、プロセス・包括的なドキュメント・契約交渉・計画に従うことは、ソフトウェア開発の手段ですが、時としてそれ自体が目的化してしまいます。それを回避して「右記のことがら」、個人との対話・動くソフトウェア・顧客との協調・変化への対応を重視するのがアジャイル開発です。ただ、「左記のことがらに価値があることを認めながらも」とここで記載されてる以上、プロセス等を軽視して良いわけではない点には留意しましょう。

アジャイルソフトウェア開発宣言は日本語訳されて公開されていますので、ご参照ください。（参照先：アジャイルソフトウェア開発宣言）

アジャイルソフトウェア開発宣言を見れば分かりますが、アジャイル開発の原初的な定義では、方法論というよりもむしろマインドセットが問題にされています。何か定まった方法論に従えば良いというものではないですし、方法について強い取り決めがあるわけでもありません。アジャイル開発では「インセプションデッキ」という有名な方法がありますが、これはRobin Gibsonという、アジャイルソフトウェア開発宣言の作者連盟に加わっていない人間が考案したもので、原初の理念には今使われてる代表的な方法論が含まれてないことも多いです。

ただそれだと非常に抽象的で、うまく咀嚼できないところもあります。これについてはIPAが「アジャイルソフトウェア開発宣言の読みとき方」という解説資料を提供しているため、ご参照ください。（参照先：アジャイルソフトウェア開発宣言の読みとき方）

アジャイル開発の目的

では何のためにアジャイル開発という新たな開発手法は提唱されたのでしょうか。それは便利なソフトウェアを開発するためです。

ソフトウェアはあくまで顧客の問題解決のために作られるものであり、顧客の問題解決こそが価値です。ただ、プロジェクトは往々にして、プロセス・包括的なドキュメント・契約交渉・計画に従うことに傾いてしまいがちです。しかしこれらを開発の判断基準とするのは、顧客の問題解決に繋がらない、とアジャイルの提唱者たちは考えました。では何を基準にするとより良くなりやすいか？と考えて、共通点として出てきたのが上記の4つの価値であった、ということです。

アジャイル開発の方法論

アジャイルソフトウェア開発宣言は先述の通りマインドセットが中心で、12の原則もまた非常に抽象的です。具体的な方法論を提示しているわけではありません。

それゆえ、アジャイル開発の具体的な方法論については、複数の手法が提唱されています。代表的なものはスクラム開発、エクストリーム・プログラミング（通称、XP）です。

それぞれの開発手法が固有の方法論を持ちますが、とはいえ共通する要素もあります。代表的なものは、短期間での反復開発です。アジャイルでは基本的に、開発対象を小さくし、その小さい機能の計画～デリバリーを短いサイクルで頻繁に行います。この開発期間は、スクラムならスプリント、XPならイテレーションと呼ばれますが、アイデア自体は同種です。

しかし、この短期間での反復開発手法がなぜアジャイルなのか、つまりどうアジャイルの4つの価値を実現できているのでしょうか。

まず、小さくデリバリーことで、その機能が本当に必要なのかを早期に検証できます。つまり、「動くソフトウェア」という価値を実現できています。

また、早期のフィードバックを得られることで、変化に対して早期に対応ができます。つまり、「変化への対応」という価値を実現できています。

残りの2つの価値はこことはあまり関係ありませんが、少なくとも2つはこの開発手法により実現しやすくなってることがわかります。

ウォーターフォールとの違い

ウォーターフォール開発は、開発の各フェーズを1回で終わらせる開発手法です。アジャイルが各フェーズを何度も繰り返すのとは対照的な手法です。

ウォーターフォールの場合、フェーズの手戻りを許容しません。それゆえ、求められる価値に変化があったとしても、開発のやり直しをしません。仮に手戻りを許容しても、計画～デリバリーまでの時間がかかっているので、リリースした時に初めて「求められていたものと違った」とわかっても、後の祭りとなります。

段階的なリリースとの違い

段階的リリースは、機能単位でリリースしていく開発手法です。アジャイルもまた機能単位でリリースするためその点は似ていますが、システムの完成予定時期の見積もりに違いがあります。

段階的リリースは結局最初に完成形の計画がある＝リリース後の修正を見込まないためにいつが完成時期かを定義できますが、アジャイルはリリース後の修正を見込むために完成形を計画できない所から出発するため完成時期を定義できません。段階的リリースで、リリース後に価値を検証して機能のブラッシュアップを図るのであれば、それは完成時期を定義できないことになり（どういうフィードバックが得られるか予想しようがないため）、それはアジャイル開発となります。

アジャイルの向き不向き

アジャイルもひとつの開発手法に過ぎないため、向き不向きがあります。アジャイルが向かない場合は、コストをかけてでも念入りに計画し実行するしかありません。

アジャイルに向いているのは、以下の条件を満たす開発です。

• メンバーが物理的に近い

アジャイルはメンバーのコミュニケーションを重視するために、前者の要件が望ましいとされます。リモートワークはここに問題を抱えており、リモートワークが不可避な状況では、この問題をいかに軽減するかがアジャイルの成否にかかわります。

• ビジネス上、要件の変化が激しい

ビジネス的な要件の変化に乏しい場合はそもそもアジャイルが必要ありません。要件の変化のしやすさがビジネス上の問題ではなく、単に要件定義者の能力不足である場合、アジャイルは能力不足の隠れ蓑になってしまう可能性があるため、要件の変化のしやすさが何に由来するのかは見極める必要があります。

• 人命・社会インフラに影響が低い

また、人命や社会インフラの停止にかかわるようなシステムではアジャイルは許容されないでしょう。「素早く失敗すること」を手段としているアジャイルですが、それはやり直しがきく状況でのみ許されることであり、人命や社会インフラの停止は取返しがつかないため不適合となります。

アジャイル開発と契約

しかし当たり前ですが、納期やスコープに変化がない状況で要件ばかり変えていたらプロジェクトは立ち行かなくなります。アジャイル開発は納期等の制約への変更なしに要件定義を可能にする魔法の杖ではありません。間違っていた要件＝実現しても無価値なものを実現するぐらいであれば変更すべきであり、素早く価値検証することでその誤りを早期検知しようというスタンス・方法論でしかありません。

そのためこれらの開発体制には契約内容が関わってきます。契約の種類は多くありますが、ここで問題となるのは請負契約と準委任契約です。非常に簡略化すると、前者は完成物に対する責任を負う契約で、後者は工数に対する責任を負う契約です。要件定義で言えば、前者は完璧な要件定義に対して責任を負うことになり、後者は要件定義を行う工数に対して責任を負うことになります。

つまり、アジャイル開発をしたいのに請負契約をしてしまった場合、開発企業は要件の変更がどれだけあっても無償でそれに対応しなければならなくなります。これはビジネスとして現実的とは言い難いでしょう。そのため、アジャイル開発であれば基本的には準委任契約でいくべきです。もし請負契約でやるのであれば、そもそも要件の変更を認めない（アジャイルとはしない）か、相当なバッファを見込んだり、要件変更時の対応について現実的な方策を契約で合意するしかないでしょう。