システム開発ライフサイクルとは？開発の流れや開発モデルなども紹介

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

システム開発ライフサイクルとは、システム開発の企画〜廃止まで、一連の流れを人間の人生になぞらえて表現したものです。システム開発ライフサイクルは英語で「Systems Development Life Cycle」と表記されるため、SDLCとも呼ばれています。

システム開発ライフサイクルは、システム開発の企画立案〜実際の運用に至るまで、一連の経緯をわかりやすく読み取れる点が特徴です。システム運用後も安定稼働を実現するため、定期的なメンテナンスやアップデートの実施もサイクルの一部に含まれます。

システム開発ライフサイクルの流れ

どの開発モデルを選択した場合でも、システム開発ライフサイクルでは以下の手順に沿って作業を進めていきます。

自社開発や外注利用を問わず、システム開発ライフサイクルでもっとも重要な工程は要件定義です。ユーザー側と開発側で同じイメージを共有できていない場合、本来の意図にそぐわないシステムになる可能性が高まります。

要件定義

要件定義とは、ユーザーからの要望を開発側の視点でまとめる作業です。開発の進め方やどのようなシステムを開発するかを明確化し、決まった内容を要件定義書にまとめます。要件定義書に盛り込むべき主な項目を以下の表にまとめました。

システム開発ライフサイクルのなかでもっとも重要な工程は要件定義です。要望を開発担当者やシステム開発会社に正確に伝えられない場合、大規模な手戻りや修正作業を招く可能性が高まります。

最悪の場合は本来の意図と異なるシステムが完成し、修正作業にともなう追加費用の発生は避けられないでしょう。無駄な費用の支払いを避けるには、要件定義前の要求定義で自社の要望を正確に伝える姿勢が重要です。

設計

要件定義で決めた内容を実際にシステムの設計に反映していく工程です。設計は基本設計と詳細設計の2種類に分けられます。基本設計はシステムに実装する機能や操作画面など、ユーザーインターフェースに関する設計です。基本設計が終わると、以下の文書が成果物として納品されます。

詳細設計は機能の実装方法やデータベースの構築方法など、システム内部に関する設計です。詳細設計後に納品される主な成果物を以下にまとめました。

システム開発を担当するエンジニア向けの内容になるため、ユーザー側は完全に内容を理解しなくても問題ありません。

開発

設計で決めた内容をもとにプログラミング言語を使って、ソースコードを記述していく作業です。システムの規模や開発者のスキルに応じて、JavaやPython、Rubyなど、開発言語を選択します。

コードを書く際には、コードエディタやソースコード管理ツールなど、プログラミングツールを使うのが一般的です。

テスト

実環境で運用するまでに4段階のテストを実施するのが一般的です。テストの概要を以下の表にまとめました。

テストは仕様どおりにシステムが稼働するか、バグやコードの記述ミスがないかなどを発見する重要な工程です。テスト段階で不具合の原因を可能な限り排除できると、運用後のトラブルを最小限に抑えられます。

リリース

受け入れテストで問題がなければ、実環境に移行してシステムを運用します。従業員の不安を軽減するため、運用前にシステムの操作説明書やマニュアルを配布しておきましょう。事前にマニュアルを配布しておくことで、新たなシステムへの早期適応が期待できます。

メンテナンス

導入したシステムが安定して稼働しているか、稼働状況や不具合の有無を監視します。サーバーやネットワーク機器などが監視対象です。必要に応じてメンテナンスやアップデートを実施し、ユーザビリティ向上やセキュリティ対策の強化に努めます。

システムの寿命まで運用とメンテナンスを繰り返し、寿命にあわせてシステムの移行に向けた準備を進める流れです。

システム開発のモデルは6種類

システム開発は以下6つのモデルに分類できます。

各モデルの特徴を理解してから、システム開発に取り組むことが重要です。

ウォーターフォールモデル

ウォーターフォールモデルは要件定義〜リリースまで、1つひとつの工程を完結させてから次の工程へ移行するタイプです。進捗状況をすぐに把握できるため、スケジュール管理や予算管理を進めやすくなります。

技術要件が明確なシステム、多くの人員管理が必要な大規模システム開発に適したタイプといえるでしょう。

反面、前の工程への手戻りは想定しておらず、開発途中でのスムーズな仕様変更や不具合対応は望めません。仮に仕様変更が必要になった場合、開発工程が進んでいるほど修正工数が増大し、追加費用の発生や納期遅延を招きます。

