システム開発手法「ウォーターフォール型」とは？

続いての工程は設計となりますが、設計には基本設計と詳細設計があります。基本設計では要望を実現するためにどのような機能を実装するか、また利用するハードウェア、ソフトウェア、サーバー、ネットワーク構成等を選定していき、成果物として基本設計書を作成します。基本設計に関してはほとんどがクライアントも理解できる外部向けの内容となっており、要件定義と同様にクライアントと打ち合わせをして認識に齟齬がないかを確認することもあります。

基本設計が外部向けなのに対して、詳細設計は実際に作業をするエンジニアに向けた内部用の設計という色が濃い工程となります。基本設計で設定した機能をどのようなプログラムで実装するか、データベースにどのような項目を設定するか、各ページのデータ受け渡し方法等の細かい部分について設計していくため、成果物となる詳細設計書はサーバー、ネットワーク、データベースのインフラエンジニアやプログラマーといった各部門のプロジェクトリーダーに任せることも多いです。実装を担当する各エンジニアは、主にこの詳細設計書を元にその後の作業を進めていくことになります。

下流工程

下流工程は実装と各種テストから成り立っています。実装はインフラエンジニアが環境構築したり、プログラマーがプログラミングを行う段階で、プロジェクトリーダーやプロジェクトマネージャー、SEは現場の進捗管理や、問題が発生した際の対処の他、クライアントや上層部とミーティングを実施してプロジェクトの進捗報告をします。現場の人手が不足している場合は、プログラミング等の実作業を手伝う場合もあります。なお実装の工程における成果物はプログラミングされたコードとなります。

テストの種類は現場によって多少異なりますが、単体テスト、結合テスト、総合テストに分類し、この順番で行われるのが一般的です。各テストではそれぞれにテスト項目を一覧にしたチェックリストが作成されることも多く、テスト工程での成果物は動作チェックしたことが証明できるチェックリスト等になります。単体テストはプログラム単体がそれぞれ想定どおりの動作をするかの確認、結合テストは複数の機能を連携した場合に正常動作するかを確認します。最後の総合テストではシステム全体を稼働させた場合に動作に問題ないかをチェックしていきます。いずれのテスト段階においても、エラーや想定外の動作が発生した場合は原因を探って改修を済ませる必要があります。例えば単体テストで修正箇所が見つかった場合は結合テストに進まず、改修して問題ないことが確認できてから次に進みます。

総合テストまでの段階は主に各担当エンジニアが実施しますが、そこまでで問題ないことが確認できた後は実際にシステムを利用することになるクライアント側のユーザーに使い方や仕様をレクチャーしながら触ってもらいます。本番同様の操作をしてもらうことで発覚するエラーや不具合もあるため、発覚した場合には改修するという作業を繰り返していき、問題ない状態となったら最終的にクライアントへ納品となります。

よく比較されるアジャイル開発とは?

アジャイル開発で行われる各工程はウォーターフォール型とほぼ同じです。しかしアジャイルの場合は要件定義(計画)〜テストまでのサイクルが短期間で行われます。これはシステムのリリースを早めて一刻も早くクライアントに業務利用してもらおうという考えから採られた手法であるためです。

開発するシステムに優先順位をつけていき、すぐに必要となる部分だけを優先的に開発してリリースし、その後も要件定義(計画)〜テストのサイクルを繰り返して機能を追加しながらシステムの完成を目指します。なお「アジャイル(agile)」という言葉は馴染みのない英単語かもしれませんが、日本語で「敏捷、素早い」という意味を持つので、まさにこの類の開発手法を表している名称と言えます。またアジャイル開発において短期間の繰り返しのことを「イテレーション(反復)」と呼び、期間としては1週間〜長くても1ヶ月程で行われることが多いです。

リリース後は実際にクライアントが利用してその結果をフィードバックしてもらい、必要に応じて改修を行うということを繰り返していきます。このようにアジャイルは短期間で開発を繰り返してリリースし、フィードバックによって仕上げていく手法となるため、ウォーターフォール型に比べて柔軟な対応が可能で、やり直しもしやすい手法となります。

