ISO/IEC 12207 (ソフトウェアライフサイクルプロセス)

1. 概要

定義: ISO/IEC 12207とは、ソフトウェアの取得・供給・開発・運用・保守・廃棄に至る全ライフサイクルにわたる活動を「プロセス(Process)」という共通単位で定義した国際規格であり、組織と組織の間、人と人の間でソフトウェア作業を一貫して意思疎通・契約・評価できるよう「何を実施すべきか」を規定するプロセス参照モデル(Process Reference Model)である。

ISO/IEC 12207が登場した背景には、1980〜90年代にソフトウェア産業が抱えていた「プロセスの無定形性」という問題がある。当時は発注者と供給者がそれぞれ異なる用語と手順で開発を進めていたため、契約時点で「開発はどこで始まりどこで終わるのか」「検証と妥当性確認は誰が責任を負うのか」「保守の範囲は何か」をめぐって絶え間ない紛争が発生していた。同じ「設計」という語さえ組織ごとに意味が異なり、成果物と責任の境界が曖昧で、これが日程遅延・品質低下・訴訟へとつながった。こうした混乱を解消するため、ISOとIECはソフトウェアライフサイクルの活動を標準化されたプロセス集合として定義し、1995年7月にISO/IEC 12207:1995を最初の国際規格として制定した。

この規格が必要とされる根本的理由は、ソフトウェア作業の「共通の枠組み(common framework)」の確保にある。発注者と供給者が同一のプロセス定義を参照すれば、契約書に「本事業はISO/IEC 12207の供給・開発プロセスに従う」と明記するだけで、遂行範囲・責任・成果物の基準線が合意される。さらにプロセスを明示的に定義しておけば、そのプロセスが「適切に遂行されているか」を客観的に審査・改善できるようになるが、これこそが後述するSPICE(ISO/IEC 15504、現ISO/IEC 33000群)やCMMIといったプロセス評価・改善モデルの土台となる。すなわち12207はそれ自体で品質を保証するわけではないが、品質を「測定し改善できる」ようにする基準点であるという点で、ソフトウェア工学規格体系の中心軸に相当する。

ISO/IEC 12207の核心的特徴を整理すると次のとおりである。第一に、ライフサイクル全体を包含し、開発だけでなく運用・保守・廃棄まで扱う。第二に、プロセス中心(process-oriented)であり、特定の開発方法論(ウォーターフォール・アジャイル等)を強制せず「何を」のみを規定し「どのように」は組織の選択に委ねる。第三に、テーラリング(Tailoring)可能性を前提とし、小規模プロジェクトから大規模システムまで必要なプロセスのみを選択・調整して適用できる。第四に、システムライフサイクル規格(ISO/IEC 15288)との整合性を志向し、ソフトウェアがより大きなシステムの構成要素として統合される現実を反映する。この四つの特徴が12207を単なる手順書ではなく、組織間協業とプロセス改善の基盤規格にしている。

2. ライフサイクルプロセスの全体構造

ISO/IEC 12207は、ソフトウェアのライフサイクルを相互に関連するプロセス群のネットワークとして捉える。各プロセスは「目的(Purpose)」とその目的を達成したときに現れる「成果(Outcome)」、そのための「活動(Activity)」と「作業(Task)」として階層的に定義される。この構造のおかげで、組織はプロセスの意図を理解したうえで、自らの環境に適した実装方式を自由に選択できる。例えば「検証(Verification)プロセス」の目的は成果物が仕様を正しく反映しているかを確認することであるが、その実装はコードレビューにも、静的解析ツールにも、形式検証にもなり得る。

graph TD
    A["ISO/IEC 12207 ソフトウェアライフサイクルプロセス"] --> B["合意プロセス(Agreement): 取得・供給"]
    A --> C["組織のプロジェクト実現可能化プロセス(Organizational Project-Enabling)"]
    A --> D["技術管理プロセス(Technical Management): 計画・統制・リスク・構成"]
    A --> E["技術プロセス(Technical): 要求・設計・実装・検証・移行・運用・保守・廃棄"]
    B --> F["プロセス要素: 目的(Purpose)"]
    C --> F
    D --> F
    E --> F
    F --> G["成果(Outcome)"]
    G --> H["活動(Activity)"]
    H --> I["作業(Task)"]

