【 ソフトウェア開発 入門】4つの主な開発手法について

ソフトウェア開発

ソフトウェア開発 の現場では、プロジェクトの特性などに応じて様々な開発手法が用いられます。

今回はそういった開発手法の中でも特によく使われている4つの開発手法について、説明したいと思います。

ウォーターフォール型開発

プロジェクトによって工程の定義に若干の差はあると思いますが、開発プロジェクトを時系列に、「要件定義」「外部設計」「内部設計」「製造」「テスト」「運用」などの作業工程にトップダウンで分割します。

ガントチャートを使用してこれらの工程を一度で終わらせる計画を立てて、進捗管理していきます。

原則として、前工程が完了しないと、次工程に進まないことで、前工程の成果物の品質を確保し、前工程への手戻りを最小限にします。

大規模開発ではよく「ウォーターフォール型開発」が採用されています。

メリット

数多くの適用事例があるため、一般的なシステム開発プロジェクトの経験者であれば、多くの説明をせずともほとんどの場合、すでに経験済みの手法なので、導入が容易になります。

また、プロジェクト管理経験が豊富なプロジェクトマネージャーも少なくないので、プロジェクトマネージャーを確保することも容易になります。

各工程で何を成果物として作成するかを文書化し、承認した上で次の工程へ進むため、成果物が確実に残る点や、作業工程に対応する成果物が明確で進捗が管理しやすくなります。

デメリット

前工程へ手戻りすることが想定されていません。しかし、実際のシステム開発の現場では、契約時や要件定義時では明確でなかった想定外の要望やニーズが、仕様を詳細化していくにつれて明らかになることが多々あります。

このように現場では、開発側ではコントロールできない要因(外部要因)により手戻りが必要になることがあるのですが、ウォーターフォール型開発では、この「手戻り」を考慮していないため、実際に手戻りが発生すると、納期遅延や予算超過に繋がっていきます。

プロトタイプ型開発

実際に動作するものを早期に製作していく開発手法です。その目的は、「設計を様々な観点から検証する」「機能やアイデアを実際に形にすることで、ユーザから早めにフィードバックを得る」など、様々です。

実際に動くモノをユーザが早期に確認できるので、要求分析フェーズで明確ではなかった仕様についても、実際の挙動を見ながら明確化していくことができます。エンドユーザは設計書だけでは製品の完成をイメージしづらいことが多いので、このように早期にプロトタイプとして製品を提供することで、要件の明確化や要求事項の取捨選択を行いやすくしてくれます。

メリット

作成したプロトタイプ自体は容易に変更可能なので、実際に機能追加を試して見て、「良かったらそのまま、ダメだったら元に戻す」といったことも簡単に行えます。

また、ユーザに対して早期に目に見える形でシステムを提供することができるので、システムの最終形をユーザがイメージしやすくなります。

実際にシステムを動作させながら打ち合わせなどを行うことができるため、ユーザから色々な意見を聞くことができる可能性も高まります。

デメリット

局所的な機能の追加や改修が行われることで、作成したシステムが組織や業務全体に対して、適合しないシステムとなる可能性があります。また、適宜システムに対して修正がおこなわれていくため、システムの共通化設計などがおろそかになり、メンテナンス性が低く、柔軟性が欠如したシステムとなる可能性があります。

大規模開発の場合は、プロトタイプを作成するまでの期間が長くなりすぎるなど、不向きな側面があります。

度重なる仕様変更や機能追加が行われるため、作業計画や作業見積りが非常に困難となり、プロジェクトマネジメントの難易度が高くなることがあります。

スパイラル型開発

トップダウン設計とボトムアップ設計の長所を生かした開発手法であり、設計とプロトタイピングを繰り返して開発していく手法となります。

設計、製造、テスト、プロトタイプ(試作品)の試用などの一通りの工程を繰り返してシステムの質を高めていきます。

初めてのシステム開発の場合、最初からシステムの最終形をイメージして要求分析を行うことは非常に難しいため、一度実際にシステムを作ってみることで、フィードバックを得てまた開発を行い、システムの質を高めていきます。

スパイラル型開発は大規模プロジェクトでよく利用されます。アメリカ軍では「 Future Combat Systems 」の開発にスパイラル型開発を採用しています。

メリット

システムの試用後にフィードバックを反映する際に、問題が発生したとしても、臨機応変に対応することができます。

