ソフトウェア開発、SDLC（Software Development Life Cycle）とは？

ソフトウェア開発とは？

ソフトウェア開発とは、簡単に言えば、プログラマーがコンピュータ・プログラムを設計・開発し、配備するために行うプロセス全般のことを指します。開発チームがソフトウェアを作成するために行う一連の手順は、ソフトウェア開発ライフサイクル（SDLC）と総称され、技術要件とビジネス要件を満たす製品を構築して提供するために必要なプログラミングとコンピュータサイエンスに関連するその他の活動で構成されています。

SDLCは、ソフトウェア開発者やエンジニアが、ソフトウェアアプリケーションを開発し提供（本稼働）するために、プロジェクト全体を通じて使用できるフレームワークを提供します。具体的には、SDLCの明確に定義されたステージに従うことで、ソフトウェアプロジェクトのチームメンバー全員が、プロジェクトの責任、目標、およびタイムラインについて共通の理解を持つことができ、最終的にチームが期待通りの時間に高品質のソフトウェアを提供することを可能にします。

SDLCの各ステージは、一般的にソフトウェア開発ライフサイクルの次のステップを実行するために必要な成果物をもたらします。ここで、ソフトウェア開発の集団作業は、ソフトウェア開発者とソフトウェアエンジニアだけが行う作業に限定されるものではありません。他のIT専門家も開発プロセスに関わることがあります。

ソフトウェア開発手順に含まれる段階

上記のようにSDLCは、ソフトウェア開発者・技術者がソフトウェアを開発する際に、最初から最後まで行わなければならない必須ステップです。原則として、SDLCのプロセスには6段階があります。

• 要求分析
• 設計
• ソフトウェア開発
• テストと実行 品質保証
• 最終コードのデプロイメント
• メンテナンス

それでは、各ステップについて詳しく見ていきましょう。

1 - 要件分析

プログラマーやコーダーがソフトウェアアプリケーションを構築するために、最初のコードを書き始める前に、ユーザーや他のプロジェクトの利害関係者が、何を求めているかを理解するための要件を収集する必要があります。ここで、ソフトウェア開発チームのメンバーとプロジェクトの利害関係者は、製品の技術仕様とユーザー要件に合意します。

この段階で、プロジェクトスコープの概要と詳細は、ソフトウェア設計者、開発者、エンジニア、QA/ソフトウェアテスター、ビジネスアナリスト、UI/UXデザイナーなど、すべての開発チームメンバーの責任とともに確立され文書化し、共通のプロジェクト目標がタイムリーに達成できるようにします。

またプロジェクトマネージャーと開発者が、開発方法論（ウォーターフォール、アジャイルなど）を最終決定する段階でもあります。この要求分析段階の成果物は、「ソフトウェア要求仕様書」にまとめられ、チームで開発プロセス全体を通じて参照できるようにします。

2 - ソフトウェア設計

これはソフトウェア開発プロセスの第2段階です。前の段階で確立されたユーザー要求と仕様から、ソフトウェア設計者と開発者は、ソフトウェアを作成するために必要な全体的なアーキテクチャをマッピングします。予算、スケジュール、選択した技術スタック、チーム構成など、さまざまな側面が考慮されます。

このステップの成果物として、開発者、テスター、プログラマーは、アーキテクチャ設計、システム要件、バックエンド、フロントエンドの表現などを明記したテンプレートを提供し、チームが開発プロセス全体を通じてフォローできるようにします。

3 - コーディング/インプリメンテーション

設計仕様書（DSD）を作成した後、前段階の仕様に基づき、コードの記述やソフトウェアの開発に着手します。簡単に言うと、この段階では、フロントエンド開発者がインターフェイス（エンドユーザーがソフトウェアアプリケーションを使用する際に目にするすべてのもの）を構築し、バックエンド開発者がサーバー側のプログラミングに取り組み、データベース管理者がデータベース要件を処理します。この段階で開発者は通常、自分のコードと他の人のコードをレビューします。

普通この段階の開発プロセスは、全体の中で最も多くの時間とリソースを必要とします。

4 - QAとソフトウェアテスト。

QAプロセスは、この段階で実施されます。プロジェクトによっては、開発QA（コードレビュー、ユニットテストを含む）と、機能テスト、統合テスト、回帰テストなどのソフトウェアテスト活動、さらに非機能テストやテスト自動化などが含まれます。テスターとソフトウェアQAの主な目標は、事前に定義されたシナリオと仕様に従って、製品が意図したとおりに動作することを検証し、保証することです。

