ウォーターフォール開発の問題点とアジャイル開発のコアコンセプトまとめ


# システム開発手法

新規でシステム開発をする際　どのようにシステムを開発するかの開発手法は２つあります。

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

どちらも非常に有名ですが、ここでは開発手法についてまとめていきたいと思います。（初心者向けです）


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

一般的に「何か目標を達成しよう」とした時に、「逆算」をして計画を立てていくと思いますが、ウォーターフォール開発はまさにその方法と思ってもらって問題ありません。


具体的にはWBS（Work Breakdown Structure）というエクセルなどで作るガントチャート管理表を元に、

1. 要件定義
1. 画面イメージの作成
1. 各種DB・API・フロントエンド設計
1. インフラ構築
1. 実装（バックエンド・フロントエンド）
1. テスト
1. リリース＆納品　

という工程を順番に行なって最終的なシステム開発→納品をする手法になります。


## WBSの作成イメージ
各工程をガントチャートにして上から順にタスクを消化していくイメージです。

要件定義・設計・インフラ構築→上流工程
実装・テスト→下流工程

という言葉はウォーターフォール開発から生まれました。

![ガントチャート.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722496/55c66c8f-4d82-4c1b-9cb0-0b1e43357b63.png)



出典：
https://plus-pm.jp/blog/wbs/

今でも金融や行政システムの開発をする日系大企業を中心に、ほとんどの会社でこの開発手法がとられています。システムの完成形を顧客と話して確定させてから、それに向かってTODOを整理し、各工程に振り分けます。
PM（プロジェクトマネージャー）は、概算ベースで各工程ごとの工数（エンジニア数と開発時間）の見積もりを行います。（PMが各工程のリードエンジニアに工数見積もりを依頼する場合もあります）

そしてその見積もりをベースにして人件費を計算し受託会社(2次受け)やSES（システムエンジニアリングサービス）などに対して開発依頼を出していき、開発がスタートします。

## ウォーターフォール開発の細かな開発の流れ

![スクリーンショット 2025-06-04 22.21.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722496/20755707-a68e-470d-9135-3b332f9faf7f.png)


1. 【要件定義フェーズ】
経営層や上級のマネージャー、PM、CTOなどが顧客とシステムの概要などについて会話をして、そのブリーフをベースに各自PMやエンジニアリーダーが機能要件や非機能要件などを決めていきます。  

1. 【設計フェーズ】
設計の段階になると、大量の設計書をエクセルで作成する必要があるため、日本の場合はここからSESや受託会社などを利用して大規模に設計書の作成を行なっていきます。DB/API/フロントエンド/モバイルと設計専門のエンジニアが日々設計業務だけを行いお互いの作成したエクセルをレビューします。

    大規模なシステムになると場合によっては、ここまでで1.5-2年ほどかかる場合もあります。本当にあります。これは言い換えると、エンジニアとして入社したにもかかわらず、2年間全くコードを書くことなく2年間ずっとエクセルだけという「悲劇」を生むことにも繋がります。日進月歩のIT業界において、新人時代にコードをかかないエンジニアに技術者としての輝かしい未来はありません。
  
1. 【製造（実装）フェーズ】
ようやく実装段階になりますが、人材自分が作成した設計書の箇所を実装するとは限りません。また、設計期間が長期の場合、受託会社やSESなどでは、プロジェクトから退出する方も発生し、新しいエンジニアが実装段階からアサインされる場合は日常茶飯事です。また、実装にはどうしても人手が必要なため、さらに様々なエンジニアが新規アサインされます。
多くのエンジニアは、設計書を作成していないため設計書の読解からスタートします。フロントエンドの場合、ここでようやく設計書の不備やAPIの不具合などに気がつき、その都度関係者に相談や確認、場合によってはバックエンド側の修正を待ってから実装を進めるため　PMがプロジェクト初期段階で決定した工数をオーバーすることは日常茶飯事になります。このようになると、シニアのPMが毎朝遅延しているエンジニアをピックアップして理由を問い詰め、進捗を厳しく管理することも珍しくなくなります。特に新人エンジニアの場合は、どうしても不明箇所が多く、実装が遅くなりがちなため非常に辛い経験をした方も多いのではないでしょうか？

