ウォーターフォールは間違っている！私がアジャイル開発をエンジニアに勧める理由

ウォーターフォールは間違っている！私がアジャイル開発をエンジニアに勧める理由

オフ 投稿者: sesera

みなさん、こんにちは！今回は「ウォーターフォール開発」とよく誤解されている「アジャイル開発」について、本質的な部分からお話ししたいと思います。

目次

ウォーターフォールは間違っている！

1970年にウィンストン・ロイス博士が発表した論文「Managing the Development of Large Software Systems」からウォーターフォールという概念の知名度が上がりました。

そこでは、確かにウォーターフォール型の図が掲載されていました。しかし、これは「こうすると失敗する」という警告として示された図だったんです。

ですが、図が登場したのが論文の序盤であり、そのウォーターフォールを否定するのが論文の後半だった事や、ウォーターフォールの図が「人々が無意識的にしていた開発の流れを可視化した分かりやすい図」だった事もあり、後半で説明されている重要な警告や改善案を見落とされたまま広がってしまいました。

ちなみに、ロイス博士は実際には以下のように警告していました：

  • このモデルは危険で欠陥がある
  • イテレーティブな開発が必要
  • フィードバックループが不可欠

つまり、今日私たちが知っているウォーターフォールモデルは、「こうしてはいけない」という例として示されたものが、誤って広まってしまった結果なんです。

論文で元々主張される予定だった物

ロイス博士は「アジャイル開発をしよう！」と言っていた訳ではありません。アジャイル開発に近い物ではあるのですが、「改良版ウォーターフォールをしよう！」と主張したかったのです。

ロイス博士が提案した改良版モデルの特徴：

  • 反復的な開発サイクル
  • 継続的なフィードバック
  • 早期のプロトタイピング
  • 頻繁な顧客との対話

これらは、まさに本来のアジャイル開発の特徴そのものですよね。

アジャイルの方がエンジニアとしての成長が早い

正しく実践されるアジャイル開発では、以下のような良いプラクティスが自然と根付きます：

  • 小さな単位での成果確認
  • 継続的な改善の機会
  • 頻繁なフィードバック
  • チーム内でのナレッジ共有

これらのプラクティスは、単なる「儀式」ではなく、品質と生産性を高めるための具体的な施策として機能します。

そして、エンジニア目線でも上記のようなプロアクティスの影響により、技術力の向上がウォーターフォールと比べて段違いです。

なぜアジャイルの方が技術の成長が早いのか

それは時間の使い方が違うからです。

ウォーターフォールとアジャイルでは、時間の使い方は大きく変わってきます。以下は一例として参考にしてください（プロジェクトの性質や組織によって異なります）：

ウォーターフォール型の開発では：

  • 包括的なドキュメント作成：35%
  • 会議・レビュー：30%
  • 実際の開発作業：25%
  • 技術研究・検証：10%

正しいアジャイル型の開発では：

  • 実際の開発作業：45%
  • 技術研究・検証：25%
  • 適切なドキュメント作成：15%
  • チーム内コミュニケーション：15%

※比率は私が経験した一例です。

「手を動かさないと覚えない」と皆が言っていますが、実際にアジャイル開発の方がコードやテストコードに触れている時間、技術に関して話し合っている時間、改善の時間が多く取れるので成長速度が早いです。

また、アジャイル開発では、ドキュメントに割く時間の割合が少ないのですが、ドキュメントを単に「書かない」のではなく、以下のような形で効率的に残します：

  • チャットツールでの会話ログ
  • プルリクエストのレビューコメント
  • 自動生成されたAPI仕様書
  • テストコードによる仕様の表現
  • ペアプロ・モブプロでの知識共有

画期的かつ効率的ですよね。

それと個人的な意見ですが、この時間配分にできる要因としてはTDD（テスト駆動開発）という概念が一番貢献してくれていると感じます。

長くなるのでざっくり解説すると、TDDという物をする事によって「自動でテストが行われる」「テストが仕様書を兼ねる」「コードがシンプルになり変更しやすくなる」これらが実現できます。

最近のキャリア面でもアジャイル経験が有利

現代のソフトウェア開発では、以下のようなスキルが重要視される事が多くなっている傾向にあります。

  • 変化への適応力
  • 継続的な学習能力
  • 効果的なコミュニケーション
  • 価値提供への意識

実際に自分もフリーランス案件を探す際に上記のようなスキルがあるか見極められるような質問が多くあるように感じました。

正しいアジャイル開発の環境では、これらのスキルを日常的に実践し、磨く機会が多くなるので自ずとキャリア面でも有利になります。

ただ、本質を理解していないアジャイルはダメ

今日、「アジャイル開発」という言葉を聞くと、多くの人が以下のようなイメージを持っています：

  • スクラムの儀式さえやればいい
  • ドキュメントを書かなくていい
  • 計画を立てなくていい
  • 見積もりはざっくりでいい

でも、これは大きな誤解です。本来のアジャイル開発とは：

  • 価値の早期提供を目指す
  • 継続的な改善を行う
  • 顧客との密な対話を重視する
  • 適切な計画と文書化を行う

というものです。つまり、アジャイルは「規律」のない開発ではなく、むしろ高い規律を持った開発アプローチなんです。

納期が決まっている物はウォーターフォールの方が良い？

「納期が決まっている開発ではウォーターフォール型の方が管理しやすい」という意見をよく聞きますが、実際はそう単純ではありません。

従来型の開発では：

  • 詳細な計画を立てる
  • 綿密な工数見積もりを行う
  • 詳細なスケジュールを設定

しかし実際には：

  • 後工程での問題発見
  • 計画の見直しが必要に
  • 手戻りによる遅延

一方、アジャイル型では：

  • 優先順位に基づく開発
  • 早期からの価値提供
  • 柔軟な調整が可能

重要なのは、どちらが「納期を守れるか」ではなく、「どのように価値を提供できるか」という視点です。アジャイル型では、たとえ完全な機能セットが間に合わなくても、核となる価値を確実に提供することができます。

まとめ

私は過去に厳格なウォーターフォールと、厳格なアジャイルの現場を経験しました。

その経験や、周りのエンジニア仲間を見ていても、圧倒的にアジャイル開発の方が、新しく効率的な技術やコミュニケーション能力が育っています。また、最近の変化が早くなった市場にも、新しい機能をプロダクトに追加する速さがアジャイル開発の方が勝っています。

間違ったウォーターフォールや間違ったアジャイルという定義は難しいですが、それぞれの本質に沿わない現場は、エンジニア目線でも経営者目線でも避けるべきです。

それを皆が徹底する事でより良いIT業界になると思います。

補足

自分の経験から言うと、エンジニアだけがアジャイル開発を意識すると、お客さんと連絡を取る立場の人やマネジメントサイドの人がかなり疲労し、社内でのエンジニア部門への風当たりが強くなる思います。

そもそも組織がアジャイル開発の思想を理解しないと上手くいきませんし、言い方が悪いかもしれませんが、アジャイルの思想を一定お客さんにも理解してもらう必要があると感じました。

参考になれば幸いです。

カテゴリープログラミング