システム開発ライフサイクル(SDLC)とは 各フェーズと7つのモデルを図で紹介

システム開発ライフサイクル(SDLC)とは 各フェーズと7つのモデルを図で紹介
システムやソフトウェア開発には、システム企画からリリース、運用までの周期「ライフサイクル」があります。このライフサイクルを知っておくことは、システム開発の全体像を把握する手助けになり、コストの削減や中長期的な視点で開発を進めることにつながります。このコラムでは、システム開発ライフスタイルにおける、「企画・要件定義」、「設計」、「プログラミング」、「テスト」、「展開・リリース」、「保守運用・メンテナンス」の7つの過程と、7つの開発モデルについて解説します。この記事は、デザインワン・ジャパン DX事業本部でシステム・アプリ開発に携わる泉川学が作成しました。

目次

システム開発ライフサイクル SDLCとは

「システム開発ライフサイクル」とは、システムが企画されてから実際にリリースして運用されるまでの周期を、ライフサイクル(人の誕生から死まで)になぞらえて表したものの呼称です。「Systems Development Life Cycle」、または「SDLC」と略して称されることもあります。具体的には、システムの企画から始まり、設計、コーディングなどのプログラミングといった実装、その後テストを経てリリースされ、実際に運用されていく過程のことです。

運用が開始した後も、バグの修正や機能の追加など、運用保守・メンテナンスがそのサービスが続く限りは実施されていきます。




 

システム開発ライフサイクル 7つの過程

システム開発ライフサイクルは、7つの過程で説明できます。

まず、どういった目的でそのシステムを開発するのかなど企画、要求を明確にする「企画・要求定義」、その要求を踏まえて実装する機能や仕様を決めていく「要件定義」、使い勝手や機能に対する「設計」、プログラミング言語で実際に開発していく「プログラミング」、設計通りになっているかの「テスト」、システムを公開する「展開・リリース」、リリース後に問題がないかを都度チェックしていく「保守運用・メンテナンス」と続きます。それぞれを解説します。

 

企画・要求定義

システム開発は、発注側の企業で企画し、要求定義することから始まります。これは、開発したいシステムについて、発注側の企業が、何の目的でそのシステムを開発するのか、ビジネスにどう寄与するのか、などを企画し、そして何をどうしたいか、という「要求」を明確にする工程となります。要求定義は、明確になっていないままプロジェクトが進むと、開発がスタートした後で修正が何度も発生して開発スピードが落ちたり、あとあと開発費用がかさむことにもつながってしまいます。

 

企画は、ビジネスの根幹に関わる部分であるため、開発会社に丸投げすることはお勧めしません。要求定義については、システム開発を発注すると、この次の工程である「要件定義からしか受け付けない」という開発会社も多いようですが、システム開発初心者には、難易度が高いと感じられることもあるでしょう。

デザインワン・ジャパンでは、新規事業の立ち上げなどもサポートしておりますので、お気軽にご相談ください。

 

要件定義

発注企業からの要求定義を踏まえて、開発企業側で実装する機能や仕様などを定め、どのように進めていくのかを決めるフェーズです。

 

設計

操作性、使い勝手に影響するUI(ユーザーインターフェース)の設計「外部設計」と、機能や動作の「中身」に関する「内部設計」を行います。

 

プログラミング

設計した内容を、プログラミング言語を使って実際に開発する工程です。ここからシステムをカタチにしていく「製造工程」に入っていきます。

 

テスト

作ったシステムを、実際にテストする工程です。問題なく動作するか、設計通りになっているかを確認していきます。このテストには、主に単体テスト、結合テスト、システムテスト、運用テストと4段階あります。

 

展開・リリース

システムを公開する工程です。

 

保守運用・メンテナンス

実際に使用する中で発生したバグやトラブル、アップデートなどの工程です。サービスが続く限り行っていきます。

 

システム開発ライフサイクル 主要な7つのモデル

ここでは、システム開発ライフサイクルの、主要な7つの開発モデルを紹介します。これらのモデルのどれで進行していくかによって、開発のスピード感や質に差が出てくるのは、1億円以上などの大規模開発のケースであると考えられます。そのような場合でない限りは、どのモデルを選ぶべきかを意識しすぎる必要はありませんが、主要なモデルを把握しておきたいという場合に参考にしてください。

モデル

ウォーターフォール(予想)

アジャイル(適応)

ハイブリッド型

反復型

スパイラル(漸進)型

V字型

プロトタイプ型

概要

一つの開発工程を完了させてから次の工程に進んでいくモデル

開発工程を機能単位のサイクルで繰り返すように進めていくモデル

ウォーターフォール型とアジャイル型を組み合わせたモデル

工程を繰り返して段階的に開発を進めるモデル

工程を機能ごとに分割し、重要な機能から開発していくモデル

各工程に対して、対応するテストで検証していくモデル

試作品(プロトタイプ)を作ったのちに本格的な開発を行うモデル

開発途中の修正の柔軟性

 

修正によるスケジュール遅延のリスク

メリット

納期やスケジュールが想定しやすい

仕様や要件を随時ブラッシュアップしやすい

ウォーターフォール型のスピード感を持ちながら、アジャイル型の柔軟性を取り入れられる

軌道修正がしやすい

柔軟に仕様を変更しやすく、品質を高めやすい

開発全体像に向けてチェックが行えるため、手戻りや大幅な修正のリスクが抑えられる

発注側が不慣れでも具体的な指示を出すことができる

 

ウォーターフォール(予想)型モデル 

一つの開発工程を完了させてから次の工程にステップしていく開発モデルが「ウォーターフォール型」です。この名称は上流から下流へ滝の水(water)が流れ落ちる(fall)よう、開発を行うことに由来しています。日本国内ではこのモデルが一般的です。

