こんにちは、SOLASTER BizDevの徳永(@kotaxi_ru)です!

今回はIT開発手法の一つで一番オーソドックスな「ウォーターフォール型開発」について解説します。

昔から今も使われている手法で馴染みがある方が多いので、これからIT開発を発注する方やまだIT開発の発注に慣れていない方はぜひ参考になれば嬉しいです。

この記事を読んで欲しい人
  • IT開発の発注が初めてor慣れていない
  • ウォーターフォール開発について詳しく知りたい
  • オフショア開発に興味がある
  • ロシアやウラジオストクに興味がある
  • SOLASTERに興味がある

弊社SOLASTERでは、日本から近いロシアのウラジオストクでオフショア開発事業を展開しています。

IT開発の人的リソースでお困りであれば、お気軽にお問合せください!

ウォーターフォール型開発とは?

ウォーターフォール型開発はシステム開発で用いられる開発手法のうちの1つで、「要件定義」「設計」「実装」「テスト」などの工程に分けて、作業を一つ一つ完成させて順番に進めていく方法です。

アジャイル型やラボ型など数ある開発手法の中で、歴史が古いかつ認知度の高いので現在でも大規模なプロジェクトを中心にシステム開発で用いられています。

ウォーターフォール型開発の特徴
  • 1工程が終わるまでは次に進まない
  • 次の工程に進んだら前の工程に戻らない
  • 各工程ごとに成果物を作ち品質を確保

一度始まったら前には戻れないという特徴が滝に似ているところから、ウォーターフォール(滝)と呼ばれています。

ウォーターフォール型開発の3つのモデルとは?

なるほど、一度始まったら戻れないからウォーターフォール型開発は開発前に足並み揃えることがかなり大事なんだね…!

そうなんです。ここではウォーターフォール型開発にある3つのモデルをご紹介します!

V字型モデル

V字型モデルは、ウォーターフォール型開発の1工程である「テスト運用」に着目してプロセスが決まる開発モデルです。

このモデルでは実装(プログラミング開発)を折り返し地点にし、要件定義などの上流工程とテスト運用が対等になるようにテストを行います。

「要件定義⇔受け入れテスト」「基本設計⇔結合テスト」「詳細設計⇔単体テスト」といった具合で各上流工程と各テストをリンクさせて、「ちゃんと要件にあった成果物が出来上がったか」というレビュー効果の向上が期待できます。

プロトタイピングモデル

プロトタイピングモデルは、本格的な設計が始まる前に簡単なプロトタイプ(試作品)を開発しユーザーや顧客によってその試作品の評価が行われる開発モデルです。

ではこのプロトタイピングの工程はどこに組み込まれるかというと、要件定義と基本設計の間に組み込まれます。

プロトタイピングモデルのメリットは、顧客の要件と開発者の齟齬などを早期に発見&解決できるため最終工程から大きく手戻りしてしまうリスクを事前に防ぐことができます。

スパイラルモデル

スパイラルモデルは設計・実装・テストのシステム開発の一通りの工程を繰り返し、成果物(システム)の質を向上させていく開発モデルです。

この開発モデルのメリットは、品質が高くない状態でも一旦成果物としてアウトプットすることで顧客にソフトウェアがどのように動くのかといったイメージを、早い段階から共有することができます。

開発サイクルをグルグルと渦のように回していくイメージなので、スパイラルモデルと名付けられました。

スパイラルモデルとアジャイル開発の違いは?

「一通りの開発工程を繰り返す」という点はアジャイル開発と重なりますが、アジャイル開発は品質が高くない状態でもリリースをしてしまい改善と開発を繰り返す手法です。

スパイラルモデルは一定の品質に到達するまでリリースまではせずアジャイルと似た開発手法ではありますが、近年では早期でリリースできるアジャイル開発が主流です。

ウォーターフォール型開発の流れとは?

ウォーターフォール型といっても色んな開発モデルがあってプロジェクトによって変わるのね…!

