共通フレームとは、IPAの共通フレーム2013、プロセスやワーク、覚え方、概要までわかりやすく解説

システム開発の現場では、発注者と受注者の間で「言った・言わない」のトラブルが絶えません。こうした認識の齟齬を防ぎ、プロジェクトを円滑に進めるためのガイドラインが共通フレーム（SLCP）です。

今回は、IT業界の標準的な基準となる共通フレーム2013について、その全体像から各プロセスの詳細、さらには資格試験にも役立つ効率的な覚え方までを専門的な視点で詳しく解説します。

共通フレーム（SLCP）とは？

システム開発は、目に見えないソフトウェアを作り上げる複雑な工程です。まずは、共通フレームの定義とその必要性について確認していきましょう。

共通フレームの定義と目的

共通フレームとは、ソフトウェアの開発、運用、保守といったライフサイクルの中で必要となるプロセスを体系化したものです。英語ではSLCP（Software Life Cycle Process）と呼ばれます。

最大の目的は、システム開発に関わるすべての人々が、同じ言葉で、同じ作業内容を理解できるようにすることです。

例えば、要件定義という言葉ひとつをとっても、人によって「画面イメージまで作る工程」と考える人もいれば、「必要な機能のリストを作る工程」と考える人もいます。共通フレームでは、それぞれの工程で行うべきタスクが定義されているため、作業範囲（スコープと言います）を明確に定めることができます。

共通フレームに含まれている主な考え方

共通フレーム2013はシステム開発の失敗を回避し、ビジネス価値を最大化するための考え方を提唱しています。IPAの資料に基づき、提唱されている7つの主要な考え方を解説します。

（１）利害関係者の役割と責任分担の明確化

システム開発には、発注者、利用者、開発者など多くのステークホルダーが関わります。共通フレームは、それぞれのプロセスにおいて「誰が主体となり、誰が責任を持つのか」を明確にすることを求めています。特に、企画や要件定義などの上流工程において、発注者が主体的に関与することの重要性を強調しています。

具体的には、事業要件の定義については社長～関連会社まで、経営層から業務部門にまたがり、それぞれが責任を持ってい自らの責任を果たすこと。業務要件レベルの定義は業務部門、システム要件定義は情報システム部門がそれぞれ責任を果たすことを求めています。

（２）多段階の見積り方式

プロジェクトの初期段階で、最終的な総額を正確に見積もることは不可能です。共通フレームでは、工程が進み、詳細が明らかになるにつれて見積もりを精緻化していく「多段階見積り」を推奨しています。

具体的には、システム化の方向性、システム化計画までを試算とし、要件定義で概算、設計で確定とするような見積を提唱しています。このように段階を分けることで、予算の乖離や赤字プロジェクトのリスクを軽減します。

（３）Ｖ字モデルの採用

開発工程（V字の左側）とテスト工程（V字の右側）を対応させる「V字モデル」の考え方をベースとしています。Vの文字の上部分を超上流、下部分を下流とし、各工程が対になるよう、左右の要素を配置した考え方になっています。各設計工程で「何をテストすべきか」を定義しておくことで、品質の抜け漏れを構造的に防ぐ仕組みです。

図表.1 Ｖ字モデル

出典：独立行政法人情報処理推進機構(IPA) - 共通フレーム２０１３の概説 より抜粋

（４）超上流における準委任契約の採用

不確実性が高く、作業範囲が確定しにくい「企画」や「要件定義」の段階では、完成を保証する請負契約よりも、専門家の役務提供を基本とする準委任契約が適していると提唱しています。これにより、発注者と受注者が協力して最適な要件を練り上げることが可能になります。

～Tips：準委任契約～
受注者が「完成」を約束するのではなく、善管注意義務（プロとして最善を尽くす義務）を持って作業を行う契約形態。要件が固まっていない上流工程での柔軟な対応に適している。

（５）要件の合意及び変更ルールの事前確立

プロジェクト進行中の「追加要望」や「仕様変更」は、スケジュール遅延の最大の原因です。共通フレームでは、変更が発生した際の承認ルート、コスト負担、影響分析の方法をあらかじめルール化しておくことを重視しています。これにより、「言った・言わない」のトラブルを防止します。特にIPAの資料では、「時の経過に伴って要件は変わるもの」であると明記されており、事前にルールを策定することを求めています。

（６）非機能要件の重要性を認識すること

機能要件、つまり画面や機能だけでなく、システムの安定性、セキュリティ、パフォーマンス、拡張性といった「非機能要件」の重要性を説いています。これらはユーザーからは見えにくいものの、ビジネス継続において極めて重要な要素であり、初期段階から定義すべき項目として位置づけられています。業務要件の中に非機能要件も含まれており、業務部門にとっては業務要件こそが重要、としています。