プロトタイプモデル

プロトタイプモデルは試作機の動作検証や顧客のフィードバックをもとに、次の工程へ進むかを判断するタイプです。開発側はユーザー側とイメージを共有しやすく、認識のズレにともなう手戻りや大規模な修正作業を避けられます。

開発途中での仕様変更を前提としており、要件定義の段階では細部まで作り込みをしません。開発の初期段階から試作機の作成や動作検証をおこなうため、ユーザーは完成後のイメージを具体的に描けます。

ユーザー側がシステム開発の経験に乏しい場合、機能性重視のシステム開発を検討している場合に適したタイプです。反面、試作機の作成回数が増えるほど、開発費用の高騰や開発期間の長期化を招きます。

アジャイルモデル

アジャイルモデルは設計〜テストまでを機能単位で繰り返し、システムの完成度を高めていくタイプです。設計〜テストまでの流れをイテレーション（反復）と呼び、テストを終えた機能から順次リリースされます。イテレーションの期間は1週間〜4週間です。

アジャイルモデルはプロトタイプモデルと同様、要件定義の段階では細部まで詰めません。ユーザーとコミュニケーションを重ねながら仕様を固めていくため、仕様変更や機能追加にも柔軟に対応できます。開発期間の短縮とシステムの完成度向上を両立できる点が魅力です。

反面、開発の方向性がブレやすく、全体の進捗状況把握やスケジュール管理の徹底が求められます。

スパイラルモデル

スパイラルモデルはシステムを機能単位に分割し、重要度の高い機能から開発を進めていくタイプです。設計〜テストまでを機能単位で繰り返し、テストの際には試作品を活用します。テストが終わったら次の機能開発に進むため、リリースはしません。

動作検証やユーザーからのフィードバックをもとに、試作品の完成度を高めていく点が特徴です。スパイラルモデルは他のモデルと同様に仕様変更を前提としており、要件定義では細部に至るまで作り込みはしません。

顧客からの要望へ柔軟に対応できるだけではなく、システムの完成度も高められます。反面、試作品の作成回数が増えると開発費が高騰するため、注意が必要です。

ハイブリッドモデル

ハイブリッドモデルは、ウォーターフォールとアジャイルの特徴を組みあわせたタイプです。要件がある程度固まっている箇所をウォーターフォール、仕様変更の可能性がある箇所にはアジャイルモデルを導入します。

たとえば、要件定義やテスト、リリースはウォーターフォール、設計や開発はアジャイルモデルを適用するかたちです。工程単位で2つのモデルを使い分けることで、開発期間の短縮と仕様変更への柔軟な対応につなげられます。

仮に手戻りが発生したとしても、大規模な修正作業が発生する心配はありません。反面、開発に携わるメンバーが目的や特徴を理解していないと、作業が進めにくくなります。

V字モデル

V字モデルとは開発工程とテスト工程の各作業をリンクさせ、効率的に動作検証を進めるモデルです。たとえば、要件定義の内容をシステムテストで確認し、設計内容は単体テストと総合テストで検証を進めていきます。

これまでのモデルと異なり、システムに実装する機能〜全体像にかけて、テストの段階が進んでいくかたちです。実装段階からテストを実施するため、手戻りや修正工数を大幅に削減できます。

V字モデルはウォーターフォールモデルとの組みあわせが一般的です。アジャイルモデルとの併用も可能ですが、ユーザーが積極的に参加しない限り、品質の担保は難しいでしょう。

システム開発ライフサイクルで意識すべき4つのポイント

システム開発の前に以下4つのポイントを把握しておきましょう。

ポイントの内容を1つひとつみていきます。

ポイント1. システムの寿命を知る

業務システムは永遠に利用できるわけではありません。たとえば、業務の中核を担う基幹システムの寿命は14年といわれています。

寿命を過ぎたシステムを使い続けると、業務効率低下やランニングコストの増大など、さまざまなリスクに見舞われます。システム導入に携わった担当者が退職や人事異動によって不在となる前に、ノウハウの伝承も必要です。

仮にシステムに精通した人材が不在の場合、トラブルへの早期対応が難しく、事業運営に大きな影響を及ぼします。大規模なトラブルへ発展する前に、新システムへ移行する準備を進めなければなりません。

ポイント2. RFPを作成する