1.  【テストフェーズ】
実装とほぼ同時に進められるのがテストになります。大規模なPJ（プロジェクト）の場合、テスターが配置されてテスト項目の作成とアプリケーションの動作確認、場合によってはエンジニアが書いたテストコードなどを実行して、エクセルにその結果のスクリーンショットを貼り付けるといった業務を行います。実装の修正があった場合は、かならず毎回テストを行って品質を担保しますが、非常に単調な作業が多いと同時に、テストは短納期が当たり前のためどうしてもプロジェクトの脱落者が多い部門でもあります。そしてすべてのテストが完了してシステムはリリース＆納品となります。


## ウォーターフォール開発のメリット（世間一般論）
- 最初に完成物を確定させる
- 開発期間を明確にして、最終納品日を決めることができる
- 必要なエンジニア数の計算をプロジェクトの初期段階で明確にすることができる
- PMにとって、各エンジニアの進捗を管理することが容易
- 設計期間を十分に取ることでトラブルを防ぐことができる


しかし、私自身　複数社においてWBSをもとにしたウォーターフォール開発を経験した中で一般的にメリットとして語られている上記は、すべて問題点になっていました。

:::note warn
最初に完成物を確定させる

そもそもシステム開発がわからない顧客は、最初の段階で完成物を完璧にイメージなどできません。PJの初期段階ではお互い簡単な図解とイメージでしか会話をすることができないため工程が進むにつれて認識のずれが生じ、「言った言わない」の不毛な議論になってしまいます。私の関わったPJでは、完成物を納品したあと、顧客のイメージとあまりにも違っていたため、ほぼ始めから開発のやり直して２年後に再度納品というPJもありました。  
:::

:::note warn
開発期間を明確にして、納期を決めることができる
必要なエンジニア数の計算をプロジェクトの初期段階で明確にすることができる

いくらリードエンジニアが見積もりをしたからといって初期段階で開発工数を正確に見積もることはできません。どんなPJでも「そのPJ独特の難しいポイント」があります。それは初めから炙り出すことは難しく、やってみたら難しかったということは山ほどあります。また、エンジニアの能力は均一ではなく差があります。そのような中で開発期間や必要なエンジニアの人数を初期段階で正確に見積もることは不可能です
:::

:::note warn
PM/PMOにとって、各エンジニアの進捗を管理することが容易

SIerにおいてはPMは開発経験は皆無かほとんどない方が担当する場合が多く、進捗管理自体は表面上できても、進捗が遅れた場合の原因など技術的なことを理解できるPMが圧倒的に少なくエンジニアとPMの間に壁が生まれることは多々あります。
「PMが上、エンジニアは下」という構造のもとPMの決めた納期に従って設計・実装を行い、進捗が遅れた場合はエンジニアの能力不足となることが大半です。PMのエンジニア評価軸は「進捗がいいかどうか」になるためせっかくチーム制をとっていたとしてもチームワークは評価はされず、チーム内で教え合う・助け合うような文化が育ちにくいです。ひどい場合には、エンジニアチームとPMが常に対立しているような現場もあります。
:::

:::note warn
設計期間を十分に取ることでトラブルを防ぐことができる

ウォーターフォール開発の場合、設計と実装が完全に分かれているため、設計担当のエンジニアと実装担当のエンジニアは異なることが多々発生します。設計書はエクセルで残されますが、どんなに丁寧にレビューをされた設計書でも漏れはありますし、設計者自身実装を行なっていないため 実装時の考慮がされていない設計書は当たり前に量産されます。また、どんなに良い設計書だったとしても設計書が人の手による文章である以上 文章の解釈の仕方には人によって差分がでるため 実装者が100%設計者の意図を理解できるとは限りません。どんなに設計に時間をとっても実装・テストの段階で設計時の漏れや設計間違いが発覚して徹夜と休日出勤を連日繰り返しながら納品まで間に合わせるといったエピソードを聞かなかったエンジニアはいないでしょう。
:::