ではここでは、先ほど軽く触れた”開発の流れ”についてより具体的に解説します。

  1. 要件定義プロセス

    要件定義プロセスは、ウォーターフォール型開発で最も上流にある工程です。

    担当者がクライアントにヒアリング調査を実施し、話し合いの中で実装したい機能や性能を明確にしていきます。

    そこから整理した情報を基に、要件定義書を作成しクライアントと開発するシステムについて認識の齟齬が無いか確かめます。

  2. 基本設計プロセス

    基本設計プロセスでは、要件定義プロセスで話し合った顧客の要望を満たす機能や開発方法を決定します。

    要件定義書を参考にして開発すべき機能を全て洗い出し、どのようにシステムが実装できるかを明確にすることがここでは重要です。

    このプロセスでは基本設計書が成果物として出来上がり、仕上がりのイメージに齟齬がないかクライアントと確認をします。

    そこまで複雑ではないプロジェクトでは、要件定義プロセスと基本設計プロセスが同時に行われることもあります。

  3. 詳細設計プロセス

    詳細設計プロセスでは、主に開発サイドや開発会社内に向けた書類を作成します。

    要件定義プロセスや基本設計プロセスの段階ではまだ不明瞭だったものがあれば、訂正を行い仕様書を作成します。

    プログラマーなどの開発者はここで出来上がった仕様書を基に開発します。ここに記載の無い修正や追加開発は費用やスケジュールに影響が出るので、認識に齟齬が無いか担当者としっかり話し合いましょう。

    ちなみに仕様書はロシア語でТехническое Задание(ТЗ)といいます!(完全に社内でしか使わない用語なので安心してください)

  4. 実装プロセス

    実装プロセスでは、開発をスタートし設計書や仕様書を基にシステムや機能を実装していきます。

    本プロセスでの成果物はソースコードで、多くの場合は実装プロセスと次の単体テストを同時に進めていきます。

  5. 単体テスト

    単体テストでは、開発した機能を単体ごとでエラーなく動いているかどうかを評価するプロセスです。

    機能単体が想定通りに動いていることを証明するエビデンスが成果物となることが多いです。

    簡単な単体テストをする場合は、テストスクリプトを作成し効率的に自動テストツールでテストを行います。

  6. 結合テスト

    結合テストでは、単体テストのフェーズで想定通りに作動した機能同士を連携させ、正確に作動するか確認して性能を評価します。

    機能を連結させた際プログラムがエラーなく動作するかどうか確認することが目的です。結合テストでも、プログラムが想定通りに動作したことを証明できるエビデンスをとり、成果物とします。

  7. 総合テスト

    機能ごとの単体テストが終われば、次はシステム全体を組み合わせて総合テストを行い性能を評価します。

    ここでスムーズに機能が動く確認が取れれば、次の受け入れテスト(検品)に進みます。

  8. 受け入れテスト

    受け入れテストでは、いわゆる納品&検品で本番環境でも無事システムが動くかどうかをチェックします。

    もしここでエラーが生じれば、その原因を探るために前のプロセスへ戻る必要が出てくる可能性があります。

  9. リリース

    開発したシステムを本番環境へリリースします。

  10. 保守・運用プロセス

    納品し終わったシステムの保守&運用を行い、使用中で不具合があればSLA(サービスレベル合意書)に基づいて速やかに対応します。

    またリリース後に追加開発のリクエストがクライアントから挙がる可能性もあるので、その場合もシステム保守として追加開発などの対応をします。

ウォーターフォール型開発が向いているプロジェクト&案件

ウォーターフォール型開発は一つ一つのプロセスをしっかり進めていくんだね。じゃあそんな開発スタイルが向いてるプロジェクトってどんなものがあるんだろう?

ここではウォーターフォール型開発にした方が良いプロジェクトや案件をご紹介します。

大量のリソースやコストがかかる大規模な開発プロジェクト

大規模な開発プロジェクトではかなり多くの人的リソースが関わります。

人が多いだけに開発中の意思疎通が非常に困難となるため、開発に着手する前に細かい仕様まで決めるウォーターフォール型開発と相性が良いのです。

人手が必要になるタイミングで、人員を大量に確保して開発をスムーズに進めることができます。

また人的リソースが充当している場合は、新たに開発者などの人員確保をせず必要な人材だけを稼動し効率良くプロジェクトを管理できます。

要件が状況によって変化しないシステム

ウォーターフォール型開発は、確実性が高いかつ開発途中で要件や仕様が変更にならない基幹系システム開発に適しています。

基幹系システムとは、生産管理や勤怠管理・財務会計などヒト・モノ・カネに関わるシステムのことを言います。

こういったシステムは法的に制約されている部分もあるため、システム開発の仕様が大幅に変更されることはほとんどありません。

高品質が求められるシステム

銀行のATMなどの基幹系システムでは、不具合や障害が発生すると企業に大きな損失がかかってしまいます。

そこで高品質が求められるシステム開発では、開発に着手する前に綿密に設計を行うウォーターフォール型が非常に相性が良いのです。

システムをリリースする前に全ての機能を実装しテストを繰り返すので、ウォーターフォール型は障害発生率を限りなく0%に近づけるシステム開発に向いています。

