ITの工程について、ウォーターフォールがどういうものかを説明します。
ウォーターフォールの利点、欠点を述べ、アジャイルについても説明します。
ウォーターフォールとは？
Wikipediaによると、ソフトウェアを作る方法として1970年代にウォーターフォールが登場したようです。
「ウォーターフォール」は英単語として「滝」を意味します。
滝のように工程が流れる様からウォーターフォールモデルと言われています。
工業的なモノづくりを考えると上記はとても自然です。
例えば、車や家電などの工業製品を作ることを考えてみてください。
まず、何を作るかを考えます（要件定義、外部設計）
そして、どうやって作るかを考えます（内部設計）
モノを作ります（コーディング、単体テスト）
作ったものが、考えていた通りかを確かめます（システムテスト）
そして製品が出荷されていきます。
工業製品を作っている人たちからするとこれ以外の作り方があるのか？という話になります。
この記事を執筆している2022年においても最もポピュラーな工程の進め方です。
ウォーターフォールの利点
ウォーターフォールはいろいろな場面で使われています。
工業的なものづくりを真似ていますので、メーカー系などものづくりをやっている会社は、ウォーターフォールを採用する傾向が強いです。
利点は以下の通りです。
- 契約するなどの法務的なことと相性がよい
- 管理しやすい
- 分業できる
- 未知な事象が少ない時は最適
契約するなどの法務的なことと相性がよい
モノをつくってください、とお願いするとき、
「どういうモノをいつまでに作る」ことを事前に約束してもらうのは当たり前に思えます。
要件定義でどういうモノを作るかを決めて、スケジュールをたててこの日に納品します、
と発言するには工程を分けて進んでいく様を想像できないといけない、と思います。
ということで、法務的な課題をクリアするにはウォーターフォールの相性がとてもよいです。
管理しやすい
いつまでにこれができていないと、というのを事前に決めておけば、進捗の管理を容易に行うことができます。
PMPでは、事前にある程度見通すことができる、ことを前提にしています。
分業できる
工程を分けておくと、途中から別の人がやることができるようになります。
例えば、内部設計を書いてコーディングと単体テストを外注に出すというよなことができるようになります。
元々の工業でも、設計する人と製造する人は別です。したがって、工業製品を作っている人からすると製造にあたるコーディングを他の人がやることに何も不自然さを感じません。
未知な事象が少ない時は最適
未知なものが少ない時、例えば、巨大なシステムの一機能を少し強化する、というようなときはウォーターフォールで作るのが最適です。
計画時点で、何をどういう風に作るのかがほぼ分かるという状態であればウォーターフォールが最も最適な手段となります。
ウォーターフォールの欠点
ウォーターフォールは、常に批判に晒されてきました。
ソフトウェアは工業製品とは似て非なるものなのでウォーターフォールは合わない、という主張は多くの人によって繰り返し繰り返し述べられています。その一部を紹介します。
- ソフトウェア設計では要件変更が当たり前？
- 思いもよらないことが必ず起こる
- 計画と実態がかけ離れたら残業 ブラックになる
- プロセス重視、ドキュメント至上主義が人間を軽視する
ソフトウェア設計では要件変更が当たり前？
家の設計が終わって、家を建て始めた段階で「2階建てを3階建てにしてくれ」という要望は通りません。
どうしても通したいのであれば、今まで払ったお金を全て捨てて設計からやり直し、というのが妥当でしょう。
しかし、ITにおいては、非常にしばしば要件を途中で変える顧客がいます。
追加料金を払うからお願い、と言えるお客様であればまだいいですが、
「追加料金なし、スケジュール変更なしで、要件を変えよ」と宣うのには包丁でめった刺しが相当です。
顧客が100%悪いと思える場合であっても、ほとんどの場合は要求を飲むことが多いですね。
モノを作っている方からすると「要件定義書」にある文章を理解するのに数か月かかる理解力のなさをを呪いたくなりますが、
ITという形の見えないものを想像するのがとても難しいのかもしれません。
思いもよらないことが必ず起こる
ITにおけるモノづくりは、他の工業製品と違って一回だけの独自性を持った仕事です。
車の設計図であれば、その設計図をもって何万台もの車を作ります。
しかし、ソフトウェアやシステムの設計は一回だけのモノづくりのために行われます。
この独自性が、全く予想していなかったことを引き起こします。
同様のソフトウェア、システムを作った経験がない場合は、特に、今まで知らなかったトラブルに見舞われます。
新規製品であれば「必ず何かが起こる」と言っていいでしょう。
- 多重で動かすと動かない
- 多重で動いても性能が出ない
- 性能が出てもリソース枯渇
- ネットワークがパンクするとは思っていなかった
というような「バグ」「不良」と言えるようなものから、
- 採用したライブラリが思っていたように動かない
- メンバ間に仕様認識の齟齬があり組み合わせると動かない
- メンバが鬱病で離脱
- 役員がちょっかい出してくる
などの問題がなぜか発生します。
このような問題が起きるとスケジュールを守れなくなってきてスケジュールは遅延します。
というか、ほとんどのプロジェクトは遅延します。
計画と実態がかけ離れたら残業 ブラックになる
ITにおいてウォーターフォールで開発していると、スケジュールが遅れてきます。
計画変更をやらずに挽回するには、メンバの残業、休日出勤に頼るしかなくなります。
残業と休日出勤をバッファと思っている馬鹿PMさえ存在します。
メンバ自身が原因であれば残業も致し方ない気もしますが、原因は他にあることが多いです。
そうやって職場はブラックになってきます。
本質的には、ウォーターフォールだから、ではありませんね。PMが無能だからです。
プロセス重視、ドキュメント至上主義が人間を軽視する
ソフトウェアに限らないかもしれませんが、プロセスやドキュメントを重視する人たちがいます。
プロセスを遵守すること、ドキュメントを細やかに作成することは、尊く大事なことです。
ただし、あまりにプロセス、ドキュメントを重視することによって、人間を軽視することになってしまいます。
スケジュールを守るために残業させ、メンバの健康を損なうことは人間軽視です。
「なぜ」「なぜ」と問いを繰り返して本質的原因を探る、と言いながら、個人を攻撃することをやめない人々は、自分たちの行動に気付いていないんでしょうか？
アジャイル
ウォーターフォールの様々な反省の元にアジャイルが生まれました。
アジャイルでうまくいくプロジェクトがある一方、工業製品にアジャイルを適用する話は全くないので、アジャイルはITだけのものです。
アジャイルの本質は「アジャイルマニフェスト」にあります。
- プロセスやツールよりも、人との交流を
- 包括的ドキュメントより、動作するソフトウェアを
- 契約上の交渉よりも、顧客との協調を
- 計画に従うことよりも、変化に適応することを
イテレーション、スプリントなどと言われる短期的なサイクルを繰り返し回すことによって実現します。
プロセスやツールよりも、人との交流を
プロセスなんかよりも人と話し合え、ということです。
ウォーターフォールと真っ向から対抗します。
包括的ドキュメントより、動作するソフトウェアを
ドキュメントが整備されていることよりも、動作するソフトウェアを志向します。
ドキュメントは誰かのメモであったり、ホワイトボードのUML図などで補えばよくて、ちゃんと動くソフトウェアの方が大事だということです。
契約上の交渉よりも、顧客との協調を
契約を重視するアメリカでこの考えが広まったことに驚きです。
契約に拘っていくよりも、目的をはっきりさせて、協調してモノを作っていきましょう。
計画に従うことよりも、変化に適応することを
PMPは「計画が全て」みたいなところもあります。計画はくずれていくものだから、適応していくことに重点を置きましょう、ということらしいです。
筆者は本当の意味のアジャイルを経験したことがありません。噂によると、アジャイルで成功するプロジェクト多数のようです。羨ましい限りです。
アジャイルについては以下の本が詳しいです。
「アジャイルぽい」はブラック職場を生む
さて、少し余談です。
「アジャイル」はIT業界に革命を起こしたのかもしれません。筆者はその恩恵に与ったことはありませんが、かなりよい効果を得ているものと思います。
それにあやかってか、時折「アジャイルっぽくやろう」と言う人がいます。下から上がってきた意見であれば無邪気にやりたい、と思っていると思いますが、偉い人が言い始めると注意が必要です。
今まで「アジャイルっぽく開発しよう」という偉い人に何度か出くわしました。
不幸にも、上記のアジャイルマニフェスト4つのどれかを遂行することを意図していたことはありません。
「アジャイル」はアジャイルマニフェスト4つの全てを満たそうと努力することによって成功します。
しかし、偉い人は、イテレーションを繰り返して他はウォーターフォールと同じ、と考えていることが多いです。
ウォーターフォールのときと同じく
- プロセスを重視
- ドキュメントを作ることを重視
- はじめに決めた契約を守る
- 計画変更はもってのほか
で、短期間で開発せよ、と迫ります。
ウォーターフォールを逸脱せずに単に早くやれ、と言うだけで、ひどいブラック環境になることは確定です。
「中途半端なアジャイルよりウォーターフォール」という標語を掲げてください。
まとめ
ウォーターフォールとアジャイルについて、ふんわり説明しました。
各工程ごとの解説は以下をどうぞ。
>>> 【ITエンジニア】工程ごとの分類
コメント