このように、教科書的にメリットとされるようなことも実際の開発の現場を経験をすると、それがいかに「欺瞞や綺麗事」に満ち溢れているか実感しているエンジニアは私だけではないと思います。

ウォーターフォール開発のおける問題点はそのほかにも挙げたらキリがありません。
その問題点を解消するためにアメリカや日本のWeb系企業で積極的に採用されているのがアジャイル開発になります。（シリコンバレーやニューヨークではアジャイル開発がスタンダード）次はアジャイル開発ついて説明をしていきます。


# アジャイル開発

初めて「アジャイル開発」と聞いた時には非常にイメージしにくいと思います。
馴染みが薄く、専門用語が多いため誤解されることが多い開発手法だとも思っております。

実はアジャイル開発という開発手法は近年になって積極採用されている開発手法になります（具体的にはここ10年くらいでしょうか？）
開発手法のコンセプト自体も「自主性」が重んじられていることから、企業での実践方法にはさまざまなバリエーションがあります。そのため完全に「これ」といった形がまだ存在しない開発手法になっています。

しかし、根底にある考え方や核の部分、基本的な用語についてはどの会社も変わらないためここでは基本概念と基本用語について解説をします。



## 開発の流れ

![スクリーンショット 2025-06-04 22.50.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722496/769a7d36-b363-4a68-a849-71b4ab6d1b4b.png)

スクラムと言われるチームを作成します。人数は大体4-5人程度です。
そして、会社やプロジェクトで決めた「スプリント」と言われる期間で
設計・製造・テスト・リリース（ステージング環境など）を実施します。
スクラム内で短期間の間に設計からテストまで全てを実施します。

アジャイル開発は新しい開発手法のため、人によって考え方や実践方法は本当にさまざまです。しかし、コアの考え方は以下にあると私は考えています。

:::note info
＜コアコンセプト＞
- チーム開発、チーム関係者をお互いリスペクト
- エンジニアファーストな風土
- 初めから完璧なものを目指さない（問題を見つけて都度updateしていく考え方）
:::

:::note info
アジャイル開発は関係者同士、非常に密なコミュニケーションを必要とします。
そして、エンジニアがお互いに自立して、開発する製品や機能に向き合う必要があります。
:::

以下では、上記の図と記述に掲載されている用語をまとめました。

### スクラムとは
3-5人の小さなチームを作り、そのチームが「機能や画面」の開発責任を基本的にすべて負う形になります。
つまりチーム内で設計・製造・テストを行い、担当機能や画面を完成させて納品します。
開発組織を小さなチームに分けることでまとまりがなくなるのではないか？という不安があると思いますが、「スクラムマスター」というポジションが各チームを管理・サポートします。

### スクラムマスター
エンジニアで成り立つ各スクラムの進捗や方向性を管理し、サポートをする役割。また、スクラムに所属するエンジニアが仕事に集中できるような立ち振る舞いも求められます。
日本ではこの立ち回りのポジションをPMOと呼ぶ会社も多いです

### スプリント
1回の開発にかける期間になります。期間は会社によって様々です。1週間のところもあれば、2週間のところもあります。スクラム開発の場合、短期間で一つの機能を完成する工程を何度も繰り返しながら、最終的な納品物を作っていくため、スプリントという単位を設けて、その期間ごとに開発のスケジュール、定例会議などを設定していきます。

### フィードバック
1スプリントが終わったあとにスクラムマスターやPMグループなどに対して成果物をフィードバックする会があります。