テスターとソフトウェアQAは、テストプロセスで検出された製品の欠陥やバグを開発者に報告し、開発者は必要に応じてバグを修正する措置をとります。

5 - デプロイメント段階

テスト段階を経て、最終的にソフトウェアにエラーや欠陥がなければ、開発者は製品を本番環境に配備し、顧客に提供します。この段階では、ベータテストを実施し、実際の顧客やエンドユーザーからのフィードバックを得ることで、ソフトウェアが大規模かつ高いレベルで動作することを確認します。何か問題が発生したときのために、ロールバックプランを含む適切な計画を事前に準備する必要があります。

6 - メンテナンス

製品版が稼動し、顧客が高品質のソフトウェアを使い始めたら、次のステップは製品の維持と保守です。エンドユーザーが遭遇した問題を管理して解決、バグ修正とシステムパフォーマンスの改善を含む、展開後のソフトウェアアプリケーションの修正と更新を行います。

ソフトウェア開発ライフサイクル（SDLC）プロセスモデル

一般的に、ソフトウェア開発において、これらの開発プロセスの段階は変わりませんが、ソフトウェア開発チームは、各段階での機能をさまざまな方法で実装することが出来ます。これらはSDLCの方法論と呼ばれる。それぞれの方法論は、異なる階層を使用し、異なる開発プロセスを実行します。

今日、いくつかのタイプのSDLCモデルが使用されていますが、最も人気のあるモデルなので知っておくべきSDLC方法論の主な8種類だけです。それでも、すべての開発モデルの共通の目標は、エンジニアが高品質なソフトウェアを効率的に作成するのを助けます。

一般的に、特定のプロジェクトで選択されるソフトウェア開発モデルは、必要な専門知識のレベル、ビジネス要件、タイムライン、および予算のような要因に依存します。したがって、十分な情報に基づいた決定を下すために、ソフトウェアエンジニアはSDLCのすべての方法論を理解するよう努めるべきです。

ここでは、一般的なSDLCモデルの概要を説明します。

図の左下の象限にあるSDLCモデルは、順次フローを取るため、実装、使用、管理が容易であり、図の上にあるほど、将来的にプロセスを変更する必要がある場合に柔軟に成ります。

チャートの左側の方法論は、顧客関与が低いことを示し、さらに右側に進むと、顧客はより協力的になり、ソフトウェア開発ライフサイクルの異なるステージで、より一層顧客を関与させるようになります。

SDLCモデルの種類

このようにSDLCの方法論には、ウォーターフォール、Vモデル、インクリメンタルモデル、スパイラルモデル、RUP、アジャイルスクラム、XP、カンバンの8つのタイプがあります。

ウォーターフォール

ウォーターフォールモデルでは、分析、設計、コーディング/実装、テスト、配備、保守というすべての開発段階を経て、それぞれを完了させます。各フェーズには特定の納品物があり、厳密に文書化されます。前の段階が完了する前に次の段階を開始することはできません。

したがって、例えば開発/コーディングの段階でソフトウェアの要件を再評価することはできません。また、最後の配備段階が完了するまで、ソフトウェアの確認やテストができないので、プロジェクトのリスクが高くなり、予測できないプロジェクトの結果につながります。テストは通常急がされ、エラーの修正にはコストがかかります。

このモデルは、以下のような場合に使用出来ます。 

• 中小規模の単純なプロジェクト（小規模企業のWebサイト開発）で、要件が明確に定義されて、変更されない場合。
• より厳密な管理、予測可能な予算、スケジュールを必要とするプロジェクトは、政府プロジェクトのようなものです。
• 医療系プロジェクトなど、様々なルールや規制を遵守するプロジェクト。
• 有名な技術スタックやツールを使用するプロジェクト。

Vモデル（検証・妥当性確認モデル）

V-モデルは、各ステージに対応するテストランを持つ線形モデルです。ワークフローの構成は、優れた品質管理を意味しますが、同時にVモデルは最も費用と時間のかかるモデルの1つとなっています。

また要求仕様、コード、アーキテクチャのエラーなどの欠陥は早期に発見できますが、開発プロセス中の変更は依然として高価で困難です。ウォーターフォールモデルと同様に、すべての要件は最初から収集され要約されているため、変更することはできません。

