最近、アジャイル開発という言葉が、大分、定着してきました。
しかし、全体的に、アジャイル開発の手法やツールなど技術的側面がクローズアップしているように思えます。
そのせいか、開発プロジェクトにアジャイル開発を適用しても、うまく行かなかったという例が多々あるようです。
それは、アジャイルの根本的な哲学が理解されることなく、表面的な理解だけで取り入れようとしているからなのではなでしょうか?
今回は、アジャイル開発について、以下の順に解説します。
- アジャイル開発とは
- アジャイル開発とウォータフォール型開発
- エンタープライズアーキテクチャ(EA)におけるアジャイル開発の位置付け
- アジャイルソフトウェア開発宣言とは
アジャイル開発とは
アジャイル(Agile)とは「素早い」とか「機敏な」という意味です。
なので、アジャイル開発とは、機敏な開発方法というこになります。
どういうことでしょうか?
それは、ソフトウェアを小さな単位に分けて、小単位で実装とテストを繰り返して開発を進めることで、途中で変化が起こっても機敏に対応できることを表しています。
小さな単位で顧客の目に見えるものが出来上がっていくので、その都度、顧客の要求が明確になり、その要求を製品に反映していくことができます。
つまり、アジャイル開発は「早く開発できる」というよりも「要求の変化に機敏に対応できる」開発方法を表す言葉ということです。
アジャイル開発とウォーターフォール型開発
ソフトウェアの開発方法は、大きく
- ウォーターフォール型開発
- 反復型開発
に分けることができます。
それぞれ、見ていきましょう。
ウォーターフォール型開発
ウォーターフォール型開発とは、ソフトウェアの開発工程を時系列に分けて、順番に開発していく方法です。
ソフトウェア開発が、工程ごとに、あたかも滝(waterfall)のごとく水が上から下に落ちていくように進んでいくのでウォーターフォール型開発と呼びます。
ウォーターフォール型開発では、一つ工程を一度で終わらせる計画を立て進捗を管理するので、原則として、前工程が完了しないと次工程に進みません。
なので、ウォーターフォール型開発のメリットは、開発工程が順番に流れていくシンプルな構造になっており進捗管理しやすいということです。
逆に、ウォーターフォール型開発のデメリットは、比較的、開発のリスクが高いということです。
なぜでしょうか?
ウォーターフォール型開発の問題点は前工程に間違いがないことを前提にしている点です。
顧客の要求を事前に詳細に定義することは非常に困難です。
なぜならば、ソフトウェアは概念で変わりやすいものなので、それを明確な形で表すことが困難だからです。
なので、顧客の要求を徹底的に確認したにも関わらず、下流工程になって始めて顧客の目に見えるものが出来上る場合、それを見た顧客から修正要望が出ることがあります。
この要望に応えるには、時間をかけて進めてきた工程を、後に戻してやり直す必要があります。
開発の後戻りにより、開発の予算や納期をオーバーしてしまう可能性があるのです。
反復型開発
反復型開発とは、ソフトウェアを小さな単位に分けて、小単位で一連の開発工程を繰り返し、段階的にリリースしていく開発方法です。
この小さな単位をイテレーション(反復)といいます。
反復型開発のメリットは、比較的、開発のリスクが低いということです。
反復型開発の場合、小さな単位で顧客の目に見えるものが出来上がっていくので、その都度、顧客の要求が明確になり、その要求を製品に反映していくことができます。
なので、開発の初期段階から顧客の要求とのズレを調整しいくことができ、ウォータフォール型開発のように、後工程で、いきなり顧客の要求との大きなズレが発覚することは、まずありません。
それでは、反復型開発デメリットは何でしょうか?
それは、進捗管理が難しいということです。
反復型開発の場合、小さな開発単位が反復しながら進んでいくとともに、状況状況に合わせて反復を設計する必要があるので進捗管理が複雑です。
縦軸に開発のリスク、横軸に時間をとってウォータフォール型開発と反復型開発の違いを表すと下図のようになります。
ウォータフォール型開発が開発の後半までリスクが残っているのに対し、反復型開発は、初期段階からリスクが下がっていることがわかります。
さて、アジャイル開発ですが、これは反復型開発の一種です。
ただ、通常の反復型開発が開発計画を重視するのに対し、アジャイル開発はソフトウェアが顧客に提供する価値を重視しています。
なので、アジャイル開発の場合、イテレーションを小さくし、小刻みに顧客の要求を吸収することができるように設計されています。
アジャイル開発 vs ウォータフォール型開発
以上より、アジャイル開発とウォーターフォール型開発を、
- 進捗管理の難易度
- 開発のリスク
という観点から比較すると次のようになります。
ウォーターフォール型開発のプロセスは、建物の建築プロセスに似ています。
建物の場合、建築様式がほぼ決まっており、建築過程で顧客の要求がコロコロ変わることもないので、要求、設計、施工という順で問題なく進めることができると思います。
ビジネスの変化も少なく、先行きが予測できた時代は、顧客の要求も一定で、ソフトウェア開発も建築業のプロセスで進めることができたと思いますが、ビジネスの変化が激しく、先行き不透明な昨今、ビジネスの変化に合わせて顧客の要求も変化するので、ソフトウェア開発に建築業のプロセスを適用することが、事実上、難しくなってきました。
アジャイル開発の場合、このような時代の変化を受けて、顧客の要求は変化することを前提に考えられており、建築業の堅いプロセスより、サービス業の柔らかいプロセスに近いものになっています。
以上、アジャイル開発の意味や特徴を、ウォーターフォール型開発と比較しながら見てきました。
次に、企業全体の業務とシステムの設計図の中で考えると、アジャイル開発はどのように位置付けられるのか見ていきましょう。
エンタープライズアーキテクチャ(EA)におけるアジャイル開発の位置付け
企業全体の業務とシステムの設計図をエンタープライズアーキテクチャ(EA)といいます。
EAは4階層で構成されており、その中の一つにテクノロジーアーキテクチャ(TA)があります。
TAは、物理インフラとマネジメントインフラから構成されています。
マネジメントインフラには、システムを開発してリリースするまでのマネジメント標準を表すシステム開発マネジメントと、システムリリース後、システムがビジネスをどう支援するかに関するマネジメント標準を表すITサービスマネジメントがあります。
アジャイル開発のシステム開発マネジメントを、アジャイル開発マネジメントといいます。
ここで、アジャイル開発マネジメントを、
- 哲学
- 手法
- ツール
に分けて整理してみましょう。
すると、
- ベースにアジャイル開発の哲学であるアジャイル開発宣言があり、
- その上に、スクラムやDevOpsのような手法があり、
- その上に、バージョン管理などのツールがある
という構成になります。
これを見てもわかるように、手法やツールを効果的に活用するためには、まず、アジャイルの根本的な哲学、アジャイルソフトウェア開発宣言を理解する必要があります。
アジャイルソフトウェア開発宣言とは
2001年、アジャイル開発の分野の著名人17人がアメリカ合衆国のユタ州のスノーバードに集まり、それまで個別に提唱していた開発手法の重要な部分を統合し、アジャイルソフトウェア開発宣言(Manifesto for Agile Software Development) としてまとめました。
これを読むと、従来型のウォーターフォール型開発との考え方がの違いが明確に打ち出されています。
これは、ソフトウェア開発だけでなく、ビジネスや政治などあらゆる分野において、時代に合わせて新しいマインドセットをインストールせよ、と叫んでいるように聞こえるのは私だけでしょうか。
たまに、ソフトウェア開発には計画やドキュメントは必要ない、と言うアジャイル開発フリークがいます。
しかし、これを読むと、そうではないことがわかります。
従来のやり方を認めつつ、時代に合わせて比重を移したほうがいいよ、と言っていますね。
作ることが目的ではなく、顧客に価値を提供することが目的です。
作れば売れる時代は、作ることが目的だという錯覚を植え付けました。
改めて、誰のために作るのか、原点回帰しましょうという姿勢が伺えます。
さて、アジャイルソフトウェア開発宣言には、アジャイル宣言の背後にある原則があります。
顧客と開発者は運命共同体です。顧客に寄り添って開発しましょう。
短い期間で、目に見える動くソフトウェアを提示して、継続的に顧客の要求を対面で確認しながら機敏に進化し続けるというリズムをつくりましょう。
そのために、互いを信頼し、顧客価値を生まないムダを削り、優れた技を蓄積・共有できる自律的なチームを目指しましょう。
このアジャイル開発の哲学が腹に落ちてこそ、アジャイル開発の手法やツールを使いこなせるのではないでしょうか。
DevOpsに関して参考になる書籍には以下のようなものがあります。
The DevOps ハンドブック 理論・原則・実践のすべて
[改訂第3版]Jenkins実践入門 ――ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)
Docker/Kubernetes 実践コンテナ開発入門
以上、今回は、アジャイル開発について解説しました。
[…] という観点から比較すると次のようになります。 ウォーターフォール型開発のプロセスは、建物の建築プロセスに似ています。 建物の場合、建築様式がほぼ決まっており、建築過程で顧客の要求がコロコロ変わることもないので、要求、設計、施工という順で問題なく進めることができると思います。 ビジネスの変化も少なく、先行きが予測できた時代は、顧客の要求も一定で、ソフトウェア開発も建築業のプロセスで進めることができたと思いますが、ビジネスの変化が激しく、先行き不透明な昨今、ビジネスの変化に合わせて顧客の要求も変化するので、ソフトウェア開発に建築業のプロセスを適用することが、事実上、難しくなってきました。 統一ソフトウェア開発プロセスでは、、このような時代の変化を受けて、顧客の要求の変化に機敏(アジャイル)に対応できるサービス業のプロセスに近い反復型開発をベースに組み立てられています。 ここで、反復的でインクリメンタルなプロセスについて明確にしておきましょう。 反復的(イテラティブ)プロセスと漸増的(インクリメンタル)プロセスを分けて考えます。 反復的プロセスでは、サイクルを繰り返すごとに、システム全体の濃度が上がるように仕上げていきます。 一方の漸増的プロセスでは、システムを小さな要素に分解し、サイクルを繰り返すごに要素を一つづつ仕上げていきます。 反復的でインクリメンタル(漸増的)なプロセスとは、この2つの組み合わせで、骨組みであるアーキテクチャが固まったあとは、ユースケース一つ一つを漸増的に仕上げていき、システム全体を反復的に肉付けしていくという方法です。 これは、ユースケース駆動とアーキテクチャ中心というコンセプトを活かした反復型開発で、ユーザーに対する価値を持続的に提供し続けられるシステムを構築するためのモデルになっているのです。 ここでは、反復的でインクリメンタルなプロセスを開発の工程(縦)と開発のフェーズ(横)に分けて解説します。 なお、反復型開発の一種に、アジャイル開発があります。 通常の反復型開発が開発計画を重視するのに対し、アジャイル開発はソフトウェアが顧客に提供する価値を重視しています。 アジャイル開発については、記事アジャイル開発とは何かを参考にしてください。 […]
[…] 合性を上げることができる アジャイル開発は、反復的・漸進的な開発& […]