RFP（Request for Proposal）とは、自社からの要望をまとめた提案依頼書です。RFPに記載する主な項目を以下にまとめました。

RFPを作成するメリットは、外注先と認識を正確に共有できる点です。RFPの提出によって、どのような機能を実装したシステムをどの程度の予算で開発したいか、明確に伝えられます。自社の要望を書面に残せるため、伝達ミスによる手戻りや修正作業の発生を心配する必要もありません。

RFPの完成度が高まるほど、各企業から提示される提案レベルや開発費用を正確に把握できます。RFPの作成に割く時間を十分に確保しましょう。

ポイント3. 開発の優先順位を整理しておく

自社開発または外注利用を問わず、システム開発での優先順位を明確化しておくことが重要です。システムの開発規模やノウハウの有無、希望期限などによって、選択すべきモデルは異なります。

たとえば、システムの開発経験に乏しい場合は、プロトタイプモデルの選択がおすすめです。開発の初期段階から試作機を通じて機能性を確認できるため、完成後のイメージを描きやすくなります。試作機の改良を通じて、システムの完成度を高められる点も魅力です。

早期に新しいシステムを完成させたい場合は、アジャイルモデルやハイブリッドモデルを選択しましょう。上記のように優先事項を明確化すると、選択すべき開発モデルは自然と絞られます。

ポイント4. 外注先の選定にビジネスマッチングを活用する

システム開発に精通した人材が社内にいない場合、システム開発会社を活用するのが無難な選択です。IT人材は慢性的な人手不足に陥っており、優秀な人材を短期間で採用できる保証はありません。

外注先を探す際は、ビジネスマッチングを活用しましょう。ビジネスマッチングとは「仕事の発注先を探す企業」と「顧客を探す企業」をつなぐサイトです。必要な情報を入力すると、条件に合致した企業が提示されます。

得意分野や実績など、企業の特徴がコンパクトにまとめられている点も魅力です。本業が忙しい方も必要な情報を効率的に収集できるでしょう。「比較ビズ」を利用すると、1,000社の中から自社の条件を満たす企業を探せます。

まとめ

今回の記事では以下の3点に関して述べてきました。

システム開発ライフサイクルは要件定義〜リリースまで、システムが完成に至るまでの一連の流れを指します。自社でシステムを開発する場合、プログラミングやセキュリティなど、専門知識を持つ人材が不可欠です。

専門知識を持つ人材が不在の場合、システム開発会社を活用しましょう。「比較ビズ」を利用すると、必要事項を入力する2分程度で条件にあったシステム開発会社を探し出せます。システム開発の外注先を探している方は、利用してみてください。

監修者のコメント

株式会社エン・ＰＣサービス

代表　齋藤完次

株式会社エン・ＰＣサービス代表。信州大学工学部情報工学科卒。卒業後富士通ＦＩＰ（現富士通）に就職。某コンビニエンスをクライアントに基幹系、情報分析系、会計・ＳＦＡなどのシステム提案、構築、運用サポートを行う。他、ネットワーク構築やサーバー構築も行うなど、フルスタックエンジニアとして活躍。その後、広く多くの人にサービス提供を行いたいという想いから独立し、主にウェブ技術を用いて自社サービス構築と運営を行う。同時に日本のビジネスを底上げするという想いから、中小スタートアップ企業を対象にＩＴシステム開発事業を、企画立案からマーケティング、運営サポートまでワンストップ対応している。

詳しく見る

システム開発にあたってSDLCの観点とその手法を知っておくことはとても大切です。発注者もSDLCの考える知る事は大切です。

記事では要求定義の重要性を特に説いていますが、要求事項を提示する必要性が生じたときに、開発モデルとどの工程にいるかを理解する事で、要求事項を取り込む事でどれだけのリスクやコストが生じるかを判断できるようになるからです。

とはいえ一朝一夕にこの考えを獲得出来るものでもありません。記事最後にあるように、外注先の選定にビジネスマッチングを活用してもよし。ＩＴコンサル、ＩＴ相談役といった外部専門家を迎える事で、開発事業者と対等に物言える関係性を作る事も有用でしょう。

執筆者

比較ビズ編集部では、BtoB向けに様々な業種の発注に役立つ情報を発信。「発注先の選び方を知りたい」「外注する際の費用相場を知りたい」といった疑問を編集部のメンバーが分かりやすく解説しています。