（７）運用・保守を含めたSLCPを考えること

システムは作って終わりではありません。共通フレームは、開発後の運用・保守、さらには廃棄に至るまでのライフサイクル全体を考慮することを提唱しています。初期開発費用だけでなく、長期的な運用コストを意識した意思決定を促しています。システムを生き物のように考えて意思決定する必要があることを提唱しています。

共通フレームの歴史と変遷

共通フレームは、国際規格であるISO/IEC 12207や、それに対応する日本産業規格JIS X 0160をベースに作成されています。

歴史を遡ると、最初の共通フレーム（共通フレーム94）が1994年に策定されました。その後、システム開発を取り巻く環境の変化（外部委託の増加やオフショア開発の普及など）に伴い、1998年版、2007年版と改訂が重ねられてきました。

現在、日本のIT業界で最も広く参照されているのが、2013年に発行された共通フレーム2013です。JIS X 0160:2012の内容を反映し、さらに日本独自の商習慣や「超上流工程」の重要性も加味して作られています。

IPA（独立行政法人情報処理推進機構）の公式アーカイブ資料「共通フレーム2013の概要」等を参照し、規格の変遷やJISとの対応表を確認することをお勧めします。

共通フレームが必要とされる具体的な理由

責任分界点の明確化
どの作業を誰が行うのかをはっきりさせます。

見積もりの透明化
作業項目が細分化されるため、コストの妥当性を判断しやすくなります。

品質管理の基準
実施すべき作業が網羅されているため、工程の抜け漏れを防げます。

～Tips：SLCP（Software Life Cycle Process）～

ソフトウェアの構想、開発、運用、廃棄に至るまでの全期間（ライフサイクル）を、段階的なプロセスとして管理する考え方のこと。

共通フレーム2013の全体像、4つのプロセス群と構成要素

共通フレーム2013は、非常に膨大な作業項目を含んでいますが、大きく分けると4つのプロセス群で構成されています。ここでは全体構造を整理しましょう。

主体となる4つのライフサイクルプロセス

共通フレーム2013では、大きく分けて以下の4つの柱があります。

1. 企画プロセス：経営戦略に基づき、どのようなシステムを作るべきか構想を練る。

2. 要件定義プロセス：システムで実現すべき機能や性能を明確にする。

3. 開発プロセス：設計、プログラミング、テストを行い、システムを形にする。

4. 運用・保守プロセス：リリースされたシステムを安定して動かし、必要に応じて修正する。

これらは、システムが生まれてから役割を終えるまでの時系列に沿っています。

共通フレームの階層構造を理解する（プロセス・アクティビティ・タスク）

共通フレームは、情報の粒度によって3つの階層に分かれています。この構造を理解することが、全体を把握する近道です。

1. プロセス（大分類）：要件定義、開発、運用などの大きな区切り。

2. アクティビティ（中分類）：プロセスをさらに細かくした作業群（例：ソフトウェア詳細設計）。

3. タスク（小分類）：具体的に実施する最小単位の作業（例：データベース設計書の作成）。

実務では、このタスクレベルを元にWBS（作業分解構成図）を作成し、スケジュールや担当者を割り当てていきます。

図表.2 プロセス・アクティビティ・タスク

出典：独立行政法人情報処理推進機構(IPA) - 共通フレーム２０１３の概説 より抜粋

2007年版から2013年版への変更点（超上流工程）

2013年版の最大の特徴は、超上流工程と呼ばれる、開発に着手する前の段階が強化された点にあります。

2007年版までは、システム化の目的が曖昧なまま開発が進み、結果として「使われないシステム」が完成してしまう失敗が多発していました。2013年版では、経営課題の解決に焦点を当てた企画プロセスが充実し、要件定義との接続がより明確になっています。

～Tips：超上流工程とは？～
システム開発における初期段階（企画・要件定義など）のこと。この段階でのミスや漏れは、後の工程で修正する場合、多大なコストと時間を要するため、極めて重要視される。

共通フレームの主要なプロセスと具体的なワーク内容

ここからは各プロセスで具体的にどのような業務が行われるのかを深掘りします。いくつか事例を考えながら、各プロセスで行う業務を列挙していきます。

企画プロセス（立案・算出・策定・分析）

企画プロセスは、いわば「なぜこのシステムを作るのか」を定義する段階です。

• システム化構想の立案：経営目標を達成するために必要なITの全体像を描きます。

• システム化計画の立案：費用対効果の算出、プロジェクトの全体スケジュールの策定、リスク分析などを行います。

要件定義プロセス（RFP・定義）

要件定義プロセスでは、「何を」作るのかを確定させます。

