2024.12.03
ソフトウェア開発の流れを円環として捉えるフレームワークとして「SDLC（ソフトウェア開発ライフサイクル）」というものがあります。
「SDLC」という言葉を聞いたことがあっても、概要についてはよく分からないという方も多いのではないでしょうか。
そこで本記事では、ソフトウェア開発に携わる方なら理解しておきたい「SDLC」概要や、プロセス・考え方について解説していきます。
- もくじ
1. SDLCとは？概要と主な目的
まずはSDLCの概要や主な目的、進行プロセスについて解説していきます。
1-1 SDLCとは
SDLC（Software Development Life Cycle：ソフトウェア開発ライフサイクル）とは、ソフトウェア開発の開始から終了までの流れを、ひと回りの円環として捉える考え方や手法を指します。
本来の「ライフサイクル」は、生物の誕生から衰退までの過程をひと回りの円環として捉えるものです。
SDLCは、このライフサイクルをソフトウェア開発に当てはめ、体系化したものといえます。なお、SDLCは「Systems Development Life Cycle：システム開発ライフサイクル」と解釈される場合もありますが、意味は大きく変わりません。
1-2 SDLCの主な目的
SDLCの主な目的は、ソフトウェア開発の進め方を最適化し、QCD（品質・コスト・納期）を向上させることです。
SDLCでは、ソフトウェア開発のライフサイクルを複数のプロセスに分割します。各プロセスには、実施すべき作業や完成すべき成果物、完了基準などが定義されています。これらはソフトウェア開発に関わる各組織が長年の経験を経て、体系化・最適化したものです。
各プロセスに沿ってソフトウェア開発を進めていけば、品質の担保・コスト（工数）の削減・納期の短縮が可能となります。
1-3 開発モデルによって進行プロセスは変わる
SDLCには、いくつかの開発モデルが存在し、モデルによってプロセスの進め方は変わってきます。
そのためSDLCを学ぶ際には、主要な開発モデルについても理解を深めることが大切です。
たとえば、「ウォーターフォールモデル」では1つのサイクルを直線的に進めますが、「アジャイル」では機能ごとに短期間のサイクルを設けて進めます。
それぞれの開発モデルにはメリット・デメリットが存在するため、ソフトウェアの種類やプロジェクトの状況に合わせた選定が必要です。なお、主要な開発モデルについて詳しくは後述します。
2. SDLCにおける主なプロセス
SDLCにおける主なプロセスは、次の7つです。ただし、SDLCにおけるプロセスの分割方法も、開発モデルにより異なる場合があります。
2-1 計画・要求定義
まずは、ソフトウェア開発を始めるためにプロジェクトを計画し、「要求定義」を行います。プロジェクトの計画とは、目的や予算、人員、スケジュールなどを明確にし、全体の方針を固めるプロセスのことです。
また、ソフトウェア開発は大前提として、ソフトウェアを求める顧客やエンドユーザーの要求から始まります。そのため初期段階で、ソフトウェアに何が要求されているかを明確に定義するプロセスも必要です。これを「要求定義」と呼びます。
要求定義の進め方についての記事はこちらをご覧ください。
2-2 要件定義
要求定義の内容を踏まえて、「要件定義」を行います。要件定義とは、ソフトウェアに求められる機能や性能などを明確に定義するプロセスのことです。
顧客やエンドユーザーの要求を満たすために、ソフトウェアに何が必要なのか、どうあるべきかを検討します。
要件定義の内容が顧客の認識と食い違っている場合は、要求を満たすソフトウェアは開発できません。そのため、要件定義の内容は顧客に共有し、フィードバックを受ける必要があります。
要件定義についてはこちらの記事をご覧ください。
2-3 設計
要件定義の内容を踏まえて、「設計」を行います。設計とは、ソフトウェアをどのように実現するかを具体的に決めるプロセスのことです。
要件を満たすソフトウェアを開発するために、プログラム要素の構成や処理の流れ、データ構造などを具体化します。
設計は、次プロセスでのプログラム作成を意識して実施することが求められます。技術的に実現できない設計では、次のプロセスで手戻りとなるでしょう。また、設計によって速度性能やメンテナンス性などが変わる場合もあるため、慎重な検討が必要です。
2-4 実装・構築
要件定義や設計に沿って「実装」を行います。実装とは、ソフトウェアの機能を実現するためにプログラムを作成するプロセスのことです。
「プログラミング言語」と呼ばれる言語を1つ以上用い、言語のルールに従ってプログラムを記述します。
また、実装した各プログラム要素を統合・連携させて、1つのソフトウェアを構築します。たとえばWebアプリケーションの場合、画面を制御するプログラムや、サーバーでユーザーの要求を処理するプログラムの統合が必要です。
2-5 テスト
構築したソフトウェアに対して、「テスト」を行います。テストとは、ソフトウェアを実際に動かし、要件や設計どおりに振る舞うか検証するプロセスのことです。検証の手順や期待値などを「テストケース」として定義し、それに沿って動作を確認します。
要件や設計に合致しない振る舞いが判明した場合は、原因調査やプログラムの修正、再テストが必要です。テストで問題を見逃した場合、市場に不具合が流出してしまいます。そのため、テストはソフトウェア品質を左右する重要なプロセスといえます。
テスト実行についてはこちらの記事をご覧ください。
2-6 リリース・デプロイ
テストで品質を保証できたソフトウェアをリリース（顧客やエンドユーザーに提供）します。リリースの手段は、ソフトウェアの種類や開発形態によってさまざまです。
たとえばパッケージソフトウェアの場合、製品を販売店に流通させるための手配が必要です。顧客から開発を請け負った場合は、顧客へのソフトウェア納品が事実上のリリースとなります。
またWebアプリケーションの場合は、本番環境のサーバーにプログラムを配置し、ユーザーが利用できるようにするプロセスが必要です。これを「デプロイ」と呼びます。
2-7 運用・保守・廃棄
ソフトウェアのリリースやデプロイ後は、「運用」や「保守」を継続的に行っていきます。
運用はソフトウェアを安定稼働させていくプロセス、保守はソフトウェアの稼働におけるトラブルを防止・解決するためのプロセスです。
具体的には、サーバーの監視やデータのバックアップ、ソフトウェアの改良・アップデートなどを行います。システム障害や不具合報告といったトラブルが発生した場合は、迅速に対応することが大切です。
また、ソフトウェアが使われなくなった場合は「廃棄」を行うことで、そのライフサイクルを終わらせます。具体的には、当該ソフトウェアの提供やサーバーの稼働を停止し、サービスやサポートの終了をステークホルダーに通知します。
ソフトウェア保守の必要性についてはこちらの記事をご覧ください。
3. SDLCで採用される代表的な開発モデル・フレームワーク
SDLCで採用される代表的な開発モデル・フレームワークは、次の2つです。それぞれの特徴やメリット・デメリットについて解説します。
3-1 アジャイル開発
「アジャイル」は、機能ごとに設けた短期間のサイクルを繰り返していく開発モデルです。要件定義・設計・実装・テストといったプロセスを各機能に対して繰り返し実施し、ソフトウェアの完成度を高めていきます。
短いスパンでソフトウェアをリリースできるため、細かいフィードバックを受けながら柔軟に開発を進められるのがメリットです。一方で、前述したプロセスが不明確になりやすく、開発の方針もぶれやすいデメリットがあります。
アジャイルについて詳しくは、この記事を参考にしてください。
3-2 ウォーターフォールモデル
「ウォーターフォールモデル」は、流れ落ちる水のように一方通行のプロセスを進めていく開発モデルです。ソフトウェア全体で1つの大きなサイクルを構成し、前のプロセスをしっかり完了させたうえで次のプロセスに進みます。
全機能のプロセスが1つのサイクルに集約されているため、プロジェクトの計画や管理がしやすいのがメリットです。ただし1プロセスあたりの規模が大きい分、前プロセスの不備が後から判明すると、手戻りが大きくなるデメリットもあります。
ウォーターフォールモデルについて詳しくは、この記事を参考にしてください。
4. SDLCに関連する有力な考え方・アプローチ
SDLCに関連する有力な考え方・アプローチとして、次の2つを知っておきましょう。これらは、SDLCにおける組織体制やプロセスの進め方に関わるものです。
4-1 DevOps
「DevOps」は、Development（開発）とOperations（運用）を組み合わせた言葉です。開発プロセスと運用プロセスの連携を図ることで、効率を高める考え方を指します。
例としては、開発チームが完成させたソフトウェアを、自動的に運用環境へデプロイする仕組み作りが挙げられます。また、開発チームと運用チームを統合し、組織体制そのものを刷新するケースもあります。
SDLCにDevOpsを取り入れると、運用で判明した不具合の修正や、開発後のリリース作業などの効率化が期待できます。
DevOpsについて詳しくは、この記事を参考にしてください。
4-2 シフトレフト／シフトライト
「シフトレフト」および「シフトライト」は、昨今注目されているアプローチです。
「シフトレフト」とは、テストプロセスを本来よりも早期に実施するアプローチを指します。
SDLCの終盤に位置するテストでバグが多発することによる、手戻りの増大を防ぐためのアプローチです。開発文書のレビューを強化したり、実装の途中で簡易テストを実施したりすることで、バグの早期検出や混入の未然防止を図ります。
「シフトライト」とは、テストプロセスを本来よりも後の段階にまで拡張するアプローチを指します。リリース後に利用者からフィードバックを受けることを前提とし、継続的にソフトウェアを改良していくアプローチです。
前述のアジャイルやDevOpsと相性が良く、柔軟に顧客やエンドユーザーのニーズに応えられます。
5. 最適なSDLCを実現するためにはテストプロセスの効率化・自動化が重要
SDLCにおけるテストプロセスは、それまでの全工数のうち30％を超えるケースも少なくありません。
最適なSDLCを実現するためには、工数のウェイトが大きいテストプロセスの効率化・自動化が重要となります。
特に、ソフトウェアの変更時に既存の機能が損なわれていないか検証する「回帰テスト」は、自動化の効果を高めやすいポイントです。昨今増えているアジャイル開発では、短期間のサイクルのたびに回帰テストが発生します。またウォーターフォールモデルも、プロセスの途中で顧客の要求が変わり、回帰テストが発生する場合もあります。
回帰テスト（リグレッションテスト）についてはこちらの記事をご覧ください。
繰り返し発生する回帰テストを自動化するうえでは、テスト自動化ツール「T-DASH」が有力な選択肢です。
T-DASHであれば、日本語で書いたテストケースからスクリプトを生成し、自動テストを行えます。プログラミングの知識が不要なため扱いやすく、回帰テストのたびにプログラムを調整せずに済みます。SDLCのテストを効率化したい場合は、ぜひT-DASHをご活用ください。
まとめ
SDLC（Software Development Life Cycle：ソフトウェア開発ライフサイクル）とは、ソフトウェア開発の開始から終了までの流れを、ひと回りの円環として捉える考え方や手法のことです。
SDLCでは、ソフトウェア開発の進め方を最適化し、QCD（品質・コスト・納期）を向上させることを目的としており、進行プロセスは開発モデルによって変わってきます。
最適なSDLCを実現するためには、アジャイルやDevOpsなど、関連する手法や考え方に関する理解を深めることが大切です。
また、テストプロセスの効率化・自動化にも取り組んでいきましょう。
