共通フレーム2007 第2版改訂情報 - IPA共通フレーム2007（第2版）に含めた（→ 補足説明集の表6-1 参照）。第3部においても、プロセスごとに規定内容と関連が深い『原理原則17ヶ条』を

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright © 2009 IPA, All Rights Reserved

共通フレーム共通フレーム2007 2007 第第22版版改訂情報改訂情報

～～

第第11版との差異版との差異

～～

2009／11／02IPA／SEC

エンタプライズ系プロジェクト

ビジネスプロセス改善領域

プロセス共有化WG

確定版

Software Engineering Center 2

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

Copyright © 2009 IPA, All Rights Reserved

目次■

第２版

第１部、第２部における改訂内容

■ 〃

第３部における改訂内容

■ 〃

第４部における改訂内容

■ 〃

第５部における改訂内容

■ 〃

補足説明集における改訂内容

■ 〃

用語集、参考文献、索引の改訂内容




■

第２版第１部、第２部における改訂内容

★共通フレーム2007 第２版の表紙・背表紙

★共通フレーム2007 （第１版，第２版）の位置づけ

★数字でわかる「第１版」と「第２版」の違い

★共通フレームのプロセス体系

★共通フレームの設計思想として「超上流の重視」を追加

★「請負・準委任の問題」への提言を追加

★「多段階の見積り方式」の提言を明言

★「要求」と「要件」の概念整理に基づく用語変更

★第2部における「付２－２」の見方

★プロセス名称、アクティビティ名称の変更

★タスク名称の変更

（注）上記に示す内容は、第2版改訂内容の一部です。




★共通フレーム2007 第２版の表紙・背表紙




★共通フレーム2007 （第１版，第２版）の位置づけ

JIS化X 0160-1996

共通ﾌﾚｰﾑ98(1998年)

共通フレーム20XX

共通フレーム2007（第１版，’07年10月）

JIS化X0170：2004

ISO/IEC15288：2002

ISO 追補２

(2004)

JIS X 0160：2007（ISO追補１・２

を

含む和訳版）

ISO 追補１

(2002)

ISO/IEC12207：1995

追補１・２のJIS原案

共通フレーム2007（第２版，’09年10月）

新版

12207：2008 JIS化（2010年度）

新版

15288：2008 JIS化

（未定）

【システムライフサイクルプロセス】

【ソフトウェアライフサイクルプロセス】

取組み中

未実現

実現済み

超上流の本

ビジネスを改善する新しい取り決め




★数字でわかる「第１版」と「第２版」の違い

【背景】

第１版から第２版へ、どの程度変化したのかを、各項目について定量的に明らかにする。

【評価項目】

①

プロセスの数

②

アクティビティの数

③

タスクの数

④ 図表の数

⑤

索引に掲載した用語数

⑥

書籍のページ数

⑦

書籍の価格

⑧

第3部で改訂した範囲

（a）プロセス

（b）アクティビティ

（c）タスク

【第１版】

26

123

456

図：56

表：6

448

320

2,381円（税別）

【第２版】

26 （うち名称変更：

1）

123 （うち名称変更：11）

472 （うち名称変更：58、新規に追加：16）

図：60 （うち改訂：41、削除：2、

表：7 新規作成：7）

244 （精選した数）

344 （表紙、折込等を除く）

（注）320頁のうち改訂頁数：283、88％相当。

2,381円（税別）

規定内容を、何かしら改訂した範囲

（a）

26プロセスのうち、

22個を改訂

（b）123アクティビティのうち、15個を改訂

（c）456タスクのうち、

161個を改訂

（注）新規追加のタスクはカウント対象外。




共通フレームの修整

システム監査プロセス

システム監査の視点

文書化プロセス

構成管理プロセス

支援ライフサイクルプロセス

管理プロセス

環境整備プロセス

改善プロセス

人的資源プロセス

資産管理プロセス

再利用施策管理プロセス

ドメイン技術

プロセス

組織に関するライフサイクルプロセス

主ライフサイクルプロセス

問題解決プロセス

ユーザビリティ（使用性向上）プロセス

品質保証プロセス

検証プロセス

妥当性確認プロセス

共同レビュープロセス

監査プロセス

品質管理の視点

企画と要件定義の視点

運用プロセス

運用の視点

開発プロセス

エンジニアリングの視点

保守プロセス

企画プロセス

要件定義プロセス

取得プロセス

供給プロセス

契約と合意の視点

契約の変更管理プロセス

：規格部分

：共通フレームで拡張した部分

：追補で変更，追加された部分

修整プロセス

（※１）

上記の図は、『共通フレーム2007』（第2版）の

p.38 に掲載。

★共通フレームのプロセス体系




★共通フレームの設計思想として「超上流の重視」を追加

【背景】

第１版では、「超上流の重視」について明確に触れられていない。そのため、第２版で明記する。

●

第１版では、「まえがき」で少し触れられているだけで、第１部～第５部において

書かれていない。共通フレーム２００７

第１版

第２版

●

第２部「5.1 共通フレーム作成における設計思想」で、日本独自の考え方として

「超上流の重視」を明記した。

⇒

ここで初めて、

『経営者が参画する要求品質の確保（第2版）』との関係を紹介。

●『経営者が参画する要求品質の確保（第2版）』から

原理原則17ヶ条を取出し、

共通フレーム2007（第2版）に含めた（→

補足説明集の表6-1 参照）。

⇒

第３部においても、プロセスごとに規定内容と関連が深い『原理原則17ヶ条』を

ガイダンスに列挙して（留意点／行動規範として）、「気づき」を促すように工夫した。

SEC BOOKS『経営者が参画する要求品質の確保（第2版）』において、

「超上流の重要性」を説いている。重要な重要な関係関係




★「請負・準委任の問題」への提言を追加

【背景】

V字モデルにおいて、超上流における取引契約類型の対称性を確保することは、取引の適正化につながることを明

言する。この提言は、契約に係るトラブルの発生を予防する手段のひとつとなる。

システム要件定義システム要件定義

プログラミングプログラミング

要件定義要件定義

システムテストシステムテスト

運用テスﾄ運用テスト

ソフトウェア設計ソフトテストシ

ス

テ

ム

業

務

システム化の方向性・システム化計画

運用・評価

ソフトウェア

事

業

システム方式設計システム結合

システムレベルの設計

システム方式設計

ソフトウェア設計

ソフトウェアテスト

システム結合

システムレベルのテスト

システム要件定義システム要件定義


要件定義要件定義

システムテストシステムテスト

運用テスﾄ運用テスト

ソフトウェア設計ソフトテストシ

ス

テ

ム

業

務

システム化の方向性・システム化計画

運用・評価

ソフトウェア

事

業

システム方式設計システム結合

システムレベルの設計

システム方式設計

ソフトウェア設計

ソフトウェアテスト

システム結合

システムレベルのテスト

準委任に！

準委任のとき準委任のとき




★「多段階の見積り方式」の提言を明言

【背景】

見積りに起因するトラブルを減少させるために、「モデル契約」で推奨され編著者としても望ましいと考える「多段階

の見積り方式」を強調して提言する

（第１版における第1部 2.（6）項の表現を書き直す）。

仮試算試算概算確定

システム化の方向性

設計システム化計画

わずかな情報／高いリスク

終的な規模終的な規模

情報の充実／低いリスク

誤差

製作要件定義

規模規模

「不確定要素が多い中での見積りを，プロジェクトの目標値として

設定すべきではない」

※SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～（第２版）」より引用・一部改修※SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～（第２版）」より引用・一部改修

時間

「あいまいさが多く残る段階の見積りを，より明確になった段階で，

再見積りできるルールづくり等が，プロジェクト成功の鍵となる」

仮試算試算概算確定

システム化の方向性

設計システム化計画

わずかな情報／高いリスク

終的な規模終的な規模

情報の充実／低いリスク

誤差

製作要件定義

規模規模

「不確定要素が多い中での見積りを，プロジェクトの目標値として

設定すべきではない」

※SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～（第２版）」より引用・一部改修※SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～（第２版）」より引用・一部改修

時間

「あいまいさが多く残る段階の見積りを，より明確になった段階で，

再見積りできるルールづくり等が，プロジェクト成功の鍵となる」




★「要求」と「要件」の概念整理に基づく用語変更（１／３）

【背景】

国際標準で使用されている「requirements」の訳語として、「要求」と「要件」がある。この2つの用語の概念を整理し

た上で、「共通フレーム2007」の文章全般にわたって使用箇所を見直し、適切な訳語を当てはめる。

【プロセス共有化WGにおける合意事項】

➀

「要求」「要件」は、ともに

requirements

の訳語である。

➁

「要求」を一般的な訳語とする。ただし、「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う。

➂

「要求」「要件」以前のものを、「ニーズ(needs)」という。

期待(expectation)、要望(desire/wants)、思い(wish)、夢(dream)、意図(intension)などは、ニーズの類義語である。

システム

業務(運用)

システム運用・操作

企業環境外部環境

Reqプロセス

(企業レベル)

トップレベルのニーズ

Reqプロセス

(業務レベル)

BRS

事業要件

ニーズ

Reqプロセス(システムレベル)

BRS

ニーズ

業務要件

SyRS

システム要件

Reqプロセス

(ソフトウェアレベル)

ニーズ

SRS

ソフト要件

BRS : Business Requirements Spec.

SyRS : System Req’ts Spec.

SRS : Software Req’ts Spec.

米国原案日本案

ISO/IEC JTC1/SC7/WG7国内小委員会2009.10提供

Example of the Sequence of

Req’ts Processesand Specifications

システム

業務(運用)



Reqプロセス

(企業レベル)


Reqプロセス

(業務レベル)

BRS

事業要件

ニーズ


BRS

ニーズ

業務要件

SyRS

システム要件

Reqプロセス


ニーズ

SRS

ソフト要件

システム

業務(運用)



Reqプロセス

(企業レベル)


Reqプロセス

(業務レベル)

BRS

事業要件

ニーズ


BRS

ニーズ

業務要件

SyRS

システム要件

Reqプロセス


ニーズ

SRS

ソフト要件

BRS : Business Requirements Spec.

SyRS : System Req’ts Spec.

SRS : Software Req’ts Spec.

米国原案日本案

ISO/IEC JTC1/SC7/WG7国内小委員会2009.10提供

Example of the Sequence of

Req’ts Processesand Specifications




★「要求」と「要件」の概念整理に基づく用語変更（２／３）

頁場所変更前変更後頁場所

8 (4) 1行目システムに対する要求システムに対するニーズ 8 (4) 1行目

9 (6) 1行目要求が曖昧なまま曖昧なニーズのまま 9 (6) 1行目

10 (7) 1行目要求仕様要件 10 (7) 1行目

10 (7) 7行目要件定義仕様要件 10 (7) 6行目

11 (12) 8行目変更要求仕様変更 12 (12) 8行目

20 (3) 8行目要求仕様要件 20 上から 1行目

31 (1)(a) 1行目システムの要求品質システムの品質 34 (1)(a) 1行目

32 (e)全体（省略）（省略） 34 (b)全体

33 上から 1行目要求を業務要件にニーズを業務要件に 35 上から 9行目

35 (3) 3行目システム要求で構成システム要件で構成 39 (3) 2行目

〃　〃システム要求が定めシステム要件が定め〃 (3) 3行目

40 6.1 10行目新規開発要求が上がった新規開発ニーズが上がった 44 6.1 11行目

43 4行目プロジェクトからの要求プロジェクトからの要求事項 46 下から 2行目

〃〃契約上の要求契約上の要求事項〃下から 1行目

43 下から 2行目システム要求事項システム要件 47 (f) 3行目

46 下から 7行目 9001に基づいた品質要求 9001に基づいた品質要求事項 51 上から 1行目

51 1.4.2.1 経営要求経営上のニーズ 55 1.4.2.1

79 1.1.5.2 システム要件定義に従ってシステム要件に従って 86 1.1.5.2

80 ガイダンス 11行目要求仕様を反映している要件を反映している 87 ガイダンス 10行目