### レトロスペクティブ （ミニ反省会・振り返り会）
今回のスプリントを通して、良かった点と改善点をカジュアルに話しながらまとめ、次のスプリントにいかしていきます。日本企業の最終反省会後に作成するような仰々しい報告書やまとめWikiのようなものは作成せずに、スクラムマスターやチームリーダーがメモ程度の記述をNotionやJIRA, Confluなどの社内のドキュメントツールにまとめておきます。


:::note info
メリット
- 短いスパンでの開発により、開発を通して発見があった問題点を次に生かせる
- フィードバックを受けながら完成物をブラッシュアップしていける（思っていたのと違うという悲劇を防ぐ）
- スクラムマスターは「エンジニアのサポート役」というポジションという考え方（エンジニアとスクラムマスターの立ち位置は平等）
- チームとしての納品になり、360度評価の会社が多く、助け合い・自発的・ボトムアップの文化が生まれやすい
- 忙しい時期がこまめに分散する（後述もしますが、どうしても忙しくなりがちな実装・テストが短期間で終わるため、何ヶ月も実装とテストで会社に泊まり込むようなことはない）
:::

上記を見る限り、デメリットのない夢のような開発手法に見えます。
しかし、デメリットはもちろん存在します。

:::note warn
デメリット
- 開発初期段階で明確な納期を決めることが実質的に不可能
- 開発初期段階で明確なコストや予算を決めることが実質的に不可能
- 予算を決めることが難しいというのは非常に問題で、この問題をクリアするために以下のような方針をとっている会社もあります。（必要最低限の機能についてはコストを提示して納品を終わらせ、その後の追加開発については別途見積もりを作成。別な例では、完全に開発コストを定額にして顧客が満足するまでスプリントを繰り返して開発を実施するなど）
- チーム開発が前提であり、チーム内での綿密なコミュニケーションが必要不可欠（出社must、それが不可な場合は定例会議以外の頻繁なZoomなど）
- エンジニアに求められる技術力・立ち振る舞いが多岐にわたり、自主的に動くことができる意欲的なエンジニアの採用が求められる
- 受託開発の場合、顧客との打ち合わせ回数は多くなりがち
- スプリント単位で顧客に成果物を見せて都度議論をすることになるため顧客側にも一定程度のシステム開発のノウハウや経験値が必要になる）
:::




# 現代においては、どちらの開発手法が優れているか？

私は、顧客にとっても、エンジニアにとっても「アジャイル開発」の方が圧倒的に優れていると思っています。

理由は以下になります。

:::note info
開発者側
- 忙しさが定期的に分散される（ウォーターフォール開発の場合、実装・テスト工程は一気に集中しているため、その期間　会社の近くのビジネスホテルに泊まる or タクシー帰宅などがどうしても発生）
- スクラムの中のエンジニアが常に設計・製造・テストを経験でき短期間で技術的に成長できる
:::

:::note info
顧客側
- 開発の初期段階のような早い段階から開発側と完成物を共有することができるのでシステムのイメージがつきやすい（納品後、思っていたものと違ったということが起こりにくい）
- うまくアジャイル開発が回れば予算の大幅なオーバーやリリース期限の大幅延期といったことが起こりにくい（ゼロからやり直しといったことが起こりにくいため）
- 予算に従って可能な機能やデザインを拡張できる
:::

世界最先端のIT企業が集まるシリコンバレーやニューヨークの企業では「アジャイル開発」がスタンダードになっています。人材の流動性が非常に高く、徹底的な合理性を優先するアメリカ企業のエンジニアたちが選んでいるということは、アジャイル開発の方が多くのエンジニアにとってより開発しやすいと受け入れられている証拠だと思っています。（もし、ウォーターフォール開発の方に優位性がある場合は、ウォーターフォール開発にすぐ戻っているはずですね）







# 日本のSIerへの導入の問題点


