アジャイル vs ウォーターフォール論争に終止符を打つ

2020.03.08

成功を左右するのは、方法論ではなく「判断」である

「アジャイルとウォーターフォール、どちらが良いですか？」

ITプロジェクトでは、今でもよく聞かれる質問です。技術者の採用面談でも、「御社はアジャイルはやってますか」「Rubyの案件はありますか」といった声を耳にします。エンジニアにとってアジャイルというやり方で仕事ができるのは魅力的なのでしょう。経営者も「開発時間の短縮」「変化に柔軟に対応」と聞くと、現場に「次はアジャイルでやれ」とひとこと言いたくなります。

しかしこの議論は20年以上続いているにもかかわらず、いまだに決着がついていません。それもそのはずです。実は、この問い自体が少しズレているからです。

IT業界は、方法論の話が好きすぎる

IT業界には、少し不思議な文化があります。

アジャイル派は、「ウォーターフォールは時代遅れだ」と言い、ウォーターフォール派は、「アジャイルは管理できない」と言う。SNSやカンファレンスでも、この議論は何度も繰り返されています。

しかし発注企業の経営者からすると、本音はもっとシンプルです。

どちらでもいいから、予定通り稼働してほしい。

プロジェクトの成功率は、方法論の名前では決まりません。プロジェクトを成功させるのは方法論ではありません。成功する会社は、アジャイルでも成功します。ウォーターフォールでも成功します。一方で、失敗する会社は、どちらを採用しても失敗します。

本当に問うべきなのは、「どの方法論を採用するか」ではなく、「何を判断するか」です。

まず、それぞれの定義を整理する

「ウォーターフォールとは」

ソフトウェア工学では非常に古くからあるポピュラーな開発モデル。開発プロジェクトを時系列に、「要求定義」「外部設計」「内部設計」「開発」「テスト」「運用」などの作業工程にトップダウンで分割する。原則として前工程が完了しないと次工程に進まないことで、前工程の成果物の品質を確保し、前工程への後戻りを最小限にする。

参考：Wikipedia

「アジャイルとは」

ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称。反復（イテレーション）と呼ばれる短い期間単位を採用することで、リスクを最小化しようとするもの。アジャイルソフトウェア開発手法とは、一群のソフトウェア開発手法の総体を意味する言葉であり、単一の開発手法を指す言葉ではない。

「アジャイルソフトウェア開発宣言」

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。

参考：Wikipedia

ちなみにアジャイルはウォーターフォールの課題を克服する形で現れたため、「ウォーターフォールは古く、アジャイルは新しい」という文脈で語られることが多いようです。しかしこの理解は少し正確ではありません。

ウォーターフォールとアジャイルは対立する概念ではない

アジャイルという概念を捉えるうえでは、まずウォーターフォールの理解が必要です。ウォーターフォールの考え方は「何が問題なのか」「その問題をどう解決するか」が出発点になります。つまり「システムを作る」こと以前の検討事項に対して存在していると言えます。一方アジャイルは「システムを作る」ことに対して存在します。

さらに両者をソフトウェア工学以前の視点から捉えると、問題発見と解決のアプローチとしてウォーターフォールという概念があり、その後工程であるシステム開発を、シーケンシャルと反復のどちらのアプローチで行うか、という話です。

つまりウォーターフォールとアジャイルは、新旧あるいは対立の概念で捉えるものではありません。最適な解決方法を検討するうえで、私たちの手には複数の選択肢と組み合わせがある、ということです。

方法論は「調理法」でしかない

料理を考えてみてください。焼く、煮る、蒸す——どれも優れた調理法です。しかし、何を作るか決まっていなければ、調理法だけ議論しても料理は完成しません。

ITプロジェクトも同じです。アジャイルもウォーターフォールも、あくまで目的を実現するための手段です。調理法が目的になった瞬間、プロジェクトは方向を見失います。手法ファーストはあらゆる点において博打なのです。

医療に例えれば、胃腸の専門医は患者が「胃が痛い」と言えば胃腸薬を処方します。しかしその胃の痛みが脳挫傷から来ている場合は何の意味もありません。胃腸薬のことしか知らない医者は、どんな症状の患者が来ても胃腸薬で解決しようとするのです。だから医者はしっかり診療して「ここが問題だ」と突き止めてから、それに対する処方をするわけです。

