アジャイルとウォーターフォール開発

# 記事の目的・背景
SI・コンサルなどのエンタープライズ業界でもアジャイル開発を取り入れる動きがあります
とはいえまだまだ開発事例などは少ないです（あってもなんちゃってになる）
ここ数日Twitter（X）でも話題なので2つの違いや問題点などについて記載出来ればと思います

:::note warn
ここで記載するアジャイルはスクラムを前提として記載します
アジャイル＝スクラムでないことは注意ください
:::

# アジャイル開発とは
そもそもアジャイル開発ってなに？ってところでアジャイルの意味は**素早い・機敏な**という意味になります
以下はアジャイル開発宣言の文ですが、**動くソフトウェアを優先に作ろう**ってことになります

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/d7098542-2940-c23c-5480-fcbbcd2c99e6.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/75a445ff-37ca-3cd5-fe6c-b3d7d7bb8d51.png)



## アジャイル開発よくある勘違い

### 成果物に関する勘違い
**アジャイル開発の成果物ってソフトウェアのみで設計書とか書かなくていいんでしょ？**

アジャイル開発挙げられる成果物はバックログとインクリメントとして定義されます
バックログはプロダクトそのものを指す場合とスプリントごとを指す場合で粒度が異なりますが、タスクやゴールみたいな計画基準に当たります

じゃあインクリメントってなんだろう？ってことで調べてみると以下の情報がでてきます

デジタル庁 デジタル社会推進標準ガイドラインから引用すると開発成果物を動くシステムそのものを開発成果物としてスクラムでいうインクリメントと呼ぶとあります
つまり設計書などはインクリメントとして定義していないように見えます

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/8b20d969-710d-f995-c8c5-ce62a9f50c98.png)

以下の2つはIPAのアジャイル開発の進め方とスクラムガイドからの抜粋ですが「インクリメント一回のスプリントにおける成果」「プロダクトゴールに向けた具体的な踏み石である」と記載があり設計書は作らないとは捉えられない文章です

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/4b99f0d9-aefa-2748-6cb3-75291f921012.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/70d532a9-23df-2d55-d6b4-52faa7b3b47a.png)

**・結論**
アジャイル開発では設計書などのドキュメント類はプロジェクトにより異なるので自分たちで決めましょう
必要ないなんてことはない

### 全体計画に関する勘違い
**アジャイルって柔軟に開発を進めていくから全体計画とかって作らなくていいんでしょ？**

デジタル庁 デジタル社会推進標準ガイドラインから引用すると結論としてはNOです
当たり前ですね
無限にお金が湧いてくるわけでもないし！
MVP（Minimum Viable Product）の定義や優先度マイルストーンの定義墓わらず、必要になってくるとお思います

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/ef4d0b74-d077-8b47-8537-8e98da727643.png)

# ウォーターフォール開発とは

ウォーターフォール開発は、システムやソフトウェアの開発で用いられる開発手法です。
ウォーターフォール（Waterfall）は英語で「滝」を意味し、その言葉通り滝のように上から下へ、つまり上流工程から下流工程へと順番に開発が進められていく開発手法です。

## ウォーターフォール開発よくある勘違い
### 不可逆性に関する勘違い
上記の通りウォーターフォールは上から下へ順番に流れていく開発手法です
その結果前工程の要件を詳細化していくことはあっても増えたり減ったりすることはありません
そんな事が起こる場合（実際の現場ではあるあるだと思う）は完全なるアンチパターンであることを頭に入れておかないといけないです
# アジャイルとウォーターフォールの違い
## QCDの取り扱い

![4ef4dcb4-11c8-4010-9b99-5bf60f358bd1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/78fe9090-4187-34e4-ebab-e4f2d51263f5.png)

ウォーターフォールではスコープ（要件）が決まっています
最初に決めた要件を実現するべく納期やコストは増減します

アジャイルではコストと納期を固定した上でスコープが変化します
そのためには最低限度必要な機能（MVP）や各機能の優先度を明確にする必要があります

## プロセス

![2021_colser_img03-1024x531.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/137987/133b3fa6-8080-d02c-dfa5-8f6ea6b2178b.png)

ウォーターフォールでは要件定義で定義した要件を設計→開発→テストと工程を進めていき最後にリリースします

アジャイルでは決まったコストと納期内でスプリントを複数実行し、リリースを繰り返していきます
※1スプリント＝１リリースとは限らない

## ロール（役割）
[従来型ロールとアジャイル型ロールの対応イメージ](https://www.ipa.go.jp/files/000065437.xlsx)

半分参考資料ですが、IPAによるウォーターフォールとアジャイルのロールの対応表です
これを見るとわかりますがウォーターフォールは役割がある程度明確ですが、アジャイルではみんなが各工程に関わってくるため役割分担が不明確です

# 私の考え

アジャイル開発ではチーム一丸となって開発を進める必要があります
ひときわPdM（プロダクトマスター）の動きが大切になってきます

日本のエンタープライズ領域のソフトウェア開発では社外のSIerなどへ外注し進める場合が多いです
その結果ステークホルダーが増え、開発管理の複雑化してるのかと思います

実際社内システムを内製化しているアメリカではアジャイル開発が向かないという話は聞きません

如何に社外まで含めた関係者をまとめ上げて開発を進められるかが鍵なのかなと思います

## 参考意見
Twitterに流れる話題のツイートをいくつか載せておきます

https://x.com/MochinecoNonato/status/1761693264900731345?s=20


https://x.com/s5ml/status/1761511324226584703?s=20

https://x.com/hpeo_jp/status/1760500911229554738?s=20

https://x.com/kabukawa/status/1761345735193460967?s=20

# 参考資料
このブログを書くに当たり参考にした資料です
できるだけ公式的な文章を集めて中立的な意見を書けるようにしました

[IPA アジャイル開発の進め方](https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065606.pdf)
[デジタル庁 デジタル社会推進標準ガイドライン](https://www.digital.go.jp/resources/standard_guidelines)
[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)
[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)