ソフトウェア開発ライフサイクルにおける7つのステージ：プロジェクトにとって最適な開発モデルを選ぶために

ソフトウェア開発プロセスは、7つの個別ステージに分けることができる。本稿では、ソフトウェア開発ライフサイクルの各ステージにアプローチする方法を説明する。

[Chris Tozzi，TechTarget]

　ソフトウェア開発ライフサイクル（SDLC）は、複数のステージに明確に分けられる。ソフトウェア開発に着手するに当たって、これらのステージを理解することが最初の重要なステップになる。ステージの考え方は、ソフトウェアプロジェクトの具体化から展開、保守に至るまでの、詳細かつ反復可能なガイドラインとして活用できる。

　SDLCのステージを理解するには、各ステージで実施すること、各ステージが重要な理由、次のステージに進む条件をしっかりと把握する必要がある。

SDLCの7つのステージ

　SDLCのステージ数については意見が分かれる部分がある。SDLCの主要ステージは5つか6つしかないという意見もある。各ステージにはさまざまな呼称が存在するが、本稿では、SDLCを7つの基本ステージに分けて解説する。

　7つのステージは以下の通り。

ステージ1．計画

　SDLCの最初のステージは計画だ。ビジネス要件に基づいてアプリケーションに必要な機能の開発について基本計画を立案することを目的としている。

　開発チームは、このステージで大まかな計画を立てる。特定の機能を実装する方法や使用するプログラミング言語についてはあまり細かくは取り決めない。

　このステージでは、アプリケーション機能の基本的な目標を設定し、その機能が対処するビジネス課題を概説する。保留すべき非現実的な目標もこのステージで特定する。例えば、リソースが足りないため、アプリケーションでは全てのビジネスニーズに対処できないとする。最終的に実装を諦める可能性のある機能を実装しようとして時間を無駄にするよりも、このステージでそうした機能について話し合う必要がある。

　計画ステージでは、技術目標と業務の優先順位を一致させることを重視する。そのため、開発者には業務関係者と効果的にコミュニケーションを取る能力が不可欠になる。

　アプリケーションの目的とその目的の実現に必要な機能を開発チームが明確に理解すれば、計画ステージは完了だ。

ステージ2．分析

　SDLCの分析ステージでは、大まかな計画と目標を実行可能なアイデアに変える。そのため、前のステージで考案した計画を技術的に分析し、実装するのに最適な方法を判断する。

　例えば、アプリケーションのセキュリティを優先することを目標にするのであれば、この分析ステージで目標に最適なアプリケーションアーキテクチャとプログラミング言語を決める。また、実装予定の機能を調べ、分析に基づいて各機能を個別のマイクロサービスとして実装するか、モノリシックなアーキテクチャを使用するかも決定する。

　分析ステージでは、開発作業を着手できる技術計画を立てることが最終目標だ。コードを実装する方法を1行ずつ詳しく記述する必要はない。しかし、アプリケーションの構築時に使用するツールやプロセスは正確に把握しておく必要がある。

ステージ3．設計

　設計ステージでは、アプリケーションの動作と、ユーザーの立場からどのように見えるかを決めることに重点を置く。例えば、アプリケーションがGUI（グラフィカルユーザーインタフェース）を備えるのであれば、このステージでインタフェースのレイアウトを決める。また、アプリケーションを使用する際にユーザーがアカウントを登録する必要があるかどうかも決める。登録する必要があれば、管理者アカウントや特権を持たないアカウントなど、ユーザー別にさまざまな種類のアカウントを用意するかどうかも検討する。

　設計ステージは、分析ステージで確立したアプリケーションの技術仕様に基づいて設計する。実際には、SDLCの分析ステージと設計ステージは1つのステージとして扱われる場合もある。ただし、分析ステージでは技術要件に重点を置き、設計ステージではUX（ユーザーエクスペリエンス）に重点を置くことから、2つのステージに分けるべきだと考えられる。

　ユーザーがアプリケーションを操作する方法を明確に理解した時点で設計ステージが完了する。

ステージ4．実装

　実装ステージ（開発ステージやコーディングステージと呼ばれることもある）では、実際にコードを記述する。記述するコードが複雑でコード量も多ければ、実装ステージはSDLCの中で最も時間がかかるステージになる可能性がある。だが、特にローコード／ノーコード開発や人工知能（AI）支援の開発といった手法を使えば実装時間は比較的短くなる可能性がある。

　いずれにせよ、開発者が実装中にコードを記述するに当たって、コードを管理する明確なプロセスを確立することが重要だ。特に複数人の開発者が同時に作業する場合はその重要度が高まる。継続的インテグレーション（CI）サーバを使用するチームは多い。新たに記述するコードを共有コードベースにマージするCIサーバは、異なる開発者が記述したコード同士が競合しないようにするのに役立つ。

　さらに、全てのコードの一貫性を確保するため、コーディングスタイルやコーディング規約についての想定事項を明確に定める必要がある。そうすれば、自身が記述していないコードをメンテナンスしたり更新したりする能力が向上する。オリジナルのコードを記述した開発者が退職しても数年間はアプリケーションを使用する予定であれば、これが重要な検討事項になる。

　全機能を実現するために必要なコードをアプリケーションに全て記述したら、実装ステージが完了する。ただし、この後のテストステージで実施されるテストの結果によっては、再度このステージに戻ってコードの調整が必要になる場合があることに注意する。

ステージ5．テスト

　コードの記述が終わると、そのコードをテストする準備が整う。ソフトウェアのテストでは、下記のような観点でアプリケーションがどの程度目標を満たしているかを評価する。

