Contract
1.合意プロセス
1.1 取得プロセス
1.2 供給プロセス
1.3 合意・契約の変更管理プロセス
2.テクニカルプロセス
2.1 企画プロセス
2.1.1 システム化構想の立案プロセス
2.1.2 システム化計画の立案プロセス
2.2 要件定義プロセス
2.3 システム開発プロセス
2.3.1 システム開発プロセス開始の準備プロセス
2.3.2 システム要件定義プロセス
2.3.3 システム方式設計プロセス
2.3.4 実装プロセス
2.3.5 システム結合プロセス
2.3.6 システム適格性確認テストプロセス
2.3.7 システム導入プロセス
2.3.8 システム受入れ支援プロセス
2.4 ソフトウェア実装プロセス
2.4.1 ソフトウェア実装プロセス開始の準備プロセス
2.4.2 ソフトウェア要件定義プロセス
2.4.3 ソフトウェア方式設計プロセス
2.4.4 ソフトウェア詳細設計プロセス
2.4.5 ソフトウェア構築プロセス
2.4.6 ソフトウェア結合プロセス
2.4.7 ソフトウェア適格性確認テストプロセス
2.4.8 ソフトウェア導入プロセス
2.4.9 ソフトウェア受入れ支援プロセス
2.5 ハードウェア実装プロセス
2.6 保守プロセス
3.運用・サービスプロセス
3.1 運用プロセス
3.2 廃棄プロセス
3.3 サービスマネジメントプロセス
4.支援プロセス
4.1 文書化管理プロセス
4.2 品質保証プロセス
4.3 検証プロセス
4.4 妥当性確認プロセス
4.5 共同レビュープロセス
4.6 監査プロセス
4.7 問題解決プロセス
5.プロジェクトプロセス
5.1 プロジェクト計画プロセス
5.2 プロジェクトアセスメント及び制御プロセス
5.3 意思決定管理プロセス
5.4 リスク管理プロセス
5.5 構成管理プロセス
5.6 ソフトウェア構成管理プロセス
5.7 情報管理プロセス
5.8 測定プロセス
6.組織のプロジェクトイネーブリングプロセス
6.1 ライフサイクルモデル管理プロセス
6.2 インフラストラクチャ管理プロセス
6.3 プロジェクトポートフォリオ管理プロセス
6.4 人的資源管理プロセス
6.5 品質管理プロセス
6.6 知識管理プロセス
6.7 ソフトウェア再利用プロセス
6.7.1 ドメイン(領域)エンジニアリングプロセス
6.7.2 再利用資産管理プロセス
6.7.3 再利用施策管理プロセス
6.8 「システム監査」プロセス
7.プロセスビュー
7.1 ユーザビリティプロセスビュー
8.テーラリング（修整）プロセス
本文書は、「共通フレーム 2013」の第 3 部から、有効な<ガイダンス>の部分のみを抽出したものである。
1.1：
1.取得プロセスについては，第4部1.1「（a） 取得プロセス，供給プロセス 及び 合意・契約の変更管理プロセス」及び同「（b） 契約作業（二者間契約）」に概説している。
2.取得者は，その取得対象となるシステム，ソフトウェア製品又はサービスが（取得者自身の決める判断基準に沿って）一定規模以上になる場合，多段階の見積り方式の採用，及び／又は工程に応じた取引契約形態（準委任型，請負型）の採用を検討することが望ましい。
なお，「多段階の見積り方式」と取引契約形態のうち「準委任」については，第1部 2.の「（6）見積りの問題」と「（5） 不明確な取引の問題」を参照。
3.取得プロセスについては，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ 原理原則[5] 多段階の見積りは双方のリスクを低減する原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり，事あらばここへ立ち返るもの原理原則[16] 機能要求は膨張する。コスト，納期が抑制する
原理原則[17] 要件定義は説明責任を伴う
1.1.1.1：取得プロセスは，開発の一部を発注することもあるため，発注部分の仕様固めを行うことを意図している。
1.1.1.2：システム要件に含むことが望ましい「適合する規格」とは，共通フレームやその他の関連する規格類を指す。例えば，「設計表記法は，JIS X 0125決定表に従うこと」，「機器構成図は，JIS X 0127 計算機システム構成の図記号と用法に従うこと」などの要件となる。
1.1.1.3：
1.供給者を雇った場合は，取得者側が，供給者に協力することが大切である。このことは，このタスクに限らず，すべてのプロセス，アクティビティ，タスクにおいても同様である。
2.企画プロセス（2.1）や要件定義プロセス（2.2）のアクティビティやタスクの一部を供給者に発注することもある。ただし，契約時は，最終的な責任の所在を明らかにするために，「請負」か
「準委任」かの区別をしておくのがよい。
また，経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」が取りまとめた「情報システム・モデル取引・契約書」を参照のこと。
1.1.1.5：経営に係るシステム，ソフトウェア製品，サービスとは，例えば，大規模な投資を必要とするもの，経営改革や業務プロセスの見直しなどが前提となるもの，多くのエンドユーザに対してインパクトをもつものなどが挙げられる。
1.1.1.7：近年ではグリーン調達を考慮することもある。
1.1.1.7（d）：将来的な支援の計画が明確でない場合にはこれらの情報を収集するとよい。
1.1.1.9：受入れ終了後は，供給者の契約上の責任は，瑕疵担保（通常1年間）を除いてなくなるので，受入れ方針と条件を注意深く考慮するとよい。なお，瑕疵担保責任については経済産業省の「情報システム・モデル取引・契約書」を参照のこと。
受入れ方針及び条件（基準）の定義にかかる基準は，システム完成後の利用環境，運用条件，保守，危機対応等を想定し，個別場合分けを行い，具体的かつ定量的に定めるとよい。作成した基準は，システム受入れ支援プロセス（2.3.8），ソフトウェア受入れ支援プロセス （2.4.9参照）だけでなく，運用テスト及びサービスの提供開始（3.1.2参照）にも利用するとよい。
1.1.1.9（b）：受入れテストの内容，体制，スケジュール等を明確にした受入れテスト計画書を文書化することが望ましい。
1.1.1.10 （f）：外部委託先管理に関しては，適切な情報セキュリティ対策を講じる必要がある。情報セキュリティ対策については，「情報セキュリティ監査基準」（経済産業省，平成15年）「情報セキュリティ管理基準」（経済産業省，平成20年改正版）等を参照のこと。
1.1.1.11：テーラリング（修整）の方法については，第4部「2.2 テーラリング（修整）における留意点」を参照のこと。
1.1.1.13：契約遂行上の節目は，明確に定義した開始基準及び完了基準に基づくことが望ましい。
1.1.3.1：提案書評価基準及び要件適合度の重み付けには，必要に応じて特定領域の専門家を含めるとよい。
1.1.3.2：その他の考慮すべき要素の例
システム構築の能力・成熟度 （補足説明集 2.6「（2） 能力成熟度モデル」を参照のこと）対象領域の専門知識
過去の実績
経営上の安定性など
1.1.4.1：取得者はプロジェクト用に独力で，あるいは供給者と協働してプロセスをテーラリング（修整）することや，供給者組織のプロセス標準に基づいた提案書を請求し，供給者の提案するプロセスを評価することができる。
1.1.4.2：
1.取得に関する要件には，費用，納期，性能，品質の間にトレードオフの関係がある。これを考慮して，取得に関する要件をまとめることが望ましい。
2.知的財産権については，経済産業省の「情報システム・モデル取引・契約書」を参照のこと。
1.1.4.4：
1.契約内容に将来の事項，予測に基づく事項などが多い場合は，基本契約と個別契約により，契約行為をやりやすくする方法がある。
2.対象プロセスの決定とテーラリング（修整）（1.1.1.11）に基づき，契約する範囲を明確にする。
3.経済産業省の「情報システム・モデル取引・契約書」では，個別契約書で工程毎に委託料を定める多段階契約と再見積りのプロセスモデルを採用している。同契約書では，要件定義作成支援業務，外部設計書作成（支援）業務，ソフトウェア開発業務，ソフトウェア運用準備・移行支援業務に分割するモデルが示されている。
1.1.5.1：供給者に対して適切な情報セキュリティ対策を求める必要がある。情報セキュリティ対策については，「情報セキュリティ監査基準」（経済産業省，平成15年）「情報セキュリティ管理基準」（経済産業省，平成20年改正版）等を参照のこと。
1.1.5.2：供給者への協力では，業務の流れ，データ量などに関する確実な情報提供の他，問題解決のための定例会議の設定などを含む。
経済産業省の「情報システム・モデル取引・契約書」では，第12条で連絡協議会の設置を求めている。
1.1.6：このアクティビティは，取得者（又は取得者が指定した機関）が供給者の活動や納入するシステム，ソフトウェア製品又はサービスを，契約に従って受入れやすくするための作業を定義する。 1.1.6.1：受入れを行うために必要なすべての環境資源は両者が合意する。これらの資源には，人，場所，
設備，ハードウェア，ソフトウェア，さらにツールを含む。
1.1.6.2：受入れレビュー及び受入れテスト終了後，取得者は，受入れ記録結果を供給者に配布し，供給者は，受入れで検出された問題点とその解決策を取得者に確認する。
受入れテストは，システム，ソフトウェア製品又はサービスの納入可能な成果物に対して，供給者側のテスト仕様書（テストデータ，テストケース）あるいはテスト結果報告書などをもとにして，以下を確認するために実施される。
納入されるソフトウェア製品が要件を反映している
契約で規定された受入れレビューとテスト要件が，成果物の納入に際して適切であるテストデータが仕様に合っている
ソフトウェア製品と利用者用文書が一致している
1.1.6.4：システム及びソフトウェア製品の構成管理を含め，保守契約を結んでもよい。
1.2：
1.供給プロセスについては，第4部1.1「（a） 取得プロセス，供給プロセス 及び 合意・契約の変更管理プロセス」及び同「（b） 契約作業（二者間契約）」に概説している。
2.供給者は，その供給対象となるシステム，ソフトウェア製品又はサービスが（供給者自身の決める判断基準に沿って）一定規模以上になる場合，多段階の見積り方式の採用，及び／又は工程に応じた取引契約形態（準委任型，請負型）の採用を検討することが望ましい。
なお，「多段階の見積り方式」と取引契約形態のうち「準委任」については，第1部2.の「（6） 見積りの問題」と「（5） 不明確な取引の問題」を参照。
3.「供給プロセス」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ 原理原則[5] 多段階の見積りは双方のリスクを低減する原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり，事あらばここへ立ち返るもの原理原則[16] 機能要求は膨張する。コスト，納期が抑制する
原理原則[17] 要件定義は説明責任を伴う
1.2.2.1：取得プロセス（1.1）取得の準備（1.1.1）を参照のこと。
1.2.2.2：入札には，入札の公示，入札の管理，契約相手の決定という取得者の活動と，実際の札を入れるという意味での入札という供給者の活動がある。
1.2.2.3：この定義は，供給者が取得者からの依頼によらず提案活動を行うことを妨げるものではない。提案する内容に，プロジェクトの仕事の進め方を共通フレームで表し，プロジェクトの特性に合わせたテーラリング（修整）案を含めることが望ましい。
提案で，プロトタイプ，体験版ソフトウェアの提供及び，デモンストレーションの実施時は，事前にこれらの権利関係を明確にする。
1.2.3.1：供給者は，提案書に基づき，取得者と交渉し，契約内容を明確化する。それらは契約書，受注条件書，見積書として文書化する。
1.2.3.4：契約で取決め，共同レビューで相互に合意したベースラインに対して，大幅な仕様変更で契約内容との差異がでた場合などを指す。差異の管理を行うのが構成管理である。
1.2.4.3：供給者は品質保証計画に対する要件を確定する前に，取得者の品質保証計画に対する要件が定められていれば，その内容を確認し，それと一貫性のとれたシステム，ソフトウェア製品及びソフトウェアサービスの品質計測を行うためのフレームワークを確立することが望ましい。
1.2.4.5 （a）：外部組織に仕事を委託する場合は，請負契約と準委任契約では，法的に権限と責任に大きな違いがある。
取引契約類型については，第2部4.2 の「（2）サービスメニュー」を参照のこと。
1.2.4.5 （b）：エンジニアリング環境は変化が激しいため，技術動向を把握するとともに，それぞれを評価した上で適用することが望ましい。
1.2.4.5 （d）：品質特性の管理の計画立案に当たっては，自社の方針及び取得者による要件を考慮する。 1.2.4.5（f）：外部委託について取得者が制約を設ける場合があるので取得者と協議するのが望ましい。
1.2.4.5 （i），（j）：取得者や利用者の参画する範囲と深さを一覧化することが望ましい。
1.2.4.5 （l）：情報セキュリティ対策については，「情報セキュリティ監査基準」（経済産業省，平成 15年）「情報セキュリティ管理基準」（経済産業省，平成20年改正版）等を参照のこと。
1.2.4.6：
1.プロジェクト管理計画は必要に応じて，更新，修正されることが望ましい。
2.取得者には計画の更新が通知されることが望ましい。
1.2.4.7：供給者は，契約に従い，以下の作業の支援を行ってもよい。
1.企画プロセス（2.1参照）に従ったシステム，ソフトウェア製品及びソフトウェアサービスの企画。
2.要件定義プロセス（2.2参照）に従ったシステム，ソフトウェア製品及びソフトウェアサービス
の要件定義。
1.2.4.9：当初の契約事項とは，取得者と供給者が当初結んだ主契約（prime-contract）の要件をいう。
1.2.4.9：外部委託先に対して適切な情報セキュリティ対策を求める必要がある。情報セキュリティ対策については，「情報セキュリティ監査基準」（経済産業省，平成15年）「情報セキュリティ管理基準」
（経済産業省，平成20年改正版）等を参照のこと。
1.2.4.14：経済産業省の「情報システム・モデル取引・契約書」では第35条で，供給者が開発の過程で作成した中間資料について，取得者に確認を求める手続きを定めている。
1.2.5.2：支援する期間，範囲は契約に記載する。納入されたシステム，ソフトウェア製品又はソフトウェアサービスに関する支援は，保守契約及び／又は保守支援契約を結ぶとよい。
1.3：
1.システム開発においては，当初想定していなかった事態の発生や上流工程での要件確定の曖昧さなどを起因として，取得者及び供給者の双方から，契約の変更要求が発生することが多い。合意・契約の変更管理プロセスは，このような事態が発生した場合において，二者間で合意できる新たな契約条件を導くためのプロセスとして位置付けられる。
2.契約内容の変更に関しては，経済産業省の「情報システム・モデル取引・契約書－ソフトウェア開発委託基本モデル契約書」の第4章「本契約内容等の変更」を参照。
3.「合意・契約の変更管理プロセス」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[4] ステークホルダ間の合意を得ないまま，次工程に入らない
原理原則[10] 要件定義書はバイブルであり，事あらばここへ立ち返るもの原理原則[16] 機能要求は膨張する。コスト，納期が抑制する
原理原則[17] 要件定義は説明責任を伴う
1.3.1.1：協議の場への出席者，開催時期，議事運営方法について定めておくことが望ましい。この協議の場を「情報システム・モデル取引・契約書」に定める「連絡協議会」とするとよい。（「情報シス テム・モデル取引・契約書」の第12条（連絡協議会の設置）及び第37条（変更管理手続き）を参照。） 1.3.1.2：契約の変更管理手続きについては，「情報システム・モデル取引・契約書」の第37条（変更管
理手続き）を参照。
供給者は開発の途中において，契約で取り決めたベースラインに関して取得者に確認を行うことが望ましい。この場合，確認手続きを事前に契約書に定めておくものとする。開発の途中におけるベースラインの確認に関しては同第35条（中間資料のユーザ確認）を参照。開発の都合上，やむを得ず未確定要件が残される場合がある。こうした事態に備えて，同36条（未確定事項の取扱い）においては，事前に未確定要件を書面で確認する取り扱いについて定めている。
1.3.2.1：契約の変更要求には，当初から契約内容の変更を意図したものやシステム開発作業において提案された仕様変更が影響度調査の結果として契約内容の変更に到るものなどがある。契約の変更要求については，「情報システム・モデル取引・契約書」の第34条（書面交付による変更要求又は提案）を参照。
1.3.3：「影響の調査分析アクティビティ」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[2] 取り決めは合意と承認によって成り立つ
1.3.3.1：取得者からの変更要求については，供給者が変更をすべて受入れた場合，また部分的に受入れた場合に予想されるプロジェクト計画，費用，利益，品質及び予定に与える影響を明記した処置案を取得者に提示するとよい。
供給者からの変更要求については，取得者がその変更を受入れた場合に予想される利益，ビジネスへの影響を明記した処置案を取得者に提示するとよい。また，契約の変更要求の影響調査分析にあたっては，必要に応じて要件定義プロセス（2.2参照），システム開発プロセス（2.3参照）及びソフトウェア実装プロセス（2.4参照）を使用することが望ましい。
1.3.4：「協議の実施と合意の形成アクティビティ」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[4] ステークホルダ間の合意を得ないまま，次工程に入らない
1.3.4.1：協議に当たっては，要求内容，水準の変更や代替案の策定を含め，両者で誠意を持って協力し，双方が満足できる結論を導くことが望ましい。
1.3.4.2：原則として各組織の契約金額に基づく承認レベルに応じた管理層へエスカレーションする。ビジネスに多大な影響を与える変更については金額の多寡にかかわらずに経営層までエスカレーションすることが望ましい。
1.3.5.1：変更契約の締結については，「情報システム・モデル取引・契約書」の第33条（本契約及び個別契約内容の一部変更）を参照。
合意が調わない場合の対応については，同第38条（変更の協議不調に伴う契約終了）を参照。 1.3.5.3：後日のトラブルを防止するため，契約の変更内容がすべての利害関係者にxxxxされている
ことが不可欠である。
2.1.1：
1.企画プロセス（2.1）全体については，第4部1.2「（a） 企画プロセス」に概説している。共通フレームにおけるこれらのプロセスは，新規事業の立ち上げや現行事業の大幅な見直し等に伴い，システムの新規取得又は現行システムの改良について検討する際のアクティビティ及びタスクを定義している。要件定義プロセスや開発プロセスに先立ち実施することを想定しているが，事業の見直しを伴わない小規模なシステム改良，目的や用途が明確になっているシステム
（計測，制御用システム，組込みシステム，通信システム等）では，本プロセスを省略して，要件定義プロセスや開発プロセスを選択してもよい。
2.システム化構想の立案プロセス（2.1.1）については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する原理原則[7] ライフサイクルコストを重視する
原理原則[8] システム化の方針・狙いのxxxxが成功の鍵となる
3.システム化構想の立案プロセス（2.1.2）においては，アクティビティを実行する上で，「ISO/IEC 29148 Systems and software engineering – Life cycle processes – Requirements Engineering」 Annex A （normative） System operational concept の A.2.5 Concepts for the proposed system の内容を参考にするとよい。
2.1.1.1.3：標準には，規格（国際規格，国内規格），業界標準，社内標準を含んでいる。
2.1.1.2.1：
1.補足説明集1.2「要件の定義と役割（ロール）」を参照されたい。
2.アクティビティを実行する上で，「ISO/IEC 29148 Systems and software engineering – Life cycle processes – Requirements Engineering」 Annex B （Concept of operation） の内容を参考にするとよい。
2.1.1.2.2：競争相手の製品，サービスの分析は，どの分野においても重要である。
2.1.1.2.3：
1.業界におけるシステム技術水準の評価は，安定的な技術水準の確認に用いることができる。
2. EA（エンタープライズ・アーキテクチャ）を導入し，ガバナンスを効かせることで，業務とITの整合性の確認，将来像の共有，利用システム技術の統制を図ることが可能となる。
2.1.1.2.4：情報技術の範囲は広く，変化が激しい。そのため，継続して情報収集するとよい。
2.1.1.2.5：経営上のニーズ，業務環境の調査，分析，現在の業務の調査，分析，システムの調査分析，情報技術動向の調査，分析に基づいて優先順位をつけるに当たっては，選択基準を作成する。
優先順位は，事業目的，目標の達成に対する評価対象とする年数，効果，緊急度，実現可能性，予算，体制，要員などにより判断するとよい。
2.1.1.2.6：業務の全体像は，総括的な業務モデルである。業務機能の重要な項目と業務組織のモデルを検討する。
業務再構築（BPR：ビジネス・プロセス・リエンジニアリング）も検討するとよい。
2.1.1.3.1：システム化にあたっては，自社開発か，開発作業を外部委託するかを含めて考慮するとよい。
2.1.1.3.2：システム化推進体制は，支援プロセス，プロジェクトプロセスおよび組織のプロジェクトイネーブリングプロセスに従って，テーラリング（修整）するとよい。
2.1.2：
1.企画プロセス（2.1）全体については，第4部1.2「（a） 企画プロセス」に概説している。共通フレームにおけるこれらのプロセスは，新規事業の立ち上げや現行事業の大幅な見直し等に伴い，システムの新規取得又は現行システムの改良について検討する際のアクティビティ及びタスクを定義している。要件定義プロセスや開発プロセスに先立ち実施することを想定しているが，事業の見直しを伴わない小規模なシステム改良，目的や用途が明確になっているシステム
（計測，制御用システム，組込みシステム，通信システム等）では，本プロセスを省略して，要件定義プロセスや開発プロセスを選択してもよい。
2.システム化計画の立案プロセス については，「超上流から攻めるIT化の原理原則17ヶ条」の中
で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[4] ステークホルダ間の合意を得ないまま，次工程に入らない原理原則[6] システム化実現の費用はソフトウェア開発だけではない 原理原則[7] ライフサイクルコストを重視する
原理原則[8] システム化の方針・狙いの周知徹底が成功の鍵となる原理原則[15] 要件定義は「使える」業務システムを定義すること
3.システム化計画の立案においては，アクティビティを実行する上で，「ISO/IEC 29148 Systems and software engineering – Life cycle processes – Requirements Engineering」 Annex A
（normative） System operational concept の A.2.5 Concepts for the proposed system の次の内容を参考にするとよい。
A.2.5.1 Background, objectives, and scope
A.2.5.2 Operational policies and constraints
A.2.5.3 Description of the proposed system
A.2.5.4 Modes of operation
A.2.5.5 User classes and other involved personnel
A.2.5.5.1 Organizational structure
A.2.5.5.2 Profiles of user classes
A.2.5.5.3 Interaction among user classes
A.2.5.5.4 Other involved personnel
A.2.5.6 Support environment
2.1.2.1.3：標準には，規格（国際規格，国内規格），業界標準，社内標準を含んでいる。
2.1.2.2.2：対象業務の流れと業務で扱う情報は，処理とデータの形式で分類したり細分化して，レベル間の不整合を取り除く，あるいは類似の処理とデータの統合を図ることがある。組込み型の開発の場合は，機能などの概要調査を行う。
2.1.2.2.3：解決すべき課題の定義が，対象業務の再設計につながることもある。
2.1.2.2.4：例えば，組織や業務と関連させ，対象業務の内容の確認（2.1.2.2.2）と同様に処理とデータの形式で整理するとよい。
システムの停止，誤動作，データの破壊等によって生じるリスクを分析し，障害対策のレベルを設定するとよい。
2.1.2.2.5：適用情報技術の調査（2.1.2.2.5）を行っていれば，その結果を具体的な業務と対応づける。適用情報技術の調査，分析を行っていなかったり，調査後に期間が経過している場合には，調査項目に即して調査する。
2.1.2.2.6：業務の全体像を具体化した業務モデルの作成には，次に示す活動がある。業務プロセスの定義
データクラスの定義業務モデルの定義 業務モデルの分析 レビュー，意思決定
ここも業務再構築（BPR：ビジネス・プロセス・リエンジニアリング）の検討に有効なポイントである。 2.1.2.2.7：情報システムの構築には既製品を用いてもよい。ただし，既製品を用いる場合には，システ
ムに組込むためのテストを行う必要がある。この場合，開発プロセスのテスト関連のアクティビティ，タスクを実行してもよい。
システム化構想の新システム全体イメージを，システム開発プロセス（2.3参照）のシステム方式設計プロセス（2.3.3）を参照して開発者の視点で見直すとよい。
2.1.2.2.8：
1.業務及びシステム移行に対する基本方針の明確化
業務及びシステムを移行する際に，業務開始日程，移行方法，必要な基本的要件（データベース，
ネットワークの移行，業務手順の変更など），旧業務，旧システム停止日程など概略の計画を明確にする。
システムを実際に保守，運用するための方針，スケジュール等基本的な要件を明確にする。 2.システム再利用に対する基本方針の明確化
既存システムの継続利用，あるいはマイグレーション（コンバージョンなどの手段による再利用），業務パッケージの利用，外部サービスの利用について，その機能範囲，必要機器構成，稼動条件などを明確化する。
3.他システムとの連携方針明確化
対象システムの分析（2.1.2.2.4）で洗い出された他システムについて，新システムでの連携方針を明確化し，新たな機能の開発が必要な場合には，業務モデルの作成（2.1.2.2.6）に加える。
4.システム運用と保守に対する基本方針の明確化
システム運用時に発生した障害に対する保守体制，保守内容に対する基本要件を明確にする。また，システム変更作業を実施するための方針を明確にする。
5.環境整備に対する基本方針の明確化
環境整備のために必要なシステムの大枠を期間別に見積り，使用量を算出する。環境整備には，開発環境，運用環境，保守環境を含む。
6.教育訓練に対する基本方針の明確化
業務，システムに関する教育訓練について目的，対象範囲，教育訓練体制，教育訓練設備，環境，実施スケジュールなどの基本的な要件を明確にする。利用部門を含めた教育訓練計画を文書化しておくことが望ましい。
7.取得者組織内における開発体制の位置づけ，開発プロジェクトの体制とその要員数，役割分担，受入れテスト体制，利用部門との協力などについて明確にする。
8.利用部門を含めた業務移行計画を文書化しておくことが望ましい。移行方法には，一斉切替え，拠点別切替え，業務別切替え，並行運用などの方法があり，おのおの利点や移行上のリスクが異なるため十分検討することが望ましい。
2.1.2.2.15：取得者の作業と予定を策定するに当たっては，要件定義，システムテスト等開発時作業に係る取得者側要員手配をあらかじめ行うとよい。
2.1.2.3.1：要件の合意（2.2.5）の後，必要があればシステム化計画の見直しを行う。
2.1.2.3.2：
1.システム化計画とプロジェクト計画は１：ｎの関係となる。システム化範囲のうち，規模が大きい，実施時期が異なるなどの理由で複数プロジェクトによる推進が望ましい場合は，システム化計画に対して複数のプロジェクト計画を作成する。１：１の場合には，プロジェクト計画はシステム化計画に含めてもよい。
2.要件の合意（2.2.5）の後，必要があればプロジェクト計画の見直しを行う。
3.外部委託の締結後，その作業項目，スケジュール等の変更を行った場合には，合意・契約の変更管理プロセス（1.3参照）に従う。
2.2：
1.要件定義プロセスについては，第4部1.2「（b） 要件定義プロセス」に概説している。
2.開発形態，開発モデルによっては，要件定義プロセスは，システム開発プロジェクトを開始する前の作業として位置づけられ，契約の内容に応じて取捨選択されることがある。
3.「要件定義プロセス」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[1] ユーザとベンダの想いは相反する
原理原則[8] システム化の方針・狙いの周知徹底が成功の鍵となる原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり，事あらばここへ立ち返るもの 2.2.1.5：標準には，国際規格，国内規格，業界標準，社内標準を含んでいる。
2.2.3：「要件の識別アクティビティ」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である原理原則[6] システム化実現の費用はソフトウェア開発だけではない
原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの原理原則[12] 表現されない要件はシステムとして実現されない
原理原則[13] 数値化されない要件は人によって基準が異なる原理原則[14] 「今と同じ」という要件定義はありえない
原理原則[15] 要件定義は「使える」業務システムを定義すること原理原則[16] 機能要求は膨張する。コスト，納期が抑制する
原理原則[17] 要件定義は説明責任を伴う
2.2.3.1：
1.要件定義者は，要件を識別，抽出したものについて，要件として定義するために実際的な分析，制約条件や運用シナリオの具体的な内容を以下に記載する。
（1）業務要件の定義
要件定義者は，新しい業務のあり方や運用をまとめた上で，業務上実現すべき要件を明らかにする。業務要件には例えば，次のようなものを記述する。
（a） 業務内容 （手順，入出力情報，組織，責任，権限など）
（b） 業務特性 （ルール，制約など）
（c） 業務用語
（d） 外部環境と業務の関係，授受する情報
（2）組織及び環境要件の具体化
要件定義者は，上述，（1）業務要件の定義の中から，組織の構成，要員，規模等の組織に対する要件を具体化し，新業務を遂行するために必要な事務所や業務用の諸設備等に関する導入方針，計画，及びスケジュールを明確にする。
（3）機能要件の定義
要件定義者は，上述，（1）業務要件の定義で明確にした業務要件を実現するために必要なシステム機能を明らかにする。具体的には，業務を構成する機能間の情報（データ）の流れを明確にし，対象となる人の作業及びシステム機能の実現範囲を定義する。また，利用者のニーズ及び要望をもとに，情報管理の観点，管理の単位，形式などを理解し分析する。更に他システムとの情報授受などのインタフェースを定義する。この時，必要に応じて，システム要件定義（2.3.2），システム方式設計（2.3.3），ソフトウェア要件定義（2.4.2），ソフトウェア方式設計（2.4.3）を使用してもよい。
（4）非機能要件の定義
要件定義者は，（1）業務要件の定義で明確にした業務要件を実現するために必要なシステムの機能要件以外の要件（非機能要件）を明らかにする。この時，必要に応じて，システム要件定義（2.3.2），システム方式設計（2.3.3），ソフトウェア要件定義（2.4.2），ソフトウェア方式設計（2.4.3），ユーザビリティプロセスビュー（7.1）を使用してもよい。非
機能要件には，例えば，次のようなものを記述する。
品質要件：JIS X 0129-1（ISO/IEC 9126-1）「ソフトウェア製品の品質－第1部:品質モデル」に「品質特性」として挙げられている次のものが援用できる。
（a） 機能性 （functionality）
（b） xxx （reliability）
（c） 使用性 （usability）
（d） 効率性 （efficiency）
（e） 保守性 （maintainability）
（f） 移植性 （portability）技術要件：
（a） システムの実現方法
（b） システム構成
（c） システム開発方式（言語等）
（d） 開発基準，標準
（e） 開発環境運用，操作要件：
（a） システム運用手順
（b） システム運用形態
（c） システム運用スケジュール
（d） システム監視方法，システム監視基準
（e） サービス提供条件（障害復旧時間等）
（f） 災害対応策（Disaster Recovery）
（g） 業務継続策（Business Continuity）
（h） データの保存周期，量
（i） エンドユーザ操作方法移行要件：
（a） 移行対象業務
（b） 移行対象ソフトウェア
（c） 移行対象ハードウェア
（d） 移行手順
（e） 移行時期付帯作業：
（a） 環境設定
（b） 端末展開作業
（c） エンドユーザ教育
（d） 運用支援その他要件：
（a） 費用，納期の目標値
（b） 電力量
（c） 作業環境
（d） フロア面積
2.担当する業務を遂行する上での，業務への新たなニーズ及び要望への対応や，問題点への対策に起因する追加，改善のための要件を整理するとよい。用語の定義では，特に組織特有の意味をもつ用語は残らず定義するとよい。
3.機能要件の定義としては，JIS X 0135-1（ISO/IEC 14143-1）「ソフトウェア測定－機能規模測定－第1部：概念の定義」に，「利用者の要求を満足するためにソフトウェアが実現しなければならない利用者の業務及び手順を表す」とある。
画面の設計では，画面の原案を利用部門が作成して，それを開発者が実装可能なレベルに変換することが望ましい。また，画面の遷移についても利用部門が確認するとよい。
4. 運用プロセス（3.1 参照）で設定された，応答時間，回復時間，セキュリティなどの業務運用評価基準がある場合には，運用，操作要件としてこれらを定義した上で，他の非機能要件への反映も検討する。
2.2.4：「要件の評価アクティビティ」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である原理原則[4] ステークホルダ間の合意を得ないまま，次工程に入らない
原理原則[7] ライフサイクルコストを重視する 2.2.4.1：
1.必要があれば，システム化計画及びプロジェクト計画の見直しを行う。
2.例えば，運用テストのテスト計画，テスト設計，テストケース作成，テストデータ作成，環境作成，テスト実施，テスト評価等の役割分担を企画部門，利用部門，情報システム部門，ベンダ等で明確化する。
3.この場合の「要件変更」とは，主に取得者内の利害関係者間での合意変更ルールであり，取得者と供給者間での要件変更については，合意・契約の変更管理プロセス（1.3）に従う。
なお，要件の追加や変更は，ベースラインで取り決めた当初の人，物，金，時間，環境等への影響を伴う。したがって，予算を追加する，機能を削減する，開発方針を見直すなどを事前にルール化する。
さらに，影響を受ける利害関係者の合意の手続きについても取り決めておく。
2.3：
1.システム開発プロセス及び開発作業におけるユーザ，ベンダ間の役割分担については，第4部1.2
「（c） システム開発プロセス，ソフトウェア実装プロセス」に概説している。
2.システム開発プロセスは，システムの新規開発やその保守に伴う開発（是正保守，予防保守，適応保守，完全化保守）又は旧システムからの移行に伴う開発を行う場合に用いられる。
3.システムレベルのプロセスとソフトウェアレベルのプロセスの関係については，第2部5.1 「（7）ソフトウェアを中心としたシステム関連作業までを包含」を参照のこと。
2.3.1.1.1：ここでいうライフサイクルモデルとは開発モデルを指す。使用すべきソフトウェアライフサイクルモデルが契約で指定されている場合はそのモデルに従う。指定がない場合は，条件に合ったソフトウェアライフサイクルモデルを定義，選択し，アクティビティ，タスクを選定し，ライフサイクルモデルと対応付ける。
2.3.1.1.5：開発で使用した非納入品目が，取得者側の保守でも使われる必要がある場合は，開発者は供給者と取得者にその旨を伝え，両者がその扱い（納入品目にするか，非納入品目にするか）について協議する機会を与えることが望ましい。
2.3.2：何が要求されているかを十分に理解するためには，利用者集団からヒアリングを行うとよい。
2.3.2.2：システム要件の評価は，開発者に対し，次のステップであるシステム方式設計段階でシステム要件が実現できるかどうか，さらにシステムの運用が可能かどうか，また，システムの保守を可能とする内容であるかどうかを見極めることを課している。例えば，製品の開発が可能かどうかを見極めるために，プロトタイピングやシミュレーションといった作業が必要な場合がある。
2.3.5.2.1：データは，できる限り本稼働で用いるデータに近いものを設定する。現行システムのデータが存在する場合は，セキュリティを考慮した上で，それを移行して利用する。
2.3.7：システム導入は，本来取得者が責任を負う作業である。いわゆる「開発」案件の委託に際して，システム導入に対する供給者と取得者の責任範囲を明確にしておく必要がある。
2.3.7.1：システム導入の計画作成及び実施においては，既存の業務及びシステムに及ぼす影響の大きxx様々な利害調整が必要となることから，取得者が作業主体となり，供給者（ここでは開発者にあたる）はそれを支援する形が望ましい。
2.4.1.1.1：ここでいうライフサイクルモデルとは開発モデルを指す。使用すべきソフトウェアライフサイクルモデルが契約で指定されている場合はそのモデルに従う。
2.4.1.1.5：開発で使用した非納入品目が，取得者側の保守でも使われる必要がある場合は，開発者は供給者と取得者にその旨を伝え，両者がその扱い（納入品目にするか，非納入品目にするか）について協議する機会を与えることが望ましい。
2.4.2：何が要求されているかを十分に理解するためには，利用者集団からヒアリングを行うとよい。
2.4.2.1.1：外部インタフェースには，例えば次のものが含まれる。
サブシステム間や他システムとのインタフェースとなる電文，ファイル，データベース等ユーザインタフェースとなる画面，帳票，ファイル
2.4.2.1.1：（a） ～ （k）について，それらの目標基準を定義するような様式を前もって決めておくとよい。（b） の要件に関しては，ソフトウェアを取巻く環境として，従来のinB（社内システム）の観点の他に，BtoB（企業間取引），BtoC（インターネットなどによる不特定顧客取引），ASPやSaaS（サービスとしてのソフトウェア提供者）などとの関係も考慮する必要がある。
2.4.2.1.2：ソフトウェア要件の評価には，ソフトウェア品目の外部インタフェースに対する要件の評価も含まれる。
2.4.3.1.1：「最上位レベルの構造を表現する方式で」とあるように，ここでは特定の手法に依存した定義を行っていない。
適用に際しては，開発計画に記述された標準，手法，ツールに従って具体化し，定義する。
2.4.5：文中のソフトウェア設計とは，ソフトウェア方式設計（2.4.3.1）及びソフトウェア詳細設計
（2.4.4.1）の結果を指す。
2.4.5.1：「ソフトウェア構築」とは，いわゆるプログラミングのことを指す。
2.4.6：成果g） 回帰戦略は，リグレッション戦略と同意である。
2.4.8.1：導入とは，本番移行用ライブラリへの登録などを指す。本番環境へのインストール及び本番データの移行は運用者が行う（3.1参照）。
2.6：
1.ソフトウェアの保守プロセスについては，第4部1.2「（d） 保守プロセス」に概説している。
2.システム及びソフトウェア製品は開発段階にあるものよりも保守段階にあるものが多い。実際に，多くのシステム，ソフトウェア製品が保守契約を結んでいる。
システム及びソフトウェア製品の保守プロセスを代行するアウトソーシング契約もある。共通フレームでは保守サービスと呼んでいる。
契約を結ぶ場合には，保守項目は保守プロセスをテーラリング（修整）して用いるとよい。保守契約に関しては，「情報システム・モデル取引・契約書」の「情報システム保守運用委託基本モデル契約書」を参照のこと。
保守プロセスは問題解決プロセス（4.7参照）から呼び出される場合がある。保守契約を結んでいる場合には，問題解決プロセスは保守プロセスの中に埋込んで定義してもよい。
3.保守プロセスで作成される保守計画は，ソフトウェア保守戦略での分析結果を受けて作成されることが望ましい。ソフトウェア保守戦略の主な要素は，保守概念，保守計画，資源分析である。詳細は，ISO/IEC TR 24748-3:2011 を参照。
4. 共通フレームは，国際規格である「ISO/IEC 12207（JIS X 0160）ソフトウェアライフサイクルプロセス」に適合するが，ISO/IEC 12207（JIS X 0160）規格には，その規格群の一つであり，保守プロセスと密接な関係を持つ「ISO/IEC 14764（JIS X 0161）ソフトウェア保守」の規格がある。この規格は，保守プロセスのフレームのみならず，実施時の考慮事項，ソフトウェア保守の戦略などについても記述するとともに，タスクリストを明示するなどソフトウェア保守の内容をより詳細に説明している。
5. 保守プロセスのガイダンスでは，この規格で示されたアクティビティでの入力／出力の成果等，その一部を取入れている。詳細については，補足説明集 2.3 （1） を参照。
2.6.1：
1.業務運用及びシステム運用に関する文書は，例えば，業務運用マニュアルやシステム運用マニュアルを指し，以下のような記述内容があるとよい。
運用モード（通常運用・デグレード・保守・訓練・緊急事態・代替サイト・平時）に関する記述 利用者のクラス分け（操作する利用者，データ入力を行う要員，システム運用者，運用の支援要員，
ソフトウェア保守担当者，トレーナーなど）に関する記述，現行システム及び保守後のサービスレベルに関する記述
2.保守者は，保守に必要な成果物の引き継ぎアクティビティの中で，保守プロセスで実施される計画及び手続きを作成する。保守計画作成は，保守者が企画プロセスに参画し，システム開発プロセス及びソフトウェア実装プロセスと並行して実施することが望ましい。また，保守者は，必要な組織上のインタフェースを確立することが望ましい。
3.このプロセス開始の準備アクティビティ実施のための入力と出力は以下の通りである。
入力は，旧ベースライン，システム文書，問題報告又は修正依頼などがある。出力は，保守計画，訓練計画，保守手続き，プロジェクト管理計画，問題解決手続き，測定計画，保守マニュアル，利用者へのフィードバック計画，引き継ぎ計画，保守性アセスメント，構成管理計画などがある。すべての出力は，構成管理下に置かれることが望ましい。
2.6.1.1：保守プロセスだけを契約する場合には，供給者は保守に必要なシステム，ソフトウェア製品は，取得者から提供を受ける。保守のために新たにシステム，ソフトウェア製品が必要な場合は，保守契約に含めるか，取得者が用意するかを決めておく。
2.6.1.3：修正手続きは契約で定めておくとよい。契約手続きの提案は，利用者が行ってもよい。
2.6.1.4：構成管理プロセス（5.5参照）及びソフトウェア構成管理プロセス（5.6）の実施に当たっては，保守者，運用者，利用者の役割分担を明確にするとよい。
2.6.1.5：保守に必要な文書を保守文書と呼ぶことがある。保守プロセス（2.6）に対する契約を行う場合には，保守に必要な文書は，取得者から提供を受ける。
保守に必要な文書がない場合は，その作成及び責任範囲を契約に含めることがある。システム開発プロセス（2.3）及びソフトウェア実装プロセス（2.4）から保守プロセス（2.6）への引き継ぎは，業務及びシステムの移行（3.1.3）に基づいて行う。
2.6.2：保守者は，システムを修正する前に組織，現行システム及び関連するシステムへ与える影響を明らかにするため，問題報告又は修正依頼を分析することが望ましい。
推奨する可能性のある解決策を作成し文書化し，実現するための承認を得る。
この問題把握及び修正分析アクティビティ実施のための入力と出力は以下の通りである。
入力は，問題報告及び修正依頼，ベースライン，ソフトウェアリポジトリ，システム文書などがある。システム文書は，構成状況の情報，機能要件，インタフェース要件，プロジェクト計画立案データ，
保守プロセス（2.6）のプロセス開始の準備（2.6.1参照）からの出力などがある。
出力は，影響分析，推奨された選択肢，承認された修正内容，更新された文書などがある。
影響分析は，問題又は新しい要件の記述，問題又は要件の評価，要求された保守タイプの分類，初期の優先順位，検証データ（是正修正の場合），現行システムを修正するために必要な資源の初期見積りなどがある。
更新された文書には，テスト戦略，テスト計画，テスト手順及びテスト報告を含むテスト文書，ソフトウェア文書，要件などがある。
2.6.2.1：修正依頼の項目を保守者の業務として行う場合には，契約に明記するとよい。利用者の業務として行うものがある場合も，契約に明記するとよい。
2.6.2.2：問題の再現の確認を利用者が行うように契約で定める場合もある。
2.6.2.3：修正案の選択肢で用意する範囲及び技術的な要件について契約に定めるとよい。範囲を定めていない場合，選択肢の提案を無制限に求められることがある。
2.6.2.4：運用者又は利用者が問題報告／修正依頼の文書化を行うように契約で定めてもよい。
2.6.3：保守者は，修正の実施アクティビティの中で，ソフトウェア製品の修正及びテストを実施する。修正には，システム開発プロセス（2.3）及び ソフトウェア実装プロセス（2.4）を開始する。
このアクティビティ実施のための入力と出力は以下の通りである。
入力は，ベースライン，問題把握及び修正の分析（2.6.2参照）からの出力などがある。
＊ベースラインは，システム方式の定義，修正履歴，ソースコードを含むことが望ましい。
出力は，更新されたテスト計画及びテスト手順，更新された文書，修正されたソースコード，テスト報告，計測指標などがある。
＊更新された文書は，更新された修正履歴，詳細な分析報告，更新された要件，更新されたテスト計画，テスト手順及びテスト報告，更新された教材などを含むことが望ましい。
また，修正対象が購入パッケージの場合には，調達の際に定義された契約事項に基づき，購入パッケージの修正を行う。なお，保守契約に関しては，「情報システム・モデル取引・契約書」の「情報システム保守運用委託基本モデル契約書」を参考にするとよい。
2.6.4：保守者は，保守レビュー及び／又は受入れアクティビティの中で，システムの修正と承認が正しく完了していることを確認する。
保守レビュー及び受入れアクティビティ実施のための入力と出力は以下の通りである。入力は，修正されたソフトウェア，修正テストの結果などがある。
出力は，受入れられた修正を組込んだ新ベースライン，却下された修正，受入れ報告，レビュー及び監査報告，ソフトウェア適格性確認テスト報告などがある。
2.6.5：
1.保守者は，システムを異なる環境で稼動させるための変更が必要な場合には，新しい環境へのシステム移行に必要な作業を見極め，手順や工程，計画を作成する必要がある。
この移行アクティビティを実施するための入力と出力は以下の通りである。入力は，旧環境，新環境，旧ベースライン，新ベースラインがある。
出力は，移行計画，移行ツール，目的の通知，移行したソフトウェア製品，完了の通知，保管データなどがある。
2.データを移行するためのツールの開発や調達，移行の自動化のための開発，移行用のシステム構築や設定が必要な場合は，要件定義プロセス（2.2），システム開発プロセス（2.3）及びソフトウェア実装プロセス（2.4）を用いて，移行の前に準備する必要がある。
3.1：
1.運用プロセスについては，第4部1.3「（a） 運用プロセス」に概説している。
2.運用プロセスで扱う運用には，システムの運用，業務の運用及びパッケージソフトウェア利用の支援が含まれる。
運用プロセスで運用者が支援する対象となる利用者には，次のような利用者が含まれる。システムの運用サービスを受ける一般の利用者
システムの運用サービスを受けて業務を行う利用者又はオペレータシステムの運用を専門に行うオペレータ
パッケージソフトウェアを利用する一般の利用者
したがって運用では，運用者が直接システムを運用して，そのサービスを受ける一般の利用者，業務を行う利用者又はオペレータを支援する場合がある。
運用プロセスからもたらされる情報は，保守，及び客先からの提案依頼，企画などに関係する場合がある。
3.「運用プロセス」については，「超上流から攻めるIT化の原理原則17ヶ条」の中で，以下の原理原則を参照するとよい。
原理原則[8] システム化の方針・狙いの周知徹底が成功の鍵となる原理原則[12] 表現されない要件はシステムとして実現されない 原理原則[13] 数値化されない要件は人によって基準が異なる
4.「運用プロセス」について，SMSを導入している場合は，JIS Q 20000-1:2012の中の以下の内容を参照するとよい。
4 サービスマネジメントシステムの一般要求事項
5 新規サービス又はサービス変更の設計及び移行
6 サービス提供プロセス
7 関係プロセス
8 解決プロセス
9 統合的制御プロセス
3.1.1：利用者のクラスには，操作する利用者，データ入力を行う要員，システム運用者，運用の支援要員，ソフトウェア保守担当者，トレーナー等を含む。また，運用モードとは，通常運用，デグレード，保守，訓練，緊急事態，代替サイト，新旧並行運用，平時等をいう。
SMSを導入している場合は，計画立案については，JIS Q 20000-1:2012の中の4.5.2 SMSの計画を参照するとよい。
3.1.1.2：運用の開始は，開発の遅れ，開発成果物の不備又は開発時には予見できなかった問題点など，主にシステム開発プロセス及びソフトウェア実装プロセスによる影響を受けることがある。そこで，開発をはじめとする各プロセスに運用に役立つ資産を要請し，それらを引き継ぐあるいは入手し，運用中に利用できるように準備する作業を重視して運用・サービスプロセスのタスクとしている。例えば，業務運用仕様書を運用マニュアル原案として利用する，システム適格性確認テスト結果をもとに運用中の負荷状況を分析する，又はテスト結果を参照して利用者からの問い合わせに回答するなどの運用を実行できるように資産を引き継ぐ。取得者又は供給者からの運用のための資産の引き継ぎは，取得者又は供給者と運用サービスに限定して契約した第三者が運用プロセスの活動を行う場合に特に重要となる。
運用のための資産には，運用を補助，監視，分析又は改善するために有用な関連製品，文書類，データ及びツールなども，運用対象のシステム，ソフトウェア製品又はサービス及び運用マニュアルと同様に含めるとよい。
3.1.1.2（b）：設計文書には，処理機能，画面，入力帳票，出力帳票，業務手続などを含めるとよい。
3.1.1.2（c）：取得者の受入れ確認文書とは，利用者又は取得者がシステム，ソフトウェア製品又はサービスの受入れを確認したことを示す文書を指している。
3.1.1.2（d）：業務運用マニュアルについては，業務運用に係る作業手順の確立（3.1.1.8）を参照のこと。
3.1.1.3：SMSを導入している場合は，サービスマネジメントプロセス（3.3）の 解決管理（3.3.3）を参照するとよい。
3.1.1.6：「ISO/IEC 9126（JIS X 0129）ソフトウェア製品の評価－品質特性及びその利用要領」にあるソフトウェア品質特性（機能性，信頼性，使用性，効率性，保守性，移植性）を品質モデルとして参考にし，評価基準を設定してもよい。
またSMSを導入している場合は，JIS Q 20000-1:2012の中の4.5.3 SMSの導入及び運用を参照するとよい。
3.1.1.6（d）：安全性とセキュリティに関しては，以下を参照するとよい。
「システム管理基準」 （経済産業省，2004年）
「システム監査基準」 （経済産業省，2004年）
「金融機関等コンピュータシステムの安全対策基準・解説書（第8版）」（金融情報システムセンター，2011年）
「コンピュータ不正アクセス対策基準」 （経済産業省，2000年）
「コンピュータウイルス対策基準」 （経済産業省，2000年）
「情報セキュリティ管理基準」 （経済産業省，2009年）
「情報セキュリティ監査基準」 （経済産業省，2003年）
「JIS Q 27001（ISO/IEC 27000シリーズ）」 （日本規格協会，2006年）
3.1.1.6（f）：運用時間の管理の評価では，例えば，データをバックアップするためにサービス提供を休止する時間及び定期点検に要する時間などを評価するとよい。
3.1.1.6（h）：定性的には，システム運用によるサービスを受ける顧客へのイメージアップや顧客対応の充実など，運用目的との適合度を評価するとよい。
定量的には，利用者の作業量が軽減された省力化の比率，システムが提供するサービスの稼働率（例えば，ネットワーク接続稼働率）などを評価するとよい。
3.1.1.8：業務運用マニュアルから派生する文書化の例としては以下のものがある。システム（画面）操作マニュアル
システム運用マニュアル業務運用規定
障害時対応マニュアル情報セキュリティ規約
3.1.1.8：手書き帳票，ローカル伝票を運用開始までに準備する。
3.1.1.10：運用評価基準をもとに運用テスト終了基準を設定するとよい。
3.1.2.1：このタスクには，運用テスト環境へのプログラム及びデータベースの導入（インストール），運用テストのためのテストデータの用意などが含まれる。
擬似運用環境で運用テストを実施した場合は，業務及びシステムの移行（3.1.3）を実施してから運用を始める必要がある。実運用環境で運用テストを実施した場合は，システム運用（3.1.4）を実施できる。
3.1.2.3：運用テスト終了基準（3.1.1.10参照）を満たすことが確認できたら，利用部門へ報告又は共同レビューを開催し，移行の是非についての判断を促す。
3.1.3：
1.移行に伴う作業の規模や難易度，リスク，費用などから見て，影響範囲が広いと判断した場合は，移行自体を開発とは別のプロジェクトとして管理するのが望ましい。
2.本アクティビティは，擬似運用環境で運用テストを実施したシステムを，実運用環境に移行する際に実施する。
ISO/IEC 12207（JIS X 0160）では，本アクティビティは特に規定されていないが，共通フレームでは，システムとシステム運用手順だけでなく業務の運用手順も重視し，このアクティビティを設けている。
運用中のシステム又はソフトウェアの移行は，運用プロセス（3.1）の業務及びシステムの移行
（3.1.3）を実施する。
3. SMSを導入している場合は，サービスマネジメントプロセス（3.3）の 統合的制御管理（3.3.4）を参照するとよい。
3.1.3.1：共通フレームでは移行のためのツールやデータも製品の一部としている。ソフトウェアの作成及びデータの作成については，必要に応じてシステム開発プロセス（2.3）及びソフトウェア実装プロセス（2.4）に引渡して実施する。
3.1.3.2（c），（d）：データを移行する際は，移行するデータの取捨選択の他に整合性の崩れたデータの修復や文字コード（全半角，外字等）統一，新旧の読み替えなど複雑な取り扱いを明示し，必要に応じツールを開発しておくことが望ましい。
移行データの準備には，旧システムに登録されているデータの整備状況を確認し，あらかじめ移行できる状態にデータを整備しておくことを含む。
3.1.3.2（i）：移行作業は限られた時間で行うため，事前策として，移行作業における障害発生時の対応計画を織込んでおくとよい。対応計画には移行作業のやり直しや旧運用に戻すなどの対応策を選択する判断基準も必要である。
3.1.3.2（j）：旧運用から新運用へ切替える際には，新たに追加又は修正された運用手順が，移行後の運用要件に合致していることを確認する。
このため，新運用での新しい要件だけでなく，新運用でも旧運用と変わらない要件についても合致していることを確認するとよい。
3.1.3.2（j）：移行の実施前に，供給者等による移行支援を受けることができるよう，手配しておくことを考慮する。これは，新運用への移行直後に，テスト時には発覚しなかった事象に対処するためである。事前に決めておくこととして，支援の実施期間，あるべきシステムの状態，期待すべき初期評価などがある。
3.1.3.7：旧運用関連データを保持し，新旧の運用の切替えトラブルの発生時に，新旧のデータ比較又は旧運用に戻すなどの対策がとれるようにするとよい。
3.1.4.1：利用者用文書とは，システム運用マニュアル，業務運用マニュアルなどの文書を指す。
3.1.4.1 注記4：例えば，運用の自動化システム，運用支援ツール，ネットワーク，監視ツール，複数分散システムのxx監視ツール等により，システム運用者の作業負荷を軽減するなどの方策がある。継続的な運用改善活動を確立することが望ましい。
3.1.4.1 注記5：SMSを導入している場合は，サービスマネジメントプロセス（3.3）のサービス提供管理
（3.3.1）を参照し，サービスレベル管理，サービス報告，サービス継続及び可用性管理，サービスの予算業務及び会計業務，容量・能力管理，情報セキュリティ管理等の事項を検討するとよい。
また，必要に応じて，関係管理（3.3.2），解決管理（3.3.3），統合的制御管理（3.3.4）も参照するとよい。
3.1.5.1：このアクティビティの実施については，要求を出す側の業務担当者，エンドユーザの代表者が中心となって計画し，システムの実際の開発者や運用担当者を組織して実現する必要がある。
3.1.5.2：利用者への周知は，システム開発の早い段階で行うことで現場の協力を得やすくなるが，周知のタイミングや方法は工夫する必要がある。
3.1.5.3：円滑な移行と業務運用を可能にするため，教育内容としては利用者に対する新システムの操作方法や業務の手続きなどが必要となる。
3.1.6.4：当面の回避策として，運用制限又は機能縮退運転など，運用手順上の対策を検討するのがよい。回避策には，ソフトウェア及びシステムの代替利用又は性能の優れたCPU，ハードディスク，通信設備，といったハードウェアの代替利用も含めてよい。
3.1.6.4：SMSを導入している場合は，サービスマネジメントプロセス（3.3）の解決管理（3.3.3）を参照するとよい。
3.1.7：システム運用の評価は， システム運用評価基準の設定（3.1.1.6）で設定したレベルを評価する。
3.1.7：運用者はシステム運用の課題及び改善の必要性が認識された場合，企画プロセス（2.1参照），要件定義プロセス（2.2参照）に引き継ぐ際，新システム構築のメンバーとして参画することもできる。
3.1.7.1（f）：例えば，データをバックアップするためにサービス提供を休止する必要のある時間，定期点検の時間などの必要性を評価するとよい。
3.1.7.1（h）：運用目的との適合，利用者の作業量が軽減された比率，システムが提供するサービスの稼働率（例えば，ネットワーク接続稼働率）などを評価するとよい。
3.1.8：業務運用の評価は，業務運用評価基準の設定（3.1.1.9）で設定したレベルを評価する。
3.1.9：投資効果と業務の改善効果について，旧業務運用時の過去のデータ，新業務運用システムの企画で見込んだ予想データ，及び新業務運用での実績データを比較するとよい。
3.2.2：ソフトウェア製品がその製品寿命に達した場合には廃棄を行う。廃棄を実際に行う前に分析を実施することが望ましい。
廃棄の分析では，次のことを判断することが望ましい。時代遅れの技術の保持
新しいソフトウェア製品を開発することによる新技術への移行モジュール性を達成するための新しいソフトウェア製品の開発保守を容易にするための新しいソフトウェア製品の開発
標準化を達成するための新しいソフトウェア製品の開発
納入者からの独立を容易にするための新しいソフトウェア製品の開発
保守者は，ソフトウェア製品を廃棄するために，必要な手順を作成することが望ましい。また，廃棄されたソフトウェア製品のデータ利用についてどのように扱うべきか考慮することが望ましい。
この廃棄の実行アクティビティを実施するための入力と出力は以下の通りである。
入力は，廃棄される旧ソフトウェア製品のベースライン，新しいソフトウェア製品，旧環境などがある。
出力は，廃棄計画，目的の通知，廃棄の結果，教育訓練を受けた人々，廃棄されたソフトウェア製品，完了の通知，測定値，保管されたベースラインなどがある。
3.2.2.2（a）：例えば，デバイス，CPU等のハードウェアのリプレースやアップグレードを含む。
3.2.2.3：切替えの失敗等に備えて，エンドユーザの運用継続ができるよう，いざというときの切戻しのために新旧ソフトウェアの並行運用を行うとよい。
3.2.2.4：関係者とは，業務運用者及び支援要員等を指す。
3.3：
1.サービスマネジメントプロセスについては，第4部1.3「（b） サービスマネジメントプロセス」に概説している。
2.サービスマネジメントプロセスのアクティビティとタスクに対する責任は，そのプロセスを実行する組織にある。
4.1：システム又はソフトウェアは可視化しにくいため，生み出される情報の文書化及び管理は重要である。文書の変更をxxの手続きで行う場合は，構成管理プロセス（5.5参照）に従って管理する。
4.1.1.1：作成する文書の種類を決め，名称や文書コードを付与して識別できるようにする。
4.1.3.1：電子媒体を使用する場合は，セキュリティや媒体の劣化を防ぐための考慮が必要である。
4.1.3.2：不適切な文書を使用させないために，文書の最新版を識別するための管理が必要である。これは，例えば，以下のことを保証する。
（a） 適切な版を使用すべきすべての場所で利用可能にし，最新版がどれであるかが常に分かるようにする。
（b） 不適切な文書は，発行あるいは使用するすべての場所から速やかに取り除き，それが継続して使用されないようにする。
4.2：品質保証プロセスについては，第4部1.4「（a） 品質保証プロセス」に概説している。
4.2.1.2：
1.品質保証に関連したプロセスについては，補足説明集 2.2「（2） ISO 9001 による品質マネジメントシステムの保証」及び「（3） 効果的な品質保証の実施」を参照のこと。
2.関連するプロセスを調整する目的は次のとおりである。不必要な評価作業，有害な重複作業を排除すること
評価作業は互いに意味があり，現実的であること
関連したプロセスから矛盾した報告が出された場合は，問題解決プロセス（4.7参照）に引渡す前に解決されること
4.2.3.3：主契約とは，取得者と供給者が当初結んだ契約（prime-contract）をいう。
4.2.4.1：JIS Q 9001 （ISO 9001） の適用については，第4部2.2「（10） 共通フレームの適用例」，補足説明集2.2「共通フレームの「品質保証プロセス」と関連する情報」を参照のこと。
1.検証プロセスについては，第4部1.4「（b） 検証プロセス」に概説している。
2.検証プロセスを含む品質管理に関するプロセスの特徴については，補足説明集 2.2「（3） 効果的な品質保証の実施」を参照のこと。
4.3.2.1：契約の検証は，提案依頼書又は見積依頼書などをもとに行う。取得者は，基本的に契約の締結前に，供給者から提出された提案書又は見積書などを検証する。
契約の検証は，供給者が，提案書又は見積書の提出前や契約の締結前に行うこともある。
4.3.2.2：プロセスの検証では，そのとおりに実施したことの確認が事後では困難な作業については，検証の方法を事前に考慮しておくべきである。例えば，コーディング規約を守っているかどうかは，作成したコードを見ることによって確認できるが，デザインレビューの実施方法が規定されていても，記録の方法によっては，そのとおりに実施したことが確認できない場合がある。
4.3.2.3：要件の検証は，例えば，システム要件定義書やソフトウェア要件定義書などをもとに行う。システム要件が完全で，正確であることや，ソフトウェア要件がシステム要件を正確に反映していることの検証に当たっては，関連する規格，標準及び他の製品の仕様書の適切な版が必要な場合がある。
4.3.2.4：設計の検証は，例えば，システム設計仕様書やソフトウェア設計仕様書などをもとに行う。設計の検証には，必要に応じて特定の領域の専門家を含めるべきである。例えば，ハードウェアと密接に絡むようなソフトウェアの設計の検証には，ハードウェアの専門家を含めるとよい。
4.3.2.5（a）：「標準」，「規約」及び「規定」は，厳密には意味が異なるが，守るべきことを記述したものという意味で，同じと考えてよい。
4.3.2.6：結合の検証は，例えば，ソフトウェア設計仕様書などをもとに行う。
結合の検証では，結合されたソフトウェアが，xxに構成管理されている検証済みのコードで構成されていることも確かめるべきである。また，ハードウェア品目がシステムに含まれている場合，ハードウェアが最終製品ではない（β版等）状況では，ソフトウェアへの影響について常に考慮する必要がある。
1.妥当性確認プロセスについては，第4部1.4「（c） 妥当性確認プロセス」に概説している。
2.妥当性確認プロセスを含む品質管理に関するプロセスの特徴については，補足説明集 2.2「（3）効果的な品質保証の実施」を参照のこと。
4.4.2.2：「意図された用途に対応した」とは，利用者の視点に立った用途に適合したという意味である。
1.共同レビューのアクティビティは，取得者と供給者間の公式な，契約上定められたやり取りのための枠組みを規定する。すなわち，契約に定められた手順に従い，取得者と供給者間で各段階（プロセス，アクティビティ）での成果物の内容や進捗状況に関して同意を得る。共同レビューは，管理面と技術面の両方からなり，契約期間中開催される。
2.共同レビュープロセスは，社内においても利害を異にする二者間に用いてよい。例えば，SLA（サービスレベル契約）を結ぶユーザ部門と情報システム部門間などである。
3.共同レビュープロセスを含む品質管理に関するプロセスの特徴については，補足説明集 2.2「（3）効果的な品質保証の実施」を参照のこと。
4.5.2.1：プロジェクト進捗状況報告書やプロジェクト工程管理xxで評価する。
1.監査プロセスについては，第4部1.4「（d） 監査プロセス」に概説している。
2.この監査プロセスでは，成果物と活動の両方を監査の対象としている。これに対して ISO 9001の品質マネジメントシステム規格で要求されている内部品質監査の活動では，成果物の品質を直接確かめることは要求されていない。
監査する者（auditor，auditing party）は，監査者，監査人，監査組織と呼ばれることがある。一方，監査を受ける者（audited party）は，被監査者，被監査人，被監査組織と呼ばれることがある。
3.「システム監査」プロセス（6.8参照）との違いについては，「システム監査」プロセス（6.8）のガイダンスを参照のこと。
4.監査プロセスを含む品質管理に関するプロセスの特徴については，補足説明集 2.2「（3） 効果的な品質保証の実施」を参照のこと。
4.6.1.1：監査は，監査の目的が果たせるような時期に実施する必要がある。例えば，作業が手順どおりに行われていることの確認は，作業が完了してしまってからでは不可能な場合もあることを考慮する必要がある。
4.6.1.2：監査活動の客観性及び独立性を保証するため，次のことに留意する。
組織内部の監査者が監査を行う場合には，監査者は監査対象となる組織から独立した別の組織に所属している必要がある。
監査者は客観的な判断力を維持するために，過去に開発の活動に携わった製品に対する監査を避ける必要がある。
監査者は，その監査結果により監査対象の製品に再作業や納入時期遅延などの影響が生じたとしても責任を問われないことを確認する必要がある。また，監査者の独立性をさらに高めるために，組織は外部の第三者に監査を委託してもよい。
4.6.1.3：例えば，監査を受ける側が，監査のための場所，設備及びツールを提供したり，監査者がインタビューできるように開発者の予定を調整する場合がある。監査者にも，監査対象の業務内容を理解する能力と監査技術が求められる。
4.6.1.4：議題（agenda）では監査の重点テーマを示すとよい。
監査対象が開発プロセスの活動成果以外の場合もある。例えば，運用プロセスの業務運用支援についても監査することがある。
4.6.1.5：問題点の記録は，後でその事実が確認できるような証拠資料（監査証跡となるエビデンス）を添付するとよい。
4.6.1.6：監査結果を文書化したものは，監査報告書とするとよい。監査結果に至るまでの経緯が分かるように，監査全体を通じての結果を記述するとよい。
4.6.2.1：監査の項目，基準及び手順を適切に運用するのを助けるために，監査マニュアル等を整備するとよい。
4.6.2.1（a）：監査者は，監査を効果的に実施するため，次のような調査や資料提供を，開発者又は運用者などに要請する場合がある。
（1）監査対象の成果物，プロセス，人，機器設備などの一部分を抽出してサンプリング調査する。
（2）組織の管理者や担当者又はユーザにインタビューや質問を行って調査する。
（3）文書類を閲覧して調査する。
（4）レビュー又はテストの記録などの有無，記録の記載内容を調査する。
（5）監査のためのレビュー又はテストを実施して調査する。
（6）製品を使用して調査する。
4.6.2.1（h）：費用については，要員及び工数の配分，教育訓練への投資，環境又は機器，設備の整備への投資などが適切であったかどうかを確認する場合がある。予定については，実施が時機を逸さず適切な時期であったかどうかを確認する場合がある。例えば，十分な要員と工数で，適切な時点に，レビュー及びテストなどの活動，開発及びテスト環境の整備，教育訓練が実施されたかなどを確認するとよい。
4. 支援プロセス
4.7.1.1（a）：問題が発見された時点で問題記録票（障害記録票，バグ票などを含む）が起票される。この問題記録票には，原因の調査，分析及び解決についての記載欄が設けられている。問題記録票は，プロジェクト期間を通じて管理保存され，原因の判明，対策内容の確定に従って，その内容が追記される。また，問題を横断する傾向が発見された場合，その内容と対応についても記録が加えられる。
4.7.2.1：問題解決プロセスに従って問題を解決する。これらのプロセスの実施は問題報告書にまとめられる。
問題には，製品やサービスに含まれる問題とその製品やサービスを生み出すプロセスに含まれる問題がある。問題解決プロセスを通じて問題を除去するとともに再発を防止するための予防処置をとることが望ましい。例えば，ソフトウェアの問題であれば，保守プロセス（2.6参照）を呼び出す。
プロジェクト期間を通して，問題記録票全体をまとめたものが問題報告書となる。問題報告書は，標準化に対するフィードバック，次期システムや後続システムにインプットされる。
5.1.1.1：プロジェクト計画プロセス（5.1）は，システム又はソフトウェア製品の構築に係るプロジェクトだけでなく，新しい事業又は業務を構築するためのプロジェクト全体に利用するとよい。
5.1.1.2：例えば，そのための入力情報としては，プロジェクト概要書，リソース一覧表などがある。プロジェクトの範囲と規模によって管理ツールを使用した方がよい場合がある。そのようなツールの利用に当たっては，使用方法の習熟に要する時間も考慮する必要がある。
5.4.6：リスク管理については，「ISO/IEC 16085 （JIS X0162）システム及びソフトウェア技術－ライフサイクルプロセス－リスク管理」が参照できる。
5.5.1.1：ISO 10007「品質マネジメントシステム－構成管理の指針」では，「構成管理とは，製品の構成を文書化するものである。構成管理は，ライフサイクルの全段階で，識別及びトレーサビリティ，その物理的及び機能的要件の達成状況並びに正確な情報へのアクセスをもたらす。構成管理は，組織の規模並びに製品の複雑さ及び性質に基いて実施できる。構成管理は，ISO 9001に規定されている製品識別及びトレーサビリティの要件を満たすために使用することができる」と定義している。
5.6：ソフトウェアの品目の例示としては，次のようなものが挙げられる。
システムソフトウェア関連：OS，データベースマネジメントシステム，各種ミドルソフトウェア アプリケーションソフトウェア関連：アプリケーションシステム，サブシステム，プログラム，モ
ジュール
ファイル関連：データベース，テーブル，レコード，フィールド
マニュアル関連：業務運用マニュアル，システム運用マニュアル，システム（画面）操作マニュアル
5.6.5：構成の評価は独立した活動として，あるいは契約で定められた監査プログラムの一部として実施してもよい。ここでいう技術的記述とは，ユーザの要求をソフトウェア品目に反映する場合の媒体（業務仕様書，技術仕様書等）となるものを指す。
5.8：
1.測定はプロジェクトプロセス全体に係り，定量的に管理し評価するPDCAサイクルを実施するために必要なアクティビティである。
2.測定については，「ISO/IEC 15939（JIS X 0141）システム及びソフトウェア技術－測定プロセス」が参照できる。
6. 組織のプロジェクトイネーブリングプロセス
6.1：
1.ライフサイクルモデル管理プロセスについては，第4部1.6「（a） ライフサイクルモデル管理プロセス」に概説している。
2.ライフサイクルモデル管理プロセスは，プロセスを確立し，改善するプロセスである。
プロセスを改善した結果，中間生産物が改善され，結果としてシステム，ソフトウェア製品及びサービスが良くなることが期待できる。人材，中間生産物及びシステム，ソフトウェア製品及びサービスを改善した結果として，プロセスが改善される場合もある。
プロセスアセスメント，プロセス改善の方法論の中には，人材，製品の改善とプロセスの改善を独立して取り扱うものもあるが，現場の改善活動の中では，それぞれのバランスをとるとよい。そのため，特定のプロセス改善方法を選択して実行するだけでなく，柔軟に対応してプロセスを改善するのがよい。
6.1.1.1：プロセスの確立に当たっては，JIS規格又は共通フレームを直接用いてもよい。
プロセスを特定の事例に適用する場合は，テーラリング（修整）プロセス（8.）を用いるとよい。
6.1.2.1：プロジェクトアセスメント及び制御プロセス（5.2）のプロジェクトアセスメント（5.2.3）の結果の評価（5.2.3.2）のうち，プロセスの評価はこのタスクで行うことができる。
6.1.3.2：プロセスの長所，弱点を理解するには，ISO/IEC 15504 Process Assessment（JIS X 0145），又はCMMI ，SPEAK-IPAのような一つの評価体系を用いるとよい。
分析の成果は，継続するプロジェクトだけではなく，組織の新しいプロジェクトに対してもフィードバックできる。
6.1.3.3：組織のプロセス標準は，テーラリング（修整）によって定義されたプロセスを指し，組織でプロセス標準を決定していることが望ましい｡
プロセスの保証（4.2.3） において，プロセスの改善が必要な場合は，プロセスの改善
（6.1.3） を実行することができる。
1.インフラストラクチャ管理プロセスについては，第4部1.6「（b） インフラストラクチャ管理プロセス」に概説している。
2.ここでいうインフラストラクチャには，単に開発を支援するインフラストラクチャ（開発環境）だけでなく，取得，供給，合意・契約の変更管理，企画，要件定義，運用又は保守を支援するインフラストラクチャも含まれる。
取得，供給プロセスで必要となるインフラストラクチャとしては，提案依頼書，ネットワークを介して契約書等をやり取りするための文書標準，電子メール，電子会議等のツール群が含まれる。また，開発プロセスで必要となる試験環境はもちろん，運用，保守プロセス等の実施に当たって必要となる作業場所，作業環境等も含めてよい。
ネットワークを介したオープンでグローバルなソフトウェアの調達や複数の供給者による協調分散開発のケースでは，インフラストラクチャ管理が特に重要となる。このため，取得者と供給者間でインフラストラクチャに対する十分な協議が必要であり，その責任分担，費用負担等の曖昧さによるトラブルが生じないよう契約書に明記しておく必要がある。
6.2.2.1： インフラストラクチャによっては，機器の手配，据付け等，準備期間を要するものがあるので注意する必要がある。また，必要により，インフラストラクチャ利用者に対する訓練も考慮する必要がある。
6.2.3.1：インフラストラクチャの利用状況及び利用効果の評価を行ってインフラストラクチャの改善に役立てるとよい。
1.人的資源管理プロセスについては，第4部1.6「（d） 人的資源プロセス」に概説している。
2.人的資源管理プロセスの実施に成功すると次の状態になる。
（1） 組織要件及びプロジェクト要件を適時にレビューすることによって，組織及びプロジェクトの運用に必要な役割及びスキル（技能）が識別されている。
（2） 人的資源が組織及びプロジェクトに提供されている。
（3） 組織及びプロジェクトからの入力に基づいた組織横断的な一連の共通の教育訓練ニーズが識別され，提供されている。
（4） 確立された仕組みを通して，組織の知的資産が利用可能となり（又は“収集され”），活用されている。
人的資源管理プロセスは，組織及びプロジェクトに対して，役割を効果的に実行し，統一感があるグループとして一緒に働くためのスキル（技術）及び知識をもつ人材を提供する。
6.7.1.1：適用可能なドメインエンジニアリング計画のひな形があれば，それを再利用する。計画には，ドメインエンジニアリングを実行するための標準，手法，ツール，活動，役割の割り当て及び責任を含めるのが望ましい。ドメインエンジニアリング計画を作成するために，ドメインエンジニアは，ドメインに関する文献及び／又はデータの資源を調査し，ドメインの専門家，開発者及びドメイン内でソフトウェア製品に関する利用者に助言を求めるのが望ましい。ドメインエンジニアリング計画を実行する。
6.7.1.2：ドメインの分析は，ドメイン内での共通性及び変動性を発見し，公式に記述するアクティビティである。ドメインエンジニアはこの情報を，ドメインモデル集合の中に記録する。
6.7.1.3：ドメインの設計は，ドメインの基本構造を定義し，ソフトウェア製品を構築するために利用できる資産の仕様を決める。ドメインの基本構造は，正式に資産のインタフェースの仕様が決まるような，xxレベルの設計である。ドメインの基本構造は，ソフトウェア製品を構成するために資産を再利用するための枠組みとして提供される。
6.7.1.5：資産の保守は次の内容も含まれる。
1. 資産修正の承認
ドメインエンジニアは，資産を修正するために，選択した実施の選択肢，スケジュール及び計画の承認を得る。
2. 資産修正計画の通知
ドメインエンジニアは，資産の修正要求が承認されたかどうかを資産管理者に通知する。さらに，それらの承認された修正要求のための計画及びスケジュールを資産の修正要求を依頼した資産管理者に通知する。修正要求が承認されなかった場合は，問題解決プロセス（4.7）に規定されたように，そのことが記録され，問題解決プロセスに入力される。
3.資産の修正
承認が得られた後，ドメインエンジニアは，資産に修正を実施するためにドメインエンジニアリングプロセスに入力する。
4.修正資産の送付
ドメインエンジニアは，利用指示書及びテスト資産とともに，完成した修正済み資産を，資産の修正要求を送った資産管理者へ提出する。
6.7.2.3.5：資産の再利用情報には，再利用者の氏名，プロジェクト名称，資産の最初の開発者又は所有者，資産の再利用の費用，並びに資産の再利用から得られた節約及び利得を含むことが望ましい。 6.7.2.3.7：資産管理者は，資産に関する問題に直面するときはいつでも，問題解決プロセス（4.7）を使
用することが望ましい。
6.7.3.1.1：再利用施策の要素は，次の事項を記述することが望ましい。
1.再利用後援者（スポンサ）
2.再利用基盤（再利用を実践するための，ハードウェア，ソフトウェア，ツール，技術，標準，測定方法及び設備を含む。）
3.再利用の資金及び他の資源
4.再利用施策支援機関
5.再利用の情報交換，フィードバック及び通達の仕組み
6.7.3.1.4：再利用運用部門は，次の事項を含むことが望ましい。
1.組織における再利用実態の調査
2.組織内の潜在的な再利用機会があるドメインの識別
3.組織内の再利用に対する責任の割当て
4.再利用を支援し促進するための組織の励みになるもの，意欲をそぐもの及び文化の再定義
6.7.3.1.5：再利用施策支援部門の責任は，次の事項を含むことが望ましい。
1.再利用施策実施計画の作成及び実施への参画
2.再利用戦略の識別，文書化，及びすべての再利用施策参画者への伝達
3.再利用に前向きなソフトウェア文化を促進するための再利用実態の推進
4.現在及び将来のソフトウェアプロジェクトにおける再利用を実践するための機会の探求
5.再利用基盤の確立及び維持
6.再利用を実践するソフトウェアプロジェクトへの再利用コンサルティング支援の提供
6.7.3.3.4：改善は，ライフサイクルモデル管理プロセス（6.1）を使用する。
6.7.3.4.1：適用可能な再利用施策計画のひな形があれば，それを再利用する。その計画は，次の事項を記述する。
1.再利用施策アクティビティ
2.これらのアクティビティを実行するための手続き及びスケジュール
3.これらのアクティビティを実行するための関係者の責任
4.ソフトウェア開発者，ドメインエンジニアなどの他の関係者との関係
5.再利用施策のために必要な資源
6.7.3.5.3：問題の解決には問題解決プロセス（4.7）を使用する。
6.8：
1.「システム監査」プロセスは，監査プロセス（4.6）とは別個の独立した監査人のプロセスとして取り扱う。
2.監査の対象にプロセスとソフトウェア製品が入る点で監査プロセスと「システム監査」プロセスは相通じている。一方，「システム監査」プロセスは，ITガバナンスの実現のため，情報システム全体にわたる信頼性，安全性，効率性などの観点からの監査を行うという点で，扱う範囲が広い｡
3.「システム監査」実施に際して，活用すべき基準と合わせて活用する指針として，次のものがあげられる。
（経済産業省）
「システム監査基準」，平成16年10月8日（改訂）
「システム管理基準」，平成16年10月8日策定
「システム管理基準 追補版（財務報告に係るIT 統制ガイダンス）」，平成19年3月30日公表
「情報システム安全対策基準」，平成9年9月24日（通商産業省告示第536号）（最終改正）
「コンピュータウイルス対策基準」，平成12年12月28日（通商産業省告示第952号）（最終改定）
「コンピュータ不正アクセス対策基準」，平成12年12月28日（通商産業省告示第950号）（最終改定）
「ソフトウェア管理ガイドライン」，平成7年11月15日策定
「情報セキュリティ監査基準」，平成15年4月1日策定
「情報セキュリティ管理基準」，平成15年4月1日策定
「SaaS向けSLAガイドライン」，平成20年1月2１日策定
「金融機関等コンピュータシステムの安全対策基準・解説書（第8版）」，平成23年3月，財団法人金融情報システムセンター
「JIS Q 15001：2006 個人情報保護マネジメントシステム－要求事項」
6.8.1.1：
1.「システム監査基準」は，システム監査人としての適格性及び監査業務上の遵守事項を規定する
「一般基準」，監査計画の立案及び監査手続の適用方法を中心に監査実施上の枠組みを規定する
「実施基準」，監査報告に係る留意事項と監査報告書の記載方式を規定する「報告基準」からなっている。
2.「システム監査基準」は，組織体の内部監査部門等が実施するシステム監査だけでなく，組織体の外部者に監査を依頼するシステム監査においても利用できる。さらに，情報システムに保証を付与することを目的とした監査であっても，情報システムの改善のための助言を行うことを目的とした監査であっても利用できる。
3.「システム管理基準」は，経営戦略に沿って効果的な情報システム戦略を立案し，その戦略に基づき情報システムのライフサイクルの中で，効果的な情報システム投資のための，またリスクを低減するためのコントロールを適切に整備，運用するための実践規範である。
6.8.1.2：
1.「システム監査」体制の整備で求められる，システム監査人の独立性，客観性と職業倫理，品質管理等については，「システム監査基準」の「・．一般基準」を参考にするとよい。
2.システム監査人を選択する際には，システム監査技術者試験の合格者が含まれるように選ぶとよい。外部のシステム監査人の一つとして，システム監査企業 （通商産業省の告示による「システム監査企業台帳に関する規則」に基づき，システム監査企業台帳に登録申請しているシステム監査を業とする企業） がある。
6.8.1.3：「システム監査」計画の策定については，「システム監査基準」の「・．実施基準」を参考にするとよい。
6.8.1.4：「システム監査」結果の「評価，結論」については，「システム監査基準」の「・．報告基準」を参照，確認するとよい。
6.8.2.1：
1.合意プロセス（1.）に関する「システム監査」に際しては，以下の文献が参考になる。
「情報システムの信頼性向上に関するガイドライン 第2版」，平成21年3月
「情報サービス・ソフトウェア産業維新」，産業構造審議会 情報経済分科会，平成18年9月
「情報システム・モデル取引・契約書（受託開発（一部企画を含む），保守運用）＜第一版＞」，平成19年4月）
「情報システム・モデル取引・契約書（パッケージ，XxxX／ASP活用，保守・運用）＜追補版＞」，平成20年4月
2.合意プロセス（1.）の「システム監査」項目として，経済産業省の「システム管理基準」で，76の基準項目を定めている「・.共通業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・.共通業務」
（a） ドキュメント管理
（b） 進捗管理
（c） 品質管理
（d） 人的資源管理
（e） 委託，受託
（f） 変更管理
（g） 災害対策
3.企画プロセス（2.1）の システム化構想立案プロセス（2.1.1）の「システム監査」項目として，経済産業省の「システム管理基準」で，47の基準項目を定めている「・．情報戦略」，23の基準項目を定めている「・．企画業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・．情報戦略」
（a） 全体最適化
（b） 組織体制
（c） 情報化投資
（d） 情報資産管理の方針
（e） 事業継続計画
（f） コンプライアンス
「・．企画業務」
（a） 開発計画
（b） 分析
（c） 調達
なお，必要に応じて「・．共通業務」も参照，確認するとよい。
4.企画プロセス（2.1）のシステム化計画の立案プロセス（2.1.2）及び 要件定義プロセス（2.2）の「システム監査」項目として，経済産業省の「システム管理基準」で23の基準項目を定めている「・．企画業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・．企画業務」
（a） 開発計画
（b） 分析
（c） 調達
なお，必要に応じて「・．共通業務」も参照，確認するとよい。
5.システム開発プロセス（2.3）及びソフトウェア実装プロセス（2.4）の「システム監査」項目として，経済産業省の「システム管理基準」で，49の基準項目を定めている「・.開発業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・.開発業務」
（a） 開発手順
（b） システム設計
（c） プログラム設計
（d） プログラミング
（e） システムテスト，ユーザ受入テスト
（f） 移行
なお，必要に応じて「・．共通業務」も参照，確認するとよい。
6.運用・サービスプロセス（3.）及び 保守プロセス（2.6）の「システム監査」項目として，経済産業省の「システム管理基準」で，73の基準項目を定めている「・.運用業務」，19の基準項目を定めている「・.保守業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・.運用業務」
（a） 運用管理ルール
（b） 運用管理
（c） 入力管理
（d） データ管理
（e） 出力管理
（f） ソフトウェア管理
（g） ハードウェア管理
（h） ネットワーク管理
（i） 構成管理
（j） 建物，関連設備管理
「・.保守業務」
（a） 保守手順
（b） 保守計画
（c） 保守の実施
（d） 保守の確認
（e） 移行
（f） 情報システムの廃棄
なお，必要に応じて「・．共通業務」も参照，確認するとよい。
7.支援プロセス（4.），プロジェクトプロセス（5.）及び 組織のプロジェクトイネーブリングプロセス（6.）の「システム監査」項目として，経済産業省の「システム管理基準」で，76の基準項目を定めている「・.共通業務」を参照，確認するとよい。
この基準は，次の構成になっている。
「・.共通業務」
（a） ドキュメント管理
（b） 進捗管理
（c） 品質管理
（d） 人的資源管理
（e） 委託，受託
（f） 変更管理
（g） 災害対策
6.8.3.1： 「システム監査」結果をとりまとめるに当たっての必要事項及び結果に基づく措置については，「システム監査基準」の「・．報告基準」を参照，確認するとよい。
6.8.3.2： システム監査人は，自らの評価基準（判断基準）を明確にして，IT ガバナンスの実現のため，情報システム全体にわたる信頼性，安全性，効率性などの評価を記載する。
指摘事項は何が問題であるか，理由を明確にするとともに，指摘事項の中から，改善を要する事項を，改善事項としてまとめ，通常改善又は緊急改善に分けて改善勧告を行う。
改善勧告については，可能な範囲で，システム監査人の改善案を示すことが望ましい。
6.8.3.3： システム監査人は報告会を通じて，関係者に改善勧告の内容，重要性，緊急性等について理解を求め，改善の実現を図る。
| 41
7.プロセスビュー
7.：プロセスビューについて，第4部1.7「プロセスビュー（7.）」に概説している。