ウォーターフォールとアジャイルを比較するとき、しばしば次のような単純な構図で語られます。
- ウォーターフォールは古く、変化に弱い
- アジャイルは新しく、変化に強い
- したがって、アジャイルのほうが優れている
しかし実際の開発現場を見ていると、開発手法そのものよりも、ビジネス側と開発側がどのような関係を築いているかのほうが、プロジェクトの成否に大きく影響しているように感じます。
関係者の間に信頼があり、役割と責任が整理されていれば、ウォーターフォールでも柔軟に開発できます。反対に、関係性が悪ければ、アジャイルを採用しても無秩序な要求変更に振り回されるだけです。
この記事でいう「正しい扱い方」とは、特定の方法論を教科書どおりに運用することではありません。
開発プロセスを、相手を拘束したり責任を押しつけたりする武器ではなく、関係者が協働するための共通ルールとして使うことを意味しています。
この記事で言いたいこと
先に要点をまとめます。
- ウォーターフォールでも、変更を取り込むことはできる
- アジャイルでも、いつでも無制限に変更してよいわけではない
- どちらの手法も、ビジネス側と開発側の関係が悪いと「武器」になる
- 標準プロセスは開発者だけでなく、仕事を依頼する側も守る必要がある
- 開発手法の優劣より、意思決定と責任分担の設計が重要である
開発プロセスは、単なる作業手順ではない
開発プロセスは、要件定義、設計、実装、テストといった作業の順番を決めるものです。
しかし、実際にはそれだけではありません。
開発プロセスは、次のようなことも決めています。
- 誰が要求を出すのか
- 誰が優先順位を決めるのか
- いつまでに何を決めるのか
- 途中で変更したい場合に、誰が判断するのか
- 変更による追加コストを誰が負担するのか
- 何をもって「完成」とするのか
- 問題が起きたときに、誰がどこまで責任を持つのか
つまり開発手法は、技術的な作業方法であると同時に、ビジネス側と開発側の権限、責任、負担を調整する仕組みでもあります。
だからこそ、関係者の信頼が失われると、プロセスは協働のための仕組みから、自分を守ったり相手を制限したりする仕組みに変わってしまいます。
ウォーターフォールは「変更できない手法」ではない
ウォーターフォールというと、最初にすべての要件を決め、その後は一切変更できない方法だと思われがちです。
しかし、実際にはウォーターフォールでも、工程ごとのレビューや変更管理を通じて要件を変更できます。
たとえば、要件定義や設計のレビューにおいて、次のような話し合いができます。
- この要求は本当に今回必要なのか
- 将来的には必要だが、今回は見送るべきではないか
- この機能を追加するなら、どの機能の優先順位を下げるのか
- 技術的な制約を考えると、別の方法が適切ではないか
- 要件を変更する場合、納期や予算をどう調整するのか
したがって、ウォーターフォールの特徴は「変更できないこと」ではありません。
より正確に言うなら、ウォーターフォールは、変更の影響と責任を明示的に扱おうとする方法です。
変更によって設計、実装、テスト、納期、予算にどのような影響が出るのかを確認し、関係者が合意したうえで取り込む。この仕組み自体には合理性があります。
ウォーターフォールのドキュメントが持つ意味
ウォーターフォールでは、各工程でドキュメントを作成することが一般的です。
たとえば、要件定義書、基本設計書、詳細設計書、テスト計画書などです。
管理する側から見ると、これには大きなメリットがあります。
- 何が決まっているのかを確認できる
- 工程の進捗を把握しやすい
- 部門や会社をまたいだ引き継ぎがしやすい
- 過去の判断理由を追跡できる
- 品質や安全性を確認する材料になる
- 開発者個人への依存を減らせる
特に、大人数が関わる開発や、複数の会社が参加するプロジェクトでは、口頭のコミュニケーションだけですべてを共有するのは困難です。
その意味で、ドキュメントは単なる管理資料ではなく、関係者の認識を合わせるための重要な道具です。
一方で、ドキュメントにはコストもあります。
仕様が変更されるたびに、複数のドキュメントの整合性を保たなければなりません。実装よりも文書の更新に時間を取られることもあります。
また、ドキュメントの完成率が80％だからといって、利用者にとって価値のあるシステムが80％完成しているとは限りません。
ここで注意しなければならないのは、次の二つを混同しないことです。
- 成果物が増えていること
- 利用者にとっての価値が生まれていること
ドキュメントは必要ですが、ドキュメントを作ること自体が目的になると、プロジェクトは進んでいるように見えて、実際には重要な問題が何も解決されていないという状態になり得ます。
ウォーターフォールが防御手段になるとき
ビジネス側や経営側から、次のような要求が繰り返される現場があります。
- 思いつきで要求が追加される
- 要求同士が矛盾している
- 優先順位を決めてもらえない
- 予算と納期は変えずに機能だけ増やされる
- 前提が変わったのに、最初の見積もりだけは守るよう求められる
- 問題が起きたときの責任だけが開発側に押しつけられる
このような状況では、開発側は自分たちを守るために、プロセスを厳格に運用するようになります。
たとえば、次のような対応です。
- 要件確定後の追加要求は次期開発に回す
- 変更要求書の提出を必須にする
- 変更ごとに影響分析と再見積もりを行う
- 承認が得られるまで作業を開始しない
- 文書に記載されていない要求には対応しない
外から見ると、これは官僚的で融通の利かない態度に見えるかもしれません。
しかし現場にとっては、無制限な要求追加から身を守るための合理的な防御である場合もあります。
問題は、変更管理を行うこと自体ではありません。
本来、変更管理はプロジェクト全体を守るための仕組みです。それが、必要な対話や変更まで拒絶するための仕組みに変わったとき、プロセスは機能不全を起こします。
本来は変更を安全に扱うための仕組みだったものが、関係性が悪化すると、変更を拒絶するための壁になる。
これが、ウォーターフォールが悪く見える理由の一つではないかと思います。
ウォーターフォールは管理側にも悪用できる
ウォーターフォールを防御手段として使うのは、開発側だけではありません。
管理側や発注側も、計画やドキュメントを利用して開発側を拘束できます。
たとえば、次のようなケースです。
- 不確実な段階で、納期と予算を確定させる
- 要件が曖昧なまま、開発側に見積もりを約束させる
- 要件定義書への承認を、責任転嫁の材料として使う
- 途中で前提が変わっても、最初の計画だけを守らせる
- 実態よりも、工程表どおりに進んでいることを重視する
- 問題を報告した開発者だけを「計画との差異」の責任者として扱う
このような運用では、計画書や承認記録が、合意形成のための道具ではなく、責任を押しつけるための証拠になってしまいます。
ウォーターフォールでは、仕様書、計画書、見積書、承認記録などが権力を持ちやすいといえます。
誰がそれらを作り、誰が承認し、誰が変更を認めるのか。
その設計が不公平であれば、プロセスも不公平になります。
健全なウォーターフォールでは、レビューが交渉の場になる
関係性が良いプロジェクトでは、工程ごとのレビューは単なる承認儀式ではありません。
レビューは、ビジネス側と開発側が現実的な落としどころを探すための交渉の場になります。
たとえば、ビジネス側から新しい要望が出たとき、開発側が単に「変更できません」と答えるのではなく、次のような会話ができます。
この機能は将来的に必要になると思います。ただし、今回入れる場合はテスト期間が短くなります。今回は見送り、次のリリースで対応するのはどうでしょうか。
あるいは、次のような提案もできます。
本来の要求を満たすには大規模な変更が必要ですが、目的を限定すれば小さな修正で対応できます。まずは限定版で利用状況を確認しませんか。
このような会話が成立するなら、ウォーターフォールでも一定の柔軟性を保てます。
その場合、ドキュメントは「最初に決めたことを絶対視するためのもの」ではありません。
その時点での判断と合意を共有し、次の議論の土台にするものになります。
アジャイルは「いつでも何でも変更できる手法」ではない
アジャイル開発では、実際に動くものを小さく作り、フィードバックを得ながら改善していきます。
不確実性が高く、最初から正解を決めることが難しい開発では、とても有効な考え方です。
しかし、アジャイルは「要件を決めなくてよい」という意味ではありません。
また、「思いついた要求をいつでも追加してよい」という意味でもありません。
アジャイルにおいても、少なくとも次のことは必要です。
- プロダクトが目指す方向を決める
- 要求の優先順位を決める
- 誰が最終判断をするかを決める
- 何をもって完成とするかを共有する
- フィードバックを適切なタイミングで返す
- 変更によって何を後回しにするかを決める
- 品質や技術的負債をどのように扱うかを合意する
短い周期で変更できることと、無秩序に変更してよいことは別です。
アジャイルはプロセスが不要なのではなく、短い周期で意思決定と検証のプロセスを繰り返す方法だと考えたほうがよいでしょう。
アジャイルが発注側に悪用されるとき
アジャイルでは、要件を最初から完全に確定させることを目指しません。
これは変化に対応するための重要な特徴です。
しかし、この特徴は悪用もできます。
発注側やビジネス側が要求を意図的に曖昧にしておけば、後になって次のように言うことができます。
こちらが意図していたものと違う。
当然、この機能も含まれていると思っていた。
アジャイルなのだから、これくらい変更できるはずだ。
実際に見てみたら違ったので、次の開発ですぐ直してほしい。
要求を具体的にしなければ、後からいくらでも解釈を変えられます。
すると、要求する側には「できるだけ曖昧なままにしておく」というインセンティブが生まれます。
さらに、すべての要求を「優先度が高い」と扱い、何を諦めるかを決めなければ、開発側の作業量だけが増えていきます。
これは柔軟性ではありません。
単に、変更のコストと責任を開発側に押しつけているだけです。
アジャイルにおける変更可能性は、無料で無限に使えるものではありません。
新しい要求を入れるなら、既存の要求を後回しにする、納期を調整する、体制を変えるなど、何らかのトレードオフが必要です。
アジャイルは開発側にも悪用できる
一方で、開発側も「アジャイル」という言葉を言い訳として使うことがあります。
たとえば、次のようなケースです。
- アジャイルだから計画は作らない
- アジャイルだからドキュメントは書かない
- アジャイルだから見積もりはできない
- アジャイルだから将来の見通しは説明できない
- アジャイルだから仕様は決めなくてよい
- アジャイルだから、とりあえず作ってから考える
もちろん、不確実な仕事に対して精密すぎる長期計画を作っても意味はありません。
また、使われないドキュメントを大量に作る必要もありません。
しかし、だからといって、ビジネス側への説明責任までなくなるわけではありません。
開発側には、現在の状況、技術的な制約、品質上の懸念、今後の見通しを、可能な範囲で明らかにする責任があります。
「先のことは確実には分からない」と説明することと、「何も説明しない」ことは別です。
ウォーターフォールとアジャイルは、異なるものを武器にできる
両者を比較すると、次のように整理できます。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 健全な使い方 | 合意と責任を文書化し、変更の影響を管理する | 小さく作って検証し、学習しながら優先順位を変える |
| ビジネス側による悪用 | 無理な計画を固定し、承認や契約を責任転嫁に使う | 要求を曖昧にしたまま、変更を無制限に押し込む |
| 開発側による悪用 | 文書や変更手続きを盾に、必要な対話まで拒否する | 「アジャイルだから」と計画や説明を放棄する |
| 必要な仕組み | レビュー、影響分析、変更管理、合意形成 | 目標、優先順位、受け入れ条件、レビュー、振り返り |
少し刺激的な言い方をすると、次のようになります。
ウォーターフォールでは、合意済みの仕様が武器になる。
アジャイルでは、仕様を確定させないことが武器になる。
しかし、本来はどちらも武器ではありません。
合意済みの仕様は、関係者の認識を合わせるためにあります。仕様を確定させすぎないことは、不確実性に対応するためにあります。
どちらも、相手に責任を押しつけるために使い始めた瞬間に、本来の目的を失います。
標準プロセスは誰のためにあるのか
開発プロセスや標準プロセスというと、開発者を管理するためのルールだと思われがちです。
しかし、本来は仕事を依頼する側にも一定の行動を求めるものです。
たとえば、次のようなルールです。
- 要求はどのような形式で提示するのか
- 誰が優先順位を決めるのか
- 誰が受け入れ判断をするのか
- 要求を変更する場合、いつ反映するのか
- 緊急対応と通常対応をどう区別するのか
- 納期、範囲、品質のどれを優先するのか
- 技術的負債をどのように扱うのか
- 意思決定の記録をどこに残すのか
これらは、開発者だけが守る規則ではありません。
標準プロセスは、「開発者はこのように働く」というルールであると同時に、「依頼する側もこのように振る舞う」という約束である。
仕事を依頼する側がルールを守らず、開発側だけにプロセスの遵守を求めるなら、それは共通ルールではなく、一方的な管理です。
逆に、開発側が自分たちの都合だけでプロセスを作り、ビジネス上の必要性を無視する場合も、健全とはいえません。
開発プロセスは、開発者を縛る鎖というより、ビジネス側と開発側の間に置かれるAPIのようなものだと考えられます。
入力として何が必要なのか。誰が判断するのか。エラーが起きた場合にどう処理するのか。変更をどのように伝えるのか。
インターフェースが定義されていなければ、双方が相手の内部事情を推測しながら仕事をすることになり、やがて認識のずれや責任の押しつけ合いが発生します。
どちらの手法を選ぶべきか
ウォーターフォールとアジャイルのどちらを選ぶかは、流行や好みだけで決めるべきではありません。
少なくとも、次のような点を考える必要があります。
- 最初の段階で要求をどこまで明確にできるか
- 利用者からどの程度の頻度でフィードバックを得られるか
- 途中変更にどれくらいのコストがかかるか
- 契約上、範囲や納品物を事前に決める必要があるか
- 法令、監査、安全性などの制約があるか
- 複数の会社や部署をまたいだ調整が必要か
- ビジネス側が継続的に意思決定へ参加できるか
- 開発側が状況を継続的に可視化できるか
すべてをウォーターフォールかアジャイルのどちらか一方に統一する必要もありません。
全体の予算、契約、主要なマイルストーンは事前に整理しつつ、具体的な機能は短い周期で開発し、フィードバックを取り込むという進め方もあります。
重要なのは、方法論の名前ではありません。
そのプロジェクトに存在する不確実性やリスクを、どのような仕組みで扱うのかです。
まとめ
ウォーターフォールとアジャイルのどちらが優れているかという議論は、分かりやすい一方で、現場の問題を単純化しすぎているように思います。
ウォーターフォールでも、ビジネス側と開発側が対話し、変更の影響を一緒に検討できるなら、十分に柔軟な開発ができます。
アジャイルでも、ビジネス側が要求を曖昧にしたまま無制限な変更を求めたり、開発側が説明責任を放棄したりすれば、うまくいきません。
どちらの手法も、関係者が責任を共有するために使えば有効です。
そしてどちらの手法も、関係性が悪ければ、相手を拘束し、自分を守り、責任を押しつけるための武器になります。
開発プロセスに必要なのは、開発者だけを管理するルールではありません。
仕事を依頼する側と作る側の双方が、
- 何を決めるのか
- 誰が決めるのか
- 変更のコストをどう扱うのか
- 何を諦めるのか
- 何をもって完成とするのか
を共有するためのルールです。
ウォーターフォールとアジャイルの正しい扱い方とは、手法を厳密に守ることではありません。
プロセスを相手に対する武器にせず、対話と交渉を成立させるための共通基盤として運用することなのだと思います。
おわりに
この記事では、あえて「武器」という強い言葉を使いました。
「障壁」や「防御手段」といった表現も考えましたが、開発プロセスは本来、相手を傷つけたり拘束したりするためのものではなく、関係者全員がより良い開発を進めるためのものです。それにもかかわらず、信頼関係が崩れると、本来は相手に向けるべきではない「武器」として使われてしまうことがあります。
その危うさへの注意喚起を込めて、本記事ではあえて「武器」という言葉を選びました。