SDLCとは、ソフトウェアを計画から運用・廃棄まで一連の段階として管理する枠組みで、Software Development Life Cycle（ソフトウェア開発ライフサイクル）の頭文字です。単なる工程の並びではなく、各段階の入力と出力、品質ゲート、そして反復の回し方までを含む考え方を指します。この記事では、SDLCの定義と標準フェーズ、その土台になっている国際規格が2026年に改訂された中身、ウォーターフォールやアジャイルといった主要モデルの違い、DevOpsやCIパイプラインとの関係、案件に応じたモデルの選び方、そしてSDLCが形骸化する条件までを、実装と運用の現場視点で整理します。品質ゲートをGitHub Actionsの設定ファイルで固定する例も置きました。
まとめ：SDLCの工程・モデル選定とDevOps連携の判断
SDLCは「どの順で作るか」ではなく「各段階で何を確定させ、次に何を渡すか」を決める設計です。要件定義で仕様を、設計で構造を、テストで品質を確定させ、確定できないまま下流へ流さない——この段階ごとの締めが、手戻りコストを抑える芯になります。
モデルは一つではありません。要件が固い規制案件ならウォーターフォール、要件が動く新規事業ならアジャイル、大規模で失敗リスクが高いならスパイラルというように、案件特性で選び分けます。選んだモデルの上にDevOpsとCIを重ね、テスト・デプロイ・運用を継続的なループとして回す形が、いまの実装現場では主流になりました。
土台の規格も動いています。ソフトウェアライフサイクルプロセスの国際規格 ISO/IEC/IEEE 12207 は2026年版へ改訂され、2017年版は置き換え済みの扱いになりました。反復開発とアジャイル実践に寄せた改訂であり、「SDLC＝ウォーターフォール」という古い等式は規格側からも崩れています。
一方で、SDLCは導入すれば効くわけではありません。ドキュメントを揃えることが目的化した瞬間、フェーズは儀式に変わります。本記事では、モデル選定の判断基準と、形骸化を避けるための運用条件までを言い切ります。
SDLCとは何か：定義と国際規格12207が定めるプロセスの範囲
まず言葉の範囲をそろえます。SDLCは、開発を単発の作業ではなく、始まりと終わりを持つ循環として捉える枠組みです。個々の工程名より、「段階を区切り、各段階に責任と成果物を割り当てる」という発想そのものが本体だと考えてください。
SDLCの定義と、ソフトウェア開発をライフサイクルとして捉える意味
SDLCは、ソフトウェアの構想から運用・保守、そして廃棄までを一連の段階として体系化した枠組みです。ライフサイクルという語を使う理由は、開発が「作って終わり」ではないからです。リリース後も改修と運用が続き、その知見は次の計画へ戻っていきます。この循環を意識すると、設計段階で運用のしやすさを織り込む、といった前倒しの判断がしやすくなります。工程を発注者の目線で成果物と工数から見たい場合はシステム開発の工程と7フェーズの成果物の記事が全体像を担う役割です。本記事は実装者向けにライフサイクルの回し方へ寄せて掘り下げます。
12207が2026年版へ改訂された経緯と、JIS X 0160との版ずれ
SDLCという言葉の後ろには実在の国際規格があります。ISO/IEC/IEEE 12207（Systems and software engineering — Software life cycle processes）です。長く参照されてきた12207-2017は2017年11月15日発行で、IEEE SAの規格ページ上ではすでに Superseded（後継あり）の状態になっています。後継の12207-2026はIEEE SA標準委員会が2026年2月12日に承認し、2026年4月15日に発行された Active な規格で、2017年版を置き換えると明記されています。改訂の方向は反復開発とアジャイル実践への接近、そして技術管理とソフトウェア変更の統制強化です。
ここで実務が引っかかるのが国内規格との差です。IPAの国際規格SLCPの解説ページによれば、ソフトウェアライフサイクルプロセスのJISは JIS X 0160:2021 が最新で、対応する国際規格は12207の2017年版です。システムライフサイクル側の JIS X 0170:2025 は ISO/IEC/IEEE 15288:2023 に対応します。つまり「JIS X 0160 準拠」と契約書に書いた場合、参照しているのは2017年版世代のプロセス定義になります。規格名だけで合意せず、版と発行年まで書き下しておくのが安全です。
国内向けの補助線として参照できる資料が共通フレーム2013です。IPAは同書を、現行の国際規格SLCPで割愛された「ソフトウェア固有プロセス」を解説する資料として、国内では継続して参照されると位置づけています。規格本文を買う前に、日本語で工程の粒度を揃えたいときの入口として使えます。
SDLCの標準7フェーズ（計画・要件定義・設計・実装・テスト・移行・運用）
フェーズの区切り方は流派で数が変わりますが、実務では次の7段階に整理すると過不足がありません。各段階には固有の成果物があり、それが次段階の入力になります。
- 計画：目的・体制・概算コストと期間を定める
- 要件定義：機能・非機能の要求を仕様に落とす
- 設計：アーキテクチャと詳細仕様を決める
- 実装：仕様に沿ってコードを書く
- テスト：単体から結合・システムまで検証する
- 移行・デプロイ：本番環境へ展開する
- 運用・保守：監視・障害対応・改修を続ける
段階の順は絶対ではありません。後述するモデルによって、この7つを一度で通すか、小さく何度も回すかが変わります。共通するのは「各段階の出口で何を確定させたか」を明示する点です。テスト段階をさらに単体・結合・総合へ割る切り方はシステム開発のテスト工程の種類と流れで分解しています。
SDLCを回す目的：品質・コスト・進捗を予測可能にするための狙い
SDLCを敷く狙いは、開発の進み方を予測可能な状態にすることです。段階を区切らないまま作ると、仕様の抜けが実装後に見つかり、修正費用が跳ね上がります。ここで「要件段階の欠陥修正コストを1とすると、リリース後は数十倍から百倍」という数字がよく引かれます。ただしこの倍率は1970〜80年代のBoehmらの見積もりに由来する経験則で、いまの開発形態でそのまま再現される保証はありません。数字を根拠に社内を説得するなら、出典と時代背景まで添えるべきです。
国内の実測に当たりたい場合は、IPAのソフトウェア開発分析データ集2022が使えます。2022年9月26日公開で、累計5,546プロジェクトの定量データのうち直近6年の1,479件を分析対象にしています。同資料はIPAの事業終了に伴い今後の発行予定がないと明記されており、2022年版が最終版です。母集団の年次が固定される点を踏まえたうえで、自社の実績値と突き合わせる基準線として扱ってください。
SDLCの主要モデル：ウォーターフォールとアジャイルの違いと選択
SDLCは一つの手順ではなく、フェーズの回し方が異なる複数のモデルを持ちます。同じ7段階でも、一度で通すのか、短く反復するのかで性格が変わります。代表的な4系統を押さえておけば、案件ごとの判断がぶれません。
ウォーターフォール型モデルの特徴と、向く案件・つまずきやすい場面
ウォーターフォールは、上流から下流へ後戻りせず順に進めるモデルです。要件定義を固めきってから設計、設計を終えてから実装、と段階を明確に区切ります。強みは、進捗と成果物を管理しやすいという点です。金融や公共のように仕様と監査要件が先に固まる案件では、この予見性が効きます。弱点は、後半で要件変更が入ると手戻りが大きいこと。作り始めてから仕様が動く新規サービスでは、この硬さがつまずきの原因になります。工程とV字モデルの詳細はウォーターフォール開発の工程とV字モデルで扱っています。
アジャイル・イテレーティブ型モデルの特徴とスプリント反復の進め方
アジャイルは、機能を小さく区切って短い期間で作り、動くものを見ながら方向を調整するモデルです。ここで押さえておきたいのは、原典が工程を規定していない点にあります。アジャイルソフトウェア開発宣言は2001年に公開された4つの価値だけの短い文書で、スプリントの長さも役割も定めていません。期間の目安を与えているのはスクラム側です。スクラムガイドの2020年11月版はスプリントを「一貫性を生むための1か月以内の固定長イベント」と定義しており、実務でよく言われる1〜4週間という幅はここから来ています。要件が固まりきらない段階でも着手でき、市場やユーザーの反応を早く取り込めるのが強みです。反面、全体のゴールや契約範囲が曖昧なまま走ると、スコープが際限なく膨らみます。受託開発でアジャイルを採るなら、優先度づけと変更管理のルールを先に握っておく必要があります。
スパイラル・V字モデルなどリスクと検証を重視する派生モデル群
ウォーターフォールとアジャイルの中間や派生として、いくつかのモデルが生まれました。スパイラルは、リスク分析を軸に小さなサイクルを繰り返し、危険度の高い部分から試作して不確実性を潰していくモデルです。大規模で失敗の代償が大きい案件に向きます。V字モデルは、ウォーターフォールの各設計段階に対応するテスト段階を一対一で結びつけ、要件定義には受け入れテスト、詳細設計には単体テストを紐づけます。検証の抜けを防ぎたい品質保証重視の案件で採られる形です。どちらも「リスクと検証をどこで担保するか」に答えを出すための派生だと捉えてください。
主要SDLCモデルの比較：適合案件・変更への強さ・リリース頻度
4系統を実務の判断軸で並べると、選び分けの勘所が見えます。数字ではなく「変更にどれだけ耐えるか」「いつ品質を確定させるか」で性格が分かれます。
| モデル | 適合する案件 | 変更への強さ | リリース頻度 |
|---|---|---|---|
| ウォーターフォール | 要件が固い・規制案件 | 弱い | 一括・低頻度 |
| アジャイル | 要件が動く新規事業 | 強い | 反復・高頻度 |
| スパイラル | 大規模・高リスク | 中程度 | 段階的 |
| V字 | 品質保証・検証重視 | 弱い | 一括・低頻度 |
表はあくまで初期の当たりをつけるためのものです。実際には一つの案件でモデルを混ぜることもあります。基盤はウォーターフォールで固め、UI周りだけ反復で回す、といった折衷は珍しくありません。
SDLCとDevOps・CIの関係：品質ゲートをコードで固定する手順
モデルを選んだら、次はライフサイクルを「継続的に回す」層を重ねます。ここで登場するのがDevOpsとCIパイプラインです。SDLCが段階の設計図だとすれば、DevOpsはその図面を高速で何周も回すためのエンジンにあたります。パイプラインと導入判断の全体像はCI/CDの仕組みと導入判断で整理しています。
GitHub Actionsでフェーズ順の品質ゲートを組む設定ファイル例
「品質ゲートを置く」を口頭の運用ルールで終わらせると、締切前に必ず外されます。SDLCのフェーズ順序をワークフローの依存関係として書き下し、前段が落ちたら後段が動かない状態をリポジトリに固定してください。GitHub Actionsならneedsでジョブの前後関係を宣言でき、記法は公式のワークフロー構文リファレンスにまとまっています。次の設定は、単体テスト→結合テスト→本番デプロイという3段を、そのままジョブの依存で表現した最小構成です。
name: sdlc-quality-gate
on:
push:
branches: [ main ]
pull_request:
jobs:
unit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: 22
- run: npm ci
- run: npm run test:unit -- --coverage
integration:
needs: unit
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: docker compose up -d db
- run: npm ci
- run: npm run test:integration
deploy:
needs: [ unit, integration ]
if: github.ref == 'refs/heads/main'
environment: production
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: ./scripts/deploy.sh
アクションの版は固定しておきます。GitHub APIで実測した2026年9月10日時点の最新リリースは actions/checkout が v7.0.1（2026年7月20日）、actions/setup-node が v7.0.0（2026年7月14日）でした。deployジョブに付けたenvironmentは、GitHubのEnvironment保護ルールと結びつく指定で、承認者を設定すれば移行フェーズの人的ゲートもここへ寄せられます。ブランチ運用そのものの決め方はブランチ戦略とコミット規約の決め方を先に固めてから合わせてください。ツール自体の選定で迷う場合はCI/CDツールの無料枠と料金比較が判断材料です。
SDLCにセキュリティを組み込むDevSecOpsとSSDFの実践区分
従来のSDLCでは、セキュリティ検査をリリース直前にまとめて実施しがちでした。この置き方だと、後半で重大な脆弱性が見つかったときの手戻りが大きくなります。DevSecOpsは、セキュリティを各フェーズに前倒しで組み込み、要件・設計・実装・テストのそれぞれで検査を回す考え方です。実装段階での依存ライブラリ検査、CIでの静的解析、といった形で分散させます。
「どこに何を置くか」を自前で決めきれないときは、公的な枠組みを写経するのが早道です。NISTは2022年2月にSP 800-218（Secure Software Development Framework v1.1）を公開し、セキュアな開発実践を組織の準備・ソフトウェアの保護・脆弱性への対応といった区分で整理しました。特定のツールや手法を指定せず成果で書かれているため、ウォーターフォールにもアジャイルにも重ねられます。DevOpsとの違いや導入の判断はDevSecOpsのライフサイクル設計と導入判断で詳しく整理しています。
テスト工程の自動化をCIパイプラインへ載せる設計と判断の基準
SDLCを短く速く回すうえで、テストの自動化こそエンジン部分です。コードを push するたびにCIが単体テストと結合テストを走らせ、通らなければ先へ進めない運用にすると、品質ゲートが人手を介さず機能します。どのレベルのテストをどれだけ持つかは、修正時に既存機能が壊れていないかを確かめるリグレッションテストの範囲選定と自動化の考え方が土台です。画面操作までを通しで検証したい場合はE2Eテストの目的とツール選定を、実装フェーズの品質担保にはコードレビューの観点と運用設計を組み合わせます。すべてを自動化するのではなく、繰り返し実行する価値の高い検証から載せるのが現実的な順序です。
SDLCモデルの選定基準と、形骸化させないための運用設計の判断
ここからは立場を明確にします。SDLCは、モデルを選んだだけでも、ドキュメントを揃えただけでも機能しません。案件に合わないモデルを選べば足かせになり、目的を見失ったフェーズは儀式に堕ちます。選定と運用の判断基準を具体的に示します。
要件の固まり方からSDLCモデルを選ぶ判断基準と見極めの観点
モデル選びの第一の軸は、要件がどれだけ固まっているかです。契約や規制で仕様が先に確定し、後から動く余地が小さい案件は、ウォーターフォールやV字が向きます。逆に、市場の反応を見ながら仕様を詰める新規事業では、要件を固めきる前提のモデルは合いません。第二の軸は変更頻度、第三は失敗したときの代償の大きさです。人命や大金が絡む大規模案件では、リスクを先に潰すスパイラルの慎重さが効きます。「流行だからアジャイル」という選び方は避けるべきです。監査で全工程の証跡を求められる案件にアジャイルを無理に当てると、かえって管理コストが膨らみます。
ドキュメント倒れなどSDLCが形骸化するアンチパターンと回避策
SDLCが空回りする典型は三つあります。第一にドキュメント倒れ。設計書を作ること自体が目的化し、コードと乖離した書類だけが残る状態です。回避策は、成果物を「次段階が実際に使う分だけ」に絞ることに尽きます。第二にフェーズの飛ばし。テストを省いてリリースし、運用フェーズで火を噴くパターンで、品質ゲートを人の裁量で外せる運用にした時点で起こります。前節のワークフロー例のように、ゲートをリポジトリの設定へ移すのが確実な歯止めです。第三はモデルと現場の不一致。ウォーターフォールを掲げながら実態は行き当たりばったり、という二重帳簿です。三つに共通するのは、フェーズの形だけ真似て目的を捨てている点にあります。段階を区切る狙いは手戻りを減らすことだ、という原点に立ち返るのが唯一の回避策です。
SDLCの効果を工数比率と欠陥密度で測る指標と改善順の決め方
SDLCを敷いた効果は、感想ではなく数字で見ます。最小構成は三つで足ります。工程別の工数比率、工程別の欠陥検出件数、そしてリリース後に見つかった欠陥の件数です。最初の二つはチケット管理とCIのテスト結果から取れますし、三つ目は障害票を数えるだけで出ます。IPAの分析データ集2022のような公開データを基準線に置き、自社の値がどちらへ振れているかを見る使い方が現実的です。
改善順は、欠陥がどの工程で作り込まれ、どの工程で見つかったかの差で決めます。要件定義で作り込んだ欠陥が総合テストで見つかっているなら、手を入れるべきはテストではなく要件のレビューです。逆に、実装で作り込んだ欠陥がリリース後に出ているなら、単体テストとコードレビューの網が粗い証拠になります。運用フェーズの指標設計まで踏み込むなら、エラーバジェットで信頼性と開発速度の綱引きを扱うSREとDevOpsの違いの考え方が接続します。数字を月次で並べる仕組みを先に作り、指標が動かない工程には手を入れない、と決めておくと改善が拡散しません。
受託開発と保守フェーズでSDLCの運用を定着させる体制の設計
SDLCは、体制と運用ルールが伴って初めて回るものです。とくに外部へ開発を委託した成果物や、担当者が入れ替わりながら長く保守するシステムでは、段階ごとの品質ゲートを誰がどう守るかを決めておかないと形骸化しやすくなります。社内にライフサイクルを設計できる人材がいない、既存システムの保守で改修のたびに品質がぶれる、といった場面では、外部の伴走が歯止めです。一創ではシステム保守運用・内製化支援として、既存システムの改修プロセスの整備や、CIとテストを組み込んだ運用体制づくりを支援しています。内製化を進める過程で、SDLCの回し方をチームへ定着させる伴走まで含みます。
よくある質問
SDLCの理解と実務でつまずきやすい点を、5つの質問に絞って整理します。
SDLCの読み方と何の略かを教えてください？
SDLCは「エスディーエルシー」と読み、Software Development Life Cycle の頭文字です。日本語では「ソフトウェア開発ライフサイクル」と訳されます。ソフトウェアの計画から運用・廃棄までを一連の段階として管理する枠組みを指す言葉で、特定のツール名や製品名ではありません。対応する国際規格は ISO/IEC/IEEE 12207 です。
SDLCとアジャイル開発の違いは何ですか？
両者は同じ階層の対立概念ではありません。SDLCはライフサイクル全体を管理する上位の枠組みで、アジャイルはそのSDLCを回すための一つのモデルです。ウォーターフォールもアジャイルも、どちらもSDLCという枠組みの中に収まるアプローチだと捉えると整理できます。2026年版の12207が反復開発とアジャイル実践へ寄せて改訂された点も、この関係を裏づけます。
SDLCとSDLの違いは何ですか？
SDLとして略される語はいくつかありますが、開発文脈で紛らわしいのはSecurity Development Lifecycle（セキュリティ開発ライフサイクル）です。こちらはセキュリティ確保に特化したプロセスで、開発全体を扱うSDLCとは目的の広さが異なります。セキュリティを開発全体へ組み込む発想は、DevSecOpsやNISTのSSDFに近い考え方だと理解してください。
SDLCとDevOpsはどう関係しますか？
SDLCが開発の段階を定義する設計図だとすれば、DevOpsはそのライフサイクルを高速に何周も回すための文化と仕組みです。両者は競合しません。SDLCで段階と品質ゲートを設計し、DevOpsとCIパイプラインでその段階を自動化して継続的に回す、という重ね方が実務的です。ゲートはワークフローの依存関係として書き下しておくと外れません。
SDLCの規格は何を見ればよいですか？
国際規格は ISO/IEC/IEEE 12207 で、2026年4月15日発行の2026年版が現行、2017年11月15日発行の2017年版は置き換え済みです。国内のJISは JIS X 0160:2021 が最新で、対応する国際規格は12207の2017年版になります。日本語で工程の粒度を確認したい場合は、IPAの共通フレーム2013が「ソフトウェア固有プロセス」の解説として使えます。
関連記事
- システム開発の工程とは：発注者目線での7フェーズの成果物と工数比率の全体像
- ウォーターフォール開発とは：SDLCの代表モデルの工程とV字モデルの詳細
- CI/CDとは：SDLCを継続的に回すパイプラインの仕組みと導入判断
- DevSecOpsとは：SDLCの各段階にセキュリティを組み込むライフサイクル設計
- リグレッションテストとは：テストフェーズで回帰不具合を抑える範囲選定と自動化