• パフォーマンス：アプリケーションの応答性を評価する
• 負荷：需要の変動に応じたアプリケーションの実行能力を評価する
• セキュリティ：アプリケーションに潜むセキュリティの脆弱（ぜいじゃく）性を評価する
• ユーザビリティ：許容可能なUXをアプリケーションが提供できることを評価する

　テストステージでは、SDLCの最初の3つのステージで確立した目標に沿ったテストを設計する。テストの設計を終えたら、テストを実施し、想定を満たさない結果を見極める。アプリケーションが1つでもテストに合格しなければ、前のステージに戻って、コードの一部を修正して問題を解決してから、再度テストステージを実行しなければならない場合もある。

　テストは手作業でも実行できる。例えば、パフォーマンスを手作業でテストし、特定のリクエストに対するアプリケーションの応答速度を確認しても構わない。ただし、大規模に効率良くテストするのであれば、オープンソースの「Selenium」や「Cucumber」などのテスト自動化フレームワークを使って、可能な限り多くのテストを自動化する。

　アプリケーションが全てのテストに合格したら、テストステージは完了する。

ステージ6．デプロイメント

　デプロイメントステージでは、アプリケーションを運用環境に移し、エンドユーザーがアクセスできるようにする。

　SaaSモデルを使ってアプリケーションをホストする場合は、アプリケーションをホスティングの運用環境にデプロイし、アプリケーションへの全てのリクエストがその環境に送られるように、ネットワークファイアウォールやロードバランサーを構成する。

　アプリケーションをユーザーのデバイスでローカルに運用する場合は、デプロイメントステージでは、アプリケーションをパッケージ化し、ユーザーがアプリケーションを検索しダウンロードできるアプリストアなどのチャネルを通じてパッケージをユーザーに配布する。

　バグが潜むアプリケーションを運用環境に送り込むリスクを減らすため、ブルーグリーンデプロイメント（blue／green deployment）やカナリアリリースなどの手法を検討する必要がある。ブルーグリーンデプロイメントはアプリケーションの新しいバージョンを段階的かつ体系的に切り替えるのに役立つ手法だ。カナリアリリースはユーザーベース全体に影響が及ばないよう、バグを特定する目的で一部のユーザーに先行してデプロイする手法を指す。

　デプロイメントのリスクを減らすにはコンテナ化アプリケーションも役に立つ。コンテナは、デプロイ先を問わず、ほぼ同一のホスティング環境を提供する。つまり、テストステージでアプリケーションがコンテナ内で正常に動作すれば、デプロイメント時にも同様に正しく運用されると想定できる。

　アプリケーションを対象とするエンドユーザー全てにリリースしたら、デプロイメントステージは完了する。

ステージ7．メンテナンス

　SDLCの最後のステージはメンテナンスで、アプリケーションを継続的に監視し、運用開始後に発生する問題を特定することを目標とする。例えば、ある特定種類のリクエストでエラーが発生するのであれば、開発チームはその問題を解決できるように記録する。

　また、メンテナンスステージで収集するフィードバックは、アプリケーションの将来のアップデート指針として役に立つ。例えば、特定機能のパフォーマンスが最適ではないと判明した場合は、次回のアップデートでその機能を徹底的に見直す必要があると結論付けることができる。そういう意味では、メンテナンスステージはSDLCを反復プロセスに変えるのに役立つ。反復プロセスになれば、SDLCの毎回の繰り返しで独自のステージを経ることになるため、アプリケーションのリリースがアプリケーションの新しいアップデートの原動力となる。

　SDLCの他のステージとは異なり、メンテナンスステージには必ずしも明確な終わりはない。このステージは、ユーザーがアプリケーションの利用を中止するか、アプリケーションが新たなバージョンに切り替わるまで際限なく続く。アプリケーションが新たなバージョンに切り替われば、チームは新たなバージョンのアプリケーションのメンテナンスに移行する。

SDLCの開発モデル

　SDLCの7つのステージは、さまざまなソフトウェア開発手法（実装の指針を提供し、アプリケーションの変更セットを体系化する設計手法）を使って実装できる。

　これまで最も人気があった開発モデルがウオーターフォールモデルで、大掛かりで繰り返しがほとんどない手法でアプリケーションへの変更を送り込む手法だった。現在では、ウオーターフォールモデルとアジャイルソフトウェア開発を使い分けたり、組み合わせたりすることが主流になっている。

　アジャイルでは、アプリケーションのアップデートを細かい単位の作業に分け、短いスプリントを使ってその作業単位を管理することが推奨される。小さく管理しやすい単位でターゲットを設定できるため、開発者の効率が上がる。大掛かりに徹底的に見直された巨大なアプリケーションに対処することなく、アップデートを定期的に受け取ることができるため、ユーザーにとってもメリットがある。

　ウオーターフォールとアジャイルの要素を幾つか組み合わせる手法もある。例えば、段階的開発はアプリケーション開発の目標を個別の単位に分割するという点ではアジャイルに似ているが、ウオーターフォールと同様、アプリケーションの頻繁な変更は必ずしも必要とされない。

　アジャイルやウオーターフォールよりも頻繁に変更する手法もある。例えば、高速アプリケーション開発（RAD：Rapid Application Development）も開発作業を小さなプロジェクトに分割するためアジャイルに似ているが、よりアグレッシブで、一般的には小規模チームに適している。

　プロジェクトにとって最適な開発モデルは、変更を実装する速度やチームの開発者数などの要因に左右される。ウオーターフォールは、迅速なイノベーションが最優先ではないレガシーアプリケーションの新機能の開発に適している一方、アジャイルは、作業を比較的小さく管理しやすいタスクのセットに分割することから、大規模チームの共同作業の効率を高めるのに役立つ。