上記の構造で注目すべき点は、プロセスが垂直的な階層ではなく水平的な協力関係として編まれていることである。合意プロセスが契約の境界を設定すると、組織のプロジェクト実現可能化プロセスがインフラ・人員・品質基盤を提供し、技術管理プロセスが日程とリスクを統制するなかで、技術プロセスが実際のソフトウェアを産出する。これらは順次に一度だけ通過するのではなく、反復(iteration)と再帰(recursion)を通じてライフサイクルの間、何度も繰り返されながら相互作用する。アジャイルのスプリントで要求・設計・実装・検証が2週間単位で反復されるのも、12207の観点では「技術プロセス群の反復適用」として解釈される。

このプロセスネットワークの観点がもたらす実務的含意は、責任と成果物の追跡可能性(traceability)である。プロジェクトで品質問題が発生したとき、それが要求定義の不十分さなのか、検証プロセスの欠落なのか、構成管理の失敗なのかを、プロセス単位で遡って追跡できる。例えば金融機関の次世代システムで要求変更の統制が繰り返し失敗するならば、12207の「構成管理(Configuration Management)」と「情報管理(Information Management)」プロセスが適切に定義・遂行されているかを点検する形で、問題を構造的に診断できる。

3. 1995年原版の3大プロセスカテゴリ

ISO/IEC 12207:1995の原版は、ライフサイクルプロセスを三つのカテゴリに分けており、この分類は今でも教科書的理解の出発点として広く引用されている。各カテゴリは単なる一覧ではなく、「誰が責任を負う活動か」という観点でまとめられたものである。

A. 基本ライフサイクルプロセス(Primary Life Cycle Processes)

基本プロセスは、ソフトウェアを実際に取得・供給・生産・使用する主体が直接遂行する中核活動であり、原版では取得(Acquisition)・供給(Supply)・開発(Development)・運用(Operation)・保守(Maintenance)の5つで構成された。取得は発注者がソフトウェアやサービスを調達する活動を、供給は供給者が契約に従って製品を提供する活動を規定し、契約両当事者の役割を明確に分離する。この分離が重要である理由は、ソフトウェア紛争の相当数が「発注者の要求明確化責任」と「供給者の実装責任」の境界が曖昧であることに起因するからである。

開発プロセスは要求分析・設計・実装・統合・試験を網羅する最も膨大なプロセスであり、実際の成果物が作られる中心軸である。運用プロセスは受け入れたソフトウェアを実環境で稼働させ利用者を支援する活動を、保守プロセスは欠陥修正(是正)・環境変化への対応(適応)・機能改善(完全化)・障害予防(予防)など、納入後の変更を体系的に管理する活動を担う。実務でソフトウェア総所有コスト(TCO)の60〜70%が保守段階で発生する点を考慮すれば、12207が保守を開発と対等な独立プロセスに格上げしたことは、「ソフトウェアコストの重心が納入後にある」という現実を規格に反映したものである。

B. 支援ライフサイクルプロセス(Supporting Life Cycle Processes)

支援プロセスは、基本プロセスの品質と信頼性を支える補助活動であり、原版では文書化・構成管理・品質保証・検証(Verification)・妥当性確認(Validation)・共同レビュー・監査(Audit)・問題解決の8つが定義された。これらは独立して価値を生むというより、他のプロセスに「組み込まれて(embedded)」遂行され品質を保証する。例えば構成管理は開発・保守の全過程で成果物のバージョンと変更履歴を統制し、どの時点に何がなぜ変わったかを追跡可能にする。

