アジャイルってどうせアレでしょ?8つの誤解を解いて正しく知ろう
アジャイルなアプローチは、柔軟性や適応性、スピード、継続的なデリバリー、顧客とのコラボレーションなどを特徴とします。ソフトウェア開発の現場を中心に、IT業界で広く受け入れられています。しかし、その人気の高まりとともに、多くの誤解も生まれています。その多くは、従来型のウォーターフォールモデルの長所や特徴との比較で、単純化して語られがちなことから生まれています。
今回は、そんなアジャイル—特にソフトウェア開発に関する、よくありがちな8つの誤解を例に挙げてみます。ウォーターフォールが伝統的に得意としてきたこととの関係性をチェックし、誤解を解きながら、アジャイルの本質について考えてみましょう。基本情報の過去記事も、ぜひ併せてお読みください。
誤解1:アジャイルはドキュメント化を必要としない
すべての段階で徹底した文書化が必要なのが、ウォーターフォールモデルです。それと比較して、アジャイルでは『文書化は必要ではない』と誤解されることがあります。確かにアジャイルマニフェストでは、「包括的なドキュメントよりも動くソフトウェア」を提供することが推奨されます。しかしこれは、文書が要らないという意味ではありません。アジャイルでも、有用で必要な文書を重視されます。
正しい理解1:
文書よりも、実際に機能するソフトウェアを提供することの方が推奨される。しかし、ドキュメンテーションは、アジャイルであっても必要。
誤解2:アジャイルは構造化されていない
ウォーターフォールは高度かつ厳格に構造化されていて、明確なフェーズがあります。伝統的なプロジェクトマネージメントのアプローチと比べると、アジャイルの手法は構造化されていないように見えるかもしれません。しかし、チームワークを重視し、一連の価値観や実践を通じて作業を構造化し、管理するスクラムや、視覚的なタスクを利用してワークフローを管理するカンバンのような手法は、役割の定義や確立された手順、定期的なミーティングなど構造や規律があります。
正しい理解2:
アジャイルは、構造的・反復的なプロジェクト管理の手法である。柔軟性がある流動的なアプローチではあるが、構造化されている。
誤解3:アジャイルは計画を無視していい
ウォーターフォールでは、コーディングの前に大規模で綿密な計画と設計が必要です。一方、アジャイルでは、『立てた計画に厳密に従うことよりも、変化に柔軟に対応すること』が重視されます。しかし、これは計画を無視するという意味ではありません。多くの場合、アジャイルでは、早期に完了させなければならない作業は詳細に、将来の作業は大まかに計画を立て、プロジェクトが進化するにつれて後の段階の詳細が明らかになっていきます。
正しい理解3:
アジャイルに必要なのは、硬直的で柔軟性のない計画より、適応可能で柔軟性のある計画。徐々に詳細が明らかになっていく、反復計画なプロジェクト。
誤解4:アジャイルなチームにマネージャーは必要ない
アジャイルなチームは、各メンバーが自律的である必要があります。そのため、伝統的なプロジェクトマネージメントの役割が明確に定義されているウォーターフォールに対して、マネージャーは必要ないという誤解を招いています。しかし、リーダーシップが必要ないわけでありません。アジャイルにおけるマネージャーやリーダーに求められるのは、チームを促進し、障害を取り除いて、ゴールの達成を支援することです。
正しい理解4:
アジャイルが成功するのは、自己組織的なチーム哲学を持つこと。そのリーダシップを持つマネージャーの存在は不可欠。
誤解5:アジャイルは速くゴールを達成できる
ウォーターフォール開発は、直線的なアプローチから遅く見えるかもしれません。しかし、アジャイルが常に速いというのは誤解で、ただのスピードよりも持続性と品質が重視されます。むしろ、アジャイルの初期段階では、明確なコミュニケーションを確立し、チームが機能するように調整する時間が必要なので、遅く思えるかもしれません。アジャイルが約束するのは、安定した持続可能な作業ペースと、継続的かつ早期にユーザーに価値を提供する能力です。
正しい理解5:
アジャイルでは継続的なデリバリーが促進されるが、より速い開発を保証したり意味するものではない。体制の構築や促進が必須。
誤解6:アジャイルには期限は必要ない
ウォーターフォールのステージでは、開始日と終了日が明確に定義されます。アジャイルには期限がないと誤解されがちですが、そうではありません。過去の開発から得たノウハウや運営指針を活かして改善点などを見つける、エクストリームプログラミング(XP)で使用されるのが、一連の工程を短期間で繰り返す開発サイクルとしてのイテレーション。チームで協力しながら生産性を高めるスクラムで使用されるのが、設計から改善までの一連の流れを繰り返し、顧客の意見を反映するスプリント。アジャイルは、締め切りがないわけではなく、一定の期間やサイクルという明確な期限があります。
正しい理解6:
アジャイルにも期限がある。その期限までに何を納品するかは優先順位に基づいており、スコープは必要に応じて調整される。
誤解7:アジャイルはソフトウェア開発だけのもの
確かに、アジャイルはソフトウェア開発で生まれた考え方です。ウォーターフォールが、ソフトウェア開発以外にも多くの業界で使われてきた一方、アジャイルはソフトウェア開発にしか使えないという誤解を招いている面もあります。しかし、アジャイルの考え方や原則は、製造やマーケティング、人事など、さまざまな業界やプロジェクトに適用できます。
正しい理解7:
ソフトウェア開発に限らず、チームや組織のマインドにアジャイルを導入して定着できるかが重要。
誤解8:アジャイルなら全て解決できる
そんなことがあったら、世の中のエンジニアは誰も苦労はしていないはず…。当たり前ですが、アジャイルはプロジェクトや組織におけるすべての問題を解決できるわけではありません。アジャイルとは、チームがより効果的に機能し、変化にうまく対応できるように導く、一つのベストプラクティスです。アジャイルが成功するかどうかは、チームがアジャイルの考え方を受け入れることができるかどうか、そして組織の文化や体制がそれをサポートしているかどうかに大きく依存しています。
正しい理解8:
アジャイルは万能のアプローチではない。所属チームのカルチャーの転換や、改善への継続的な関与、反復的な学習などが不可欠だと理解することが不可欠。
リープリーパーの記事でも、アジャイルとウォーターフォールを比較した説明をしています。今後も、必要に応じて両者を照らし合わせることはあるでしょう。
しかし、アジャイルとウォーターフォールは、それぞれ長所と短所を持つ異なるアプローチです。長年、安全な選択だとみなされてきた伝統的なアプローチとしての、ウォーターフォールとの対比から生じている妄想と期待は危険です。対立したり、置き換えられるべき手法ではなく、プロジェクトの具体的なニーズや仕様次第で、適材適所で使われることは注意しておきましょう。
また、アジャイルな手法の特徴が活かせるのは、ソフトウェア開発やITビジネスに限った分野ではありません。アジャイルについての思い違いや先入観から解放され、正しい知識と理解を深めながら、実践することでさらに知見を深めていきましょう。