繰り返し問題点の修正を行い開発することで、最終的に質の高いシステムを構築することができます。

デメリット

フィードバックする度に様々な問題が発生した場合、何度も何度もシステムを開発しなければならないため、開発の完了までに時間がかかってしまいます。

また、当初の想定よりも仕様が肥大化してしまい、費用超過となってしまう可能性があります。

アジャイル型開発

迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称です。

近年、数多くのアジャイル型開発手法が考案されており、徐々にではありますが、ソフトウェア開発の現場で実際に採用されることも増えてきています。

アジャイル型開発の多くは反復(イテレーション)と呼ばれる短い期間単位を採用することで、システム開発におけるリスクを最小化しようとしています。期間単位はプロジェクトによって異なりますが、だいたい1〜4週間くらいになることが多いです。

アジャイル型開発では1つの反復(イテレーション)内でソフトウェア開発に必要な全行程(設計・製造・テスト)を行います。また、開発は業務プロセスにおいて優先度が高いものから開発していきます。

アジャイル型開発についてはこちらも参考にしてみてください。

[アジャイル開発][ Scrum ] Scrum のルールとか用語のまとめ
Scrum の用語やルールとかをまとめてみました。他のアジャイル開発の開発手法の情報とメリット・デメリットもまとめてるの...
Scrum Sprint のタスクに関する Tips 30
アジャイル開発の1つ、「 Scrum 」におけるスプリントのタスクに関する Tips がまとめられてるサイトを見つけまし...
システム開発における「 リーン 」の考え方
システム開発における「 リーン 」の考え方についてアジャイル開発について色々調べてたときに、 Scrum の他に Lea...
SCRUM BOOT CAMP THE BOOKを読んでみた(基礎編)
SCRUM BOOT CAMP THE BOOK の基礎編を読んだ時に参考になった考え方や用語について説明したいと思いま...
SCRUM BOOT CAMP THE BOOKを読んでみた(実践編)
SCRUM BOOT CAMP THE BOOK の実践編を読んだ時に参考になった考え方や用語について説明したいと思いま...

メリット

業務プロセスにおいて優先度が高いものから開発を進めるため、ユーザが本当に欲しいもののみを提供することができるようになります。

また、顧客が実際に動く画面や機能を試すことができるので、仕様の不備や要求漏れに早い段階で気づくことができます。

たくさんの詳細な仕様書を作成するよりも、実際に動く、ユーザが実際に使えるプロダクト(製品)を作ることを重視し、変化にできるだけ柔軟に対応していくことで、プロダクト(製品)の価値の最大化を目指したシステム開発が可能となります。

デメリット

変化に柔軟に対応しようとするあまり、ユーザからの要求が収束しなくなる可能性があります。

また、プロジェクトの計画を立てることが困難であるため、場当たり的な開発となってしまう可能性があります。

アジャイル型開発を経験したことがあるエンジニアも少ないため、何か問題が発生した場合に対応が困難になる可能性があります。

契約においても、契約時にシステムの最終形が明確でないため、成果物と請求の対比が非常に難しいです。きちんと契約時のルールを明確化せずにアジャイル型開発を進めてしまうと、ユーザもしくは開発者にとって不利益な契約となってしまう可能性があります。

最後に

いかがでしたでしょうか?一口にソフトウェア開発といっても、色々な開発手法があります。プロジェクトの特性に応じた開発手法を選択することで、プロジェクト失敗のリスクを軽減することができます。

また、あらかじめこういった開発手法の特性を知っておくと、プロジェクトにアサインされた際に、いつもと違う手法の開発であったとしても、開発手順などで戸惑うことなく開発を進めることができると思います。

コメント

  1. […] こちらのサイトに端的に開発方法論の主要な開発手法の種類についてまとめられています。 概略を掴むにはこちらのサイトを確認すると良いでしょう。 下記で、より詳細に記載されて […]

  2. […] 参考記事1 […]

  3. […] こちらのサイトに端的に開発方法論の主要な開発手法の種類についてまとめられています。 概略を掴むにはこちらのサイトを確認すると良いでしょう。 下記で、より詳細に記載されて […]

  4. […] 【ソフトウェア開発入門】4つの主な開発手法について | CodeLab […]

  5. […] 【ソフトウェア開発入門】4つの主な開発手法について | CodeLab […]

タイトルとURLをコピーしました