このモデルは、以下のような場合に使用出来ます。

• 医療用ソフトウェアやフライト管理ソフトウェアなど、エラーやダウンタイムが許されないプロジェクト。

反復モデル、インクリメンタルモデル

インクリメンタルモデルに基づくSDLCは、複数のイテレーションに分割されます。新しいソフトウェアモジュールは各反復で追加され、以前に追加されたモジュールには全く、あるいはほとんど変更が加えられません。開発サイクルは逐次的または並列的に行うことが出来ます。並行開発は納品スピードにプラスになりますが、複数の反復開発サイクルはプロジェクトを長期化させ、コスト高になる可能性があります。



反復開発では、ソフトウェアは反復、開発、進化するたびに変化します。各反復は前の反復の上に構築されるため、ソフトウェアの設計は一貫しています。

ソフトウェアは部分的に分散されるため、プロジェクト当初から完全な仕様書を作成する必要はなく、開発過程で微妙な要求の変更が発生することもあります。しかし、要件を完全に変更することはできません。特にインクリメンタル開発におけるシステム設計では、分散したソフトウェアの追加統合が問題になることがあるため、必要な条件を最初から定義しておくことが必要であります。

特にインクリメンタル開発におけるシステム設計では、分散ソフトウェアの追加統合が問題になることがあるため、必要な条件を最初に定義する必要があります。また、開発プロセス中に細かい要件を変更する必要がある場合もあり、SDLCモデルは顧客の参加を必要とすることもあります。

このモデルは、以下のような場合に使用出来ます。

• マイクロサービスやWebサービスを使って基本機能を迅速に提供する必要がある大規模で長期にわたる開発プロジェクト。 

スパイラルモデル

このモデルは、包括的なリスクアセスメントに重点を置いています。したがって、Spiralモデルを最大限に活用するためには、リスクアセスメントを実施するための確かな経験を持つ人材に参加してもらう必要があります。スパイラルサイクルは通常6ヶ月程度で、包括的なプランニング、リスク分析、プロトタイピング、既納部品のレビューという4つの主要な活動から始まります。スパイラルサイクルを繰り返すことで、プロジェクトの期間が大幅に延長されます。

お客様の関与が多いモデルです。各サイクルの探索とレビューのフェーズに参加出来ます。開発段階では、お客様からの修正は認められません。

このモデルは、次のような場合に使用出来ます。

• ビジネスニーズやイノベーションが不明確なプロジェクト、または野心的すぎるプロジェクト
• 大規模かつ複雑なプロジェクト
• 研究開発（R&D）、または新しいサービスや製品の導入。

RUP（ラショナル・ユニファイド・プロセス）

RUP（Rational Unified Process）は、線形フレームワークと反復型フレームワークを組み合わせたものです。このモデルでは、ソフトウェア開発プロセスを「インセプション」「エラボレーション」「コンストラクション」「コンバージョン」の4つのフェーズに分割しています。最初のフェーズを除いて、各ステップは通常、複数の反復を行う。開発プロセスのすべての基本作業（要求、設計など）は、強度は異なるものの、RUPの4つの段階にわたって並行して実行される。

このモデルは、柔軟であると同時に安定したソリューションの構築に役立ちますが、アジャイルグループのモデルほど迅速かつ適応的ではありません（後ほど詳しく説明します）。顧客エンゲージメント、ドキュメントの強度、再現性の長さは、プロジェクトのニーズによって変わる可能性があります。

このモデルは、次のような場合に使用出来ます。

• 大規模でリスクの高いプロジェクト、ユースケースに基づく開発、高品質なソフトウェアの高速開発。

アジャイル方法論 

次の3つのSDLCの方法論は、アジャイル方法論の傘の下にあります。PMIが実施したプロジェクトマネジメント実務者を対象とした世界最高峰の調査「Pulse of the Profession 2017」では、70％の組織がITプロジェクトにアジャイル手法を導入していることが明らかになりました。簡単に言うと、アジャイルアプローチは、より良い改善のための反復開発、絶え間ないコミュニケーション、そして早期の顧客フィードバックに重点を置いています。