ここで検証(Verification)と妥当性確認(Validation)の区別は、技術士答案で頻繁に要求される核心概念である。検証は「製品を正しく作っているか(Are we building the product right?)」を問う活動であり、成果物がその段階の入力仕様を正確に反映しているかを見る。一方、妥当性確認は「正しい製品を作っているか(Are we building the right product?)」を問う活動であり、最終成果物が利用者の実際の要求と意図を満たしているかを見る。例えば要求仕様どおりに正確に実装したにもかかわらず(検証通過)、利用者が望んでいた機能ではなかったならば(妥当性確認失敗)、これは要求導出段階の失敗として追跡される。この二つを分離して定義したのは、品質欠陥の原因が「実装の不正確さ」なのか「要求の誤解」なのかを構造的に区別するためである。

C. 組織ライフサイクルプロセス(Organizational Life Cycle Processes)

組織プロセスは、個別プロジェクトを超えて組織次元でプロセスそのものを運用・改善する活動であり、原版では管理(Management)・基盤(Infrastructure)・改善(Improvement)・訓練(Training)の4つで構成された。管理プロセスはプロジェクトの計画・追跡・統制を、基盤プロセスは開発環境・ツール・設備の確保を、改善プロセスは組織のプロセスを継続的に評価・改善する活動を、訓練プロセスは人員の力量確保を担う。

組織プロセスが別個のカテゴリとして存在する理由は、ソフトウェア品質が個別プロジェクトの努力だけでは持続しないからである。いかに一つのプロジェクトが成功しても、その経験が組織の標準プロセスと教育体系として資産化されなければ、次のプロジェクトは再び英雄的個人に依存することになる。まさにこの「改善」プロセスがCMMI・SPICEのいう「組織成熟度」の根であり、組織がプロセスを定義→測定→改善する好循環を回すようにする。

カテゴリ	原版(1995)の構成プロセス	遂行主体の観点	核心的性格
基本(Primary)	取得・供給・開発・運用・保守	契約当事者が直接遂行	価値を直接生産
支援(Supporting)	文書化・構成管理・品質保証・検証・妥当性確認・共同レビュー・監査・問題解決	基本プロセスに内在	品質・信頼性を保証
組織(Organizational)	管理・基盤・改善・訓練	組織次元で運用	プロセスの資産化・改善

4. 2017年改訂版: ISO/IEC 15288との調和と4大プロセスグループ

ソフトウェアが単独で存在せず、より大きなシステム(ハードウェア・ネットワーク・人的要素)の一部として動作する現実が深まるにつれ、ソフトウェアライフサイクル(12207)とシステムライフサイクル(ISO/IEC 15288)を別個に運用することは重複と不整合を生んだ。そこで2008年改訂版が両規格の構造を整列させ始め、2017年のISO/IEC/IEEE 12207:2017は15288:2015と用語・プロセス構造をほぼ一致させた調和(harmonization)の決定版として発表された。これによりシステムエンジニアとソフトウェアエンジニアが一つの一貫したプロセス体系の上で協業できるようになった。

2017年改訂版はプロセスを四つのグループに再編した。これは原版の「基本・支援・組織」の3分類を、契約の観点(合意)・組織基盤提供の観点・プロジェクト管理の観点・エンジニアリングの観点に再構成したものである。

flowchart LR
    subgraph AG["合意プロセス(Agreement)"]
      A1["取得(Acquisition)"]
      A2["供給(Supply)"]
    end
    subgraph OP["組織のプロジェクト実現可能化(Organizational Project-Enabling)"]
      O1["ライフサイクルモデル管理"]
      O2["インフラ・ポートフォリオ・人的資源"]
      O3["品質管理・知識管理"]
    end
    subgraph TM["技術管理(Technical Management)"]
      M1["プロジェクト計画・評価・統制"]
      M2["意思決定・リスク・構成管理"]
      M3["情報管理・測定・品質保証"]
    end
    subgraph TP["技術プロセス(Technical)"]
      P1["要求定義・アーキテクチャ・設計"]
      P2["実装・統合・検証・移行"]
      P3["妥当性確認・運用・保守・廃棄"]
    end
    AG --> OP --> TM --> TP
    TP -. フィードバック・反復 .-> TM