メリットは、企画や要件定義などの上流工程から保守・運用などの下流工程まで計画的に開発を進めることができるため、納期やスケジュールが想定しやすいこと。一方、後戻りができない開発とも言えます。

デメリットとしては、工程の後半にならないと実物に触れられない点。いざ出てきた実物が、イメージ通りではなかったり、不具合やバグがあったりした場合は、修正に大幅な時間やコストが掛かってしまいます。

 

アジャイル(適応)モデル

要件定義から設計、プログラミング、テストという開発工程を機能単位のサイクルで繰り返すように進めていく開発モデルです。アジャイル(Agile)とは、「素早い」「機敏な」「頭の回転が速い」という意味。必要な要件を優先して開発していき、開発が完了した各機能の集合体としてシステムやソフトウェアを形成していくモデルです。適応モデルとも呼ばれます。

短期のサイクルで開発とフィードバックを繰り返しながら開発を行うため、仕様や要件を随時ブラッシュアップしやすいことが大きなメリットです。完成度も高めやすいと考えられます。しかし、ウォーターフォール型に比べると、納期や進捗は予想しづらいでしょう。

 

ハイブリッド型

ハイブリッド型は、ウォーターフォール(予想)型とアジャイル(適応)型を組み合わせたライフサイクルです。要件がある程度固まっている部分はウォーターフォール型で計画的に開発を進めていき、固まっていない部分はアジャイル型を使って機能単位で開発工程を繰り返しながら開発していきます。

ウォーターフォール型のデメリットである、最後の工程まで進まないと開発内容の確認ができない点が、ハイブリッド型では途中で発注側のフィードバックをもらうことも可能に。つまり、ウォーターフォール型のスピード感を持ちながら、アジャイル型の柔軟性を取り入れられるということです。プロジェクトの特徴や開発の工程、時期ごとなどに、両型を使い分けて柔軟に開発を進めることができます。

 

反復型モデル

 

反復型モデルは、要件定義、設計、プログラミング、テストの一連の工程を反復しながら開発を進めるモデルのこと。ウォーターフォール型よりも小さい単位で反復していくため、より柔軟に修正に対応することができます。一連の工程を完了するごとに、発注側が開発途中の段階のものを確認できるため、軌道修正がしやすい点がメリットです。

  

スパイラル(漸進)型

漸進型とも呼ばれるスパイラル型は、システムを機能ごとに分け、機能単位で設計、プログラミング、テスト、評価の一連の工程実施し、完成したら次の機能についても同様の工程を反復して開発を進めるモデルのことです。重要度の高いシステムから優先的に開発していいきます。

 

メリットとしては、個々の機能を、発注側のフィードバックを得ながら開発できるため、柔軟に仕様を変更しやすく、品質を高めやすい点です。一方で、その柔軟性の高さは、開発期間の延長や開発コストの肥大化につながりやすいことに注意が必要です。そのため、スパイラル型を採用する場合は、開発を始める前に修正依頼ができる範囲をある程度決めておくことが重要になります。

  

 V字型


V字型は、要検定、基本設計、詳細設計、プログラミングの各工程に対して、運用テスト、システムテスト、結合テスト、単体テストと各テストで検証していくモデルのことです。各工程で実施すべきテストが予め明確なため、チェックすべき内容も決まりやすく、品質向上につながりやすいと言えます。実施するテストの順番は、プログラミングに対する単体テスト、詳細設計に対する結合テスト、基本設計に対するシステムテスト、要件定義に対する運用テストの順です。開発の詳細部分である実装フェーズに近い工程から開発の全体像に向けてチェックを行っていくことになるため、手戻りや大幅な修正のリスクを抑えることにつながる点もメリットです。

 

プロトタイプ型

 

プロトタイプ型は、本格的な開発を進める前にシステムの試作品(プロトタイプ)を作り、発注者に評価してもらった上でシステムの設計を行うモデルです。試作品というたたき台があることで、どこをどのように改善したいのか、発注側も具体的な指示が出すことができるでしょう。特に、発注者側が開発に慣れていない場合などには、机上で使用や機能を詰めていくよりも、開発側とも認識を合わせやすいと言えます。

一方で、あくまでも「試作品」がベースになるため、実際の開発を進めてみないと分からない部分や、実装が難しいこともあります。また、慣れていない発注側でも要望を出しやすい分、要望が多くなりがちでスケジュール遅延につながることも散見されます。

 

 システム開発のライフサイクル まとめ

システム開発ライフサイクル(SDLC)の6つの過程と、7つの開発手法を解説してきました。各開発手法の特徴やメリット、デメリットを鑑みて、自社が開発したいシステムに最適なモデルを採用する参考にしてみてください。

 

アプリ・システム開発するなら実績豊富な当社へ

デザインワン・ジャパンは、アプリ・システム開発の実績が豊富なベトナムのダナンとフエに開発拠点を持つ日本の東証スタンダード上場企業です。御社とベトナムの開発チームとの間にはブリッジSEをアサインするため、まるで日本のIT企業に発注しているかのようにコミュニケーションもスムーズ。コストと品質のバランスが取れた開発が特徴です。IT人材のリソース確保にお悩みの企業様や、国内企業に委託するよりも費用を抑えたい企業様におすすめです。

 

システム開発のライフサイクルには複数のモデルがあるため、御社で実施したいプロジェクトには「どのモデルで進めるべきか分からない」という方もいらっしゃるでしょう。ご相談やお見積りやこちらから、お気軽にお問い合わせください。






contact お気軽にご連絡下さい。