83 ガイダンス 4行目要求仕様の変更仕様変更 91 ガイダンス 1.2.3.4

94 1.4.2.1 経営要求経営上のニーズ 103 1.4.2.1

〃 1.4.2.1 2行目経営要求経営上のニーズ〃 1.4.2.1 2行目

101 成果(3) 要求事項ニーズ 110 成果(3)

119 1.6.10.2 2行目要件(細字) 要件(太字) 129 1.6.10.2 2行目

第１版第２版




★「要求」と「要件」の概念整理に基づく用語変更（３／３）

頁場所変更前変更後頁場所

125 1.7.1.6(a) 要求機能要件 136 1.7.1.6(a)

126 1.7.1.9(a) 要求機能要件〃 1.7.1.9(a)

129 1.7.3.2(a) への要求定義に対する要件 139 1.7.3.2(a)

133 1.7.6.2 これらの要求これらの要求事項 143 1.7.6.2

〃 1.7.7.1(a) 要求機能要件〃 1.7.7.1(a)

134 1.7.8.1(a) 要求機能要件 144 1.7.8.1(a)

140 ガイダンス 7行目機能的要求情報機能要件 150 ガイダンス 7行目

〃　〃インタフェース要求事項インタフェース要件〃　〃

〃　〃 11行目新しい要求事項新しい要求〃　〃 10行目

〃　〃問題又は要求事項問題又は要求〃　〃

〃　〃 15行目更新済の要求事項更新済の要求〃　〃 14行目

162 2.4.2.3 2行目システム要求事項システム要件 173 2.4.2.3 2行目

〃　〃ソフトウェア要求事項ソフトウェア要件〃　〃

〃　〃 2行目システム要求事項システム要件〃　〃 2行目

232 上から 1行目要求変更仕様変更 244 上から 1行目

〃上から 3行目要件確定の曖昧さ要件確定の不十分さ〃上から 3行目

〃図4-3 契約の変更要件契約の変更要求〃図4-3

235 図4-7 (2) 経営要求経営上のニーズ 247 図4-7 (2)

238 図4-10の直上要求分析段階で（他の理由から全く異なる解説文に変更） 249 (a)全体

240 上から 1行目機能要求機能要件 251 (b) 3行目

271 5. 2行目要件の分析漏れニーズの抽出漏れ 295 (3) 2行目

295 life cycle model システムの要求定義から企画から 316ライフサイクルモデル　2行目

第１版第２版




★第2部における「付２－２」の見方

【背景】

共通フレーム2007の使用者である組織／企業が、自らの組織（企業）標準と共通フレーム2007との間でマッピング

を行っている場合、「付２－２」の変更箇所は、どことどこなのかを容易に確認できるようにする。

共通フレーム2007 共通フレーム98JIS X 0160（追補含）

1.5　　要件定義プロセス

　1.5.1　　　プロセス開始の準備

　　1.5.1.1　要件定義作業の組立て

　　1.5.1.2　必要な支援プロセスの組込み

　　1.5.1.3　利害関係者の定義と役割の確認

　　1.5.1.4　要件合意及び承認ルールの決定

　　1.5.1.5　要件定義環境の準備

　　1.5.1.6　要件定義プロセス実施計画の作成

　1.5.2　　　利害関係者要件の定義

　　1.5.2.1　利害関係者のニーズの識別と制約事項の定義

　　1.5.2.2　業務要件の定義

　　1.5.2.3　組織及び業務環境要件の具体化

付2-2

共通フレーム2007，共通フレーム98 と ISO/IEC 12207 （JIS X 0160 含追補）の対比（注）この対比表の「共通フレーム2007」列において下線付きの箇所は、第1版と異なるところ（第2版の改訂箇所）を示す。

名称に、下線あり　　　　　　　　　　　→　名称の変更を示す。

項番と名称に、下線あり　　　　　　　　　　　→　タスクの追加を示す。

項番のみに、下線あり　　　　　　→　項番が単純にずれたことを示す。




★プロセス名称、アクティビティ名称の変更

アクティビティ名称の変更

項番

旧名称

----

-------------------------------------

2.3.4

品質システムの保証

2.9.2

人間中心の設計

2.9.3

人間の観点からみた戦略，導入，及び支援

3.4.2

教育訓練の要求事項の定義

3.4.3

適格な要員の採用

3.4.4

要員の実績評価

3.4.5

プロジェクトチームの要求事項の確立

3.6.2

ドメインの特定

3.6.3

再利用の評価

3.6.4

計画立案

3.7.4

資産の用意

項番

新名称

----

-------------------------------------

2.3.4

品質マネジメントシステムの保証

2.9.2

人間中心設計

2.9.3

戦略，導入及び支援の人間的側面の考慮

3.4.2

教育訓練要件の定義

3.4.3

有資格要員の採用

3.4.4

要員業績の評価

3.4.5

プロジェクトチーム要件の確立

3.6.2

ドメインの識別

3.6.3

再利用アセスメント

3.6.4

計画

3.7.4

資産の準備

プロセス名称の変更

項番

旧名称

----

-------------------------------------

3.6

再利用プログラム管理プロセス

項番

新名称

----

-------------------------------------

3.6

再利用施策管理プロセス

対象：１１アクティビティ

【背景】

作業内容を、適切に表現する名称に改める。

また、名称変更に際して、必要に応じて、追補（JIS X 0160:2007）の訳語も考慮する。




★タスク名称の変更（１／３）

【背景】

作業内容を、適切に表現する名称に改める。

また、名称変更に際して、必要に応じて、追補（JIS X 0160:2007）の訳語も考慮する。

タスク名称の変更

項番

旧

名

称

----

------------------------------------------

1.4.1.1

企画作業の定義

1.4.1.2

必要な支援プロセスの実施

1.4.2.1

経営要求，課題の確認

1.4.3.8

システム化に必要な付帯機能，付帯設備に関する

基本方針の明確化

1.5.1.1

要件定義作業の定義

1.5.1.2


1.5.2.3

新組織及び業務環境要件の具体化

1.6.1.1

開発作業のライフサイクルモデルへの対応付け

1.6.1.2


1.6.6.8

ソフトウェア詳細設計の共同レビュー

1.7.1.3

運用時の問題管理手続きの確立

1.7.3.2

移行計画の作成及び実行

1.8.1.3

修正手続きの確立

1.8.5.2

移行計画の作成と実行

2.1.1.1

文書計画の立案と実施

2.3.1.4

品質保証アクティビティ及びタスクの実行

2.3.4.1

JIS Q 9001（ISO 9001）への適合

2.6.1.1

レビューの実施

2.6.1.4

問題点記録と解決

項番

新

名

称

----

------------------------------------------

1.4.1.1

企画作業の組立て

1.4.1.2

必要な支援プロセスの組込み

1.4.2.1

経営上のニーズ，課題の確認

1.4.3.8

システム化に必要な付帯機能，付帯設備に対する

基本方針の明確化

1.5.1.1

要件定義作業の組立て

1.5.1.2


1.5.2.3

組織及び業務環境要件の具体化

1.6.1.1

開発作業の組立て

1.6.1.2


1.6.6.8

ソフトウェア詳細設計の共同レビューの実施

1.7.1.3

問題管理手続きの確立

1.7.3.2

移行計画の文書化と検証

1.8.1.3

問題管理手続きの確立

1.8.5.2


2.1.1.1

文書計画の立案

2.3.1.4

実施計画の実行

2.3.4.1

JIS Q 9001 （ISO 9001）

の適用

2.6.1.1

レビューの実施時期の設定

2.6.1.4

問題点の記録と解決

対象：５８タスク




★タスク名称の変更（２／３）


項番

旧

名

称

----

------------------------------------------

2.7.1.1

監査時期の確認

2.7.1.5

監査指摘事項の記録

2.9.1.2

人間中心の設計プロセス計画の実施

2.9.2.6

ユーザビリティの開発

3.1.2.1

実施プロセス実行計画の策定

3.1.4.1

計画の実行の開始

3.1.4.2

実行の監視

3.2.2.1

環境の構成計画の策定

3.4.3.1

採用プログラムの確立

3.4.5.1

プロジェクトチームの要求事項の定義

3.5.1.2

資産管理の実施

3.5.1.3

資産管理計画の共同レビュー

3.5.2.2

資産の分類

3.5.2.3

共同レビューの実施

3.5.3.3

資産の再利用分類

3.6.1.2

スポンサの指名

3.6.1.4

運営機能の確立

3.6.1.5

支援機能の確立

3.6.2.3


3.6.3.1

再利用能力の評価

3.6.3.2

再利用可能性の評価

3.6.3.3

再利用評価結果の勧告

項番

新

名

称

----

------------------------------------------

2.7.1.1

監査の実施時期の設定

2.7.1.5

問題点の記録と解決

2.9.1.2

人間中心の設計プロセス計画の立案

2.9.2.6

ユーザビリティの設計開発

3.1.2.1

プロセス実行計画の策定

3.1.4.1

プロセス実行計画の開始

3.1.4.2

プロセス実行の監視

3.2.2.1

環境構成計画の策定

3.4.3.1

採用施策の確立

3.4.5.1

プロジェクトチーム要件の定義

3.5.1.2


3.5.1.3

資産管理計画の共同レビューの実施

3.5.2.2

資産分類体系の作成

3.5.2.3

資産管理の仕組みの共同レビューの実施

3.5.3.3

資産の分類

3.6.1.2

後援者（スポンサ）の指名

3.6.1.4

運営機関の確立

3.6.1.5

支援機関の確立

3.6.2.3

ドメイン評価結果の共同レビューの実施

3.6.3.1

再利用能力のアセスメント

3.6.3.2

再利用可能性のアセスメント

3.6.3.3

再利用アセスメント結果の勧告




★タスク名称の変更（３／３）

項番

旧

名

称

----

------------------------------------------

3.6.4.4


3.6.6.1

再利用戦略の達成と効果の評価

3.6.6.2

評価結果の提供

3.6.6.3

評価結果の反映による改善

3.7.1.3


3.7.2.2

ニーズの特定

3.7.2.4

語彙集の作成

3.7.2.6

ドメインモデルと語彙集の評価

3.7.2.7


3.7.3.1

ドメインアーキテクチャの作成

3.7.3.2

ドメインアーキテクチャの評価

3.7.3.3

資産の仕様の作成

3.7.3.4

資産の評価

3.7.3.5


3.7.3.6

ドメインアーキテクチャの提出

3.7.4.1

資産の開発

3.7.4.4


項番

新

名

称

----

------------------------------------------

3.6.4.4

再利用計画の共同レビューの実施

3.6.6.1

再利用戦略の達成と効果のアセスメント

3.6.6.2

アセスメント結果の提供

3.6.6.3

アセスメント結果の反映による改善

3.7.1.3


3.7.2.2

ニーズの識別

3.7.2.4

用語集の作成

3.7.2.6

ドメインモデルと用語集の評価

3.7.2.7

ドメイン分析の共同レビューの実施

3.7.3.1

ドメインの基本構造の作成

3.7.3.2

ドメインの基本構造の評価

3.7.3.3

資産の仕様書の作成

3.7.3.4

資産の仕様の評価

3.7.3.5

ドメイン設計の共同レビューの実施

3.7.3.6

ドメインの基本構造の提出

3.7.4.1

資産の作成

3.7.4.4

資産の共同レビューの実施





■

第２版第３部における改訂内容

★第3部『｢共通フレームとガイダンス｣の見方』の例示を交代

★第3部で

プロセスに関連する「原理原則17ヶ条」を追記

★第3部で「共同レビューの実施」タスク（作業）を追記

★第3部で「検証」「妥当性確認」を行うように明記

★第3部の各所において、呼出される主プロセスを追加

★第3部で

プロセスの表示順序を実際の流れに即して変更

★第3部の主プロセスで「システム監査を実施する」旨を追記

★第3部で

外部調達時、情報セキュリティ対策の必要性を追記

★タスクの関係性の整理、粒度の見直し

★第3部で

「運用プロセス」内でガイダンスを追加

★第3部で「保守プロセス」の規定内容を修正・追加