四つのグループの役割を散文で解くと次のとおりである。合意プロセスは組織間契約(取得・供給)を通じて作業の境界と責任を確定する。組織のプロジェクト実現可能化プロセスは、ライフサイクルモデル管理・インフラ管理・ポートフォリオ管理・人的資源管理・品質管理・知識管理のように、個別プロジェクトが成功できるよう組織が基盤を整える活動である。技術管理プロセスはプロジェクト計画・評価および統制・意思決定管理・リスク管理・構成管理・情報管理・測定・品質保証を含み、エンジニアリングが統制された状態で進むよう管理する。技術プロセスはビジネス/ミッション分析から利害関係者要求定義・システム/ソフトウェア要求定義・アーキテクチャ定義・設計・実装・統合・検証・移行・妥当性確認・運用・保守・廃棄まで、計14個前後のエンジニアリング活動で構成され、実際の製品を作り出す中心をなす。

原版の3分類から2017年の4グループへの転換は、単なる再配置ではなく観点の分離という設計意図を含む。特に管理活動を「組織が提供する基盤(組織のプロジェクト実現可能化)」と「プロジェクト内部の統制(技術管理)」に分けたのは、組織水準の責任とプロジェクト水準の責任を区別してガバナンス体系を明確にするためである。例えば「品質」は組織次元の品質管理(Quality Management)とプロジェクト次元の品質保証(Quality Assurance)に分かれ、前者が品質方針・標準を樹立し後者が特定のプロジェクトがその標準を守っているかを保証する形で役割が分化する。

5. プロセスのテーラリング(Tailoring)と適用

ISO/IEC 12207のすべてのプロセスをすべてのプロジェクトに全部適用することは非現実的であり、規格自体がそれを要求もしない。規格はテーラリング(Tailoring)過程を公式活動として定義し、プロジェクトの規模・リスク・契約の性格・ライフサイクルモデルに合わせてプロセスを選択・調整・削除できるようにする。テーラリングが重要である理由は、小規模ウェブサービス開発に大規模国防システム水準の重い構成管理・監査手続きをそのまま適用すれば、官僚主義とコストだけが増加し品質は良くならないからである。

テーラリングの実務的事例を挙げると、スタートアップの2週間スプリント基盤のモバイルアプリ開発では「共同レビュー」を格式ある文書レビューの代わりにデイリースタンドアップとスプリントレビューで代替し、「文書化」はコードと自動化テストが文書を代替するよう最小化できる。一方、原子力・航空のように安全が重要な(safety-critical)領域では、検証・妥当性確認・監査・構成管理プロセスをむしろ強化し、追跡性マトリクスと独立検証(IV&V)を追加する。同一の規格が両極端のプロジェクトにすべて適用され得るのは、12207が「何を」のみを規定し「どれほど厳格に」はテーラリングに委任するからである。

このテーラリング概念は公共ソフトウェア事業で特に重要である。国内公共SI事業の作業指示書や提案依頼書(RFP)で適用するライフサイクルプロセスと成果物一覧を定義する際、12207のプロセス体系を参照すれば、事業規模に比べ過度または不十分な成果物要求を調整できる。すなわちテーラリングは「規格を守りつつ現実に合わせる」という実用主義の核心装置であり、テーラリング決定とその根拠を文書化しておくことが、紛争予防と品質確保の均衡点を提供する。

テーラリングの定量的効果を推し量ると、成果物数十種を一律に要求していた公共事業で、事業特性に合わない文書を取り除き核心成果物のみを残せば、形式的な文書作成に費やされていた工数を相当部分節減しつつ、追跡性には影響を与えないことができる。ただしどのプロセスを削除するかはリスク基盤で判断すべきであり、検証・構成管理・問題解決のように欠陥を早期に捕捉するプロセスをコスト節減を理由に削除すれば、後半の再作業コストが節減額を超える逆効果が発生し得る。したがってテーラリングは「何を抜くか」より「どのリスクを受け入れられるか」の観点から接近すべきであり、この判断自体が技術士の核心的力量に相当する。