なおアジャイル開発にはフレームワークが存在し、有名なものに「スクラム」という手法があります。スクラムはチーム一丸となって協力しながらプロジェクトを効率的に進めるフレームワークであり、各チーム間での継続的なコミュニケーションが必要とされます。またイテレーションごとにうまくいっていることや課題点等を現場で振り返って、次のイテレーションに生かします。その他にもアジャイル開発には「エクストリーム・プログラミング」や「ユーザー機能駆動開発」等のフレームワークがあります。

ウォーターフォール型のメリット・デメリット、アジャイル開発との使い分け

アジャイル開発は2000年頃から広く採用されるようになったのに対して、ウォーターフォール型は1970年代から論文等の中で取り上げられている歴史の長い開発モデルです。これだけ長い間利用されているウォーターフォール型のメリットの一つはシンプルで管理しやすいということが挙げられます。要件定義や設計で決めたことを元にあらかじめ全体のスケジュールを立て、実装やテストを進めていくので計画が大きく崩れることはなく、進捗管理や、途中で担当者が変わった場合も引き継ぎがしやすく、実務をしながらの人材育成もしやすい方法です。システムが完成した際の品質を高いレベルで担保できるという点もウォーターフォール型のメリットです。

一方のデメリットとして後戻りが難しいという点が挙げられ、クライアントから仕様変更の要望があった際の対処に多くの時間やコストが発生する可能性が高くなります。またウォーターフォール型では要件定義書や各種設計書、テスト時のチェックリスト等、成果物として多くの書類を作成する必要があります。ウォーターフォール型は総合的に開発完了までに時間がかかりやすく、その間クライアントはほとんどシステムの出来具合を知ることができないというデメリットがあります。

以上の特徴より、ウォーターフォール型は不具合が頻発することを避けたい高品質なシステムが求められる金融や通信システム、組み込み系を開発する場合や、仕様変更の少ないシステム、大規模で大人数で進めるプロジェクトに適していると言えます。

逆にスタートアップやベンチャー企業ですぐにサービスをリリースしたいため開発のスピードを重視するという場合に有効なのがアジャイル開発となります。またウォーターフォール型と違って、仕様や計画の変更が行われることを前提としている手法でもあるので、クライアントからのフィードバックに沿って柔軟な対応ができることもアジャイル開発のメリットです。一方で短いサイクルのイテレーションがたくさん発生するため全体の進捗が見えづらい、管理しづらいというデメリットもあります。また仕様変更が多発することで本来の想定と完成したシステムのギャップが発生してしまう可能性が高くなりやすい手法でもあります。

以上見てきたようにウォーターフォール型、アジャイル開発にはそれぞれ向き不向きがありますが、この両者のメリットをうまく組み合わせた「スパイラル型」という開発手法もあるので最後に簡単に紹介します。スパイラル型はほぼアジャイルと同様でイテレーションを繰り返して完成を目指しますが、その中でシステムのプロトタイプ(試作品)を構築し、クライアントに実際に操作してもらいながらフィードバックを受けるという特徴があります。そのため開発状況がクライアントに対してオープンとなり、密に連携を取りながら臨機応変に仕様変更や改修を行えるうえ、システムの品質を高めていくことが可能となります。しかしながらスパイラル型にもプロトタイプを構築するための工数やコストが余計に発生してしまうというデメリットがあることにも注意が必要です。

まとめ

ITシステムの開発は絶対的にウォーターフォール型、またはアジャイル型であるべきということはなく、プロジェクトで作り上げるシステムによって適切なモデルを選択して採用する必要があります。最適な開発モデルを採用することで効率的に進められ、結果的にクライアントの満足度を上げることにも繋がるため、ぜひ各開発モデルを正しく理解し、みなさんが管理するプロジェクトにおいて使い分けていただけると幸いです。また開発モデルはあくまで開発を効率的に進めているための型なので、型にはめるために現場の状況に相応しくない指示を出してしまうと本末転倒となりかねません。ぜひスパイラル型開発等の他の手法も検討しながら臨機応変に対処し、現場のエンジニアから信頼されるリーダーやマネージャーを目指しましょう。