★第3部の「保守プロセス」のガイダンス内容を更新

★第3部で「構成管理プロセス」の規定内容を改訂

★第3部で「品質保証P」でユーザビリティPの呼出しを追加

★第3部で「品質マネジメントシステム」という表記に改訂

★第3部で「3.4 人的資源プロセス」内の表記変更

★第3部で「3.5 資産管理プロセス」内の表記変更

★第3部で「3.6 再利用施策管理プロセス」内の表記変更

★第3部で「3.7 ドメイン技術プロセス」内の表記変更

★第3部で「4. システム監査プロセス」内の表記変更

★第3部で、その他こまごまとした規定内容変更

★第3部の規定内容（共通フレーム定義体）を変更した項番





★第3部『｢共通フレームとガイダンス｣の見方』の例示を交代

【背景】

第１版の例示は、日本独自に追加した規定が含まれていなかった（表示ミスも含まれていた）。そのため、第２版で

は、例示する箇所を選び直して、JIS規格の規定内容と日本独自に規定した内容とが含まれるようにする。

（※１）

上記の「見方」は、『共通フレーム2007』（第2版）の

p.77 に掲載。

（※２）

文字種について、書籍上では、「太字」はゴシック体に、細字は「明朝体」による表示となっている。

（本体の形式）

1.6.10.4 システム適格性確認テストの準備

システムの適格性確認要求事項ごとに，システム適格性確認テストを行うため，一連のテス

ト，テストケース（入力，出力及びテスト準備）及びテスト手順を作成し，文書化する。開発者は，

結合したシステムがシステム適格性確認テストを実施できる状態にあることを確認する。

テスト実施にあたって各種マスタファイルのデータ，トランザクションデータを作成し，テスト環

境に登録する。

1.6.10.4：データは本稼働で用いるデータにできる限り近いものを設定する。現行システムのデータ

が存在する場合は，セキュリティを考慮し移行して利用する。

ガイダンス

（青色の囲み）

共通フレーム定義体

を表す。（文字種）

国際標準：太字、国際標準の追補：太字／斜体、国内での追加部分：細字。（ガイダンス）

国内で追加した解説を表す。

国際標準との差異を明示している（※２）。




★第3部でプロセスに関連する「原理原則17ヶ条」を追記

【背景】

プロセスごとに、その規定内容と関連が深い「原理原則17ヶ条」を、ガイダンスに列挙することによって、使用者が

17ヶ条の言葉に啓発されて、作業上の留意点／行動規範となるようにする。

【例】

1.5 要件定義プロセス

の「ガイダンス」において

1.5：

1. ・・・

2. ・・・

3. 「要件定義プロセス」については，「超上流から攻めるIT化の原理原則17ヶ条」における以下の原理原則を

参照するとよい。

原理原則[１]

ユーザとベンダの想いは相反する

原理原則[８]

システム化の方針・狙いの周知徹底が成功の鍵となる

原理原則[９]

要件定義は発注者の責任である

原理原則[10]

要件定義書はバイブルであり，事あらばここへ立ち返るもの

ガイダンスの項番

参照している「原理原則17ヶ条」の項番

---------------

-------------------------------------------------------------------------

1.1 の

3.

－

1条、2条、5条、9条、10条、16条、17条

1.3 の

3.

－

1条、10条、16条、17条

1.3.3

－

2条

1.3.4

－

2条、4条

1.4 の

2.

－

1条、8条

1.4.2

－

7条

1.4.3

－

2条、4条、6条、7条、15条

1.5 の

3.

－

1条、8条、9条、10条

1.5.2

－

3条、6条、11条、12条、13条、14条、15条、16条、17条

1.5.3

－

2条、3条、4条、7条

1.7 の

3.

－

8条、12条、13条

【追記した箇所】




★第3部で「共同レビューの実施」タスク（作業）を追記

【背景】

「共同レビュー」を必要とするプロセス又はアクティビティにおいて、「共同レビューを行う」旨を明記することによって、

共同レビューの実施を促進する。

【記号の意味】

項番：タスク番号、

○：JIS X 0160に明記済、

★：第１版で追記、

●：第２版で追記

○

1.1.4.1 （取得プロセス内）

○

1.2.6.2 （供給プロセス内）

★

1.6.2.3 （開発プロセスのシステム要件定義）

★

1.6.3.5 （

〃

システム方式設計）

○

1.6.4.3 （

〃

ソフトウェア要件定義）

○

1.6.5.7 （

〃

ソフトウェア方式設計）

○

1.6.6.8 （

〃

ソフトウェア詳細設計）

○

1.6.8.6 （

〃

ソフトウェア結合）

★

1.6.10.6 （

〃

システム結合）

○

1.8.4.1

（保守プロセス内）

○

3.5.1.2 (c) （資産管理プロセス内）

○

3.5.1.3 （

〃

）

○

3.5.2.3 （

〃

）

○

3.6.2.3 （再利用施策管理プロセス内）

○

3.6.4.4 （

〃

）

○

3.7.3.5 （ドメイン技術プロセス内）

○

3.7.4.4 （

〃

）

●

1.3.4.1 （契約の変更管理プロセス内）

●

1.4.1.2 (d) （企画プロセス内）

●

1.5.1.2 (d) （要件定義プロセス内）

●

1.6.9.4 （開発Pのソフトウェア適格性確認テスト内）

●

1.6.11.3 （

〃

システム適格性確認テスト内）

●

1.7.1.11 （運用プロセス内）

●

1.7.2.3 （

〃

）

●

1.7.3.2 （

〃

）

●

1.7.7.1 （

〃

）

●

1.7.8.1 （

〃

）

●

3.1.2.2 （管理プロセス内）

●

3.1.5.3

（

〃

）

●

3.2.1.3 （環境整備プロセス内）

●

3.2.2.2 （

〃

）

●

3.3.1.2 （改善プロセス内）

●

3.4.1.2 （人的資源プロセス内）

●

3.4.2.2 （

〃

）

●

3.4.3.2 （

〃

）

●

3.4.4.2 （

〃

）

●

3.4.6.2 （

〃

）

●

5.4.2 （修整プロセス内）

＋＋

●：21箇所○：14箇所、

★：3箇所




★第3部で「検証」「妥当性確認」を行うように明記

【背景】

プロセス品質や製品品質を確保するため、「○○を確認する。」という記述レベルではなく、「○○を検証する」又は

「○○の妥当性確認を行う」といったように、なすべき活動を明確にする。

項番

タスク名称

------------

----------------------------------------------------------------------------

1.4.2.6 －

業務の新全体像の作成

1.4.3.16

－

経営事業戦略，情報戦略，システム化構想との検証

1.5.3.1 －

要件の合意と承認

1.7.3.2

－


1.8.2.4

－

文書化

1.8.5.4

－

新旧環境の並行運用と旧環境の停止

【明記した箇所】

【例】

1.4.2.6

業務の新全体像の作成

「

・・・

全体イメージを作成し、業務機能と組織モデル、新システムとが整合しているか確認する。」

「

・・・

全体イメージを作成し、業務機能と組織モデル、新システムとが整合しているかを、検証プロセス

（2.4参照）及び妥当性確認プロセス（2.5参照）に従って検証及び妥当性確認を行う。」




★第3部の各所において、呼出される主プロセスを追加

【背景】

契約の変更管理、企画、要件定義の各プロセスが追加されたとき（共通フレーム98／第１版にて）、主プロセスから

他の主プロセスを呼出す箇所において、呼出される主プロセスの追記が漏れていたための修正である。

【見方】項番：アクティビティ又はタスクの項番、「･･･」：規定内容の抜粋、太字：追記された主プロセス

を示す

1.7.7.1

システム運用の評価

「また

～

場合には，問題解決プロセス，保守プロセス，企画プロセス，要件定義プロセス又は開発プロセスに引き継ぐことができる。」

1.7.8.1

業務運用の評価

「また

～


1.7.9.1

投資効果及び業務効果の評価

「また

～


2.4

検証プロセス

「費用対効果の見地から

～

これを必要とするプロセス（例えば，供給，企画，要件定義，開発，運用，又は保守プロセス）と

～

」

2.8

問題解決プロセス

「問題解決プロセスは，企画，要件定義，開発，運用，保守又はその他のプロセスの実行の過程で発見された

～

」

2.9

ユーザビリティ（使用性向上）プロセス

「ユーザビリティ（使用性向上）プロセスは，

～

を含む。このプロセスは，ソフトウェア又はシステムの企画，要件定義，開発，運用及び

保守の全期間に渡って

～

」

「開発者は

～

を管理する。ユーザビリティの専門家は，

ユーザビリティアクティビティ及びユーザビリティアクティビティからの結果と

企画プロセス，要件定義プロセス，開発プロセス，運用プロセス，保守プロセス及び支援ライフサイクルプロセスの

～

を融合させ

る。」

3.2

環境整備決プロセス

「環境整備プロセスは，～

である。環境には，取得，供給，契約の変更管理，企画，要件定義，開発，運用又は保守のための

～

」




★第3部でプロセスの表示順序を実際の流れに即して変更

【背景】

資産管理プロセス、再利用施策管理プロセス、ドメイン技術プロセスが3つとも引用されている箇所において、その

表示順序を、実際の活動順序に合うように変更する（ドメイン技術→資産管理→再利用施策管理の順とする）。

項番

プロセス名称

------------

-------------------------------------------------------------------

1.4 －

企画プロセス

1.5 －


1.6 －

開発プロセス

【変更した箇所】

【第1版】

「

また，資産管理プロセス（3.5参照），再利用施策管理プロセス（3.6参照），ドメイン技術プロセス（3.7参照）に従って

蓄積された資産を再利用してもよい。」

【第2版】

「また，ドメイン技術プロセス（3.7参照），資産管理プロセス（3.5参照），再利用施策管理プロセス（3.6参照）に従って

蓄積された資産を再利用してもよい。」

項番

プロセス名称

------------

-------------------------------------------------------------------

1.1 －

取得プロセス

1.2 －

供給プロセス

1.3 －


1.7 －

運用プロセス

1.8 －

保守プロセス


（書籍）

図図44--2121

参照参照




★第3部の主プロセスで「システム監査を実施する」旨を追記

【背景】

システム監査プロセスの活用を促し、主プロセスそれぞれの適正実施を図る。

項番

プロセス名称

------------

-------------------------------------------------------------------

1.1 －

取得プロセス

1.2 －

供給プロセス

1.3 －


1.4 －

企画プロセス

1.5 －


1.6 －

開発プロセス

1.7 －

運用プロセス

1.8 －

保守プロセス

【対象プロセス】

【主プロセスの末尾に以下の1文を追加】

「

システム監査プロセス（4.参照）に従って，●●プロセスを対象にシステム監査を実施する。」




★第3部で外部調達時、情報セキュリティ対策の必要性を追記

【背景】

外部調達する場合、必要な情報セキュリティ対策を忘れないで実施するよう、ガイダンスに追記する。

項番

第3部のガイダンス（内容の一部）

-------------

-------------------------------------------------------------------

1.1.2.1(f) －

外部委託先管理に関しては、適切な情報セキュリティ対策を

～

。

1.1.4.1 －

供給者に対して適切な情報セキュリティ対策を

～

。

1.2.4.5(l) －

情報セキュリティ対策については、

～

。

1.2.5.4 －

外部委託先に対して適切な情報セキュリティ対策を

～

。


【ガイダンスに以下のような文を追加】

「

外部委託先管理については、適切なセキュリティ対策を

～

～

を参照のこと。」




★タスクの関係性の整理、粒度の見直し（１／２）

【背景】

企画プロセス、要件定義プロセスのタスクにおいて、タスクの順序関係やタスクの粒度に問題があると思われるもの

を取り上げ、必要な調整を図る。

第１版

第２版

（本図において便宜上、

項番は第1版のままとした）

次のシートに、これに関連して

改訂した箇所を示します。

1.4.3 システム化計画の立案 1.5.2 利害関係者要件の定義

