ウォーターフォールモデルというシステムを開発していく手法は、現在でもよく用いられる伝統ある開発手法です。近年では「ウォーターフォールモデル」と「アジャイルモデル」の両手法が議論に挙げられるのですが、現時点においては、まだまだ多くの開発案件でウォーターフォールモデルが利用されています。
システム開発において「ウォーターフォールモデル」がよく用いられる理由を考えていきたいと思います。メリットやでメソッドを理解しつつ、それらがなぜ開発手法として確立されたのかも理解しておくと、案件全体を俯瞰して考えることができるので、一歩進んだエンジニアとして成長できることと思います。
ウォーターフォールモデルの特徴
「システム開発の流れを整理してみた【ウォーターフォールモデル】」でも解説した通り、ウォーターフォールモデルは各工程が厳密に分けられている特徴を持っています。一つ一つの工程に区切りをつけ開発を進めていきます。ウォーターフォールは「水が落ちる」という意味ですが、水が落ちるかの如く工程を降りていくのです。
ウォーターフォールを用いた開発は大規模な案件に向いており、複雑で高品質なシステムの際に高い効果を発揮してくれます。しかしながら、開発を確実に進めていくために特定の工程を完了させると、前の工程には戻れないのが一般的で、柔軟性に欠ける開発手法とも言い換えることが出来るかもしれません。
ウォーターフォールモデルはW. W.ロイスによって1970年に発表された論文「Managing the Development of Large Software Systems」において、「大規模ソフトウェア開発には、製品製造過程のようにいくつかの工程に分けたトップダウンアプローチが必要」と述べており、この論文がウォーターフォールモデルの原型となる考え方のようです。
ウォーターフォールモデルのメリット・デザイン
ウォーターフォールモデルについて紹介したところで、ウォーターフォールモデルのメリット・デメリットを紹介していきます。ウォーターフォールモデルは確実に工程を進めることが出来るので、高品質なシステムが期待できるものの、それ相応にデメリットがあるのも事実です。
ウォーターフォールモデルのメリット
ウォーターフォールモデルが持つ最大のメリットは「プロジェクトの計画が立てやすい」ことだと思います。システム開発は不透明な部分が多いため計画を立てるのが難しいです。計画を立てるのが難しいということは、見積もりも難しいということに他なりません。
プロジェクト全体の計画が見えてくると、予算や人員の手配に関しても段取りが立てやすいということになります。基本的にウォーターフォールモデルでは、上流工程から徐々に人員を増やし、設計・実装・試験工程が最も人が必要となるフェーズです。全体の計画が立っているので、いつ頃に何人くらいの人員を増やせばよいか、という内部的な計画も立てやすくなります。
システム開発は終わりのない戦いのような側面があります。改善部分や不具合は常にたくさんありますし、気が付けば要望が増えてます。そういった状況でも「区切り」がつけられるので、追加で挙がってきた要望は「リリースした後の追加改修で」とかわすこともできます。全体が新規要望に揺さぶられるのを防ぎ、現時点でやるべきかどうかの判断がはっきりした状態を保てるのがウォーターフォールモデルのメリットと言えると考えています。
ウォーターフォールモデルのデメリット
ウォーターフォールモデルのデメリットは「工程が区切られている」という側面だと思います。あれ、メリットも「区切られていることじゃん」と持ったかも知れません。これは開発側ではなく、発注する側の視点になるのですが、「工程が区切られて前工程に戻れない」という前提は、プロジェクトの成果物に柔軟性が欠ける可能性があることの言い換えです。
システム開発をしていくと「要件から漏れた」や「こんなこともしたかった」など、汲み取れていなかった部分が後から顕在化することが多々あります。もちろん、前の工程に戻って対応することもできますが、それにはスケジュールを変更し、プロジェクト全体のスケジュールを再確認する必要があるため、納期や進捗具合に対して様々な問題を抱えることになります。
そうした調整のために時間がとられてしまいますし、場合によっては設計工程で作成した部分を一部変更する必要性が出てくるといった手間も発生します。ウォーターフォールモデルのデメリットは、計画性の明確さゆえに柔軟性に乏しく、顧客でいうと「融通が利かず、意見が取り入れられない」という事態を招く可能性があるという点です。
ウォーターフォールモデルが使用される理由
ウォーターフォールモデルが利用される理由は、システムを開発する側としては「工程管理がしやすいこと」が一番だと思います。フェーズを切ることで計画が明確になるので、増員の計画がしやすいことが最大の理由だと思います。エンジニアの母数は多くないため、「〇月までに〇人のエンジニアを確保する」という計画性を持たせないと、エンジニアの確保が難しいのです。
また、開発規模が大きいと設計工程をやりながら実装工程をこなす、というアジャイル開発のような形式では大量のエンジニアを確保し続けなければならず、必然的に必要な予算等が上がり、案件獲得に対する大きなハードルになることでしょう。そういう点では、最初は少ない数のエンジニアで案件をスタートさせ、徐々に増員し、開発・試験工程に最大人員を動員して作り上げる形式のほうが人材配置もしやすいはずです。
IT界隈では案件が終了すると、案件に当たっていたエンジニアが労働市場に戻ってくるので、そのタイミングを調整しながらエンジニアの増員を計画します。特に大手と言われる元請企業は実装部隊を持たないことがほとんどであり、実働部隊は下請け企業に任せる傾向が強いため、より一層人員の調整が重要になっていくのです。
そうしたIT業界特有の人材の流動性に適しているのも、ウォーターフォールモデルが採用される理由の一端だと思います。
また、別の視点からいうと「区切りがある」ことにより請求がし易いという理由があると考えます。一括で請け負う場合もありますが、予算を「要件定義から基本設計で〇〇円」という取り方をする企業もあります。工程で分けられている場合は、顧客に対する請求も段階を踏めるのでリスクを分散させることが出来ます。
ウォーターフォールモデルは歴史のある開発手法ですが、上記の理由により日本では、まだ一般的に用いられているのだと考えられます。もちろんアジャイルモデルが良い場合もありますが、それらは案件の規模が小さく、数人で設計や実装が賄える場合だと思います。大量のエンジニアをずっと抱え込むのはコストがかかるのです。
決してウォーターフォールモデルが劣っているとは思いません。しかし、柔軟性がないことで顧客と揉めることもあります。要件定義がうまくいかず、認識の相違が発生したまま進んだことにより、結局、要件定義からやり直し、顧客に怒られながら案件をやり、なおかつ、やり直し部分の費用は開発企業が負担して大赤字という案件もありました。
ウォーターフォールモデルが万能とは思いませんし、アジャイルモデルも完全ではないと思います。前提としてシステム開発は不透明なので、相手の要望により「どのような手法で開発するのが最善か」を考えて、それに応じて提案を進める必要があると思います。
ウォーターフォールモデルの採択は「妥当案」
ウォーターフォールモデルを利用して開発する手法は「最適解」ではなく「妥当案」だと思っています。顧客の要望や開発規模の大きさから考えて、「一つ一つ工程を進んでいくほうが、計画性があり全体を俯瞰して進捗を管理しやすい」というメリットを選んでいることが多いと思います。
ウォーターフォールモデルは顧客の要望を取り入れるのが難しいという欠点はありますが、それを加味しても「計画性」や「予算」を重要視する傾向が高いといえるかもれません。実際、システムを開発するには多額の予算が必要ですし、システムを開発するための名目上、「○○までにシステムを導入して業務効率を図ります」と謳わなければ、予算が取れないからでしょう。
そういった予算取りにあわせて計画を立てられるのがウォーターフォールモデルの最大のメリットでしょう。「目標に対する推進力が強い」と言えると思います。日本企業の案件の立ち上がり方の特性や進め方、見せ方といった部分で、現時点ではウォーターフォールモデルを採択することが「妥当な解決策」になっているのだと思います。