アジャイル開発がアメリカで非常に多く取り入れられている理由は前述の他に「開発製品の違い」にもあると思っています。
自社サービスの開発が中心のアメリカでは、大規模SIerは数えるほどしかありませんが、
日本のIT企業（と一般社会で認知されている会社）は　私の体感70%以上がSIerや受託会社、そしてSESだと思います。

|  | メインストリーム | 少数 | 
| ---- | ---- | ---- | 
| アメリカ | 自社サービス | 受託開発・エンジニア派遣 | 
| 日本 | 受託開発・エンジニア派遣 | 自社サービス | 


また、日本のSIerの場合、エンジニアは基本的に外注になります。（実装担当のエンジニアを大量にかかえるSIerはありません）
私の経験した範囲ですが、大きなシステムの場合、システム開発の人材アサインの構造は以下のようになっている場合が多いです。

![スクリーンショット 2025-06-07 9.12.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722496/4654b3b5-b226-43a3-a7c8-3e6aaddc1a09.png)


設計エンジニア
実装エンジニア
テストエンジニア

それぞれの開発時期に応じて、SESや受託会社が、分担をして開発を行うことが当たり前です。設計エンジニアは設計書の作成のみで、実装を実施しない場合もあります。テストエンジニアは、設計書を見ながらエクセルで膨大なテスト項目を作成し、実装エンジニアが作成したAPIやUIをひたすら打鍵してテストをしてテスト結果をエクセルにスクリーンショットの画像を貼り付けていきます。

それぞれの部署についてもフロアが違うなどは今でもよくあり、実装エンジニアが実装をスタートした段階で、設計エンジニアの契約が終了して（正社員の場合退職など）、プロジェクトからすでに退出をしており設計書について疑問があっても詳細は誰もわからないので、もう一度過去のSlackやメール,JIRAチケットを読みながら確認などということは実際に経験しました。

:::note alert
このような構造がベースにある日本のSIer企業でアジャイルのような「カジュアル」で「日々壁のない緊密なコミュニティーションが必要」な開発手法が普及し、プロジェクトで使いこなすことができるのでしょうか？
:::

# アジャイル開発の心構え

ここからは私の考えになりますが、
アジャイル開発は、従来の「管理側に権限を集めて軍隊のようにエンジニアを働かせる」ようなトップダウン式の開発手法ではなく、エンジニア自身が自発的にスケジュールやタスクを決めながら設計・開発をして、エンジニア自身がテストをすることにより製品に対して責任と愛着をもつようなボトムアップの開発手法だと考えています。言い換えると、開発の主役が管理業務主体のPMではなく、エンジニア自身になった開発手法だと思っています。

経営者やCTOの皆様におかれましては、「うちはシリコンバレー発のアジャイル開発」を導入しているから「従来よりも早く開発ができる」と思い込んでエンジニア側に無理をしいていませんか？アジャイル開発を導入して生産性やエンジニアの開発意欲・成長速度に変化はありましたか？定期的に開発手法の問題点や反省点を見直す機会を設けていますか？モダンな他社の導入事例などを参考にしながら、場合によっては自らLPへの参加や、他社見学など実施して「KAIZEN」に励んでいますか？形だけの導入をしていないでしょうか？もし変化がないようであれば、エンジニアやPM,スクラムマスター側に導入だけを押し付け、アジャイルのコアコンセプトが社内に浸透していないのではないでしょうか？

# ハードウェア業界でのアジャイル開発導入の流れ

最後にアジャイル開発はソフトウェア開発のみに適用されると勘違いされていますが、ウォーターフォール開発の生みの親であるハードウェア業界においても近年　アジャイル開発を積極採用する企業が国内外で出てきております。

つまり、アジャイル開発は「小さなスタートアップ」だけの特異な開発手法ではなく、大企業のような巨大な組織を抱える企業でもうまく取り入れることができる開発手法であり、導入が成功すればコストはもちろん、従業員のモチベーション向上にも大きく貢献することができる開発手法と言えるでしょう。