1.4.3.1 システム化計画の基本要件の確認 1.5.2.1 利害関係者のニーズの識別と制約事項の定義1.4.3.2 対象業務の内容の確認 1.5.2.2 業務要件の定義1.4.3.3 対象業務のシステム課題の定義 1.5.2.3 新組織及び業務環境要件の具体化1.4.3.4 対象システムの分析 1.5.2.4 機能要件の定義1.4.3.5 適用情報技術の調査 1.5.2.5 非機能要件の定義1.4.3.6 業務モデルの作成 1.5.2.6 スケジュールに関する要件の定義1.4.3.7 システム化機能の整理とシステム方式の策定

1.4.3.8システム化に必要な付帯機能、付帯設備に対する基本方針の明確化

1.4.3.9 サービスレベルと品質に対する基本方針の明確化 1.5.3 利害関係者要件の確認1.4.3.10 プロジェクトの目標設定1.4.3.11 実現可能性の検討 1.5.3.1 要件の合意と承認1.4.3.12 全体開発スケジュールの作成 1.5.3.2 要件変更ルールの決定1.4.3.13 システム選定方針の策定1.4.3.14 費用とシステム投資効果の予測1.4.3.15 プロジェクト推進体制の策定1.4.3.16 経営事業戦略、情報戦略、システム化構想との検証1.4.3.17 システム化計画の作成と承認1.4.3.18 プロジェクト計画の作成と承認

ノーマルな前後関係粒度が逆転しているように見える関係双方に関連なく孤立しているように見えるタスク

粒度の見直し等の調整が必要と思われるタスク

1.4.3 システム化計画の立案 1.5.2 利害関係者要件の定義

1.4.3.1 システム化計画の基本要件の確認 1.5.2.1 利害関係者のニーズの識別と制約事項の定義1.4.3.2 対象業務の内容の確認 1.5.2.2 業務要件の定義1.4.3.3 対象業務のシステム課題の定義 1.5.2.3 組織及び業務環境要件の具体化1.4.3.4 対象システムの分析 1.5.2.4 機能要件の定義1.4.3.5 適用情報技術の調査 1.5.2.5 非機能要件の定義1.4.3.6 業務モデルの作成 1.5.2.6 スケジュールに関する要件の定義1.4.3.7 システム化機能の整理とシステム方式の策定

1.4.3.8システム化に必要な付帯機能、付帯設備に対する基本方針の明確化

1.4.3.9 サービスレベルと品質に対する基本方針の明確化 1.5.3 利害関係者要件の確認1.4.3.10 プロジェクトの目標設定1.4.3.11 実現可能性の検討 1.5.3.1 要件の合意と承認1.4.3.12 全体開発スケジュールの作成 1.5.3.2 要件変更ルールの決定1.4.3.13 システム選定方針の策定1.4.3.14 費用とシステム投資効果の予測1.4.3.15 プロジェクト推進体制の策定1.4.3.16 経営事業戦略、情報戦略、システム化構想との検証1.4.3.17 システム化計画の作成と承認1.4.3.18 プロジェクト計画の作成と承認

ノーマルな前後関係粒度が逆転しているように見える関係見直し終了（2009.1.26）

双方に関連なく孤立しているように見えるタスク見直し終了（2009.2.6）

粒度の見直し等の調整が必要と思われるタスク見直し終了（2009.2.17）




★タスクの関係性の整理、粒度の見直し（２／２）

【見方】項番：タスクの項番、「･･･」：規定内容の抜粋、太字：追記された内容

を示す

1.4.3.6

業務モデルの作成

「

～

，業務機能と組織をモデル化する。

1.4.2.6（業務の新全体像の作成）を実施した場合は，その検討結果に基づき詳細化する。

～また業務，組織及びシステムの主要な変更点と業務実施上の具体的課題をまとめる。」

1.4.3.12

全体開発スケジュールの作成

「

対象となったシステム全体の開発スケジュールの大枠を作成する。システム化計画を複数プロジェクトに分解する場合は，

個々にスケジュールを作成する。例えば，必要に応じて

～

，サブシステム単位に開発スケジュールを作成する。」

1.5.1.3

利害関係者の定義と役割の確認

「

要件定義者は，対象とする業務，システムに直接的あるいは間接的に関係する利害関係者の定義及びその役割についての確認を

行う。」

1.5.1.4

要件合意及び承認ルールの決定

「

要件定義者は，利害関係者間での要件定義に関する役割分担，各要件策定の責任者の設定，及び要件の合意並びに承認に至る

ルールの決定を行う。」

1.5.2.7

実現可能性とリスクの検討

「

業務要件，機能要件，非機能要件の定義にあたっては，要員，納期，コストなどの前提条件で，技術的，経済的な実現可能

性とリスクについて検討する。」

1.5.3.1

要件の合意と承認

「

要件定義者は，1.5.2.7 （実現可能性とリスクの検討）で検討した結果を踏まえ，検証プロセス

（2.4参照）及び妥当性確認

プロセス

（2.5参照）に従って，定義された要件の検証及び妥当性確認を行う。また，1.5.1.4 （要件合意及び承認ルールの

決定）で定めたルールに従って，要件の合意と承認を得る。この時，特に以下の観点で確認を行う。

～

(d) 要件を実現するための利害関係者の役割分担，責任及び作業の組立て（手順，スケジュールなど）の決定。

～」

※

上記の見直しに伴って、ガイダンス

1.4.3.15、1.4.3.17、1.4.3.18、1.5.3.1、1.5.3.1(d)の新規追加、1.5.3.2への追記などの改訂も行っている。

この2つは、旧1.5.1.1のリスト(a) (b)項から、タスクとして格上げされた。

新規に追加されたタスク




★第3部で「運用プロセス」内でガイダンスを追加

【背景】

運用開始後の初期サポートの必要性を 1.7.3.2(j) で明記し、業務運用の評価に関するガイダンスを

1.7.8 で明記す

る。

【第2版において】

1.7.3.2 (j) ：

移行の実施前に，供給者等による移行のサポートを受けることができるよう，手配しておくことを考慮する。

これは，新運用への移行直後に，テスト時には発覚しなかった事象に対処するためである。サポートを受ける

に際して事前に決めておくこととして，サポートの実施期間，あるべきシステムの状態，期待すべき初期評価

などがある。

1.7.8 ：

業務運用の評価は，1.7.1.9 （業務運用評価基準の設定）で設定したレベルを評価する。

【見方】項番：ガイダンスの項番、「･･･」：ガイダンス内容の抜粋、太字：追記／変更された内容等

を示す




【背景】

第１版での記述漏れ（欠落）を訂正するとともに、保守プロセスから呼出すプロセスとして「開発」以外にも、「企画」

「要件定義」「運用」プロセスもあることを明記する。

★第3部で「保守プロセス」の規定内容を修正・追加

図4-23　主プロセスから主プロセスの呼出し例

２．支援ライフサイクルプロセス

2.8　問題解決プロセス

1.4　企画プロセス

・システム化構想，計画の立案

　　 1.8　保守プロセス

　・プロセス開始の準備

　・問題把握及び修正分析

　・修正の実施

　1.5　要件定義　　　　プロセス

・利害関係者要件の定義

1.6　開発プロセス

1.6.2 システム要件定義

1.6.4 ソフトウェア要件定義

1.6.11システム適格性

確認テスト

1.6.7 ソフトウェアコード作成及び

テスト

1.6.9 ソフトウェア適格性確認

テスト

問題発生

発生した問題のレベルによって，呼出すプロセスが異なる

呼出し，連携

1.7.2運用テスト

1.7.9投資効果及び業務効果の

評価

1.7　運用プロセス

呼出したプロセスによって，戻りのルートも異なる

ルート１

ルート2 ルート2

ルート３ルート３

ルート１

・・・

【訂正】

（第２版の

p.146）

「

保守者は，このプロセスを管理するために具体化した管理プロ

セス（3.1参照）に従って，保守プロセスをプロジェクトレベルで管理

する。環境整備プロセス（3.2参照）に従って，保守プロセスの

基盤となる環境を確立する。修整プロセスに従って，保守プ

ロセスをプロジェクトに適した形に修整する。

～

」

（※）第１版の読者の皆様にはお詫び申し上げます。

【追加】

（第２版の

p.146、p.151）

「1.8.2.4

文書化

～

また，文書化し選択した修正案は，検証プロセス

（2.4参

照）又は妥当性確認プロセス

（2.5参照）に従って検証又は

妥当性確認を実施する。」

「1.8.3.2

修正の実施

～

また，修正対象によっては，企画プロセス（1.4参照），

要件定義プロセス（1.5参照），運用プロセス（1.7参照）を

利用してもよい。」

第４部の「第４部の「2.22.2

主プロセスから主プロセスの呼出し方と主プロセスから主プロセスの呼出し方と

その関係その関係」において、この規定部分を引用している。」において、この規定部分を引用している。




★第3部の「保守プロセス」のガイダンス内容を更新

【背景】

新の規格 JIS X 0161:2008 （ソフトウェア保守）に基づいて、第3部「1.8 保守プロセス」のガイダンス内容を更新

し、保守プロセスの利用者に役立つ情報を提供する。

【見方】項番：ガイダンスの項番、「･･･」：ガイダンス内容の抜粋、太字：追記／変更された内容等

を示す

【例】

1.8.1：保守者は，プロセス開始の準備アクティビティのなかで，保守プロセスで実施される計画及び手続きを作成する。保守計画作成は，

保守者が企画プロセスに参画し，開発プロセスと並行して実施することが望ましい。

～

入力は，旧基準線（ベースライン），システム文書，問題報告又は修正依頼などがある。出力は，保守計画，訓練計画，保守手続き，

プロジェクト管理計画，問題解決手続き，測定計画，保守マニュアル，利用者へのフィードバック計画，引き継ぎ計画，保守性

アセスメント，構成管理計画などがある。

～

1.8.1.5：保守に必要な文書を保守文書と呼ぶことがある。

【上記の例以外に、保守プロセスのガイダンス内容を変更した項番】

・1.8 の

1, 2, 4, 5

・1.8.1

・1.8.1.5

・1.8.2

・1.8.2.3

・1.8.2.4

・1.8.3

・1.8.5.3

・1.8.5.4

・1.8.6

・1.8.6.3




★第3部で「構成管理プロセス」の規定内容を改訂

【背景】

追補（JIS X 0160:2007）に沿って記述内容を見直し、その正確性を図る。また、「品目」という用語だけでは、何を指

しているのか不明であるため、語句を補う。


（１）

2.2項において、用語「品目」→「ソフトウェア品目」に改める。

（理由）

「備考」のところで、「ソフトウェア品目という用語を適宜置き換えること」と、特に、記述されていることから、

「ソフトウェア品目」で統一する。

（２）

2.2項において、以下のように、記述内容を変更する。

「・・・

構成管理プロセスは，ソフトウェアライフサイクルを通じて適用される管理的な手続き及び技術的な手続きからなる

プロセスである。

(1) システムの中の作業成果物，ソフトウェア品目を識別し，定義する。

(2) ソフトウェア品目の修正及びリリースを制御する。

(3) ソフトウェア品目及び修正依頼の状況を記録し，報告する。

(4) ソフトウェア品目の完全性，一貫性及び正確性を確実にする。

(5) ソフトウェア品目の貯蔵保管，取扱い及び納入を制御する。

・・・

」

【見方】項番：アクティビティ又はタスクの項番、「･･･」：規定内容の抜粋、太字：追記／変更された内容等

を示す




★第3部で「品質保証P」でユーザビリティPの呼出しを追加

【背景】

品質保証は、検証、妥当性確認、共同レビュー、監査及び問題解決のような支援プロセスだけではなく、ユーザビリ

ティ（使用性向上）プロセスも利用できることを強調する。


2..3

品質保証プロセス

「

品質保証は，検証（2.4参照），妥当性確認（2.5参照），共同レビュー（2.6参照），監査(2.7参照)，問題解決（2.8参

照）及びユーザビリティ（使用性向上）（2.9参照）のような他の支援プロセスの結果を利用してもよい。」

2.3.1.2