アジャイルの各反復プロセスは、通常、完全なソフトウェアバージョンを提供するために数週間かかります。このグループのモデルは、詳細なソフトウェア文書（詳細な要求仕様、詳細なアーキテクチャ記述）よりも、アプリケーションとソフトウェアのテスト活動の機能部分を提供することに重点を置いています。

そのため、迅速な開発が可能ですが、ソフトウェアの詳細な記述がないため問題点の発見に時間を要し、保守フェーズが複雑化します。

アジャイルモデルのもう一つの特徴は、チーム間でも顧客との間でも緊密に連携することにあります。ステークホルダーは、開発の進捗状況を確認し、将来のイテレーションにおけるタスクの優先順位を再評価することで、ROIを高め、ビジネスゴールとユーザーニーズの整合性を確認することが出来ます。

したがってアジャイルモデルでは、頻繁なリリースと継続的なソフトウェアの改良が期待出来ます。

要約すると、アジャイルモデルがもたらすメリットは、迅速なアップデート、機能追加、簡単な修正、変更を可能にし、これらの特性はユーザーのニーズを満たすアプリケーションを提供するのに役立ちます。.

アジャイルの唯一の欠点は、ソフトウェアの詳細な文書がないため、問題を特定することが難しく、結果としてプロジェクトに必要な予算、スケジュール、人的資源を見積もることが困難であることです。

アジャイルモデルは、以下のような場合に利用出来ます。

• エンドユーザーの早期フィードバックが不可欠なスタートアップ企業。
• カスタム開発段階の中規模プロジェクトで、ビジネス要件が詳細なソフトウェア要件に変換できない場合。
• 大規模なプロジェクトで、機能的に小さなパーツに分割しやすく、イテレーションごとに徐々に開発できるもの。

アジャイルとウォーターフォールの違いについては、こちらの記事をご覧ください。

スクラム

最も人気のあるアジャイルモデルの1つです。スプリント/イテレーションは通常、終了までに2～4週間かかります。そのため、事前に綿密な計画と評価を行う必要があります。スプリントの運用が確認されると、変更は許されません。

XP(エクストリーム・プログラミング)

エクストリーム・プログラミング（XP）では、1～2週間での定期的な繰り返しが行われます。チームが類似のソフトウェアを扱ったことがない場合は、イテレーション開始後の変更も許容されます。この柔軟性が、品質の高いソフトウェアの提供を著しく複雑化させるのです。この問題を軽減するために、XPでは、ペアプログラミング、テスト指向の開発とテストの自動化、継続的インテグレーション（CI）、小規模なリリース、シンプルなソフトウェア設計、コーディング標準に準拠したレギュレーションが必要とされます。

カンバン

カンバンSDLCに関しては、明白な反復がないことが主要な特徴であります。使用する場合は、1日のスプリントと呼ばれる極めて短い期間にとどめます。計画を可視化することに重点が置かれます。チームはカンバンボードというツールを使って、すべてのプロジェクト活動、数量、担当者、進捗状況を提示する事ができます。

このような透明性は、最も緊急性の高いタスクをより正確に見積もるのに役立ちます。

さらに、このモデルには独立した計画段階がないため、いつでも新しい変更要件を導入することが出来ます。また、かんばんは顧客とのコミュニケーションを頻繁に行うことが出来ます。これにより、顧客はいつでも仕事の結果を確認することができますし、プロジェクトチームと毎日ミーティングを行うことも可能なのです。

その特性から、カンバンモデルは、ほとんどのソフトウェアサポートと進化プロジェクトで使用されています。

まとめ

どのタイプのSDLCメソドロジが良いとは言えません。それぞれのメソドロジは、あなたがキャリアの中で遭遇するそれぞれのプロジェクトに対してユニークな価値を提供します。したがって、正しいものを見つけることが重要です。ソフトウェア開発ライフサイクル手法に関するより多くのアドバイスが必要な場合は、いつでもTP&Pテクノロジーにご連絡ください。

私たちは、アジア地域でトップのソフトウェア開発企業であることを誇りに思っています。様々なプログラミング言語に精通し、豊富な開発経験を持つ専門家集団が、お客様のプロジェクトに適した各モデルについて、的確なアドバイスを提供します。

また、ソフトウェア開発のアウトソーシング料金についてお悩みの方は、オフショアサービスの費用とガイドラインをご覧いただき、お客様が支払うことになる平均的な費用を念頭に置いてください。

Contact Us