請負契約でのシステム開発

請負契約とは、請負人(システム開発会社)が仕事を完成させることを条件に、その結果(納品)に対して料金が支払われる契約形式です。

この請負契約では契約時点で実装する機能・いつまでに開発するか・いくらで開発するかを明確にする必要があります。

ウォーターフォール型開発は開発に着手する前に仕様や要件を確定させるため、請負契約とも相性が良いです。

また、システムの一部機能だけを開発するスポット型開発にもおすすめしています。

弊社では初めてお取引する開発会社様からまずスポット型開発でお試しいただく場合が多いので、ぜひお気軽にご相談ください!

ウォーターフォール型開発のメリット

なるほど!ミスが絶対に許されない慎重な開発だったり成果物が決まっているものはウォーターフォール型開発と相性が良いんだね。

ここからはウォーターフォール型開発のメリットについて解説します。

開発スケジュールの全体像を把握&管理しやすい

ウォーターフォール型開発ではプロジェクトの開始時に全体スケジュールの計画を作成しそれに沿って開発を進め進めるため、スケジュールの大幅な遅れを防ぐことができます。

またウォーターフォール型開発では、最初の要件定義プロセスの段階で必要な機能や人員・予算などを確定させます。

そのため開発の最中でもそれぞれの工程での進捗把握やスケジュール管理がしやすく、前工程から次工程へ引き継ぎがしやすいというメリットがあります。

開発プロジェクトの方針が明確で一貫している

最初のヒアリングから要件定義・設計プロセスの段階で合意した仕様を途中で変えないというのがウォーターフォール型開発の原則です。

開発プロジェクトの初期段階で実装すべき機能や仕様をしっかりと定義することで、プロジェクトのゴールを明確にすることができスムーズに開発を行うことができます。

ゴールが明確になっていることで納品物の品質も非常に担保しやすく、またイレギュラーも起こりづらいためエンジニアの人材育成にも向いています。

歴史が長く開発事例や経験者が多い

ウォーターフォール型の歴史は非常に長く、起源は1970年頃だと言われています。

日本でも長年採用されており、日本の開発者やプロジェクトマネージャーのほとんどはウォーターフォール型開発を経験しています。

なので人材を確保しやすく開発作業をスムーズに行えます。

ウォーターフォール型開発のデメリット

堅実な開発ができるのがウォーターフォール型開発ですが、もちろんデメリットとなる部分もあります。

開発中に仕様変更があると大きな手間がかかる

ウォーターフォール型開発では最初に全ての工程の機能や要件を決定した上で開発に取り掛かるので、上流工程である要件定義プロセスや基本設計プロセスでしか発注者やクライアントのヒアリングする機会がありません。

その為、開発中に仕様変更などがあった場合は大きな手間がかかり納品が大幅に遅れる可能性が高くなります。修正にもコストがかかるため、致命的でなければそのままリリースしてしまうのも珍しくないケースです。

開発期間が長期化しやすくスピード感が遅い

素早くリリースしながら開発サイクルを回すアジャイル開発などと比較すると、ウォーターフォール型開発は事前に要件や機能を確定させるため開発着手までに時間がかかります。

そのため基幹系システムなどではなく、スタートアップやベンチャー企業のアプリ開発とはスピード感がウォーターフォール型開発と相性が悪いと言われています。

現場で納品物を使うユーザーの意見が反映されにくい

ウォーターフォール型開発では、実際にシステムを使うユーザーが開発物を確認するのは受け入れテストや納品などの最終工程です。

そこでイメージしていたシステムと違うものが出来上がったりするケースが発生することもあるので、プロトタイピングモデルと併用するケースもあります。

まとめ

今回はシステム開発手法の1つであるウォーターフォール型開発の基本から向いているプロジェクト、メリットやデメリットまで解説していきました。

ウォーターフォール型開発は銀行ATMなどの障害を限りなく0に近づけたいシステム開発一部機能だけを開発するスポット型開発などに向いていて、それぞれの工程を丁寧に踏んでいけば開発前のイメージと非常に近いものが完成するでしょう。

近年では、ウォーターフォール型開発よりもアジャイル開発を取り入れる開発企業なども増えてきています。

今回の記事を読んでいただいて、「どちらの開発手法が良いか?」という視点ではなく「どんなシステムを開発したいか」「システムを使う上でどんなことに気をつけたいか」などといった視点で開発手法を選ぶようにしましょう。

弊社SOLASTERでは、日本から近いロシアのウラジオストクでオフショア開発事業を展開しています。

IT開発の人的リソースでお困りであれば、お気軽にお問合せください!