関連プロセスとの調整

「

品質保証プロセスは，関連する検証（2.4参照），妥当性確認（2.5参照），共同レビュー（2.6参照），監査（2.7参照），

問題解決（2.8参照）及びユーザビリティ（使用性向上）（2.9参照）の各プロセスと調整をとることが望ましい。」

2.3.1.3

実施計画の策定

「

(e) 検証（2.4参照），妥当性確認（2.5参照），共同レビュー（2.6参照），監査（2.7参照），問題解決（2.8参照）及び

ユーザビリティ（使用性向上）（2.9参照）の支援プロセス群から選択したアクティビティ及びタスク。」


を示す




★第3部で「品質マネジメントシステム」という表記に改訂

【背景】

追補（JIS X 0160:2007）に沿って記述内容を見直すも、追補の訳語が適切ではないと判断して、意図するところが

正確に読者に伝わるように訳し直した規定内容にする。また、その理由をガイダンスに記述する。

【第1版】

2.3.4.1

JIS Q 9001 （ISO 9001）

への適合

「

さらなる品質管理活動は，JIS Q 9001 の条項に従って保証されてもよい。」

【第2版】

2.3.4.1

JIS Q 9001 （ISO 9001）

の適用

「

さらに，JIS Q 9001 の箇条に従って，品質マネジメント活動を確実にすることができる。」


を示す

【追記したガイダンス】

2.3.4.1：追補

（JIS X 0160:2007）の「0 （追補1の序文）」に基づけば，2.3.4.1の元の規格定義を，以下の翻訳文で置き換えるように

指示されている。

「さらなる品質管理活動は，JIS Q 9001の箇条に従って達成することができる。」

しかし，共通フレームでは，以下の理由により，上記翻訳文をそのまま採用せずに一部変更している。

(1) JIS Q 9001 によれば，品質マネジメント(Quality Management)と品質管理(Quality Control)とは異なる概念であるが，

2.3.4.1の原文では「Quality Management」が使用されているため，前者の訳語を使用する。

(2) 「さらなる」の原文は「Additionally」であるが，これは副詞として，主語ではなく，述語の方を修飾しているため，「さらに」と

訳す。

(3) 述語の原文は「can be assured」である。品質マネジメント活動は「達成する」ものではなく，JIS Q 9001を参照することに

よって，組織の品質マネジメントシステムをより確実なものへと高められる旨を意図しているものと読み取れ，原文を「確実

にする」と訳した。




★第3部で「3.4 人的資源プロセス」内の表記変更

【背景】

SLCP規格の追補（JIS X 0160:2007）に沿って、表記（用語）を合わせる。

3.4

の「成果」にて

「

(1) 組織要件及びプロジェクト要件を

～

。」

「

人的資源プロセスは，～

グループとして一緒に働くためのスキル（技術）及び知識をもつ人材を提供する。」

3.4

の「アクティビティ一覧」にて

（アクティビティ名とタスク名の変更）

(2) 教育訓練要件の定義

(3) 有資格要員の採用

(4) 要員業績の評価

(5) プロジェクトチーム要件の確立

3.4.1.1

人的資源要求事項の定義

「組織要件及びプロジェクトの要件のレビューを実施し，

～

取得又は作成のための対策を，適時に，確立し，決定

しなければならない。」

3.4.2.1

知識基準の設定と教育訓練計画の策定

「組織要件及びプロジェクト要件を

～

。

～

資源要件及び教育訓練ニーズを

～

。」

3.4.2.4

教育訓練の実施

「

役割を実行するために

～

をもつように人員を教育訓練する。」

3.4.3.1

採用施策の確立

「

～

体系的な施策を確立する。」

3.4.5.2

プロジェクトチームへの権限委譲

「

チームが次のものをもっていることが確実な場合，

～。」

「 (d) プロジェクト要件を遂行するための適切な管理層による支援」

3.4.6.4

知識資産の展開手段の確立

「

～

この仕組みは，組織におけるアクセス，保管及び検索要件を支援する。」


を示す




★第3部で「3.5 資産管理プロセス」内の表記変更

【背景】


【用語の変更（統一）】

・全頁にわたって「再利用プログラム」→「再利用施策」に統一。

・3.5.3.5 の「削減及び恩恵」→「節約及び利得」へ。

・3.5.3.6 の「是正／修正計画」→「是正計画・修正計画」へ。

・3.5.3.7 の「是正／報告」→「要求・報告」へ。

・3.5.3.8 の「資産の消去」→「資産の廃棄」へ（※１）。

【追加文】

・3.5.3.8 の後に、以下の１文を追加。

「

ソフトウェア資産の廃棄は，保守プロセスの1.8.6 （システム又はソフトウェア廃棄）アクティビティに引き渡す。」

【誤字】

・3.5.2.3 の「2.3に規定された」→「2.6に規定された」へ。

・3.5.3.1 の「保障基準」→「保証基準」へ。

（※１）

追補では、「消去」という用語が使用されているが、「1.8.6 システム又はソフトウェア廃棄」アクティビティにおいて

「廃棄」という用語が使用されているため、後者の表記に合わせることとした。


を示す




★第3部で「3.6 再利用施策管理プロセス」内の表記変更

【背景】



・全頁にわたって「再利用プログラム」→「再利用施策」に統一。

・「領域」→「ドメイン」へ。

・「ドメインの特定」→「ドメインの識別」へ。

・3.6.3、3.6.6 で使用されている「評価」→「アセスメント」へ、また「評価する」→「アセスメントを行う」へ。

【追加文】

・「アクティビティ一覧」の前に、以下の１文を追加。

「

このプロセスで作成される文書は，文書化プロセス（2.1参照）に従って管理される。」

・3.6.3.4 再利用環境の改善

において

「

再利用施策管理者は，適切な取得者，供給者，企画者，要件定義者，開発者，運用者，保守者，資産管理者及び

ドメイン技術者と協力して，

～

」

【誤訳・誤字】

・「再利用プログラム支援機能」→「再利用プログラム支援機関」へ。

・「技法」→「技術」へ。

・「仕様許諾権」→「使用許諾権」へ。

・「再利用運営機能」→「再利用運営機関」へ。

・「再利用実態」→「再利用実践」へ。

・「再利用環境」→「再利用基盤」へ。


を示す




★第3部で「3.7 ドメイン技術プロセス」内の表記変更

【背景】



・「領域」→「ドメイン」へ。

・「維持」→「保守」へ変更（※１）。

・「注記１」で、「資産の形成（例えば，

・・・）を

～

」→「資産（例えば，要求事項，・・・）の形成を～」へ。

・「実施する」→「実行する」へ。

・3.7.1.3 の（ｅ）で、「変更依頼」→「変更要求」へ。

・3.7.3.4 の「仕様化された資産それぞれ」→「仕様化された各資産」へ。

・3.7.5 の「新規又は改定された要件」→「新規の要件若しくは改正された要件」へ。

・3.7.5.1 の「修正依頼」→「修正要求」へ、また「実装の選択肢」→「実施の選択肢」へ。

・3.7.5.3、3.7.5.5 の「資産の修正」→「資産の修正要求」へ。

【誤訳・誤字】

・3.7.4.1 の（ｂ）で、「（1.3参照）」→「（1.6参照）」へ。

（※１）

「維持」と「保守」の意義を改めて考察した。

「維持」：「物事の状態をそのまま保ちつづけること。」（大辞泉より）

「保守」：保守プロセスの記述を読むと、「変更させた環境に適合させること」を目的の１つに挙げている。そのために、アクティビティ一覧

にあるように、問題把握／修正分析、修正の実施、保守レビュー／受入れ、移行、廃棄が含まれている。このことから、「維持」の

意味する範囲は非常に狭いが、「保守」の範囲は広いことが分かる。そこで、改めて、「3.7 ドメイン技術プロセス」で用語「維持」が

使用されている箇所を確認してみると、意味的には、どうやら「開発された資産」を「維持」するよりも、「保守」することが求められ

ているものと思われる。例えば、成果の(6)(7)では「ライフサイクルを通して」と書いてあるように、環境変化に適合させるために

「開発された資産」を修正又は廃棄等も必要となってくるからである。これがもし「維持」という訳語を当てはめてみた場合には、

たとえ、どんな環境変化が生じたとしても、初に資産が開発され提供された状態のままで、その資産を保つのだという意味に解

釈できる。それだと、ドメイン技術、再利用施策管理、資産管理の３つが一体となって意図する効果が発現しにくいということにな

る。このことから、「保守」の訳語を当てはめた方が適切であると判断できる。


を示す




★第3部で「4. システム監査プロセス」内の表記変更

【背景】

文章を短文にし、かつ主語を明確にし、出来るだけわかり易く意味が通じるようにする。

【表記の変更（統一）】

・以下の項番において、表記を統一。

｛

4.2.3、

4.3.3、

4.4.3、

4.5.3、

4.6.3、

4.7.3 ｝

［変更前］

「システム監査人は

～

について監査し，その監査結果を，

～

に従って，監査報告の実施と改善勧告

に基づく措置を

～

」

［変更後］

「システム監査人は

～

について監査する。システム監査人は，その監査結果を，

～

に従って，報告し，

改善勧告に基づく措置を

～

」

【文献の追加】

・「SaaS向けSLAガイドライン」（平成20年1月2１日策定）

・「情報システムの信頼性向上に関するガイドライン

第2版」（平成21年3月）

・「情報システム・モデル取引・契約書（パッケージ，SaaS／ASP活用，保守・運用）＜追補版＞」（平成20年4月）


を示す




★第3部で、その他こまごまとした規定内容変更（１／３）

【背景】



を示す

1.1.5.2

受入れ

第2段落で、「システム要件定義に従って，」→「システム要件に従って，」に修正。

1.2.3.4

契約変更の要求

「

～

一環として，契約の変更管理プロセス

（1.3参照）を使用して，契約の変更を要求してもよい。」のように挿入。

1.3


「成果」を記述している段落の次で、「取得者及び供給者はこのプロセスを管理するため，管理プロセス（3.1参照）に従ってプロジェクトレ

ベルで管理する。契約の変更管理に係る文書化は，文書化プロセス

（2.1参照）に従う。」のように挿入。

1.4.1.2


「（ｂ）

成果物を構成管理プロセス

（2.2参照）のもとにおき，これに従って変更管理を行う。」と、

「（d）

必要に応じて，関係者との間で共同レビュープロセス（2.6参照）を実施する。」を挿入。

1.5.1.6

要件定義プロセス実施計画の作成

「

要件定義プロセスの

～

役割分担（要件ごとの責任の所在を含む）を決定して，記載する。」と変更。

1.5.2.3

組織及び業務環境要件の具体化

「

要件定義者は，～，組織の構成，要員，規模等の組織に対する要件を

～

。」と変更。

1.5.2.5

非機能要件の定義

「運用，操作要件」において

(a) システム運用手順

(d) システム監視方法，システム監視基準

(e) サービス提供条件（障害復旧時間等）

< 次に続く

>




★第3部で、その他こまごまとした規定内容変更（２／３）


を示す

1.5.2.5

非機能要件の定義

「運用，操作要件」において

(f) 災害対応策（Disaster Recovery）

(g) 業務継続策（Business Continuity）

のように変更。また、「その他要件」も追加。

1.5.3.2

要件変更ルールの決定

「

要件定義者は，

～

対象となるシステムの機能，費用，～

について，利害関係者の組織間で合意を得る。」に変更。

1.7.1.6

システム運用評価基準の設定

「(a) 要件の実現度，特定の利用目的の実現度」に変更。

（※１）

1.7.1.9 (a)、1.7.7.1 (a)、1.7.8.1 (a) でも、同様に変更。

1.8.1.1

開発プロセスからの引き継ぎ

「(d) 利用者文書

例えば，システム運用マニュアル及び業務運用マニュアル，など」と追記。

2.1

文書化プロセス

「成果」を記述している段落の次の次で、「組織によるプロセスの実行は，

～

確立をもたらす。

」を、追補に基づいて

「組織がこのプロセスを実行すると，

～

