ウォーターフォールモデルとは、水が上から下に流れるように、順番に工程を進めていく方式です。要求定義、外部設計、内部設計、プログラム設計、コーディング、テストという分け方が一般的です。

そんなウォーターフォールモデルでの開発は、多くのソフトウェア開発者にとって、一番初めに触れるモデルでソフトウェアやシステム開発の進め方の基礎といってもいいモデルです。

時代遅れと言われることもありますが決してそんなことはありません。
デメリットさえ改善できればいまだに有効な進め方といってよいでしょう。

ウォーターフォールモデルのメリット

ウォーターフォールモデルのメリットとしては、プログラム開発では一番使われているモデルでもあり、作る方としても委託する方としても共通認識として機能する部分が多いこと。

また、最初に道筋をきれいに決めて進むことで、全体の工数を把握しやすく、進捗管理がしやすいモデルです。

ウォーターフォールモデルのデメリット

管理し易く丁寧な印象のウォーターフォールモデルですが、デメリットもあります。

最も大きな問題点は、仕様変更に弱いという性質。最初にきっちりと仕様書を作り、それに則って作業を進めるウォーターフォールモデルは手順を戻す時に、殆ど全てをやり直さないといけないことになります。

とはいえ、工数や進捗の管理し易さ、分かりやすさからウォーターフォールはクライアント(システム作りを依頼、購入した)にも分かりやすく、人気なモデルです。欠点を補い、良さを引き出して上手く付き合っていきたいところ。

ウォーターフォールモデルのやり方を外れ過ぎない程度に、ちょっとした工夫を凝らしてみると開発がはかどるかもしれません。

以下ではウォーターフォールモデルとの上手な付き合い方を3点ご紹介します。

具体的な例としては、設計図の画面は実物のスクリーンショットにするといった工夫でしょう。設計書には、どういった画面かの図を載せないといけませんが、先に画面を実際に作ってしまえば、後はスクリーンショットを撮って張り付けるだけで画面イメージを作れてしまいます。

また、画面のレイアウトや、ちょっとした画面遷移など、誰でもすぐに理解できるレベルの所までは、先に開発を済ませてしまうことで、システム全体のイメージも掴みやすくなり、設計書を書く時にも捗ることと思います。

当然、画面はそのまま実装することを前提に作るので、コーディング作業と基本設計の両方を同時に進行できます。

過去にサイト設計したクラウドファンディングのサイトでも、実物のスクリーンショットを先に作ったことでスムーズな進行ができました。

ウォーターフォールモデルに忠実に従うとすれば、ＳＥは設計関連、プログラマはコーディングやテストと、きっちりと役割分担をする必要があります。

しかし、それだとウォーターフォールモデル「仕様変更に弱い」という弱点は解消されません。そのため、役割分担を少しだけ崩してみるといった柔軟な工夫をしてみましょう。

プログラマはコーディング、ＳＥは設計といった役割分担は、システムを作るという観点においてはあまり効率的とはいえません。設計作業と製造作業は、たがいに行き来しながら行う方が、やり方として自然だからです。

最初にある程度、どういった機能を持っていて、どういう風に作るのかといったことを決めるのは必要ですが、最初に完成されたシステムを全てイメージすることは、経験豊富なＳＥでも難しい事です。

なので、設計書を作る際には実際に画面レイアウトや画面遷移を作りながら設計書を書くことになります。

また、この手法は、個々のスキル差を埋めるためにも有効です。実際にコーディングしてみないと全くイメージが湧かない人や、逆にコーディングは設計がきっちりと出来てからでないと難しいという人。こういった人はプログラマ、ＳＥといったくくりに限らず、存在します。

システム開発は求められるスキルに差があるため、派遣や出頭した人でチームを組むことが多い職業です。

なので、仕事の進め方や得手不得手の傾向はバラバラになりがちです。この手法は、そういったプロジェクトチームの断衝材になるでしょう。

クライアントとの擦り合わせの情報を全体に公開して、要求定義書を書きながら、基本設計書、可能な範囲で詳細設計書も書き、コーディングも出来る所まで済ませてしまえるようにすると効率がいいです。

その際、マクロや引用等で設計書を関連付けてしまうと書類作成の面でも効率がアップします。

このテクニックのポイントは、不明確な仕様の部分は後回しにすることです。クライアントとは出来るだけ蜜に連絡を取りたいものですが、完全にリアルタイムとはいきません。また、開発を進めるうちに浮き出てくる疑問点や問題点もあるでしょう。

仕様変更での後戻りを無くす手段としては、不明確な場合は基本設計の段階でも作成をストップさせ、明確な部分は詳細設計やコーディングまで進めてしまうといった、工程毎ではなく機能毎の進捗管理が効率的です。

その際に懸案事項のリストを作成、共有し、不明確な部分はそこに書いて疑問点を明確にしておくと、いざクライアントとの打ち合わせの時に聞き漏らしが少なくなるので、合わせて行いましょう。

細かい所をちょっとしたアイデアで工夫して、工数節約、効率アップを心掛けたいですね。

・作る方としても委託する方としても共通認識ができる。・仕様変更に弱い。・設計図の画面は実物のスクリーンショットにする。・役割分担は明確に作らない方が良い。・不明確な仕様の部分は後回しにする。

ウォーターフォールモデルをせ成功させるコツは柔軟性にあります。

さまざまな開発における基礎であり、有効に進めることができます。

このモデルを取り入れる方は、ぜひ上記を意識してみてください。