**キオクシア様（旧東芝メモリ）**

*-回路設計はソフトウェアのようにデジタルな側面と、ハードウェアとしてのアナログな側面があります。「論理的な設計は正しいのに、実測で期待値が出ない」ことは日常茶飯事であり、開発作業は、作っては直し、作っては直しの繰り返しになります。この細かい修正の繰り返しは、ウォーターフォールよりむしろアジャイル的な世界に思えます。-*

https://www.ricksoft.jp/case-studies/kioxia.html#:~:text=%E3%81%AA%E3%81%9C%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%97%E3%81%9F%E3%81%AE%E3%81%8B&text=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AF%E3%80%81%E3%82%88%E3%82%8A%E8%A8%AD%E8%A8%88%E7%8F%BE%E5%A0%B4,%E3%81%A6%E3%81%84%E3%81%8F%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82&text=%E3%81%94%E5%AD%98%E7%9F%A5%E3%81%AE%E9%80%9A%E3%82%8A%E3%80%81%E5%8D%8A%E5%B0%8E%E4%BD%93%E9%96%8B%E7%99%BA,%E3%82%82%E6%84%9F%E3%81%98%E3%81%A6%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82



**スペースX様**

*-複雑な製品では、起こりうるすべての問題や失敗のポイントを予見することが難しいということです。アジャイルエンジニアリングは、複雑なシステムにおいてすべてのリスクを予見することは極めて困難であり、長い先行計画を立てるよりも、まだ完全ではない部分の繰り返しを通して学ぶことに時間を費やした方が良いことを認めている-*

https://abi-agile.com/tesla_agile/#index_id6:~:text=%E8%A4%87%E9%9B%91%E3%81%AA%E8%A3%BD%E5%93%81%E3%81%A7%E3%81%AF%E3%80%81%E8%B5%B7%E3%81%93%E3%82%8A%E3%81%86%E3%82%8B%E3%81%99%E3%81%B9%E3%81%A6%E3%81%AE%E5%95%8F%E9%A1%8C%E3%82%84%E5%A4%B1%E6%95%97%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%82%92%E4%BA%88%E8%A6%8B%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E9%9B%A3%E3%81%97%E3%81%84%E3%81%A8%E3%81%84%E3%81%86%E3%81%93%E3%81%A8%E3%81%A7%E3%81%99%E3%80%82%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AF%E3%80%81%E8%A4%87%E9%9B%91%E3%81%AA%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E3%81%99%E3%81%B9%E3%81%A6%E3%81%AE%E3%83%AA%E3%82%B9%E3%82%AF%E3%82%92%E4%BA%88%E8%A6%8B%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AF%E6%A5%B5%E3%82%81%E3%81%A6%E5%9B%B0%E9%9B%A3%E3%81%A7%E3%81%82%E3%82%8A%E3%80%81%E9%95%B7%E3%81%84%E5%85%88%E8%A1%8C%E8%A8%88%E7%94%BB%E3%82%92%E7%AB%8B%E3%81%A6%E3%82%8B%E3%82%88%E3%82%8A%E3%82%82%E3%80%81%E3%81%BE%E3%81%A0%E5%AE%8C%E5%85%A8%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E9%83%A8%E5%88%86%E3%81%AE%E7%B9%B0%E3%82%8A%E8%BF%94%E3%81%97%E3%82%92%E9%80%9A%E3%81%97%E3%81%A6%E5%AD%A6%E3%81%B6%E3%81%93%E3%81%A8%E3%81%AB%E6%99%82%E9%96%93%E3%82%92%E8%B2%BB%E3%82%84%E3%81%97%E3%81%9F%E6%96%B9%E3%81%8C%E8%89%AF%E3%81%84%E3%81%93%E3%81%A8%E3%82%92%E8%AA%8D%E3%82%81%E3%81%A6%E3%81%84%E3%82%8B