が確立される。」に変更。

2.5.1.1

妥当性確認作業の必要性判断

「プロジェクトが妥当性確認作業を

～

。」と変更。

2.6.3.1

技術レビューの実施

「(e) 次の活動が計画されている場合，ソフトウェア製品又はサービスが，その活動に移れるようになっている。」と追補に基づいて変更。

2.9.2.1

要求事項の確立

「

利害関係者要件及び組織要件の仕様を規定する。システムに対する組織要件及び

～

」に変更。




★第3部で、その他こまごまとした規定内容変更（３／３）


を示す

2.9.2.2

要求事項の明確化

「(ｅ）

システムの使用方法を定義する。」

「(ｆ）

利害関係者要件及び組織要件を生成する。」と追補に基づいて変更。

2.9.3.3

支援活動の実施

「(ａ）

変更の管理。」

「(f) 職場内の人間工学的な規則への適合。」と変更。

3.1

管理プロセス

「目的」において、「

～

組織が管理プロセスを制定するのは，

～

。

」と追記。

3.1.3.1

測定責任の確立と維持

「

管理者は，測定の責務を確立し，維持する。測定のための

～

確実にする。」に変更。

（※）

なお、3.1.3 において「測定プロセス」→単に「測定」と表現する。

3.1.3.2

測定の計画

「管理者は測定の計画を立案する。」に変更。

3.1.3.3

測定の実行

「

～

このタスクの結果は，データが収集され，以降の検索及び分析に

～

。」と変更。

3.1.3.4

測定値の評価

「～に保管する。測定値及び測定アクティビティのタスクの結果は，

～

。」と変更。




★第3部の規定内容（共通フレーム定義体）を変更した項番

規定内容を変更した、タスク項番

1.1.2.3

1.1.5.2

1.2.3.4

1.2.5.3

1.3.2.1

1.3.4.1

1.3.5.2

1.4.1.1

1.4.1.2

1.4.2.1

1.4.2.6

1.4.2.7

1.4.2.8

1.4.3.3

1.4.3.4

1.4.3.6

1.4.3.12

1.4.3.15

1.4.3.16

1.4.3.17

1.5.1.1

1.5.1.2

1.5.1.5

1.5.1.6

1.5.2.3

1.5.2.4

1.5.2.5

1.5.3.1

1.5.3.2

1.6.1.1

1.6.1.2

1.6.2.3

1.6.3.5

1.6.4.1

1.6.4.3

1.6.5.6

1.6.6.8

1.6.8.6

1.6.10.6

1.6.11.4

1.7.1.1

1.7.1.2

1.7.1.3

1.7.1.4

1.7.1.6

1.7.1.9

1.7.1.11

1.7.2.2

1.7.2.3

1.7.3.2

1.7.6.2

1.7.7.1

1.7.8.1

1.7.9.1

1.8.1.1

1.8.1.2

1.8.1.3

1.8.2.4

1.8.3.2

1.8.4.1

1.8.5.1

1.8.5.2

2.1.1.1

2.2.2.1

2.2.4.1

2.3.1.2

2.3.1.3

2.3.1.4

2.3.4.1

2.5.1.1

2.6.1.1

2.6.1.4

2.6.3.1

2.7.1.1

2.7.1.5

2.9.1.2

2.9.2.1

2.9.2.2

2.9.2.6

2.9.3.3

3.1.2.1

3.1.3.1

3.1.3.2

3.1.3.3

3.1.3.4

3.1.4.1

3.1.4.2

3.1.4.4

3.2.2.1

3.4.1.1

3.4.2.1

3.4.2.3

3.4.2.4

3.4.3.1

3.4.4.3

3.4.4.4

3.4.5.1

3.4.5.2

3.4.6.4

3.4.6.5

3.5.1.1

3.5.1.2

3.5.1.3

3.5.2.2

3.5.2.3

3.5.3.1

3.5.3.2

3.5.3.3

3.5.3.5

3.5.3.6

3.5.3.7

3.5.3.8

3.6.1.1

3.6.1.2

3.6.1.3

3.6.1.4

3.6.1.5

3.6.2.1

3.6.2.2

3.6.2.3

3.6.2.4

3.6.3.1

3.6.3.2

3.6.3.3

3.6.3.4

3.6.4.1

3.6.4.2

3.6.4.3

3.6.4.4

3.6.5.1

3.6.5.2

3.6.5.3

3.6.5.4

3.6.6.1

3.6.6.2

3.6.6.3

3.7.1.1

3.7.1.3

3.7.2.2

3.7.2.4

3.7.2.6

3.7.2.7

3.7.3.1

3.7.3.2

3.7.3.3

3.7.3.4

3.7.3.5

3.7.3.6

3.7.4.1

3.7.4.3

3.7.4.4

3.7.5.1

3.7.5.3

3.7.5.5

4.2.3

4.3.3

4.4.3

4.5.3

4.6.3

4.7.3

4.8.3

161箇所

同アクティビティ№

1.7.5

1.7.9

1.8.6

2.3.4

2.9.2

2.9.3

3.4.2

3.4.3

3.4.4

3.4.5

3.6.2

3.6.3

3.6.4

3.7.4

3.7.5

15箇所

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

2.1

2.2

2.3

2.4

2.6

2.8

2.9

3.1

3.2

3.4

3.5

3.6

3.7

4. 22箇所

同プロセス№

【背景】

このシートは、第3部で規定している内容（共通フレーム定義体）が変更された項番を、一覧として示す。

なお、プロセス／アクティビティについては、タスク部分を含まない記述内容が変更されたか否かで判定している。




■

第２版第４部における改訂内容

★第4部で

目次構成の変更

★第4部の図表に出てくるタスク等の名称改訂

★第4部で

主プロセス同士の関係図を変更

★第4部で

適格性確認のための解説図を差替え

★第4部で

V&Vの適用場面を解説する図を追加

★第4部で

プロセスの呼出し関係を説明する図を全面差替え





★第4部で目次構成の変更

【背景】

第4部の目次構成において、第3部でのプロセスの並びに合わせる。また、プロセスの呼出し方に関する説明を、よ

り分かり易い内容に変更する。

第１版

【第４部の扉において】

・・・

1.2


・・・

（ｄ）共同レビュープロセス

（ｅ）検証プロセス

（ｆ）妥当性確認プロセス

・・・

2. プロセスの呼出し方とその関係

（ａ）取得プロセス

（ｂ）供給プロセス

【第４部の扉において】

・・・

1.2


・・・

（ｄ）検証プロセス

（ｅ）妥当性確認プロセス

（ｆ）共同レビュープロセス

・・・

2. プロセスの呼出し方とその関係

2.1

主プロセスから支援プロセスや組織に関する

プロセスの呼出し方とその関係

2.2

主プロセスから主プロセスの呼出し方とその関係

第２版




★第4部の図表に出てくるタスク等の名称改訂

【背景】

第2部の「付２－２」及び第3部におけるタスク等の名称変更に合わせて、第4部の図表で表示されているタスク等の

名称も改訂する。

番号

図表の名称

--------

-------------------------------------------------------------------

4-1 －

取得プロセスと供給プロセス

4-2 －


4-3 －

契約の変更管理プロセスと構成管理プロセス及び要件定義プロセス

4-7 －

企画プロセスの位置づけとその構成

4-8 －

要件定義プロセスの位置づけとその構成

4-9 －

開発プロセスの位置づけとその構成

4-11 －

保守プロセスの位置づけとその構成

4-13 －

運用プロセスの位置づけとその構成

4-16 －

管理プロセスの仕組み

4-17 －

環境整備プロセスの仕組み

4-18 －

資産管理プロセスの概要

4-19 －

再利用施策管理プロセスの概要

4-21 －

ドメイン技術プロセス

【対象となった

図表】

【趣旨】

以下に示す図表において、タスク名称、アクティビティ名称をそのまま表示させるように改訂する。

（第１版においては、作業内容を要約した表記が一部含まれており、第3部との対応関係が分かりにくかった。）




★第4部で主プロセス同士の関係図を変更

【背景】

プロセス間の遷移図が曖昧なものであったため、その修正を行う。

（

対象は、図4-7、図4-8、図4-9、図4-11、図4-13 の5つ。）

第１版の図4-7

企画プロセス

保守プロセス

運用プロセス開発プロセス要件定義プロセス

第２版の図4-7

企画プロセス

保守プロセス

運用プロセス開発プロセス要件定義プロセス




★第4部で適格性確認のための解説図を差替え

【背景】

旧図4-10（ソフトウェア適格性確認テスト、システム適格性確認テストの目的）と本文解説内容とが一致していなかっ

たため、改めて図を作成すると共に説明文も書き直して、読者の方々にとり理解し易いものとして提供する。

第１版の図4-10

企画プロセス

開発プロセス

運用プロセス

業務移行・運用・評価

システム移行・運用・評価

業務層

利用層

開発層

情報戦略・業務概要

ソフトウェア適格性確認テストソフトウェア要件定義

要件の定義・計画


システム構想・計画

システム適格性確認テストシステム要件定義

企画プロセス

開発プロセス

運用プロセス

業務移行・運用・評価

システム移行・運用・評価

業務層

利用層

開発層

情報戦略・業務概要

ソフトウェア適格性確認テストソフトウェア要件定義

要件の定義・計画


システム構想・計画

システム適格性確認テストシステム要件定義

第２版の図4-10

（適格性確認要求事項と適格性確認テストとの関係）

システム要件定義（システム適格性確認要求事項）



業務要件定義業務要件定義

システム結合システム結合

（業務）運用テスト（業務）運用テスト

ソフトウェア要件定義（ソフトウェア適格性確認要求事項）


ソフトウェアテスト（ソフトウェア適格性確認テスト）


ＩＴ

シ

ス

テ

ム

層

業

務

層

事

業

層

事業評価事業評価事業要件事業要件

ソフトウェア層

システムテスト（システム適格性確認テスト）


システム方式設計システム方式設計

ソフト方式設計ソフト方式設計ソフトウェア結合ソフトウェア結合




業務要件定義業務要件定義


（業務）運用テスト（業務）運用テスト





ＩＴ

シ

ス

テ

ム

層

業

務

層

事

業

層

事業評価事業評価事業要件事業要件









★第4部で V&Vの適用場面を解説する図を追加

【背景】

V&V（Verification and Validation）の適用場面を示し、何と何とを比較するのかを明確にし、読者の方々に理解＆

実践してもらうことにより、システム及びソフトウェアの品質向上を図る。

図4-xx 検証（Verification）と妥当性確認（Validation）の適用場面

詳細設計・作成詳細設計・作成

利害関係者要件（要件定義）



運用テスト（運用）



ソフトウェア要件定義（ソフトウェア適格性確認要求事項）ソフトウェア適格性確認テストソフトウェア適格性確認テスト

ＩＴ

シ

ス

テ

ム

層

業

務

層

事

業

層

投資効果，業務効果（運用）


システム化構想，計画（企画）



システム適格性確認テストシステム適格性確認テスト


凡例：検証：妥当性確認




※１

※1：事業目標，経営戦略との妥当性確認を示す

詳細設計・作成詳細設計・作成







ソフトウェア要件定義（ソフトウェア適格性確認要求事項）ソフトウェア適格性確認テストソフトウェア適格性確認テスト

ＩＴ

シ

ス

テ

ム

層

業

務

層

事

業

層






システム適格性確認テストシステム適格性確認テスト


凡例：検証：妥当性確認




※１

※1：事業目標，経営戦略との妥当性確認を示す




★第4部でプロセスの呼出し関係を説明する図を全面差替え

【背景】

第１版の図4-21、図4-22 は一目で呼出し関係が分かるものではなかったため、第２版では、新たに図4-22、図4-23 を起こし、読者の方々にとって理解し易いものとして提供する。

契約を関係するものを含めた取得要求事項

供給者，その他との契約

・システム要求事項

・取得計画

・受入れ基準

監視・評価の結果

受入れ製品，サービス

アクティビティ内部使用プロセスの呼出し出力

開始

提案依頼書の準備

契約準備及び更新

受入れ及び完了

共同レビュー監査検証妥当性確認

契約の変更管理

要件定義


契約前

契約後

開発

企画

供給者の監視

契約を関係するものを含めた取得要求事項

供給者，その他との契約

・システム要求事項

・取得計画

・受入れ基準


受入れ製品，サービス

アクティビティ内部使用プロセスの呼出し出力

開始

提案依頼書の準備

契約準備及び更新

受入れ及び完了

共同レビュー監査検証妥当性確認

契約の変更管理

要件定義


契約前

契約後

開発

企画

供給者の監視

第１版の図4-21

第２版

図4-22　主プロセスから支援又は組織に関するプロセスの呼出し例


２．支援ライフサイクルプロセス

1.6.11 システム適格性確認

テスト

1.6.9 ソフトウェア適確性確認

テスト

1.6.3 システム方式設計

1.6.2 システム要件定義

1.6.1 プロセス開始の準備

３．組織に関するライフサイクルプロセス

3.1 管理プロセス

3.2 環境整備

プロセス

3.3 改善プロセス

3.4 人的資源プロセス

3.5 資産管理プロセス

3.6 再利用施策管理プロセス

3.7 ドメイン技術

プロセス

プロジェクトレベルで管理

基盤となる環境を確立

組織レベルで管理

蓄積された資産を再利用

・・・

関係者間レビュー

テスト検証妥当性確認

2.3 品質保証プロセス

2.4 検証プロセス

2.5 妥当性確認プロセス

2.7 監査プロセス

2.8 問題解決プロセス

2.9 ユーザビリティプロセス

2.1 文書化プロセス

2.2 構成管理プロセス

2.6 共同レビュ

ープロセス

成果物を文書化

変更管理

課題・障害管理品質保証の

計画／実施

・・・・・・

プロセスを呼出す

（矢印の先側が

呼ぶ）。

矢印の先側のプロセスを，組織的な観点から管理・統制




■

第２版第５部における改訂内容

★第5部で

共通フレームの設計思想を分かり易く改訂

★図5-1を作成した「基本的な考え方」の説明を補強

★第5部で

問題解決と保守に関係するプロセス関連図を追加





★第5部で共通フレームの設計思想を分かり易く改訂

【背景】

第5部

１章で共通フレームの設計思想が記述されているが、第2部

5.1節の改訂に伴って、第5部

１章の内容を分か

り易い内容に改訂する。

第１版

【第5部１章の第１段落において】

共通フレームの設計思想は，ISO/IEC 12207

（JIS X 0160）規格作成時の8つの基本原則

（「第2部

5．共通フレームのアーキテクチャ

5.1 共通フレーム作成における設計思想」参

照）を踏襲している。その基本原則の中でも，

特に，プロセス内のアクティビティやタスクは，

互いに機能的な連関関係が強いもので構成（モ

ジュール性の採用）され，それらの実施時期は

考慮していない（工程，時間からの独立性）た

めに，同じプロセス内のアクティビティやタス

クといえども，実行されるタイミングが異なる

ものがある。

・・・

【太字：改訂された記述を示す（下線が改訂前）】

共通フレームの設計思想は，ISO/IEC 12207（JIS

X 0160）規格作成時の9つの基本原則（第2部「5.1

共通フレーム作成における設計思想」参照）を踏襲

している。その基本原則の中でも，特に，プロセス

は，互いに機能的な関係が強いアクティビティやタスクで

構成される（モジュール性の採用）が，一方で，それらの

実施時期は考慮されていない（工程，時間からの独立

性）。つまり，共通フレームにおいては，プロセスやアク

ティビティ，タスクの順序や時間関係を規定しているわけ

ではないため，同じプロセス内のアクティビティやタ

スクといえども，実行されるタイミングは現場ごと

に異なることがあり得る。

・・・

第２版




★図5-1を作成した「基本的な考え方」の説明を補強

【背景】

図5-1 で示されている「企画フェーズ」、「要件定義フェーズ」、「システム・ソフトウェア要件定義」、「基本設計」等の

名称は、共通フレームで規定しているものではない。そのため、例示であることを強調する。

第１版

【第5部１章の第４段落において】

当該図を作成した，基本的な考え方を以下に

示す。

(1) 時間軸として，一般的に使用されている

「フェーズ」を用いた。

フェーズ名の選定においては，「情報システ

ムの信頼性向上のための取引慣行・契約に関す

る研究会」の検討結果も参考にした。

また，企画プロセス段階は，一般慣行的には

フェーズという概念は相応しくないかも知れな

いが，後続フェーズとの整合性から，あえて，

「企画フェーズ」とした。

・・・

【太字：改訂された記述を示す（下線が改訂前）】

当該図を作成した，基本的な考え方を以下に示す。

(1) 時間軸として，一般的に使用されている

「フェーズ」を用いた。

フェーズ名は，「情報システムの信頼性向上のた

めの取引慣行・契約に関する研究会」の検討結果も

参考にした一例であり，フェーズ名を規定しているわけで

はない。

また，企画段階は，一般慣行的にはフェーズとい

う概念は相応しくないかもしれないが，後続フェー

ズとの整合性から，あえて，「企画フェーズ」とし

た。

・・・

第２版




★第5部で問題解決と保守に関係するプロセス関連図を追加

【背景】

「問題が発生」した後、問題解決プロセスから呼出された保守プロセスが、その問題のレベル（影響度など）に応じて

呼出すプロセスが異なることを、図として明快に示す。

問題発生！

1.8.6システム又は

ソフトウェア廃棄

1.5.2利害関係者要件の定義

1.5要件定義プロセス

1.5.1プロセス開始

の準備

1.4企画

プロセス

1.4.1プロセス開始

の準備

ルート２

ルート３ルート３

2.8.1　プロセス開始の準備　2.8.1.1 問題解決プロセスの確立

2.8.2　問題解決　2.8.2.1 問題の解決

1.8.2問題把握

及び修正分析

1.8.3修正の実施

1.8.4保守レビュー及び受入れ

1.8.5移行

1.8.1プロセス開始の

準備

1.7.2運用テスト

1.7.7システム運用の

評価

1.7.8業務運用の評価

1.7.9投資効果及び業務効果の

評価

ルート２：　新しい業務や運用のあり方から検討する場合で，「1.5 要件定義プロセス」⇒「1.6 開発プロセス」⇒「1.7.2 運用テスト」⇒「1.8.3 修正の実施」を辿るルート。　例えば，業務内容（業務フロー，入出力情報，組織責任，権限）の追加・変更，業務特性（ルール，制約）の追加・変更，大幅な運用要件の変更を検討する場合。

ルート５

：　ハードウェア，基盤ソフトウェア（OS，ミドルウェア等），アプリケーションソフトウェアなどシステム全体の適化や変更を検討する場合で，「1.6.2 システム要件定義」⇒「1.6.3 ～ 1.6.10の各アクティビティ」⇒「1.6.11 システム適格性確認テスト」⇒ 「1.8.3 修正の実施」を辿るルート。　　例えば，明確化された業務要件のシステム化検討，ハードウェアが追加されるなどシステム化方式やシステム間インタフェースを追加検討する場合。

：　基盤ソフトウェア（OS，ミドルウェア等）や，アプリケーションソフトウェア等のソフトウェア要件の追加・変更を検討する場合で，「1.6.4 ソフトウェア要件定義」⇒「1.6.5 ～ 1.6.8の各アクティビティ」⇒「1.6.9 ソフトウェア適格性確認テスト」⇒ 「1.8.3 修正の実施」を辿るルート。　　例えば，アプリケーションソフトウェア仕様（画面，バッチ，帳票，DB，ファイル等）が変更になる場合，ＯＳや通信ミドルウェアやセキュリティソフトウェアを更新する場合。

ルート３

ルート４

：　コーディング，コンパイル＆テストを実施するソフトウェアユニットレベルの変更が必要な場合で，「1.6.6 ソフトウェア詳細設計」⇒「1.6.7 ソフトウェアコード作成及びテスト」⇒「1.6.8 ソフトウェア結合」⇒ 「1.8.3 修正の実施」を辿るルート。　　例えば，プログラムレベルの仕様追加やバグ修正の場合。

1.6.2システム要件定義

1.6.4ソフトウェア要件定義

1.6.5ソフトウェア方式設計

1.6.6ソフトウェア詳細設計

1.6.7ソフトウェアコード作成及びテスト

1.6.8ソフトウェア

結合

1.6.9ソフトウェア適格性確認

テスト

1.6.10システム

結合


1.6.3システム方式設計

1.6.11システム

適格性確認テスト

ルート４ルート４

ルート５ルート５

①

② ③ ⑦

⑧

ルート２

ルート１ルート１

ルート１：　現行事業の大幅な見直し等に伴い，システムの新規取得または現行システムの改良について検討する場合で，「1.4 企画プロセス」⇒「1.5 要件定義プロセス」⇒「1.6 開発プロセス」⇒「1.7.2 運用テスト」⇒「1.7.7 システム運用の評価」⇒　　「1.7.8 業務運用の評価」⇒「1.7.9 投資効果及び業務効果の評価」⇒「1.8.3 修正の実施」を辿るルート。　　例えば，新規業種を現行事業に吸収統合，現行事業の抜本的な効率化のための見直し等を検討する場合。

1.7　運用プロセス

2.7監査

プロセス

2.9ユーザビリティプロセス

2.6共同レビュープロセス

2.5妥当性確認

プロセス

2.1文書化プロセス

2.2構成管理プロセス

2.3品質保証プロセス

2.4検証

プロセス

1.4.3システム化計画の立案

1.5.3利害関係者要件の確認

1.4.2システム化構想の立案

1.7.1プロセス開始の

準備

1.7.3業務及び

システムの移行

1.7.4システム

運用

適切なライフサイクルモデルへ分岐分岐したライフサイクルモデルから戻る

1.6.1プロセス開始の準備

⑤

⑥

２．　支援ライフサイクルプロセス

図 5 － 6　保守プロセスを中心とした，問題解決に関係するプロセス連関図

④

2.8　問題解決プロセス

1.8　保守プロセス

ビジネス環境：　通常（プロセスの修整なしのとき）の，作業の遷移を示す。

（注意）各プロセス内のアクティビティは，紙面の都合上，主要なもののみの記載に留めている。

：　プロセスの呼出しを示す（矢印の先側が呼ぶ）。

又は

凡例

次の図も新規に作成

・図5-7 （事例1）

・図5-8 （事例2）




■

第２版補足説明集における改訂内容

★補足説明集の構成を変更

★補足説明集1.1 で

「表6-1 原理原則17ヶ条」を追加

★補足説明集2.3で

ソフトウェア保守規格の関連情報を更新

★補足説明集2.3（1）（b）で

「４つの保守タイプ」を紹介

★補足説明集で

国際標準等の情報を更新





★補足説明集の構成を変更

【背景】

補足説明集の情報を分類し、読者にとって分かり易い目次構成でもって表示することにより、利便性を向上する。

1 システム開発における役割分担について 1 役割分担の視点

2 ４つの保守タイプ 1.1 IT化における役割分担について

3 ソフトウェア保守の規格 ISO/IEC 14764 (JIS X 0161) 1.2 要件の定義と役割（ロール）

4 ISO9001による品質マネジメントシステムの保証 2 各プロセスに関する参考情報

5 効果的な品質保証の実施 2.1 共通フレーム2007のベースになった国際規格と関連規格

6 ISOにおけるプロジェクト管理の仕組み（１）ライフサイクルプロセスの国際規格

7 PMBOKによるプロジェクト管理（２）システム開発に関連する国際規格

8 CMM, CMMI 2.2 共通フレームの「品質保証プロセス」と関連する情報

9 ISO/IEC 15504 （１）品質マネジメントシステムに関連する国際規格

10 教育訓練および教育訓練の評価の例（２） ISO 9001 による品質マネジメントシステムの保証

11 ソフトウェアのユーザビリティの規格（３）効果的な品質保証の実施

12 要件の定義と役割（ロール） 2.3 保守プロセスに関連する情報

13 システム監査プロセスの制定経緯と規準（１）ソフトウェア保守規格について

14 国際規格制定の状況（２）ソフトウェア保守に関する課題と対応　・・・　★新規

15 他の国際規格との関係 2.4 プロジェクト管理に関連する情報

(1) ISO9001:2000関連規格との関連（１）プロジェクト管理に関連する国際規格

(2) 他の国際規格との関連（２） PMBOK におけるプロジェクト管理

2.5 プロセス評価に関連する情報

（１）プロセスアセスメントに関連する国際規格

（２）能力成熟度モデル

2.6 ユーザビリティに関連する情報

（１）ソフトウェアのユーザビリティに関連する国際規格

3 その他の事項

3.1 教育訓練及び教育訓練の評価の例

3.2 システム監査プロセスの制定経緯と規準

第１版第２版




★補足説明集1.1 で「表6-1 原理原則17ヶ条」を追加

【背景】

第2部

5.1 （１）項で「超上流の重視」を追加し、第3部のガイダンスで17ヶ条のうち関連する条項を列挙することにし

たため、17ヶ条全体を表として一括表示する。併せて『経営者が参画する要求品質の確保（第２版）』を紹介する。

原理原則【１】

ユーザとベンダの想いは相反する

原理原則【２】

取り決めは合意と承認によって成り立つ

原理原則【３】

プロジェクトの成否を左右する要件確定の先送りは厳禁である

原理原則【４】

ステークホルダ間の合意を得ないまま、次工程に入らない

原理原則【５】

多段階の見積りは双方のリスクを低減する

原理原則【６】

システム化実現の費用はソフトウェア開発だけではない

原理原則【７】

ライフサイクルコストを重視する

原理原則【８】

システム化方針・狙いの周知徹底が成功の鍵となる

原理原則【９】

要件定義は発注者の責任である

原理原則【10】

要件定義書はバイブルであり、事あらばここへ立ち返るもの


優れた要件定義書とはシステム開発を精緻にあらわしたもの


表現されない要件はシステムとして実現されない


数値化されない要件は人によって基準が異なる


「今と同じ」という要件定義はありえない


要件定義は「使える」業務システムを定義すること


機能要求は膨張する。コスト、納期が抑制する


要件定義は説明責任を伴う

表表66--11




★補足説明集2.3で

ソフトウェア保守規格の関連情報を更新

【背景】

ISO/IEC 14764（ソフトウェア保守）が1999年版から2006年版に改訂されたことに伴い（対応するJIS X 0161は

2002年版→2008年版へ）、その改訂内容を共通フレーム2007に取り込むと共に、規格情報をも提供する。

【補足説明集

2.3 の目次構成】

2.3

保守プロセスに関連する情報

（１）

ソフトウェア保守規格について

（ａ）ソフトウェア保守規格

ISO/IEC 14764 （JIS X 0161）の概要

・・・

< ISO/IEC 14764 （JIS X 0161）の位置付け、特徴、保守プロセスから関連するプロセスを呼出す場合の参照先を解説している

>

（ｂ）規格にみる４つの保守タイプ

・・・

< 是正保守／予防保守／適応保守／完全化保守の定義を示している

>

（２）

ソフトウェア保守に関する課題と対応

（ａ）ソフトウェア保守プロセスの改善は喫緊の課題

・・・

<

ソフトウェア保守の重要性を説くとともに、新規開発との相違点を解説している

>

（ｂ）ソフトウェア保守のプロセス改善に向け「ふたこぶラクダ」の特性を知る

・・・

< 「ふたこぶラクダ」の特性について解説している

>

（※）

補足説明集

2.3 の改訂に際して、次の方のご協力を頂きました。ここに、御礼を申し上げます。

増井

和也

様

（東芝ソリューション株式会社）

（ソフトウェア・メインテナンス研究会（SERC）の幹事のおひとりで、JIS X 0161

原案作成委員会にも関わっておられます。

SERC （Software Evolution

Research Consortium）

：

ソフトウェアのメインテナンスを専門に研究する非営利任意団体。）

→→

工程工程

相対工数

相対工数

←←




★補足説明集2.3（1）（b）で「４つの保守タイプ」を紹介

【背景】

ソフトウェア保守といっても、様々なタイプがあることを紹介する。なお、実際には複数の保守タイプが混合する案件

も多い。このようなソフトウェア保守の多様性に対応して、保守プロセスの適化（修整）が求められる。

【 ① 是正保守（corrective maintenance）

】

ソフトウェア製品の引渡し後に発見された問題を訂正す

るために行う受身の修正（reactive maintenance）。

（注記）

この修正によって，要求事項を満たすようにソフトウェア製

品を修復する。

なお，是正保守の一部として，是正保守実施までシステム

運用を確保するための，計画外で一時的な修正として，「緊急

保守

（emergency maintenance）」がある。

【 ② 予防保守（preventive maintenance）

】

引渡し後のソフトウェア製品の潜在的な障害が運用障

害になる前に発見し，是正を行うための修正。

【 ③ 適応保守（adaptive maintenance）

】

引渡し後，変化した又は変化している環境において，ソ

フトウェア製品を使用できるように保ち続けるために実施

するソフトウェア製品の修正。

（注記）

適応保守は，必須運用ソフトウェア製品の運用環境変化に

順応するために必要な改良を提供する。これらの変更は，環

境の変化に歩調を合わせて実施する必要がある。例えば，オ

ペレーティングシステムの更新が必要になったとき，新オペ

レーティングシステムに適応するためには，幾つかの変更が

必要かもしれない。これは，アプリケーションの全体機能要件

は変わらないにも関わらず，オペレーティングシステムやミドル

ウェアの変更，ハードウェアの変更，法改正などに伴ってアプ

リケーションソフトウェアに影響する部分の改良が必要になる

ようなケースである。

【 ④ 完全化保守（perfective maintenance）

】

引渡し後のソフトウェア製品の性能又は保守性を改善

するための修正（１）。

（注記）

完全化保守は，利用者のための改良（改善），プログラム

文書の改善を提供し，ソフトウェアの性能強化，保守性などの

ソフトウェア属性の改善に向けての再コーディングを提供する。

業務の改善に伴う機能要件が変わるときに行う改良などを指

す。

(1) この定義は，ISO/IEC 14764:1999 （JIS X 0161:2002）から引用

している。ISO/IEC 14764:2006 （JIS X 0161:2008）においては，

完全化保守と予防保守の定義が類似した表現となっているため，

読者が混乱しないよう，あえて旧規格の定義を掲載した。

「引渡し後のソフトウェア製品の潜在的な障害が，故

障として現れる前に，検出し訂正するための修正。」と

定義している。




★補足説明集で国際標準等の情報を更新

【背景】

補足説明集にある各種の国際標準に関する情報を、例えば財団法人日本規格協会などのWebサイトで確認して、

出来る限り新の情報に更新する。

2.1 （１）

ライフサイクルプロセスの国際規格

●ISO/IEC 12207:2008、

ISO/IEC 15288:2008の発行について言及した。また、それらの新版規格に対する編著者の見解を追記した。

2.1 （２）

システム開発に関連する国際規格

●表６－３（代表的な国際規格一覧）を、出来る限り、新情報に基づいて更新した。

2.2 （１）

品質マネジメントシステムに関連する国際規格

●ISO 9001:2008 の発行を認識した上で、補足説明集の本文及び図６－３、表６－４を、ISO 9001 の用語及び概念に基づいて改訂した。

2.4 （２）

PMBOK

におけるプロジェクト管理

●PMBOK の新状況について紹介するよう、記述内容を更新した。

2.5 （１）

プロセスアセスメントに関連する国際規格

●財団法人日本規格協会のWebサイトで確認して、新の情報に更新した。

2.5 （２）

能力成熟度モデル

●CMU-SEI の

Webサイトで確認して、記述内容（各種

CMMI for XXX の発行状況）を更新した。

2.6 （１）

ソフトウェアのユーザビリティに関連する国際規格

●本文を分かり易く見直した。

3.1

教育訓練及び教育訓練の評価の例

●参照先としての

URL情報を更新した。

3.2

システム監査プロセスの制定経緯と規準

●制定経緯がやや分かり易くなるよう、見直した。




■

第２版

用語解説、参考文献、索引の改訂内容

★用語解説の見直し

★参考文献の追加

★索引に掲載する「用語」の抜本的な見直し





★用語解説の見直し

【背景】

JIS X 0160の用語定義に基づいて、より正確に用語解説を改訂する。また、第3部での改訂に伴って、改訂すべき

用語解説の部分を見直し、記述内容を変更する。

・ISO 9001

・アクティビティ

・受入れテスト

・開発者

・監査

・管理プロセス

・企画

・基準線

・既製品

・供給者

・検証

・合意

・システム

・取得者

・成果物

【解説を一部でも

変更した用語】

・セキュリティ

・ソフトウェア製品

・妥当性確認

・提案依頼書

・提案書

・適格性確認

・適格性確認テスト

・テスト網羅性

・テスト計画性

・版

・評価

・品質保証

・保守

・ライフサイクルモデル

・利用者以上、30

用語




★参考文献の追加

【背景】

2007年10月～ 2009年5月までに発行された報告書、書籍のうち、共通フレーム2007の内容をより良く理解するた

めに参考となる文献を追加する。

第２版で新しく追加した参考文献

（既出文献についての情報更新は除く）

● 「JIS X 0161：2008 ソフトウェアライフサイクルプロセス

–

保守」

，財団法人

日本規格協会，2008年3月

● 「情報システムの信頼性向上に関するガイドライン

第2版」，経済産業省，平成21年3月24日

● 「情報システム・モデル取引・契約書

（パッケージ，SaaS/ASP活用，保守・運用）＜追補版＞」，

経済産業省

商務情報政策局

情報処理振興課，平成20年4月

● 「情報システム・ソフトウェアの信頼性及びセキュリティの取組強化に向けて

～豊かで安全・安心な高度

情報化社会に向けて～

－中間報告書－」，経済産業省

商務情報政策局

情報処理振興課，

平成21年5月28日

● 「～ISO 14764による～

ソフトウェア保守開発」

，ソフトウェア・メインテナンス研究会編，

ソフト・リサーチ・センター

，2007年10月

● 「ソフトウェア現場力ハンドブック」

，松本吉弘編，オーム社，2009年4月




★索引に掲載する「用語」の抜本的な見直し

【背景】

「使われる索引」とするために、第１版の索引に掲載されている用語を尊重しつつも、その採用（第２版での再掲載）

には厳しく当たり、用語を厳選する。

４４８

【第１版の索引に掲載されている用語数】

【趣旨】

第１版の索引においては、特に確立したルールに基づいて、用語が選定され、「索引」に掲載されているわけでは

なかった。また第１版の索引に載っている用語から、その参照先のページを開いてみると、特に、用語の定義や説明

が記述されているわけではなく、単に「その用語が使われている」だけにすぎないケースも、多数見受けられた。

このような索引を提供した場合、読者は、何回か索引を使ううちに「使う意味がない」ことに気づき、全く索引を使わ

なくなる。このようなことでよいのだろうかという問題意識のもと、索引に掲載する用語の選定について、一から見直し

た。そこで、真に「使われる索引」とするために、共通フレームの本の中で、用語の定義又は説明が記述されているも

のに絞って、索引に載せることとした。その結果が、第２版の索引である。

また、共通フレーム９８のときには掲載されていた英語表現の用語も、索引に含めるようにした。

２４４

【第２版の索引に掲載されている用語数】

△204




改訂情報終わり




ありがとうございました

Documents

共通フレーム2007 第2版 改訂情報 - IPA共通フレーム2007（第2版）に含めた（→ 補足説明集の表6-1 参照）。 第3部においても、プロセスごとに規定内容と関連が深い『原理原則17ヶ条』を

共通フレーム2007 第2版改訂情報 - IPA共通フレーム2007（第2版）に含めた（→ 補足説明集の表6-1 参照）。第3部においても、プロセスごとに規定内容と関連が深い『原理原則17ヶ条』を