「SLCPって名前は聞いたことあるけど、結局なに？共通フレームと同じ？」と頭を抱えていませんか。実はこの用語、IPA試験の開発技術分野で繰り返し問われる定番テーマです。この記事では、SLCPの正体・5つのプロセス・過去問の傾向まで、図解と確認テストで一気に整理します。
対象試験と出題頻度
SLCP（ソフトウェアライフサイクルプロセス）は、基本情報技術者・応用情報技術者の午前問題で出題される頻出テーマです。
特に「企画プロセスで定義するものはどれか」「要件定義プロセスで行う作業はどれか」のように、各プロセスの役割を区別させる問題が定番化しています。開発工程全体を体系的に押さえる視点が問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「SLCPと共通フレームって同じものなの？違うものなの？」と混乱しがちです。
SLCP（Software Life Cycle Process）とは、一言で言うと
「ソフトウェアの企画から廃棄までの一連の作業を、発注者と開発者が共通の言葉で語れるように整理した国際規格」
のことです。
イメージとしては、「家を建てるときの工程表テンプレート」です。
家を建てるとき、施主と工務店が「土地探し→設計→基礎工事→上棟→内装→引き渡し→アフターメンテナンス」という共通の工程表を持っていれば、「今どこの段階で」「次に何が必要か」を齟齬なく話せます。
SLCPはこれをソフトウェア開発に当てはめたもので、業界全体の共通言語として機能します。
📊 SLCPの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Software Life Cycle Process |
| 国際規格 | ISO/IEC/IEEE 12207 |
| 日本版 | 共通フレーム（SLCP-JCF）／最新版は共通フレーム2013 |
| 策定・発行 | IPA（情報処理推進機構） |
| 主な目的 | 取得者（発注側）と供給者（開発側）の認識合わせ・取引の透明化 |
解説
ソフトウェア開発のトラブルの多くは、「言った・言わない」「想定していた範囲が違う」といった発注者と開発者のズレから生まれます。
発注者は「ここまでやってくれると思っていた」、開発者は「そんな話は聞いていない」。この溝を埋めるために、誰が・どの工程で・何をやるのかを規格として明文化したものがSLCPです。
国際規格としては ISO/IEC/IEEE 12207（ソフトウェア向け）と ISO/IEC/IEEE 15288（システム向け）があり、IPAはこれを日本の商習慣に合わせて翻訳・拡張した「共通フレーム」を発行しています。
SLCPと共通フレームの関係
SLCPと共通フレームの位置関係
SLCP (Software Life Cycle Process)
ISO/IEC/IEEE 12207 ／ 世界共通の枠組み
共通フレーム (SLCP-JCF)
最新版：共通フレーム2013 ／ 取得者と供給者の共通の物差し
📌 試験での扱い：SLCPと共通フレームは厳密には「規格」と「日本向けガイドライン」で別物だが、午前問題ではほぼ同じ意味で出題される。両者を別物として身構える必要はない。
5つの主要プロセス
共通フレーム2013では多数のプロセスが定義されていますが、試験で問われるのは中心となる5つのプロセスです。それぞれの「目的」と「やること」を区別できるかが得点の分かれ目になります。
| プロセス | 目的 | 主な作業 |
|---|---|---|
| ① 企画 | 経営目的・事業目的を達成するために必要なシステムの全体像を構想する | システム化構想の立案、システム化計画の立案 |
| ② 要件定義 | 利害関係者のニーズを明確化し、システムに求める機能・性能を確定する | 業務要件の定義、機能・非機能要件の整理 |
| ③ 開発 | 要件定義の内容を実際に動くソフトウェアとして実装する | 設計、コーディング、テスト、導入 |
| ④ 運用 | 本番環境でシステムを安定稼働させ、利用者にサービスを提供する | 運用テスト、業務運用、ユーザサポート |
| ⑤ 保守 | 稼働中のシステムを修正・改良し、価値を維持・向上させる | 障害修正、機能改善、性能改善 |
図解：SLCPのライフサイクル
ソフトウェアの一生（5つのプロセスの流れ）
▲ 保守からは必要に応じて企画・要件定義・開発・運用の各プロセスが呼び出される（共通フレーム2013）
プロセス・アクティビティ・タスクの階層
共通フレームでは、作業を3階層で整理します。試験では用語と階層関係がそのまま問われます。
プロセス
役割の観点でまとめた最大単位（例：開発プロセス）
アクティビティ
関連するタスクをまとめたもの（例：システム要件定義）
タスク
具体的な作業の最小単位（例：機能要件の文書化）
💡 SLCPの核心を3行で
・ソフトウェアの企画から廃棄までを共通言語で整理した国際規格（ISO/IEC/IEEE 12207）
・日本版が「共通フレーム（SLCP-JCF）」、最新版は共通フレーム2013
・主要プロセスは「企画→要件定義→開発→運用→保守」の5つ
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
SLCP（共通フレーム）は、FE・APの午前問題でマネジメント系・開発技術の境界領域として安定的に出題されています。出題の中心は「各プロセスで何をするか」を区別させる問題です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H21秋 午前 問49 |
共通フレームの説明として正しいものを選ぶ問題。 | ・「取得者と供給者の双方が、企画～保守の作業内容を共通に参照できる」が正解 ・ISO 9000やCMMIの説明がひっかけ |
| AP H21秋 午前 問65 |
企画プロセスの目的を選ぶ問題。 | ・正解は「経営事業の目的・目標を達成するためのシステム化構想を立案する」 ・要件定義・開発・運用の説明がひっかけ |
| FE H24秋 午前 問66 |
企画プロセスで定義するものを選ぶ問題。 | ・経営戦略に基づくシステム化構想が正解 ・業務手順の詳細（要件定義の領域）がひっかけ |
| AP H23特別 午前 問64 |
要件定義プロセスで行う作業を選ぶ問題。 | ・利害関係者のニーズを定義する作業が正解 ・工数見積（企画）や設計（開発）がひっかけ |
📝 IPA試験での出題パターン
パターン1：「共通フレームの説明を選べ」
4つの説明文から共通フレーム（SLCP）に該当するものを選ぶ形式。「取得者と供給者の共通の物差し」「ソフトウェアのライフサイクル全体を可視化」というキーワードが正解の目印。ISO 9000（品質マネジメント）、CMMI（成熟度モデル）、ITIL（運用ベストプラクティス）の説明がひっかけ選択肢として頻出。
パターン2：「○○プロセスで定義／実施するものを選べ」
企画・要件定義・開発・運用・保守のうち、特定のプロセスで行う作業を選ばせる形式。最頻出は「企画プロセスの目的」と「要件定義プロセスの作業」。「経営目的→企画」「ニーズの明確化→要件定義」「設計・実装→開発」と紐付ければ判別できる。
細かい内訳（プロセス・アクティビティ・タスクのどの階層か等）まで踏み込まれることはほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 共通フレーム（SLCP-JCF）の説明として、最も適切なものはどれでしょうか？
- A. 取得者（発注側）と供給者（開発側）の双方が、ソフトウェアの企画・要件定義・開発・運用・保守といった作業内容を共通に参照できるよう、ライフサイクル全体を体系化したガイドラインである。
- B. 組織の品質マネジメントシステムが満たすべき要求事項を定めた国際規格であり、第三者認証を通じて品質保証体制をアピールするための仕組みである。
- C. ソフトウェア開発組織のプロセス成熟度を5段階のレベルで評価し、継続的な改善活動を導くために用いられるプロセス改善モデルである。
正解と解説を見る
正解：A
解説：
選択肢Aは共通フレーム（SLCP-JCF）の定義そのものです。発注者と開発者が同じ用語で同じ工程を語れるようにすることが最大の目的で、AP H21秋 午前問49でも同じ趣旨の文章が正解として出題されました。
選択肢BはISO 9000シリーズ（品質マネジメントシステム）の説明です。組織の品質保証体制に焦点を当てた規格であり、ソフトウェアのライフサイクル全体を整理するものではありません。選択肢CはCMMI（能力成熟度モデル統合）の説明です。プロセスの成熟度を5段階で評価する改善モデルであり、開発工程そのものを定義するガイドラインとは目的が異なります。
よくある質問（FAQ）
Q. 共通フレームには2007、2013など複数の版があります。試験ではどれを覚えればよいですか？
最新版である「共通フレーム2013」を基本に押さえれば十分です。共通フレーム2013ではSLCP-JCF2007からの主な変更点として、保守プロセスから企画・要件定義・運用も呼び出せることの明記や、超上流工程（企画・要件定義）の強化が行われました。古い問題では2007ベースの記述も残っていますが、5つの主要プロセスの考え方は版が変わっても大きく変わらないため、試験対策としては年版にこだわり過ぎる必要はありません。
Q. SLCPとウォーターフォールモデル・アジャイルなどの開発モデルは何が違いますか？
SLCPは「どんな工程が存在し、それぞれ何をやるか」を定義する枠組みであり、開発モデルは「その工程をどんな順序・粒度で回すか」を決める進め方です。たとえばウォーターフォールは要件定義から保守までを一方向に進める方式、アジャイルは小さな単位で要件定義～開発～運用を繰り返す方式ですが、どちらの場合でもSLCPで定義された各プロセスの要素は登場します。SLCPは開発手法の上位にあるメタな共通言語と捉えてください。
Q. 「取得者」と「供給者」の使い分けがピンと来ません。具体的に誰のことですか？
取得者はシステムを発注して受け取る側、つまりユーザ企業や情報システム部門を指します。供給者はシステムを作って納める側、SIerやソフトウェアベンダがこれにあたります。SLCPは両者の責任範囲を曖昧にしないため、契約・要件定義・受入の各場面で「どちらがいつ何をするか」を共通の用語で取り決めます。RFP（提案依頼書）やSLA（サービスレベル合意）の議論はこの取得者・供給者の関係を前提にしています。
Q. システムライフサイクルプロセス（ISO/IEC/IEEE 15288）とソフトウェアライフサイクルプロセス（ISO/IEC/IEEE 12207）はどう使い分けますか？
15288はハードウェア・ソフトウェア・人間の運用まで含む「システム全体」を対象とし、12207は「ソフトウェア」に焦点を当てた規格です。両規格は2023年の改訂で用語・プロセスの整合が取られ、組み合わせて使えるよう設計されています。IPA試験では基本的に12207ベースの「ソフトウェアライフサイクル」を扱えば十分で、15288まで深掘りされることはまずありません。
