oss ライセンス遵守活動の ソフトウェアライフサイクルプロ …12207...
TRANSCRIPT
OSS ライセンス遵守活動の
ソフトウェアライフサイクルプロセスへの組込み
2013 年 3 月
はしがき
2010 年 4 月に独立行政法人情報処理推進機構（IPA）が発表した「第 3回オープンソー
スソフトウェア活用ビジネス実態調査（2009 年度調査）」では、今後利用するという回答
が多かった「OSS 利用の新たな拡大領域」として、クラウド、携帯電話、データベースク
ラスタ、CMS（コンテンツ管理システム）が挙げられていた。事実、携帯電話やデジタル
テレビを皮切りに、今日、国内にも多くの利用者を有する Google、Facebook、Twitter、
Amazon、モバゲーTOWN、クックパッドなどのクラウド型のインターネットサービスを
構成するプラットフォームや、iPhone・iPad、Androidのようなモバイル機器に搭載され
ている OS やミドルウェア等にも、オープンソースソフトウェア（OSS）は深く関係してお
り、今後の IT の趨勢においても大きな影響を及ぼす存在となっている。
他方、OSS 普及の阻害要因についての調査では、「サポートに対する不安」、「ライセンス
に対する懸念」、「人材および経験の不足」が挙げられていた。リスクも考慮した上で革新的
なサービスを提供し差別化を図る新進企業がある一方で、特に国内の企業情報システムや製
品・サービスが、まだまだレガシーな技術をベースに提供されている実情を鑑みると、残念
ながらこちらは十分に解消されたとは言い難い。
OSSは、GPL、BSDライセンスなど、種々のライセンス類型があり、複製、改変、配布
といった著作権法上の権利はもちろんのこと、配布に伴うソースコードの提供など、ライセ
ンス個々に異なる条件が存在する。そこで、本ワーキンググループでは、2009 年 4 月に
「GNU GPLv3（General Public License第 3版）逐条解説書」、翌年 2010 年 5 月に「OSS
ライセンスの⽐較、利用動向および係争に関する調査」を公開、特に上述の「ライセンスに
対する懸念」に対する負担の逓減に努めてきた。そして、今回、本書では、システムや製品・
サービスを開発する上でOSS を利用する際、実際にどのようにライセンス義務を履行すれ
ばよいのかという本質的な課題に正面から取り組み、具体的な開発プロセスを踏まえた
OSS ライセンスに対する遵守活動を示した。 本書が、多くの企業の技術者そして法務担当者に対して、OSS を利用したシステムある
いは製品・サービスを開発する際の参考となることを期待するとともに、グローバル化時代
をリードする製品・サービスの実現に寄与するコア・リソースの一つとして OSSのさらな
る普及発展の一助になれば幸甚である。
2013 年春 独立行政法人情報処理推進機構（IPA）
技術本部国際標準推進センター リーガルワーキンググループ
目 次
1. はじめに .............................................................................................................................3
2. OSS 利用プロセスと「共通フレーム 2007」 ..................................................................4
2.1. ソフトウェアライフサイクルプロセス標準の関連について ......................................4
2.2. IEEE 1517-1999 の概略 ............................................................................................5
3. 共通フレーム 2007 に組み込んだ OSS ライセンス遵守活動の実際 ...............................6
3.1. プロセスの対象範囲および本章の構成と利用の流れ .................................................6
3.2. 供給者／取得者関係の入れ子構造 ...............................................................................8
3.3. OSS の upstream/downstream と開発委託の関係 ...............................................10
3.4. OSS ライセンス遵守活動（共通フレーム 2007 版）リファレンス ........................12
3.5. OSS ライセンス遵守活動（共通フレーム 2007 版）本文 .......................................19
4. 参考文献 ...........................................................................................................................27
付録. IEEE 1517-1999 におけるプロセスの変更状況 .......................................................28
IPA技術本部国際標準推進センター リーガルワーキンググループ ...................................33
3
1. はじめに
本ワーキンググループ（WG） では、GPLv3 の日本語による逐条解説、各種オープンソー
スソフトウェア (OSS) ライセンスの調査報告をまとめた後、具体的に開発プロセスの中に
OSS ライセンスの義務履行に対する遵守活動をどう組み込むかについての議論を始めた。
この活動において問題となったのが、議論に参加した委員の所属会社間でも開発プロセスに
相違があり、遵守活動を組み込む対象を組織によらない形で記述することが難しいというこ
とだった。
この議論の過程で、すでに国際標準化の世界では、ソフトウェアライフサイクルプロセスの
概念を標準化するという動きがあり (ISO/IEC 12207 としてその成果はまとめられてい
る)、 この標準によって定義された用語 (一部の委員からは、個別の用語に関して実務で使
用する用語との乖離に関する指摘 1もあったが) を使うことで、組織から独立した記述が可
能ではないかという提言がなされた。
そこで、OSS ライセンス遵守活動を開発プロセスへの組み込むための資料をまとめる前に、
ISO/IEC 12207 をもとにどの部分が OSS ライセンス遵守活動において影響を受けるか
についての洗い出しを行い、各委員で分担してまとめることとした。ただし、この洗い出し
は ISO/IEC 12207 (もしくはその日本語版である JIS X0160) を直接使うのではなく、
ISO/IEC 12207 の中で規定されている tailoring の手法で作成された「共通フレーム 2007 (SLCP-JCF 2007)」に対して行うこととした。
具体的な作業としては、まず「共通フレーム 2007 (第２版)」の各プロセスに対して委員が
分担して OSS ライセンス遵守活動の観点から必要となる作業を洗い出し、場合によって
はもとの記述が OSS を利用する場合に妥当でないところを修正し、作業定義ごとの改変
案を作った。これをもとにワーキンググループの定期会合で各委員により、その改変案のレ
ビューを行なった。改変の対象は定義体 (標準の考え方では normative な部分) に対する
ものであることもあれば、ガイダンス (標準の考え方では informative な部分) に対する
ものもある。もとの記述に対する追加でなく新規な記述になる場合、それを定義体に追加す
るのか、ガイダンスに追加するのかは、その記述が normative か informative かを基準
とした。この成果が、本書の 3.5 節に示す「OSS ライセンス遵守活動 (共通フレーム 2007
版)」である。
この作業の後、本書の 3.4 節に示す、各項の定義体/ガイダンスへの変更の有無を記載した
「OSS ライセンス遵守活動（共通フレーム 2007 版）」リファレンスを作成した。共通フ
レーム 2007 (もしくはそのもととなった ISO/IEC 12207) をすでに利用している読者に
とっては、同リファレンスを確認することで OSS 遵守活動がソフトウェア開発プロセス
のどのステージに影響を与えるかを理解することができるだろう。
1たとえば、「取得」プロセスは一般的な言い方なら「調達」プロセスではないか、など。
4
なお、本活動と類似のものとして IEEE で進められている Reuse Process の ISO/IEC
12207 に対する組込み (その成果は IEEE 1517 -- Software Life Cycle Process - Reuse
Process) があり、本活動は作業定義の改変案の記述法などについて上記活動の成果も参考
にした。
2. OSS 利用プロセスと「共通フレーム 2007」
2.1. ソフトウェアライフサイクルプロセス標準の関連について
前節にも述べたように、ソフトウエアライフサイクルプロセス (SLCP) に関しては、その
国際標準である ISO/IEC 12207 を中心に、さまざまな標準や文書 (以下ではこれらをま
とめて「標準等」という) が存在する。この節では、本書に関連するそうした標準等の関係
について概説する。
図 1 : 本書と既存の標準等との関係 図 1 で ISO/IEC 12207 が元々の国際標準であり、その左にある JIS X0160 がそれの
JIS 版という位置づけで、右にある IEEE 1517 は ISO/IEC 12207 に定義された方法
(tailoring) でソフトウェアの再利用に注目をしたものとなる。
ISO/IEC 12207 自体は過去に二度の追補の発行 (2002 年、2004 年) および一度の改訂
がなされており、以前の文書が ISO/IEC 12207:1995、そして改訂された文書が ISO/IEC
12207:20082 となる。IEEE 1517-1999 で着目した、ソフトウェアの再利用に関する記
2 なお、ISO/IEC 12207:2008 はすでに JIS X0160:2012 として日本標準化されている
ISO/IEC 12207:1995
二つの追補
ISO/IEC 12207:2008
JIS X0160:1996
JIS X0160:2007
IEEE 1517-2010
IEEE 1517-1999
共通フレーム 2007
共通フレーム 98
5
述は その一部が ISO/IEC 12207 の 2002 年版の追補 (の付録 G) を経てISO/IEC
12207:2008 に取り入れられている。
IEEE 1517-1999 は ISO/IEC 12207:19953 に対して、そしてIEEE 1517-2010 は
ISO/IEC 12207:2008 に対して、再利用の観点から必要となる手続きを埋め込んだ標準で
IEEE 1517-1999 に関しては、上で述べたようにISO/IEC 標準の改訂にあたって相当部
分が取り入れられた。詳細に関しては、次節で述べる。しかしながら、IEEE 1517 を源流
とする現在の再利用プロセスはあくまで、その機能面に着目したものであり、第三者権利物
に特有である再利用の権利の許諾 (OSS においては、一般に再利用の可能性を極力広く認
めようとするのが一般的だが、再々利用の可能性を認めない使用法に対して再利用を禁じる
という形での制限、これを copyleft もしくは reciprocity と言う、が加えられる事も多い)
が対象となる開発アウトプットに妥当であるかを確認するなどの行為に対する言及はほと
んどない。
「共通フレーム 98」 や「共通フレーム 2007」 はそれぞれ対応する JIS をもとに「各
部門の作業」という観点からの tailoring を行ったものであり、またその結果として「超上
流」の重要性にも着目したものと言える。「共通フレーム 2007」 は JIS X0160:2007 (こ
の文書は ISO/IEC 12207 の追補の翻訳なので、JIS X0160:1996 も参照して) をもとに
tailoring されているので、結果的に IEEE 1517-1999 に源を持つ「再利用の観点」も含
まれている。(図 1 の赤の矢印は「再利用の観点」の系譜を示す)
そこで、本書では、OSS のライセンス管理という観点から 「共通フレーム 2007」をも
とに、tailoring を行なうことで、OSS を導入する開発プロセスにおいて、ライセンス管理
などが不適切であることによる、OSS に対する著作権侵害を未然に防止することを意図し
た。
2.2. IEEE 1517-1999 の概略
「再利用」に注目するという点からは、権利関係に関する言及があまりなされていないとい
う問題があるとはいえ、本書と IEEE 1517 は関連が深いので、IEEE 1517 の概略を以下
が、本書の作成中にはそれに対応する「共通フレーム」は発行されておらず、本書が「共通
フレーム 2007 への tailoring」という位置付けを持つので、図1では JIS X0160:2012 を
省略した。JIS X0160:2012 に対応する「共通フレーム」は 2013/3/4 に「共通フレーム
2013」として、発行された。 3 正しくは、それぞれ IEEE 12207.0-1996 および IEEE 12207-2008 に対して、再利用
プロセスを埋め込んだものであるが、これら二つの IEEE 標準は対応する ISO/IEC 標準
と同一なので (IEEE 12207-2008 に至っては、ISO, IEC と並んで IEEE も発行者に名
前を連ねる triple logo の標準になっている) ここでは説明を簡潔にするために、ISO/IEC
標準名を使用する。
6
に述べる。
本標準は IEEE 12207.0-1996 (以下この節では「元文書」と呼ぶ) に対して「再利用」の
観点から tailoring を行ったもので、文書の構成としては元文書に規定されたプロセスのう
ちで再利用の観点から、アクティビティもしくはタスクを追加しなければいけないものを取
り出し、それらのプロセスに関して追加点を記載した部分 (5章) とプロセス自身が追加さ
れた部分 (6, 7, 8 章) からなる。
アクティビティもしくはタスクが追加されたプロセスは
Acquisition Process (取得プロセス)
Supply Process (供給プロセス)
Development Process (開発プロセス)
Operation Process (運用プロセス)
Maintenance Process (保守プロセス)
の五つであり、プロセス自身が追加されたものとしては
Asset Management Process (資産管理プロセス, supporting process として追加)
Reuse Program Administration Process (再利用施策管理プロセス, organizational
life cycle process として追加)
Domain Engineering Process (ドメイン技術プロセス, cross-project process と
して追加)
の三つがある。これらのうち、後者 (プロセス自身が追加された部分) に関しては、元文書
の改訂に伴い大部分が取り入れられている。
なお、各プロセスに対してどういう追加/変更が行われたかに関しては巻末の付録に記載し
たので、参考にされたい。
3. 共通フレーム2007 に組み込んだOSS ライセンス遵守活動の実際
3.1. プロセスの対象範囲および本章の構成と利用の流れ
（１）プロセスの対象範囲
今回、共通フレーム 2007 に OSS ライセンス遵守活動を組み込む対象となったプロセス
（黄色部分）を以下に示す。
7
ここでは、組込み先として、共通フレーム 2007 のプロセスのうち、「主ライフサイクルプ
ロセス」のみを対象としている。
その理由は、次の 2点である。
（ａ）共通フレーム 2007 の中心である主ライフサイクルを対象とすることにより、OSS
利用における考慮点は、ほぼカバーされる。
（ｂ）主ライフサイクルプロセス以外の、「支援ライフサイクルプロセス」「組織に関するラ
イフサイクルプロセス」「システム監査プロセス」「修整プロセス」については、共通フレー
ムの次期バージョンで大幅な変更が予定されていたため、「主ライフサイクルプロセス」に
フォーカスした。
（２）本章の構成と利用の流れ
本章の構成として、3.2 節に供給者／取得者関係の入れ子構造、3.3 節に OSS の
upstream/downstream と開発委託の関係、3.4 節に共通フレーム 2007 に対して OSS ラ
イセンス遵守活動を組み込むに当たって変更が必要な記述を含むプロセス・アクティビテ
図 2: 共通フレーム 2007（第 2版）「共通フレームの基本構成」を参考に作成
8
ィ・タスクをリファレンスとして示し、その遵守活動自体の内容については、本文として
3.5 節に示す。
本章の想定読者は、共通フレーム 2007 に基づいて OSSを利用する供給者または取得者で
あり、本章の利用のタイミングとしては、ソフトウェアまたはシステムを供給または取得す
る場合に、OSSを利用することを決めた際に使うことができる。
本章の利用の流れは、次を想定している。
（ａ）立場の確認
「OSS ライセンス遵守活動（共通フレーム 2007 版）」を読むに当たり、供給者／取得者
の立場によって、読み方が変わるため、自分の立場がどちらかを確認する。この際、取得者
と供給者の両方の立場になることがあるため、供給者／取得者関係の入れ子構造に留意する
必要がある。詳細は、3.2 節および 3.3節を参照のこと。
（ｂ）該当するプロセス、アクティビティ、タスクの確認
リファレンス (3.4 節) で OSS を利用する際に共通フレーム 2007 で該当するプロセス、
アクティビティ、タスクを確認する。
（ｃ）具体的な変更部分の確認
上記（ｂ）で確認した該当するプロセス、アクティビティ、タスクに対し、本文 (3.5 節) で、
遵守活動として具体的な変更部分（定義体および／またはガイダンス）を確認する。
3.2. 供給者／取得者関係の入れ子構造
ISO/IEC 12207 系の標準と⽐較した場合に、本書の取り扱う事象の特徴として、明示的に
供給者／取得者関係の入れ子構造が導入されていることがあげられる。そこで、各作業定義
の説明に入る前に、供給者／取得者関係の入れ子構造に起因する本書の特徴に関して説明す
る。
あるソフトウェアシステムの構築を請け負った者 (この意味ではソフトウェアシステムの
発注者に対して「供給者」の立場にある) が、(その発注者との合意の上で) そのソフトウ
ェアシステムの一部に OSS を導入する場合 (この意味では OSS の供給者、一般に言うと
ころの OSS プロジェクト、に対して「取得者」の立場にある) 、システムの供給者とシス
テムの取得者という供給者／取得者関係の他に、(システムの供給者でもある) OSS の取得
者が OSS の供給者との間に供給者／取得者関係を築くというのが入れ子構造の典型的な
例となる。この場合、図 3 に示すように、システムの供給者／取得者の双方は両者の合意
9
事項の遵守義務があるのと同時に、OSS ライセンスの遵守義務も生じることになる。特に、
システムの取得者に OSS ライセンスの遵守義務がある事は忘れられがちなので強調して
おく。
なお、図 3 では OSS ライセンスに記載された「義務」について単純化のために使用形態
による差がないものとして書いているが、多くの OSS ライセンスでは、配布を伴う場合
と伴わない場合 (つまり、単なる使用の場合) で遵守すべき義務が異なることに注意を要す
る。
図 3: 供給者／取得者の入れ子構造の例
もちろん、元来の ISO/IEC 12207 においても「外部委託先」という形で、こうした入れ
子構造が存在することに対する言及はあるが、その場合と本書が取り扱う事象に相違が生じ
る。
元来の ISO/IEC 12207 では、供給者が外部委託先に委託し、それを取得者に供給する場
合には、一旦供給者がその対象となるソフトウェアシステム全体の知的財産権を取得 (もし
くは最低限、目的に合致する使用許諾を取得) した上で、取得者にその当該知的財産権を譲
渡するというケースを前提にしていると考えられる。少なくとも、現在の ISO/IEC 12207
では、供給という行為に当たって外部委託先に原始的な知的財産権が存在する部分に関する
権利処理を行う、という作業定義が存在しない。
これに対して、供給者がOSS を利用したソフトウェアシステムを供給する場合には、一般
に言って OSS プロジェクトから知的財産権を (排他的に) 取得することは考えられず、取
得者に当該ソフトウェアシステムを供給するにあたっても、本来の供給者／取得者間の合意
の遵守に加えて、供給者には OSS プロジェクトによって課せられたライセンスの遵守義
務が継続して発生することとなる。
OSS の取得者 ∥
システムの供給者
OSS の供給者
システムの取得者
OSS ライセンス遵守の義務
OSS ライセンス遵守の義務 二者間の合意の遵守義務
10
また、上記「本来の供給者／取得者間の合意」は、この二者間で考えれば、契約自由の原則
から、その内容を自由に設定できるように考え勝ちであるが、取得者が「OSS ライセンス
遵守の義務」を有することから、二者間で可能な合意にも制約が生じることとなる。図 4
では、代表的な OSS ライセンスの一つである GPL を例に取って、システムの供給者／
取得者間の合意に追加的制約条項を導入できない (追加的制約条項の禁止は、GPL の規定
に由来する) 根拠を示す。
図 4: 二者間の合意に影響を及ぼす例 (GPL における、追加的制約の禁止)
本書では、こうした供給者／取得者の入れ子構造 (そして、それに伴う合意の外延性) に留
意し、ISO/IEC 12207 の記述の修正案を作成した。修正案中では、特にどの階層の供給者
／取得者の関係について述べたものであるかを明記していない部分が多いが、それは文脈か
ら判断いただきたい。
3.3. OSS の upstream/downstream と開発委託の関係
前節では、OSS の供給者から、システムの取得者へと直線的にライセンス関係が成立する
場合について述べた。実務上では、前節のような直線の関係になることは稀で、複数の供給
先からのソフトウェアをもとにシステムが構築されることが非常に多い。
もちろん、OSS だけに話を限っても、複数のプロジェクトから異なるライセンスで OSS を
入手して、それらをもとにシステムを構築する 4というのは一般的な話だが、OSS と外部
委託先の双方から入手したソフトウェアをもとにシステムを構築しそれを供給する場合に
4 この場合に、「ライセンスの矛盾」と言われる関係が生じる事がある。
OSS の取得者 ∥
システムの供給者
OSS の供給者
システムの取得者
OSS ライセンス遵守の義務 (追加的制約禁止付き)
OSS ライセンス遵守の義務 二者間の合意の遵守義務 (追加的制約条項は含むことができない)
11
は、より一層の注意が必要となることがある。
つまり、日本の一部の企業においては、「契約条件を交渉可能な相手」との契約行為を担当
する部署と、「すでにある約款の条項を遵守する」活動をする部署が異なることがあるとい
う現状から生じる注意点である。
一般には、OSS ライセンスは約款類似の契約と考えられ、個別の供給／取得関係で別種の
契約交渉を行うことはない 5。つまり、前に述べた「条項の遵守」には該当するが、「交渉
可能な相手」とはみなされない結果、契約交渉担当部門が OSS ライセンスで保護される
ソフトウェアの使用に関心を持たず、システムの供給者の立場としてみると全体として矛盾
するライセンスでシステムの取得者に供給してしまうというリスクが発生するということ
である。
以下の図 5 にあるように、契約交渉可能の領域から入手したものと、それ以外の領域から
入手したものは、最終的に統一した目で条項の矛盾がないかをチェックしたのちに供給する
必要があるといえる。
図 5 : OSS の供給取得と外部委託先の関係
5 勿論、多数の OSS プロジェクト (この文脈で言えば OSS の供給者) は、「別途契約の可能性」を表明しており、実作業上そうした別途契約を利用して商用ソフトウェアにおける
ライセンス障害を取り除くという事も行われてきた。
OSS の供給者
外部委託先
OSS の第二取得者
システムの供給者
契約交渉可
能の領域
12
3.4. OSS ライセンス遵守活動（共通フレーム 2007 版）リファレンス
リファレンスは OSS利用に当たり、共通フレーム 2007 の主ライフサイクルプロセスにお
いて、変更したプロセス・アクティビティ・タスクの一覧を以下の表で示している。
リファレンスにより、変更部分が定義体なのかガイダンスなのか、全体が俯瞰できる。
「OSS ライセンス遵守活動（共通フレーム 2007 版）」リファレンス 項番 共通フレーム 2007 定義体 ガイダンス
1. 主ライフサイクルプロセス 1.1 取得プロセス 1.1.1 開始 1.1.1.1 概念又はニーズの記述 ○ 1.1.1.2 システム要件の定義と分析 1.1.1.3 システム要件定義の依頼と結果の承認 1.1.1.4 ソフトウェア要件の定義と分析 1.1.1.5 企画プロセス，要件定義プロセス，開発プロセスの使用 ○ 1.1.1.6 選択肢の検討 ○ 1.1.1.7 取得条件の確認 ○ ○ 1.1.1.8 取得計画の作成と実行 ○ 1.1.1.9 受入れ方針及び条件の定義 ○ ○ 1.1.2 提案依頼書の準備 1.1.2.1 要求事項の文書化 ○ 1.1.2.2 対象プロセスの決定と修整 1.1.2.3 共同レビュー及び監査実施時期の定義 1.1.2.4 要求事項の提示 1.1.3 契約準備及び更新 1.1.3.1 供給者選択手順の確立 1.1.3.2 供給者の選択 1.1.3.3 修整への他者の参加 1.1.3.4 供給者との契約準備及び交渉 ○ ○ 1.1.3.5 責任分担の決定 ○ 1.1.3.6 供給者との契約締結 1.1.3.7 契約変更の管理 ○ 1.1.4 供給者の管理 1.1.4.1 共同レビューと監査による監視 ○ 1.1.4.2 供給者への協力 1.1.5 受入れ及び完了 1.1.5.1 受入れの準備 1.1.5.2 受入れ ○ ○ 1.1.5.3 受入れの終了 1.1.5.4 受入れ後の構成管理 ○ 1.2 供給プロセス 1.2.1 開始 1.2.1.1 提案依頼書の要求レビュー 〇 1.2.1.2 入札又は契約受入れの決定 1.2.2 提案書の準備 1.2.2.1 提案書の用意 〇
13
項番 共通フレーム 2007 定義体 ガイダンス 1.2.3 契約締結 1.2.3.1 契約内容の文書化 1.2.3.2 責任分担の決定 〇 1.2.3.3 交渉と契約締結 ○ 1.2.3.4 契約変更の要求 ○ 1.2.4 計画立案 1.2.4.1 取得要求事項のレビュー ○ 1.2.4.2 ライフサイクルモデルの選択 1.2.4.3 計画に対する要求事項の確定 ○ 1.2.4.4 供給方法の選択肢の検討 ○ 1.2.4.5 プロジェクト管理計画の立案 ○ 〇 1.2.5 実行及び管理 1.2.5.1 プロジェクト管理計画の具体化と実行 1.2.5.2 プロセスの実行 ○ 1.2.5.3 進捗及び品質の管理 ○ 1.2.5.4 外部委託先の管理 ○ 〇 1.2.5.5 検証，妥当性確認又はテストの代行者との協調 1.2.5.6 他の関係者との協調 1.2.6 レビュー及び評価 1.2.6.1 取得者との調整 1.2.6.2 取得者への支援 1.2.6.3 検証及び妥当性確認の実施 ○ 〇 1.2.6.4 取得者への報告の準備 1.2.6.5 取得者の設備視察の容認 ○ 1.2.6.6 品質保証活動の実施 1.2.7 納入及び完了 1.2.7.1 納入 ○ 1.2.7.2 取得者への支援 ○ 〇 1.3 契約の変更管理プロセス 1.3.1 プロセス開始の準備 1.3.1.1 契約の変更管理にかかわる協議の場の設置 1.3.1.2 契約の変更管理手続きの制定 1.3.2 契約の変更要求 1.3.2.1 契約の変更要求の文書化と提示 ○ 1.3.3 影響の調査分析 1.3.3.1 影響の調査分析の根拠 ○ 1.3.4 協議の実施と合意の形成 1.3.4.1 協議の実施 1.3.4.2 承認レベルのエスカレーションと合意の形成 1.3.5 契約の変更 1.3.5.1 契約の変更 1.3.5.2 基準線の変更 1.3.5.3 関係者への周知徹底 1.4 企画プロセス 1.4.1 プロセス開始の準備 1.4.1.1 企画作業の組立て 1.4.1.2 必要な支援プロセスの組込み 1.4.1.3 企画環境の準備 ○
14
項番 共通フレーム 2007 定義体 ガイダンス 1.4.1.4 企画プロセスの実施計画の作成 1.4.2 システム化構想の立案 1.4.2.1 経営上のニーズ，課題の確認 1.4.2.2 事業環境，業務環境の調査分析 ○ 1.4.2.3 現行業務，システムの調査分析 1.4.2.4 情報技術動向の調査分析 ○ 1.4.2.5 対象となる業務の明確化 1.4.2.6 業務の新全体像の作成 1.4.2.7 対象の選定と投資目標の策定 ○ 1.4.2.8 システム化構想の文書化と承認 1.4.2.9 システム化推進体制の確立 1.4.3 システム化計画の立案 1.4.3.1 システム化計画の基本要件の確認 1.4.3.2 対象業務の内容の確認 1.4.3.3 対象業務のシステム課題の定義 1.4.3.4 対象システムの分析 1.4.3.5 適用情報技術の調査 1.4.3.6 業務モデルの作成 1.4.3.7 システム化機能の整理とシステム方式の策定 1.4.3.8 システム化に必要な付帯機能，付帯設備に対する基本方針の明確化 ○ 1.4.3.9 サービスレベルと品質に対する基本方針の明確化 1.4.3.10 プロジェクトの目標設定 1.4.3.11 実現可能性の検討 1.4.3.12 全体開発スケジュールの作成 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.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 組織及び業務環境要件の具体化 1.5.2.4 機能要件の定義 1.5.2.5 非機能要件の定義 1.5.2.6 スケジュールに関する要件の定義 1.5.2.7 実現可能性とリスクの検討 1.5.3 利害関係者要件の確認 1.5.3.1 要件の合意と承認
15
項番 共通フレーム 2007 定義体 ガイダンス 1.5.3.2 要件変更ルールの決定 1.6 開発プロセス 1.6.1 プロセス開始の準備 ○ 1.6.1.1 開発作業の組立て 1.6.1.2 必要な支援プロセスの組込み ○ 1.6.1.3 開発環境の準備 1.6.1.4 開発プロセス実施計画の作成 1.6.1.5 非納入品目の使用の容認 1.6.2 システム要件定義 1.6.2.1 システム要件の定義 ○ 1.6.2.2 システム要件の評価 ○ 1.6.2.3 システム要件の共同レビューの実施 1.6.3 システム方式設計 1.6.3.1 システムの最上位レベルでの方式確立 1.6.3.2 利用者文書（暫定版）の作成 1.6.3.3 システム結合のためのテスト要求事項の定義 1.6.3.4 システム方式の評価 ○ 1.6.3.5 システム方式設計の共同レビューの実施 1.6.4 ソフトウェア要件定義 1.6.4.1 ソフトウェア要件の確立 〇 1.6.4.2 ソフトウェア要件の評価 ○ 1.6.4.3 ソフトウェア要件の共同レビューの実施 1.6.5 ソフトウェア方式設計 1.6.5.1 ソフトウェア構造とコンポーネントの方式設計 ○ 1.6.5.2 外部，コンポーネント間の各インタフェースの方式設計 1.6.5.3 データベースの最上位レベルの設計 1.6.5.4 利用者文書（暫定版）の作成 1.6.5.5 ソフトウェア結合のためのテスト要求事項の定義 1.6.5.6 ソフトウェア方式設計の評価 ○ 1.6.5.7 ソフトウェア方式設計の共同レビューの実施 1.6.6 ソフトウェア詳細設計 1.6.6.1 ソフトウェアコンポーネントの詳細設計 〇 1.6.6.2 ソフトウェアインタフェースの詳細設計 1.6.6.3 データベースの詳細設計 1.6.6.4 利用者文書の更新 1.6.6.5 ソフトウェアユニットのテスト要求事項の定義 1.6.6.6 ソフトウェア結合のテスト要求事項の更新 1.6.6.7 ソフトウェア詳細設計及びテスト要求事項の評価 ○ 1.6.6.8 ソフトウェア詳細設計の共同レビューの実施 1.6.7 ソフトウェアコード作成及びテスト 1.6.7.1 ソフトウェアユニットとデータベースの作成及びテスト手順とテスト
データの作成 〇
1.6.7.2 ソフトウェアユニットとデータベースのテストの実施 1.6.7.3 利用者文書の更新 1.6.7.4 ソフトウェア結合テスト要求事項の更新 1.6.7.5 ソフトウェアコード及びテスト結果の評価 ○ 1.6.8 ソフトウェア結合 1.6.8.1 ソフトウェア結合計画の作成
16
項番 共通フレーム 2007 定義体 ガイダンス 1.6.8.2 ソフトウェア結合テストの実施 1.6.8.3 利用者文書の更新 1.6.8.4 ソフトウェア適格性確認テストの準備 1.6.8.5 ソフトウェア結合テストの評価 1.6.8.6 ソフトウェア要件の共同レビュー実施 1.6.9 ソフトウェア適格性確認テスト 1.6.9.1 ソフトウェア適格性確認テストの実施 1.6.9.2 利用者文書の更新 1.6.9.3 ソフトウェア適格性確認テストの評価 ○ 1.6.9.4 ソフトウェア適格性確認テストの共同レビューの実施 1.6.9.5 監査の支援 1.6.9.6 納入ソフトウェア製品の準備 〇 1.6.10 システム結合 1.6.10.1 システム結合計画の作成 1.6.10.2 システム結合テストの実施 1.6.10.3 利用者文書の更新 1.6.10.4 システム適格性確認テストの準備 1.6.10.5 システム結合テストの評価 1.6.10.6 システム結合の共同レビュー実施 1.6.11 システム適格性確認テスト 1.6.11.1 システム適格性確認テストの実施 1.6.11.2 システムの評価 〇 1.6.11.3 システム適格性確認テストの共同レビューの実施 1.6.11.4 利用者文書の更新 1.6.11.5 監査の支援 1.6.11.6 各納入ソフトウェア製品の準備 〇 1.6.11.7 運用，保守に引き継ぐソフトウェア製品の準備 〇 1.6.12 ソフトウェア導入 1.6.12.1 ソフトウェア導入計画の作成 〇 1.6.12.2 ソフトウェア導入の実施 ○ 1.6.13 ソフトウェア受入れ支援 1.6.13.1 取得者の受入れレビューと受入れテストの支援 ○ 1.6.13.2 ソフトウェア製品の納入 〇 1.6.13.3 取得者への教育訓練及び支援 1.7 運用プロセス 1.7.1 プロセス開始の準備 1.7.1.1 運用プロセス実施計画の作成 1.7.1.2 運用のための資産の引き継ぎ ○ 1.7.1.3 問題管理手続きの確立 1.7.1.4 システム運用に係る事前調整 ○ 1.7.1.5 システム運用に係る作業手順の確立 1.7.1.6 システム運用評価基準の設定 1.7.1.7 業務運用に係る事前調整 1.7.1.8 業務運用に係る作業手順の確立 1.7.1.9 業務運用評価基準の設定 1.7.1.10 運用テスト計画の作成 1.7.1.11 プロセス開始のためのレビュー実施 1.7.2 運用テスト
17
項番 共通フレーム 2007 定義体 ガイダンス 1.7.2.1 運用テストの準備 1.7.2.2 運用テストの実施 1.7.2.3 運用テスト結果の確認 1.7.2.4 システム運用の訓練 1.7.3 業務及びシステムの移行 1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵
守
1.7.3.2 移行計画の文書化と検証 1.7.3.3 関係者全員への移行計画等の通知 1.7.3.4 新旧環境の並行運用と旧環境の停止 1.7.3.5 関係者全員への移行の通知 1.7.3.6 移行評価のためのレビュー 1.7.3.7 旧環境関連データの保持と安全性確保 1.7.4 システム運用 1.7.4.1 システムの運用 1.7.4.2 運用監視及び運用データの収集 1.7.4.3 問題の識別，記録及び解決 1.7.4.4 運用環境の改善 1.7.5 利用者教育 ○ 1.7.5.1 システム利用教育環境の構築 1.7.5.2 利用者への周知 1.7.5.3 利用者の教育 1.7.6 業務運用と利用者支援 1.7.6.1 業務の運用 1.7.6.2 利用者の支援 ○ 1.7.6.3 保守プロセスへの引き継ぎ 1.7.6.4 回避策の提供 1.7.7 システム運用の評価 1.7.7.1 システム運用の評価 1.7.8 業務運用の評価 1.7.8.1 業務運用の評価 1.7.9 投資効果及び業務効果の評価 1.7.9.1 投資効果及び業務効果の評価 1.8 保守プロセス 1.8.1 プロセス開始の準備 1.8.1.1 開発プロセスからの引き継ぎ ○ 1.8.1.2 計画及び手続きの作成 1.8.1.3 問題管理手続きの確立 1.8.1.4 修正作業の管理 1.8.1.5 保守のための文書作成 1.8.2 問題把握及び修正分析 1.8.2.1 問題報告又は修正依頼の分析 1.8.2.2 問題の再現又は検証 1.8.2.3 修正実施の選択肢の用意 1.8.2.4 文書化 1.8.2.5 修正案の承認 1.8.3 修正の実施 1.8.3.1 分析と修正部分の決定
18
項番 共通フレーム 2007 定義体 ガイダンス 1.8.3.2 修正の実施 1.8.3.3 購入パッケージの修正実施 ○ 1.8.4 保守レビュー及び受入れ 1.8.4.1 修正システムのレビュー 1.8.4.2 完了の承認 1.8.4.3 保守のための文書の更新 1.8.5 移行 1.8.5.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵
守
1.8.5.2 移行計画の文書化と検証 1.8.5.3 移行計画等の利用者への通知 1.8.5.4 新旧環境の並行運用と旧環境の停止 1.8.5.5 関係者全員への移行の通知 1.8.5.6 移行評価のためのレビュー 1.8.5.7 旧環境関連データの保持と安全性確保 1.8.6 システム又はソフトウェア廃棄 1.8.6.1 廃棄計画の立案 1.8.6.2 廃棄計画等の利用者への通知 1.8.6.3 新旧ソフトウェア製品の並行運用と利用者の教育訓練 1.8.6.4 関係者全員への廃棄の通知 1.8.6.5 廃棄関連データの保持と安全性確保
19
3.5. OSS ライセンス遵守活動（共通フレーム 2007 版）本文
「OSS ライセンス遵守活動（共通フレーム 2007 版）」本文では OSS 利用に当たって共通
フレーム 2007 に対し変更した部分を示している。なお本文も、リファレンス同様可読性向
上のため表形式で示している。
本文の見方
・「共通フレーム 2007」の列には、OSS 利用に当たって変更した項目のみを記載している。
・「JIS X0160」の列には、対応する項目がある場合に、その項目番号を記載している。
・「OSS 利用により影響を受ける変更部分」の列については、【ガイダンス】の記載が無い
場合、および【ガイダンス】より前の部分は、定義体に対する変更部分である。
追加・変更した部分は赤字で表記している。
「OSS ライセンス遵守活動（共通フレーム 2007 版）」本文 共通フレーム 2007 JIS X
0160 OSS 利用により影響を受ける変更部分 項目番号 作業定義 項目番号
1.1 取得プロセス 1.1.1.1 概念又はニーズの記
述 取得者は、システム、ソフトウェア製品、OSS又はソフトウェアサ
ービスを取得、開発又は改善するために、概念又はニーズを記述す
ることから取得プロセスを開始する。 1.1.1.5 企画プロセス、要件定
義プロセス、開発プロ
セスの使用
1.1.1.1(概念又はニーズの記述)のタスクの実施において、経営にかかわるシステムやソフトウェア製品、OSS、サービスの取得が想定される場合は企画プロセス(1.4参照)を使用する。（以下、修正なし）
1.1.1.6 選択肢の検討 5.1.1.6 (a)要求事項を満たす既製のシステム、ソフトウェア製品又はサービスを購入、又は無償の OSSをダウンロード等により入手する。 (e)既存のシステム、ソフトウェア製品、OSS又はサービスを改善する。
1.1.1.7 取得条件の確認 5.1.1.7 取得者は、既製のシステム、ソフトウェア製品、OSS 又はサービスを取得するときには、次の条件が満足されることを確認す
る。 (a)そのシステム、ソフトウェア製品、OSS 又はサービスが要求事項を満たしている。 (e)OSS については、OSS の情報(名称、入手先、ライセンス条件等)が明確であり、ライセンス条件の遵守が可能である。 (f)その OSS の支援状況が明確である。 【ガイダンス】
OSS の採用判断に必要な情報を明確にし、ライセンス条件の遵守が可能であることを前提とする。 OSS についての利用方針（例えば、GPL の OSSを利用しない等）がある場合は、取得条件に加える。
20
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 1.1.1.8 取得計画の作成と実
行 【ガイダンス】
(h):既に認識している OSS 以外の混入の疑いがあった場合の判断、手続きを決めておく。
1.1.1.9 受け入れ方針及び条
件の定義 5.1.1.9 (a)受入れ対象品目及び受入れ範囲の定義
受入れ対象となるシステム、ソフトウェア製品、OSS 又はサービス及び受入れの範囲と手続きを明らかにする。 (b)基準の明確化 システム、ソフトウェア製品、OSS 又はサービスの受入れに対する判断基準を統一化するため、受入れの際の基準となる仕様
書、テスト項目、テストデータ及びテスト方法等の受入れの入力
及び出力基準を明らかにする。 【ガイダンス】 認識していない OSS が含まれていないか、必要に応じて OSS
検出ツールを利用してチェックする等の受入れの検査方法を明
確にする。 OSS のライセンスを遵守できているかを確認するための手順を
決めておく。 1.1.2.1 要求事項の文書化 5.1.2.1 (d)システム、ソフトウェア製品、OSS 又はサービスの一覧 1.1.3.4 供給者との契約準備
及び交渉 5.1.3.4 次に取得者は、供給者との契約の準備及び交渉を行い、納入す
るシステム、ソフトウェア製品、OSS 又はサービスの費用及び予定を含めて、取得に関する要求事項を明示する。契約では、再
利用可能な既製のシステム、ソフトウェア製品、OSS 又はサービスに帰属する、専有権、使用権、所有権、保証及びライセンス
付与権についても言及する。
【ガイダンス】 取得者がインターネットからのダウンロード等により、直接、
OSS を入手する場合、OSS の提供元が供給者となる。この場合、
取得者は、OSS に添付されたライセンス(契約)を見て利用の可否を判断するため、供給者と交渉しないことが多い。
1.1.3.5 責任分担の決定 【ガイダンス】 OSS の瑕疵や権利侵害について供給者との責任分担、責任の内容について契約に明記する。OSS のライセンスに免責や無保証が記載されていたとしても、取得者と供給者との契約では、任意の責任分
担を取り決めることが可能である。 1.1.3.7 契約変更の管理 5.1.3.5 【ガイダンス】
開発途中で OSS を採用することになった場合、あるいは予定し
ていた OSS が適切ではないことが判明し、変更する場合、変更手
順を定めておくとよい。 1.1.4.1 共同レビューと監査
による監視 5.1.4.1 【ガイダンス】
承認した以外の OSS を組み込まないよう教育と監視を行うこと
が望ましい。 1.1.5.2 受入れ 5.1.5.2 取得者は、納入システム、ソフトウェア製品、OSS 又はサー
ビスについて、受入れレビュー及び受入れテストを行い、すべて
の受け入れ条件を満足したときに供給者から納入物を受領する。
（以下、修正なし） 【ガイダンス】 1.1.1.9(受入れ方針及び条件の定義)に従い、承認した OSS 以外の
21
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 混入がないかを確認する。また、OSS のライセンス条件を遵守できていることを確認する。
1.1.5.4 受入れ後の構成管理 受入れ後、取得者は、納入されたシステム、ソフトウェア製品、OSSの構成管理(2.2 参照)責任をもつことが望ましい。
1.2 供給プロセス － 1.2.1.1 提案依頼書の要求レ
ビュー 5.2.1.1 【ガイダンス】
OSS の利用が指定されていないかチェックする。OSS が含まれていた場合は、取得者による OSS 配布の有無も考慮したうえで、供給者がライセンスを遵守可能か（実質的な知的財産権の喪
失とならないかを含む※）を確認する。さらに、OSS の瑕疵や権利侵害についての供給者の責任範囲、本稼働後の支援内容を確
認する。 ※参考資料（IPA発行） ・「GPLv3 逐条解説」 ・「OSS ライセンスの⽐較、利用動向および係争に関する調査」報
告書 1.2.2.1 提案書の用意 5.2.2.1 【ガイダンス】
取得者が指定した OSSに問題がある場合は、問題の指摘を行い、代替案を記載するとよい。 新規に OSS の提案をする場合は、OSS の情報(名称、入手先、ライセンス条件等)、役割分担（OSS 入手等）、供給者の責任範囲、支援内容等を記載するとよい。また、提案依頼書の内容と不一致があ
る場合は、その点を明記し、取得者との交渉準備をするのがよい。 1.2.3.2 責任分担の決定 【ガイダンス】
OSS に起因する瑕疵および権利侵害の責任分担、OSS 入手等の
役割分担を明記するとよい。 1.2.3.3 交渉と契約締結 供給者は、システム、ソフトウェア製品、OSS 又はサービスを提
供するために取得者組織と交渉し、契約を締結する。 1.2.3.4 契約変更の要求 5.2.3.2 【ガイダンス】
契約締結後に OSS の採用を提案する場合、OSS に関する責任範
囲、支援内容、役割分担を明記し、契約変更の申し入れを行うのが
よい。 1.2.4.1 取得要求事項のレビ
ュー 供給者は、プロジェクトの管理及び保証の枠組み、並びに納入す
るシステム、ソフトウェア製品、OSS 又はサービスの品質保証の枠組みを定義するために、取得要求事項のレビューを行う。
1.2.4.3 計画に対する要求事
項の確定 供給者は、プロジェクトを管理し、確実に運営するための計画、
及び納入するシステム、ソフトウェア製品、OSS又はサービスの品質保証計画に対する要求事項を確定する。（以下、修正なし）
1.2.4.4 供給方法の選択肢の
検討 5.2.4.4 計画のための要求事項が確定したならば、供給者は、システム、
ソフトウェア製品の開発又はソフトウェアサービス、OSSを供給するときの選択肢を、それぞれの選択肢に関連する危険分析を
考慮して検討する。 選択肢には、次のものがある。 (c)供給者の内部又は外部から、既製のシステム、ソフトウェア製品、OSS を調達する。
1.2.4.5 プロジェクト管理計
画の立案 5.2.4.5 (c)システム、ソフトウェア製品、OSS 又はソフトウェアサービ
ス、非納入品目などを含むライフサイクルプロセス及びアクティ
ビティの作業項目構成。（以下、修正なし）
22
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 (d)システム、ソフトウェア製品、OSS 又はソフトウェアサービスの品質特性の管理。品質に関する計画は別途策定してもよい。 (e)システム、ソフトウェア製品、OSS 又はソフトウェアサービスについての安全性、セキュリティ及び他の重大性に関する要求
事項の管理。安全性及びセキュリティに関する計画は別途策定し
てもよい。 【ガイダンス】 (b)エンジニアリング環境としてのライブラリやツールにOSSを利用する場合、これらを利用した結果、取得者への納品物に
OSS(の一部のプログラム)が含まれることがないかを考慮する。 (d)採用した OSSに関するバグ情報の収集、対応状況の管理を行うことが望ましい。 (e)採用した OSSに関する脆弱性の情報収集、対応状況の管理を行うことを考慮する。 (i)取得者として、OSSライセンスの遵守確認の手順、方法を定めておく。さらに、認識していない OSS 混入のチェック要否、手段を定めておくことが望ましい。 (o）要員が勝手に OSS を混入しないよう、また OSS のライセンスを遵守できるように、必要な教育の計画を立てることを考慮する。
1.2.5.2 プロセスの実行 (a)開発プロセス(1.6 参照)に従ったシステム、ソフトウェア製品、OSS 及びサービスの開発。 (b)運用プロセス(1.7 参照)に従ったシステム、ソフトウェア製品、OSS 及びサービスの運用。 (c)保守プロセス(1.8 参照)に従ったシステム、ソフトウェア製品、OSS 及びサービスの保守。
1.2.5.3 進捗及び品質の管理 供給者は、契約したライフサイクル全体にわたって、そのプロ
ジェクトのシステム、ソフトウェア製品、OSS 又はサービスの進捗及び品質を監視し、管理する。 (以下、修正なし)
1.2.5.4 外部委託先の管理 5.2.5.4 供給者は、取得プロセス（1.1参照）に従って、外部委託先を管理し、制御する。供給者は、納入するシステム、ソフトウェア
製品、OSS又はサービスが当初の契約要求事項どおりに開発又は実施されていることを確実にするために、必要なすべての契約
要件事項を外部委託先に引き渡す。 【ガイダンス】 外部委託先が OSS の採用を希望する場合の手続きを明示し、納
品物に未承認の OSS が混入しないようにする。 1.2.6.3 検証及び妥当性確認
の実施 5.2.6.3 供給者は、システム、ソフトウェア製品、OSS 又はサービス
及びプロセスが取得者のそれぞれの要求事項を十分に満足して
いることを証明するために、2.4(検証プロセス)、及び 2.5(妥当性確認プロセス)に従って検証及び妥当性確認を行う。 【ガイダンス】 OSS のライセンスが遵守できていること、未承認の OSS が混入
していないことを定められた手続きに従い確認する。 1.2.6.5 取得者の設備視察の
容認 供給者は、契約及びプロジェクト計画で指定するシステム、ソフ
トウェア製品、OSS 又はサービスのレビューのために、取得者が供給者及びその外部委託先の設備にアクセスできるようにする。
23
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 1.2.7.1 納入 供給者は、契約で定めるとおりに、システム、ソフトウェア製品、
OSS 又はサービスを納入する。 1.2.7.2 取得者への支援 5.2.7.2 供給者は、契約で定めるとおりに、取得者へ納入されたシステ
ム、ソフトウェア製品、OSS 又はサービスに関する支援を行う。 【ガイダンス】 取得者へ納入後、ライセンスが遵守できていない、あるいは未
承認 OSSの混入の疑いを指摘された場合、事実を確認し、取得者と協議のうえ、対処することを考慮する。 本稼働後に OSS の支援（修正情報や脆弱性情報の収集／対処、
問題発生時の原因調査／対処、性能改善等）を行う場合は、保守契
約に支援内容を明記する。 1.3 契約の変更管理プロ
セス －
1.3.2.1 契約の変更要求の文
書化と提示 【ガイダンス】
開発途中で OSS の変更、あるいは新規 OSS の採用を提案する場合、変更または新規採用の理由とともに、新規で OSS を提案する
際と同様の情報（1.2.2.1 参照）を提示する。 1.3.3.1 影響の調査分析の根
拠 【ガイダンス】
供給者は、取得者から OSS の指定があった場合、その条件を確認し、ライセンスを遵守可能であるかを確認する。 供給者は、OSS を採用できない理由がある場合は、その理由を取得者へ説明する。
1.4 企画プロセス － 1.4.1.3 企画環境の準備 【ガイダンス】
OSS に関する社内方針や採用基準、採用時の手続きを確認する。 1.4.2.2 事業環境、業務環境
の調査分析 【ガイダンス】
市場、他社等で広く利用されている OSS の情報を収集し、開発
コミュニティの活動状況を分析することが望ましい。 1.4.2.4 情報技術動向の調査
分析 【ガイダンス】
採用予定の OSSのライセンス情報や、開発コミュニティの活動状況、権利侵害訴訟や脆弱性の情報等を収集し、分析するとよ
い。 (IPA 参考文献) ・「OSSライセンスの⽐較、利用動向および係争に関する調査」報告書 ・組込み総合技術展 Embedded Technology 2010 「OSSライセンス－その戦略と係争の実態」
1.4.2.7 対象の選定と投資目
標の策定 【ガイダンス】
OSS の採用にあたっては、ライセンス違反のリスクや、瑕疵や権利侵害のリスク、問題発生時の対応の可否、外部委託により支援を
受ける際の費用を検討に含めるとよい。 1.4.3.8 システム化に必要な
付帯機能、付帯設備
に対する基本方針の
明確化
【ガイダンス】 OSS の採用に関する方針(採用不可とするライセンス条件等)、
採用決定までの承認手続き、要員への教育内容、方法を明確にす
る。 OSS を採用する場合、OSS と他プログラムとの連携方法、配
布の有無によるライセンスの影響等を明確にする。 OSS に起因する障害発生時に対応するための体制、方針を明確にす
24
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 る。
1.4.3.14 費用とシステム投資
効果の予測 【ガイダンス】
OSS の修正情報や脆弱性の情報の収集、対処について必要な工数を見積もり、これらの作業支援を外部委託する場合は、委託費用を
含めることが望ましい。 1.5 要件定義プロセス 1.5.1.6 要件定義プロセス実
施計画の作成 【ガイダンス】
OSS の採用に関する手続きを明確にする。 1.5.2.1 利害関係者のニーズ
の識別と制約事項の
定義
【ガイダンス】 OSS の利用方法に関し、制約事項があれば明記する。
1.6 開発プロセス － 1.6 開発プロセス 成果：
(8)最終製品に OSS が利用されている場合、当該ライセンスに遵守して導入されている。 システム監査プロセス（4.参照）に従って,開発プロセスを対象にシステム監査を実施する。 開発されたソフトウェア製品が利用する OSS のライセンスが変
更された場合，又は新たに OSS を利用する場合は，契約の変更管
理プロセス（1.3 参照）を実施する。 1.6.2.1 システム要件の定義 (h)OSS の利用がシステム要件に加わっている場合、適用対象の
定義 (k)システムやソフトウェアに OSS を利用する場合， 当該 OSS に
適用されるライセンス個々にその条件を満たす配布メカニズム（配
布物の内容や配布方法）を定義する。 1.6.2.2 システム要件の評価 (f) OSS の利用がシステム要件に加わっている場合，
当該 OSSのライセンス条件との妥当性 1.6.3.4 システム方式の評価 5.3.3.2 (f) OSS がソフトウェア品目に加わっている場合，
当該 OSSのライセンス条件との妥当性 1.6.4.1 ソフトウェア要件の
確立 5.3.4.1 【ガイダンス】
＊2）利用の可能性については，当該システムやソフトウェアに OSSが含まれる場合，当該 OSS のライセンス条件に対する妥当性も含
まれる。 1.6.4.2 ソフトウェア要
件の評価 5.3.4.2 (g) OSS がソフトウェア要件に加わっている場合，
当該 OSSのライセンス条件との妥当性 1.6.5.1 ソフトウェア構造と
コンポーネントの方
式設計
5.3.5.1 ・・・。ソフトウェア品目の方式は文書化する。 加えて、明らかにしたソフトウェアコンポーネントに OSS を利
用する場合については、著作権者、適用ライセンス名、また，，当該
OSS の入手先（Web 経由で入手することが一般的な OSS については URL)についても文書化する。
1.6.5.6 ソフトウェア方式設
計の評価 5.3.5.6 (g) 一部のソフトウェアコンポーネントに OSS を利用する場合，外
部あるいは当該 OSS とその他のソフトウェアコンポーネントとの
結合形態が，各々のソフトウェアコンポーネントのライセンス条件
に対しての妥当性 1.6.6.1 ソフトウェアコンポ
ーネントの詳細設計 5.3.6.1 【ガイダンス】
ソフトウェアコンポーネントから詳細化されたソフトウェア
ユニットについて，著作権者、適用ライセンス名、変更記録情報
等のライセンスで規定された必要不可欠の情報また，Web 経由
25
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 で入手することが一般的な OSSについては，入手元（URL)についても文書化する。 （コンポーネントとして利用した OSS がユニット単位で異なるラ
イセンスが適用されている場合があることに配慮する。） 1.6.6.7 ソフトウェア詳細設
計及びテスト要求事
項の評価
5.3.6.7 (g) 一部のソフトウェアユニットに OSS を利用する場合、当該 OSS以外のソフトウェアユニットとの結合形態が，各々のソフトウェア
ユニットのライセンス条件に対して妥当であること 1.6.7.1 ソフトウェアユニッ
トとデータベースの
作成及びテスト手順
とテストデータの作
成
5.3.7.1 【ガイダンス】 ソフトウェアユニットに OSSを利用する場合，当該 OSS のライセンス条件（例えば，著作権者名，改変履歴の表示、無保証・免責
の告知）に従ったソフトウェアコードの作成を行う。
1.6.7.5 ソフトウェアコード
及びテスト結果の評
価
5.3.7.5 (h) ソフトウェアユニットに OSSを利用されている場合，当該ソフトウェアユニットのソフトウェアコードに対する当該 OSS のライ
センス条件の妥当性 1.6.9.3 ソフトウェア適格性
確認テストの評価 5.3.9.3 (e) OSSが利用されている場合は、当該 OSS ライセンスの妥当
性 【ガイダンス】 OSS 及びこれを利用するソフトウェアの使用許諾条件が，当該
OSS ライセンス条件に遵守していることに加え，開発者の意図に対して合理性を有しているかを評価する。
1.6.9.6 納入ソフトウェア製
品の準備 5.3.9.5 【ガイダンス】
OSS が利用されている場合は，当該 OSS ライセンスの配布メカ
ニズムの定義に従って納入ソフトウェア製品を準備する。 1.6.11.2 システムの評価 5.3.11.2 【ガイダンス】
OSS が利用されている場合は，当該 OSS ライセンスの妥当性に
関する評価結果も文書に含めるものとする。 1.6.11.6 各納入ソフトウェア
製品の準備 5.3.11.4 【ガイダンス】
OSS が利用されている場合は，当該 OSS ライセンスの配布メカ
ニズムの定義に従って納入ソフトウェア製品を準備する。 1.6.11.7 運用，保守に引き継
ぐソフトウェア製品
の準備
【ガイダンス】 OSS が成果物である場合において，当該 OSSのソースコードを、バイナリコードとともに納入しない場合は，当該 OSS ライセンス
の配布メカニズムの定義に従って配布の方法も，運用，保守に引き
継ぐ成果物として準備するものとする。 1.6.12.1 ソフトウェア導入計
画の作成 【ガイダンス】
OSS については，当該 OSS のライセンス条件に従い，必要な資
源及び情報が利用できるように準備するとともに，当該資源及び情
報の入手の方法についても文書化する。 1.6.12.2 ソフトウェア導入の
実施 【ガイダンス】
ソフトウェア製品を構成する OSS に関して，ソースコードの提供が予定されている場合については，当該 OSSライセンスの配布メカニズムの定義に従って、当該 OSSのソースコードが導入先においても適切にビルドされバイナリコードが生成できる
こと、及び生成されたバイナリコードがソフトウェア製品を構成
する当該の OSSのバイナリコードと一致することを確認するものとする。 加えて、GPL/AGPL3.0，LGPL3.0 が適用される OSS がユーザ
製品として定義されたハードウェアに導入される場合は、インスト
26
共通フレーム 2007 JIS X 0160 OSS 利用により影響を受ける変更部分
項目番号 作業定義 項目番号 レーション情報に従ってインストールが適切にできることを確認す
る。 1.6.13.1 取得者の受入れレビ
ューと受入れテスト
の支援
・・・受入れレビュー及びテストは，共同レビュー（2.6 参照），監査（2.7 参照），ソフトウェア適格性確認テスト（1.6.9 参照）、システム適格性テスト（1.6.11 参照）（実行した場合）及び導入の実施
（1.6.12）（該当 OSSの再導入）の各々の結果を考慮する。・・・ 1.6.13.2 ソフトウェア製品の
納入 5.3.13.2 【ガイダンス】
OSS については，契約条件に加えて，当該 OSS ライセンスの配
布メカニズムの定義に従ってソフトウェア製品を納入するものとす
る。 1.7. 運用プロセス － 1.7.1.2 運用のための資産の
引き継ぎ 【ガイダンス】
運用対象のシステムが結合されて運用される場合、ごく稀なケ
ース (AGPL) として、ソース開示の範囲が元システムにまで及ぶ事がありえる。 この時点での確認では遅いと思われるが、前段階でその場合に対
処する部分がないので、ここに注意しておく。 1.7.1.4 システム運用に係る
事前調整 5.4.1.3 と共通フ
レーム 2007 p.60 にあるが、1.7.1.5 に対応す
るはず。
【ガイダンス】 ソフトウェア配布等手配において、法人格の異なる組織への配布
は著作権法上の配布とみなされる。この結果、著作権法上の配布か
否かによってライセンスへの適合活動が異なるライセンス (GPL など) においては、適切な準備が必要となる。
1.7.5.1 システム利用教育環
境の構築 【ガイダンス】
第三者権利物を使用してシステムを構築した場合、その第三者 (OSS の場合はコミュニティ) が妥当な教育環境を用意していることもありえる。この場合、そうした既存の教育資料を活用すること
を検討すること。 1.7.6.2 利用者の支援 5.4.4.1 【ガイダンス】
第三者権利物を使用してシステムを構築した場合、その第三者が
ヘルプデスクなどの支援環境を用意していることも多い。こうした
既存の支援閑居を活用することを検討すること。また OSS の場合はメーリングリストやフォーラムで技術的質問に答えられることも
あるので、その活用も検討すること。 1.8. 保守プロセス － 1.8.1.1 開発プロセスからの
引き継ぎ 【ガイダンス】
保守者が開発者と別の法人格である場合、そこで著作権法上の配
布が生じる可能性がある。その結果ライセンス条項が変更されるこ
ともあるので注意。 1.8.3.3 購入パッケージの修
正実施 タスクおよびタスク名の修正
修正対象が第三者権利物の場合には、取得の際に定義された契約
事項に基づき第三者権利物の修正を行う。特に OSS の場合は、修正を禁じられてはいないにしても、修正することによって新たな義
務が発生する可能性があるので、その可能性を確認すること。
27
4. 参考文献
SEC BOOKS「共通フレーム 2007 第 2 版」, 独立行政法人情報処理推進機構著, 2009年 9
月発行, 出版社：オーム社, ISBN :978-4-274-50247-7
「共通フレーム 2013」～経営者、業務部門とともに取組む「使える」システムの実現～,
独立行政法人情報処理推進機構, 2013年 3 月発行, ISBN：978-4-905318-19-4
ISO/IEC 12207:1995, ISO/IEC, 1995
ISO/IEC 12207:2008, ISO/IEC, 2008
IEEE 1517-1999, IEEE, 1999
IEEE 1517-2010, IEEE, 2010
JIS X0160:1996, 日本規格協会, 1996
JIS X0160:2007, 日本規格協会, 2007
GPLv3 逐条解説書, 情報処理推進機構, 2010,
(https://www.ipa.go.jp/files/000028320.pdf)
OSS ライセンスの⽐較、利用動向および係争に関する調査, 情報処理推進機構, 2010,
(https://www.ipa.go.jp/files/000028335.pdf )
OSS ライセンス－その戦略と係争の実態, IPA リーガルワーキンググループ, 組込み総合
技術展 Embedded Technology 2010,
OSS ライセンス戦略とその概要
（https://www.ipa.go.jp/files/000028285.pdf）
OSS に関する著作権法上の係争事例
（https://www.ipa.go.jp/files/000028286.pdf）
OSS に関する特許係争・ライセンス事例
（https://www.ipa.go.jp/files/000028287.pdf）
28
付録. IEEE 1517-1999 におけるプロセスの変更状況
それぞれのプロセスに対するアクティビティやタスクの追加の状況は以下の通り。(なお、
各プロセス、アクティビティ名のあとの括弧書きの日本語は「共通フレーム 2007」など、
ISO/IEC 12207 に基づいた日本語版で使われているものを参考のために挿入した)
5.1. Acquisition Process (取得プロセス)
5.1.1.Initiation (開始) 3タスクの修正、2 タスクの追加
(新規タスク) 資産からの再利用可能性の検討
(新規タスク) 資産の再利用性付加の要求
(タスク 5.1.1.6 「選択肢の検討」への追加) 再利用を選択枝として認める
(タスク 5.1.1.7 「取得条件の確認」への追加)外部資産の導入での再利用可能性確認
(タスク 5.1.1.8 「取得計画の作成と実行」への追加) 取得計画の再利用の可能性の検討
5.1.2. RFP preparation (提案依頼書の準備) 1 タスクの修正
(タスク 5.1.2.1 「要求事項の文書化」への追加) 要求文書に再利用に関する言及を入れ
ること
5.1.3. Acceptance and completion (受け入れ及び完了) 1 タスクの修正
(タスク 5.1.5.1 「受け入れの準備」への追加) 受け入れ検査に再利用に関する観点を入
れること
5.2. Supply Process (供給プロセス)
5.2.1. Planning (計画立案) 3タスクの修正、2 タスクの追加
(タスク 5.2.4.2 「ライフサイクルモデルの選択」への追加) ソフトウェアライフサイク
ルの定義における再利用への言及
(タスク 5.2.4.4 「供給方法の選択肢の検討」への追加) 開発計画における再利用への言
及
(タスク 5.2.4.5 「プロジェクト管理計画の立案」への追加) 再利用戦略
(新規タスク) 既存のソフトウェアを使用する可能性の検討
(新規タスク) 開発するソフトウェアの資産化への言及
5.3. Development Process (開発プロセス)
5.3.1. Process implementation (プロセス開始の準備) 3タスクの修正、1 タスクの追加
(タスク 5.3.1.1 「開発作業の組立て」への追加) 組立てにおける再利用要求の充足
(タスク 5.3.1.3 「開発環境の準備」への追加) 開発環境における再利用容易性の選択
(タスク 5.3.1.4 「開発プロセス実施計画の作成」への追加) 再利用可能な実施計画の選定
(新規タスク) ドメインエンジニア、資産管理者との連携可能なメカニズムの確立
5.3.2. System requirements analysis (システム要件定義) 2タスクの修正、3 タスクの追加
29
(新規タスク) ドメインモデルの選択
(新規タスク) 既存のシステム要件定義の再利用の可能性の検討
(タスク 5.3.2.1 「システム要件の分析」への追加) システム要件への再利用要件の記載
(タスク 5.3.2.1 「システム要件の分析」への追加) 再利用の観点からのシステム用件の評価
(新規タスク) システム要件のフィードバック
5.3.3. System architectural design (システム方式設計) 1 タスクの修正、3タスクの追加
(新規タスク) ドメインモデルと整合性のあるアーキテクチャの選定
(新規タスク) 選定したドメインアーキテクチャと整合性のあるアーキテクチャの設計
(タスク 5.3.3.2 「システム方式の評価」への追加) 再利用の観点からのアーキテクチャ
の評価
(新規タスク) 再利用の問題のドメインエンジニアや資産管理者へのフィードバック
5.3.4. Software requirements analysis (ソフトウェア要件定義) 4タスクの修正、1 タス
クの追加
(タスク 5.3.4.1 「ソフトウェア要件の確立」への追加) 品質要求への再利用性の追加
(タスク 5.3.4.1 「ソフトウェア要件の確立」への追加) 既存のソフトウェア要件の再利
用可能性の検討
(タスク 5.3.4.1 「ソフトウェア要件の確立」への追加) テンプレートによる要件定義
(タスク 5.3.4.2 「ソフトウェア要件の評価」への追加) 再利用可能性の観点からの要件
の確認
(新規タスク) 要件からのドメインエンジニアや資産管理者へのフィードバック
5.3.5. Software architectural design (ソフトウェア方式設計) 5 タスクの修正、1タスク
の追加
(タスク 5.3.5.1 「ソフトウェア構造とコンポーネントの方式設計」への追加) ドメイン
アーキテクチャーからの設計
(タスク 5.3.5.2 「外部、コンポーネント間の各インターフェースの方式設計」への追加)
インターフェースのドメインアーキテクチャや既存資産との整合
(タスク 5.3.5.3 「データベースの最上位レベルの設計」への追加) データベースモデル
のドメインアーキテクチャとの整合
(タスク 5.3.5.4 「利用者文書(暫定版)の作成」への追加) 利用者文書の既存資産から流用
の可能性の検討
(タスク 5.3.5.6 「ソフトウェア方式設計の評価」への追加) 再利用の観点からの評価
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.6. Software detailed design (ソフトウェア詳細設計) 5タスクの修正、1 タスクの追加
(タスク 5.3.6.1 「ソフトウェアコンポーネントの詳細設計」への追加) 詳細設計におい
て、再利用の観点を入れること。設計は適切なドメインモデルを採用すること。
(タスク 5.3.6.2 「ソフトウェアインターフェースの詳細設計」への追加) ドメインイン
30
ターフェース標準に適合すること。
(タスク 5.3.6.3 「データベースの詳細設計」への追加) データベースについて、再利用
の観点を入れて詳細設計を行う。
(タスク 5.3.6.5 「ソフトウェアユニットのテスト要求事項の定義」への追加) テスト要
求事項を再利用の観点から定義すること。
(タスク 5.3.6.7 「ソフトウェア詳細設計及びテスト要求事項の評価」への追加) 再利用
の観点から評価すること。
(新規タスク) 詳細設計に関するドメインエンジニアや資産管理者へのフィードバック
5.3.7. Software coding and testing (ソフトウェアコード作成及びテスト) 2タスクの修
正、1タスクの追加
(タスク 5.3.7.1 「ソフトウェアユニットとデータベースの作成及びテスト手順とテスト
データの作成」への追加) ソフトウェアユニットの作成に当たって、再利用できるものに
ついて留意すること。
(タスク 5.3.7.5 「ソフトウェアコード及びテスト結果の評価」への追加) 再利用可能性
の観点から評価すること。
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.8. Software integration (ソフトウェア結合) 4タスクの修正、1タスクの追加
(タスク 5.3.8.1 「ソフトウェア結合計画の作成」への追加) 計画の作成にあたり、再利
用できるものがないか留意。
(タスク 5.3.8.2 「ソフトウェア結合テストの実施」への追加) テスト報告書の作成に再
利用できるものがないか留意。
(タスク 5.3.8.4 「ソフトウェア適格性確認テストの準備」への追加) テストの準備にあ
たり、再利用できる資産がないかに注意する。
(タスク 5.3.8.5 「ソフトウェア結合テストの評価」への追加) 評価は再利用性の観点か
らも行うこと。
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.9. Software qualification testing (ソフトウエア適格性確認テスト) 2タスクの修正、
1 タスクの追加
(タスク 5.3.9.1 「ソフトウェア適格性確認テストの実施」への追加) 文書化は再利用可
能な資産をもとに行う。
(タスク 5.3.9.3 「ソフトウェア適格性確認テストの評価」への追加) 再利用性の観点か
ら評価を行う。
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.10. System integration (システム結合) 2 タスクの修正、1 タスクの追加
(タスク 5.3.10.1 「システム結合計画の作成」への追加) テストで再利用できる資産を元
に計画を作成する。
31
(タスク 5.3.10.3 「利用者文書の更新」への追加) 再利用の視点からの評価
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.11. System qualification testing (システム適格性確認テスト) 1 タスクの修正、1タ
スクの追加
(タスク 5.3.11.2 「システムの評価」への追加) 再利用の観点からの評価
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.3.12. Software installation (ソフトウェア導入) 1タスクの修正、2タスクの追加
(タスク 5.3.12.1 「ソフトウェア導入計画の作成」への追加) 再利用可能な導入計画のテ
ンプレートの利用
(新規タスク) 導入計画およびそのテンプレートは再利用可能性の観点から評価されること。
(新規タスク) ドメインエンジニアや資産管理者へのフィードバック
5.4. Operation Process (運用プロセス)
5.4.1.Process implementation (プロセス開始の準備) 1タスクの修正、2 タスクの追加
(タスク 5.4.1.1 「運用プロセス実施計画の作成」への追加) 再利用可能な実施計画の流
用
(新規タスク) 実施計画の再利用可能性の評価
(新規タスク) 運用からのドメインエンジニアリングへのフィードバック
5.5. Maintenance Process (保守プロセス)
5.5.1.Process implementation (プロセス開始の準備) 1タスクの修正、2 タスクの追加
(タスク 5.5.1.1 「開発及び手続きの作成」への追加) 再利用可能な保守計画の流用
(新規タスク) 既存資産に起因する障害の資産管理者への報告
(新規タスク) 既存資産への障害報告への対応
5.5.2.Problem and modification analysis; (問題把握及び修正分析) 2 タスクの修正、1
タスクの追加
(タスク 5.5.2.3 「修正実施の選択肢の用意」への追加) 再利用可能な資産の流用の検討
(タスク 5.5.2.1 「問題報告又は修正依頼の分析」への追加) 既存資産への問題報告又は
修正依頼の分析
(新規タスク) 既存資産に関する分析結果の資産管理者への報告
5.5.3.Modification implementation; (修正の実施) 1 タスクの追加
(新規タスク) 資産管理者からの既存資産への修正の評価
5.5.4.Migration; (移行) 1タスクの修正、2タスクの追加
(新規タスク) 新環境への移行前の資産管理者への報告
(新規タスク) 新環境への移行後の資産管理者への報告
(タスク 5.5.5.6 「移行評価のためのレビュー」への追加) レビュー後の資産管理者およ
びドメイン技術者への報告
5.5.5.Software retirement. (ソフトウェア廃棄) 2タスクの追加
32
(新規タスク) 廃棄前に当たっての資産管理者への報告
(新規タスク) 廃棄後の資産管理者への報告
6.1 Asset Management Process (資産管理プロセス)
JIS X0160:2007 の 7.5 と同等。
7.1 Reuse Program Administration Process (再利用施策管理プロセス)
JIS X0160:2007 の 7.6 と同等。
8.1 Domain Engineering Process (ドメイン技術プロセス)
JIS X0160:2007 の 7.7 と同等。
33
執筆者 IPA 技術本部国際標準推進センター リーガルワーキンググループ
主査 江端 俊昭 ワークブレイン・ジャパン株式会社 パートナー 行政書士 委員 稲葉 清高 株式会社リコー 研究開発本部 グループ技術企画室 技術戦略室 委員 上山 浩 日⽐谷パーク法律事務所 弁護士・弁理士 委員 大内 佳子 富士通株式会社 SI 技術サポート本部知的財産統括部 委員 村上 晴夫 株式会社日立製作所 情報･通信システム社 IT プラットフォーム事業本部 開発統括本部 ソフトウェア本部構造改革推進部 委員 瀬戸 邦夫 故人 元キヤノン株式会社デジタルプラットフォーム開発本部 ソフトウェア基盤第 2開発部、ソフトウェア基盤 22 開発室 追悼の言葉 瀬戸邦雄氏は、2011 年 9月 25日、不慮の事故に遭われ永眠されました。 本ＷＧの委員としてはもちろんのこと、友人として瀬戸さんを失った事への悲しみは、
筆舌に尽くしがたいものがあります。本書についても、構想時より多大なる貢献を頂
きましたが、何よりも本 WG の活動に共に取り組めた事への感謝を込めて、瀬戸さん
に本書を捧げます。 瀬戸邦雄氏のご冥福を心よりお祈り申し上げます。
【著作権・責任】 本書の著作権は独立行政法人情報処理推進機構（IPA）に帰属します。
IPA は、クリエイティブコモンズライセンス 2.1 表示-非営利-改変禁止（http://creativecommons.org/licenses/by-nc-nd/2.1/jp/）の条件のもとで、無償で本書の利用を許諾します。利用に際しては IPA の著作物であることを明記してください。 内容の改変や営利目的での利用は禁止します。ただし、企業・団体等の内部における利用
を目的とした複製及び翻訳については、無償でこれを許諾します。 本書の内容を適用した結果生じたこと、また、適用できなかった結果について、執筆者、
IPA とも一切の責任を負いませんのでご了承ください。