【開発法】アジャイルについて理解を深める（1）
はじめに
こちらは、私が開発技法についての理解を深めるメモのようなものです。
もし参考になれば幸いです。
また何か間違いなどありましたら、コメントでのご指摘のほどよろしくお願い致します。
前回までのアウトプット → https://mikiyakupo.hatenablog.com/entry/2020/08/25/161732
ゴール
アジャイルが生まれた背景を知る
アジャイルとはそもそも何かを知る
- はじめに
- ゴール
- そもそもアジャイルとは何か？
- ウォーターフォール（WF）について
- アジャイルの立ち位置
- アジャイルはマインドセット
- ウォーターフォールとの違い-鉄の三角形（アイアントライアングル）による説明
- 「鉄の三角形」で何を重視するのか？
- まとめ
- 参考
そもそもアジャイルとは何か？
既存の開発モデルに対するアンチテーゼとして提案された考え方。
日本語訳すると「俊敏」とかになる。
ここで重要なのが、あくまで「考え方」である点。
よく、ウォーターフォール VS アジャイルと対立概念として並べられる事が多いが、
そうでもない。
この点に関しては、後ほど記載する「アジャイルソフトウェア開発宣言」にて取り上げたいと思う。
ウォーターフォール（WF）について
ウォーターフォールは、最も知名度が高く、最も古く、基本的な開発モデル。
上図は簡略したものであるが、基本的に要件定義からシステムのリリースまで一気に下るものであり、
前の工程に戻ることはない。
ウォーターフォールのメリット
- 開発経験の多さ
最も古い基本的な開発モデルだからこそ、ウォーターフォールで開発する経験を持ったSEが多い。 - 計画が立てやすい
ウォーターフォールでは工程を区切る。
そして工程ごとに何らかの成果物を顧客に対して提示する。
そういっった形だからこそ、次の工程からもっと安いベンダーに発注できたり、
工程ごとに管理ができるためある程度の計画の調整が可能である。 - 進捗管理がしやすい
どんな作業を行うのかスコープが決まっている場合が多いため、
作業進捗の管理が行いやすい。
ウォーターフォールのデメリット
- 途中変更しづらい
ウォーターフォールでは先程も記載したように、前工程に戻ることは基本的にない。
開発の後期になって、要件定義時といった上流工程では想定されていなかった要望が判明する事がある。
場合によるが、再要件定義になったりPJ自体が中断することも考えられる。
後ほど触れる「アジャイルソフトウェア開発宣言」にも絡んでくるが、
変更を容易に受けることが出来ない所が問題に取り上げられている。
- 成果物作成による作業時間増加
各工程ごとに成果物（要件定義書等）が求められるため、
開発規模に比例してこの成果物に対する作業時間も増加することが考えられる。
アジャイルの立ち位置
ここまで記載した従来の開発モデルの代表であるウォーターフォールに対して
どういう立ち位置として提言されたのかまとめる。
従来の開発モデル
<https://mikiyakupo.hatenablog.com/entry/2020/08/25/161732 > 上記の勉強でまとめたウォーターフォールやスパイラルモデルなどは、ソフトウェア工学のライフサイクルモデルに基づくもの。
要件定義 基本設計 詳細設計 プログラミング 単体テスト 結合テスト 運用テスト リリース・保守
といった工程をどのように実践していくか？という試みであった。
変化
1990年代後半から現在に掛けてITとビジネスの関係が大きく変化してきた。
以下の画像を見てもらいたい。
1990年代までは、ITは便利な道具だった。
そこからITは徐々にビジネスにとって欠かせないものとなっていく。
そして現在、ITがビジネスのコアとなりIT無しでは既にビジネスが成り立たない時代である。
また技術の変化スピードがとても早いことは目に見えてわかる。
そうした中、企業は競争力維持強化することを迫られるのだ。
システム一つとっても、1年以上掛けて開発していれば新しい技術がビジネスモデルとして確立するかもしれない。
そのための変化に適応しやすいシステム開発が求められる様になった。
アジャイルソフトウェア開発宣言
こういった時代に直面し、生まれたのがアジャイルという考え方。
この考え方を反映しているものが、「アジャイルソフトウェア開発宣言」である。
ここに一部を抜粋し、記載する。
プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、価値とする。
そしてもう一つこれを支える原則の一部を以下に抜粋する。
要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。
この宣言と原則を見てわかるように、
既存開発モデルであるウォーターフォールのデメリットを包括的に補う形で
ITの変化とビジネスモデルの変化に対して柔軟に対応しようと宣言されている事がわかる。
アジャイルはマインドセット
アジャイルは、決してウォーターフォール等の対立開発モデルとしての開発手法のことではない。
アジャイルとは、「こうしたらどうだ？」という一種のマインドセットのようなもの。
これは先程のアジャイルソフトウェア宣言に確認することができる。
すなわち、左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく。
これは先程の、「プロセスやツールよりも…」に続く文言である。
左記とは従来の開発モデルに見られるモノ。
右記にはそれに対応した策。
「認めながらも」とある。
つまり対立概念ではない。
「こういうのはどうだ？」という提言、一種のマインドセットのようなものであることが読み取れる。
ウォーターフォールとの違い-鉄の三角形（アイアントライアングル）による説明
アジャイルはウォーターフォールに対立する開発モデルではないため、ここからはアジャイルな考えと表記していく。
アジャイルな考えとウォーターフォールではどんな違いがあるのか。
これを説明する一つの方法は、システム開発における「鉄の三角形」である。
マイクロソフトのサイトにこちらについて詳しい解説がある。
簡単に言えば、システム開発では「スコープ（何を作るか）・コスト（作るための資源はどれくらいか）・スケジュール（いつまでに作るか）」が制約としてついてくるというもの。
スコープを重視すれば、コストやスケジュールに影響は出るし、
ほかもまた然り。
この3つは相互に作用し、切っても切り離せない関係ということだ。
そんな鉄の三角形で、「何を重視するのか？」が
アジャイルな考えとウォーターフォールの違いに出てくる。
「鉄の三角形」で何を重視するのか？
It is argued that the waterfall model can be suited to projects where requirements and scope are fixed, the product
itself is firm and stable, and the technology is clearly understood.
引用：https://en.wikipedia.org/wiki/Waterfall_model
特にrequirements and scope are fixedの部分。
ウォーターフォールは、要件とスコープが固定されているプロジェクトに向いているということである。
最初から明確に何を作るかが定義されている。
一方アジャイルではどう考えられているのか。
Compared to traditional software engineering, agile software development mainly targets complex systems and product development with dynamic, non-deterministic and non-linear characteristics.
見てもらいたいのは以下部分。
mainly targets complex systems and product development with dynamic, non-deterministic and non-linear characteristics
「動的で非決定的かつ非線形な特徴を持つ複雑なシステムと製品開発」に向いているという。
つまり、最初から何を作るかは明確に定義はされていないのである。
画像に表すと以下のようなイメージ。
ウォーターフォールでは、
最初から何を作るかという成果物が明確化されている事が多い。
それに対する期間や人月といったコストは後から決まる可変である事がおおい。
一方のアジャイルな考えでは、
コストや市場に参入するための期間などは決まっている事が多いが具体的な成果物が定義されていることは少ない。
また短期的なスプリントという単位で開発をすすめるため、そういった意味でも期間は固定されているとも言えるだろう。
まとめ
今回はアジャイルの理解を深めるため、既存の開発モデルの代表であるウォーターフォールとの違いを見てきた。
ウォーターフォールはソフトウェア開発のライフサイクルをモデル化したものであるが、
アジャイルは時代背景に合わせて既存開発モデルに対する提言であり、対立した概念ではない。
そしてその考えとは、
対話と変化への対応を重視したものであった。
少しでも違いについてヒントになれば幸いです。
参考
IPA（2019）『ユーザのための要件定義ガイド 第2版要件定義を成功に導く128の勘どころ』
「アジャイルソフトウェア開発宣言」https://agilemanifesto.org/iso/ja/manifesto.html
「アジャイルとは？アジャイルを教わりに行ったら組織哲学を学んだ話。LINEアジャイルコーチ 横道さんにFLEXYの麻衣子お姉さんが聞く！ #アジャイル編」
https://flxy.jp/article/5984
プロジェクトの三角形https://support.microsoft.com/ja-jp/office/%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AE%E4%B8%89%E8%A7%92%E5%BD%A2-8c892e06-d761-4d40-8e1f-17b33fdcf810