私たちの仕事も同様です。「ここが問題だ」と分かるためには、ITでの様々な解決手法をしっかり知ったうえで、クライアントをしっかり理解しなければなりません。「今はアジャイルがすごい」「やはりウォーターフォールが基本だ」という考えで進めるのは、博打でしかありません。

本当に難しいのは「何を決めるか」

実際のプロジェクトで難しいのは、アジャイルを採用することでも、ウォーターフォールを採用することでもありません。例えば、以下のような判断です。

今回、本当に必要な機能は何か
後回しにできるものは何か
品質とスピードのどちらを優先するか
現場運用は変えるのか
パッケージに合わせるのか、独自開発するのか

プロジェクトは、判断の積み重ねで出来ています。そしてその判断が止まった瞬間に、プロジェクトは失敗に向かいます。

私たちが支援した案件でも、アジャイルで成功した案件があります。ウォーターフォールで成功した案件もあります。逆に、アジャイルを掲げながら迷走した案件も、ウォーターフォールで膨大な仕様書を書いたにもかかわらず途中で何も決められなくなった案件もあります。原因は共通しています。方法論ではなく、意思決定が止まったことです。

またアジャイルを扱ううえで注意すべき点として、「文書より対話だ」「ソースコードこそすべて」という偏重から無文書・無設計という極端なスタイルが生まれることがあります。アジャイルは「作る」という行為に対するリスクを最小化しているように見えて、実のところ「作り始めた」以上は後には引きにくいものです。一方ウォーターフォールであれば「作らない」という判断をして打ち切ることができます。一長一短の特徴を理解したうえでアプローチを組み立てることが重要です。

アジャイルが向くケース、ウォーターフォールが向くケース

もちろん、それぞれ得意分野はあります。

アジャイルが向くケース

新規サービス・UI/UX改善
要件が変化しやすいプロジェクト
小さく試しながら改善したい場合

ウォーターフォールが向くケース

基幹システム・会計・物流
法規制対応が必要なプロジェクト
関係者が多い大規模案件

しかし現実には、完全なアジャイルも、完全なウォーターフォールも、ほとんど存在しません。基幹システムでもPoCは行いますし、アジャイル開発でも予算やスケジュール管理は必要です。特にAIや新規事業の分野では「まずは作ってみて検証しよう」となりがちですが、アジャイルが必ずしも最適解とは限らず、「ありき」で始まった開発は結構な確率でおかしなことになります。多くのプロジェクトは、両者を組み合わせることが現実解です。

だから「構想」が重要になる

方法論を決める前に、まず決めなければならないことがあります。

プロジェクトの目的
成功の定義
優先順位
投資判断
捨てるもの

これらが曖昧なまま「アジャイルで進めましょう」「ウォーターフォールでいきましょう」と決めても、土台が固まっていません。設計図のない建築が危険なのと同じです。

私たちはアジャイルを勧める会社でも、ウォーターフォールを勧める会社でもありません。その会社にとって何が適切なのか、何を優先し何を諦めるのか——その判断を整理し、経営として納得できる形にすることこそが、プロジェクト成功の出発点だと考えています。

方法論を選ぶ前に、「何を判断するか」を整理しませんか？

「アジャイルとウォーターフォール、どちらにすべきか」という議論の前に、整理すべきことがあります。それは、プロジェクトとして何を実現したいのかという構想です。

「方法論は決まったが、何から始めればよいか分からない」「要件定義に入る前に判断軸を整理したい」「アジャイルとウォーターフォールをどう組み合わせるべきか悩んでいる」——こうした状況では、方法論の選択よりも先に、構想を固めることが重要です。

オーシャン・アンド・パートナーズでは、特定の製品やベンダーに依存しない第三者の立場から、経営課題を整理し、「何を実現するためのプロジェクトなのか」という構想策定を支援しています。方法論の議論に入る前に、経営として何を判断し、どのような優先順位で進めるのか。その設計図から、一緒に整理してみませんか。

▶ 関連サービス：システム構想策定支援
▶ 関連コラム：「ITプロジェクトに正解はない」

この記事を書いた人について

谷尾薫: オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。