【開発手法モデル】アジャイルとは?ウォータフォール型との違いは?

  • このエントリーをはてなブックマークに追加
  • Pocket

こんにちは。タクマ™ [@suwaru_blog] です。

最近どこの現場も「猫も杓子もアジャイル開発」な感じです。
僕もウォータフォール型の開発現場で苦い思いをしたので気持ちは分かります…

ウォータフォールってなに?アジャイルってなに?

駆け出しエンジニアの頃、その言葉の意味をよくわかっていませんでした。
難しい言葉を難しい言葉で説明しないでほしいなぁと。

今回はそんなソフトウェア・システム開発手法の 1 つ「アジャイル」をやさしく解説します!

そもそもソフトウェア・システム開発手法ってなに?

ソフトウェア・システム開発手法とは、開発工程のフレームワークです。

  • ウォータフォール
    • 古くからある、もっともポピュラーな開発手法
    • 顧客の要求分析から本番稼働まで一気にやる
    • 基本的に後戻りしないので、工数見積もりや進捗管理がしやすい
  • アジャイル
    • つくるシステムを「小さな単位」に分割して、開発計画を立てる
    • 分割した小さい単位を「短い期間」内で開発する
    • 短い期間の開発を「反復」していくことで最終的に完成させる
    • 全体の進捗管理は難しいが、突然の変更に対応しやすい

それぞれ長所・短所があるので、
プロジェクトの性質や状況に応じて最適な開発手法を選択する必要があります。

ウォーターフォールとは?

アジャイルが登場する以前の開発手法「ウォータフォール」についてまず触れておきます。

従来型の「ウォーターフォール」の問題点

  1. 要求分析
    • 顧客と打ち合わせして、システムの要件を決める (要件定義)
  2. ソフトウェア設計
    • システムの基本設計書・詳細設計書をつくる
  3. 実装
    • コーディング・レビューする
  4. テスト
    • 単体テスト・結合テスト・総合テストをする
  5. デプロイ
    • サーバにシステム配置したり、ストアにアプリをアップロードする
  6. メンテナンス
    • 本番稼働後に運用・保守をする

このプロセスに数ヶ月 〜 数年かけて、後戻りせず突き進むことをウォータフォールと言います。

ウォータフォールは日本語で「滝」という意味ですが、
1 に近い工程を「上流工程」6 に近い工程を「下流工程」と言います。

時間をかける慎重な開発手法なのですが、
現実は下流工程でも突然に要件が変わったり、新しい要件が見つかります。
これを仕様変更と言います。

仕様変更が起きると一体どうなるのか

実装がすでに始まっている場合、仕様変更にうまく対応できないことがあります。
これがウォータフォールの一番の問題でした。というか 2020 年現在も問題になっています。

エンジニアはそれまで作り上げたものを捨てて後退するか、
断固たる態度で変更を拒否するしかありません。

そのため、プロジェクトの進捗が遅れるか、
間違ったものを作ってしまい、顧客を怒らせることになります。

アジャイルとは?

仕様を無視することは大問題ですが、
近年「要件はプロジェクトの終盤に入るまでわからないもの」という考えが出てきました。

ここでアジャイルという考えが登場します。

アジャイルとは「仕様変更を受け入れる」こと

要件の変更を認め、受け入れ、そのような制約に逆らわず、
むしろ制約をうまく受け止められるような開発プロセスを構築すること

これがアジャイルのキモです。

アジャイル採用している現場にいながら、
「仕様変更うぜー!」みたいなこと言う人がいますが、アジャイルとはそういうものです。

アジャイル宣言 – アジャイルで大切にすること

ユタ州のスノーバードというスキーリゾート地にて、
業界リーダーやエンジニアが集まり、アジャイルに関する議論をしました。

そこで生まれたのがアジャイル宣言。アジャイルの原理原則です。その内容を要約します。

  • 「プロセス・ツール」 <「 個人とのコミュニケーション」
  • 「ドキュメント」 < 「実際に動作するソフトウェア」
  • 「契約交渉」 < 「顧客との協力」
  • 「計画の遂行」 < 「変化への対応」