• 業務要件定義：新しいシステムを使った業務フローを定義します。

• システム要件定義：業務要件を実現するために必要な、機能（画面、帳票など）や非機能（セキュリティ、性能、拡張性など）を定義します。

この段階の成果物は、受注者（ベンダー）に対して提示するRFP（提案依頼書）のベースとなります。

開発プロセス（設計・実装・テスト）

開発プロセスは、エンジニアが中心となる工程です。ここでは、以下のステップをたどります。

1. システム設計：システム全体の構造を設計します。

2. ソフトウェア設計：ソフトウェアの各部品（モジュール）の詳細を設計します。

3. 実装（コーディング）：プログラムを書きます。

4. テスト：単体テスト、結合テスト、システムテスト、運用テストを行い、バグがないか、要件を満たしているかを確認します。

これらは、要件定義で決めた内容を検証していくV字モデルという考え方と深く結びついています。

運用・保守プロセス（運用・保守）

システムは作って終わりではありません。むしろ、リリース後の方が期間は長くなります。

• 運用プロセス：日常的なデータのバックアップ、監視、ユーザーサポートなど。

• 保守プロセス：不具合の修正や、法改正に伴う機能追加、OSのアップデート対応など。

共通フレーム2013では、最終的なシステムの廃棄プロセスまでが定義されています。データの消去やハードウェアの処分も、重要なライフサイクルの一部です。

管理プロセスと支援プロセス（管理・品質）

主要なプロセスの裏側で、プロジェクト全体を円滑に進めるためのプロセスも定義されています。

• プロジェクト管理プロセス：進捗、コスト、品質、リスクを管理します。

• 構成管理プロセス：プログラムのソースコードや設計書のバージョンを管理し、混乱を防ぎます。

• 品質保証プロセス：作業成果物が基準を満たしているかを客観的にチェックします。

現場で役立つ共通フレームの覚え方と試験対策のコツ

情報処理技術者試験（応用情報、システムアーキテクト、ITストラテジストなど）において、共通フレームは頻出項目です。丸暗記ではなく、構造で覚えるのがコツです。

合意プロセスとテクニカルプロセスの分類を整理する

試験で混乱しやすいのが、プロセスの分類名です。JIS X 0160:2012では、大きく以下の4つに分類されています。

1. 合意プロセス：取得（発注）、供給（受注）。「買う・売る」の約束。

2. 組織のプロジェクト実現プロセス：ライフサイクルモデル管理、インフラ管理、プロジェクトポートフォリオ管理。組織全体としての備え。

3. プロジェクトプロセス：計画、評価、制御、リスク管理。個別のプロジェクト運営。

4. テクニカルプロセス：要件定義、設計、実装、テスト、運用、保守、廃棄。実際のモノづくり。

まずは、この大きな4つの箱をイメージできるようにしましょう。

語呂合わせやイメージで覚える！主要プロセスの分類法

1人の人間がプロセスの全工程に関わるということは極めて稀です。多くの場合、ひとり一人、専門のプロセスを持って業務に従事することになるでしょう。ですので自分の仕事の範囲から全体像を想像するのは難しいかもしれません。おすすめの覚え方として、自分を主人公にしたストーリー仕立てにする方法があります。

• 合意：お店（ベンダーといいます）に行って、何を買うか決める。

• プロジェクト：予算を管理し、納期に間に合うように進める。

• テクニカル：実際に設計図を描き、組み立て、試運転し、使い、最後は捨てる。

このように、日常生活の購買行動や工作に当てはめると、抽象的な用語が具体性を帯びてきます。特に最後の「捨てる」という工程は通常、細分化された業務レベルでは想定しにくい部分になりますので、意識して考えてみましょう。

見積もり根拠や責任分界点への応用

実務において共通フレームを使いこなすとすれば、見積書や契約書の作業項目を、共通フレームのタスク名に合わせるという方法があります。

例えば、「設計作業一式」という業務範囲の曖昧な表現ではなく、「共通フレーム2013におけるソフトウェア詳細設計およびユニットテストデータの作成」と記載することで、作業の範囲を誰の目にも明らかにできます。これにより、追加費用が発生した際も、「これは共通フレームのこの範囲外の作業である」という根拠を持って交渉が可能になります。また自前で範囲を詳細に記載する必要もないため、効率的で漏れの心配もありません。微調整が必要な場合も、「共通フレーム2013設計における●●の部分は除く」など除外項目として定めることも可能と想定されるため、たたき台のような役割としても使えます。

共通フレームの最新動向とアジャイル・DX時代への適応

システム開発の手法は、ウォーターフォールからアジャイルへと多様化しています。2026年現在、共通フレーム2013はどのように扱われているのでしょうか。