6. 比較および連携: 12207 · 15288 · CMMI · SPICE

ISO/IEC 12207を正確に理解するには、隣接する規格・モデルとの関係も併せて見なければならない。核心は、12207と15288は「プロセスを定義」する参照モデルである一方、CMMIとSPICE(ISO/IEC 15504、現33000群)はそのプロセスが「どれほどよく遂行されるか」を評価・改善するモデルであるという分業構造である。たとえるなら12207は「何をすべきかが書かれた標準教科書」であり、SPICE・CMMIは「その教科書をどれほど習熟したかを採点する試験・成績表」に相当する。

この違いが生じる理由は規格の目的が異なるからである。12207は組織間の意思疎通と契約の共通基準を提供することが目的なので「定義」に集中し、SPICEはその定義されたプロセスの遂行水準を6段階(0〜5)の能力水準で審査する評価フレームワークである。実際、SPICEのプロセス参照モデルは12207・15288のプロセス定義をそのまま持ってきて評価対象(Process Reference Model)とする。したがって三つの規格は競争関係ではなく、「定義-評価-改善」の役割分担として相互に補完する。

区分	ISO/IEC 12207	ISO/IEC 15288	CMMI	SPICE(ISO/IEC 15504→33000)
対象	ソフトウェアライフサイクル	システムライフサイクル	組織のプロセス力量	プロセス遂行能力
目的	プロセス「定義」(参照モデル)	プロセス「定義」(参照モデル)	成熟度診断・改善	能力水準評価
構造	4大プロセスグループ(2017)	4大プロセスグループ(整列)	成熟度1〜5 / 能力0〜3	能力水準0〜5
関係	15288と調和	12207と調和	12207をベストプラクティスとして参照	12207を評価対象として参照

7. 深化: 規格の進化とアジャイル・DevOpsとの接合

ISO/IEC 12207の改訂史は、ソフトウェア産業のパラダイム変化をそのまま反映する。1995年原版は組織間の契約紛争解消という当面の課題から出発し、2002・2004年の二度の修正(Amendment)を経て、2008年改訂でシステムライフサイクル規格(15288)との整列を始め、2017年のISO/IEC/IEEE 12207:2017で15288:2015と構造・用語を調和させ、「システム-ソフトウェア統合ライフサイクル」の枠を完成させた。報道によれば2026年4月には後続改訂版(第2版)が発表されたと伝えられているが、詳細条項は改訂によって変わり得るため、答案では「周期的に改訂され、15288との整合性を強化する方向」という流れで記述するのが安全である。

最新動向の核心は、アジャイル・DevOpsのような軽量・反復方法論と12207の接合である。過去には12207がウォーターフォールモデルと結合した重い文書中心規格と誤解されることもあったが、規格は本来ライフサイクルモデルを強制しない。2017年改訂でプロセスを目的・成果中心に定義し反復・再帰適用を明示したのは、アジャイルの反復スプリントやDevOpsの継続的統合/デプロイ(CI/CD)パイプラインを12207プロセスの反復実行として解釈できるようにするためである。例えばDevOpsの自動化されたビルド・テスト・デプロイは、12207の「実装-統合-検証-移行」プロセスがツールによって高速で反復される形にマッピングされる。

もう一つの動向は、サプライチェーン・セキュリティ・AI要素のライフサイクル統合である。オープンソースとサードパーティ構成要素がソフトウェアの大部分を占めるにつれ、12207の取得・供給プロセスはSBOM(ソフトウェア部品表)・サプライチェーンセキュリティと連携する方向に解釈が拡張されている。さらにAI・機械学習基盤のシステムはデータ・モデルという新たなライフサイクル要素を含むため、伝統的なソフトウェアライフサイクル規格をISO/IEC 42001(AI経営システム)やMLOps体系と併せて適用する統合ガバナンスが要求される。すなわち12207は固定された手順書ではなく、産業変化に合わせて解釈と連携が進化する「生きた基準」として見るべきである。

