1.4 ソフトウェア開発手法の比較(agile, lean, waterfall)

ソフトウェア開発手法とは、「何を・どの順番で・どう進めて作るか」という仕事の進め方の型である。代表的なものに waterfall（ウォーターフォール）、agile（アジャイル）、lean（リーン）がある。本ページでは、3つがそれぞれ何の困りごとを解こうとして生まれたのか、そしてなぜ「唯一の正解」が決まらないのかを見ていく。

3手法は別々の課題から生まれた

3手法が併存するのは、それぞれが別の時代の別の課題に答えて生まれたからである。おおまかには、waterfall が「順序立てて作る」を、agile が「途中で変えられる」を、lean が「ムダを出さない」を重視する。まず全体像を表で押さえる。

waterfall の限界が agile を生んだ

agile は、waterfall の「途中で変えられない」という限界への答えとして生まれた。この流れを理解すると、両者の関係がすっきりする。

waterfall は、要件定義 → 設計 → 実装 → テスト → リリースという工程を、滝が上から下へ流れるように1回ずつ順に進める。各工程を完了させてから次へ移る。工程がはっきり分かれるので、計画が立てやすく進捗も管理しやすい。橋やビルの建設のように「後戻りが本質的に難しく、最初の設計が固められる」対象には今でも合理的だ。

flowchart LR
    A["要件定義"] --> B["設計"] --> C["実装"] --> D["テスト"] --> E["リリース"]

問題は、ソフトウェアの要件が「作っている途中で変わる」ことが多い点だ。完成してテスト段階で初めて「これは欲しかったものと違う」と判明しても、waterfall では前の工程に戻るコストが非常に大きい。最初の計画がそのまま正しいという前提が、現実とずれていた。

そこで agile は発想を変えた。全部をまとめて1回で作るのをやめ、短い期間（数週間程度。反復・イテレーションと呼ぶ）で「動く小さな成果物」を作り、それを見て次の方針を決める。これを何度も繰り返す。

flowchart LR
    P["小さく計画"] --> M["作る"] --> V["動かして確認"] --> F["フィードバック"]
    F --> P

短い反復ごとに方向を修正できるので、「変更」を失敗ではなく当たり前の前提として扱える。要件が動く・先が読めない開発で agile が強いのは、この「こまめに軌道修正できる」性質による。

lean は agile と何が違うのか

lean と agile は似て見えるが、出発点が違う。agile が「変化に対応する」ことを軸にするのに対し、lean は「ムダを徹底的になくす」ことを軸にする。

lean はもともと製造業（トヨタ生産方式）の考え方から来ている。中心にあるのは「価値を生まない作業＝ムダ」を見つけて削る、という視点だ。ソフトウェア開発でいうムダとは、たとえば「誰も使わない機能を作り込むこと」「手戻り」「待ち時間」「過剰な在庫（作りかけの未完成品の山）」などである。これらを減らし、価値が利用者に届くまでの流れをできるだけ速く・滑らかにすることを目指す。

両者は対立せず、しばしば一緒に使われる。agile が「短く反復して変化に追従する枠組み」を与え、lean が「その中で何がムダかを問い続ける視点」を与える、と捉えると整理しやすい。agile が進め方の形なら、lean は良し悪しを測るものさしに近い。

なぜ「正解の手法」が1つに決まらないのか

最適な手法が状況によって変わるからである。要件が固く後戻りが難しい対象なら waterfall の計画性が活き、要件が動く対象なら agile の反復が活き、効率を継続的に改善したいなら lean の視点が活く。どれかが常に優れているわけではない。

判断の手がかりは「要件がどれだけ変わりそうか」「間違いの修正にどれだけコストがかかるか」だ。変化が少なく一発勝負なら前もって固める価値が高く、変化が多く小さく試せるなら反復して学ぶ価値が高い。現場では純粋にどれか1つではなく、agile を軸に lean の視点を混ぜるなど、組み合わせて使うことも多い。

本ページはCisco DevNet Associate(200-901) Exam Topics v1.1を学習範囲の根拠として参照。文章・図表はすべて新規作成。