最新、2026年現在、共通フレーム2013はどう扱われているのか？

共通フレーム2013は、主にウォーターフォール型の開発を前提としてまとめられていますが、その本質であるプロセス管理の考え方は、手法を問わず有効です。

現在、ISO/IEC 12207:2017という新しい国際規格が登場しており、共通フレームもこれに準拠したアップデートが議論されています。しかし、現場の実務や契約、資格試験においては、依然として共通フレーム2013が基準点として機能しています。

2026年4月時点でIPAの新着・プレスリリースを見ても、共通フレーム自体の新版公開は確認できませんでした。ですので共通フレーム2013が最新ということになります。一方で、基盤となる国際規格SLCPは2015年以降に大きく改訂されており、IPAはデジタルスキル標準 ver.2.0 やAI安全性関連ガイドなど、DX・AI時代の周辺基盤を強化しています。つまり、共通フレームそのものの更新より、周辺の制度・実務ガイドの拡充が進んでいる状況です。

アジャイル開発版共通フレームへの展開

アジャイル開発では、要件定義と開発を繰り返すため、従来の時系列的なプロセスとは馴染まない部分があります。

IPAでは、アジャイル開発に共通フレームの考え方をどう適用すべきかというガイドも発行しています。固定的なプロセスとして捉えるのではなく、各アクティビティを迅速に、繰り返し実行するという解釈が一般的になっています。

IPAが公開している「アジャイル開発の進め方」や、アジャイルに特化したガバナンスの資料を参照することを推奨します。

DX推進における共通フレームの役割

DXにおける共通フレームの立場として、IT投資の透明性を高めるという点が挙げられます。DX（デジタルトランスフォーメーション）が叫ばれる中、ITは単なる業務効率化ツールから、ビジネスの核へと変化しています。共通フレームは、経営層がIT投資の内容を正しく理解し、評価するための共通言語としての役割がますます強まっています。共通フレームを用いて説明することで、根拠のある提案と判断ができるでしょう。

共通フレームに関するよくある質問（FAQ）

共通フレームの導入や学習において、多くの人が疑問に思うポイントをQ&A形式でまとめてみました。

Q1：共通フレームとSLCPは何が違うのですか？

基本的には同じものを指していると考えて差し支えありません。SLCP（Software Life Cycle Process）は、ソフトウェアの構想から廃棄までのライフサイクルを管理する「考え方」や「国際規格」の名称です。これに対し、共通フレームは、日本のIT業界の慣習に合わせてIPAがSLCPの規格（JIS X 0160）を具体的に解説・体系化したガイドブックの名称です。

Q2：2013年版が最新ですか？2026年現在、新しいバージョンはありますか？

現在も実務や試験の基準となっているのは「共通フレーム2013」です。ベースとなる国際規格（ISO/IEC 12207）やJIS規格は2017年以降に改訂されていますが、日本国内のシステム開発における共通言語としての参照先は、依然として共通フレーム2013が主流のようです。最新の規格動向については、IPAの公式サイトを定期的に確認することをお勧めします。

Q3：アジャイル開発に共通フレームを適用するのは難しいですか？

共通フレーム2013はウォーターフォール型のプロセスを意識して構成されていますが、アジャイル開発でも活用可能です。例えば、要件定義やテストといった「実施すべきアクティビティ」の内容自体は、アジャイルでも変わりません。ただ、それらを時系列に進めるのではなく、短期間のイテレーション（反復のこと）の中で繰り返し実行するという運用上の工夫が必要になります。

Q4：共通フレームに従うことは法律で義務付けられていますか？

法律による強制力はありません。しかし、裁判などでシステム開発の責任分界点が争点になった際、共通フレームが「業界の標準的な信義則」として参照されることがあります。契約書や作業定義書に共通フレームのプロセスを引用しておくことは、法的なトラブルを未然に防ぐリスクマネジメントとして非常に有効です。

Q5：情報処理技術者試験のどの区分で出題されますか？

ITパスポート試験から、基本情報技術者、応用情報技術者、さらにはITストラテジストやシステムアーキテクトなどの高度試験まで、幅広く出題されます。低いレイヤーの試験では用語の定義や分類が、高いレイヤーの試験では企画や要件定義などの各プロセスの具体的な進め方や判断基準が問われる傾向にあります。

共通フレームを正しく理解し、プロジェクトの成功率を高めよう

共通フレームの知識は、エンジニアだけでなく、発注側のWeb担当者や経営層にとっても、ITプロジェクトを成功に導くための強力な武器になります。まずは、自社のプロジェクト工程が共通フレームのどの部分に該当するのか、照らし合わせてみることから始めてみてはいかがでしょうか。

テクノロジーについてコチラもおすすめです【関連記事】