8つの開発手法をメリット・デメリット付きで解説!

プロジェクト管理やシステム設計を進めるうえで、いくつかの開発手法があります。
代表的なものとしては、ウォーターフォール型開発やアジャイル型開発などです。
開発スパンやシステム規模に応じて考案された開発手法で、それぞれに特徴を持っています。
本記事では、各開発手法の概要を確認しながら、メリットとデメリットを解説します。
プロジェクト管理 | ウォーターフォール型開発、プロトタイピング型開発、スパイラル型開発 |
システム設計 | 多層アーキテクチャ、MVCモデル |
チーム管理 | アジャイル型開発、継続的インテグレーション |
その他 | ユニケージ開発手法 |
プロジェクト管理における3つの開発手法
プロジェクト管理に使える開発手法としては、要件定義から総合テストまでを順次行うものや、先にプロトタイプを作成するもの、そして設計からテストまでを反復しながら開発する手法があります。
それぞれの開発手法は以下の3つです。
- ウォーターフォール型開発
- プロトタイピング型開発
- スパイラル型開発
ウォーターフォール型開発
ウォーターフォール型開発は、プロジェクト工程を時系列に行っていく開発手法です。
上流から下流に流れるような開発のためウォーターフォール、つまり「滝」をイメージしたネーミングとなっています。
開発前に仕様を固めるスタンダードなシステム開発で、その手順は以下の流れです。
1.要件定義
2.外部設計
3.基本設計
4.詳細設計
5.実装
6.単体テスト
7.結合テスト
8.総合テスト
開発現場によって多少名称に違いはありますが、要件定義からしっかりと確認していく手法です。
メリット
ウォーターフォール型開発のメリットは、まずプロジェクトの全容を確実に把握できるということです。
全体像が分かるので予算も組みやすく、SEやPGの人員配置も計画的に行えます。
また、工程が分かりやすいので進捗管理もしやすく、それぞれのポジションを分業で担当しても全体的な管理が容易です。
デメリット
ウォーターフォール型開発のデメリットは、仕様変更に弱い事が挙げられます。
要件定義の段階で仕様を固め、それを元に設計からテストまでを順次行うため、例えば実装段階で要件定義に変更が入った場合大きな手戻りが発生します。
手戻りが発生すればその分のコスト増加や、納品までのスケジュールにも大きく影響しますので、プロジェクトが大きく傾く原因です。
プロジェクトが進行していれば、それだけ仕様変更による影響は深刻になります。
プロトタイピング型開発
プロトタイピング型開発では、プロジェクトが本格的に進行するまえに試作品(プロトタイプ)を作成します。
工程を順次進めていくウォーターフォール型開発とは真逆の開発手法といえるでしょう。
メリット
実際に動作するプロトタイプを作ることで、エンドユーザーも開発側もプロジェクトの全体像を把握しやすくなります。
また、エンドユーザーに早い段階でプロトタイプを確認してもらうので、すぐに要求をヒアリングでき、プロジェクト進行中の手戻りを最小限に防げます。
エンドユーザーに最初から完成イメージをつかんでもらうという事は、要求定義の漏れを防ぐことにもつながるのです。
デメリット
エンドユーザーにプロトタイプを見てもらい、そこからさらに要望をヒアリングして、再びプロトタイプを作成するという手順は、システムの規模が膨らむ可能性があるというデメリットがあります。
規模が大きくなれば、当初の予定よりも工数やコストの増加につながるのです。
開発側の負担が増えるということも、デメリットの1つといえるでしょう。
スパイラル型開発
スパイラル型開発は、開発工程の「設計」「実装」「テスト」を反復して進める開発手法です。
機能などの小さな単位に区切り、プロトタイプを作りながらシステムを完成させていきます。
比較的大規模なプロジェクトに利用される手法です。
メリット
スパイラル型開発は、仕様変更に対して柔軟に対応できることがメリットに挙げられます。
細かな単位で設計からテストまでを繰り返し、プロトタイプで動きも確認できるため、仕様変更を最小限の修正で抑えることができるのです。
また、要所要所でプロトタイプが見れるため、エンドユーザーにとっても要望の出しやすい開発スタイルです。
デメリット
デメリットとしては、開発が細かな単位に分かれているため、全体像が把握しにくくなることが挙げられます。
また、エンドユーザーの要望も細かくなるため、開発が長引く可能性もでてくるのです。
小さな単位で開発を進めているとはいえ、細かな仕様変更が多くなれば、それだけ開発側の負担は増えていきます。
システム設計における2つの開発手法
システム開発における開発手法には、アプリケーションの機能を分類することで効率化する開発方法があります。
主にクライアントサーバー型のシステムに用いられ、ユーザーサイドとサーバーサイドで実現する機能を分ける考え方です。
大きく分けると、以下の2つが挙げられます。
- 多層アーキテクチャ
- MVCモデル
多層アーキテクチャ
多層アーキテクチャは、複雑なアプリケーションを機能ごとに分けて単純化させる考え方です。
3層アーキテクチャでは、大まかに「プレゼンテーション層」「ファンクション層」「データ層」の3つに分けられ、システム全体を専門分野に分けて構築します。
多層アーキテクチャでは、これをさらに分割して考えます。
- ユーザーインターフェース:ユーザー側に表示される画面など
- アプリケーション:入力や画面制御など
- サービス:トランザクションやセキュリティなど
- ロジック:ビジネスロジックなど
- データ:DBなど
このように分けることで単純化することで、それぞれの専門エンジニアがシステム構築を行えるのです。
メリット
多層アーキテクチャのメリットには、仕様変更の際に修正しやすいことが挙げられます。
例えば、ビジネスロジックに変更があった場合には、ロジック層だけを変更することでユーザーインターフェースなどの層には影響を及ぼしません。
システムを分割し単純化することで、仕様変更による影響を最小限にとどめる役割も果たします。
デメリット
機能を各層に分割することでシステムの手順が複雑化し、処理が遅延するというデメリットがあります。
1つのプロセスが冗長化することで、ネットワークを経由するデータ転送においてその手順が繰り返されてしまうのです。
MVCモデル
MVCモデルは、「Model」「View」「Controller」の3つの頭文字を取った名称です。
それぞれは、以下のような役割に分類されます。
- Model:システムのビジネスロジック
- View:UI、表示や入力を行う画面
- Controller:Viewから受け取ったリクエストに対するレスポンスし、データをModelに渡す
システムの流れとしてはまず、「View」でユーザーがリクエスト(データの入力など)を行います。
Viewが受けたリクエストを「Controller」が受け取り、入力データを「Model」へ渡します。
「Model」は、受け取ったデータを元にDBを参照し「検索」や「検証」を行い、結果をControllerへ返します。
この結果を受けControllerは、Viewへ結果をレスポンスするのです。
このように、役割を分割するのがMVCモデルの考え方です。
メリット
MVCモデルは、1つのシステムを3つの役割に分担することで、開発が効率的になることが挙げられます。
例えば、Viewはユーザーインターフェースに関わるUI・UXを専門とするエンジニアが担当し、Modelは業務を深く知るエンジニアが担当するなど、それぞれの機能に関して専門性を高めることができるからです。
デメリット
MVCモデルは、3つの分野それぞれに機能を分担しているものの、システム規模によってはControllerやModelなどどこかに負担が偏る場合もあります。
それぞれの分野が機能のどこまでを担うかを管理することも難しくなるからです。
また、お互いの依存性が強まると仕様変更の際に変更範囲が大きくなってしまいます。
チーム管理における2つの開発手法
ここでは、チーム管理における開発手法の2つを紹介します。
Web開発も多い現代、アジャイル開発は主流といってもよい開発手法ですし、バージョン管理のリポジトリを使った開発も人気があります。
- アジャイル型開発
- 継続的インテグレーション
アジャイル型開発
アジャイル開発は、システム開発開始時に決める仕様は大まかなものです。
特にWebアプリケーションの開発では仕様変更も多いため、威嚇のサイクルを短期的に反復して開発します。
1.要件定義
2.設計
3.実装
4.テスト
小さな単位に分割して開発を進めることで、短期間での開発を可能にしています。
メリット
アジャイル開発は、仕様変更に強いというメリットがあります。
要件定義からテストまでを細かく繰り返していくことで、修正範囲なども小さく素早く行えますので、エンドユーザーからの要望にも細かく答えられるのです。
また、短期間での開発ができますので、比較的開発期間の短いWebアプリケーションなどの開発にメリットのある開発手法です。
デメリット
小さな単位で開発とリリースを繰り返していくので、最終的なゴールが見えにくいというデメリットが挙げられます。
エンドユーザーの要求に細かく応えられる半面、負担した工数を考慮したスケジュール管理も難しく、計画がずれてしまいがちです。
また、全体像が見えにくいので、システム全体の進捗管理が難しいという面があります。
継続的インテグレーション
継続的インテグレーションとは、バージョン管理のリポジトリを利用して行われる開発手法です。
複数人の開発者が、自身が更新したソースコードをリポジトリにコミットしていき、フィードバックを受けながらシステムを構築していきます。
利用される人気のリポジトリとしてはGitHubなどが有名です。
メリット
継続的インテグレーションのメリットには、チーム開発の効率化が挙げられます。
ビルドとテストが自動的に行われフィードバックが通知されますので、常に最新のソースコードが共有でき、ソースコードの品質向上も担保されるのです。
また、ビルドとテストに失敗した場合にはビルドが壊れますので、その時点で不具合を確認でき、バグの早期発見につながります。
デメリット
継続的インテグレーションのデメリットは、ビルドが壊れた時に不具合を改修するため、チーム全体の開発が止まる可能性があることです。
開発者全員が1つのリポジトリを利用し、ビルド・テストが自動的に行われるため、コミットしてビルドが壊れた場合、問題を解決しなければならないのです。
これにより、開発者がソースコードのコミットに対して恐怖心が覚えてしまうこともあります。
ユニケージ開発手法
ユニケージ開発手法は、UNIX系のコマンドやシェルスクリプトでシステム開発を行うもので、日本発の開発手法としても知られています。
あらかじめ用意されているコマンドを、パイプやリダイレクトでつなぎ、基幹システムなどを構築します。
メリット
ユニケージ開発手法は、すべてをコマンドで行うため処理速度が高速で、ビッグデータなどの膨大なデータ処理を短時間でできるメリットがあります。
また、基本的には既存のコマンドを組み合わせてコーディングするため、比較的習得しやすい開発手法です。
デメリット
一般的なプログラミング言語に比べて、ソースコードが読みにくいというデメリットがあります。
ほとんどが既存のコマンドですし、足りない機能は独自にシェルスクリプトが作成されるため、保守やメンテナンスの際にも負担となるでしょう。
開発手法 まとめ
開発手法は、構築するシステムによって選定する必要があります。
大規模なシステムならば、最初から仕様をしっかりと固めるウォーターフォール型開発、リリースタイミングが速いWeb開発ならアジャイル型開発など、それぞれのメリットを十分に考慮しましょう。
また、各開発手法のデメリットを最初に把握しておくことで、開発中に問題がおこりそうな部分をあらかじめ洗い出し、工数やスケジュール、リソースの確保など十分な備えをしておくことが大切です。