アジャイルでは左側より右側の項目のほうが重要である!…と宣言しています。

あくまで優先順位の話

勘違いしてはいけないのが、左側の項目を軽視するわけではありません。
アジャイル宣言はあくまで優先順位について言っているのです。

例えば「ドキュメント」を軽視するわけではありません。
これがないと新しくジョインする開発者が困りますし、引き継ぎもスムーズにいきませんね。

アジャイル 12 の原則 (マニフェスト)

先程のアジャイル宣言は、以下の 12 の原則が元になっています。
大事なところを赤文字にしました。

  1. 私たちは、価値のあるソフトウェアを早い段階から継続的に提供し続けることを通じてお客様に満足してもらうことをほかの何よりも優先する。
  2. 開発作業が終盤に入っても、要件の変更を歓迎する。アジャイルプロセスは、お客様の競争優位を実現するためのチャンスとして要件変更を活用する。
  3. 動作するソフトウェアをひんぱんにお客様に届ける。ひんぱんとは 2、3 週間から 2、3 か月という意味で、短ければ短いほどよい。
  4. ビジネスサイドの人々とソフトウェア開発者は、プロジェクトを通じて毎日協力して仕事を進めなければならない。
  5. 意欲のある個人を中心としてプロジェクトを進める。彼らが必要とする環境とサポートを提供し、彼らを信頼して仕事を任せる。
  6. 開発チーム内で、また開発チームとの間でもっとも効率よく効果的に情報をやりとりする方法は、顔を突き合わせての対話だと考える。
  7. 進捗状況の最大の尺度は、動作するソフトウェアだ。
  8. アジャイルプロセスは持続可能な開発を奨励する。資金提供者、開発者、利用者は、いつまでも一定のペースを維持できなければならない。
  9. 技術的な卓越性と優れた設計に絶えず注意を払うことにより機動性を引き上げる。
  10. 単純性、すなわちしなくて済む作業をできる限り増やす技術が必要不可欠だ。
  11. 最高のアーキテクチャー、要件、設計は、自律的なチームから生まれる。
  12. チームは定期的にもっと効果的な仕事を生み出す方法を考え、それに従って行動を調整するものとする。

乱暴な言い方をすると、

少数精鋭のチームで、無駄を省いて、優先順位つけて早く開発しようぜ!

…って感じでしょうか。
技術を重要視する一方で、コミュニケーションの重要性も説いているのがいいですね。

絵に書いた餅になることは多い

ここまで「アジャイル、めっちゃいいじゃん!」って感じがします。

しかし、チームでモチベーションを高く維持して、
短い開発期間を遵守しながらリリースし続けるのは大変なことです。

例えば、自分のタスク管理で TODO リストを作ることを想像してください。

TODO を詰め込んだものの、
いつしか実行されない TODO で溢れかえり、
TODO リストそのものがまったく機能しなくなった…

そんなことはないですか?アジャイルでは日々のタスク管理が重要です。
細切れになったタスクを「毎日淡々とこなす」ストイックさが必要です。

8. アジャイルプロセスは持続可能な開発を奨励する。資金提供者、開発者、利用者は、いつまでも一定のペースを維持できなければならない。

アジャイル採用する場合「持続的に開発しづづける困難さ」をイメージしておきましょう。

アジャイルは「手法」じゃなくて「概念」

ここまでウォーターフォールとアジャイルの説明をしてきましたが…

ウォータフォールは「手法」ですが、アジャイルは「手法」じゃなくて「概念」です。
アジャイルを具体的な手法に落とし込む必要があります。

アジャイルを使った手法

下記のものがアジャイルを使った代表的な手法です。

  • スクラム
  • カンバン
  • エクストリームプログラミング (XP)

アジャイル採用している現場ではこのどれかを使うことが多いです。
これら開発手法については別の記事で解説します。

関連記事

お仕事ください!

僕が代表を務める 株式会社 EeeeG では Web 制作・システム開発・マーケティング相談を行っています。
なにかお困りごとがあれば、Twitter DM や Web サイトからお気軽にご相談ください。

コメント

コメントを残す

*