ウォーターフォールとアジャイルは対立概念ではない（応用情報視点）

開発手法の話になると、
「ウォーターフォールか、アジャイルか」という
二者択一で語られがちです。

しかし応用情報技術者試験では、
この2つを対立する思想としてではなく、
使い分ける考え方として理解しているかが問われます。

この回では、
ウォーターフォールとアジャイルが
なぜ対立概念ではないのかを、
応用情報視点で整理します。

ウォーターフォールの本質

ウォーターフォールは、
全体を先に定義し、順序立てて進める考え方です。

• 要件を固めてから作る
• 変更を前提にしない
• 管理と説明を重視する

応用情報では、
「計画性」と「説明可能性」を
重視する場面で有効な手法として扱われます。

アジャイルの本質

アジャイルは、
変化を前提にしながら進める考え方です。

• 小さく作って試す
• 途中で方向修正する
• 利用者の反応を重視する

こちらは、
不確実性が高い状況で
力を発揮する思想です。

なぜ対立させると失敗するのか

この2つを対立させると、

• 計画が甘くなる
• 変更に耐えられなくなる
• 現場と管理が分断される

といった問題が起きます。

応用情報では、
どちらか一方を絶対視すること自体が
リスクであると示唆しています。

応用情報での典型的な出題意図

午後問題では、

• 要件が固まっていないのに
  厳密な計画を立てている
• 変更管理がないまま
  作り続けている

といった不整合が、
問題点として描かれます。

ここで、
手法の選択ミスに気づけるかが
問われます。

実務での使い分け

実務では、

• 全体計画：ウォーターフォール的
• 実装・改善：アジャイル的

といった組み合わせが
よく使われます。

応用情報は、
この現実的な折衷を
理解しているかを見ています。

まとめ

• ウォーターフォールは計画重視
• アジャイルは変化対応重視
• 応用情報は使い分け思考を問う

開発手法を見るときは、
「何が不確実なのか」
を基準に選ぶことが重要です。

次回予告

次回は、
「テストは『バグを見つける作業』ではない」
を扱います。

開発・運用編をさらに深掘りします。