8. 考慮事項および示唆 (技術士の観点)

第一に、規格の本質は「プロセス定義」であって「品質保証」ではないという点を明確にすべきである。 12207を採用したからといって自動的に品質が担保されるわけではなく、定義されたプロセスが実際に遂行され、その遂行水準がSPICE・CMMIで評価・改善されるときに初めて成果につながる。適用戦略の観点から、組織は12207でプロセスを定義しSPICEで能力を診断し改善ロードマップを回す「定義-評価-改善」の三角体系を併せて設計すべきである。

第二に、テーラリング(Tailoring)の適正性が成否を分ける。 プロセスを過度に適用すれば俊敏性とコストで損をし、過少に適用すれば追跡性と品質統制を失う。トレードオフの観点から、安全重要システムは検証・妥当性確認・監査を強化する方へ、速い市場対応が重要なサービスは文書・レビューを軽量化する方へテーラリングしつつ、テーラリング決定の根拠を文書化して紛争と監査に備えるべきである。テーラリングは「規格無視」ではなく「規格の知的適用」であることを区別するのが核心である。

第三に、検証(V&V)と構成管理はライフサイクル品質の中枢であるため、先行投資すべきである。 欠陥はライフサイクル後半へ行くほど修正コストが幾何級数的に増加するため(要求段階に比べ運用段階で数十〜数百倍)、検証・妥当性確認を各プロセス段階に内在化する「左方移動(shift-left)」が費用効率的である。この点で12207はDevSecOps・自動化テスト・継続的統合ツール体系と自然に連携する。

第四に、システム・ソフトウェア・AIライフサイクルの統合ガバナンスの観点が必要である。 ソフトウェアがシステムの一部であり、AI・データと結合する現実において、12207を15288(システム)・42001(AI)・MLOps・SBOMサプライチェーンセキュリティと整列して運用してこそ、重複と死角をなくせる。展望の観点から、12207は今後も15288との調和を強化し、アジャイル・DevOps・AIライフサイクルを包含する方向に進化するであろうし、技術士は個別規格の暗記ではなく、これらを「一つのライフサイクルガバナンス」として編み上げる統合設計力量を備えるべきである。

第五に、国内の公共・調達環境での実務的活用度を考慮すべきである。 公共SI事業の作業定義・成果物標準・監査基準を設計する際、12207のプロセス体系は発注者-事業者間の責任境界を明確にする準拠となる。ただし国内SW事業の対価算定・監査制度のような現実制度との整合性を合わせるテーラリングが必要であり、規格を形式的に引用のみして実際のプロセスと乖離する「宣言的適用」を警戒すべきである。結局12207は独立した規範ではなく、組織の品質・調達・セキュリティ・AIガバナンス全般とかみ合って運用されるときに実質的価値を発揮する。

参考資料

ISO/IEC/IEEE 12207:2017, "Systems and software engineering — Software life cycle processes": https://www.iso.org/standard/63712.html
ISO/IEC/IEEE 15288:2015, "Systems and software engineering — System life cycle processes": https://www.iso.org/standard/63711.html
ISO/IEC 33001:2015, "Information technology — Process assessment — Concepts and terminology": https://www.iso.org/standard/54175.html

一言まとめ: ISO/IEC 12207はソフトウェアの取得・供給・開発・運用・保守・廃棄の全ライフサイクルを標準プロセスとして定義した国際規格であり、原版の基本・支援・組織の3分類から2017年改訂でISO/IEC 15288と調和した合意・組織支援・技術管理・技術の4大プロセスグループに再編され、特定の方法論を強制せずテーラリングを通じて適用される「プロセス定義の共通言語」であり、SPICE・CMMIのプロセス評価・改善の土台である。