初めまして。QA担当のBell_Treeです。
今回はウォーターフォールモデルについて実体験も交えて説明しようと思います。
はじめに
本記事ではウォーターフォールモデルについて、実体験を交えて説明させていただきます。
あくまで私個人の体験になりますので、全部が全部こういったものではないということはご理解いただけますと幸いです。
ウォーターフォールモデルとは
ウォーターフォールモデルについて、簡単に説明させていただきます！
ウォーターフォールの開発作業工程は以下の通りです。
1.要求定義（要求仕様）
↓
2.外部設計（概要設計）
↓
3.内部設計（詳細設計）
↓
4.開発（プログラミング）
↓
5.テスト
↓
6.運用
上記のように各工程を1から順番に上から下へと流れていく様子が"滝"のようであることから、
"ウォーターフォール"と呼ばれています。
ウォーターフォールは基本的に工程を飛ばして開発を進めることはなく、各工程きっちり段階を踏んで次の工程へと進んでいきます。
仕様の考慮漏れなどイレギュラーな事態がない限りは、前の段階へ戻ることはありません。
ウォーターフォールとアジャイルの違い
アジャイル開発とは
アジャイルソフトウェア開発 - Wikipediaより一部引用させていただきますと、
アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（アジャイルソフトウェア開発宣言）。
すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。
というような説明がされています。
もう少しざっくり説明すると・・・
『ユーザーストーリー単位で仕様の調整や実装、テストの実施を柔軟に行っていく開発手法』になります。
ウォーターフォールとアジャイルの違い
①スケジュール管理のしやすさ
◆ ウォーターフォール
ウォーターフォールは、おおよその工程や納期などが決まっているので、納期に合わせてどの工程がいつまでに終わって、この工程はいつまでに始めないと！のような予定が立てやすいのが特徴です。
◆アジャイル
開発単位が小さく柔軟に対応できる反面、試行錯誤を繰り返して行うこともあるため、スケジュール管理が難しい部分があります。
ただし、トレードオフスライダーにより「品質」「予算」「納期」「スコープ」の優先順位が定まっている場合は、「スコープを調整することによりスケジュール遅延を発生させない」等、定めた指針によって関係者で擦り合わせを行うことができます。
②仕様の柔軟性
◆ ウォーターフォール
どのような製品にしたいか？
仕様を上流工程の段階で決め、その仕様に則って開発を進めていきます。
そのため、決められた仕様での開発となるため、柔軟性には欠けます。
◆アジャイル
ある程度の仕様が定まっている状態でも、開発途中などに「やっぱりこっちの方がいいんじゃない？」のような意見があった場合に、より良い方に転換できる柔軟さがあります。
ただし、仕様がコロコロ変わることでドキュメントの最終着地点が曖昧になりやすい面もあります。
【イメージしてみよう】
脈絡もなく、ウォーターフォールとアジャイルの違いをガ〇ダムのプラモデルで例えてみようと思います。
例えばですが、A君がガ〇ダムのプラモデルを買ったとします。
決められた仕様(=設計書)に沿って組み立てていけば、仕様通りの製品ができあがりますよね？
つまり、ウォーターフォールガ〇ダムの完成です！
話は変わり、B君、C君、D君によるプラモデル同好会にE君より「こういうコンセプトのガ〇プラを作成して欲しい」と依頼がありました。
B君、C君、D君はコンセプトを基にどのようにしたらクライアントであるE君が満足するか話し合いました。
また、逐一E君に作業進捗を報告し、試作物を見せ、E君からは「こういうのもかっこいいけど、こういう風にしたらよりかっこいいかも！」と意見を貰ったりしました。
そうやって、試行錯誤を繰り返しE君が納得のいく物を作成しました。
「ガ〇プラは自由だ！」と言わんばかりのオリジナルガ〇プラ、アジャイルガ〇ダムの完成です！
...イメージできましたでしょうか？(笑)
上記のように決められた仕様で作成するものがウォーターフォールっぽく、よりこっちの方がかっこいいのではと仕様を変更したりできるのがアジャイルっぽいということを"仕様の柔軟性"の部分に絞ってお伝えしたかったです。
...というのと、私がただただガ〇プラで例えられないかなと思い付きで書いた次第ですので、超個人的な解釈となります！
ウォーターフォール開発の実体験談
ここからは私が前職で実際に体験してきたウォーターフォールでの開発ってどういう感じなの？
などを記載していきたいと思います。
私は前々職でウォーターフォール開発を7年、前職でスクラム開発を2年ほど経験してきました。
今回は前々職での経験を基に記載させていただきます。
どのような流れでやっていたか
主に受託業務を行っている会社に勤めていたため、大まかに下記のような流れでやっていました。
※記憶が少し曖昧なので、本当に大まかなものとなっております。
①営業さんから開発チームに見積もりや資料作成の依頼あり→顧客に提出
↓
②案件受注
↓
③顧客に納品時期確認、見積もりとも照らし合わせながら大まかなWBSを作成
※要件定義次第では想定外の内容が飛び出してくることもあるので、WBSのFixは④の後などに設定
↓
④顧客と要件定義のMTGを何度か実施し、要件を固める
↓
⑤要件定義書を基に設計書を作成
↓
⑥設計書を基に開発(単体テスト含む)、テスト仕様書を作成
↓
⑦結合テストを実施→不具合が出たら修正／修正確認
↓
⑧顧客側にて受入試験→不具合が出たら修正／修正確認
↓
⑨顧客OKが出たら、必要なドキュメント類をまとめ納品
↓
⑩(話があれば)運用保守
実際の経験を通して
【スケジュールについて】
スケジュールを組み、その通りにタスクをこなしていけば、基本的には平和に終われるのがウォーターフォールの良いところです。しかし、そう簡単には上手くいかない場合もあります...
例えば、機能の実装フェーズにおいて機能の実装が難航した場合にスケジュールに遅れが発生するとします。
そうなると、結合テストのフェーズにツケがまわってくるので、かなりせかせかとテスト実施をしないといけないという状況がありました。
また、設計書を基に試験仕様書を作成していたのですが、確認しないといけない項目のボリュームが大きくなり、想定以上の工数を要することもありました。
そういった場合は、早めに増員願いをマネージャーなどに相談して対応しておりました。
学びとしては納期はきっちり意識しつつも、余裕をもったスケジュールを組み立てることが大事ですし、アラートは早めにあげられるに越したことはないと思いました。
バッファはなんぼあってもいいですからね(笑)
【要件定義段階にて】
おおよそ、要件定義前の見積もり時に顧客が実現したいことなどの資料があったのですが、要件定義を進めていくうちに新しい情報が出たり、そもそもの実現したいことの難易度が変わったりというのが割とありました。
そのため、要件定義が終わる段階で完全に要件がFixしたら再度見積もりをするのが吉です。
また、スケジュールに関しても大幅に修正が必要な場合は顧客に明確な理由を伝え、リスケすべきです。
でないと、実際に作業が始まった際に地獄がじわじわと広がっていきます...(笑)
自社サービスと請負案件の違い
一つ目は、無理のないスケジュールとなっていることです。
私は弊社の某サービスに関わっているのですが、弊社に入社して実際にリリースまでの流れに携わっての感想が「スケジュールに余裕があるから大変と感じない」というものでした。
※私個人のタスク量からの個人の感想となります。
※後述とはなってしまいましたが、私が現在携わっている某サービスはウォーターフォールモデルにて開発を行っております。
また、作業内容も決まっているため、それに沿って作業を進めていけば、毎回大幅にぶれるということがありません。
二つ目は、融通が利きやすいと思います。
自社サービスですので新規バグではない既存バグが発見された場合、顧客影響が低いものであれば今回リリースするバージョンでは修正せず、後続のバージョンで修正することができるのが請負案件との違いだと思います。
基本的に上流工程での内部調整となりますので、自社内で完結できるのは自社サービスでの開発のメリットかと思います。
まとめ
ここまで読んでいただきありがとうございます。
今回は私の経験も交えて、ウォーターフォールについて記述させて頂きました。
大まかにウォーターフォールがどのようなものなのかを、イメージできるものになっていれば幸いです！
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com
