ソフトウェア開発ライフサイクル（SDLC）：フェーズと方法論

ソフトウェア開発ツールの進化に伴い、より高度で洗練されたソフトウェアを構築する新たな可能性が、かつてないスピードで広がっています。コードを書くことはソフトウェアの提供プロセスの一要素にすぎませんが、計画、管理、コミュニケーションも同じくらい重要です。ここで重要な役割を果たすのが、ソフトウェア開発ライフサイクル（SDLC）です。

SDLCとは？

SDLCはソフトウェア開発ライフサイクルを意味し、小規模な機能から数百万ドル規模のシステム全体まで、あらゆるソフトウェア成果物をリリースするプロセスを表します。SDLCはいくつかのフェーズで構成され、構想から成果物の完成に至るまでに必要な手順を順番に示します。

これらのフェーズの進め方は、プロジェクトの性質や管理方法によって大きく異なります。

SDLCが重要な理由

ソフトウェア開発ライフサイクルは、不確実性の高いことが多いソフトウェアプロジェクトに取り組むための、体系的な枠組みを提供します。プロジェクトの関係者が必要な作業をより深く理解し、早期に問題を特定してコストを抑え、より高品質なソフトウェアを提供できるようになります。

SDLCの7つのフェーズとは？

ソフトウェア開発は単にコードを書くことだと思われがちですが、実際には、プログラミングはその一つにすぎず、提供に至るまでに複数のソフトウェア開発ライフサイクルの段階があります。これらのフェーズには、要件定義、分析、設計、開発、テスト、デプロイ、保守が含まれます。

SDLCの7つのフェーズ

採用するSDLCの方法論によっては、各フェーズが必ずしも直線的に進むとは限りません。以下で個々のフェーズを説明するように、段階が重なったり、順序が変わったりすることもあります。

1. 要件定義

ソフトウェア開発プロジェクトに着手する前に、実際に何を行う必要があるのかを理解することが重要です。開発チームと顧客の間で、最終的な成果物のイメージが異なることは珍しくありません。たとえば、顧客は当初、必要なものを正確に把握できていない場合があります。しかし、プロジェクトが進み、ソフトウェアを試せるようになると、イメージが明確になることがあります。

しかし、問題はその時点ではすでに手遅れだということです。開発チームが十分な検証を行わずに多大な時間と労力をかけてシステムを構築してしまうと、その後、顧客の基準やソリューションに対するビジョンに合わせて変更するには、はるかに大きな労力が必要になります。そのため、顧客の課題を理解し、要件を効果的に引き出すために、最初の段階から緊密に連携することが重要です。

開始段階にとどまらず、ソフトウェア開発ライフサイクルを通じて顧客からフィードバックを得ることで、調整を行い、顧客と開発チームの認識を一致させる必要があります。

2. 分析

要件定義の段階で解決すべき問題を検討した後、開発チームは最適な解決策を決定します。プロジェクトの早い段階で技術的な詳細に踏み込みすぎずに、コストや納期を含め、プロジェクトの実施に必要な工数を見積もる必要があります。ここでの目標は、予算と想定納期に基づいてプロジェクトの実現可能性を評価することです。

3. 設計

プロジェクトが分析フェーズを通過したら、開発チームはソフトウェアの構築計画、つまりソフトウェア開発ライフサイクルの設計フェーズに進みます。ソフトウェアソリューションの作成では、コード以外にも、インフラストラクチャ、システムアーキテクチャ、ユーザーインターフェースなど、考慮すべき要素が数多くあります。必要なすべての機能面・非機能面を網羅できるよう、事前に計画を立てることが重要です。計画なしに必要なコンポーネントを構築すると、コストのかかる書き直しにつながる可能性があります。

4. 開発

ソフトウェアの構築は、単にコードを書くことにとどまらない技術です。コードは通常、サーバーやネットワークを含むインフラストラクチャ、またはマネージドホスティングプラットフォーム（Azure App ServiceやAWS Elastic Beanstalkなど）上で実行されます。

DevOpsは、従来の開発者とインフラエンジニアの分断を解消するベストプラクティスです。インフラがコードと同じくらい重要であることを踏まえ、通常、DevOpsエンジニアは開発チームの一員として、サーバーやネットワークからCI/CDパイプラインまで、幅広い業務を担当します。

5. テスト

ソフトウェアを開発するだけでは不十分です。顧客にソフトウェアを納品する前に、目的に適合しており、重大な問題がないことをチームが確認する必要があります。

• すべての要件を満たしているか？

• 妥当な時間内に処理できるか？

• 使いやすいか？

• 利用が急増しても対応できるよう拡張できるか？

• セキュアなSDLCとアプリケーションセキュリティテストを導入し、一般的な攻撃手法であるSQLインジェクション攻撃などから保護できているか？

こうした問題は、SDLCの後半になると修正コストが大幅に増えるため、早期に発見することが重要です。

6. デプロイ

ソフトウェアが目的に適合していることを確認したら、顧客に引き渡します。プロジェクトの管理方法によって、プロジェクトの最後に一度に引き渡す場合も、開発中の継続的なプロセスの一環として引き渡す場合もあります。その後、実際の環境にソフトウェアをセットアップし、顧客がユーザー受け入れテスト（UAT）を実施します。承認後、本番環境での使用を開始します。

7. 保守

デプロイはソフトウェア提供の最終段階と見なされることが多いものの、実際にはソフトウェアの有用なライフサイクルの始まりにすぎません。バグの修正や新機能の追加のために、ほとんどの場合、見直しが必要です。通常、ソフトウェアの提供元は顧客にサービスレベル契約（SLA）を提示し、ソフトウェアに関する問題への対応方法を定めます。大規模な再開発が必要な場合は、新たなSDLCが必要になることもあります。

SDLCの方法論

現在、ソフトウェアプロジェクトの多くは、アジャイル手法を用いて開発・提供されています。しかし、SDLCを実施する方法はほかにも数多くあります。ウォーターフォールモデルはより伝統的なアプローチですが、時代遅れと見なす人が多くいます。スパイラルモデルなど、広く使われなくなったアプローチもあります。

ウォーターフォール型SDLC

ウォーターフォールモデルは、SDLCの各フェーズが次のフェーズへと進む、厳格で直線的なアプローチです。たとえば、テストフェーズを始める前に、開発フェーズを完了する必要があります。このアプローチは、プロジェクトに関する情報をすべて事前に把握できることを前提としています。しかし、開発中に予期しない問題が発生し、要件が絶えず変化する現実にはそぐわない考え方です。

一方で、要件や成果物の品質に一切妥協できないミッションクリティカルなプロジェクトでは、ウォーターフォール型のアプローチが適している場合もあります。航空・宇宙産業では、ソフトウェアのバグが人命を奪った事例が歴史上いくつもあります。こうした状況では、柔軟に適応してイノベーションを起こすことよりも、完璧さがはるかに重要です。

アジャイル型SDLC

開発の途中であっても要件が突然変わる可能性があるという、ソフトウェアの変化し続ける性質を踏まえ、著名なソフトウェアエンジニアたちがアジャイルソフトウェア開発宣言を発表しました。この宣言をきっかけに、ソフトウェアプロジェクトでは変化に迅速に対応する必要があり、過剰な官僚主義に妨げられてはならないという考え方が広まりました。

これを受けて、スクラム、カンバン、エクストリームプログラミングなど、いわゆるアジャイル手法が数多く生まれました。いずれもアジャイルソフトウェア開発宣言の原則を取り入れ、少しずつ異なる方法でSDLCを実践します。

アジャイル型SDLCでは通常、迅速な反復に重点を置き、成果物を小さく、頻繁にリリースします。これには次のようなメリットがあります。

• 変更コストが小さい：要件が変わっても、1年分ではなく数日分の作業をやり直すだけで済むことがあります。

• SDLCの各フェーズ を並行して進められる：開発チームが次の機能に取り組む間に、QAチームが開発完了済みの機能をテストできます。

• 成果物をより頻繁に提供できる：顧客はプロセスの早い段階から、ソフトウェアが形になる様子を確認できます。また、迅速な軌道修正が可能になり、後になって発覚すると修正に多大なコストがかかる予期せぬ問題を防げます。

SDLCのメリット

以前は、1人の開発者が単独でプロジェクトを完成させることもできたかもしれません。しかし現在では、比較的小規模なアプリケーションの構築にも、プログラミング言語、サードパーティライブラリ、クラウドサービスプロバイダー、コンテナ、SQLおよびNoSQLデータベースなど、さまざまなツールが関わります。そのため、現在ではほとんどのプロジェクトにチームが必要であり、開発者、テスター、プロジェクトマネージャー、DevOpsまたはDevSecOpsエンジニア、顧客など、多くの関係者が関わります。SDLCは、全員の認識を一致させ、共通の目標に向かって取り組むための体系的なアプローチを提供します。

SDLCとSSDLCの違いとは？

セキュアソフトウェア開発ライフサイクル（SSDLC）のフレームワークでは、開発プロセス全体にセキュリティを組み込みます。一方、従来のSDLCフレームワークは、初期計画から本番運用、保守、最終的な廃止に至るまで、アプリケーションを構築するプロセスを定義します。

SnykでセキュアSDLCを実装する

SDLCの各フェーズにセキュリティを組み込み、適切なSDLCのベストプラクティスに従うことが不可欠です。

最適なセキュリティツールの一つであるSnykは、CLIインターフェース、ワンクリックのGitインテグレーション、CI/CDパイプラインの失敗条件としてSnykを追加する方法など、SDLCのさまざまな段階に統合できます。導入方法ごとにメリットがあります。Gitインテグレーションならチームの作業状況をより可視化でき、CIインテグレーションならより安全なデプロイが可能になります。

ニーズに最も適した導入方法を選ぶ際は、開発チームにも参加してもらい、事前に認識を共有しておくことが重要です。また、Snyk CLIインターフェースやIDEプラグインの利用もチームに推奨することをおすすめします。開発プロセスのより早い段階でSnykを統合するほど、発生する可能性のある問題を簡単に修正できます。

セキュアなソフトウェア開発ライフサイクルの実装には、次のツールが役立ちます。

• Snyk Code：コードの脆弱性の特定と修正を支援する、AIを活用した静的アプリケーションセキュリティテスト（SAST）。

• Vulnerability Database：サードパーティパッケージに潜む攻撃の可能性を特定します。

• Snyk Infrastructure as Code (IaC)：TerraformやKubernetesのコードに含まれるセキュリティ問題を見つけて修正します。

• Snyk Containers：コンテナやKubernetesアプリケーションの脆弱性を検出します。

• Snyk Open Source Security Management：アプリケーションのオープンソース依存関係に含まれる脆弱性を検出し、優先順位を付けて修正します。