Comments
Description
Transcript
中間報告書 - 電子政府の総合窓口e
資料３ 情報システム・ソフトウェアの信頼性及び セキュリティの取組強化に向けて ∼豊かで安全・安心な高度情報化社会に向けて∼ −中間報告書− 削除: （案） 見え消し版 平成 21 年 4 月 XX 日 高度情報化社会における情報システム・ソフトウェアの 信頼性及びセキュリティに関する研究会 経 済 産 業 省 削除: 3 （白紙のページです） 書式変更: フォントの色 : 自動 目次 第一部 情報システム・ソフトウェアの信頼性及びセキュリティに関する社会的共通認識の形 成と安全で安心な高度情報化社会の協働建設.................................................. 5 （１） 情報システム・ソフトウェアの経済社会への浸透 .............................................................. 6 （２） 情報システム・ソフトウェアの現状とその信頼性及びセキュリティの問題が経済社会に与える 影響................................................................................................................................... 6 （３） 信頼性及びセキュリティに係る社会的共通認識の重要性............................................... 14 第二部 安全で安心な高度情報社会において求められる情報システム・ソフトウェアの信頼 性及びセキュリティの水準を実現するための諸課題への取組 ........................... 19 第１章 情報システム・ソフトウェアの信頼性及びセキュリティに係る評価・管理指標の整備及びそ の評価体制..................................................................................................... 19 （１） “見える化・測る化”とその共有化の重要性 .................................................................... 19 （２） “見える化・測る化”を推進するための具体的な取組 ....................................................... 27 （３） セキュリティを客観的に評価できるようにする仕組み・体制の整備.................................... 44 第２章 IT を活用してサービスを展開するユーザ企業の IT 活用力の強化........................... 48 （１） ユーザ企業・ベンダ企業間の対話の重要性と相互信頼性の確保.................................... 48 （２） 効率的でリスクに強いシンプルな業務プロセスへの革新 ................................................ 50 （３） ユーザ企業の“要件定義力”、“システム設計力”、“プロジェクトマネジメント力”の強化 ........ 52 （４） ユーザ企業のグローバル化をサポートするベンダ企業の国際競争力の強化.................... 53 第３章 情報システム・ソフトウェアの取引・契約におけるユーザ企業・ベンダ企業の間の共通認 識の欠如を解決するための契約の在り方 ........................................................... 55 （１） ユーザ企業・ベンダ企業間の契約に係るこれまでの取組と課題 ...................................... 55 （２） 責任・役割の関係が明確となる取引・契約の定着 .......................................................... 62 （３） 新しい契約形態への対応 ........................................................................................... 63 第４章 情報システムの開発・運用・保守の高度化のための情報共有体制及び事業継続計画の 普及・啓発....................................................................................................... 73 （１） 運用ノウハウや障害事例、脆弱性関連情報等のデータを収集・分析・活用するための支援体 制整備 ............................................................................................................................. 73 （２） 事業継続計画の普及・啓発......................................................................................... 78 第５章 複雑化する情報システム・ソフトウェアの信頼性及びセキュリティの水準を高度化するた i めの新たな技術課題への対応 .......................................................................... 80 （１） アーキテクチャ記述言語や形式手法............................................................................ 80 （２） 新たな開発手法・技術への対応（アジャイル、MDA、テスト等） ....................................... 82 （３） 頑健なシステム・アーキテクチャの開発（クラウド基盤、オートノミック等）............................ 85 （４） 複雑化・多層化するアーキテクチャへの対応 ................................................................ 87 第６章 クラウド・コンピューティング等の新たなサービスにおける信頼性及びセキュリティの確保 の在り方 ......................................................................................................... 89 （１） クラウド・コンピューティング等の新たなサービスの出現 .................................................. 89 （２） 利用者に対する信頼性・セキュリティ水準の確保 ........................................................... 90 （３） サービス提供者間の責任分界の明確化や障害発生時における対応指針の整備 ............. 95 （４） データが物理的に確保されるデータセンタの在り方 ....................................................... 97 第７章 高信頼で安全な情報システム・ソフトウェアの実現を支える人材を育成するための取組の 在り方 ............................................................................................................ 99 （１） 高度情報化社会の基盤を支える人材の育成に向けて産学官で加速すべき取組 .............. 99 （２） ユーザ企業側の人材育成についての取組強化 .......................................................... 101 （３） 高度な IT 人材の位置付け ....................................................................................... 102 第三部 高度情報化社会の実現に向けた情報システム・ソフトウェアの信頼性及びセキュリ ティの向上のための国際貢献 ...................................................................... 104 （１） 信頼性・セキュリティに関する日本の国際的なポジション .............................................. 104 （２） 主要各国との政策対話の強化................................................................................... 116 （３） 評価・管理指標の国際標準化を目指した産学の連携体制の具体化.............................. 120 （４） 国際協力体制を組んだプロジェクトの推進.................................................................. 122 （５） ソフトウェアの適合性・相互運用性の評価のための認証機関間の国際連携体制の構築 .. 123 ii はじめに IT とサービスが融合し、製品と社会システムが連動する高度情報化社会では、情報システム・ ソフトウェアの規模の拡大と情報システム間の複雑な連携が急激に進展し、その用途も急激に拡 大していく。実際に情報サービス・ソフトウェア産業の市場規模は、2000 年度の売上高約 11 兆円・ 従業員数約 52 万人から 2007 年度には売上高約 17 兆円・従業員数約 79 万人に拡大しており、 今後もこの流れは変わらないだろう。 銀行の ATM、IC カードによる鉄道の自動改札、株式のオンライントレード、あるいは自動車を制 御する電子機器など情報システム・ソフトウェアは、我が国の社会・経済活動において、社会インフ ラとして人々の社会生活を支えるために必要不可欠な存在となっている。また、インターネットの普 及、さらには SOA（サービス指向アーキテクチャ）、SaaS（Software as a Service）、クラウド・コ ンピューティングといった新しい技術やアーキテクチャの出現に伴い、情報化社会の構造が変化し、 様々な IT サービスが創造される高度情報化社会へと変貌を始めている。 情報システム・ソフトウェアが我が国の社会・経済活動の隅々まで行き渡り、“インフラの中のイン フラ”ともなっていく中、社会が情報システム・ソフトウェアの安全・安心に求める要求は極めて高く、 我が国は世界に先駆けて豊かで安全・安心に暮らせる高度情報化社会の実現を目指して、新しい 削除: という 領域に入り始めている。我が国のサービス提供者（ユーザ企業）と情報システム・ソフトウェアの開 発事業者（ベンダ企業）は、その社会の要求に応え、信頼性・セキュリティの高いサービスとそれを 支える情報システム・ソフトウェアを実現するために、既に様々な取組を開始している。 経済産業省においても、1997 年に情報処理振興事業協会（当時）にセキュリティセンターを設 立し、次いで 2004 年に独立行政法人情報処理推進機構／ソフトウェア・エンジニアリング・センタ 削除: たとともに ー （IPA/SEC）を設立、エンタープライズ系ソフトウェアと組込みソフトウェアの開発力強化、情報 システムの品質・信頼性向上に取り組んでいる。 しかし、現状では、社会インフラとなっている情報システム・ソフトウェアにも障害が発生し、その 障害が社会・経済活動に与える影響は、より広範囲かつ深刻なものとなっている。 また、第 2 次情報セキュリティ基本計画では、事故が生じることを前提とした“事故前提社会”へ の対応力強化の実現を目指し、そのためには、100％の情報セキュリティ対策の実現は容易では ない点を社会共通認識として持つ必要性を述べている。実際に、情報システムの信頼性やセキュ リティを向上させるためには相当の開発コストや対策コストが発生するため、限られた経営資源（ヒト、 モノ、カネ）において、信頼性及びセキュリティの確保とコスト低減はトレードオフの関係にあり、適 切なバランスを保つことが重要である。情報システムに関するリスクをユーザ企業とベンダ企業双 方で認識し、共有することが大切である。さらには、障害が発生することを前提とした、早期復旧、 影響の局所化、利用者への配慮や代替手段の提供など、事業継続計画での対応が大切である。 一方、現状では、相次ぐ情報システム障害を受けて、情報システム・ソフトウェアの信頼性及びセ キュリティに対する高い期待に応えるため、必要以上にコストをかけて品質を確保するなど、過剰 1 削除: が、過剰品質や硬直的な業界構造に つながる 投資による社会的ロスも増大している。 このような状況において、我々は、まず、どのような情報システム・ソフトウェアがどの水準の信頼 性やセキュリティを具備するべきか、さらにはその信頼性やセキュリティ水準とコストとの適切なバラ ンスはどうあるべきかなど、高度情報化社会における適切な信頼性及びセキュリティの在り方につ いて社会的な共通認識を持った上で、豊かで安全・安心な高度情報化社会を目指すことが極めて 重要である。このように安全・安心な社会を築くという高い目標へ向かって努力することが、高度情 報化社会における新たなイノベーションを生み出す原動力になる。 また、高度情報化社会を迎えるにあたり、信頼性・セキュリティについて国際的にも高い関心が 集まっている。我が国のユーザ企業とベンダ企業は、世界に類を見ないほど高い社会の期待に応 え、信頼性及びセキュリティの高い情報システム・ソフトウェアを作る力を身につけてきており、今後 はその強みを生かして、本格的にグローバル展開を実施する時期に来ているのではないだろう か。 本研究会においては、このような時代の変化や国際的な動向を踏まえつつ、現状の信頼性及び セキュリティに関する課題・問題点を整理し、情報インフラの上で様々な IT サービスが創造され、 豊かさと安全・安心を実感できる高度情報化社会を実現するために求められる情報システム・ソフト ウェアの適切な信頼性及びセキュリティの在り方と、それを実現するための我が国の戦略的な取組 を検討し、報告書に取りまとめる。 2 高度情報化社会における情報システム・ソフトウェアの 信頼性及びセキュリティに関する研究会 委員名簿 （平成 21 年 3 月時点） 座 長 浜口 友一 社団法人情報サービス産業協会 会長 （株式会社 NTT データ 取締役相談役） 委 員 石原 邦夫 社団法人日本情報システム・ユーザー協会 会長 （東京海上日動火災保険株式会社 取締役会長） 委 員 小野 功 日立ソフトウェアエンジニアリング株式会社 代表執行役 委 員 神山 茂 株式会社ジャステック 代表取締役社長 委 員 神庭 弘年 日本アイ・ビー・エム株式会社 テクニカル・リーダーシップ 委 員 小園 文典 東日本電信電話株式会社 代表取締役副社長 委 員 志賀 典人 株式会社ジェイティービー 常務取締役 委 員 重松 崇 トヨタ自動車株式会社 常務役員 委 員 須藤 修 東京大学大学院情報学環 教授 社長兼取締役 ICP Sr. Executive Project Manager 削除: 委 員 関口 和一 株式会社日本経済新聞社 編集局産業部 編集委員兼論説委員 委 員 武井 優 東京電力株式会社 常務取締役 委 員 西垣 浩司 独立行政法人情報処理推進機構 理事長 委 員 広崎 膨太郎 日本電気株式会社 代表取締役 執行役員副社長 委 員 広西 光一 富士通株式会社 取締役副社長 委 員 本山 博史 株式会社みずほフィナンシャルグループ 常務取締役 削除: 書式変更: 両端揃え 表の書式変更 （現在、株式会社みずほコーポレート銀行 取締役副頭取（代表取締役）） 委 員 山口 英 奈良先端科学技術大学院大学 情報科学研究科 教授 委 員 山本 喜一 慶應義塾大学 理工学部情報工学科 教授 委 員 吉田 正夫 三木・吉田法律特許事務所 委 員 和田 成史 社団法人コンピュータソフトウェア協会 会長 （株式会社オービックビジネスコンサルタント 代表取締役社長） （50 音順、敬称略） 3 高度情報化社会における情報システム・ソフトウェアの 信頼性及びセキュリティに関する研究会 検討経緯 ○ 第 1 回研究会 日時: 平成 20 年 11 月 27 日（木）15:45∼17:45 議題: 研究会の趣旨説明 経済産業省の信頼性・セキュリティ向上に関する取組について 事前調査の取りまとめ結果の概要について ○ 第 2 回研究会 日時: 平成 20 年 12 月 25 日（木）10:00∼12:00 議題: 信頼性・セキュリティに係る論点の整理 個別施策等の進捗状況説明 ○ 第 3 回研究会 日時: 平成 21 年 2 月 19 日（木）10:00∼12:00 議題: 中間報告書骨子（案）について ○ 第 4 回研究会 日時: 平成 21 年 3 月 23 日（月）10:00∼12:00 議題: 中間報告書（案）について 4 第一部 第一部 情報システム・ソフトウェアの信頼性及びセキュリティに関する社会 的共通認識の形成と安全で安心な高度情報化社会の協働建設 我が国経済は、国際的な金融問題の影響を強く受け、現下、景気は急速に悪化を続け、厳しい 状況にある。こうした状況の中、企業の設備投資は停滞し、情報システムに対する投資についても、 減速傾向を強めてきている。 しかしながら、現在こうした厳しい経済環境にあるとしても、我が国の高度情報化社会への流れ は決して後退することはない。むしろ、社会が大きな転換点に立つ中、経済活動をより効率化する ための、また、新たな需要を掘り起こすための、IT を活用した新規の挑戦は徐々に拡がりを見せて いき、我が国がネットワーク化された情報システムによる高度情報化社会を迎えることは間違いの ないことである。しかし、高度情報化社会は、単純にこれまでの延長線上にあるものではない。これ までのルールや常識がそのまま適用されることはなく、高度情報化社会を豊かで安全・安心なもの とするための基盤を整えていく取組が求められていく。我々は今、その入り口に立っているというこ とを強く認識することが必要である。 高度情報化社会への動きは、これまでのようにネットワークインフラの高度化による、いわば供給 側:サプライサイドが主導してきた情報化の流れとは異なり、需要側:ニーズサイドが IT の新たな活 用方法を見つけ出していくことで進められていく。それは情報システム・ソフトウェアが社会システム、 製品のあらゆる機能を実現させていくことであり、あらゆる局面で情報システム・ソフトウェアが我々 の生活を支える、いわば“インフラの中のインフラ”としての役割を拡大させていき、IT 自体が生活 の基礎となっていくことを意味している。 このような経済社会の変化、高度情報化への動きを理解した上で、今や“インフラの中のインフ ラ”となった情報システム・ソフトウェアが、安全で安心な我々の日常生活、経済活動を実現してい くために、どのような活動環境を提供することが求められているかについて明らかにし、それを実現 していくための取組を始めなければならない時期に至っている。 高度情報化社会に向けて時代が大きく動いている中、その基盤となる情報システム・ソフトウェア の信頼性及びセキュリティの水準について、社会的な共通認識は存在していない。こうした状況の 中、システム障害を巡るマスメディアの取り扱いは大きくなる一方であり、様々な問題点が多方面か ら指摘されるようになっている。一方で、情報システム・ソフトウェアに求められる信頼性及びセキュ リティの水準が見えない中、情報システムに必要以上の品質を求めた過剰品質や強い防衛意識 によるシステムの効率性、柔軟性、拡張性を犠牲にした情報システム開発も発生しており、我が国 社会における高コスト構造やサービスの柔軟性の欠如に結びつくおそれを強めてきている。 こうした状況は、我が国特有の問題と考えるべきではない。IT の利活用を高い品質水準で進め てきた我が国が真っ先に向き合っているということであり、今後、高度情報化社会に突き進んでいく 他の国においても同様に直面する問題である。そうした意味で、我が国はこの問題に対して適切 な解を見つけ出し、世界に対してモデルを示すことができるかについても試されているということを 5 第一部 意識しなければならない。 本報告書第一部では、上記のような認識の下、迎えつつある高度情報化社会において我々が 共有すべきこと=“インフラの中のインフラ”となった情報システム・ソフトウェアの信頼性及びセキュリ ティの相場観・水準について、社会的共通認識が必要となっており、そのためにどのような方向を 目指していくべきかについて論じるものである。 （１）情報システム・ソフトウェアの経済社会への浸透 朝、出勤で家を出る時に、鍵をかけることがない家が増えている。カード・キーを使っているため、 鍵をかける必要がないためだ。通勤路でコンビニエンス・ストアに立ち寄り、おにぎりと牛乳を買い、 電車に乗る。この時も現金を手にすることはない。この間、すべては非接触型のカードによって支 払が行われている。 我々のこのような生活は、ここ数年で急激に普及した技術によってもたらされたものである。多く の人たちは、今や普通にこれらの技術を活用して日常生活を送っており、それ以前の生活との断 絶を感じることもなく、IT の高度利用による新たなサービスを自然に受け容れてきている。 しかし、こうした便益が社会にもたらされる裏側で、我々の日常生活や経済活動は、広く、深く情 報システム・ソフトウェアに依存するようになり、その水準も加速度的に高まっている。 その結果、あらゆる社会活動や製品の機能を実現することになる情報システム・ソフトウェアの開 発・運用規模は爆発的に拡大している。さらに、一層の利便性を実現していくため、例えば、これま では電車の乗り降りにしか使われなかった非接触カードで買い物ができ、クレジット利用もできるよ うになるなど、これまでは独立していた様々な機能が相互に関連性を深めながら発揮されるように なっている。 情報システム・ソフトウェアが大規模化・複雑化していくことで実現されている現在のサービスは、 期待されるその領域のまだ一部だけであり、まだまだ拡大を続けていくだろう。こうしてもたらされる 我々の生活の利便性は、一方で、情報システム・ソフトウェアにいったん障害が発生した場合に、 広く、更に思いもよらない形での問題を発生させることにもつながっている。いわば、日常生活や経 済活動における大きな便益を享受する対価として、潜在的なリスクも急速に増大してきており、その 対策にかかるコストも拡大していくことを意味している。 （２）情報システム・ソフトウェアの現状とその信頼性及びセキュリティの問題が経済社 会に与える影響 ① システム大規模化の現状 社会システムや製品の機能がソフトウェアによって実現されていく範囲が拡大していく中で、 ソフトウェアの開発規模は爆発的に拡大している。例えば、大手都市銀行の合併に伴う情報 システム統合では、4 年半という歳月をかけて、総費用が 3,300 億円、開発工数 14 万人月、 ピーク時にはシステムエンジニアを 6,000 人も投入して開発を行った。 6 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt また、製品分野においても、自動車の組込みソフトウェアでは、2000 年当時は 100 万ステ ップ程度であった情報システムは、今や 1,000 万ステップを超え、2015 年頃には 1 億ステッ プに到達するという予測もある（図Ⅰ- １を参照）。 100000000 １億行 DC (BCG データ） DC (BCG 10000000 データ） （Ward' Auro World） コード行数 1000000 GM (eWeek） GM (eWeek） （Ward' Auro World） （日経ビジネス） トヨタ（日経産業新聞） 日産 （日経エレクトロニクス） （日経 金融新聞） （ECN) 100000 GM (eWeek） DC (BCGデータ） 10000 （日経エレクトロニクス） 日産 1000 DC (BCGデータ） DC (BCGデータ） 2015年にはプログラミングの コード行数（LOC）が１億行を 突破すると予測されている。 100 DC (BCGデータ） 10 DC (BCG 1 データ） 1960 1970 1980 1990 2000 2010 2015 2020 年 （出典）記事検索、BCG データベース及び分析 （注: 表中の（ ）内がデータの出所） 図Ⅰ- １ 車載電子システムのソフトウェア量の推移 ② ネットワーク化による複雑化の現状 ブロードバンドの普及によるネットワーク化の進展の下、情報システムが様々な機能を実現 していく中で、情報システムの複雑化が急激に進んでいる。特に、システム間の連携を円滑に するため、ソフトウェアの API がオープンになることが急激に増加する中で、これまでは会社 内など組織内部で活用するシステムがそれぞれ独立して存在していた状況から、外部にある リソースを積極的に内部に取り込んで活用するためにオープンな外部システムとつないでいく ようになっている。 例えば、航空券の予約について、以前であれば旅行代理店を通じて航空会社のシステム にアクセスして予約を行っていたが、今は個人顧客がインターネットを通じて航空会社のシス テムにアクセスして航空券を確保するようになり、さらに、航空券のみならず、宿泊などの他の サービスもまとめて取り扱う仲介システムを、ネットワークを介して利用できる形になっている。 例えば、ある航空会社では ID 連携の技術を利用し、他社のホテル予約サイトなどのサービス を 1 つの ID で使えるようにしている。そのような情報システムは極めて複雑なものとなり、また 情報の流れの管理も、限られた関係者間によるコミュニケーションではなく、より広範囲の関係 者と情報交換を行う必要があるため、予測が難しく、より複雑な管理を必要とするようになって いる。 また、現金自動預払機（ATM）をつなぐネットワークも拡大を続けている。ATM のネットワー クは、一律的に構成されたシンプルなものではなく、都市銀行のネットワーク、地方銀行のネッ 7 削除: るようになっており 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt トワーク、第二地方銀行のネットワーク等を相互に接続した複雑なものである。方式が統一さ れていないため、相互接続のためには送受信データの変換等も必要となる。コンビニ ATM と 都市銀行の ATM で用いる文字がカタカナと漢字とで異なっているために障害が生じた事例 は記憶に新しい。単純なミスだとしても、接続先が増えネットワークが複雑化すれば、情報シス テムの信頼性及びセキュリティの大きなリスク要因となる。 さらには、自動車や情報家電など様々な機器が、ネットワークに接続されるようになり、ユー ザは様々な便利な情報の提供を必要な時に受けられるという新しいサービスを享受できるよう になっている。しかし、ユーザは一般の消費者である場合が多く、従来からあるアナログ機器 の延長上で利用しているという現状がある。こうした機器が提供する情報が信頼に足るもので あることを保証することが難しくなってきているという状況にある 。 ③ システム障害の発生状況 このような状況の中、システム障害の発生は、以前よりも幅広い範囲に対して影響を及ぼす 削除: による被害の規模 ようになっており、その被害も大きくなる傾向を強めている。 例えば、2008 年には金融機関のネットワークに障害が発生し、約 74 万件の為替取引が未 処理のまま 1 日停止したり、航空機の国内線予約システムにトラブルが発生し、約 7 万人の利 用客に影響が出たりするなど社会的に大きな影響を与えるシステム障害が発生している。組 込みソフトウェア開発においては、不具合による対策費と経済損失の合計が、開発費の約１割 にのぼるとのアンケート結果1もある。 また、海外においても情報システム・ソフトウェアの問題に起因して、様々なシステム障害が 発生し、時に深刻な影響を社会に対して与えるようになっている（図Ⅰ- ２を参照）。例えば、 2003 年に米国の北東・中西部地域において発生した停電は、組込みシステムの不具合が原 因であったものの、その解決作業は複雑で最終的に 40∼60 億ドルの費用が発生している。 また、2004 年の米国大統領選挙でも一部地域において開票の際、電子投票システムのソフト ウェア欠陥によって間違った票集計が行われ、票が何倍にも増えたりする問題が発生するな ど、合計で 1,100 件もの電子投票機のシステム故障に関する問題が報告され、電子投票シス テムに関する信頼性が疑問視された。 さらに、別の調査2では、米国及びカナダでは、ミッション・クリティカル・システムの障害発生 時間数3は、2005 年から 2008 年にかけて倍増していると報告されている（図Ⅰ- ３を参照）。 1 2008 年版組込みソフトウェア産業実態調査（経済産業省、平成 20 年 7 月 8 日） （http://www.meti.go.jp/policy/mono_info_service/joho/2008software_resarch.html） 2 ガートナーリサーチによる GMI (Global Market Insite, Inc.)のパネルを用いた Web アンケート調査 3 ミッション･クリティカル・システム： システムが障害を起こすと売上げに無視できない影響を与えるなど、ビジネス に大きな影響を有しているシステム又は航空管制等の重要な公共機能を担っているシステム 障害発生時間： 稼動することになっている時間のうち、IT サービスが利用できない時間（停止が予め通知され ている時間は除く）。ただし、アンケートで明示しているわけではないため、回答組織によってはサービス水準が低 下している時間を含めている。 8 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 書式変更: インデント : 最初の行 : 1 字 書式変更: フォント : 9 pt 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 原 因 （推定含む） 元々の仕様・設計・構築に不具合 運用・保守時に発生 人為的なミスにより発生 （仕様要求不足・考慮漏れ含む） （アップグレード・リプレース時） （管理ミス、運用ミス等） 17. Boeingグアム墜落事故（死者228名） 破局的 22. 英Paddington列車衝突事故（死者31名） （死傷者発生 ・その 潜在性大） 32. 英Buncefield油槽所火災（警報不良） 19. 米航空管制システム障害（管制官200名） 24. 独鉄道レール切替シス不具合（3日間） 24. 米NY地下鉄衝突事故（仕様見直し不足） 23. 米道路交通信号機シス不具合（復旧半日） 18. 英航空管制SWバグ（開発費6.2億ポンド） 重 篤 度 10. NASDAQシステム誤作動（復旧24時間） 7. 米長距離電話通信網ダウン（復旧9時間） 重 大 8. 英LSE株式売買システムダウン（復旧7時間） （経済的損失大、 広範囲・ 長期障害） 25. 欧州停電（復旧最大4時間、最大6000万人） 15. 北米銀行口座残高増加（7.6億ドル誤謬） 26. 北東アメリカ大停電（人為的他複合原因） 16. 米NYSE取引停止（復旧75分） 14. 北投資家口座残高不足（復旧24時間） 11. 北米銀取引シス不具合（1億ドル、復旧2週間） 4. 加Northern電話交換シス不具合（復旧1カ月） 2. 米MCI-WorldCom NW障害（復旧8日間） 30. 米社会保険金支払不足（約70万人） 31. 加医療情報シス不具合（約600人、復旧5日） 1. Verizon社料金過剰請求（復旧4日） 3. スウェーデン電話不通（復旧最大8時間） 20. 米列車発券シス不具合（復旧最大3日間） 6. 米AOL NWダウン（復旧19時間） 5. 米Bell Atlantic電話シス不具合（復旧7時間） 9. 米地銀システムダウン（ATM停止等） その他 12. 米銀ATM停止（復旧最大1日） 28. 英納税システム不具合（約13万人） （上記以外） 27. 米大統領選投票シス障害（復旧最大半日） 29. 米財務省社会保険シス不具合（約5万人） 21. 米シスコ高速鉄道停止（復旧最大70分） 13. ドイツ銀傘下銀行口座誤処理（復旧2日） （出典）ガートナーコンサルティング分析 図Ⅰ- ２ 海外におけるシステム障害事例 *Estimated：障害時間を実測せず、推測した企業 *Tracked：障害時間を実測した企業 企業規模（従業員数） 注） 年ごとにサンプルの取り方、回答方法は異なる （出典）ガートナーリサーチ “Dataquest Insight: Unplanned Downtime Rising for Mission-Critical Applications” （2008 年 9 月分析、10 月 3 日発行）、ガートナーコンサルティング分析 図Ⅰ- ３ 北米ミッション・クリティカル・システムにおける月間平均障害発生時間（企業規模別） こうした状況の中、システム障害の発生に対する国民、マスコミの関心は高まる一方であり、 システム障害に関する報道は増加傾向を強めている。独立行政法人情報処理推進機構（以 9 書式変更: フォント : 9 pt 書式変更: インデント : 最初の行 : 0.7 字 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 下、本稿では IPA とする）の調べでは、情報システム・ソフトウェア障害に関するマスコミ報道 は増大傾向にあり、障害発生とともに社会的な関心も増加していることが分かっている（図Ⅰ４を参照）。また、海外におけるアンケート調査でも、銀行を選ぶ際に、銀行システムの安定性 に対して一般利用者が強い関心を持っていることが明らかになっている。 マスメディア公表のシステム障害発生件数（累積、年・月別） 50 45 40 30 25 20 沈静化するものの？ 15 NTT，ＡＮＡ，ＪＲ等インフラ系で 証券・商品取引所，金融関連 システム障害多発 (Ｓ開始・機能追加直後で発生） 10 東証，建築（構造計算）関連 システム障害多発、危機感増大 5 年月 2008.5 2008.3 2008.4 2008.1 2008.2 2007.11 2007.12 2007.9 2007.10 2007.7 2007.8 2007.5 2007.6 2007.3 2007.4 2007.1 2007.2 2006.11 2006.12 2006.9 2006.10 2006.7 2006.8 2006.5 2006.6 2006.3 2006.4 2006.1 2006.2 2005.11 2005.12 2005.9 2005.10 2005.7 0 2005.8 累積・月別件数 35 ▲（METI：緊急点検）（2007.5） ▲建築基準法改正（2007.6） （出典）IPA 図Ⅰ- ４ 情報システム・ソフトウェアに係る障害の増加と社会的関心 ④ 情報システム・ソフトウェアの障害の発生要因 我が国では、情報システムのユーザ企業、ベンダ企業において、情報システムの信頼性、 そして情報システムを通じて提供されるサービスの信頼性を向上させるための様々な努力が 続けられてきた。その一方、市場においては、サービスの多様化や内容を高度化するための 競争は更に激しいものとなっており、情報システムの大規模化・複雑化の流れは加速するば かりである。 このような状況の中、そもそも情報システムが実現すべき機能や品質に関する要件を明確 にすることはますます難しくなっている。情報システム・ソフトウェアの開発プロジェクトにおける 品質問題の発生原因として、実に 3 分の 1 以上の企業が、こうした要件を定義する段階（要件 定義フェーズ）における問題がシステム障害につながっていると考えている（図Ⅰ- ５を参照）。 また、システム障害の主な原因（1 位／2 位）を企業規模別に見ると、ハードウェアの故障以外 にも、独自開発ソフトウェアのバグ、運用オペレーションにおけるミス等による障害の発生も多 いことが分かる（図Ⅰ- ６を参照）。また、米国においても、ソフトウェアの欠陥の 2 割が要件定 義フェーズで発生しているという調査結果もある（図Ⅰ- ７を参照）。常に変化するサービスの 高度化のために大規模化・複雑化していく情報システムについて、信頼性及びセキュリティを 向上するために、情報システムが実現すべき要件を開発前のフェーズから明確に規定する必 10 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 要性が更に増大するという、相反する要求が高まる中で、多くのユーザ企業、ベンダ企業はそ の困難に日々悩まされる状況に直面している。 10% 0% 20% 30% 40% 50% 60% 21.7% 社内の開発体制に問題 2008年 13.9% 2003年 15.0% ベンダーの選択に問題 10.6% 36.7% 35.9% 要件定義不十分 システムの企画が不十分 16.7% 18.7% システムの設計が不正確 19.1% 31.7% 31.7% システムの開発の質が悪い 13.1% 41.7% テストが不十分、移行作業に問題 21.9% 31.7% エンドユーザーへの教育不十分 19.1% 18.3% 計画が現実の利用形態に沿わず 7.6% 11.7% その他 27.7% 有効回答は2003年が498件、2008年が60件（複数回答可） （出典）日経コンピュータ（2008年12月1日号）：第2回プロジェクト実態調査（平成20年8月∼9月） 図Ⅰ- ５ 品質問題がどこで起きているか（複数回答） 0% 10% 20% ネットワーク（キャリア側）の障害 40% 22% 独自開発ソフトウェアのバグ 13% 11% 5% 運用オペレーションにおけるミス 4% パッケージソフトウェアのバグ 4% 60% 13% 9% OS、ミドルウェアのバグ 50% 28% 15% ネットワーク（自社側）の物理的故障 1000人未満 30% 28% ハードウェアの故障 4% 11% 8% キャパシティ管理の不備 2% 3% 要求仕様の誤り、設計ミス 2% 3% ネットワーク（自社側）の運用ミス、テスト不足、設計ミス 2% 6% DBMS（データベースマネジメントソフト）のバグ 1%1% その他 6% 3% ネットワーク（キャリア側）の障害 23% ハードウェアの故障 ネットワーク（自社側）の物理的故障 1000人以上 7% 12% 運用オペレーションにおけるミス 18% 8% 要求仕様の誤り、設計ミス 10% 5% パッケージソフトウェアのバグ 8% 5% 6% 3% 2% ハードウェア以外の障害も多い 14% 6% キャパシティ管理の不備 ネットワーク（自社側）の運用ミス、テスト不足、設計ミス 14% 14% 独自開発ソフトウェアのバグ OS、ミドルウェアのバグ 11% 18% 4% 1位(n=371) 4% 2位(n=271) DBMS（データベースマネジメントソフト）のバグ 0%2% その他 4% 4% （出典）企業 IT 動向調査 2008（JUAS） 図Ⅰ- ６ 規模別システム障害の主な原因 11 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt Bad Fixes, 8.0% Documents, 12.0% Requirements, 20.0% Coding, 35.0% Design, 25.0% （出典）“SOFTWARE QUALITY IN 2008: A SURVEY OF THE STATE OF THA ART” （2008 年、SRP Software Productivity Research LLC）（JaSST Japan Symposium on Software Testing ソフトウェアテストシンポジウム資料）、ガートナーコンサルティング分析 図Ⅰ- ７ 米国におけるソフトウェア欠陥発生フェーズ また、ネットワーク化などによって情報システムの大規模化・複雑化が進んでいることで、情 報システムの運用・保守の重要性はますます高まっている。システムの運用は定常的な業務 であるという認識が持たれているが、情報システムの複雑化が進んでいく中で、その運用も以 前とは比較にならないくらい難しいものとなり、ちょっとした人為的なミスが致命的な問題を発 生させる要因となっていることも少なくない。システム障害の実に 70％は運用・保守における 問題で発生しており（図Ⅰ-８を参照）、今後さらに経済のサービス化が進んでいく中で、システ ムの運用・保守フェーズにおける信頼性の向上の取組は重要性を増大させていくことになる。 30％ 0% 70％ 開発 再構築 保守 運用 21.4％ 8.3％ 29.8％ 40.5％ 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% （出典）重要インフラ情報システム信頼性研究会（IPA、JUAS） 図Ⅰ- ８ 情報システムの障害の原因となっているフェーズの割合 12 削除: が 第一部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt さらには、証券取引の誤発注により多額の損失が発生するなど、単純なオペレーションミス が極めて大きな社会的影響を与える事故につながっている。利用者が誤った操作をした場合 でも危険な状態に陥らないように設計するフールプルーフの考え方で、ユーザインタフェース を設計するなど、情報システムのユーザビリティの向上も重要な課題となっている。 このような状況に対し、情報システム・ソフトウェアの信頼性及びセキュリティを高い水準で 実現するために検証フェーズにおけるコストが増大する傾向を強めている。例えば、2008 年 度版組込みソフトウェア実態調査によると、開発工程のうちテスト工程が半分以上を占めること が分かっており、下流工程の検証フェーズで多くのコストをかけている実態が判明している（図 Ⅰ- ９を参照）。日経コンピュータによる最新の調査4では、情報システム障害の発生要因とし てテストフェーズに問題があるとした割合は 5 年前の調査に比べて急進しており（図Ⅰ- ５を参 照）、情報システム・ソフトウェアが大規模化・複雑化する中、検証自体が大規模化・複雑化し、 完全に問題を排除することが難しくなっていることが明らかになってきている。 （出典）2008 年版組込みソフトウェア産業実態調査から IPA/SEC が作成 図Ⅰ- ９ 組込みソフトウェアの工程毎の工数比率（大工程分類） 4 第 2 回 プロジェクト実態調査（日経コンピュータ 2008 年 12 月 1 日号特集） 13 削除: 繋がって 第一部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt （３）信頼性及びセキュリティに係る社会的共通認識の重要性 市場におけるサービスの高度化を巡る激しい競争の中で、情報システム・ソフトウェアの大規模 化・複雑化が急激に進展し、情報システム・ソフトウェアにおける問題がシステム障害となって、社 会に対して深刻な影響を及ぼすようになっている中、情報システムのユーザ企業、ベンダ企業は、 増大するリスクを発現させないようにするため、情報システムをはじめとした事業の信頼性を引き上 げるための様々な努力を日々展開している。 しかし、これまでの単独の事業者による独自の努力だけでは、更に大規模化し、複雑化すること でリスクを拡大してきている情報システム・ソフトウェアの信頼性及びセキュリティの水準の向上を図 ることは限界を迎えようとしている。例えば、これまで情報システムに直接関わることがなかった人々 が情報システムを操作する機会が増大する中、誤った操作をしないようにするためのユーザビリテ ィを如何に確保していくのか、また、複雑化する情報システムの運用・保守への負担を軽減するた めにリスク・セキュリティ対策などを設計フェーズから如何に反映させるのかなど、情報システム・ソ フトウェアの適用領域が拡大して、複雑化することに対応し、様々な関係者の様々な行動を想定し て情報システム・ソフトウェアの開発前のフェーズから必要な対応策を検討し、情報システムのアー キテクチャに反映させるとともに、情報システム・ソフトウェアのライフサイクルを適切にマネジメントし ていかなければ、それらの信頼性及びセキュリティの水準の向上は困難なものとなってきている。 こうした状況を踏まえ、我々は情報システム・ソフトウェアによるシステム障害の発生を最小限に 食い止めるため、情報システム・ソフトウェアに更に求められる定量的な評価・管理指標の整備、商 取引の適正化、開発技術の高度化による開発フェーズにおける問題の発生を抑止するとともに、 情報システムを運営する人的体制を含めた組織的対応力の強化とダメージの局所化、ベストプラク ティスの共有の促進などによる運用・保守の水準の高度化を進めなければならない。 一方で、こうした情報システム・ソフトウェアの信頼性及びセキュリティの水準の向上のための取 組を強化しながらも、このような取組によってもたらされる高コスト構造などの問題を正面から認識 することが必要である。我々は、情報システム・ソフトウェアの信頼性及びセキュリティの向上を図る 取組を進める上で、どの程度の水準を実現するのかを踏まえて目標を立てなければならない。そ のためには、“第 2 次情報セキュリティ基本計画”で示された“事故前提社会”の考えを踏まえ、さら に、情報システムが大規模化・複雑化することで拡大していくシステム障害発生のリスクに対し、シ ステムの無謬性を前提とするのではなく、障害の発生をゼロにすることが容易ではないということを 理解し、サービスによってもたらされる便益、リスクとそれを抑制するためのコストについてどのよう な水準を求めるかについて、社会的共通認識を形成することが必要である。 情報システム・ソフトウェアに関する信頼性及びセキュリティの水準について、社会的共通認識 がなければ、その水準を向上するための取組の目標が示されることはなく、単に膨大なコストをつ ぎ込むこととなり、返って社会全般に対して無駄をもたらすことにもなりかねない。 適切な社会的共通認識を形成していくためには、幅広く利害関係者の考えが反映されるプロセ スが必要である。このプロセスに参加するのは、情報システムのユーザ企業、ベンダ企業だけであ ってはならない。最終利用者である消費者は、サービスの品質全般に関する顧客満足度調査など 14 削除: 譲歩 第一部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt を通じて意見を明らかにし、本プロセスに参画していくことは可能である。また、ユーザ企業、ベン ダ企業はできるだけ情報をオープンにし、説明責任を果たしていくことで、マスメディアなどを通じ て最終利用者とコミュニケーションを図っていくことも可能である。 高度情報化社会を迎えつつある中、我々は更に利便性の高いサービスを享受する一方、その サービスを利用するか否かについて自らが適切に判断していかなければならない。その判断の前 提となる情報をオープンなものとし、社会で広く共有していくことによって、議論を活発化させ、情 報システム・ソフトウェアの信頼性及びセキュリティに関する社会的共通認識を形成していくことが、 今後さらに信頼性及びセキュリティの水準を向上させていくための大切な一歩であり、高度情報化 社会を支える重要な基盤となっていくであろう。我々はそのための取組に着手すべき状況に至って いることを深く理解することが必要である。 こうして形成された社会的共通認識は、高度情報化社会において情報システム・ソフトウェアが 削除: た 実現するべき信頼性及びセキュリティの水準の目標となる。そして、その目標を達成しなければな らないという想いこそが、高度情報化社会における新たなイノベーションを呼び起こしていくことに なる。これまで高い品質の製品やサービスを実現してきた日本の“強み”が、高度情報化社会にお いても遺憾なく発揮され、次のイノベーションを創出していくためにも、その目標となる情報システ ム・ソフトウェアの信頼性及びセキュリティに関する社会的共通認識の形成は極めて重要な鍵とな るのである。 ① 信頼性・セキュリティに関する社会的共通認識 ∼あるべき姿∼ 情報システム・ソフトウェアの信頼性及びセキュリティは、サービスの内容とリスク、そしてコス トの大きさとのバランスによって決まるものであり、利用者がサービスの内容とリスク、コストにつ いて納得し、その期待通りにサービスが提供されている状態が、“信頼性及びセキュリティが 確保されている状態”であるということができる。 しかし、上記のように定義される“信頼性及びセキュリティが確保されている状態”は、静的 に決定されるものでもなく、変化しないものでもない。むしろ、同じように見える情報システムで 削除: 静的に決定され、変化しないものでは あっても、それぞれの情報システムが実現する機能によって求められるものは異なることにな ない る。さらに、技術や社会環境、時代の流れなどの変化が反映され、ほとんど同じ環境の下にあ 削除: 、 っても、利用者が直面する条件が異なることで、信頼性及びセキュリティが確保されていると考 えられる状態は異なることになり、また動的なものであると理解すべきである。 信頼性及びセキュリティに関する認識が、このように動的なものであるからこそ、利害関係者 が受けるサービスとそれに伴うリスク、コストについて共通の認識を持つことが重要となる。 ② 現状の認識 上記のように情報システム・ソフトウェアの“信頼性及びセキュリティが確保されている状態” が定義されたとしても、その具体的な水準、相場観について社会的な共通認識が形成されて 15 削除: る 第一部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt いなければ、サービスの提供者・情報システムの開発者がどの程度まで情報システム・ソフトウ ェアの信頼性及びセキュリティの水準を実現するべきかについて不明瞭な状況であることに 変わりはない。現状においては、残念ながら“信頼性及びセキュリティが確保されている状態” 削除: 代わり についての社会的な共通認識は存在していない。 その結果として、本来であれば適切に措置されているべき事項についての対応が不十分 であることが原因となり、システム障害が発生し、広い範囲の関係者に深刻な影響を与えるこ とが現実に発生している。 一方で、障害の発生に対して過剰に反応することで、本来であれば必要とされない品質水 準を実現するための過剰投資を誘発したり、サービスの効率性や情報システムの柔軟性、拡 張性を犠牲にし、結果的に最終消費者の便益を低下させているような場合もある。 こうした問題の背景には、そもそも情報システム・ソフトウェアの信頼性及びセキュリティの水 準について、議論が抽象的な段階に留まり、具体的に認識するための手法として社会的に共 有されているものが欠如していることがある。 まず、情報システム・ソフトウェアの信頼性及びセキュリティについて、その“見える化”を図り、 その水準を“測る化”することで、情報システムについて利害関係者が同じ尺度で認識するこ とができる環境を整備することが必要であり、利害関係者がその環境を積極的に活用していく ことで“信頼性及びセキュリティが確保されている状態”を実現することが求められる。 例えば、北米の従業員数 2,400 人以上の企業において、ミッションクリティカルなシステム の月間平均障害発生時間が 1 時間以上の企業は約 8 割以上存在しているにもかかわらず、 削除: 月間停止時間 約 9 割の企業が現状の障害時間は許容範囲内と考えている（図Ⅰ- １０を参照）。また当該調 査では、月に 24 時間以上ミッションクリティカルなシステムが停止している企業の割合が約 1 割存在している。これら 2 つの結果から類推すると、北米ではミッションクリティカルなシステム においては、月間平均障害発生時間が 24 時間以下（稼働率約 97%以上）であれば許容され 削除: 月間停止時間 ると想定できる。一方、我が国の基幹システムにおける稼働率の要求水準5は 、稼働率の目 標値を 98%以下で設定している企業は 2%以下6 となっており、17%の企業が 99.999%（年 間 5 分程度の停止時間）、同じく 17%の企業が 99.99%（年間 1 時間程度の停止時間）を目 標値としており、システムの信頼性に対する要求水準の違いが鮮明となっている。このような 状況を鑑みると、信頼性の基準についての共通認識があるとはいえないであろう。 また、先の調査によれば、北米の従業員数 2,400 人以上の企業において、ミッションクリティ カルなシステムの月間平均障害発生時間の実績値平均が 14.7 時間／月であるのに対し、日 本の 1,000 人以上の企業の基幹系システムにおける障害によるシステム停止時間の実績値 平均は 1.3 時間／月であり、実績においても日本の情報システムの信頼性が高いことが伺え る。 なお、セキュリティに対する要求水準については、信頼性と同様、定量的に評価できる要素 5 6 「企業 IT 動向調査 2008」社団法人日本情報システム・ユーザー協会（2008 年 4 月） 調査企業数６０９社、うち 43%が目標値を設定していないまたは不明としている。 16 削除: について 第一部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt がある一方で、個人情報7の漏洩防止など確実に確保しなければならない項目が存在するこ とに留意が必要である。 削除: 北米Mission Criticalシステムにおける 月間平均障害発生時間合計（08年、企業規模別） 改ページ 現状の障害時間は許容範囲内か？（同） N=156 % N=264（1∼499規模含む） % *Plan： 障害時間を短縮するための施策・計画の有無 *ガートナーが米国・カナダの企業IT部門担当者304名に対し、2007年10∼11月に実施した調査結果 （出典）ガートナーリサーチ “Dataquest Insight: Unplanned Downtime Rising for Mission-Critical Applications” （2008 年 9 月分析、10 月 3 日発行）、ガートナーコンサルティング分析 図Ⅰ- １０ 北米ミッション・クリティカル・システム障害発生時間 削除: 障害の原因となっているフェーズの割 合 ③ “見える化・測る化”によるあるべき姿の協働建設 情報システム・ソフトウェアの信頼性及びセキュリティについて社会的共通認識を形成して いくために、まず“見える化・測る化”を進めることが必要である。そのためには、何を“見える 化・測る化”するかについての整理が必要となる。 本研究会では、議論を通じて以下の視点が提示された。 • 利用者の視点に立ってどのような情報システムがどのような信頼性及びセキュリティの水 準を持つべきか。それを踏まえ、サービスを提供する情報システム・ユーザ企業の経営 者が開発する情報システムの信頼性及びセキュリティの水準について判断を行うことが できるようにするための“見える化・測る化”。 • 情報システムのユーザ企業が実現したいサービスのために開発する情報システムについ て、それを構築するベンダ企業が正確に理解し、確実に実現するためのユーザ企業の 要求（業務要求、機能要求、非機能要求）の“見える化・測る化”。 • 開発や運用、保守の現場において、求められる信頼性及びセキュリティの水準を確実に 実現するために必要となる定量的な開発・運用・保守管理のための“見える化・測る化”。 • 事業継続計画を策定し、様々なシステムトラブル場面を想定して訓練を実施するなど、シ 7 個人情報とは、生存する個人に関する情報であって、特定の個人を識別することができるものである。なお、パー ソナル情報（個人と連結可能な情報）については、柔軟な利活用が図られるべき対策が必要である。 17 書式変更: フォント : 9 pt 第一部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt ステム障害の発生時に実施すべきことと対応力を把握するための“見える化・測る化”。 こうした“見える化・測る化”を通じ、情報システムに求められるサービスとリスク、コストを積 極的に管理し、利用者が求める水準を実現していくことが、サービスを提供するユーザ企業と その活動を支えるベンダ企業に求められる。 また、上記のとおり、情報システム・ソフトウェアの“信頼性及びセキュリティが確保されてい る状態”が動的なものであるということを理解し、最終利用者が何を求めているかについて常 に注意深く意識し、それを反映させていくことが必要である。そのためには、ユーザ企業やベ ンダ企業は、自らの取組などについて積極的に最終利用者に情報を発信していくとともに、サ ービスを提供するユーザ企業は、顧客満足度調査などを通じながら最終利用者が求めるもの を的確に把握することに努め、その結果を情報システムの開発・運用・保守に反映させていく ことが重要である。 このように“見える化・測る化”を基礎として、広く利害関係者の意見を汲み取りながら、情報 システム・ソフトウェアの信頼性及びセキュリティに関する社会的共通認識を形成していくべき である。そのためには、社会的共通認識を形成していくための活動に、利害関係者が自ら積 極的に情報発信し、幅広く集められた情報を整理、分析し、その結果を自らが活用していくこ とが求められる。 ユーザ企業、ベンダ企業は、“見える化・測る化”の実現に協力し、実際の経済活動に反映 していくことが、経済活動の安定的な基盤を構築する上で不可欠であるということを理解し、積 極的に加わっていくことが強く求められる。また、学界は科学的視点や国際的な議論の状況 を反映させるべく、産業界の活動に加わるとともに、行政はこうした活動を支えるため、関係者 が参画しやすい体制の構築や活動への支援、標準化活動の推進などの環境整備を加速して いくことが求められる。さらに、最終消費者についても、サービスを提供するユーザ企業の顧 客満足度調査などを通じて意見を発信していくことで、社会全体のリスク・アセスメントの活動 に参加することが求められる。利害関係者がこうした形で活動していくことで、情報システム・ソ フトウェアの信頼性及びセキュリティに関する社会的共通認識の形成とその水準を実現してい く“協働”関係を構築することが重要である。 18 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 第二部 安全で安心な高度情報社会において求められる情報システム・ソフト ウェアの信頼性及びセキュリティの水準を実現するための諸課題への 取組 第１章 情報システム・ソフトウェアの信頼性及びセキュリティに係る評価・ 管理指標の整備及びその評価体制 （１）“見える化・測る化”とその共有化の重要性 第一部で、情報システム・ソフトウェアにどの程度の信頼性及びセキュリティの水準を求めるかに ついて、求めるサービスレベルと許容できるリスクとコストを踏まえた社会的共通認識を形成するた めに、信頼性及びセキュリティを“見える化・測る化”することの必要性を述べてきた。 削除: の “見える化・測る化”による社会的共通認識の形成について、本章では、次の 3 つの観点につい て述べることとする。 第一は、最終的なサービスの利用者（エンドユーザ）の視点に立って、そのサービスを提供する 削除: 1 つ目 情報システム・ソフトウェアの信頼性及びセキュリティが、どの程度の水準であれば妥当であるかと いう社会的共通認識を形成することである。例えば、航空や鉄道等の座席予約システムの障害に よりサービスが停止する場合、システムトラブルの発生頻度、乗客・利用者への影響人数、あるい は障害により被った経済的損失が、どの程度であれば許容できるのかといったリスクの許容度につ いてコンセンサスを形成することが必要である。また、利用者は、より高い信頼性及びセキュリティ 水準を実現するためには相応のコスト負担が発生することを認識し、トレードオフの関係にある信 頼性及びセキュリティ水準とコストの適切なバランスについても共通認識を持つことが重要である。 このエンドユーザ視点の見える化は、同時に企業経営者が情報システム・ソフトウェアの投資判断 を決定する際にも必要となる。 第二は、情報システム・ソフトウェアの発注者（ユーザ企業）の要件の見える化である。特に、レス 削除: 2 つ目 ポンスタイム、バッチ処理の制限時間、あるいはユーザビリティといった情報システム・ソフトウェア の性能や品質に関する要求事項である非機能要件は、誤解されない表現で明確に記述すること が非常に難しく、それを見える化することが重要である。上流工程の要件定義フェーズで何をどの ように見える化する必要があるのか、あるいは、どの水準の情報システム・ソフトウェアを実現しようと しているのかについて、ユーザ企業・ベンダ企業間で共通認識を持つために、非機能要件を見え る化するための手法・方法論やツール等が求められている。また、このような技術・手法・方法論等 を適用した場合の費用対効果についても検討を進め、ユーザ企業・ベンダ企業間で共通認識を 形成する必要がある。 第三は、情報システム・ソフトウェアの開発プロジェクト及び保守・運用フェーズでの“見える化・ 測る化”である。システムライフサイクルの各フェーズにおいて、定量データに裏付けされた科学 的・工学的に信頼のおけるマネジメントを実施し、品質（プロセス品質）を確保することが重要である。 また、第一部の図Ⅰ- ５に示すとおり、品質問題が起きた理由として、「テストが不十分、移行作業 19 削除: 最後 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt に問題」と回答した割合は、2005 年の 21.9％と比べて 2008 年には 41.7％と 2 倍近い値となって おり、近年、テストや移行作業における品質確保が重要な課題となっている。そのため、運用・本番 開始前のデータ移行等も含め、テストや移行作業において定量管理等により品質を高める取組を 強化する必要がある。 削除: ける 削除: が 同時に、この定量管理の結果、完成した情報システム・ソフトウェアの品質（プロダクト品質）との 関連性を明らかにしていくことが、ソフトウェアエンジニアリングの高度化への重要な基礎となる。そ 削除: で のためには定量管理のためのプロセス管理指標とプロダクト品質を測るための評価指標を業界横 削除: 断的で共通に使えるように整備し、さらに、これら指標に関する定量データを収集することで、関係 削除: について、 者が参照できるような目標値（相場観）を業界全体として共有することが必要である。その上で、情 報システム・ソフトウェアの信頼性及びセキュリティの向上のためには、これら相場観に基づく定量 管理の実際の現場での活用を進め、“見える化・測る化”を普及・展開することが重要である。 削除: を その際に、企業あるいは組織毎に利用している作業プロセス名が異なると評価指標や定量デー タの共有もできなくなる点に注意が必要である。これら指標を共通に利用するためには、共通フレ ーム 20078等をベースとした作業プロセスの定義の共通化とその導入促進を行うことが前提とな る。 上記 3 つの視点について、以下の①∼③で具体的に述べることとする。 ① 信頼性・セキュリティの要求水準の社会的共通認識の重要性 第一部で述べたとおり、情報システム障害等の事故を完全に排除し 100％の情報システム の信頼性及びセキュリティの実現は容易ではないという認識に立ち、ビジネス要求あるいは提 供サービス・機能の重要度に応じて、信頼性及びセキュリティが確保されることを社会的共通 認識として持つ必要がある。つまり、すべての情報システム・ソフトウェアに社会の重要インフラ のような高い信頼性及びセキュリティを求める必要はなく、その重要度に応じて適切な信頼性 及びセキュリティを実現することが重要である。 さらに、情報システム・ソフトウェアの信頼性やセキュリティを向上させるためには開発コスト や対策コストが発生するため、信頼性及びセキュリティの確保とコスト低減はトレードオフの関 削除: 限られた経営資源（ヒト、モノ、カネ）に 係にあり、限られた経営資源（ヒト、モノ、カネ）において、信頼性及びセキュリティとコストとの おいて、 適切なバランスを取ることも重要である。 また、同じ業務でも情報システム・ソフトウェアに求められるサービスレベルが全く異なる場 合がある。例えば、日本の銀行の ATM はリアルタイム・オンライン処理が常識であるが、少し 前まで米国ではすべてバッチ処理であったが、米国の多くの利用者の不満は聞こえてこない。 この場合、情報システム・ソフトウェアに求められる信頼性及びセキュリティの要求水準も、そ れにかけるコストも異なってくる。このように、信頼性及びセキュリティとコストのバランスはその 8 共通フレーム 2007（IPA/SEC、平成 19 年 10 月 1 日）： ソフトウェアを中心としたシステム開発及び取引に関わ るすべての人々が企画、要件定義、開発、運用、保守の作業内容を共通に参照できるよう用語や作業内容を標準 化するために、ソフトウェアライフサイクルプロセス（ISO/IEC12207）国際規格に適合して日本で拡張した作業体 系とそのガイドライン 20 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt サービスを享受する社会の要求度合いによって変化するものであり、同じサービスを提供する 情報システム・ソフトウェアであってもサービスを受ける相手の国や地域が変わればそのバラ ンスは変化する。 このような状況において、要求水準に応じた信頼性及びセキュリティが確保されるという社 会的共通認識を形成するためには、まず、情報システム・ソフトウェアの果たす役割を整理し、 ビジネス要求、提供サービス・機能の重要度、あるいは情報システム・ソフトウェアに求められ る信頼性及びセキュリティの客観的な要求水準により情報システム・ソフトウェアを明確に分 類・整理できる枠組みが必要となってくる。このような枠組みは、企業経営者が投資判断を行 うための評価指標としても重要なものである。 しかし、現状ではこのような整理ができる十分な仕組みが提供されていない。例えば、2009 年に経済産業省が公表した“情報システムの信頼性向上に関するガイドライン第 2 版”9の中 で、求められる信頼性・安全性の水準に応じ、情報システムを重要インフラ等システム、企業 基幹システム、その他のシステムの 3 つの区分に分けているが、具体的な分類基準やどのよう な情報システムがどの区分に該当するのかは示されていない。また、2005 年に内閣官房情 報セキュリティセンターが策定した“重要インフラの情報セキュリティ対策に係る行動計画”10で は、重要インフラの定義11と重要インフラ 10 分野において対象となる重要システム例を提示し ているが、客観的な基準は示されていないのが現状である。 さらに、このような要求水準に応じた情報システム・ソフトウェアの分類・整理の枠組みの整 備のみならず、一般利用者に広くサービス提供される情報システム・ソフトウェアに関しては、 具体的にどの情報システム・ソフトウェアがどの程度の重要度や要求水準に分類されるのかと いう社会的な共通認識を持つことも極めて重要である。また、企業内で利用する企業情報シ ステム・ソフトウェアにおいても同様に、ユーザ企業とベンダ企業の双方が納得できる相場観 を共有することが必要である。 こうした枠組みを通じ、社会的共通認識を形成していくとともに、情報システム・ソフトウェア に対する投資が適切に判断され、十分な信頼性及びセキュリティが確保されつつ、無駄なコ ストをかけずに高度情報化社会のインフラの整備を進めていくことが重要である。 ② 機能要件・非機能要件の見える化の重要性 情報システム開発の上流工程（企画プロセス、要件定義プロセス等）において、業務要件の 定義、システム要件の定義や仕様化が不十分あるいは曖昧で開発が円滑に進まないことに 起因する、情報システムの信頼性及びセキュリティを含む品質問題が多発している。その原因 9 情報システムの信頼性向上に関するガイドライン第 2 版（2009 年 3 月 24 日、経済産業省） （http://www.meti.go.jp/press/20090324004/20090324004.html） 10 重要インフラの情報セキュリティ対策に係る行動計画（2005 年 12 月 13 日、内閣官房情報セキュリティセンター） （http://www.nisc.go.jp/materials/index.html） 11 他に代替することが著しく困難なサービスを提供する事業が形成する国民生活及び社会経済活動の基盤であり、 その機能が停止、低下又は利用不可能な状態に陥った場合に、我が国の国民生活又は社会経済活動に多大なる 影響を及ぼすおそれが生じるもの 21 削除: 仕組 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt の 1 つとして、ユーザ企業の業務部門が理解できる要件である“業務要件”と、この業務要件 を受けてベンダ企業が定義する“システム要件”との間に、大きなギャップがあることが指摘さ 削除: 情報システムの関係者が明確にしたい れている。 要件である 約 800 社を対象に 2008 年に実施したプロジェクト実態調査12によると、第一部の図Ⅰ- ５ で示すとおり品質問題が起きた原因は、「テストが不十分、移行作業に問題」が 41.7％でトッ プを占め、次いで、36.7％で「要件定義が不十分」が続いている。この「テストが不十分、移行 作業に問題」の背景には、要件定義が不十分なため下流工程での作業に影響が発生したこ ともあると考えられる。また、5 年前の同様の調査では「要件定義が不十分」が 35.9％でトップ 削除: が 削除: も の原因となっており、要件定義が不十分なことによる品質問題が依然として高い割合で発生し、 削除: の発生 状況が改善されていない現状を示している。 また、上流工程の品質の低さが放置されると、下流工程に進むにつれてその影響度合いは 拡大し、開発工程の手戻りのリスクも高まる。要件定義フェーズでの不具合を修正するコストを 1 とすると、システムテスト・受け入れテストフェーズでは 8∼20 倍、運用フェーズでは 68∼110 倍になるという調査報告13もあり、上流工程の品質の低さが下流工程にいくほど修正コストに 極めて大きな影響を与えるといえる。また、同調査では、要求の誤りによって発生したプロジェ クトの手戻りに費やすコストは、全体の 70∼80％を占めるとされており、十分な要件定義を行 うことが極めて重要であることが分かる（表Ⅱ- １-１を参照）。こうしたことから、要件定義に 10 倍のコストをかけたとしても、システムライフサイクル全体のトータルコストでみると安くなるとも 考えられ、上流工程を重視する日本のシステム開発手法が国際競争力の源泉となる可能性も ある。 表Ⅱ- １-１ 要求の欠陥を修正するための相対コスト 誤りが発見されたフェーズ 要求開発 設計 構築 システムテスト、受け入れテスト 運用 修正のための相対コスト １倍 ２∼３倍 ５∼１０倍 ８∼２０倍 ６８∼１１０倍 （出典） 要求開発と要求管理（日経 BP ソフトプレス、2006.12.11） したがって、信頼性・セキュリティあるいは品質の観点のみならずコストの観点から見ても、 上流工程の要件定義において、業務要件（業務部門が理解できる要件）とシステム要件（情 報システム関係者が明確にしたい要件）とのギャップを埋める取組が極めて重要である。 業務要件については、主にユーザ企業の業務部門が日本語つまり自然言語で記述するた 第２回 プロジェクト実態調査（日経コンピュータ 2008 年 12 月 1 日号特集） 要求開発と要求管理（Karl E. Wiegers 著、田沢恵、溝口真理子訳、宗雅彦監修、日経 BP ソフトプレス 2006.12.11） 12 13 22 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt めに曖昧さが残ったり、ベンダ企業側に業務知識が不足していることにより、ベンダ企業に的 確に業務要件が伝わらなかったりすることも多い。また、ベンダ企業がその要件を解釈して定 義したシステム要件は、IT の専門家ではないユーザ企業の業務部門が自分たちの定義した 業務要件に合致しているかを確認することが困難である。そのため、ユーザ企業が定義する 業務要件定義とベンダ企業が定義するシステム要件定義で作成するドキュメントの記述内容 と記述方法を定義し、双方で使用する「用語」の定義も含め、この両者の溝を埋めるための要 件定義手法や支援ツール等の整備が必要である。 また、近年は、“非機能要件”の抜け・漏れによる情報システム稼働後のシステムトラブルや 開発工程の手戻りの発生が大きな課題として捉えられている。業務実現に必要な機能に関す る要求事項や要件を具体的に提示できる“機能要件”とは異なり、システムの具体化が進んで いない要件定義フェーズにおいては、情報システムの性能、信頼性、拡張性、運用性、保守 性、あるいはセキュリティなど機能要件以外の全般的な要求である“非機能要件”を明確化す ることは、かなり困難な作業である。 情報システム・ソフトウェアの信頼性及びセキュリティを効率的に確保するためには、上流工 程における、ユーザ企業・ベンダ企業間の密接なコミュニケーションを前提とした要件定義が 不可欠であり、特に情報システムの非機能要件に係る双方の合意に基づく品質水準の決定 が極めて重要である。また、ユーザ企業は“ベンダ企業丸投げ”とならないように、実現したい 機能・サービスといった“機能要件”とともに“非機能要件”も明確化する一方で、ベンダ企業 は“顧客の言うとおりに作っただけ”とならないよう、これら機能・サービスを提供するための最 適な実現手法を提案する役割を果たすべきである。さらに、一次請負のベンダ企業が協力会 社等に丸投げするなど、“ベンダ企業・ベンダ企業間の丸投げ”により要件定義が曖昧となる 問題も指摘されており、ベンダ企業が協力会社等に発注する要件についても明確化すること が重要である。 このように、情報システムの非機能要求に関するユーザ企業・ベンダ企業間の意識のズレ に起因する問題を共有し、発注者であるユーザ企業から要求される“非機能要求”のレベル の見える化と、ユーザ企業・ベンダ企業間で確認する手法やツールを整備することが喫緊の 課題である。 ③ 定量管理による効果と信頼性の定量管理に関する課題 2004 年の設立以来、IPA/SEC が提供する情報システムの開発プロジェクトを定量的に管 理する手法や参考となるソフトウェア開発データ白書の提供をはじめ、社団法人日本情報シ ステム・ユーザー協会（以下、本稿では JUAS とする）のソフトウェアメトリックス調査など、定量 的なプロジェクト管理に関する様々な取組が実施されてきた。 その取組の効果については、先に述べた約 800 社を対象としたプロジェクト実態調査が参 考になろう。図Ⅱ- １-１に示すとおり、この調査によると、5 年前の前回調査と比較して、 23 削除: い 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt QCD14を定量的に管理している企業の比率が 2 倍以上に達している。調査票では定量管理 の手法までは聞いていないため、定量管理の実施レベルや手法は千差万別であるが、少なく ともプロジェクトを定量管理しようという機運が高まっていることは事実であるといえる。 29.9% 30% 18.0% 20% 14.8% 10% 12.8% 8.7% 5.1% 0% 2003年 2008年 2003年 2008年 2003年 2008年 成果物を 定量的に把握する 管理手法を導入 コストを 定量的に把握する 管理手法を導入 進捗を 定量的に把握する 管理手法を導入 （出典）日経コンピュータ（2008 年 12 月 1 日号）：第 2 回プロジェクト実態調査（平成 20 年 8 月∼9 月） 図Ⅱ- １-１ プロジェクトの品質・コスト・納期を定量的に管理している企業の割合 さらに、図Ⅱ- １-２に示すとおり、QCD を定量管理する手法のうち、どれか一つでも導入し た企業のプロジェクトの成功率は、平均成功率より 15 ポイント近く高い 45.6％であり、定量管 理を一切導入していない企業のプロジェクト成功率は、平均成功率より 7 ポイント近く低い、 24.3％であった。このように定量管理の手法を導入した企業のプロジェクト成功率は、導入し ていない企業の 2 倍近くに達し、定量管理がプロジェクトの成否に如何に重要であるかが伺え る。 また、図Ⅱ- １-３に示すとおり、品質、コスト、納期の各々についても、何らかの定量管理を 導入している企業の成功率が高くなっている。 14 「成果物（ソフトやドキュメントなど）を定量的に把握できる管理手法を導入している」「コストを定量的に把握でき る管理手法を導入している」「スケジュールの進捗を定量的に把握できる管理手法を導入している」 24 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 何らかの定量管理の手法を導入している企業の成功率は、定量化をしない企業の２倍程度になる。 何らかの定量管理の手法を導入している（68件） システム開発プロジェクトの平均成功率 （有効回答212件） 成功 45.6% 失敗 54.4% 成功 31.1% 失敗 68.9% 定量管理はしていない（144件） 成功 24.3% 失敗 75.7% （出典）日経コンピュータ（2008 年 12 月 1 日号）：第 2 回プロジェクト実態調査（平成 20 年 8 月∼9 月） 図Ⅱ- １-２ 品質の順守率との相関 コストの順守率との相関 （有効回答212件※） 80% 成功率と定量管理手法の相関 （有効回答438件） 80% 70.6% （有効回答438件） 80% 68.5% 63.2% 60% 納期順守率との相関 67.1% 60.6% 60% 51.9% 60% 54.6% 48.1% 43.1% 40% 40% 40% 20% 20% 20% （※品質は実際に利用してから判断するため、回答数が他２図より低い） （出典）日経コンピュータ（2008 年 12 月 1 日号）：第 2 回プロジェクト実態調査（平成 20 年 8 月∼9 月） 図Ⅱ- １-３ 品質、コスト、納期の順守率と定量管理手法の相関 25 定量管理は していない 何らかの定量管理の 手法を導入している 0% 平均順守率 定量管理は していない 何らかの定量管理の 手法を導入している 0% 平均順守率 定量管理は していない 何らかの定量管理の 手法を導入している 平均順守率 0% 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt さらに、JUAS の調査で品質基準の有無と欠陥率の関係を調べたところ、品質目標を持っ ていたプロジェクトと目標がないプロジェクトでは発生欠陥率において平均 0.5 件／人月の差 があった。品質基準を持っていないプロジェクトの欠陥率は、持っているプロジェクトの 1.9 倍 となっており、明らかに品質基準を持っているプロジェクトの品質が高いということが見て取れ る（図Ⅱ- １-４を参照）。 1.20 件数 121 120 100 1.00 0.99 欠陥率 140 94 0.80 80 0.60 60 0.51 0.40 40 件数 平均欠陥率 0.28 0.20 20 3 0.00 0 有り 無し 記入なし （出典） ソフトウェアメトリックス調査 2008（JUAS、2008 年 6 月） 図Ⅱ- １-４ 品質基準有無―欠陥率 このように開発プロセスにおける定量管理の品質（プロセス品質）と最終的に完成した情報 システム・ソフトウェアの品質（プロダクト品質）の関連性を明らかにし、定量管理の精度を上げ ていくためのソフトウェアエンジニアリングの高度化とその普及展開を図ることが、ますます重 要となってきている。しかし、プロセス品質の定量的な管理手法については、各社のノウハウと なっていることが多いため、各社が独自の管理指標を用いて様々な方法論を適用しているの が現状である。 一方、プロダクト品質については、現在、ソフトウェア製品の品質の要求・測定・評価に関す る国際標準である ISO/IEC159126 シリーズと 14598 シリーズの統合・改訂作業が進められ、 ISO/IEC25000 シリーズ（SQuaRE16）を策定中である。ここで定義されている品質メトリクスや 測定・評価方法については、情報システムの開発現場への適用結果をフィードバックして、よ り実践的なものに精度を上げていくことが求められている。 15 ISO (International Organization for Standardization)：国際標準化機構。工業規格を国際的に標準化す る機構。また、それが定める工業規格。アイエスオー。 IEC (International Electrotechnical Commission)：国際電気標準会議。電気製品の規格や測定方法を定め る。日本の JIS 規格も IEC の規格に従っている。1906 年設立。本部はジュネーブ。（出典：大辞林、三省堂） 16 SQuaRE (Software product Quality Requirements and Evaluation) 26 書式変更: フォント : 9 pt 第二部 第 1 章 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 情報システム・ソフトウェアの品質を含む広い意味での信頼性（ディペンダビリティ）を定量 的に管理するためには、プロセス品質あるいはプロダクト品質のいずれにおいても、まず、信 頼性の水準を測るための客観的な評価指標（メトリクス）を業界全体として共有することが必要 不可欠である。 しかし、現在のところ、情報システム・ソフトウェアの信頼性を客観的に定量評価するための 仕組みが確立されておらず、このような明確な基準がないため、情報システム・ソフトウェアの 削除: 仕組 実装において、どこまで投資できるかの判断が難しくなっている。システム要件としての定量 的な信頼性に対する基準作りやリスク見積もり、それに見合うコストを判断する手法や基準等 の制定が必要である。 また、既存の様々なソフトウェアメトリクス、定量データ、あるいは管理指標、国際標準等をど のように利用して定量管理を実施するのかについての議論や管理指標自体の整理・体系化も 同時に進める必要がある。 コラム フェージング契約による落とし穴 【問題例】 A ベンダ企業は新規の情報システム開発案件を受注し、工程を区切るフェージン グ契約を適用し、企画・要件定義工程を準委任契約で、それ以降を請負契約で締 結。しかし、結果的に A ベンダ企業は、開発工程・テスト工程の請負契約で多額の 損失を出してしまった。 お客様と一緒に実施した要件定義工程で、お互いにリスク管理や定量管理を実 施しておらず、A ベンダ企業は要件定義後に開発工程・テスト工程の正確な見積も りができなかったためである。ユーザ企業に責任がある準委任契約であっても、ベン ダ企業は責任を持って定量管理を実施すべきところ、それを怠ったことが問題であ った。 （２）“見える化・測る化”を推進するための具体的な取組 前節で述べたとおり、信頼性及びセキュリティを“見える化”し、情報システム・ソフトウェアの信頼 性及びセキュリティを確保するためには、標準化された客観的な基準とそれに基づく評価制度を整 え、それらを社会基盤として容易に活用できる環境の整備が極めて重要である。 この信頼性及びセキュリティを客観的に評価するための枠組みのコンセプトを図Ⅱ- １-５に示す。 本研究会では、このコンセプトにおいて個別に取り組むべき具体的課題の検討を重ねてきた。下 記に示した課題は、経済産業省、IPA、あるいは JUAS 等の各団体・組織で既に取組に着手して いるものもあるが、それら取組を含めて、今後実施すべき取組の方向性を示す。 27 削除: これまでに 第二部 第 1 章 （２） 信頼性・セキュリティを客観的に評価する枠組（一般的な情報システムの場合） 信頼性・セキュリティ要求水準の社会的共通認識の形成 サービスレベル 許容リスク 必要なコスト 利用者 •信頼性・セキュリティの要求水準による分類の定義 •実際の情報システムの分類及び要求される信頼性・セキュリ ティ水準と許容リスク・必要コストとの関係の明確化 •実現した信頼性・セキュリティレベルを立証できる仕組 •社会的共通認識を形成するアプローチ 要求 立証・開示 サービス提供 信頼性・セ キュリティ 要求水準 ユーザ企業 受発注 ベンダ企業 要求 実現した 信頼性・セ キュリティ レベル 実現 開発・保守・ 運用フェーズ での定量評価 評価 第三者評価機関 ベンチマークによ る自己評価 コミュニティ等 評価の仕組 •標準化された基準に基づき、評価 機関により評価 •オープンな標準に基づいたソフト ウェア適合性・相互運用性等の評価 技術・体制整備 信頼性・セキュリティを客観的に評価できる仕組・体制の整備 •評価フレームワーク（要求水準と実現した信頼性レベルによる評価） •信頼性レベルの客観的評価指標の策定（システムライフサイクル全般） •既存のソフトウェアメトリクスの整理・体系化 •品質作り込みのための評価指標（開発フェーズが中心） •障害対策分析による評価指標（運用・保守フェーズが中心） •信頼性に係る要件定義の明確化（非機能要求の明確化） •システムLSIセキュリティ評価体制の整備 •電子認証に関するガイダンス 実装技術の確立／保守・運用技術の高度化 価格体系のあり方 •信頼性ガイドラインの活用 •信頼性要求水準を実現するための推奨技術・技法等の参照 •障害対策の実践・普及 •信頼性・セキュリティとコスト （価格体系）に関する共通認識 の形成 図Ⅱ- １-５ 信頼性及びセキュリティの客観的評価のコンセプト ① 信頼性及びセキュリティの要求水準の社会的共通認識の形成 １） 要求水準による分類の定義と共通認識の形成 情報システム・ソフトウェアの信頼性及びセキュリティの検討に当たっては、一般国民の 目線で分かりやすい説明が求められる。利用者の視点に立った時、情報システム・ソフトウ ェアの信頼性及びセキュリティは、実際にトラブルが発生した場合に、利用者や社会生活 等に対してどれくらいの損害や影響を与えるのかという観点で信頼性及びセキュリティの要 求水準を説明することが必要である。この要求水準については、企業経営者が情報システ ム・ソフトウェアに対して投資判断を行う際にも客観的な判断基準として必要となる。 このような信頼性及びセキュリティの要求水準を基に、情報システムの信頼性水準を 3∼ 5 つ程度に分類（システムプロファイリング）し、この分類に応じて情報システムが保持すべ き信頼性及びセキュリティについて、利用者が許容すべきリスクと必要なコストとの関係も含 めて、社会的なコンセンサスを形成することが大切である。 IPA と JUAS が共同で取り組んでいる“重要インフラ情報システム信頼性研究会”におい て、重要インフラ事業者が自社の事業活動における情報システムの位置付けを把握・認識 するため信頼性水準のレベル分け（システムプロファイリング）の手法を検討している。ここ では、人命への影響度（システム故障により何らかの形態で人命への損害を与える影響度）、 28 第二部 第 1 章 （２） 経済的な影響度（各事業者の機会損失を含めてシステム故障が引き起こす経済的損失の 影響度）、及び公共性への影響度（システム故障が引き起こす国民への公共サービス提供 面からの影響度）などの要素を基に、情報システムを 4 つのタイプに分類している（図Ⅱ１-６を参照）。 システムプロファイリングの実際の適用に際しては、レベル分けの分類数やレベルを判断 するための要素等については、事業分野など活用主体毎に異なると考えられるため、個々 の事業分野に最適なプロファイリング手法の検討を急ぐとともに、これを踏まえた社会的共 通認識の形成を含め、それが社会に受け入れられて機能していく環境を整備していく必要 がある。 したがって、産業界のコンセンサスを得るために、各企業独自に実施しているプロファイリ ングや他の検討主体の動き17も含めて、産業界全体で協力し継続的な検討と実践的なシス テムプロファイリングの策定を行うことが求められる。 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 17 例えば、情報システムの信頼性向上に関するガイドライン第２版（経済産業省、平成 21 年 3 月 24 日）の P.3 の “情報システムの分類”などが挙げられる。 29 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 第二部 第 1 章 （２） 信頼性・セキュリティ 要求水準 【基本的な考え方】 情報システムがどの要求水準にあるか を４つのタイプに分類して考える システムプロファイリング具体例① 分類分析 （影響度・リスク） システムの カテゴライズ 想定されるシステムプロファイルと 事例 ソフトウェア不具合に 起因した影響度合い （人的損害、経済損失 等リスクなど）評価 Type IV 人命に影響、甚 大な経済損失 高信頼性に加え安全性が求められる情報 システム（航空管制、医療制御、宇宙ロ ケット制御、建築構造計算、医療関連機器 制御、救急医療NWなど） 人的損害のケースあり 影響範囲が甚大 高 中 経済損失 レベルあり 低 人命損害甚大 経済損失甚大 Type III 社会的影響が極 めて大きい 世の中で基本的に高信頼性（社会的影響 極大の回避）が求められる（輸送、通信、 金融・証券、プラント制御などの重要インフ ラ） Type II 社会的影響が限 定される 個別事業の普及範囲が大きいインフラ系 で基本的信頼性（影響予測可能）が求め られる（放送、行政、水道、建設など重要 インフラ） Type I 社会的影響が殆 ど無い 個別事業内でのインフラ系で あるが、法的 な紛争な どで信頼性の強化が求められる （事業サービスに直結する事業者内インフ ラ）（国民サービス、給付系サービス、企業 間取引など） システムプロファイリング具体例② ①人命に影響を与 える可能性 ②損害金額の 予測 ③社会的影響 分類 要因 Type Ⅳ 死亡事故 １０億円以上 重大な影響を社会に与える Type Ⅲ 重大災害 １０億円以下 多くの人に迷惑をかける、ある いは特定の個人に大きな心理 的影響を与える Type Ⅱ 軽微 １億円以下 軽微 Type Ⅰ ほとんどなし １千万円以下 ほとんどなし リスク、コスト等に関する共通認識 分類 情報システム例 想定されるリスク コスト Type Ⅳ ○×システム XXXXX ○～○倍 Type Ⅲ ○○システム XXXXX ○～○倍 Type Ⅱ XXシステム XXXXX ○～○倍 Type Ⅰ □□システム XXXXX １ 図Ⅱ- １-６ システムプロファイリングの考え方（コンセプト） 30 第二部 第 1 章 （２） 図Ⅱ- １-６の IPA と JUAS で検討しているシステムプロファイリングは、事業者自体が自 社の情報システムの信頼性及びセキュリティ向上のために活用することを想定しているが、 重要インフラや一般国民に広くサービスを提供する事業者は、更に一歩進んで利用者に 対して、想定されるリスクや必要なコストとの関係も含めて、信頼性の要求水準や実現レベ ルを説明することが求められている。 ２） 実現した信頼性レベルを立証できる仕組み サービス提供事業者にとって、情報システムの信頼性・セキュリティ水準を分類したシス 削除: 仕組 削除: は テムプロファイリング結果及びリスクなど信頼性・セキュリティに関する具体的な情報を事前 に公表しておくことは、情報システム障害の際にメディアに対する担保としても機能する。そ のため、この信頼性及びセキュリティ水準に照らすことで開発側・運用側で実施状況を立証 できるような枠組みが必要であり、既に幾つかの取組が実施されている。 例えば、JUAS では、平成 20 年 6 月に UVC（User Vender Collaboration）研究プ ロジェクトⅡ報告書「非機能要求仕様定義ガイドライン」で、信頼性を含む非機能要求につ いてユーザ企業がどのように定義し、システム開発のどの工程で何を確認すべきかをモニ タリング・ガバナンスするためのガイドラインを策定している。また、現在、新規に策定中のシ ステム及びソフトウェア保証規格（ISO/IEC15026）では、情報システムの信頼性、セキュリ ティ、あるいは性能など品質の観点で、その正しさを第三者が保証する仕組み18、リスク抑 削除: 仕組 制の完全性水準、あるいはライフサイクルで実現するためのプロセスの組み立て方などの 体系化が行われている。 各事業者は、このような取組を参考にしながら自社の情報システム・ソフトウェアの信頼性 及びセキュリティ水準を説明できる環境と体制を整備することが重要である。具体的には、 各事業者（サービス提供者）はサービス利用者に向けてシステムリスクの周知を行うとともに、 さらにはシステム障害時の代替手段の整備や提供状況に関しても利用者に分かりやすく情 報提供を行い、利用者がこれら情報を踏まえた上で、納得してサービスを選択できる環境 を整備することが必要である。例えば、このような信頼性・セキュリティ水準に関わる情報を 公開するタイミングや周知する内容等に関するガイドラインを、情報開示がセキュリティ（安 全性）確保に与える影響も考慮しつつ、策定することなども求められる。 また、このような仕組みは、情報システム・ソフトウェアの開発・運用に当たって判断に苦 削除: の 削除: 仕組 慮するエンドユーザの経営層に自社の情報システム・ソフトウェアの信頼性及びセキュリティ 水準を理解してもらうためにも有効である。 なお、第三者機関による評価制度については、本節⑥の“評価制度の在り方”で記述す 削除: ⑤ る。 18 例えば、発注者の品質要求が明示されている前提で、システムのコンポーネントを提供する供給者がその品質 要求について、どのような条件かつ根拠で品質要求が満たされているかを発注者に示す仕組み 31 削除: 仕組 第二部 第 1 章 （２） ３） 社会的共通認識を形成するアプローチ 上記 1）∼2）で述べた取組を基に、情報システム・ソフトウェアの信頼性及びセキュリティ に関する社会的共通認識を得るためには、単に情報システムのタイプ分け基準などの仕組 みを構築するにとどまらず、信頼性及びセキュリティの要求レベルとリスクとコストについて 多くの一般利用者、ユーザ企業の経営者、開発現場といった様々な視点で納得を得られる ような相場観を、共通認識として形成する必要がある。 そのためには、官民協力して、以下の取組を実施すべきである。 • 情報システムの障害発生時に、情報のオープン性を確保するために、各事業会社、 あるいは然るべき中立機関等が、速やかに原因や対応状況に関する情報を提供し、 エンドユーザも含め関係者が情報共有できる環境や体制を整備する。情報提供に 際しては、開示タイミング・内容、あるいは調査中で不確かな経過情報をどの程度提 供するのかなどについて、十分な検討を行う必要がある。まずは情報共有が重要で あり、経過情報など開示した情報を訂正した場合でも、事業会社が過度な責めを負 わないことを考慮する必要がある。 • 情報システムの障害の可能性を完全に排除することは容易ではないという“事故前 提社会”の考え方を踏まえて、利用者の自己責任の在り方についても検討する必要 がある。その際には、利用者にサービス提供に係る情報システムの信頼性及びセキ ュリティに関する情報を十分に提供することが前提となる。 • 一般消費者に対して、信頼性及びセキュリティの要求レベルとリスクとコストに関する 社会的共通認識を形成することは極めて難しい。海外のサービス状況なども含めて、 一般消費者が理解するために必要な情報を分かりやすく提供する取組が必要であ る。 • 一般消費者に対しては、情報システムに関しても信頼性・セキュリティレベルが高く、 料金も高いサービスと普通のサービスといった信頼性・セキュリティレベルの差によ る選択肢を提供するなど、サービス提供方法に関する検討も必要である。 ② 信頼性の客観的な定量評価の枠組み １） 評価フレームワーク（要求水準と実現した信頼性レベルによる評価）の策定 情報システム・ソフトウェアの信頼性及びセキュリティを評価するためには、信頼性及びセ キュリティとコストのバランスを考慮することが重要である。IPA と JUAS が実施している“重 要インフラ情報システム信頼性研究会”では、図Ⅱ- １-７に示すとおり、信頼性及びセキュリ ティの要求水準と実現する信頼性及びセキュリティレベルの 2 次元で、信頼性及びセキュリ ティを客観的に評価するフレームワークの考え方を提唱している。 32 削除: 仕組 第二部 第 1 章 （２） 信頼性・セ キュリティ 要求水準 システムプロファイリングで４つにタイプ分け どの情報システムがどのタイプに該当する かの相場観の形成 分類 高 要求 水準 低 実現した 信頼性・セ キュリティ レベル 要求水準と実現した信頼性レベルによる 評価フレーム 要求水準の実施状況の評価 情報システム例 Type Ⅳ 高 ○○システム、 ××システム、 Type Ⅲ ○○システム Type Ⅱ ○○システム Type Ⅰ ○○システム 評価結果の プロット Type Ⅳ 強化すべ き対策が Type Ⅲ ある領域 要求水準 過大投資 の可能性 がある領 域 Type Ⅱ 低 Type Ⅰ 0 50 信頼性レベル 開発フェー ズでの定量 評価 管理すべきメトリクスとその目標値を提示 目標値の妥当性／相場観の形成 高 評価指標 要求水準 点数化 100 「重要インフラ情報シ ステム信頼性研究 会」の障害対策分析 の検討対象 低 ① 障害対策分析チェックリスト（評価指標） 開発メトリクス 目標値 Type Ⅳ XX密度 １０ XX率 ８０％ XX件数 ５件／KLOC … … ② 信頼性ガイドラインの評価指標 Type Ⅲ Type Ⅱ Type Ⅰ ③ ソフトウェアメトリクス調査（JUAS） ④ ソフトウェア開発データ白書（IPA/SEC） … レベルを測るための共通のものさし（評価指標）は様々 図Ⅱ- １-７ 評価フレームワーク 上記の“重要インフラ情報システム信頼性研究会”では、信頼性及びセキュリティレベル を測るための客観的な評価指標について幾つかの方法論を提示しているが、他にもソフト ウェアメトリクスや開発フェーズにおける管理指標など、既存の方法論や取組も実施されて いる。さらに、運用・保守プロセスにおいてサービス提供者と利用者の間の IT サービス機 能や範囲、品質、性能などを “見える化”するコミュニケーション・ツールである SLA(Service Level Agreement)/SLM(Service Level Management)を開発プロセスに 適用する取組も実施されている19。また、情報システムの構成要素（製品）が要求水準を満 たしていることを保証する仕組み（システム保証）についても新たな国際標準 削除: 仕組 （ISO/IEC15026）の策定が進んでいる。 信頼性及びセキュリティに関する社会的コンセンサスを得るためには、標準化された基準 に基づき信頼性を評価する共通のものさしや仕組みと、どの程度のレベルを実現するかと 削除: 仕組 いう相場観の形成が急務である。 19 平成 19 年度ソリューションサービスに関する調査報告書Ⅱ SLA 適用領域の拡大に関する調査報告書 （IS-08-情シ-5） （(社)電子情報技術産業協会・ソリューションサービス事業委員会、2008 年 3 月発行） 33 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 第二部 第 1 章 （２） ２） 信頼性及びセキュリティレベルを測定するための客観的な評価指標の策定 前述したとおり、信頼性及びセキュリティ向上に資するプロセス品質に関する定量管理手 法や定量データの収集は、現状では、幾つかの組織や団体が独自に様々な取組を実施し ている。同じようなソフトウェアメトリクスのデータを取得しているが、その定義やアンケート調 査票での設問の仕方が異なっており、客観的な共通のものさしが存在していない。実際に、 取得された定量データも相互に利用ができないという課題が指摘されている。 しかし、それぞれの組織や団体は、既に各々の目的や利用方法などに合わせてソフトウ ェアメトリクスのデータを収集・分析しており、ソフトウェアメトリクスを突然 1 つの共通のものさ しに揃えるというのは現実的ではない。したがって、プロセス品質に関しては、まずは、既存 のソフトウェアメトリクスの定義の整理・体系化を実施し、各組織・団体で取得されたソフトウ ェアメトリクスの定量データが相互利用できる環境を整備する必要がある。経済産業省では、 “ソフトウェア・メトリクス高度化検討連絡会”を開催し、様々な観点で集められている多様な 定量データや各社が個別に取り組んでいるソフトウェアメトリクス（管理指標）等を、信頼性・ セキュリティや品質向上のために活用できるように整理・体系化を行い、国際動向も踏まえ た標準化について検討を行っている。 また、プロダクト品質に関しては、既に ISO/IEC25000 シリーズ（SQuaRE）の策定が進 んでいるが、国内の既存の取組や産業界の実状を踏まえた上で、産学連携してより実践的 な品質メトリクスの実証を行い、国際標準へ貢献していくことが求められている。 国際標準化については、これらソフトウェアメトリクスの整理・体系化の取組を開始する段 階から、産官学で連携して、そのための体制を整えることが必要である。 さらに、具体的な相場観の形成には、定量データを収集しベンチマーキングを実施する とともに、信頼性及びセキュリティレベルを測る評価指標の具体的な目標値を設定し、相場 観を形成することが重要である。その際には、実際のプロジェクトデータや事例を基に評価 基準を策定するべきである。 例えば、重要インフラに関しては、IPA と JUAS が主催する“重要インフラ情報システム 信頼性研究会”で、目標値に基づいた定量的品質コントロールメカニズムの検討を行って いる。この研究会では、実際に情報システム・ソフトウェアの開発フェーズで追跡すべきプロ セスと測定すべきメトリクス（管理項目）を定め、そのメトリクスの取るべき目標値（共通リファ レンス）を設定する品質作り込みのための評価指標の策定を検討したり、重要インフラ情報 システムの障害事例や情報セキュリティ障害事例の原因を分析し、その対策を類型化して チェックリスト形式の評価基準を設定する障害対策分析による評価指標の策定などを行っ ている。 また、上記の“重要インフラ情報システム信頼性研究会”では、重要インフラシステムの評 価指標を別の角度から検討している。情報システムの評価をシステムそのものの稼働率（例 えば、99.999％（5 分停止／年）以上）で評価し、情報システムが止まらないことばかりに注 力するのではなく、何回業務が停止するのか、あるいは停止した際でも規定した時間内で 34 削除: を実施 第二部 第 1 章 （２） 復旧することが重要であるという発想の転換が必要である。同研究会では、これらを測る評 価指標として、稼働品質率と顧客満足度という評価指標の策定を進めている（表Ⅱ- １-２を 参照）。 削除: 表Ⅱ- １-２ 重要インフラシステムの評価指標の内容（例） 大区分 評価項目 評価式 評価 評価値の例 稼働率 稼働率 実績稼働時間／計画稼 1 に近いほ 99.999％（5 分停止／年） 働時間 ど良い 以上など 稼働品質率 業務停止回数 規定時間外停 顧客満足度 業務停止回数／年 規定時間以上停止した 0 に近いほ 基幹業務システムは 0.06 ど良い 件／年など 0 に近いほ 15 分以上停止した回数／ 止回数 回数／年 ど良い 年など 規定時間内応 規定内応答回数／全応 1 に近いほ 300 件／分の入力で、2 秒 答遵守率 答回数 ど良い 以内の応答率が 95％など お客様迷惑度 お客様に迷惑をかけた 0 に近いほ 指数 回数×重要度／年間 ど良い ユーザ満足度 品質、費用・生産性、納 個別に設 期、マナー、投資効果で 定 評価する （出典）JUAS の資料を基に加筆修正 いずれの取組においても、現場で管理されているメトリクスのデータあるいは障害の原 因・対策を、業界横断的に継続して蓄積・分析することが極めて重要であり、今後、官民で 連携して共有体制を構築すべきである。 ３） 信頼性に係る要件定義の明確化（非機能要件の明確化） 信頼性及びセキュリティに係る非機能要件を明確にするために、ユーザ企業・ベンダ企 業間で確認する手法やツールの整備が必要である。現在、経済産業省では、非機能要求 グレード「ユーザビュー検討委員会」において、ベンダ企業 6 社が中心となった検討会が策 定した非機能要求項目一覧表（項目ごとに 6 段階の実現レベルを表記）20を、ユーザ企業 及びベンダ企業双方で評価を実施している。この非機能要求項目一覧表に対する改善点 や内容充実のためのフィードバックを行うとともに、ユーザ企業・ベンダ企業間の共通認識 形成を支援するツールとしての有効性の机上検証を行い、その有効性を確認した21。 20 システム基盤の発注者要求を見える化する非機能要求グレード検討会（略称：非機能要求グレード検討会） （http://www.nttdata.co.jp/nfr-grade/） 21 非機能要求グレード「ユーザビュー検討委員会」報告書∼有効性評価編∼（経済産業省、2009 年上半期公開 予定） 35 削除: 内 削除: オンライン平均応答時間 第二部 第 1 章 （２） 今後は、要件定義フェーズや RFP22など実際の利用シーンにおいて、非機能要求項目 一覧表等を用いて信頼性及びセキュリティの要求水準も含む非機能要求項目を確認する 評価プロジェクトを行い、共通認識形成の支援ツールとしての完成度を高める必要がある。 また、本非機能要求項目一覧表を含む支援ツールは実地検証による有効性を確認した上 で、官民協力して広く普及展開を図るべきである。ユーザ企業・ベンダ企業間で共通認識 を得た非機能要件については、受注側が責任をもって実現することとなるため、システム構 築の上流工程において、ベンダ企業が具体的にその内容について文書化し、ユーザ企業 との間で明確な合意をとる必要がある。 また、組込みソフトウェアの開発においても、上流工程での非機能要件の定義が曖昧で システム品質へ影響することが問題となっている。そのため、組込みソフトウェア以外の情報 システムと同様に非機能要件を明確に定義するための取組が必要である。 ③ 価格体系の在り方 １） 信頼性及びセキュリティとコスト（価格体系）に関する共通認識の形成 サプライチェーンやサービス連携などネットワーク化による複数の情報システムの連携の 増加、プログラム規模の大規模化、複数のベンダ企業による階層的な開発体制などにより、 潜在するリスク要因や脆弱性を洗い出すために、より多くのコストと時間が必要になってきて いる。しかし、情報システム・ソフトウェアの信頼性、セキュリティ、品質等に関しては、それを 深掘りしてもその価値を認めてもらいにくいという問題が存在する。特に、信頼性及びセキ ュリティを確保するコストは、脆弱性に対処するための機能追加等の明示的なコストだけで なく、品質管理の強化や試験結果の提示などの管理コスト等も含めたものとなる。このように、 信頼性及びセキュリティ確保に係る様々なコストを勘案した上で、信頼性及びセキュリティ の要求水準と必要なコスト・時間に関する標準的な価格体系について、業界全体でコンセ ンサスを得ることができる共通認識の形成が求められている。 このような標準的な価格体系やコスト見積もり方法をベースに、ベンダ企業の間で適切な 市場競争が行われることで適正な相場観が形成される。その結果、情報システムの開発コ ストが不当に高止まりしたり、行き過ぎた低価格化が進んだりすることを防ぎ、適切な経済活 動が可能な産業構造の形成にもつながる。 この標準的な価格体系に関する共通認識の形成は、例えば、一企業内での取組からバ リューチェーンを構成する企業群、事業分野の企業群に広げるなど、実態に則した価格体 系の形成が重要である。 また、信頼性やセキュリティ向上に費やすコストは、想定できる経済的損失との関係を見 るだけでなく、その結果、波及する企業価値向上あるいは経済価値の観点も考慮すること が大切である。 22 RFP (Request for Proposal)：システム開発時に、使用者側が必要とする性能を満たす設計案の提出を開発 側に求めること。また、その仕様書。提案依頼書。提案要求書。（出典：大辞林、三省堂） 36 書式変更: フォント : 9 pt 第二部 第 1 章 （２） ④ 実装技術の確立 １） 情報システムの信頼性向上に関するガイドラインの高度化 情報システムの信頼性向上に関するガイドライン（以下、信頼性ガイドラインという）は、社 会的にある程度普及し、モデル取引・契約書の策定や政府調達における活用など信頼性 向上に対して一定の効果があった。しかし、経営者が読むにはやや詳細すぎるが、情報シ ステムの企画・要件定義・開発から保守・運用の担当者には、具体性に欠けるという指摘が 多かった。今後は、信頼性ガイドラインの実効性向上の観点において、何を（What）に加え て、どのように（How）の部分で多様な実施例等を引用するなど実践的なガイドに仕上げて いく必要がある。利用者からのフィードバックを反映しつつ、継続的に信頼性ガイドラインの 改訂作業を行うべきである。 また、信頼性ガイドラインの遵守状況を確認するための評価指標についても、ガイドライ ンの改訂に合わせて、より利便性が高いツールとなるように見直しを実施する必要がある。 ２） 要求水準を実現するための推奨技術・技法等の参照 これまで情報システムの信頼性及びセキュリティの要求水準とそれを客観的に評価する ための仕組みについて述べてきたが、実際に要求水準を実現するための方策も重要であ る。例えば、IPA と JUAS の重要インフラ情報システム信頼性研究会における、定量的な品 質コントロールを効果的に実施するための具体的かつ現実的な実践ガイドの検討、あるい は IPA/SEC における発注する側（ユーザ企業）と開発する側（ベンダ企業）との間で起こる 誤った理解を防ぎ、認識のずれを見つけ出すためのコツ（工夫）や留意点をまとめた発注 者ビューガイドラインの策定など、信頼性向上に資するソフトウェアエンジニアリングの高度 化に係る取組が実施されている。また、このような技術の利用方法や応用方法等を分かり やすく体系化し、広く活用される環境を整備することも必要である。 ３） 企画・要件定義／開発（設計・実装）における信頼性・セキュリティ確保 一般にシステム構築においては機能要件を満たすことが優先され、非機能要件であるセ キュリティ要件は、どうしても後回しになりがちといえる。しかし、セキュリティを確保するため には、システムの深部、細部に手を加えることが効率的であり、開発コストの低減に対しても 効果が高いため、構築プロセスの初期フェーズで十分な検討を行うことが合理的である。セ キュアなハードウェア（セキュアチップを実装した機器）やプラットフォーム（セキュア OS の採 用、SSL アクセラレータ等）の選定、共通ソフトウェアモジュールとしてのセキュリティ機能の 組込、開発プロセスのマイルストーン時点でのセキュリティ検査の実施、セキュリティ上の問 題を抱え込まないようセキュアコーディングの徹底等、設計・実装時においてセキュリティを 確保するための配慮を徹底すべきである。また、実際にこれら実装された機能やアーキテク チャ等を客観的に評価・検証する方法についても検討する必要がある。 37 削除: 仕組 第二部 第 1 章 （２） また、情報システム・ソフトウェアが社会の“インフラの中のインフラ”となるに従い、これま で情報システムに直接関わることがなかった一般の人々も、情報システム・ソフトウェアを利 用する機会が増えてくる。例えば、ユーザインタフェースに関する一貫したポリシーのもと、 開発者のスキルに依存せず、ユーザにとって使いやすい共通的な画面デザインや操作方 法などを実現しないと、ユーザの誤操作などによるトラブルに発展する可能性が増えるとい われている。このような IT に詳しくない人々が戸惑いやストレスなく自由に情報システムを使 い、必要な時に必要な情報にアクセスしたり、間違いのない正確な情報を送ったりできるよう、 画面デザイン、操作ボタンの配置・操作方法なども含め、情報システム・ソフトウェアのユー ザビリティを確保するための取組を強化すべきである。 これまでの情報システム・ソフトウェアの障害事例を分析すると、バックアップシステムへ の切り替えが動作しない、ネットワーク障害、あるいはインターネットからのトラフィックの急増 など、システム障害につながるリスク要因が、ある程度見えてくる。このような運用時のリスク に対する対策を事前に検討し、システムの設計・実装フェーズや運用設計にこれらの対策を 反映することが重要である。そのために、このようなリスク対策について費用対効果の高いベ ストプラクティスを共有し、情報システムの信頼性・セキュリティを向上させるための取組を早 急に進める必要がある。 このように既存のエンジニアリング手法に加え、新しい開発技術等への対応も含め、信頼 性向上のための技術・技法や方法論等を継続的に研究開発し、関係者がそれらを参照・活 用できる環境整備を行うことが必要である。 ⑤ オープンな標準に基づいたソフトウェアの適合性・相互運用性等を評価する体制 １） 相互運用性確保の必要性 社会全体の情報システム化、ネットワーク化の進展に伴って、企業間、政府・企業間など の情報システム間の相互運用性を確保することが一層重要となっている。平成 20 年 6 月に IT 戦略本部が策定した“IT 政策ロードマップ”23においても、国民の視点にたった電子政 府・電子自治体実現のための基本構想（e ワンストップ・イニシアティブ）推進のために、国 の行政機関及び地方公共団体のみならず、公的機関、民間機関との相互連携を進めてい くことが提言されており、そのための相互運用性確保は重要な課題となっている。 経済産業省が平成 19 年 6 月に IPA とともに策定した“情報システムに係る相互運用性 フレームワーク”24（以下本節において“相互運用性フレームワーク”）では、相互運用性が 欠如した場合に起こりうる問題点を事例形式で説明しており（下コラムを参照）、情報システ 23 24 http://www.kantei.go.jp/jp/singi/it2/kettei/080611honbun.pdf http://www.meti.go.jp/policy/it_policy/tyoutatu/jif19.pdf 38 削除: 、 第二部 第 1 章 （２） ムが我が国の国民生活や社会経済活動に浸透した現代社会において、相互運用性の確 保は身近なところでも大切な課題であるといえる。 コラム 相互運用性が欠如した場合に起こりうる問題例 【起こりうる問題例】 ■想定例 1 −利用者 PC の制限 電子申請システムを構築するにあたり、A 省は利用者 PC にアプリケーションを導 入する方法を採り、B 省と C 省は Java アプレットをダウンロードして使用する方式 を採った。ところが、A 省のアプリケーションが動作するオペレーティングシステムの バージョンと B 省・C 省が前提とするオペレーティングシステムのバージョンが異なる ため、電子申請システムのアクセスが同時に利用できないという問題が起きた。さら に、B 省と C 省が前提とする Java 仮想マシンのバージョンが異なるため、利用者 の Web ブラウザによっては正しく動作しない利用者 PC ができてしまった。 利用者 PC に導入するソフトウェアが特定のオペレーティングシステムのバージョ ンに依存しており、かつそれぞれの省が複数のソフトウェアを用意し異なったオペレ ーティングシステム又はバージョンに対応することを怠っていたのが問題であった。 ■想定例 2 −データの互換性の問題 L 市が使用している K 社のワードプロセッサの新版が発売され、それに伴って 2 年後に旧版のサポートが打ち切られるとの報道がなされた。L 市ではワードプロセッ サのアップデートを行うか、より安価な別のワードプロセッサに乗り換えるかの選択を せまられたが、市の予算では、市職員すべての PC に入っているワードプロセッサの アップデートを行ことができないことが判明した。しかしながら L 市では既に多くの電 子文書が K 社のワードプロセッサ独自のフォーマットで蓄積されていたため、K 社 のワードプロセッサと互換性の無いワードプロセッサに乗り換えることができなかっ た。そのため、L 市では来年度予算としてワードプロセッサのアップグレードのため の予算を計上し、今後 K 社の製品計画に合わせてアップグレードのための予算を 計上し続けることになった。 ２） 相互運用性確保に向けた諸外国の取組 欧州では、平成 16 年に、汎欧州電子政府サービスの相互運用可能な提供を目指すた め 、 欧 州 委 員 会 情 報 科 学 総 局 の 下 に IDABC （ Interoperable Delivery of pan-European eGovernment Services to Public Administrations, Businesses and Citizens）ユニットを設置した。IDABC では、国境を越えた公共部門のサービス提供の促 進や行政機関間の情報交換における効率性・安全性の確保等を目標に掲げ、欧州におけ 39 第二部 第 1 章 （２） る相互運用性のフレームワークとなる EIF（European Interoperability Framework）を 策定したほか、EU 加盟国の間で電子政府に関するリソース及び経験事例の共有化を推 進するための SEMIC.EU（Semantic Interoperability Center Europe）プロジェクト活 動や、EU 加盟国の各国独自で作成された“オープンな標準”に関する評価基準等の統一 化を推進するための CAMSS（Common Assessment Method for Standards and Specifications）プロジェクト活動を実施している。CAMSS プロジェクトでは、活動をフェー ズ 1 及びフェーズ 2 に分け、前者では、オープンな標準に関する評価基準の項目を作成し、 後者では、当該評価基準の項目を欧州各国で共有するための実証事業や普及活動を行う。 なお、オープンな標準に関する評価基準の項目については、平成 20 年 9 月にパブリックコ メントによる意見聴取が行われた25。 そのほか、EU では、欧州・サービス指令（2006 年）に基づき、サービス市場における加 盟国間の活動障壁をなくし、経済社会の発展を確保していくことが決定されており、それを 支援するためのシステム構築が各国で進められている。また、公的な調達に際しては、① 公正な競争を推進する、②オープンな標準又は機能による要求の定義を行う等のルール を規定しており、EU 加盟国間で共通のオープンな標準の普及が重要となっている。 その他の諸外国での取組としては、オーストラリアやニュージーランドにおいて政府機関 の情報システムに係る相互運用性フレームワークを策定しているほか、米国では、行政管 理予算局（OMB）が策定した Circular A-119 により民間規格の優先使用を全連邦政府機 関に指示し、標準の利活用促進を進めている。 ３） 相互運用性確保に向けた我が国の取組 ■政府調達における相互運用性の確保 我が国では、平成 19 年 3 月、情報システムに係る政府調達において、サービス市場に おける自由で公正な競争を促し、真の競争環境を実現するとともに、調達手続のより一層 の透明性・公平性の確保を図るため、重点計画 2006（平成 18 年 7 月、IT 戦略本部策定） 及び電子政府推進計画（平成 18 年 8 月、各府省 CIO 連絡会議決定）に基づき、“情報シ ステムに係る政府調達の基本指針”26（各府省 CIO 連絡会議決定、以下本節において“調 達指針”）を策定した。調達指針では、予定価格が一定規模以上の情報システム調達を対 象として、調達に際しては本指針の基本的考え方に沿って行うものとされている。 その中で、調達仕様書の作成においては、オープンな標準27に基づく要求・要件の記載 を優先することが明記された。すなわち、情報システム全体が特定事業者による独自技術 に依存してしまう事態を回避し、システム間の相互運用性を確保するため、調達仕様の作 25 http://ec.europa.eu/idabc/en/document/7407 http://www.meti.go.jp/policy/it_policy/tyoutatu/kihonshishin.pdf 27 調達指針によれば、「オープンな標準」とは、原則として、①開かれた参画プロセスの下で合意され、具体的仕 様が実装可能なレベルで公開されていること、②誰もが採用可能であること、③技術標準が実現された製品が市場 に複数あること、のすべてを満たしている技術標準をいう。 26 40 削除: 事象 第二部 第 1 章 （２） 成においては、原則として、独自の機能、独自のデータフォーマット及び独自の方式を使 用せず、国際規格・日本工業規格等のオープンな標準に基づく要求・要件の記載を優先 することとされたのである。 これを受け、調達指針の基本的な考え方に基づき、相互運用性の観点からより実践的な ガイドとして、平成 19 年 6 月に経済産業省及び IPA によって相互運用性フレームワークが 策定された。本フレームワークでは、政府及び公共機関の情報システムにおける最適化及 び調達指針における基本的考え方の実施及び情報システムの相互運用性の確保を支援 するために、調達指針の解説のほか、例えば分離調達実施の際の相互運用性確保におけ る留意点等の実践的なガイドなどを示している。 なお、相互運用性フレームワークでは優先すべき技術標準など具体的な情報が記載さ れていない。そのため、平成 20 年 12 月に経済産業省及び IPA は、調達担当官等の利便 性や調達効率の向上を目指し、調達において優先すべきオープンな標準のリストや、調達 指針の基本的考え方を踏まえた調達要件の記載例などを掲載した“情報システム調達のた めの技術参照モデル（TRM）”28（以下本節において“TRM”）を策定、公表した。 現在は、TRM に関する実証事業（架空の情報システム調達を設定し、その調達仕様書 について TRM 利用有無の 2 パターンを作成し、それぞれの調達仕様書によってベンダ企 業からシステム提案書を提示してもらう。その際に、提案書が当初想定したスペックをどれ だけ満たしているか、また、調達仕様書作成をどれだけ効率的に行えたかなどを検証す る。）を行い、TRM の効果や活用していく上での課題を IPA において分析している。また、 CIO 補佐官連絡会議などでの説明により、各府省の CIO 補佐官への普及・啓発を図って いるところである。これらにより明らかになった課題等は、平成 21 年度版の TRM 策定に反 映していく予定である（図Ⅱ- １-８参照。なお、図中の“オープンな標準の評価基準・評価ス キームの整備”については、次項を参照のこと。）。 図Ⅱ- １-８ 情報システムに係る政府調達における相互運用性確保に向けた方策とスケジュール 28 http://www.meti.go.jp/policy/it_policy/tyoutatu/trm20.pdf 41 第二部 第 1 章 （２） ■オープンな標準の適合性評価実施に向けた取組 情報システムに係る政府調達では、情報システム間の相互運用性を確保するためにオ ープンな標準に基づく調達を優先することとしている。ところで、“オープンな標準”の定義 については、脚注 27 のとおり調達指針で定義されているものの、その表現は曖昧であり、こ れだけでは、どの技術標準がオープンな標準に該当するかは必ずしも明確に判別できな い。また、どの製品がどのオープンな標準に該当するかについての適合性評価に関するス キームが現在我が国にはなく、情報システムの調達において、ベンダ企業から提案された 製品が指定のオープンな標準に確実に該当するかどうかを判断することは容易ではない。 オープンな標準の普及を推進し、情報システム間の相互運用性を確保していくために、我 が国においては以下 2 つの取組が必要となる。 第一に、オープンな標準に関する評価基準の策定と、当該基準に基づき個々の技術標 準がオープンな標準に該当するかどうかの判定である。当該基準としては、例えば、複数の ベンダ企業から出されているそれぞれの製品の市場占有度などを基準と定めるなどが想定 される。当該評価基準の策定は、現在、IPA オープンソフトウェアセンター内に設置された 第三者委員会において議論が重ねられており、平成 21 年度には一定の結論が得られる予 定である。本委員会で定められた基準を基にオープンな標準とされた技術標準については、 政府調達において優先すべき技術標準かどうかの判断を踏まえ、平成 21 年度版 TRM に 反映される予定である。なお、オープンな標準の基準策定については、企業の製品戦略に 影響を与えることから、パブリックコメントの実施等、幅広い議論が必要である。また、我が国 独自の基準を策定してしまうと諸外国との相互運用性確保に問題が生じるおそれがあるた め、基準策定においては諸外国との連携が必要である（諸外国との連携については、第 3 部において詳述する。）。 第二に、個々の製品が、上記基準によってオープンな標準と判断された技術標準に適 合するかどうかの評価を行う適合性評価スキームの整備である。その整備については、IPA 第二期中期計画にも掲げられており、上記のオープンな標準に関する評価基準の策定を 踏まえ、平成 21 年度以降に整備する予定である（図Ⅱ- １-９を参照）。 42 第二部 第 1 章 （２） 図Ⅱ- １-９ オープンな標準に関する評価基準の策定等の今後の取組の概要 ⑥ 評価制度の在り方 情報システム・ソフトウェアに関する各種の管理・評価の指標の整備に応じ、それを客観的 に評価する枠組みの検討を進めていくことが重要である。例えば、第三者評価機関が標準化 された基準に基づき信頼性及びセキュリティの実現レベルを評価する仕組み、あるいは蓄積 された信頼性・セキュリティの定量データを用いたベンチマークによる自己評価など、具体的 な評価制度の在り方を検討する必要がある。なお、第三者による評価スキームの検討にあた っては、評価結果の保証についての考え方や保証の範囲、障害発生時の対応等との関係に ついても考慮する必要がある。 また、既に、オープンな指標に基づくソフトウェアの相互運用性に関しては、技術参照モデ ル29の整備も進んでいるところであり、欧州の動きを視野に入れ、評価機関による評価制度の 在り方を早急に検討し、具体化を進める。 29 「情報システム調達のための技術参照モデル（TRM）」の公表及び政府調達におけるオープンな標準の活用に 向けた日欧協力について （http://www.meti.go.jp/press/20081222001/20081222001.html） 43 削除: 仕組 第二部 第 1 章 （３） （３）セキュリティを客観的に評価できるようにする仕組み・体制の整備 削除: 仕組 情報システム・ソフトウェアのセキュリティに関する評価は、国際標準（ISO/IEC 15408）などに基 づく評価の国際的枠組み（CCRA : Common Criteria Recognition Arrangement）が存在し、 その下で、我が国でも IPA セキュリティセンターが認証制度を実施してきた。 今後、前述のようにあらゆる情報システムがネットワークに接続する新しい環境を考えた場合、情 報システムを安全に運用するためには、情報・サービスが、アクセスを許可された者にだけ、必要 な時には正しい状態で提供されることを保証する信頼点の確保が不可欠となる。信頼点の確保の ためには、IC カード等に用いられるシステム LSI による信頼点の確保（保証）や、信頼点確保の基 盤となる電子認証技術が重要である。システム LSI の評価・認証体制の確立や電子認証技術に関 する考え方の整理を行うことにより、セキュリティの“見える化・測る化”に資することができると考えら れる。 ① システム LSI についてのセキュリティ評価に対する取組 近年、IC カードは、その安全性の高さにより、電子マネーやクレジットカード等の金融決済 系カード、交通系カード、社員証等の ID カード等に採用され、急速に利用が拡大している （図Ⅱ- １-１０を参照）。 （出典）シーメディア社 IC カード総覧 2007，2008 より IPA 作成 図Ⅱ- １-１０ 国内スマートカード発行枚数予測 IC カードや組込みシステムの心臓部であるシステム LSI チップのセキュリティ評価につい ては、ISO/IEC15408（CC：コモンクライテリア）に基づき行われている。しかしながら、現状で は、システム LSI に関するセキュリティ評価は、欧州の協議体による話合いで、どの程度の脅 威に対してどのような対策が必要かなど、セキュリティ評価の具体的な方法について、その内 容が決定されている。 44 削除: 現在 第二部 第 1 章 （３） IC カードは、既に企業や個人の財産・商取引を支える重要な基盤であり、“セキュリティ” “利便性”“コスト”のバランスを十分に考えた上で、セキュリティ評価技術の標準化についての 社会的な体制を構築することが重要である。加えて、我が国の特徴的な IC カードなどについ ても適切かつ合理的にセキュリティ評価を行えるような体制を整備していくことが、我が国の国 際競争力強化や国際貢献の観点からも重要といえる。 このため、欧州の協議体と連携しつつ、当該セキュリティ評価の結果を利用するユーザ側 の視点に立った IC カードのセキュリティ評価を日本国内で行うことができるよう、検討を進めて いく必要がある（図Ⅱ- １-１１を参照）。 日本のシステムＬＳＩセキュリティ評価体制イメージ METI IPA （ＣＣ（コモンクライテリア）に関する認証機関） （メーカ、ユーザー企業、 評価企業等が参加） CCタスクフォース CC普及検討SWG チップ評価技術検討SWG セキュリティ評価 に関する コンソーシアム 海外との連携、評価技術の検討 評価認証体制整備 CC技術検討WG 連携・調和 ＩＣシステムのセキュ リティに関する協会の 設立（チップメーカ、 ユーザー、評価機関等 が参加） CCマーケティングWG IPA 主導 連携 連携 連携 調和 海外 （欧州） の枠組 移行 CC制度改善WG 民間 主導 LSIチップセキュリティ懇話会 （チップメーカ、ユーザー企業、評価企業等が参加） 現行 新体制 図Ⅱ- １-１１ 日本のシステム LSI セキュリティ評価体制のイメージ ② 電子認証に関する取組について 正当な権利を有する者が、必要な時に正しいサービスの提供を受けることを保証するため には、アクセスしている者が正当な権利を有する者であることを合理的な方法で検証できるこ とが必要である。こうした検証の手段として認証技術がある。現在、主に用いられている認証 技術としては、利便性の高い ID・パスワード方式、セキュリティ強度の高い IC カード等を用い た PKI30方式などがある。最近では、生体情報を用いた方式も用いられてきている。 2007 年の野村総研 1,000 人アンケートにおいて、ほぼ毎日利用するウェブサイトのうち、 自分の ID を用いてログインしているウェブサイトの数について質問したところ、回答者の 48％ 30 PKI (Public Key Infrastructure)：公開鍵暗号を用いた基盤技術の全般を指す。（出典：大辞林、三省堂） 45 書式変更: フォント : 9 pt 第二部 第 1 章 （３） は、0∼4 個、35％は、5∼9 個と回答している（図Ⅱ- １-１２を参照）。他方、ID・パスワードを 何個まで記憶できるかという問いに対しては、回答者の 56％が 2∼3 組であれば、確実に記 憶できるとしている。また、過去にパスワードを忘れたことがある割合は 9 割を超え、加えて全 体の約 5 割がパスワードを忘れて困ったことがあると回答（図Ⅱ- １-１３を参照）している。さら に、自分の個人情報をどのような条件で登録したか、管理できているのは全体の 2 割にとどま る状況である。 （出典）野村総合研究所 1000 人アンケート（2007 年） 図Ⅱ- １-１２ あなたが自分の ID でログインして利用するサイトの数はいくつですか? （出典）野村総合研究所 1000 人アンケート（2007 年） 図Ⅱ- １-１３ あなたは、ID やパスワードを管理する際、何組までなら確実に記憶することができる と思いますか。 このような問題点を解決するため、現在、民間において OpenID31やリバティアライアンスプ ロジェクト32等、複数のウェブサイト間で、ID を連携する取組が進んできている。このような連 OpenID Foundation：2007 年 6 月に、OpenID 技術の開発と普及を推進するため、設立された米国オレゴン 州の非営利法人。OpenID 技術の仕様を公開。日本では、2008 年 10 月に、米 OpenID Foundation の公認団 体として、有限責任中間法人 OpenID ファウンデーション・ジャパンが設立された。 32 リバティアライアンスプロジェクト：2001年9月に設立されたアイデンティティ管理及びサービスのための公開標準 仕様の確立を目的とする団体。世界各国から150以上のメンバが参加。 31 46 削除: - 第二部 第 1 章 （３） 携をより一層促進していくためには、それぞれのウェブサイトで要求する認証に関する本人確 認のレベルと認証技術の強度を、ある程度一定に統一しておくことが重要である。本人確認 削除: 一定程度 のレベルと、そのレベルに合わせた適切な認証技術の選択についての考え方を整理しておく ことで、レベルの統一されたウェブサイト間においては、例えば、他の機関で行われた本人確 認結果が共有可能となり、個々のサービス毎の本人確認作業が低減するなど効果的な連携・ 運用の促進に寄与することができると考えられる。 現在、国内でも米国や欧州等の電子政府の取組状況33を踏まえつつ、電子政府の情報シ ステムにおける電子認証に関するガイドラインの作成に向け検討が進んでいるところであるこ とから、これらの取組を注視しつつ、認証のレベルの見える化・測る化を支える観点からも、本 人確認方法や認証技術等の考え方をまとめた電子認証に関するガイダンスを今後策定して いく必要がある。 書式変更: 標準、インデント : 左 0 字 33 米国：E-Authentication Guidance for Federal Agencies (OMB M04-04) （2003 年：Office of Management and Budget）、英国：e-Government Strategy Framework Policy and Guidelines（2002 年： Office of the e-Envoy） 等 47 第二部 第 2 章 （１） 第２章 IT を活用してサービスを展開するユーザ企業の IT 活用力の強化 （１）ユーザ企業・ベンダ企業間の対話の重要性と相互信頼性の確保 情報システム・ソフトウェアの信頼性及びセキュリティの問題に起因する、社会的なトラブルや非 効率性の発生を抑制していくためには、情報システムやソフトウェアの製造や販売を担うベンダ企 業の努力のみでは不十分である。情報システム・ソフトウェアを社会の様々な最前線の現場におい て利用するユーザ企業において、IT がもたらすメリットやリスクを適切に理解し、そのポテンシャル を最大限に引き出す能力（IT 活用力）を高めていくことが欠かせない。 しかしながら、以下に指摘するような傾向が阻害要因となっていて、我が国のユーザ企業におけ る IT 活用力は十分に発揮できていない状況にある。 削除: 、以下に指摘するような傾向が阻害要 因となり、 ● 経営層によるコミットメントの不足 削除: ⅰ） 経営陣が情報システムへの投資・管理に対して、直接的にコミットする体制が確立されてい ない企業が多い。結果的に IT 投資が経営施策と直結せず、その目的、運営方針が不明確な ままに実施されたり、IT 活用に関する組織内連携が適切に行われないことで、投資効果が十 分に発揮できない状況を招いている。 ● ユーザ企業内における意思疎通の不足・共通認識の欠如 削除: ⅱ） ユーザ企業において情報システムやソフトウェアを調達する部門や担当者が、情報システ ム・ソフトウェアを活用する現場の業務を十分に理解していない場合、現場において求められ る機能や性能についての要求を仕様に反映させることができず、結果的に IT 活用力の低下を 招く。また、ユーザ企業内に設置された情報システム部門が、社内他部門の状況を十分に把 握せずに情報システム・ソフトウェアの運用・管理を行う場合も同様である。 削除: う そこで、ユーザ企業における IT 活用力を向上させていくためには、IT ガバナンス、情報セキュリ ティガバナンスを確立させつつ、ユーザ企業が自ら主体となり以下の取組を実施していくことが求 められる34。 経営層の情報システムの投資・管理へのコミットメントによる、経営と IT の融合に向けた 経営層、現場部門、IT 部門の一体化 IT 投資の目的・運営方針の明確化 削除: による曖昧性の排除 非機能要件も含めた“見える化”によるユーザ企業・ベンダ企業間の要件・役割分担の明 確化 34 ITIL Version 3 でも同様の考え方が盛り込まれている。ITIL Version 3 は、従来バージョンに比べて戦略的な ガイダンスが多く盛り込まれており、サービスを中核に据えた「ライフサイクル・アプローチ」の概念を採用している （Computer World.jp より加筆修正）。 48 削除: 透明性の向上 第二部 第 2 章 （１） さらに、こうした IT 活用力を高めたユーザ企業と、情報システム・ソフトウェアのベンダ企業とが 緊密な関係を構築し、十分な対話を行って相互の信頼性を高めることで、IT で実現しようとする “価値”を共有することができる。それと同時に、ユーザ企業・ベンダ企業間でのリスクの認識と共有、 それに基づいた役割分担と対策の実施を行うことが不可欠である。これは、ベンダ企業の能力を最 大限に引き出すために最も有効な方策である。そのためには、第 1 章で述べた“見える化・測る化” の成果であるユーザ企業の非機能要件をユーザ企業・ベンダ企業間で確認する手法やツール、 開発プロジェクトの定量管理手法、あるいは信頼性の客観的な評価指標などを最大限に活用し、 ユーザ企業・ベンダ企業間の対話と合意形成を円滑に進めることが大切である。その際には、実 際のプロジェクトデータや評価データを収集した定量データ（相場観）に基づいて対話を進めること で、双方が納得の行く合意形成が効率的に実施できる。 ユーザ企業・ベンダ企業間の対話の成果は、ユーザ企業からの顧客満足度によって評価される。 これは、ユーザ企業・ベンダ企業間に構築された相互信頼についての“見える化”を行うことに相当 する。例えば、日経コンピュータ誌が定期的に実施しているベンダ企業に対する顧客満足度調査 では、顧客満足度を高めるポイントとして以下の 7 点が指摘35されており、ユーザ企業・ベンダ企業 間の対話が重要であることが分かる。 ベンダ企業・ユーザ企業側の各担当者の間での人的つながりを重視する 安請け合いをせず、リスクや困難性について明確に説明する トラブル発生時に自社の非を認める トラブル発生時の経過報告を迅速かつ明確に行う 新製品や技術革新などの将来的な見通しを示す ユーザ企業の期待を上回るような対応を行う 顧客の業務を熟知する 35 第 13 回顧客満足度調査 このベンダーに惚れた（日経コンピュータ、2008 年 8 月 15 日号） 49 第二部 第 2 章 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt （２）効率的でリスクに強いシンプルな業務プロセスへの革新 パッケージソフトをベースに情報システムを開発する“パッケージ中心型ソリューション”と、顧客 の要望に応じて一から情報システムを開発する“スクラッチ型ソリューション”に関する調査結果によ ると、2008 年度の国内 IT 市場における“パッケージ中心型ソリューション”が占める割合は 27.4％、 “スクラッチ型ソリューション”は 72.6％の割合である。その後の市場予測でもその割合に大きな変 削除: 「 削除: 」 化はないと予測されており、現状では、国内のユーザ企業はスクラッチ型開発が中心であり、自社 の業務フローを情報システムに合わせて変更する必要があるパッケージ型中心開発の普及が進ん 削除: 「 でいない（図Ⅱ- ２-１を参照）。 削除: 」 16 14 単位：兆円 6実績 12 10 見込 予測7 3.4 3.6 4.3 3.2 4.0 3.1 3.8 2.9 8.0 8.4 8.6 8.7 8.9 9.0 9.2 9.3 FY'06 FY'07 FY'08 FY'09 FY'10 FY'11 FY'12 FY'13 8 6 4 2 0 パッケージ中心型ソリューション市場 スクラッチ型ソリューション市場 （出典）ミック経済研究所 図Ⅱ- ２-１ パッケージ型&スクラッチ型ソリューション市場予測 しかし、ユーザ企業における IT 活用力を高めるためには、“現行業務を IT で置き換える”という これまでの発想から、“IT を用いて現状を改善する”という発想への転換が必要である。 こうした発想の導入事例として、自動車会社のケースが挙げられる。このケースでは 2006 年より、 情報 シス テム部門を 対 象と して “Business Alignment ” （社内 関係 の強化 ）、 “ Enterprise Architecture”（EA 導入）、“Selective Sourcing”（アウトソーシングの適正化）、“Technology 削除: 日産 削除: 日産自動車 Simplification”（技術体型の標準化・簡素化）の 4 施策の頭文字を取った“BEST 戦略”を開始し ている。これはコスト削減の実施にあたっては現場の意見を踏まえた優先順位の設定が重要との 認識に立ち、業務部門が現場で用いる IT システムに対して責任を負うような体制を実現するもの である。具体的な施策は以下のとおりとなっている。36 Business Alignment: 業務プロセス毎のコストの洗い出し、予算についての責任を負 うリーダーの選定とステアリングコミッティの設置 36 http://mag.executive.itmedia.co.jp/executive/articles/0802/13/news047.html 50 削除: 参考： 「日産の情報システム革新 「BEST 戦略」 キーワードは「標準化」」（IT media） （ 削除: ） 第二部 第 2 章 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt Enterprise Architecture: EA 手法に基づくコストや利用頻度の観点からのシステムに関 する状況の計測 Selective Sourcing: 情報システムの調達先、契約方法の見直し Technology Simplication: サーバのコンソリデーションやマイグレーションによる統合、共 通化 一方、損害保険会社では、これまで複雑化する一方であった保険商品に対応するために事務 削除: 東京海上日動火災保険 作業も増大していくという流れを改めるべく、2003 年末より業務プロセスの簡素化に取り組んでい る。保険の商品ラインをシンプルにすることで事務やメンテナンスの負担を軽減するとともに、同時 に簡素化された業務に対応する形で情報システムを刷新することで、再構築のコストを抑制しつつ 処理の効率化を達成している37。 現状における日本企業の業務プロセスは、複雑かつ各企業に固有のものが多い。これは、日本 企業が現場を重視し、現場で培われた手法やノウハウを強みとしてきたことで、業務プロセスにお いても各現場の要望に応じて発展してきたことによる。ただし、これをそのままシステム化すると情 報システムは複雑かつ大規模で、柔軟性を欠き、運用負荷の重いものとなってしまう。 情報システムの信頼性及びセキュリティを向上させるためには、情報システム自体の信頼性及 びセキュリティの向上に先立って、企業としての強みを維持しつつ、業務の見直しによる単純化・標 準化を図る取組が重要である。国際競争力の維持・向上の観点からも、業務プロセスにおける生 産性の一層の向上が望まれる。 また、ユーザ企業は、サービス提供者としての情報システムのオーナーシップに関する自覚を持 ち、ベンダ企業との役割分担や IT 技術者を確保・育成すること、さらには、業務部門へ IT 知識や システム作りの知識を広げ、ユーザ企業全体で IT 活用力を強化することが不可欠である。 削除: 「東京海上日動火災保険 総額 630 億 円で抜本改革に挑む 閉塞感をシステム刷新 で打破」（ 37 出典： 日経コンピュータ 2008 年 8 月 15 日号 削除: ） 51 第二部 第 2 章 （３） （３）ユーザ企業の“要件定義力”、 “システム設計力” 、 “プロジェクトマネジメント力” の強化 情報化が進展し、情報システム・ソフトウェアやネットワークが多機能化、複雑化、高度化する中 で、ユーザ企業は情報システムの全容を把握することが一層困難になりつつある。その結果、ユー ザ企業においては情報システム部門を含め、“要件定義力”、“システム設計力”、“プロジェクトマ ネジメント力”が従来と比べて相対的に低下していることが懸念される。 なお、“要件定義力”、“システム設計力”、“プロジェクトマネジメント力”はそれぞれ以下のように 定義される。これら 3 要素を、ユーザ企業の組織全体としてバランス良く配置ないし確保することが 望まれる。 ● 要件定義力 削除: ⅰ） 提供サービスの業務要件や必要としているシステムの要件、すなわちどのような機能を実現 してほしいかを定義し、ベンダ企業等に伝えることができる力をいう。業務の展開に情報システ ムやネットワーク活用が欠かせない現在、業務に対する視点があると同時に、システムを十分 に理解し、自らの要件定義力を活用して新しい価値創造ができる人材が必要である。 ● システム設計力 削除: ⅱ） 先進技術に立脚した、競争力のある新規サービスの開発を行える力をいう。ベンダ企業任 せになるのではなく、ユーザ企業が主導的にコントロールできる力も必要である。要件定義力 と同様、業務を十分に理解した上で、ユーザ企業であってもシステム設計力を備えた人材を得 ることで、新しい価値創造を行うことが可能となる。 ● プロジェクトマネジメント力 削除: ⅲ） 開発者側で実施するシステム設計・開発の進捗管理や課題管理について、報告を受け適 切な指示を行うことができる力をいう。ベンダ企業による対応が難しい、業務とシステムの間に 落ちるリスクをコントロールしながら、プロジェクトマネジメントができる人材が必要である。ユー ザ企業におけるプロジェクトマネージャは、システム導入プロジェクトの実行管理に責任を持ち、 プロジェクトを成功に導く役割を担う。 情報システム・ソフトウェアの信頼性及びセキュリティを向上するために、ユーザ企業がこうした “要件定義力”、“システム設計力”、“プロジェクトマネジメント力”を強化することは極めて重要であ る。そのためには、ユーザ企業は一定以上の情報リテラシー及びインテリジェンスを持つことが前 提となる。その上で、ベンダ企業の協力のもとで以下のような取組が考えられる。 ● 要件定義書の作成における、ユーザ企業・ベンダ企業間のギャップを埋める取組 確保すべき信頼性のレベルや、実施すべき情報セキュリティ対策は要件定義フェーズで明 52 削除: 具体的には 削除: ⅰ） 第二部 第 2 章 （３） 確に示すことが望ましいが、具体的な条件の提示なしに高度な要求の絶対的な保証を求める ことは、過剰装備や高コストな実装を招くおそれがある。ベンダ企業が適切な実装を実現する ために必要十分な情報を提示すべく、ユーザ企業の要件定義力を強化することが考えられ る。 ● システム設計における、信頼性及びセキュリティの高い設計を効率的に行う取組 削除: ⅱ） ユーザ企業におけるシステム設計力を高める取組において、ユーザ企業・ベンダ企業間で 信頼性やセキュリティの確保に関する知識を共有することなどが考えられる。 ● プロジェクトマネジメントにおける、仕様や開発条件の変更ニーズに対して、ユーザ企業・ ベンダ企業のいずれかに負担を片寄せしないための取組 予定の稼働時期が遅延することはユーザ企業にとって大きな損失であることを踏まえ、ユー ザ企業における開発工程に関する理解とプロジェクト管理への協力などを含む、プロジェクトマ ネジメント力の強化の取組が考えられる。また、経営者や業務部門の役割として、要件の切り 捨て、絞り込みなど、規模が膨らまないように機能削減、優先順位付けの能力を強化する取組 も求められている。 （４）ユーザ企業のグローバル化をサポートするベンダ企業の国際競争力の強化 グローバルに展開するユーザ企業において、その基盤となる情報システム・ソフトウェアの信頼 性やセキュリティは、国際競争力を強化する上で必須の要件である。しかしながら、現状において 日本の情報システム・ソフトウェアのベンダ企業はグローバルレベルでユーザ企業を十分にサポー トできているとはいえない。 ユーザ企業にとって、海外ベンダ企業が提供するグローバルなサポート体制などが優れていれ ば、国内ベンダ企業においてその信頼性やセキュリティに関する優位性があっても、総合的には 海外ベンダ企業のほうが有用と評価する可能性もある。既にグローバルなシステムの中に日本で 使うシステムがあるという発想の転換を行っているユーザ企業もあり、ベンダ企業は何が国際競争 力の源泉になるかを十分検討する必要がある。 ベンダ企業がユーザ企業のグローバル化をサポートするには、単に信頼性やセキュリティの高 い製品を作れば良いのではなく、グローバルなサポートを含めたトータルの品質を高めることが重 要である。例えば、国内で普及している運用管理ソフトウェアを日本企業の海外法人等でも利用で きるよう、海外でのサポート体制を整備することで、製品の競争力を高めたり、日本国内と同等のイ ンフラからオペレーションまでの運用サポートサービスを海外でも提供することで、現地法人の IT 活用を支援するベンダ企業も出てきている。こうしたベンダ企業によるサービスの存在により、ユー ザ企業は海外でも日本と同じサービスを得ることが可能となり、IT 活用に関する習熟コストの軽減 等のメリットを享受することができる。 ユーザ企業がグローバルに展開していく際、競争力の源泉となるのは、“品質の高い業務”並び 53 削除: ⅲ） 第二部 第 2 章 （４） に“業務革新”と“それを支えるソフトウェア”のすべてを含めたビジネスモデルである。したがって、 情報システム・ソフトウェアを開発するベンダ企業に求められる機能や役割としては、単に品質の高 いソフトウェアを提供すれば良いのではなく、価格競争力、ユーザビリティの向上、マルチリンガル 化や DB 構造のグローバル化、世界での“3 極・24 時間連続開発体制”の構築や、グローバルな適 材分業化の導入などの対応が必要となる。 また、ベンダ企業のグローバル展開は、海外に進出した日本企業のサポートのみを対象とする 削除: 一方 のではなく、現地企業をも対象としたビジネス展開がなければ事業の成長性、収益性の向上を狙う のが困難である。海外のユーザ企業に対しては、品質に対する要求は各国の文化や企業の考え 方に依存するため、機能的に高品質というだけで国際競争力があるという議論は成り立たない。ま た、製品となるソフトウェアは、その構造において、モジュール化やプラットフォーム化を進めていく ことで、生産性の向上及び製品やサービスの迅速な市場展開などを実施することが重要である。こ うした前提を踏まえたグローバルな製品やサービスメニューの開発、販売ネットワークの構築と販売 促進のグローバル展開が求められている。 グローバルな外部と接続される情報システムでは、グローバルな接続規格の開発をリードできる 環境整備などが重要である。 54 削除: 、 第二部 第 3 章 （１） 第３章 情報システム・ソフトウェアの取引・契約におけるユーザ企業・ベン ダ企業の間の共通認識の欠如を解決するための契約の在り方 （１）ユーザ企業・ベンダ企業間の契約に係るこれまでの取組と課題 ① ユーザ企業・ベンダ企業の共通認識の形成と責任・役割の明確化の必要性 情報システム・ソフトウェアの信頼性向上を図る上で、重要な役割の一翼を担うのがユーザ 企業・ベンダ企業の共通認識の形成と責任・役割の明確化に資する契約の在り方である。 以前の IT の役割は、メインフレームなどの大型コンピュータを使用して計算処理を行うもの が主流であった。しかし、今日では、IT を経営基盤として利用し、高い生産性を実現していく ことが大きな使命となっている。そのような中で求められる情報システムは、ユーザ企業とベン ダ企業が密接なコミュニケーションを前提として共同作業により構築するものとなっている。す なわち、ユーザ企業は自らの情報システム構築目的や内容を可能な限り明確にする一方、ベ ンダ企業には、不明確なユーザ企業のニーズを、IT に対する深い知識に基づいて明確化し ていき、具体的なソリューションを提供していく役割が求められている。 このように、情報システムに係る取引においては、ユーザ企業とベンダ企業がパートナーシ ップの認識38を持ってシステム導入の目的を共有し、その目的の実現に向けてベンダ企業が 提供する具体的サービス内容及びその品質レベル、コスト、リスク等について明確な合意を持 つことが必要となる。そして、その合意内容に従って、情報システム構築・運用で応分の役割 と責任を担うことが必要となる。 しかしながら、現在の取引慣行では、情報システムライフサイクルプロセスの中でのユーザ 企業・ベンダ企業間の役割・責任分担が不明確であり、また、取引される情報システムの品質 についてユーザ企業とベンダ企業の認識に乖離があるなど不透明な実態があるため、情報シ ステムの価値を決める諸要因（機能・信頼性・ライフサイクルコスト等）の水準について両者が 同じ認識を持った上での取引がなされず、事後的に、問題が発見されて紛争が生じることが 多い。それに加え、紛争が起きた場合に、契約・法的な手続に従った合理的な解決が得られ ないことも少なくない（コラム 紛争の実例を参照）。 削除: て 削除: に 削除: され 38 「詳細は、“情報システム・モデル取引・契約書＜第一版＞（経済産業省、平成 19 年 4 月）”の P.42 を参照。 （http://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf） 55 書式変更: フォント : 9 pt 第二部 第 3 章 （１） コラム 紛争の実例 【実例 1】仕様を巡るユーザ企業・ベンダ企業の認識ギャップの問題 調査会社 A ユーザ企業（年商数億円）は、約 2 千万円で新基幹システムの構築を B ベンダ企業と契約。5 回以上もの納期延長の末、納品まで 5 年をかけて完成するも バグ多数で、A ユーザ企業は検収せず、契約解除・損害賠償を巡って訴訟提起。B ベンダ企業は、A ユーザ企業の頻繁な仕様変更が原因と主張する一方、A ユーザ企 業は B ベンダ企業側の業務理解不足と主張。2 年程度の紛争を経て和解した。契約 の不備が、開発失敗、紛争長期化を招いた。 【実例 2】要求仕様不明確なままの契約締結の問題 中堅企業である C ユーザ企業（従業員約 200 人）が、老朽化した流通管理システ ムの更新を D ベンダ企業に委託。C ユーザ企業の設定した要求要件には機能の詳 細が記載されていなかったため、D ベンダ企業は一般的な開発ボリュームを想定して 契約。その後、複雑なロジック等が必要なことが判明。当初契約で追加費用等につい ての定めが無かったために、両者の紛争がエスカレート。D ベンダ企業にとっては大 幅な赤字案件に。 図Ⅱ- ３-１は、システムの仕様変更の発生度又はシステム要件定義の明確度と、構築され た情報システムの満足度（ユーザ企業側のプロジェクト責任者から見た満足度）の関係を示し ている。図から分かるように、大きな仕様変更が発生するほど、また、システムの要件定義が不 明確であるほど、提供されるシステムの満足度は低くなる傾向にある。すなわち、上流工程に おけるユーザ企業・ベンダ企業間のミスコミュニケーションが満足度の低い情報システムを生 み出す要因となっていることを端的に示している。 56 第二部 第 3 章 （１） 図Ⅱ- ３-１ システムの仕様変更発生度及び要求定義明確度とユーザ満足度 さらに、情報システム・ソフトウェアの大規模化・複雑化が進む中、今後、ユーザ企業とベン ダ企業間の共通認識の形成は一層容易ではなくなっていくと考えられることから、法務リスク が拡大していくと考えられている（図Ⅱ- ３-２を参照）。 図Ⅱ- ３-２ システム部長の法的リスクに対する意識の変化 57 第二部 第 3 章 （１） 以上から、情報システムの満足度を高め、結果として、信頼性の高いものとしていくために は、ユーザ企業・ベンダ企業の共通認識の形成と責任・役割の明確化を図ることが重要であ ると考えられる。次節では、経済産業省をはじめ各情報システム関連団体の取組について述 削除: となる べる。 ② 経済産業省の取組 経済産業省では、これまで、情報サービス・ソフトウェア産業の競争力を強化するため、ユ ーザ企業・ベンダ企業間の取引適正化について検討を進めてきている。平成 5 年には産業 構造審議会情報産業部会において通商産業大臣告示“カスタムソフトウェア開発のための契 約書に記載すべき主要事項”（以下本章において“通産省告示 359 号”）が策定され、推進体 制の強化や仕様の確定・変更、検収、瑕疵担保責任、知的財産権、機密保持義務の観点か ら契約書に記載すべき主要事項を示した。 その後、平成 17 年の証券取引所におけるシステム障害をきっかけに情報システム・ソフトウ ェアの信頼性向上は大きな政策的・社会的課題となり、平成 18 年 6 月には“情報システムの 信頼性向上に関するガイドライン”を策定した。その中で、情報システムの信頼性・安全性水 削除: 情報システムのための信頼性ガイドライ 準の向上に向け、“商慣行・契約・法的要素に関する事項”に関する具体的対策として、契約 ン における重要事項の明確化や情報システム構築の分業時の役割分担及び責任関係の明確 化を掲げた。 また、産業構造審議会情報経済分科会情報サービス・ソフトウェア小委員会において、平 成 18 年 9 月に中間取りまとめとして“情報サービス・ソフトウェア産業維新”が公表され、我が 国情報サービス・ソフトウェア産業の発展の在り方に関し、総合的な提言が行われた。その提 言では、情報システムの価値を決める諸要因（機能・信頼性・ライフサイクル等）の水準につい て、ユーザ企業・ベンダ企業が認識せずに取引が行われ、事後的に発生した問題から紛争が 生じることが多いと指摘されている。そのため、情報サービス産業の競争力強化戦略として、 ユーザ企業・ベンダ企業間の取引関係・役割分担の可視化が掲げられ、ベンダ企業とユーザ 企業の間で協働してモデル契約・契約プロセスを策定することが提言された。 こうした背景を基に、経済産業省では、平成 18 年度に法律の専門家や情報システムのユ ーザ企業団体、ベンダ企業団体を委員とした情報システムの信頼性向上のための取引慣行・ 契約に関する研究会（以下本章において“契約研究会”）を設置し、情報システムの信頼性向 上・取引可視化に向けた取引・契約の在り方の検討を行ってきた。 平成 19 年 4 月には、パブリックコメントによる幅広い意見聴取を経て、報告書として“∼情報 システム・モデル取引・契約書∼（受託開発（一部企画を含む）、保守運用）<第一版>39 （以 下本章において“モデル契約書<第一版>”）を策定し、対等な交渉力を有するユーザ企業・ ベンダ企業を契約当事者として、ウォーターフォールモデルによる重要インフラ・企業基幹シ ステム構築を前提条件としたモデル的な契約プロセス・契約書を示した。 39 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#03 58 削除: 中 第二部 第 3 章 （１） さらに、平成 19 年度には、モデル契約書<第一版>の基本的な考え方は踏襲しながらも、 “IT の専門知識を有しないユーザと業として情報サービスを提供するベンダ企業”を契約当 事者として、パッケージソフトウェアや SaaS・ASP を活用した一般的な業務システムの構築を 前提条件とした、重要事項説明書を活用したモデル的な契約プロセス・契約書を検討した。 その報告書として、パブリックコメントによる幅広い意見聴取を経て、平成 20 年 4 月に“∼情報 システム・モデル取引・契約書∼（パッケージ、SaaS/ASP 活用、保守・運用）<追補版>40”（以 下本章において“モデル契約書<追補版>”）を策定、公表した（表Ⅱ- ３-１を参照）。 表Ⅱ- ３-１ モデル契約書<第一版>及び<追補版>のポイント なお、情報システムにおける取引の適正化は、ユーザ企業にとっては信頼性の高い情報シ ステムを実現するとともに、ベンダ企業の競争力強化にも資する。このことから、“IT 政策ロー ドマップ”（平成 20 年 6 月、IT 戦略本部策定）41における具体的施策としてユーザ企業とベン ダ企業との取引慣行の改善が掲げられているほか、“重点計画 2008”（平成 20 年 8 月、IT 戦略本部策定）42でも具体的な施策としてモデル契約書の普及が掲げられているなど、政府 としての施策に位置付けられている。 ③ モデル契約書の特徴と普及の取組 モデル契約書の策定にあたっては、次の 3 つの視点を盛り込んでいる。 第一に、策定においてユーザの視点を導入した点である。これまでも関連業界団体におい 40 41 42 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#03 http://www.kantei.go.jp/jp/singi/it2/kettei/080611honbun.pdf http://www.kantei.go.jp/jp/singi/it2/kettei/080820honbun.pdf 59 第二部 第 3 章 （１） てモデル的な契約書の策定は行われてきたが、ユーザ企業団体と共同で作られてきたものは これまでになかった。モデル契約書の検討を行った契約研究会にはユーザ企業団体である JUAS やユーザ企業の有識者が委員として参画し、ユーザ企業とベンダ企業の利害が相反 しがちな著作権の帰属や損害賠償の規定などの論点について考え方を整理している。 第二に、企画開発から保守運用まで網羅的に盛り込んだ点である。関連業界団体が策定 してきたモデル的な契約書には、これまで保守・運用フェーズにおけるモデルは存在していな かった。そもそも保守・運用フェーズでは多様なサービス形態が存在するため、すべてのパタ ーンを網羅した一律的なひな形を作成することができず、モデル化は進んでいなかった。しか しながら、保守・運用フェーズでのシステム障害は多発しており、ユーザ企業・ベンダ企業が 協働して安定的なシステムを運用することは重要な課題となっている。モデル契約書では、保 守・運用フェーズのモデル的な契約プロセスや契約条項を示している。 第三に、モデル契約書<追補版>において重要事項説明書を導入している点である。モデ ル契約書<追補版>では情報システム関連の専門家や専従者を設置することが困難な企業を 契約当事者として想定しており、そのようなユーザ企業は、ベンダ企業の提案するシステムの 内容が自社の目的に適合した正しい仕様であるかなどを客観的に評価することが難しい。信 頼性が高く目的と合致するシステムを構築するためには、契約の透明性を高める合意プロセ スの確保が重要であり、モデル契約書<追補版>では、ユーザ企業・ベンダ企業双方がシステ ムライフサイクルの各フェーズで、構築する情報システムの詳細内容を確認・合意していくた めの重要事項説明書を導入した。 モデル契約書を普及するために、平成 19 年度には、モデル契約書普及に関する環境整 備事業の一環でセミナーを開催したが、募集 2 日で定員 200 名に達し、また、その後の追加 セミナーでも多数の参加者を得るなど、情報システムの取引適正化に対する関心は高かった ところである。平成 20 年度は、業界の自主的な取組として、弁護士などの有識者や関連団体 をメンバとして設置された“情報システム・ソフトウェア取引高度化コンソーシアム”43（以下本章 において“取引高度化コンソーシアム”）が、引き続きモデル契約書の普及促進を実施してい る。取引高度化コンソーシアムでは、特に、中小企業に係る取引は市場が広くユーザ企業・ベ ンダ企業間の IT に関する知識の差も大きく、契約を巡るトラブルも多くなっており、中小企業 の取引の多数を占めるパッケージソフトウェア活用型の契約書であるモデル契約書<追補版> の普及が急務であるとの観点から、平成 20 年度は主にモデル契約書<追補版>の普及を中 心とした活動を行っている。具体的には、全国規模でのセミナーの開催や、e ラーニングの整 備などに取り組んでおり、また、モデル契約書の活用にインセンティブを与えるような環境整 備に関する検討を行っている（図Ⅱ- ３-３を参照）。 43 http://www.softic.or.jp/consortiumu 60 第二部 第 3 章 （１） 図Ⅱ- ３-３ 情報システム・ソフトウェア取引高度化コンソーシアムの概要 なお、モデル契約書では、紛争が生じた場合の解決方法として法的救済手段を講じる前に 裁判外紛争解決手続（ADR）による解決を原則としている。これは、ソフトウェア開発のような 専門的で複雑な事案については、柔軟な審理が可能であり、また、技術的知見を有する専門 家の判断を仰ぐことも可能であるなど、裁判所における訴訟よりも ADR の方が迅速かつ適切 に解決できることも考えられるためである。しかしながら、情報サービス・ソフトウェア産業の取 引を巡る紛争についての専門の ADR 機関が存在せず、ソフトウェア ADR 機関の整備が必要 であった。そのため、財団法人ソフトウェア情報センターのソフトウェア紛争解決センターがソ フトウェア分野を専門に扱う機関となるべく支援を行い、平成 20 年 7 月に法務省の認証を受 けた44。今後、当該 ADR 機関がソフトウェア分野の紛争解決に活用されることが期待される。 ④ その他の関連団体の取組 情報システム・ソフトウェアの関連団体においても、情報システムにおける取引の適正化に 向けたモデル的な契約プロセスや契約書の整理などを行っている。社団法人情報サービス産 業協会（JISA）及び社団法人電子情報技術産業協会（JEITA）では、通産省告示 359 号を 基に、平成 6 年にそれぞれ“ソフトウェア開発委託基本モデル契約”、“ソフトウェア開発モデ ル契約”を策定しており、その後、JISA では平成 14 年版を作成した。さらに、今般の経済産 業省モデル契約書の策定を機に、JISA 及び JEITA それぞれで新たにソフトウェア開発のモ デル契約を策定、公表しており、その普及に努めているところである。 また、特定非営利活動法人 IT コーディネータ協会（ITCA）では、主にコンサルタントの役 割を担う IT コーディネータ向けの推奨契約として、“IT コーディネータ業務委任契約書”を策 定したほか、社団法人コンピュータソフトウェア協会（CSAJ）及び社団法人日本コンピュータ システム販売店協会（JCSSA）では、モデル契約書<追補版>の原案策定に中核的に参画し、 44 http://www.softic.or.jp/adr 61 削除: 処理 第二部 第 3 章 （１） 取引高度化コンソーシアムのセミナー講師派遣などによる普及に取り組んでいる。 JUAS では、要求仕様の明確化を図る取組として UVC（User Vendor Collaboration）開 発手法の整理を行っている。UVC とは、ユーザ企業が作成した機能要求仕様書を基にベン ダ企業が要求仕様を固めていく手法であり、ユーザ企業が考える各仕様の背景を含めて開 発担当者に伝えることができるため、仕様の意味を正確に伝えることができるなどの効果が期 待できるものである。 （２）責任・役割の関係が明確となる取引・契約の定着 ① モデル契約書の普及に向けた取組の状況と課題 責任・役割の関係が明確となる取引・契約の定着に向けては、モデル契約書の普及のため の取組が主に行われている。具体的には、上述のとおり、取引高度化コンソーシアムによるセ ミナー開催や e ラーニング整備をはじめ、JISA や JEITA においては新しく策定したソフトウ ェア開発モデル契約書の解説書を作成し、その普及を図っている。しかしながら、現状、モデ ル契約書の普及に向けては次の 2 つの課題がある。 第一に、上記普及の対象がベンダ企業に傾斜している点である。契約当事者の一方であ るベンダ企業に対しどんなにモデル契約書の普及を図ったところで、もう一方の当事者である ユーザがその考え方を理解していない状況では、実際の現場でモデル契約書に基づく取引 は行われにくい。実際の取引の場面でベンダ企業側からユーザ企業にモデル契約書の考え 方を説明しても、ユーザ企業側から見れば単なる押しつけとしか受け取りかねないからであ る。 第二に、上記普及に向けた取組が主に普及・啓発活動にとどまっており、モデル契約書を 使うことに対するメリットを実感しにくい状況となっている点である。情報システム取引に関する 契約書のひな形は既に各社が用意しているケースが多く、改めてモデル契約書の考え方を 盛り込むのは手間となるため、そのメリットを実感できなければモデル契約書の普及は進まな い。他方で、そもそも契約書のひな形が存在しない企業にとっては、ボリュームの大きなモデ ル契約書の内容を理解し、実際の取引で活用していくのは手間となるため、やはりそのメリット を実感できなければモデル契約書の普及は進まない。 ② 今後の取組の方向性 上述のモデル契約書普及に関する課題を踏まえ、責任・役割の関係が明確となる取引・契 約の定着に向けて以下のような取組が求められる。 第一に、ユーザ企業を巻き込んだ普及策の検討である。関連団体独自で行うよりも多様な 主体が参画している取引高度化コンソーシアムの場を活用し、モデル契約書<第一版>を含 め、ユーザ企業を巻き込んだ普及活動の検討が必要である。具体的には、モデル契約書の 考え方を踏まえることがユーザ企業にとってもメリットのあることを伝えていくため、モデル契約 書を活用したことによる成功事例を示しながら、次の第二の方向性で言及されているインセン 62 削除: に向けた取組の相手方 第二部 第 3 章 （２） ティブ策と併せて普及を図ることが考えられる。なお、モデル契約書のユーザ企業への普及 にあたっては、その契約の形態を安易に理解するのではなく、あくまで信頼性の高いシステム を構築するためにはどのような役割分担をし、その責任を果たしていくべきかという視点を持 つことに留意する必要がある。 第二に、モデル契約書を利用することによるインセンティブ策の検討である。例えば、取引 高度化コンソーシアムのワーキングループでは、モデル契約書と情報システム保険の在り方 について検討を重ねている。その中で、モデル契約書では、ユーザ企業・ベンダ企業の利害 が相反しがちな損害賠償などの規定を取り決めておくなどの取引の可視化を図っていること から、事後的に問題が生じた場合のリスク把握が比較的容易になっている面があり、モデル契 約書を活用した場合の取引については保険料割引ができることの可能性が示唆されている。 今後、これら議論を踏まえ、モデル契約書利用のインセンティブ策の検討を進めていくことが 考えられる。 （３）新しい契約形態への対応 ① インセンティブを高める契約形態の導入の拡大 １） インセンティブを高める契約形態（パフォーマンスベース契約）の必要性 我が国の情報システム市場は、現在、主として“人月ベース”の価格表示を行っており、 それに伴う価格の根拠がユーザ企業側の価格への不信感につながっていることは従来か ら多数指摘されているところである。高い品質や高い効果を創出するシステムを構築できる 付加価値の高いベンダ企業が適正に評価される市場構造が確立されなければ、情報シス テム・ソフトウェア産業全体が健全な発展を遂げることができない。また、人月積算を前提と した Fixed Price（固定価格）のみでは、ベンダ企業の品質向上等へのモチベーションは生 まれず、他方で、ユーザ企業にとって CEO（Chief Executive Officer：最高経営責任者） をはじめとする経営層に説明できない価格では、投資の妥当性を提示できず、投資意欲そ のものを減退させてしまうおそれがある。 このような背景から、情報システムの生み出す付加価値に着目して価格を決定する“パフ ォーマンスベース契約”（以下本章において“PBC”（Performance Based Contracting）） についての検討が求められている。なお、パフォーマンスベース契約の検討については政 府内でもその必要性が議論されているところであり、“情報サービス・ソフトウェア産業維新” （平成 18 年 9 月、産業構造審議会情報経済分科会情報サービス・ソフトウェア小委員会策 定）では、情報サービス産業競争力強化策の一つとして、“人月工数単価”（情報システム の開発に要した人数と月数の積に応じて報酬が支払われる価格決定方式）からの脱却が 一つの達成目標として掲げられている。また、“重点計画 2008”（平成 20 年 8 月、IT 戦略 本部策定）でも、情報サービス産業を高収益な業務形態へと転換するため、情報システム の取引において現行の“人月方式単価”による価格決定方式からの脱却を図り、情報シス テムの付加価値に着目して価格を決定する PBC の検討・普及を図ることが具体的施策とし 63 第二部 第 3 章 （３） て掲げられている。 ２） 経済産業省の取組 これを受け、経済産業省では、情報サービスの PBC に関する調査研究を平成 19 年度よ り実施している。 平成 19 年度は、海外及び国内（他産業に関するものを含む）の PBC 先進事例約 30 事 例を公知事例に基づき調査・分析し、PBC の分類と適用可能性に関する整理・分析を行っ た45。 まず、PBC の分類については、PRM（Performance Reference Model）のフレームワ ークをベースに、“①インプット型”、“②アウトプット型”、“③アウトカム型”の 3 つに分類した。 “①インプット型”は、システム開発、運用そのものの価値をベースに価格設定、契約を行う もので、契約対象となるのはシステム開発や運用が想定され、設定される KPI（Key Performance Indicator、重要評価指標）はシステム稼働率、バグ数、応答時間、保守時 間が挙げられる。“②アウトプット型”は、情報サービス、システムにより実現される業務改善 等のオペレーション価値をベースに価格設定、契約を行うもので、契約対象となるのはシス テム開発や運用、オペレーションが想定され、設定される KPI は利用数、利用率、欠品率、 作業時間、在庫回転率が挙げられる。“③アウトカム型”は、収益等の事業目的、成果をベ ースに価格設定、契約を行うもので、契約対象となるのはシステム開発、運用を含む事業 全体が想定され、設定される KPI は利益増大、コスト削減、満足度が挙げられる（図Ⅱ３-４を参照）。 （出典）「情報システムのパフォーマンスベース契約に関する研究」報告書（経済産業省、平成 20 年 3 月） 図Ⅱ- ３-４ PRM による PBC の分類 45 報告書は、http://www.meti.go.jp/press/20080425004/02_houkokusho.pdf に掲載。 64 第二部 第 3 章 （３） 表Ⅱ- ３-２ 情報サービスの提供形態とシステムライフサイクルプロセスを考慮した主な契約形態 （出典）「情報システムのパフォーマンスベース契約に関する研究」報告書（経済産業省、平成 20 年 3 月） 表Ⅱ- ３-２の分類を基に、委託開発形態や ITO（IT アウトソーシング）形態、BPO（ビジ ネスプロセスアウトソーシング）形態などの情報サービスの提供形態毎に、適用しうる PBC 分類や、適用の難易度について分析を行った。なお、適用の難易度は、実際の普及度や 測定コスト、また、成果の明解度を基に判断している。また、情報サービスに係る契約は、 提供形態毎にすべてを一括契約とするのではなく、提供形態によってシステムライフサイク ルプロセスのフェーズにまで細かく分けることを前提にした（全部で 19 の契約形態に分類。 65 第二部 第 3 章 （３） 表Ⅱ-3-3 を参照。）。 表Ⅱ- ３-３ 情報サービスの提供形態とシステムライフサイクルプロセスを考慮した主な契約形態 （出典）「情報システムのパフォーマンスベース契約に関する研究」報告書（経済産業省、平成 20 年 3 月） 表Ⅱ- ３-３を基に、契約形態①∼⑲をそれぞれ適用しうる PBC 分類と適用の難易度で マッピングしたのが図Ⅱ- ３-５である。これを基に、各契約形態の PBC の適用可能性につ いては、図Ⅱ- ３-５に示す 6 つのカテゴリに整理することができる。 （出典）「情報システムのパフォーマンスベース契約に関する研究」報告書（経済産業省、平成 20 年 3 月） 図Ⅱ- ３-５ 情報サービスの契約形態のマッピング結果と 6 つのカテゴリ 66 第二部 第 3 章 （３） 図Ⅱ- ３-５のカテゴリ整理により、PBC モデルとしては、図Ⅱ- ３-６に示すような大きく 3 つの方向性で展開が可能であると結論づけた。 （出典）「情報システムのパフォーマンスベース契約に関する研究」報告書（経済産業省、平成 20 年 3 月） 図Ⅱ- ３-６ 適用可能な PBC モデルの 3 つの方向性 平成 20 年度は、19 年度の成果を基に、PBC を実際に行うために必要なプロセス・手順 の整理や PBC 実施にあたっての課題整理・対応策の検討を行った。検討にあたっては、 先進的な取組を行っている企業への詳細なヒアリング調査結果も踏まえて行っている。 まず、PBC 適用の際に検討すべき内容や注意点などを 5 つのステップとしてまとめた。5 つのステップは、“PBC パターンの設定”、“KPI の設定”、“価格設定”、“契約内容の決 定”、“KPI の評価と見直し”で構成され、詳細は図Ⅱ- ３-７のとおりである。 67 第二部 第 3 章 （３） （出典）「情報サービスのパフォーマンスベース契約に関する調査研究」報告書（経済産業省、平成 21 年 3 月） 図Ⅱ- ３-７ PBC 実施にあたっての 5 ステップ なお、PBC 実施にあたり、情報サービスの提供内容と検討体制によってその契約プロセ スは異なる。上記 5 ステップの検討ポイントが契約プロセスのどこに当てはまるかはサービス の提供内容や検討体制によって異なることを踏まえ、その整理も行った。例えば、BPO や ITO などサービスまで含めた提供を受ける場合で、ベンダ企業と共同で業務仕様や PBC 適用の検討を行う場合については、図Ⅱ- ３-８のような課題について 5 ステップの検討が必 要となると整理している。 68 第二部 第 3 章 （３） （出典）「情報サービスのパフォーマンスベース契約に関する調査研究」報告書（経済産業省、平成 21 年 3 月） 図Ⅱ- ３-８ サービス提供の契約において PBC 適用についてユーザ企業・ベンダ企業共同で検 討する場合の 5 ステップの検討ポイント その他、平成 20 年度では、現場の声を拾い上げた PBC 成功のカギとなる留意点をまと めたほか、架空の情報サービス契約を基に、PBC 適用のシナリオなどを検討した。 ３） 今後の方向性 平成 19 年度からの 2 年間の調査研究により、情報サービスに対する PBC の適用につ いては一定程度の整理が進んだところである。しかし、情報システム開発における PBC の 適用については、KPI としての“パフォーマンス”の客観性、契約金額の決定方法、あるい は工事進行基準を適用する際の会計処理の実施方法など、実際の適用に際しては解決す 69 第二部 第 3 章 （３） べき課題が残されている。今後は、その実施に向け、PBC がもたらす効果や情報システム 開発の特質にも十分配慮しながら、次の 3 つの検討が必要と考えられる。 第一に、PBC に関する普及・啓発活動である。PBC については、事例の公表が少なく、 そのイメージが湧きにくい上、そもそも PBC の認知度が低いために、実際の取引において PBC 適用の検討が行われるケースが少ないのが現状である。そのため、平成 20 年度事業 の報告書を広く公表するなどして、PBC に関する普及・啓発を行い、活用に関する関心を 高めることが必要である。 第二に、PBC に関するモデル的な契約を策定することである。PBC 適用の詳細は、最 終的には契約条件として契約書に反映されるものであり、そのモデル的な契約条項を提示 することで、PBC 適用のイメージがより明解になり、普及に資するものと考えられる。モデル 契約書<第一版>においても、今後の検討課題として PBC といった多様な契約の在り方に ついて検討を行うことが掲げられており、モデル的な契約書の検討を行っていくことが必要 である。 第三に、政府調達をはじめとする情報サービス契約への導入の推進である。これまでの 調査研究により、PBC 適用については一定程度の整理が行えたものの、実証事業を実施 することによって、調査研究では把握できなかった課題が見えてくることが考えられる。また、 本調査研究事業に付随して実証事業を行い、一定の成果を得ることができれば、それが成 功事例として PBC の認知度向上に寄与するという効果も期待できると考えられ、今後、実 証事業を実施していくことが必要である。 ② 多様な開発手法（アジャイル等）に対応した契約の在り方 １） 多様な開発手法が着目されてきている背景 ソフトウェアの開発を巡る環境は、近年、大きく変化している。情報システムが我が国経済 社会に深く浸透し、社会的基盤としての役割を担うようになる中、ソフトウェアに求められる 信頼性は格段に高まってきている。また、情報システムが多機能化する中、ソフトウェアはよ り複雑に、大規模になってきており、ソフトウェアの用途の面を見ても、組込みソフトウェアと して携帯電話や自動車に搭載され、また、SaaS/ASP に代表されるようなアプリケーション サービスでもソフトウェアが活用されているなど、ソフトウェアの用途は多様化している。 このような中、ソフトウェアの用途によっては、ソフトウェア開発における要求仕様を確実 に予測することが難しくなっており、むしろ、開発過程で予測できない変化が起こることを前 提にソフトウェア開発を行うことで、高信頼性かつ高品質なソフトウェアを作り出すことができ ることもある。こうした背景のもと、アジャイル型のソフトウェア開発が着目されてきている。 アジャイル型開発とは、“Agile and Iterative Development: A Manager’s Guide” （Carig Larman 著）によれば、適応型の計画に従い、タイムボックスを適用しながら反復 型・深 化型の開 発を 行い 、段階的 に リリー ス するも ので あ り、そ のほかに も “機 敏性 （Agility）”を高めるための価値観やプラクティスが含まれると定義されている。すなわち、 70 第二部 第 3 章 （３） “機敏性”（迅速かつ柔軟に変化に対応すること）をポイントとして、ソフトウェアの開発過程 における変化を積極的に受け入れる開発形態である。 ２） アジャイル型開発手法の活用の状況 図Ⅱ- ３-９は、我が国のソフトウェア開発モデルの状況に関する調査結果である。我が国 のソフトウェア開発の多くはウォーターフォールモデルを利用しており、アジャイル型を利用 した開発はほとんど見られない。 （出典）“ソフトウェアの生産性向上のカギを考える”（前川徹、平成 18 年 6 月） 図Ⅱ- ３-９ ソフトウェア開発モデルの状況 また、開発モデルの状況を開発規模別で見ても、規模によらずウォーターフォールモデ ルが利用される開発モデルの多くを占め、アジャイル型はほとんど見られない（図Ⅱ- ３-１０ を参照）。 （出典）“ソフトウェアの生産性向上のカギを考える”（前川徹、平成 18 年 6 月） 図Ⅱ- ３-１０ ソフトウェア開発モデルの開発規模別状況 71 第二部 第 3 章 （３） 他方、米国では、民間のソフトウェア開発のみならず、政府機関が利用するソフトウェア 開発でもアジャイル開発モデルを積極的に取り入れているとする報告がある46。例えば、国 防総省では、もともとはウォーターフォールモデルによる開発を推奨したものの、失敗又は システムが使われずに終わったものが 75％にも上ったことから、スパイラル型による開発手 法を推奨するようになった。食品医薬品局では、こうした国防総省の動きに対応し、医療機 器について推奨する開発手法を、それまでのウォーターフォールモデルからインクリメンタ ルな反復型開発にシフトした。こうした変化を経て、エネルギー省や米国陸軍、航空宇宙局 などのシステムにおいて、アジャイル型開発手法が導入されている。 ３） 契約の在り方 経済産業省策定のモデル契約書<第一版>では、その策定における前提条件として開 発モデルをウォーターフォールモデルとしている。しかしながら、実際の開発プロセスを考 慮し、完全に前工程への手戻りを否定するものではなく、変更管理手続を通じて、情報シス テムの信頼性確保に必要な手戻りと応分の負担について協議するプロセスを設けたところ に本モデル契約書の特徴がある。すなわち、未確定事項の取扱いに係る条項においてシ ステム仕様書を追完又は修正できるものとし、また契約書における役割分担の明確化、同 役割分担にユーザ企業のレビュー項目を設けるなど、ウォーターフォールモデルの適用に 工夫を加えており、必ずしも厳密なウォーターフォールモデルの適用を必須としているもの ではない。また、今後の検討課題として、ウォーターフォールモデル以外の開発モデルが 活用されている実態を踏まえ、多様な開発モデルにおける契約の在り方についての検討を 掲げている。 ４） 今後の方向性 以上を踏まえ、今後、アジャイル型開発手法をはじめとした多様な開発手法を用いること が適している情報システム開発の整理を行った上で、当該開発手法に関するモデル的な 契約書の策定が求められる。なお、その策定にあたっては、アジャイル等の各種の手法の 特徴を踏まえ、委任／請負による従来型の契約とするのか、新たな契約類型とするのかと いう観点の他、その開発体制との関係等についても十分配慮していく必要がある。 また、当該開発手法の適用による効果（品質、生産性、工期等）の実績や、その課題及 び問題点に関する対応策の提供などを行い、アジャイル型開発手法をはじめとした多様な 開発手法の適材適所での活用を進めていくことが求められる。 46 JETRO ニューヨークだより「米国におけるアジャイル・ソフトウェア開発の動向」（渡辺弘美、2005 年 7 月、 http://www.ipa.go.jp/about/NYreport/200507.pdf） 72 第二部 第 4 章 （１） 第４章 情報システムの開発・運用・保守の高度化のための情報共有体制及び 事業継続計画の普及・啓発 （１）運用ノウハウや障害事例、脆弱性関連情報等のデータを収集・分析・活用するため の支援体制整備 削除: の 削除: の ① 運用ノウハウや障害事例等のデータを収集・分析・活用するための支援体制整備 削除: の 等 要求水準に応じた情報システム・ソフトウェアの信頼性及びセキュリティの確保のためには、 開発フェーズでの“見える化・測る化”に加え、運用・保守フェーズでの取組も非常に重要であ る。実際、重要インフラ情報システム信頼性研究会において収集した情報システム障害事例 のうち、開発フェーズに問題あったものは 2 割程度であり、約 7 割が運用・保守フェーズの問 題となっている（図Ⅰ- ８）。米国において行われた調査でもサービス停止の最大の割合は、 操作ミスとなっている（図Ⅱ- ４-１）。 ネットワーク 機器障害 サーバ ハードウェア障害 サーバソフトウェア 障害 操作ミス 6％ 40％ 0% 10% 20% 30% 40% 9％ 34％ 50% 60% 70% 不明 （ネットワーク） 80% 11％ 90% 100% （出典）David Oppenheimer, Archana Ganapathi, and David Patterson. “Why do internet services fail, and what can be done about it?”, In Proc. 4th USENIX Symposium on Internet Technologies and Systems, Seattle, WA, 2003. 図Ⅱ- ４-１ 米国ポータル及びハウジングサービスのサービス障害の原因割合 一方、運用・保守フェーズでは、開発フェーズにおける“見える化・測る化”の指標をそのま ま利用することは困難な面があり、新しい作業目標の設定とその実現のためのアクションが必 要となる。例えば、開発フェーズの“見える化･測る化”で用いられる指標の一つである検出密 度（不良検出件数／全ソースコード規模）は、開発途中で発見されたバグ数を用いた仕様で あるため、運用フェーズでは用いることは難しい。 運用・保守の在り方は、そのサービスの内容や事業規模、直接情報システムの継続性を確 保する以外の事業継続の体制なども関連し、開発フェーズよりも更に個別具体的な事業環境 が大きな影響を受けることになるためである。 こうした条件の下において、関係者が活用できる新しい作業目標を設定するためには、事 73 削除: の 第二部 第 4 章 （１） 例ベースでの情報収集・分析と学習、共有が非常に重要となる。それは、開発フェーズに比 べてどのような指標を用いて PDCA サイクル47を回していけば良いのか、開発フェーズ以上に コンセンサスが存在していないからである。JISA が実施した“信頼性向上のベストプラクティス を実現する管理指標調査”において収集された運用・保守事例での指標数は、開発事例の 指標数の 1∼2 割しかない（図Ⅱ- ４-２）。 （1事例あたりの指標数） （指標数） 700 200 180 指標数：左軸 600 160 500 140 120 400 100 300 1事例あたりの指標数：右軸 80 60 200 40 100 20 0 0 1 開発事例 2 保守事例 3 運用事例 （出典）信頼性向上のベストプラクティスを実現する管理指標調査（JISA、平成 20 年 4 月） 図Ⅱ- ４-２ フェーズ別の管理指標数 こうした運用・保守フェーズにおける問題を克服していくためには、情報システム・ソフトウェ アの開発前から、改修を前提としたアプリケーション設計や自動化によるテストの高度化など の運用・保守フェーズにおける信頼性及びセキュリティを確保していく方法を踏まえて情報シ ステムのアーキテクチャの設計を行い、ドキュメント管理等の環境の整備の在り方を整えておく ことが極めて重要である。こうした取組は、情報システム・ソフトウェアのライフサイクル全般に おける信頼性及びセキュリティの水準の向上に資するとともに、信頼性及びセキュリティに要 するコストの低減にも貢献することとなる。 さらに、運用・保守フェーズにおける信頼性及びセキュリティの水準の向上には、ベストプラ クティスを社会として如何に共有していくかが重要であり、まず、事例ベースで指標を収集す る取組から始めることが必要である。 具体的な事例ベースで幅広く情報を収集・分析し、それに基づき運用・保守の高度化を進 めるための学習、共有を進めるにあたっては、重要インフラ情報システム信頼性研究会共通リ ファレンス検討 WG においても指摘されている“保守運用過程では（特に要求変更が生じた 47 PDCA サイクル：計画（plan）、実行（do）、評価（check）、改善（act）のプロセスを繰り返すマネジメントサイク ル。 74 書式変更: フォント : 9 pt 第二部 第 4 章 （１） 際に）品質コントロールメカニズムが機能し難い点”及び“システム拡張・変更時のアーキテク チャ設計及びシステム検証が不足しがちな点”を改善するという視点が極めて重要である。 要求変更に応じ、保守フェーズにおいてシステムの変更を行う場合、変更箇所は少ないと しても、どのように修正すべきか調査しなければならない範囲は広範囲にわたる。その変更が 悪影響（副作用）を与えていないことを確認するためには、変更に直接関係しない範囲も含め て広範囲にわたってシステム変更に係る調査とテストを行う必要がある。したがって、変更箇 所の量にかかわらず、テストには一定量の工数が必要となる。一方で、システム変更に投入で きる作業量は、変更箇所が少なければ少なく見積もられてしまうことが多く、こうしたことが、保 守フェーズでの品質コントロールを難しくしており、システム検証が不足しがちとなることの原 因となっている。こうした問題を解決するためには、各事業者で行われているベストプラクティ スの共有が有効である。 また、運用・保守を適切に行っていくためには、システム的な保守運用とデータ管理的な運 用を分けて考えるなど、実施している運用・保守の性格について的確に分類して管理しておく ことが重要である。パッケージにデータを登録する際に間違うことと、設定そのものを間違うこと を明確に区分しておけば、それぞれに対して的確に対策を講じることが可能となる。そのため の見える化・測る化を行う効果もより明確に現れてくることが期待される。 さらに、我が国で適切な水準の信頼性及びセキュリティが確保し難い背景として、第 2 章 （1）において記したように投資決定（決裁）を行う経営者等が、情報システムについて必ずしも 詳しいとはいえないという状況を理解しておくことが必要である。こうした状況では、円滑な投 資決定を支える判断材料として他社の事例をベンチマークとして示し、事例ベースでベストプ ラクティスに関する学習、共有化を促進することは、迅速で適切な意思決定に結びつくと考え られ、有効な手段であるといえる。また、このような環境を開発・運用・保守の高度化に利用す ることが重要である。例えば、運用設計時の信頼性・セキュリティを確保するために、運用要員 やオペレーターの操作ミスや過ちを前提（フールプルーフ）とした設計事例、そのリカバリー対 策など運用時の信頼性向上のための方策、あるいはセキュリティホールを回避・リカバリーす るためのセキュリティ設計、セキュリティパッチの実施管理手法などの情報を事例ベースで共 有することが有効と考えられる。 障害事例や運用ノウハウ等に関わる事例を幅広く情報収集・分析し、それを社会全体で学 習、共有していくにあたっては、データの公表、分析を個別の民間企業が自ら行うのは難しい ことから、中立的な立場から情報の機密性を確保しつつ、これらの活動を支援・実施する公的 な中核拠点と実効的な体制を整備していくことが必要となる。 情報収集・分析を行い、共有を進めるための体制には、2 種類のタイプが求められる。第一 は、完全にオープンではなく、事業内容などに関連性が深いある程度限定されたコミュニティ の中で“悩みを共有できる”タイプの情報共有である。現実の経済活動においては、情報の公 75 削除: 、 第二部 第 4 章 （１） 開を前提とした場合、営業機密や個人情報などへの関係性に考慮しなければならないことも 多く、すぐに開示できない情報が少なくない。また、あるサービスを行う事業分野においては 当然となっているようなことであっても、文字にすることが難しいノウハウ（暗黙知）もある。この 削除: 暗黙知 ような条件の下では、単に情報をお互いに共有することを推奨するだけでは、情報システムの 運用・保守の高度化につながっていくような実効性のある情報共有体制を構築することは難し い。したがって、情報の管理や加工についての一定の条件をメンバが合意し、お互いが情報 を提供しやすく、共有をしやすい環境を構築することで、将来の運用・保守の高度化につなが る障害事例分析やベストプラクティスの共有、“見える化・測る化”のための基準の策定などを 推進していくことが有効である。 第二のタイプは、公開されている情報をベースに広く情報収集を行い、大量の情報の分析 を通じてメトリックスを整備しつつ、広く一般に情報公開を行い、我が国全体で信頼性水準の 向上につながっていくようなタイプの情報収集・分析・共有の促進である。第一のタイプのみ では、コミュニティに参加しているメンバにしか効果が及ばず、社会的共通認識を形成する土 壌を整備していくことにつながらない。“安全で安心な高度情報社会”の建設のためには、障 害の発生を未然に防ぐためにより効果の高い第一のタイプのネットワークと、社会全体で情報 を共有し、より高い次元への取組を促進する第二のタイプのネットワークが有機的に機能して いくことが重要である。 このような形で運用・保守の高度化に向けた学習、共有を促進し、高度情報化社会の基盤 を確立するためには、その場限りでデータの収集・分析・公表を行うのではなく、恒久的な体 制の整備で安定的に事業を継続していくことが望まれるため、コミュニティの活動を支援し、ま たそこでの成果、その他のノウハウを整理し公開する中核的機関を中心とした体制の整備が 求められる。また、同時に情報提供を行う企業や組織がコミュニティ活動に参加しやすい環境 を整備することも重要である。 ② 新たなサービス・技術等に対応した運用の高度化 第 5 章あるいは第 6 章で詳しく述べるが、クラウド・コンピューティングという新たなサービス が出現し、それを実現するための様々な技術が提供されてきている。これは利用者から見ると、 ネットワークを通じてサービスを利用する形態となり、具体的なコンピュータ資源（サーバ、スト レージ等）や使われる技術等を意識することはない。言語のローカライズは必要なもののサー ビス化によってグローバル展開の壁も低くなり、ネットワーク経由で世界各国においてサービ ス提供を行う事業者がますます増えて行くであろう。 代表的なクラウドサービスの提供事業者に見られるように、通常、サービス提供事業者は、 コンピュータ資源を集約し、大規模なデータセンタでクラウド・コンピューティングベースの情報 システムを運用し、効率的で費用対効果の高いサービス提供を実現している。しかしながら、 大規模な集約化の進展、また、サービスのグローバル化に伴い、システム障害で利用者に与 える影響範囲は格段に拡大するため、クラウド・コンピューティングにおける高度な運用技術 76 削除: アドホックに 第二部 第 4 章 （１） や手法が必要である。 また、複数のサービスが連携して一つのサービスを提供する場合、どれか一つのシステム 障害によりサービス全体に影響することも想定され、障害原因の究明や迅速な復旧には、こ れら複数の事業者が協力して対応することが必要である。そのためにも、クラウド・コンピュー ティング等によるサービス化が進む情報社会において、運用を高度化するためのノウハウや 削除: の 障害対策の共有など、適切な情報共有体制の在り方についても検討を行うことが重要である。 さらに、契約に関してもサービス開始後のセキュリティ事故に対する責任や補償の在り方につ いても議論が必要である。 ③ 脆弱性関連情報等のデータを収集・分析・活用の支援体制の整備 セキュリティの観点からは、ソフトウェアやウェブアプリケーションの脆弱性について、国内に おける脆弱性に関する情報の流通の枠組みである“情報セキュリティ早期警戒パートナーシッ プ”を通じ、官民における情報セキュリティ対策に関する情報共有・連絡体制の強化を推進し てきたところである。同パートナーシップは、“ソフトウェア等脆弱性関連情報取扱基準”（平成 16 年経済産業省告示第 235 号）の告示を踏まえ、国内におけるソフトウェア等の脆弱性関連 情報を適切に流通させるために作られた枠組みであり、脆弱性の発見者から IPA が情報を受 け付け、対処を行った後、脆弱性情報の公表を行う仕組みである（図Ⅱ- ４-３を参照）。 （出典）「ソフトウェア等の脆弱性関連情報に関する届出状況 [2008 年第 4 四半期（10 月∼12 月）]」 （2009 年 1 月 26 日、IPA、有限責任中間法人 JPCERT コーディネーションセンター） 図Ⅱ- ４-３ 情報セキュリティ早期警戒パートナーシップの枠組みの概要 しかし、本パートナーシップ開始以降も、発見される脆弱性の数は増加している。特にウェ ブサイトの脆弱性については、2008 年後半から届出が急増している。 また、脆弱性が発見される対象が情報家電や組込み機器にも拡大していることから、枠組 77 削除: 仕組 第二部 第 4 章 （１） みに参加するベンダ企業の拡大、脆弱性対策情報のポータルサイトである JVN（Japan Vulnerability Notes）を通じた脆弱性情報の公開、対策方法の啓蒙等の取組を引き続き強 化していく必要がある（図Ⅱ- ４-４を参照）。 削除: （出典）「ソフトウェア等の脆弱性関連情報に関する届出状況 [2008 年第 4 四半期（10 月∼12 月）]」（2009 年 1 月 26 日、IPA、有限責任中間法人 JPCERT コーディネーションセンター） 図Ⅱ- ４-４ 脆弱性関連情報の届出件数の四半期別推移 （２）事業継続計画の普及・啓発 近年発生している地震、火災、大規模な情報システム障害などによる基幹事業の停止は、取引 先や顧客の事業停止などに影響が連鎖するため、思わぬところから企業の存続問題に追い込ま れるケースも見られる。社会が企業に対して要請するのは、その企業が危機に直面した時であっ たとしても事業を遂行（継続）することであり、企業は、自社事業の被害の局限化という観点に留ま らず、コンプライアンスの確保や社会的責任をも考慮した事業継続計画を策定し、対策を講じる必 要がある。その際には、災害時の人への配慮や、お金、もの、情報を含めた経営資源全般への対 策について検討することが重要である。 事業継続に対する重要性の高まりを受け、経済産業省では企業の事業継続計画の策定を支援 するため、2005 年に“企業における情報セキュリティガバナンスの在り方に関する研究会”の成果 物の 1 つとして“事業継続計画（BCP）策定ガイドライン”を公表した。このほか、中小企業庁から “中小企業 BCP 策定運用指針”、“中小企業 BCP（事業継続計画）ガイド”が公表されており、経 済産業省としてはセミナー等における情報セキュリティ政策の説明の機会を活用し、事業継続計 画の策定の重要性について普及啓発を行っている。 しかしながら、内閣府が 2008 年 1 月に実施した“企業の事業継続及び防災の取組に関する実 態調査”の結果によると、事業継続計画を策定済の企業は大企業で 18.9％、中堅企業で 12.4％ であり、策定中の企業をあわせても大企業 35.3％、中堅企業 15.8％にすぎない（図Ⅱ- ４-５を参 照）。また、事業継続計画を知らないと回答している企業は、大企業で 22.7％、中堅企業で 61.2％となっており、米国大企業における事業継続計画の策定率の 6 割と比べてまだまだ不十分 である。その理由としては事業継続計画に対する経営者や現場の意識が低い、策定に必要なノウ 78 改ページ 第二部 第 4 章 （２） ハウ・スキルがないということが指摘されている。 こうした状況を踏まえ、経済産業省では、IT に係る部分について記述することで、事業継続計 画策定の実施内容を具体化し現場の理解促進を図った“IT サービス継続ガイドライン”を 2008 年 に公表した。今後は、本ガイドラインの普及を目指すとともに、経営者の事業継続計画に対する意 識を高めていくため、“事業継続計画（BCP）策定ガイドライン”についてのセミナー等を通じて普 及啓発を行っていく必要がある。特に、事業継続計画の認知度の低い中小企業に対しては、中小 企業の IT 利活用・情報セキュリティ対策の支援等を行っている全国の商工会議所の職員、商工 会職員、EC 実践講師、IT コーディネータ等を対象に実施している“中小企業情報セキュリティ指 導者育成セミナー”において本ガイドラインを紹介し、中小企業への IT 利活用・情報セキュリティ 対策の支援を通じて経営者の事業継続計画に対する意識を高めていく必要がある。 BCP の策定に関しても、第二部第１章（２）で述べたシステムプロファイリングの考え方と同様に、 情報システム・ソフトウェアに求められる要求水準に応じて、あるいは業種・業態毎に適切な BCP レベルを策定するべきである。 また、BCP を策定するだけでなく、様々なトラブル場面を想定して継続的な訓練を実施し、情報 システム障害等の緊急時において、計画通りに業務を継続できることが重要である。 （出典）企業の事業継続及び防災の取組に関する実態調査（内閣府） 図Ⅱ- ４-５ BCP の策定状況 79 削除: は策定するとともに 第二部 第 5 章 （１） 第５章 複雑化する情報システム・ソフトウェアの信頼性及びセキュリティの 水準を高度化するための新たな技術課題への対応 （１）アーキテクチャ記述言語や形式手法 ① アーキテクチャ記述言語、形式手法とは 複雑化する情報システム・ソフトウェアの信頼性を確保するための手法に、アーキテクチャ 言語や形式手法がある。第 1 章で記述したように、情報システムに障害が発生する重要な要 削除: 記載 因に、“要件定義が不十分”であることがある。アーキテクチャ記述言語や形式手法は、この “曖昧な要件定義”という問題を解決することで、システムの信頼性を担保する手法ということ ができるであろう。また、曖昧さが無い仕様であれば、そこからプログラムを自動生成することも 可能である。これも、ソフトウェアの不具合（バグ）の削減に貢献すると考えられる。 アーキテクチャ記述言語とは、ソフトウェア・アーキテクチャやシステム・アーキテクチャを記 述するためのコンピュータ言語である。要件定義又は基本設計フェーズにおいて、システムを 構成するコンポーネント間の関係を示すアーキテクチャは、図を用いて表現されることが一般 的である。図を用いてシステムのコンポーネント間の関係を示すことで、システムの全体像をモ デルとして示すのである。これは、開発者などがシステムの全体像を直感的に把握し、自らが 担当する部分と他の部分との関係を迅速に理解するのに大きく役立つ。しかしながら、自由度 が極めて高く、内容に矛盾がないかどうか、記載されていることが十分かどうか等の確認が難 しいという欠点を持っている。一方、アーキテクチャ記述言語は、明確に仕様が定められた言 語を用いてアーキテクチャを定義（記述）するものであり（ただし、図も用いることができるもの が多い。）、一般的な図を用いたアーキテクチャ記述の欠点を回避することができる。 次に、形式手法は、“数学”を基盤としたソフトウェア及びハードウェアシステムの仕様記述、 検証の技術であり、開発工程でエラーが入り込んでいないことを保証することができるもので ある。最もシンプルな形式手法は、システムが行うべきことを Z 記法48、VDM49、B メソッド50等 の仕様記述言語を用いて記述する。アーキテクチャ記述言語が、アーキテクチャを形式的に 言語で記述するのに対して、形式手法はより詳細な仕様まで形式的な言語で記述するものと いえる。 また、実装が仕様を満たしていることを完全に機械的に検証するために、形式手法が用い られることもあり、SPIN51、SMV52等の手法がある。 ② 欧州で進むアーキテクチャ記述言語、形式手法の利用 形式手法は、その発祥の地である欧州において、鉄道（パリ地下鉄等）などの管理・制御シ 48 49 50 51 52 Z 記法：オックスフォード大学で Abrial らによって開発された形式仕様記述言語。 VDM：Vienna Development Method の略。IBM のウィーン研究所で開発された形式手法。 B メソッド：フランスおよびイギリスで Abrial らによって開発された形式手法。 SPIN：ベル研究所で Holzmann らによって開発された形式検証ツール。 SMV：カーネギーメロン大学で Clarke らによって開発された形式検証ツール。 80 削除: は 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 書式変更: フォント : 9 pt 第二部 第 5 章 （１） ステムを中心に重要インフラへの適用が進んでいる。具体的には、パリ地下鉄 14 号線の自動 運行プログラム、シャルル・ドゴール空港シャトルの自動運行プログラムが有名である。形式手 法を用いることで 9 割以上の仕様の詳細化、プログラム化が正しく行われたことが自動で証明 されている。 本分野に関しては、欧州においては、第 6 次 EU 研究開発枠組み計画（FP6)、第７次 EU 研究開発枠組み計画（FP7）の下でプロジェクト化が行われるとともに、学界においても、ケン ブリッジ大学など英国を中心とする教育・研究機関で人材育成、先端研究に係る取組が行わ れているところである。例えば、アーキテクチャ記述言語に関しては、FP7 において、2008 年 7 月から 2 年間の予定で ATESST2 プロジェクトが実施されている。これは、全身の ATESST プロジェクトで開発されたアーキテクチャ記述言語（EAST-ADL2）を用いて、効率的な開発、 確認と検証を行うための手法と方法論の構築を目指すものである。また、形式手法に関しては、 FP6 の下での RODIN プロジェクトにおいて B メソッドを用いたツール開発が行われ、その開 発環境を情報システムに適用するためのプロジェクトが FP7 の下で行われている（DEPLOY プロジェクト）。 ただ、全体的に見れば、組込み系への適用が多く、エンタープライズ系の情報システムで は、アクセス制御機能やセキュリティ機能など限定的な適用に留まっている。組込み系におい ては、周囲環境、要求がエンタープライズ系に比べて格段に明確であることから、信頼性確保 のためにアーキテクチャ記述言語や形式手法といった技法を適用しやすい。一方、エンター プライズ、管理系の情報システムにおいては、それらが曖昧なケースもあり、要件定義やその 前の業務分析等のフェーズで、きちんと用語を定義しながら、誤解がないように検討を進めて いくことからまず始めることが必要となる。 ③ 我が国でもパイロットプロジェクトに取り組むべき時期に 我が国でも、仕様の曖昧さをなくすことを目的に仕様記述言語を用いて IC カードの外部仕 様が書かれた例などがある。このケースでは、開発工程で検出した不具合原因において、仕 様の記述誤りが原因であったのものは 0%であり、仕様不明瞭が原因であるものも 1.8％であ った。このような事例はあるものの、欧米に比べると産業レベルでの形式手法の利用は進んで いないといわざるを得ない。 形式手法やアーキテクチャ記述言語の利用は、開発プロセスの大幅な変更を求めるもので あり、抽象化等を必要とし、これまでのプログラミングとは異なるスキルが必要となる。そのため、 その導入にはハードルが高いのは事実である。一方で、近年は完全な検証を目的とするので はなく、品質の向上を目的として、コードレビューやテストの負担軽減を目的に形式手法を用 いるという動きも出てきている。 欧米では、政府の研究開発プロジェクトを通して産業界での利用を促進している状況があ る。特に欧州では、前述の DEPLOY プロジェクトにおいて、運輸、自動車などの産業界と連 携して、形式手法の適用が試行されており、先進的なソフトウェアエンジニアリング手法の確 81 削除: な 第二部 第 5 章 （１） 立と実用化が進められている。そのため、我が国においても、高信頼な情報システム・ソフトウ ェアを構築していくため、アーキテクチャ記述言語や形式手法といった技法の開発に取り組む べきである。その際には、産業界と連携し、形式手法の適用領域、開発現場への適用可能性 を考慮しつつ、開発を進めることが重要である。 また、形式手法を本格的に普及していくために、人材育成も目的としたパイロットプロジェク トに取り組むべき時期に来ているといえる。そのようなプロジェクトを通じて、形式手法等の適 用効果を実証していくとともに、導入負荷を低減し、現場への浸透を促進するための方策を検 討する必要がある。 （２）新たな開発手法・技術への対応（アジャイル、MDA、テスト等） ① 様々なタイプの開発手順に適したエンジニアリング手法の開発が必要 我が国の従来のソフトウェアエンジニアリングは、ウォーターフォール型の開発を前提にした 手法が多く見られた。しかし、情報システム・ソフトウェアの開発形態の多様化に伴い、様々な タイプの開発手順に我が国としても対応していく必要がある。ウォーターフォール型以外の開 発に対応していくためには、第 3 章（2）③で提言した契約の在り方のみではなく、技術的な対 応も必要となってくる。また、新たな技術を用いた開発を適切に管理するためのプロセスの検 討、人材育成等も進めていく必要がある。 ソフトウェアの開発に関する方針・原則には、“ウォーターフォール型”と“非ウォーターフォ ール型”の 2 つの方向性がある。『“計画重視型”と“適応的開発型”』、『“正統的開発方法”と “軽量開発方法”』などと呼ばれることもある。ウォーターフォール型は、まず作業全体の計画 を立て、その計画通りに作業が進捗しているかどうかを常に管理することを重視する。そして、 それぞれの工程で次工程に必要充分なドキュメント類を作成し、手戻りが発生しないようにレ ビューし作業を進めていくのが原則である。 一方のプロトタイピング型、モックアップ型、インクリメンタル型などの非ウォーターフォール 型は、現実の変化にすばやく適応することを重視している。 実際のソフトウェアの開発過程においては、ソフトウェアの活用範囲が急激に拡大する中、 非ウォーターフォール型が適したソフトウェア開発もあると考えられ、ユーザ企業からのニーズ もある。そのため、非ウォーターフォール型を採用した場合にも品質、信頼性を確保できるよう に、ソフトウェアエンジニアリング手法を改良・開発する必要がある。例えば、アジャイル的にソ フトウェア開発を実施するための手法としては、エクストリーム・プログラミング（XP）、スクラム、 アジャイル・モデリング等の手法が提案されている。 ただし、実際のソフトウェア開発では、ウォーターフォール型と非ウォーターフォール型の原 則をミックスした様々な開発プロセスモデルが用いられていることに留意する必要がある（図Ⅱ - ５-１を参照）。 82 第二部 第 5 章 （２） ウォーターフォール型 計画重視型 正統型 非ウォーターフォール型 適応型 軽量型 プロセスモデル例 ウォータフォール型 プロトタイプ型 デイリービルド型 文字だけで要件定義 主要部の動きを見せて要件定義 毎日構築・毎日テスト モックアップ型 インクリメンタル型 見た目をそっくりな画面で要件定義 数回に分けて機能をリリース パッケージ利用 の有無による違い パッケージ利用型 パッケージとのフィットギャップで要件定義 XP 開発手法例 構造化手法 オブジェクト指向 スクラム Agile Modeling 図Ⅱ- ５-１ 開発のライフサイクルモデルとそれに伴う開発手法のイメージ・例 アジャイル的な開発の場合には、それに適したテストの方法等、ウォーターフォール型の場 合とは異なるテスト環境、ツールが必要となる。具体的には、アジャイル的な開発では、頻繁 にプログラムに変更を加えるため、随時テストを行うことが重要となる。ウォーターフォール型で は求められる機能を洗い出し、すべての機能を実装したソフトウェアを開発するが、アジャイル 的な開発では限られた機能の動くプログラムをまず作成し、それから機能を追加していくという アプローチをとる。動くソフトウェア、動いているソフトウェアが進捗の最も重要な尺度となるた め、随時稼働し、バグを含まないソフトウェアであることを確認することが重要となる。そのため、 ウォーターフォール型に比べて早期にかつ繰り返しテストを行う。そのため、テストの実施回数 も増加し、テストの自動化が生産性に大きな影響を与えるようになるのである。このため、ソー スプログラムから実行可能ファイルを作成する作業の自動化、テストツール等の技術にも対応 していく必要がある。 また、パッケージソフトウェアを用いる場合には、スクラッチでシステムを開発する場合とは 異なるプロセスモデル（パッケージ活用型）が用いられる。パッケージの機能とユーザ要求の フィットギャップ分析等を通してシステムの仕様を固めていくことになる。テンプレートやパッケ ージを基にして議論をすることで、漠然とした要件定義に比してはるかに正確でミスのない業 務プロセスの設計が可能となる。そのため、バッケージやテンプレートというものを受け入れる 土壌、意識の改革がユーザ企業サイドにも求められる。“IT を用いて現状を改善する”ことの 必要性、パッケージソフトを用いた業務改善の必要性については、第 2 章（2）で触れたところ である。 さらに、運用フェーズで高い信頼性を実現するためには、人と情報システムの複合系の設 計技術（フォールトトレラント設計技術など）の検討も必要である。 83 第二部 第 5 章 （２） このように様々な手法、プロセスモデルに対応できるようにした上で、既存の開発手法、テス ト手法も組み合わせつつ評価・検証を行い、適用する際の特性や条件、規模の制約、品質要 求や納期を考慮して適切なプロセスモデル、開発手法を選択できるようにしていくことが重要 である。 ② MDA 等の新技術への対応 モデルドリブン開発（MDA : Model-Driven Architecture）も大きな技術の潮流である。 MDA では、モデルからコードを自動生成するため、コードをプログラマが記述する従来の方 法とはシステムの信頼性担保の考え方が異なってくる。そのため、管理手法等を含めた開発 が必要である。また、情報システムと組込み機器が連携するインフラシステムにおいては、そも そもモデリングの考え方や手法自体を検討する必要がある。 より具体的には、MDA とは、特定のプラットフォームの種類に依存しないモデル（PIM : Platform Independent Model）をまず設計し、それから特定のプラットフォームに特化した モデル（PSM : Platform Specific Model）を変換ルールにより自動作成するという開発方法 論である。通常、PSM からソースコードも自動生成される。そのため、プログラマや SE が書か なければならないコードの量が格段に減少する。 一方で、PSM やコードを自動生成するルールを構築するハイレベル SE が情報システムの 品質・信頼性に果たすべき責任が大きくなるとも考えられる。このように、MDA は情報システ ムの品質保証プロセスに変化をもたらす可能性もあり、管理手法を含めた開発が必要であろ う。 ③ ソフトウェアトレーサビリティの確保 さらに、ソフトウェアがどの程度信頼できる品質を持っているのかを見えるようにするために、 “いつ、どこで、誰が、どのように”開発したものであるかというトレーサビリティ情報であるソフト ウェアタグの高度化と現場への適用を検討する必要がある。 ソフトウェアタグの利用目的には、主に製品品質の把握、開発状況の把握、紛争処理があ る。 削除: ⅰ） 削除: ⅱ） 製品品質の把握は、一般に流通しているソフトウェア製品の保証書としてソフトウェアタグを 利用するものである。第 1 章で記した“見える化･測る化”の指標（メトリクス）の値をソフトウェア 削除: ⅲ） の購入企業が知ることができれば、購入企業はそのソフトウェアの信頼性を把握することがで 削除: ⅰ） きる。また、実際に開発した企業を知ることも可能になる。開発言語、開発プロジェクトの規模 等の情報もソフトウェアタグに加えることも考えられる。 開発状況の把握は、受注に基づきソフトウェアの開発を行っている際に、その進捗状況を 削除: ⅱ） 発注企業に伝えるためにソフトウェアタグを用いるものである。“見える化･測る化”の結果をユ ーザ企業とベンダ企業で共有するための取組ともいえる。 紛争処理の際のソフトウェアタグの利用は、第一に事故が発生した際に原因を究明し、改 84 削除: ⅲ） 第二部 第 5 章 （２） 善に結びつけるためのものである。第二に、法的係争時に責任の所在を明らかにするために 用いることも考えられる。ソフトウェアは、複雑な受発注構造で開発されることも多く、実際の開 発者を把握し難いという特性がある。タグが階層構造化されていて、それぞれの企業の役割 が明確になっていればこうした不明瞭さを解消することができる（図Ⅱ- ５-２を参照）。 （出典）ソフトウェアタグ規格 第 1.0 版 （StagE プロジェクト 奈良先端科学技術大学院大学、大阪大学、2008 年 10 月 14 日） 図Ⅱ- ５-２ 製品品質の把握のためのソフトウェアタグの利用イメージ （３）頑健なシステム・アーキテクチャの開発（クラウド基盤、オートノミック等） 本中間報告書のメインメッセージの一つは、第一部で提示したように『利用者がサービスの内容 とリスク、コストについて納得しその期待通りにサービスが提供されている状態が、“信頼性及びセ キュリティが確保されている状態”である』ということである。これは、利用者が求めるサービスレベル を利用者が納得したコストで提供できている状態と言い換えることもできる。したがって、安全で安 心な高度情報化社会を実現するための技術的ニーズとしては、信頼性の向上は当然ながら、ユー ザニーズに応じた SLA 水準に合わせた信頼性を自動で確保できる技術の開発が重要である。ス ケーラビリティやリアルタイム性、稼働率などは SLA 水準によって異なるため、利用者から求められ るレベルに応じてクラウド基盤をアレンジ（構成変更）できるような技術の確立が必要である。 例えば、サーバなどの資源を仮想化し、故障時には自動的・自律的（オートノミック）に他の資源 を利用可能にする（プロビジョニングを行う）ことでシステムの信頼性を確保する方向が一つの技術 トレンドになっている。こうしたことが実現できるシステム基盤が、クラウド基盤と呼ばれるようになっ ているといっても良い。技術のポイントは、仮想化と自動化・自律化である。特に我が国の国際競 争力という視点からは、自動化・自律化の技術に課題があり、技術力の向上が求められる。 上記のようなクラウド基盤の実現及び普及のための技術課題としては、バーチャルマシン（VM） のセキュリティ確保・パフォーマンス最適化、運用管理・監視ミドルウェアの高度化（SLA 水準に 基づくリソース自動割当・拡張、複数拠点間の協調動作、システムダウン時の動的再構成、障害検 85 削除: ⅰ） 削除: ⅱ） 第二部 第 5 章 （３） 出等）、ネットワーク仮想化等がある。また、リアルタイム性の確保への技術的ニーズも強い。 バーチャルマシン（VM）のセキュリティ確保・パフォーマンス最適化は、サーバの仮想化を行うこ 削除: ⅲ） 削除: ⅰ） とで、同じ筐体の上で異なるユーザ企業が用いる仮想サーバが稼働することに伴うセキュリティ上 の懸念を解決するための技術の開発などである。仮想サーバも、物理サーバと同レベルに相互の アクセスが制御されていなければならない。パフォーマンス最適化は、仮想化に伴う処理による性 能の低下を防ぐ技術の開発などである。 運用管理・監視ミドルウェアの高度化においては、SLA 水準に基づくリソース自動割当・拡張が 削除: ⅱ） 一つの大きなポイントになると考えられる。これが実現できれば、人手で監視、コントロールすること なくユーザ企業が求めるサービスレベルを自動で実現できるようになる。 ネットワーク仮想化は、先行して利用が進んでいるサーバの仮想化やストレージの仮想化に加 え、ネットワークについても仮想化を進めようというものである。ネットワークは、物理的な場所（線） に応じてパケットをルーティング（割り振る）するため、仮想化によってサーバを容易に別のロケーシ ョンに移せたとしても、ネットワークが仮想化されていないと、そこにはパケットが届かないことになっ てしまう。ネットワークの仮想化も進めることによって、クラウド基盤がより利用しやすいものになる。 さらに、それらの技術基盤を開発していくための開発環境（サービス主導型の仕様記述・リソース 割当ポリシー、フレームワークなど）も検討すべきである。クラウド基盤の相互運用性が確保される ような仕様記述法、共通的なポリシーが必要となるであろうし、また、クラウド基盤上のソフトウェアを 高信頼に開発するための手法、ツール等も必要となってくるであろう。 また、ユーザ視点に立てば、収集・分析しやすい形でデータを構造化し、利用の履歴管理等を 行うとともに、データを安全に管理することも求められる。さらに、複数のベンダ企業を利用する際 の請求・支払の仕組み等を自動化する必要がある。 86 削除: ⅲ） 第二部 第 5 章 （３） コラム EU RESERVOIR の概要 ネットワークとストレージの境界をまたがって移行を可能とする技術（仮想マシンと仮想 Java サービスコンテナの両方）の開発 SLA に基づく要求に適合するように資源を割り当てるためのアルゴリズム 異なる複数の RESERVOIR サイト間で、サービスの配備とライフサイクルマネジメントを可 能のするためのサービス主導型の使用記述の仕様作成 異なる物理マシン及び異なる RESERVOIR サイトにおいて、安全に仮想マシンを配置し、 移動させるためのセキュリティの仕組み 資源の利用（1 サイト若しくは複数サイトでの利用）に対して課金するためのビジネス・インフ ォメーション・モデルと請求・支払の仕組みの開発 実際の産業界における利用をベンチマークするためのテストベッドの開発 ビジネス指向のサービスマネジメントに基づく、仮想化技術とグリッド・コンピューティングの統合 が、サービス・オリエンティッド・インフラストラクチャである（図Ⅱ-5-3 を参照）。 仮想環境を認識しているグリッド 例：計測及び課金の単位にVMを使用 ＋ グリッドを認識している仮想環境 例：管理ドメインを越えた移行 ＋ ビジネス指向サービスマネジメント 例：SLAのポリシーベースの管理 ＝SOI 図Ⅱ- ５-３ RESERVOIR における SOI（The Service Oriented Infrastructure） （４）複雑化・多層化するアーキテクチャへの対応 規模が急拡大し複雑化する情報システムや組込みシステムにおいては、メカとソフトの融合、ソ フトとエレクトロニクスの融合、インフラと製品の協調といった複雑化・多層化が進んでいる。その ため、そのような複雑化・多層化したアーキテクチャの開発に対応できる高信頼な設計・検証・モデ リング・テスト技術等の開発及び研究開発体制の整備を産学官が連携して進めていくことが重要で 削除: ⅰ） 削除: ⅱ） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 ある。 まず、インフラと製品の協調に関しては、運輸、金融、流通などの重要インフラを担う情報システ ムと自動車、携帯電話などの組込み機器が連携して経済活動、国民生活を支えるシステムとして 削除: ⅲ） 稼働するようになっている。すなわち、車載制御システム、カーナビ等の車載機器と情報システムと 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 の通信などを利用した連携が一層深まり、センタ側へのアプリケーション配置が進むと考えられる。 削除: ⅲ） すなわち、従来は車載制御機器やカーナビという機器単独で処理が行われていたのに対して、今 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 後は携帯電話回線等を通してカーナビがセンターと随時通信を行い、機器側とセンター側で連携 して情報処理が行われるようになっていく。そうなれば、センタ側のシステムや携帯電話回線にも車 載制御での使用に耐えうる応答性・信頼性・セキュリティレベルを確保できる技術が必要となる。そ のため、情報システムと組込みシステムを連携させた統合システムの信頼性を確保するため、統合 87 第二部 第 5 章 （４） システム向け開発手法、ツール、管理手法等の検討が必要となっている。 さらには、道路や信号機などのインフラ側と自動車が連携して事故等を防止するインフラ協調型 システムへの期待も強い。これは、インフラ側から情報を得ることによって、運転手からは見通すこ とができない車や人との事故も防ごうというものである。この場合、インフラ側での情報処理と車側 での情報処理が複雑に連携することになる。 メカとソフトの融合、ソフトとエレクトロニクスの融合に関しては、自動車などの単体として見た場 合でも、メカ（アクチュエータ等）、エレクトロニクス（マイコン等）、ソフトウェアが相互に連携して、機 能を実現する場合が大部分である。 このようなメカ・ソフト・エレクトロニクスの融合は、自動車が最も典型的な事例であるが、自動車 削除: ⅰ） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 削除: ⅱ） 業界に限られたものではなく、組込み機器全般にあてはまることである。デジタルカメラや DVD レ 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 太字 コーダーなどの情報家電から、産業機械までソフトウェアが占める割合は増加し、ソフトウェアで制 書式変更: インデント : 最初の行 : 1 字 御するエレクトロニクス、メカ部品も含めたアーキテクチャは複雑化・多層化している。他方で、最終 製品に関する短納期化、高品質化へのニーズは高まる一方である。メカ、エレクトロニクス、ソフトウ ェアを個別にシークエンシャルに設計・開発・検証していくプロセスでは、そのようなニーズの変化 に対応していくことが厳しくなってくることも予想される。 そのため、メカ、エレクトロニクス、ソフトウェアをトータルで見て高機能化・高信頼化を実現するこ とが全体最適となることから、その実現のための開発手法・ツール等の検討が必要である。 例えば、モデリング技術等を用い、メカ部品とソフト制御とをバランスさせて高機能化・高信頼化 を実現するための開発手法・ツールの検討などが望まれる。また、開発手法・ツールに合わせて、 それらを用いる場合のプロセス、スキル管理手法なども整備していく必要があると考えられる。開発 手法・ツールが開発現場で役立つようになるためには、それらを利用できる人材の育成、また利用 にあたっての管理ができるようにならなければならないからである。 また、車載制御系では、現在、制御系基盤ソフトウェアの開発が進行中であるが、その基盤ソフ トウェアを実装するハードウェアも含めたシステム全体の統合開発も検討すべきであり、そのための アーキテクチャや開発手法などの検討も重要である。 このように、複雑化・多層化するアーキテクチャへの対応は、我が国の製造業の国際競争力に 直結する課題でもあり、産官学が連携して開発体制の整備を進めていくことが重要である。その際 には、国際標準化も見据えつつ検討を進めていくことが必要であり、国の果たすべき役割が大きい と考えられる。 88 第二部 第 6 章 （１） 第６章 クラウド・コンピューティング等の新たなサービスにおける信頼性及 びセキュリティの確保の在り方 （１）クラウド・コンピューティング等の新たなサービスの出現 インターネット技術等の進展に伴い、クラウド・コンピューティングという新たなサービスが注目を 集めている。かつて、主にメインフレームという中央集中型で大型のコンピュータが情報処理を担っ ていた時代から、多数のパソコンという分散型で小型のコンピュータが担う時代に推移し、現在、イ ンターネット越しのデータセンタ等で一括して担う、中央集中型ともいえる形態に推移しつつある。 “クラウド・コンピューティング”という用語は様々な定義で使用されているが、一般的に、“情報処 理のための複数の資源（サーバ、ストレージ等）を、具体的な資源を意識することなく使えるよう、ネ ットワークを通じて提供（利用）する形態”ということができる。クラウド・コンピューティングは、初期コ ストが削減できること、迅速なサービス提供（利用）開始が可能であること、柔軟に利用する資源の 量を変えることができること等から、今後の普及が期待される。 クラウド・コンピューティングには、提供するサービスの範囲に応じて、IaaS（HaaS）、PaaS、 SaaS 等の種類があり、また、単一の利用者にサービス提供するものから、複数の不特定な利用者 にサービス提供するものがある。 IaaS（Infrastructure as a Service）は、仮想サーバやストレージなどの基盤をサービスとして 提供するものであり、Amazon の EC2、S3 等が代表的である。利用者は仮想サーバに OS、アプリ ケーションなどをインストールして利用する。PaaS（Platform as a Service）は、IaaS に加え、仮 想サーバ等を適切に管理するミドルウェア等もあわせて提供するものであり、アプリケーションを開 発するための開発環境、開発したアプリケーションを稼働させる環境等をサービスとして提供する （図Ⅱ- ６-１を参照）。Salesforce.com の force.com、Google の Google App Engine 等が代表的 である。SaaS（Software as a Service）は、PaaS に加え、アプリケーションまでをサービスとして提 供 するも のであ り、利用者は独 自に開発 することなくサー ビスを 利用す ること ができる。 Salesforce.com の CRM（顧客管理）サービスが代表的である。 ユーザデータ ユーザデータ IaaS ユーザ開発AP ユーザ選定MW ユーザ選定OS 仮想サーバ（HW） PaaS ユーザ開発AP ユーザデータ SaaS ベンダ選定/開発MW ベンダ選定OS ベンダ選定サーバ（HW） ベンダ開発AP ベンダ選定MW ベンダ選定OS ベンダ選定サーバ（HW） 図Ⅱ- ６-１ IaaS、PaaS、SaaS のイメージ また、クラウド・コンピューティングは、パブリック・クラウドとプライベート・クラウドに分類されること もある。パブリック・クラウドは、Amazon の EC2、S3 や Google のサービスのように、コンピュータ資 89 第二部 第 6 章 （１） 源をサービス提供者が所有し、複数の利用者が資源を共有して利用する形態である。一方、プラ イベート・クラウドは、コンピュータ資源を利用者が所有する形態である。これらの中間的な形態とし て、契約等を締結した特定の複数の利用者がコンピュータ資源を共有して利用する形態があり、エ ンタープライズレベル・クラウドと呼ばれることがある。この場合、データの保存場所や共有する資源 等を契約により制限することも可能である。 コンピュータ資源を利用者が自ら所有しないパブリック・クラウド、エンタープライズ・クラウドの場 合、利用者が認識するサービスは、実際には様々な事業者によって担われる個々のサービスの総 体であることが少なくない。したがって、クラウド・コンピューティングを通じたサービスは、最終利用 者から見た場合に一つのサービスの責任が分散していく動きと、逆にサービス提供側から見た場 合には複数のサービスが最終利用者に直接提供する仲介者によって集約され、責任関係を調停 される動きと、二つの性格を持つビジネス・モデルを背景とした形で提供されていくことになる。利 用者側から見た場合とサービス提供者側から見た場合のこの違いをどのような形でバランスさせる のかが、クラウド・コンピューティングの活用が拡がるための一つの重要な要素となり、サービスの在 り方に関わる国際的な標準化が進んでいく原動力ともなっていくことが予想される。 クラウド・コンピューティングと一口にいっても、サービスの対象や利用形態によって、利用者側と サービス提供者側の責任に関する考え方のバランスは異なり、その信頼性及びセキュリティの確保 の在り方も大きく異なることから、そのことに留意することが必要である。 （２）利用者に対する信頼性・セキュリティ水準の確保 ① SLA 締結の重要性 クラウド・コンピューティングは、ネットワーク経由で提供されるサービスであり、利用者は利 用しているサーバの構成等を詳細に把握できない。このため、サービスの信頼性・セキュリティ レベルが不明瞭となる傾向がある。サービスの信頼性・セキュリティレベルが不明瞭な場合、 利用者はリスクの管理ができず安心してサービス提供を受けることができないため、クラウド・コ ンピューティングの利用においては、サービス提供者が信頼性・セキュリティを含めたサービス レベルについて利用者に明示し契約内容に加えることが重要となる。 また、システム障害が発生し、サービス停止等が生じた場合、契約フェーズで補償の在り方 について合意がなされていないと、サービス提供者と利用者の間でトラブルに発展するおそ れがある。このため、クラウド・コンピューティングにおける契約においては、信頼性・セキュリテ ィを含めたサービスレベルに加えて、障害が発生した時の補償内容も明示して契約内容の一 部にすることが重要である。 なお、今回実施したアンケート調査53では、クラウド・コンピューティングを利用する際の懸 念として「セキュリティ対策が十分かどうかわからない」、「サービスレベルが不明瞭である」など の回答が多く挙げられており、クラウド・コンピューティング利用において信頼性・セキュリティ 53 従業員 300 人以上の企業に勤める社員で、社内向のソフトウェア開発、システム開発・運用・保守に携わる方 500 人を対象に Web アンケートにより調査を実施（２００９年３月） 90 第二部 第 6 章 （２） への不安が大きな課題となっていることが伺える（図Ⅱ- ６-２を参照）。 セキュリティ対策（情報漏洩対策等）が十分かどうか分からない 情報システムを自社で構築・保有するのに比べ、本当にコストダウンするか分からない 社内システムとの連携が困難である サービスレベルが不明瞭である サービスレベルが保証されていない 情報システムを自社で構築・保有するのに比べ、障害発生時に迅速に、柔軟に対応できない サービス提供を中止される可能性がある 他社のサービスに移行するのが困難である 内部統制のルールに適合しない データ等を保存するデータセンターが海外に立地している サポートが十分でなく、利用に高いスキルを必要とする クラウドの利用判断に直接関わること になると想定される回答者 特に懸念していることはない その他 運用担当者等、利用判断には直接関 わらないと想定される回答者 0% 10% 20% 30% 40% 50% （出典）Web アンケートにより 500 人を対象に調査を実施（２００９年３月） アンケート回答者は、従業員 300 人以上の企業に勤める社員で、社内向のソフトウェア開発、システ ム開発・運用・保守に携わる方54。 図Ⅱ- ６-２ クラウド・コンピューティングの利用を控える理由・利用にあたっての懸念 クラウド・コンピューティングにおいて提示されているサービスレベルの現状は、例えば、 Amazon の EC2 の稼働率が 99.95%、Google の Gmail の稼働率が 99.9％である（表Ⅱ６-１、表Ⅱ- ６-２を参照）。 このように、既にサービスレベルの提示、SLA（Service Level Agreement）の締結は一部 で行われているものの、稼働率の定義が不明確である場合や、データの完全性、機密性等の セキュリティに関するサービスレベルの提示が欠落している場合など、現状の SLA は必ずしも 十分ではないと考えられる。また、サービスレベルは提示されているものの、補償されていな い場合や、補償を受けるために、稼働率が提示されているサービスレベルを満たしていないこ とを利用者が詳細に証明しなければならない場合等があり、こうした観点からも現状の SLA は 不十分である。 今回実施したアンケート結果では、半分以上の回答者がサービスレベルの目標ではなく、 稼働率等の保証が望ましいと考えている。また、特に基幹系システムに関しては、電子メール や情報系等のその他の情報システムに比べて、被害相当額の補償が必要と考えている回答 者の割合が高く、半数を超えている（図Ⅱ- ６-３、図Ⅱ- ６-４を参照）。 54 「クラウドの利用判断に直接関わることになると想定される回答者」は、「クラウド・コンピューティングの導入に関 し、実質的な判断を行う」又は「クラウド・コンピューティングを導入するにあたり、必要な機能の洗い出しや詳細な評 価を行う」ことでクラウドに関わる可能性があると答えた方で、回答者数は 276 名。「運用担当者等、利用判断には 直接関わらないと想定される回答者」は、それ以外の回答者で、回答者数は 224 名。 91 60% 70% 第二部 第 6 章 （２） 0% クラウドの利用判断に直接関わることになると想定される回答者 運用担当者等、利用判断には直接関わらないと想定される回答者 20% 40% 60% 58% 29% 11% 100% 54% 30% 16% 80% 実際のサービスレベルが高ければ、稼働率等の目標提示は不要である 稼働率等の目標が提示されている必要がある 稼働率等が保証されている必要がある その他 （出典）Web アンケートにより 500 人を対象に調査を実施（２００９年３月） 図Ⅱ- ６-３ クラウド・コンピューティングにおいて妥当と考えられるサービスレベルの提示方法 0% 10% 20% 19% 電子メール 30% 40% 50% 60% 28% 70% 33% 80% 90% 100% 17% 不要 利用料金に対する割合（％） 被害相当額 基幹業務系 11% 19% 55% 13% わからない その他 その他（情報系等） 23% 21% 35% 20% （出典）Web アンケートにより 500 人を対象に調査を実施（２００９年３月） （注）“クラウドの利用判断に直接関わることになると想定される回答者”における割合 図Ⅱ- ６-４ クラウド・コンピューティングにおいて必要とされる補償レベル こうした状況を鑑みると、企業活動において今後クラウド・コンピューティングが本格的に利 用されるためには、SLA の充実が極めて重要である。 また、クラウド・コンピューティングが広範囲に利用され始めた場合、その障害時の影響は企 業レベルではなく、社会全体のレベルに拡大することが想定される。このため、利用するクラウ ド・コンピューティングの用途に応じて、サービス提供者がどの程度の信頼性・セキュリティを 確保し、また、説明責任を果たし、一方、利用者がどの程度のリスクを受容するのかについて、 一定の社会的合意形成を図ることが重要である。 さらに、特定のクラウド・コンピューティングの利用を継続した場合、利用者の当該クラウド・ 92 第二部 第 6 章 （２） コンピューティングへの依存度が高まることから、利用者の円滑な事業継続を妨げることがな いようクラウド・コンピューティングの提供者のサービス撤退時のルール策定が重要である。 表Ⅱ- ６-１ Amazon AWS の SLA サービス Amazon Elastic Compute Cloud (Amazon EC2) 水準 単位 補償額 99.95% 年間稼働率 10% β Amazon SimpleDB Infrastructure Services 99.90% 月間稼働率 10% 99.00% 月間稼働率 25% Amazon Simple Storage Service (Amazon S3) Amazon CloudFront β Amazon Simple Queue Service (Amazon SQS) - （出典） Amazon （注）β:正式版をリリースする前の利用者による試用段階のもの 補償額:サービスレベルが水準を下回った場合に減額される利用料の割合 表Ⅱ- ６-２ Google の SLA Google Apps Premier EditionのSLA 水準 (補償額） サービス GMail Google Calendar Google Talk Google Docs Google Sites 米国 日本 99.9% （3days) 米国と同じ 99.0% (7days) 95.0% (15days) 無し GMail Labs functionality Gmail Voice 無し Video Chat Google Video （出典） Google （注）補償額（括弧内の数値）:サービスレベルが水準を下回った場合に無料で追加的に利用できる日 数（稼働率の実績が 99.0％以上 99.9％未満の場合 3 日延長、95.0％以上 99.0％未満の場合 7 日延長、95.0％未満の場合 15 日延長） 93 第二部 第 6 章 （２） ② サービス間の相互運用性の確保やソフトウェアのアップグレードへの対応 IaaS や PaaS では、その環境上で利用者のカスタム・アプリケーションが稼働し、データが インストールされ、サービスが利用されることとなる。このため、利用者独自のアプリケーション 等がどのクラウド・コンピューティング上でも稼働する“相互運用性”の確保が重要である。相 互運用性が完全に確保されていない場合、利用者がコスト等の観点から利用するクラウド・コ ンピューティングを他のクラウド・コンピューティングに切り替えようとしても、システム全体の信 頼性・セキュリティが著しく低下するおそれがあることなどから、切り替えが上手くいかないとい う問題が生じる可能性がある。こうした結果、利用者は特定の提供者が提供するクラウド・コン ピューティングにロックインされるおそれがある。さらに、クラウド・コンピューティングの提供者 がサービス提供を中止する場合、前述のとおり、利用者は事業継続上、多大な不利益を被る おそれがある。クラウド・コンピューティングの相互運用性が確保されていれば、そのリスクは低 減される。 SaaS の場合、提供されるサービスに独自のアプリケーション等を接続して（システムを連携 させて）利用する場合も多い。したがって、同様に相互運用性の確保が重要である。連携イン ターフェースのアップグレードの際にも、クライアント側の独自アプリケーションを変更すること なく使用が継続できる“下位互換性”が確保されることが望ましい。下位互換性に問題があると、 システム障害の原因にもなる。 また、クラウド・コンピューティングを構成する資源のアップグレード等を行う際には、提供さ れる機能・サービスが引き続き利用できる“機能継承性”が重要である。機能継承において特 に重要なポイントは、データ、プログラム、ユーザビリティが如何に円滑に負担なく継承される かである。機能継承性がない場合、利用者側にアプリケーション等の改修といった負担が発 生する。その際、システムの信頼性・セキュリティが低下する懸念もある。 さらに、クラウド・コンピューティングは、一般的に複数のベンダ企業が開発・販売している資 源から構成されており、資源間の相互運用性も重要である。資源間の相互運用性が確保され ていない場合、クラウド・コンピューティングを構成する資源のアップグレードや異なるベンダ 企業の資源の追加を行う際などに、情報システム全体の信頼性・セキュリティが低下するおそ れがあるからである（図Ⅱ- ６-５を参照）。 このようにクラウド・コンピューティングの相互運用性やアップグレードの互換性を確保する ためには、複数のベンダ企業・サービス提供企業間の調整などが必要であり、官民連携して 戦略的にその実現に取り組む必要がある。 94 第二部 第 6 章 （２） クラウド事業者ａ クラウド事業者ｂ ユーザ データ ユーザ データ ユーザ データ 「機能継続性」 ユーザAP ユーザAP ユーザAP 「相互運用性」 PaaS ｖ1.0 PaaS ｖ1.1 PaaS 開発環境・実行環境 Ｂ社サーバ Ｂ社サーバ Ｂ社サーバ Ｂ社サーバ Ａ社サーバ Ａ社サーバ Ａ社サーバ Ａ社サーバ クラウド事業者ｆ クラウド事業者ｅ ユーザ データ クラウド事業者ｃ 「相互運用性」 ユーザ データ IaaS IaaS ユーザAP 「資源間の相互運用性」 ユーザMW クラウド事業者ｄ ユーザOS IaaS ﹁相互 運用 性 ﹂ ユーザAP ユーザMW ユーザ データ ユーザOS クラウド事業者ｇ SaaS v1.1 IaaS ユーザ データ 性」 ード レ 互換 「下位 アップグ る のあ SaaS v1.0 利用企業 「相互運用性」 サーバ クラウド事業者ｈ ユーザAP 端末 ユーザ データ ユーザMW ユーザ データ SaaS ユーザOS エンドユーザ 図Ⅱ- ６-５ クラウド・コンピューティングの相互運用性等のイメージ （３）サービス提供者間の責任分界の明確化や障害発生時における対応指針の整備 クラウド・コンピューティングは、前述のとおり、一般的に複数の事業者が開発・販売している資源 により構成されることから、システム全体を一事業者が開発・販売し、障害等に対してすべての責任 を担う場合と比較して、事業者間の責任分界が曖昧になる懸念がある。また、障害原因の特定が 困難であり、障害発生時の復旧が相当程度遅れる可能性がある。そのため、契約時におけるサー ビス提供者間の責任分界の明確化や障害発生時の対応方針の整備が重要である。 今後、拡張性を考慮すると、複数のサービス提供者のクラウド・コンピューティングがまたがって 使用される可能性があり、その場合の契約・課金・決済の仕組みは複雑である。したがって、こうし た仕組みの在り方を議論し、一定の合意形成を図る必要がある。 一方で、最終的に責任分界が不明確な場合や、複数のサービス提供者、通信事業者、通信機 器メーカ等にそれぞれ一定の過失が存在する場合などにおいては、トラブル発生後に複雑な紛争 を処理することが必要となる。また、トラブルが生じた場合において、利用者からトラブルの原因とな ったサービスや機器の特定をすることは困難であることから、利用者がトラブルについて相談する ための窓口が整備されていることが望ましい。 このようなソフトウェアに関するトラブル相談や専門的で複雑な事案に関する紛争処理について 95 第二部 第 6 章 （３） は、柔軟な審理が可能であり、技術的知見を有する専門家の判断を仰ぐことも可能であるなど、 ADR における審理の方が裁判所における訴訟よりも迅速かつ適切に解決できると考えられる。 前述のように、平成 20 年 7 月には（財）ソフトウェア情報センターのソフトウェア紛争解決センタ ーが ADR 機関として法務省の認証を受けた55ところであり、ソフトウェア分野のトラブル相談と紛争 解決を専門に扱う機関として活動を開始している。今後、クラウド・コンピューティングのような形で サービスの提供主体が複雑な関係を形成しながら最終利用者にサービスを提供することが増加し ていく中で、このような ADR 機関がソフトウェア分野の多様で複雑な紛争解決に活用されることが 期待されている。 なお、欧州では、第７次 EU 研究開発枠組み計画（FP7）の下、こうした仕組みの在り方の議論 に着手して（RESERVOIR プロジェクト等）おり、我が国においても取組を推進する必要がある（表 Ⅱ- ６-３を参照）。 表Ⅱ- ６-３ RESERVOIR プロジェクトにおける課金・決済に係る研究開発概要 目的 サービスと当該サービスを提供するために用いられているインフラ環境を包 括的に提示し、ビジネス・業務の視点から管理ができるようにするためのフ レームワークの提供 フェデレーテッド・インフラ（異なる種類や異なる事業者によるインフラが連 邦的・連合的に組み合わされたインフラ）における従量課金（ユーティリテ ィ・コンピューティング）ビジネスモデルの開発 リソースの使用状況、SLA が満たせなかった場合のペナルティ、柔軟な値 引き提案等に基づく課金・請求 タスク ビジネス･インフォメーション･モデル（課金・請求のために用いられる情報の モデル） サービスの使用量を計算するためのコンポーネント ビジネス・業務指向の請求・支払メカニズム 主要成果 インフラやサービスの提供者間の商業的関係を記述でき、また、使用にあ たって課金される資産を網羅することができる高度なビジネス・インフォメー ション･モデル 他の RESERVOIR のコンポーネントと統合され、請求の業務プロセスを実 行できる完全な会計システムの設計と実装 業務ルールに基づき、かつビジネスモデルの柔軟な変更にも対応できる業 務管理ツールの設計と実装 可能性 グリッド/仮想インフラ分野における新たなビジネスの可能性を探るために必 要となる技術の進歩 （出典）Nick Tsouroulas and Juan Cáceres, ”RESERVOIR Service Manager”56 55 http://www.softic.or.jp/adr 56 http://www.ogf.org/OGF23/materials/1181/OGF-Reservoir+Service+Manager+Layer_v6.pdf 96 第二部 第 6 章 （４） （４）データが物理的に確保されるデータセンタの在り方 経営効率化や環境対応の必要などから BPO が加速し、クラウド・コンピューティングが普及して いくことで、データセンタの重要性が急速に増していくと考えられる。クラウド・コンピューティングも、 利用者が直接意識する必要はないとしても、実際にはデータセンタを用いて提供されていることに 着目する必要がある。 クラウド・コンピューティングでは、データの完全性や機密性、すなわちベンダ企業のデータに関 する秘密保持責任がこれまであまり明確にされていない。クラウド・コンピューティングの普及に伴 い、この点が極めて重要な課題となってくると予想される。クラウド以前のデータセンタ利用の段階 では、企業は個別の事業者と直接契約を行う、あるいは間接契約の場合においてもシステムインテ グレーター（SIer）を通じて自社の情報にアクセスを行う可能性のある事業者全体を把握することが 可能であったが、クラウド環境においてはクラウド事業者同士が連携して、より柔軟かつ堅牢な計 算環境を構築することが予想され、SaaS 事業者においては、どのクラウド事業者が、顧客のデー タを扱うことになるのか、正確に把握することが困難になると考えられる。また、SaaS では、データ ベース中において顧客別のアクセス制御が行われない実装が現時点では多く見られるようである ため、アプリケーションレベルでのアクセス制御を実装するように変えていく必要があると考えられ る。 またデータの保全やセキュリティ措置に関しては、大手クラウド事業者による代表的なストレージ サービス等において例に見られるように、利用者のデータのセキュリティ等に関する事項について 免責規定を置いていることが多い。一方で、海外の一部のクラウド・コンピューティング・サービスで は、セキュリティを含めた内部統制について第 3 者の監査により担保する取組が行われている。例 えば Salesforce.com は同社が提供するオンデマンド CRM サービス“Salesforce.com”について 2004 年に SAS70 Type II の監査を完了し、SysTrust の監査も終えている。Google においても、 同社が提供するオンデマンドオフィスアプリケーション提供サービス“Google Apps”について 2008 年 11 月に SAS70 Type II の監査が完了したことを発表した。SAS70 等の外部監査報告書は、そ のアウトソーシングサービスにおける情報処理やその手順、情報統制が適正であることを証明する ものであることから、利用者にとってデータセキュリティの担保という点で一つの参考基準となるもの と考えられるものの、それによってセキュリティに関するすべてが担保されるという訳ではない点に 留意が必要である。 セキュリティを何らかの形で担保されない限りは、利用者は安心してクラウド・コンピューティング を利用することができない。我が国においても、どのような方法でデータセンタのセキュリティを確認、 担保していくべきか、極めて重要な課題といえる。 クラウド事業者、SaaS 事業者は、このようなデータ管理上の懸念に対する説明責任を有する。 企業においてデータ管理の安全性を確保した上で、事業者選択を適切に行うためには、データ管 理対策に関する統一された情報公開フォーマットの策定と、表明するデータ管理対策を第三者が 監査・認証するための監査スキームの確立等を検討する必要があると考えられる（図Ⅱ- ６-６を参 照）。 97 第二部 第 6 章 （４） 0% クラウドの利用判断に直接関わることになると想定される回答者 運用担当者等、利用判断には直接関わらないと想定される回答者 20% 27% 18% 40% 60% 64% 44% 32% 35% 80% 100% 55% 64% サービス提供者自らが作成した概要資料で確認する サービス提供者自らが作成した詳細資料（システム構成等が詳述されたもの）で確認す る 自ら立入検査を行う 中立的な第3者により認証されている その他 図Ⅱ- ６-６ クラウド・コンピューティングにおいて妥当と考えられるセキュリティ対策（情報漏洩対 策等）の確認方法 98 第二部 第 7 章 （１） 第７章 高信頼で安全な情報システム・ソフトウェアの実現を支える人材を育 成するための取組の在り方 （１）高度情報化社会の基盤を支える人材の育成に向けて産学官で加速すべき取組 あらゆる経済活動への IT の浸透及び IT の社会インフラ化、経済活動のグローバル化に伴う産 業構造変化の中で、IT 産業において IT を供給する人材やユーザ産業において IT 戦略を企画し 活用する人材の育成が重要となっている。特に、本報告書で取り上げた高信頼で安全な情報シス テム・ソフトウェアの実現は、高度情報化社会の実現及び我が国の IT 産業やユーザ産業の競争 力強化に向けた戦略課題でもあることに鑑み、その実現を担う人材の育成を産学官で戦略的に取 り組む必要がある。また、そのような取組の強化は、産業競争力強化の観点のみならず、IT 産業 やユーザ産業において活躍する IT 人材のプロフェッショナルとしてのキャリア形成や職業としての 魅力向上にも資するものである。 本章では、近年の IT 人材育成施策動向や IT 人材育成の課題を踏まえ、我が国における IT 人材育成強化に向けた取組を示すとともに、本報告書が特に注目する高信頼で安全な情報シス テム・ソフトウェアの実現を支える人材を育成するために加速すべき取組の方向性を示す。 経済産業省は、IT 人材を巡る産業構造変化や諸外国における IT 人材戦略、我が国における IT 人材育成の現状や課題を分析し、平成 19 年 7 月に、我が国の IT 人材育成に向けての基本 戦略となる産業構造審議会経済分科会情報サービス・ソフトウェア小委員会人材育成ワーキング・ グループ報告書“高度 IT 人材の育成を目指して”を発表した。この報告書では、我が国が目指す 高度 IT 人材が 7 つに類型化され、それらの高度 IT 人材を育成していくための基本戦略として、 高度 IT 人材の具体像の可視化・共有化、客観的人材評価メカニズムの構築、産学連携による実 践的教育システムの構築、グローバルな人材育成メカニズムの確立等を柱とする高度 IT 人材育成 プラットフォームの構築の実現を目指すことが提唱された。その戦略の実現に向けた取組として、 高度 IT 人材を類型化する共通キャリア・フレームワークを参照する形で、情報処理技術者試験制 度の改正、IT スキル標準や組込みスキル標準、情報システムユーザスキル標準の整合化が図ら れた。2009 年度からは、職業人として誰もが共通に備えておくべき IT に関する基礎知識を対象と したエントリー試験（IT パスポート試験）をはじめとした新しい情報処理技術者試験が実施される予 定であり、高度 IT 人材育成プラットフォームの実現に向けた取組が、本格化している。 産学連携による実践的教育システムの構築に関しても、文部科学省、経済産業省により創設さ れた産学人材育成パートナーシップの情報処理分科会を中心に高度 IT 人材の育成に向けた取 組の検討が産学官で精力的に進められている他、日本経済団体連合会等を中心に産学官連携 による高度 IT 人材育成も本格化する等、産学による具体的な取組が積極的に進められている（図 Ⅱ- ７-１を参照）。 99 第二部 第 7 章 （１） 図Ⅱ- ７-１ 高度 IT 人材育成推進体制 高信頼で安全な情報システム・ソフトウェアの実現に向けては、ユーザ産業、IT 産業等において その実現を支える高度 IT 人材の育成を一層強化するとともに、その中核となる人材の輩出を担う 教育界における高度 IT 人材育成の継続的な取組が必要不可欠であり、産学官が IT 人材育成に 向けての問題意識や目標を共有し、その取組を着実に推進していくことが求められる。 特に、情報システム・ソフトウェアの高信頼やセキュリティの水準を確保していくという観点からは、 ユーザ産業等における情報システム・ソフトウェアに関する要件定義力、システム設計力、プロジェ クトマネジメント力等を高めるための人材育成施策の強化、IT 産業においては、求められる信頼性 やセキュリティ水準を高い生産性のもと実現していくため、大規模・複雑化する情報システム・ソフト ウェアを構築するためのアーキテクチャやシステム設計力やプロジェクトマネジメント力、効率的な テスト技術等のソフトウェア工学の能力を有する人材育成等に関する施策を加速する必要がある。 また、高度 IT 人材として、時代の変化に対応して新しいテクノロジを生み出し、イノベーションを実 現できる能力を有する人材の育成も求められている。その中では、その中核的役割を担う高度な IT 人材に関して、その実行能力及び権限等を担保する資格制度の在り方についても検討していく こと等、制度的な検討が必要との指摘もある。また、大学・大学院等の高等教育機関においては、 情報システムやソフトウェア工学分野等に関する高い専門性を備えた IT 人材の輩出を企図した専 門教育を産学連携により充実していくことが求められる。 さらに、大規模・複雑化する情報システム・ソフトウェアの信頼性やセキュリティの向上を実現する ためには、技術的なイノベーションも必要になるであろう。そのため、高信頼で安全な情報システ 100 削除: 実現 第二部 第 7 章 （１） ム・ソフトウェアを実現する革新的なシステム・アーキテクチャの創出に向けたスーパークリエータ等 のイノベータの育成や高信頼なソフトウェアを開発するための設計技術や生産技術等に関する研 究開発人材の育成についても強化していく必要がある。 また、経済活動のグローバル化が進む中、IT 人材に関しても、優秀な海外人材の活用のみなら ず、第三部で述べる国際的な標準化やグローバルなビジネスへの対応等、グローバルレベルで通 用する人材の育成等の視点が重要となってきており、グローバル化に対応する IT 人材の育成の ため方策についても、今後検討が必要になるであろう。 （２）ユーザ企業側の人材育成についての取組強化 経営と IT の融合が進む中、ユーザ企業における IT 人材育成は、ユーザ産業の競争力強化に 向けて、その重要性が増している。中でも高信頼で安全な情報システム・ソフトウェアの実現に向け てユーザ産業における IT 人材は、IT の供給を担うベンダ企業と十分に対話を深めるため、IT に 関する知見を深めるだけでなく、事業継続的な観点を含め業務プロセスを効率的かつリスクに強い シンプルなプロセスへと改革する力や、そのようなプロセスを実現するための情報システム・ソフトウ ェアに関する要件定義力、システム設計力、プロジェクトマネジメント力を高めていくことが求められ る。また、高信頼で安全な情報システム・ソフトウェアの実現は、ユーザ企業の経営戦略の柱の一 つでもあり、経営と IT 戦略を合致させた上で、その推進を担う最高責任者として、CIO（Chief Information Officer）の役割が一層重要になる。 一部のユーザ企業等では、情報システム・ソフトウェアの重要性を認識し、IT 人材育成に力を入 れはじめている。しかしながら、最新の IPA の調査によれば、上場ユーザ企業 232 社における IT 人材の質について、32%の企業が、IT 人材の質が“大幅に不足している”と認識している。また、 ユーザ企業における IT 人材のスキルフレームワークである情報システムユーザスキル標準 （UISS）を利用している企業は、3%に留まっている。ユーザ企業等における IT 人材育成は、その 重要性が各方面からも指摘されており、UISS の普及をはじめとした IT 人材育成強化の取組が期 待されている（図Ⅱ- ７-２を参照）。 0% N=335 25% 50% 31.6% 大幅に不足している 75% 56.1% やや不足している 100% 11.6% 特に不足はない 無回答 （出典） IPA 2008 年度 ＩＴ人材市場動向調査 図Ⅱ- ７-2 ユーザ企業における IT 人材の過不足感 101 0.6% 第二部 第 7 章 （２） また、教育機関においては、これまでどちらかと言えば、IT の供給を意識した教育が重視され、 IT の高度な利活用を担う人材の育成を企図した教育が確立しているとは言いがたい。企業活動や 社会システムと IT の融合が不可避となる中、今後は、企業経営等の社会科学系知識と情報工学 系知識の双方を習得するための育成体系（IS（Information System）教育、ダブルディグリー等） の充実やその確立に向けた取組を拡充していく必要がある。加えて、IT 人材は、ユーザ産業、IT 産業によらず専門性とヒューマンスキル等の人間力を兼ね備えることが求められるため、その素質 を実践的に養うための育成の取組なども求められている。さらに、企業改革をリードする人材を確 保する上では、より高度な IT 人材育成の取組として、CIO 候補を育成するための教育を産学で具 体化してくことも必要であろう。 また、情報システム・ソフトウェアの信頼性やセキュリティの価値が社会に広く受け入れられるた めには、ユーザ企業の IT 人材の育成は言うまでもなく、情報システム・ソフトウェアの最終受益者 が、受けるサービスの費用対効果やリスクについて納得していることも重要であり、社会全体で、情 報システム・ソフトウェアの信頼性やセキュリティに係わる情報を共有していくとともに、そのリテラシ ーを深めるための施策を進めていくことも重要となる。 （３）高度な IT 人材の位置付け 情報システム・ソフトウェアの信頼性やセキュリティ水準の見える化・測る化の重要性が指摘され る中、その実現を担う IT 人材に関しても、スキル標準等の活用による人材の見える化を進めること により、効果的な人材育成や信頼性やセキュリティの実現に向けた IT 人材戦略が促進されると期 待される。特に、高い信頼性やセキュリティが求められる情報システム・ソフトウェアの構築や運用 等において、中核的な役割を担う高度な IT 人材に関しては、その実行能力及び権限等を担保す る資格制度を創設していくことも、必要ではないかとの指摘もある。 IT スキルの標準化や IT 人材の資格化に関しては、企業等における人材戦略や世界各国や地 域における労働や産業政策的狙いから、近年幾つかの動きが活発となっている。ISO では、ソフト ウェア技術者認証について ISO/IEC/JTC1/SC7 の総会において“ソフトウェア技術者の認証”の 国際規格化に向けた研究グループの設置を決定し、先進国を中心に国際標準化の動きが進みつ つある。欧州においては、情報化の促進による知識経済の実現を目指したリスボン戦略の流れを 受けて、2007 年には、e-Skills に関する長期戦略を採択し、各国のスキル標準である SFIA（英）、 AITTS（独）、Cigref（仏）等を ICT 57 スキル及び能力に関する汎用的なフレームワークである e-Competence Framework により整合化を図るなど、EU 全体で IT 人材スキルの標準化を進め る動きが見られつつある。また、世界各国の IT に関する学協会では、高度な IT 人材の資格制度 を設け、学協会の国際的な集まりである IFIP58においても欧州の学会による資格制度を認証し、 高度な IT 人材の国際的な資格化を検討する動きがある。さらに、欧米の有力な団体等において 57 ICT は、Information and Communication Technology の略。本報告書中の IT と同義。 International Federation for Information Processing の略。国連ユネスコの提案で組織された情報処理国 際連合で、日本の代表団体は、情報処理学会である。 58 102 第二部 第 7 章 （３） は、各種の独自資格制度を設けようとするなどの動きも見られる。図Ⅱ- ７-２には、国内外の代表 的な資格制度やスキル標準等を示した。 IT 市場や IT 人材供給のグローバル化が急速に進み、上述に示したように IT 人材の資格制度 や IT スキルの国際的な標準化の動きが見られる中、我が国において高度な IT 人材の位置付け の在り方について検討していく場合には、これらの国際的な動向を視野に入れ、我が国の取組が 国際的に孤立することがないよう国際的なハーモナイゼイションを図るとともに、我が国の競争戦略 的な位置付けを踏まえ、多角的な視点からの検討を行うことが求められよう。 CISSP （ｾｷｭﾘﾃｨ） CBAP （ｺﾝｻﾙﾀﾝﾄ） 資 格 PMP （ﾌﾟﾛﾏﾈ） ITIL （運用） SCP （ｾｷｭﾘﾃｨ） ISO/IEC ソフトウェア技術者認証 （米国、日本、ドイツ、オーストラリア、韓国等） HRD Korea（韓国） III / CSF（台湾） SCS（シンガポール） e-Competence Framework SFIA（英国） AITTS（ドイツ） Cigref（フランス） ITｺｰﾃﾞｨﾈｰﾀ (ｺﾝｻﾙﾀﾝﾄ) 日 本 CSDP （IEEEソフト技術） ISTQB (ﾃｽﾄ) CEIAEC（中国） DOEACC Society（インド） VITEC（ベトナム） ス キ ル IPMA認定資格 （ﾌﾟﾛﾏﾈ） ITAC （ITｱｰｷﾃｸﾄ） CISM （ｾｷｭﾘﾃｨ） 海 外 TOGAF （EA） 資 格 NWCET（米国） JPMF認定資格 PMC等 （ﾌﾟﾛﾏﾈ） JSTQB (ﾃｽﾄ) 技術士（情報工学） 情報処理技術者試験 ス キ ル 共通キャリア・スキルフレームワーク UISS ITSS 図Ⅱ- ７-２ 国内外の代表的な資格制度とスキル標準 103 ETSS 第三部 （１） 第三部 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 高度情報化社会の実現に向けた情報システム・ソフトウェアの信頼 性及びセキュリティの向上のための国際貢献 （１）信頼性・セキュリティに関する日本の国際的なポジション ① 日本の情報システム・ソフトウェアの品質と国際貢献 １） 我が国のソフトウェア開発における米国との違い Cusumano,M 等の論文59によれば、プログラム 1K あたりのシステム導入後 1 年間に発見 されたバグ数絶対値を比較すると、日本 0.020、米国 0.400、インド 0.263、欧州 0.225 で あり、バグ数の比較としては、我が国のソフトウェアの品質は格段に高いという評価を得てい る（表Ⅲ- １を参照）。このバグ数の少なさをもって、我が国のソフトウェアが高品質であり、 それがソフトウェア開発における強みであるとして良いかは疑問が残るところである。例えば、 動作速度、スケーラビリティ、ポータビリティ、ユーザビリティなどソフトウェアの品質に関して 様々な視点が存在する。そのため、バグ数のみを持って一概に比較することは危険である といえる。また、品質をユーザ要求の満足度と捉えた場合、システム導入時の状況やユー ザがシステムに求める役割の違いがユーザ要求の違いとなって現れる。その結果品質に関 する基準にずれが生じ、他方ではバグと認識されたものが、一方ではバグとは認識されな いといった状況が発生する。特に、我が国においては、品質の良さや機能豊富さを求める あまり、開発コストの上昇や比較的長期の開発期間を必要としてしまい、システムが本来具 備すべき品質に対して、ユーザが要求する品質がオーバースペックになっているとの指摘 もある。このような点からも、情報システム・ソフトウェア開発における、“品質（Q）”、“開発コ スト（C）”、“サービスインまでの期間（D）”の 3 者のバランスを取るといった観点から、ソフト ウェアの品質について検討・評価する必要がある。また、我が国の情報システムに関わる品 質の高さは、日米における企業の情報システム導入戦略の違い、ソフトウェア開発手法ある いは IT 人材の雇用形態の違いなどに起因しているとの意見もある。システムの信頼性の評 価については、システムと業務の関係性や開発形態の違いを踏まえたより深い検討を行い、 統一的な品質についての概念及び計測指標の定義をした上で議論する必要がある。 ここでは、我が国のソフトウェア開発に関る事項について他国との比較を行い、差異を検 討することで、我が国の情報システム・ソフトウェアに関する強みを明らかにし、その強みを 活かした国際貢献の在り方について述べる。 59 Cusumano,M., MacCormack,A., Kemere,C.F., Crandall,B. “Software Development Worldwide: The State of the Practice” (IEEE Software Nov/Dec 2003, pp.28-34) 104 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 表Ⅲ- １ ソフトウェア品質の国際比較 日本 米国 インド 欧州その他 計 プロジェクト数 27 31 24 22 104 ソフトウェア品質 0.020 0.400 0.263 0.225 0.150 システム導入後 1 年間に発見された 1K あたりの不具合報告（中央値） （出典）Cusumano,M.等 （IEEE Software Nov./Dec. 2003, pp28-34） 米国におけるシステム導入方法別のシステム開発投資の割合を見ると、民間部門におい て約 4 割（2007 年度で 40.6%）が自社開発であり、その割合も 1998 年以降多少の増減は あるものの、全体としては増加傾向にある。パッケージソフトの割合は 2007 年度で 28.9％ あり、若干ではあるが増加傾向にある。その分、受注ソフトの割合が減少している60（図Ⅲ１を参照）。 民間部門における導入方法別投資割合 100% 80% 60% 40% 20% 0% 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 年度 パッケージ カスタム 内製 （出典） Bureau of Economic Analysis61 図Ⅲ- １ 民間部門における導入方法別投資割合 米国企業は、市場の変化に対して経営資源を適時的に振り分けることを経営の強みとし ており、ビジネスの戦略性を基にした、先進性とスピードを重視する傾向にあるといわれて いる。そのため、システム導入にあたっては、大多数の企業が、自社のコアコンピタンスに 関るシステムはコンピテンシー維持のために、ユーザ企業内に優秀なエンジニアを抱え内 製している62。一方、ユーザ企業が非競争領域であると認識している業務に関るシステムに ついては、戦略面よりもコスト面や導入期間面での効率化を重視し、パッケージシステムの 60 ただし、カスタムソフトウェアの支出額には、ソフトウェアの開発費用、個別契約を行っているフリーランスのソフト ウェアライター、外部コンサルティング会社への費用等を含む。また、自社開発には、従業員の給与、福利厚生費 等の一般管理費用、税金、メンテナンス及び保守費用等を含む。 61 http://www.bea.gov/national/xls/soft-invest.xls 62 世界主要国の情報サービス産業動向に関する報告書（JISA、平成 20 年 4 月） 105 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 活用が主流となっている。また、パッケージシステムの導入に際しては、自社の戦略的事業 でないがゆえにカスタマイズは最小限とし、ビジネスプロセスをパッケージに合わせるといっ た手法がとられやすい。一方、我が国の開発形態は 74%の企業がシステム開発を外部へ 委託しており（内従業員 1,000 人以上の企業は 89%）。委託先としてはいわゆる SIer が 44%、ソフトウェアベンダが 24%、情報子会社が 20%となっている。また、パッケージの導入 率から見ると、何らかの ERP パッケージを導入しいている企業は 42%であるが、パッケージ 導入企業の 83%の企業がカスタマイズを行っている63。我が国のシステム開発では、米国 に比して内製率が低く（システム開発ベンダに委託してシステム開発を実施している率が高 く）、かつカスタムソフトウェアの作成あるいはパッケージソフトウェアのカスタマイズ率が高い ことが分かる。 システム開発形態やプロジェクト実施形態についても、米国と我が国ではその雇用形態 の違いを反映して、大きく異なっている。米国では、IT エンジニアの流動性の高さとユーザ 企業によるシステム開発の内製率の高さを背景に、ユーザ企業がシステム開発プロジェクト 毎に、プロジェクトマネージャを含めた IT エンジニアを個別に直接雇用する場合が多い。 一方、我が国では IT エンジニアの流動性は米国に比して低く、SIer やシステムベンダが IT エンジニアを長期雇用し、ユーザ企業はシステムベンダと契約しプロジェクトを遂行す る。 また、開発プロセスモデルの観点では、我が国の業務アプリケーションに関するシステム 開発の多くがウォーターフォール型ではあるものの、随所でユーザとの摺り合せを実施して おり、イタレーション的要素を含めた開発モデルとなっている。いわばウォーターフォール型 摺り合わせモデルといえる。そのため、基本機能の設計から画面の詳細設計に至るまで、 ユーザ企業のニーズを最大限取り入れたシステムを構築してきたといえる。さらに、納入し た業務システムについて、納入事業者が保守・運用を担う場合が多く、システムベンダは、 自社内に顧客企業の業務知識と、当該業務に係るシステム開発や運用に関する知識やノ ウハウの双方の知見を蓄積することが可能であった。 ２） 我が国のソフトウェア開発の強みと弱み 我が国の業務アプリケーション開発は、米国に比して、長期雇用されユーザ企業に関す る知見や経験を兼ね備える IT エンジニアを有する SIer やシステムベンダによる個別開発 が中心となっている。その結果、ユーザ企業独自の業務プロセスにマッチしたシステム開発 が可能であり、仕様面でのミスマッチが相対的に少ないといえる。このような様々な要因を 踏まえた、我が国のソフトウェア開発における強みは、ユーザ視点での情報システム開発に 基づく業務と情報システムの摺り合せによる開発プロセスであり、それを可能としている人材 の長期雇用を前提としたシステムベンダに蓄積された業務とシステム開発に係るノウハウで あるといえる。 63 企業 IT 動向調査 2008（JUAS、 2008 年 4 月） 106 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 一方、このような開発形態が持つ弱みも指摘されている64。例えば、ユーザ企業にとって 戦略的な投資を必要とするシステム以外のシステムについても、ユーザ企業独自の業務プ ロセスを維持した業務側の要求に応える個別システムになってしまう。ユーザのシステムに 対する要求度と本来業務として持つべき要求度のギャップ（過剰要求）が生じ易く、コストが 高止まりする傾向があるといえる。また、システムベンダにとって、ノウハウの横展開は可能 であるが、プロダクトとしては基本的に個別生産であるため、パッケージに比して絶対ユー ザ数が少なく、ソフトウェアの特徴である収穫逓増が見込まれずビジネスとしての生産性に 課題が生じる。さらに、ユーザ企業の要件定義能力の低下も指摘されている。システムベン ダへの過度な依存が続くことにより、ノウハウがシステムベンダへ移行してしまい、ユーザ側 で発注仕様が定められなくなる危険性が内在する。同様の課題としては、開発時の摺り合 せにより、業務運用とシステム開発に係るノウハウが暗黙知化する場合が多く、組織として のマニュアル化が進まず人に依存したシステムに陥り易いことが挙げられる。言い換えれば、 我が国のソフトウェア産業は、労働集約型産業の持つ弱みを内在しているといえる。 ３） 我が国の強みを活かした国際貢献の在り方 我が国の強みである“高品質”な情報システムを開発する能力を活かしつつ弱みを克服 し、これを梃子とした競争力強化を図った上で、システム開発に係る国際貢献を果たしてい くことが必要である。我が国の持つシステム開発に係る強みの源泉を体系化した上で、各 国の人材を受け入れ、知識移転を図るとともに、我が国主導で国際標準化を進めることが、 ソフトウェアの品質向上に資する国際貢献となる。 我が国のシステムベンダはユーザ仕様に特化したシステム構築・運用を実施してきてお り、ある意味で包括的な IT アウトソーシングを請負ってきたといえる。我が国の強みを引き 出していくためには、このような経験を活かし、高品質を維持するためにシステム開発・運用 現場が培ってきたノウハウ、特に、現場ユーザをカウンターパートとしたシステムベンダ（IT エンジニア）による要件定義能力に加え、ユーザ要求に応えて臨機応変に対応する現場力 に関するノウハウに関し、表出化（見える化）し形式知として体系化することが必要である。 品質が特に重要視される分野（医療、物流、鉄道、セキュリティ関連製品等）では、品質 の高さが競争力に直結する。こうした社会インフラ分野においては、新幹線システムのよう に、システム・ソフトウェアを含むシステム全体で海外勢との競争を制している例も多い。日 本が国際競争力を発揮できる分野として、こうした高信頼性を伴う社会システムそのものの グローバル展開の可能性について検討する必要がある。一方、社会インフラ以外のソフトウ ェアについて、品質のみではなくコストや納期を含めた、いわゆるユーザ企業の魅力価値 の向上が図られない限りは、国際的な競争力を得ることができない。そのためには、労働集 64 田中辰雄「カスタムソフト偏重は日本の問題点か？」 富士通総研（FRI）経済研究所 Economic Review Vol.13 No1,Jan 2009 pp4-7 107 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 約型産業からエンジニアリング産業へその形態の転換を図ることで、日本の製造業が蓄積 してきたモノ作りノウハウを生かした高信頼性の情報システムを展開することが可能となり、 その結果、競争力のある企業体質が構築されることが期待できる。 このような取組を成功させ、国際貢献へつなげていくためには、ノウハウを蓄積している 産業界と学術的に体系化を図る学界との協力体制を基礎とした、政策としての標準化戦略 といった取組が必要であり、一層の産学官連携が不可欠であるといえる。その上で、高品 質を生み出すプロセスを我が国独自の手法として国際的に発信し、国際貢献へとつなげて いくためには、国際標準化・規格化に係る活動を我が国主導で進めることが不可欠である。 特にシステム信頼性に係る課題に対してはユーザ企業の意識と密接に関連してくるため、 アルファベット文化を超えた多様な文化を基礎においた議論をしていく必要がある。そのた め、国際標準化活動に関しては、欧州、米国と発展著しいアジアの三極構造とすべく、アジ ア各国に対して日本が働きかけることが必要となる。 標準化活動における国際連携強化を図る一環として、奨学制度等により優秀な留学生を 積極的に受け入れることで、高品質なシステムを開発するための知識や技術の移転を図る とともに、我が国の考え方（思い）や取組について浸透させていくことが考えられる。このよう な取組により、国際的な三極構造の基礎を築いた上で、各国のシステムの信頼性確保と技 術力向上に資することが、国際貢献を通じた我が国の競争力強化に係る有効な戦略といえ る。 ② 欧州及び米国の取組状況と日本の取組の位置付け １） 欧州における取組 欧州における情報システムの信頼性とセキュリティに係る政策については EU が主体的 に推進しており、特に、将来的に社会活動の基盤となる IT インフラに求められる機能として、 信頼性とセキュリティを位置付け、将来予想される高度情報化社会像を描いた上で、取り組 むべき政策を整理し体系化を行っている。 欧州における情報システムの信頼性確保に係る政策は、2000 年に発表されたリスボン 戦略において、欧州の R&D 政策として欧州 ICT 戦略が策定されたことに端を発する。ここ では 2010 年までに最もダイナミックかつ競争力のある知識基盤経済の構築を目標に、施 策・研究及び技術開発のフレームワーク・プログラム（FP）及び共同技術イニシアティブ （JTI）の実施が決定された。 その後、e ヨーロッパ計画（2000 年）を経て i2010 戦略（2005 年）では、知識とイノベーシ ョンを推進するエンジンである情報通信技術政策の中核として、単一欧州情報空間の構築、 情報通信技術における投資とイノベーションの強化、障害者を含めた完全かつ平等な参加 を 促 す 情 報 社 会 の 拡 充 が う た わ れ た 。 こ れ を 受 け 、 2006 年 1 月 に は “ Creative Innovative Europe”（通称 Aho Report）が、同 9 月には“EU 包括的イノベーション戦略 アクションプラン”が策定された。 108 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 一方、リスボン戦略の見直しとして 2005 年に“改正リスボン戦略”が策定され、欧州を投 資と労働の魅力的な場とする、知識とイノベーションを欧州の成長の中核とする、より多くの 優良な雇用を創出する政策を整備することがうたわれ、そのための技術開発が、2006 年度 からスタートした EU の第７次 EU 研究開発枠組み計画（FP7）において、成長のためのイノ ベーションと知識を重視した研究・技術開発政策のフレームワークとして取り組まれている。 ＩＴ関係の研究・技術開発においては、i2010 戦略を踏まえた FP7 の年間計画として IT 関連のワークプログラム（WP）65が実施されており、2008 年 4 月に i2010 戦略の中間直し として策定された欧州デジタル未来戦略を踏まえ、各国の IT 政策に反映されている。 欧州における情報システムの信頼性及びセキュリティ向上に係る取組としては、FP7 に おいて、SecurIST プロジェクトのアドバイザリーボードからの勧告66を受け、“2010 年以降 を見据えた情報通信技術のセキュリティと信頼性に関する研究戦略”を 2007 年に定め、暗 号技術とデジタルアセットマネジメント、個人識別とプライバシー保護、複雑化する情報シス テムの信頼性を確保した適合性、バランスの取れた信頼性、セキュリティポリシーなどの課 題に取り組んでいる。2008 年現在、情報システムの信頼性に係る WP は下表（表Ⅲ- ２）に 示す 3 つが代表的なものである。なお、FP7 の全体予算は約 320 億ユーロであり、ICT 関 係予算はそのうちの 28%の約 90 億ユーロ、セキュリティ関連は 5%の約 15 億ユーロである EU では、プライバシーや ID 管理を巡る考え方の整理とその担保のための技術開発、 制度整備が進行しているが、信頼性（ディペンダビリティ）に関しては、我が国の取組が EU を先行している状況である。内容的には EU サイドもその重要性を深く理解しており、今後 も継続して欧州の取組と連携しながら、我が国が国際標準化等の議論を主導していくこと が重要である。 65 「幅広く活用される、信頼できるネットワーク及びサービスインフラの実現」や「ユーザ主導型のコンポーネント、 システム、エンジニアリングの高度化」などが目標とされている。 66 「中長期的に情報システムの信頼性を考えた時に Security、Trust、Dependability、Privacy の４つが解決す べき課題である。」として FP７に勧告。 109 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 表Ⅲ- ２ FP7 における情報システムの信頼性確保に係る取組 名称 Trustworthy ICT 予算（ユーロ） 約 90 百万 Critical Information System Protection 約 20 百万 Embedded Systems Design 約 60 百万 内容 ・ 将来のインターネットを取り巻く状況を分析し、そのイン フラの Trustworthy 確保のための政策的プライオリティ を検討。 ・ プライバシー保護や ID 管理（端末等も含む）、通信プロ トコルの適格性などが議論の中心。 ・ 電力、金融、海外プラント分野に関する取組が進行中。 ・ 金融 分 野 では、 金 融 セ ク タ 向 けのミ ドル ウ ェ ア開発 （COMIFIN）を実施。 ・ グローバルにセキュリティ情報やアタック情報を共有で きる機能を開発。 ・ 組込みソフト設計やツール開発、ネットワークシステム エンジニアリングに関する研究開発提案を 2009 年 11 月迄受け付け。 ２） 米国における取組 米国における情報システムの信頼性確保の流れでは、重要インフラの安全保障を起点 に政策体系が組まれている。 米国における情報システムの信頼性に係る政策体系としては、1997 年の重要基盤に係 る米国のインフラ防護施策に端を発し、2000 年の国家情報システム防護計画、2002 年の 国家国土安全保障戦略が策定された。このような背景のもと、2003 年に国防総省において、 政府で利用される商業ソフトウェアのアシュアランスリスクの評価に関係する課題解決を目 標に、ソフトウェア・アシュアランス・イニシアティブが開始された。一方、国土安全保障省で は、2006 年に国家インフラ防護計画の中で、国土安全保障省と利害関係者によるリスクマ ネジメント原則に従ったセクタの横断的な優先付けを実施するとされており、続く、2007 年 に出された IT セクタのプランでは、IT セクタの調整評議会と連携し、IT インフラの国際的 依存性のリスク評価、大打撃に対する対応・回復力の強化に取り組むとしている。 さらに、国土安全保障省のサイバーセキュリティ＆通信オフィス国家サイバーセキュリティ 部門では、2003 年に策定された国家サイバースペース安全性確保戦略を受け、ソフトウェ ア・アシュアランス・イニシアティブと連携を取る形で、2006 年にソフトウェア・アシュアランス におけるセキュリティの構築（Build Security In : BSI）／ソフトウェア・アシュアランス・プロ グラム（Software Assurance : SwA）を策定し、これを支援する形で商務省の管轄する国 立標準技術研究所（NIST）がソフトウェア・アシュアランスに関するメトリックスと評価技術に 関するプロジェクト（SAMATE）に取り組んでいるところである。 BSI/SwA は、ソフトウェア開発ライフサイクルにおけるあらゆる問題解決を図る総合戦略 であり、 BSI が戦略イニシアティブを、SwA が実行計画を担うとしている。その目的として は、ソフトウェアの脆弱性に対するパッチマネジメントから、開発当初からソフトウェアの全般 的な質とセキュリティを向上させるソフトウェア・アシュアランスへのパラダイムシフトであり、 110 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt そのためには、ソフトウェア開発期間中に組み込まれるエラーコード、悪意のあるコード又 は trap door の可能性をなくすプロセスとコード開発の整合性の確保、及び、ベストプラクテ ィスと方法論を体系化するために官民の連携を促進するとしている。 米国においても、ソフトウェアの信頼性を巡る問題がクローズアップされているところであ り、情報システムの機能不全による経済的損失に加え、ソフトウェアの不具合が原因で死傷 者を出す惨事も発生している。特に、死亡事故に直結するケースとして、医療システムのソ フトウェア不具合が重要な問題として取り上げられており、食品医薬品局（FDA）の調査に よれば、医療機器のリコールのうち、ソフトウェアの不具合が原因のものが 7.7％あるとされ ている。 米国政府においても、米国におけるソフトウェア信頼性の向上に向けた具体的な取組と して、連邦政府では、既にいくつかの省庁（NASA、SSA、DOL 等）が CMMI を導入し、ソ フトウェアの開発プロセスにおけるアセスメントを実施している。特に、NASA 等では、IT シ ステムのトラブルが人命に直接的に影響を及ぼす場合があるため、信頼性のあるシステム を構築するには、適切な開発プロセスを持つことが重要との認識がある。また、情報システ ムの運用に関しても、導入自体にコストがかかると懸念されてはいるものの、いくつかの省 庁において ITIL67の導入が予定されている（表Ⅲ- ３を参照）。 67 ITIL (Information Technology Infrastructure Library)： IT サービスマネジメントのベストプラクティスを集 めたフレームワーク。 111 書式変更: フォント : 9 pt 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 表Ⅲ- ３ 米国政府のソフトウェア品質保証担保制度 取組主体 担保機関 設置時期 米国航空 宇宙局 （NASA） − − 原子力規制 委員会 （NRC） − − 連邦航空局 （FAA） RTCA（Radio Technical Commission for Aeronautics） 1982 年 食品医薬品局 （FDA） 連邦選挙管理 委員会 （FEC） ODC（Office of Device Evaluation） の特別委員 会 NASED (Association of State Election Directors) 1987 年 1989 年 制度内容 ① ソフトウェア・プロセス評価: コントラクターに対 して CMMI のレベル 3 を要件。 ② プログラム・ライフサイクルマネジメント: 7120 及 び 7120.7 の 2 種類の標準を策定。 ③ テスト工程: 第 3 者による検証・確認のプロセス に関する規定を策定（IV＆V）。 ④ 人 と 組 織 : 組 織 横 断 的 な PMO （ Project Management Office）の設置。 ※ITIL についても、導入予定。 民間の原子力発電所の運用に関して、すべてのソ フトウェアやハードウェアを対象として ISO9000 の適 用。 国際航空交通管理協定に基づき、民用・軍用すべ ての航空機搭載システムについて、DO-178B という 品質保証を取得するよう各ベンダ企業に求める。 DO-178B の審査は、①ソフトウェア開発プロセス検 査、②ソフトウェア・ライフサイクル毎に生じた問題 解析、③ソフトウェア機能検査、④プログラム・コー ディング内容の検査。 1991 年、従来から食品・医薬品・化粧品の市場投入 前検査を義務づけてきた 510(k)にソフトウェアの項 目を設ける内容のガイダンスを発表。 510(k)では、システム要求水準を 3 つのレベルに分 けており、レベルに応じて審査が行われる仕組み。 FEC が作成した電子投票システムに関するスタンダ ードに沿って、システムが検証されるプロセスを構 築。検査機関を組織内ではなく、ITA と呼ばれる民 間組織に委託するシステムを採用。 ソフトウェアの品質向上に向けた米国政府の取組としては、関係機関を横断的に統括し 政策を議論できる仕組みを活用し、ホワイトハウスの下部組織である“高信頼ソフトウェア・シ ステムズ（HCSS）”というワーキング・グループを中心に行われている。HCSS は、大統領府 の 1 つである科学技術政策室（OSTP）の管理下におかれる国家科学技術委員会 （NSTC）の省庁間横断ワーキング・グループの 1 つとして位置付けられている。具体的な 取組は以下の表（表Ⅲ- ４、表Ⅲ- ５を参照）のとおりである。 112 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 表Ⅲ- ４ ソフトウェア品質向上に向けた米国政府の取組 取組主体 米国連邦 政府 国防総省 （DOD） 設置期間 設置時期 活動内容 高信頼ソフトウェア・ 1998 年 高い信頼性を求められるシステム構築に関する研 究・開発プログラムの推進やワークショップの開催。 システムズ（HCSS） ※2003 年度から大学の研究者等を取り込んだ CSTB の特別委員会を設置。 2003 年 現状のソフトウェア保証制度における以下のポイン CSTB（Computer Science and トを、大学・企業などからの研究成果を集めつつ議 Technology Board） 論。 の特別委員会 ① CMMI や ISO9000 といった既存のソフトウェア・ プロセス評価の見直し。 ② ソフトウェアの品質保証に係る企業経営や法律 問題の検討。 ③ 政府機関での民生用（COTS）ソフトウェアの導 入によるシステム及びデータの信頼性の低下 に関する検討及び対策。 ④ ソフトウェア・ライフサイクルの各フェーズに応じ た品質改善技術の研究・開発の促進。 ITSSG（IT Security 2002 年 既存のソフトウェア品質保証制度に関するレビュー Group） 等。 ソフトウェア品質保 2003 年 既存ソフトウェア品質保証制度の改善策の検討。 証プログラム 113 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 表Ⅲ- ５ 米国における産学官共同プロジェクト及び大学における取組 設置機関 設置時 期 SCC(Sustainable Computing Consortium) 2003 年 10 月 SERC(Software Engineering Research Center） 1986 年 SEL(Software Engineering Laboratory) − カーネギーメロン 大学ソフトウェア 工学研究所 （SEI） 機関概要 活動内容 カ ー ネ ギ ーメ ロ ン 大 学に設立された Cylab という研究所が 中心となり、ベンダ企 業、ユーザ企業 、政 府機関など 30 の機 関 が結 集 し たコンソ ーシアム 米科学財団（NSF）の 産 学 協 同 リ サ ーチ・ センターの 1 つのプ ロジェクト メリーランド大学、 NASA/Goddard 及び CSC(Computer Science Corporation）という産 官学のジョイント・ベ ンチャーとして設立 ソフトウェア品質向上 の研究を行う、最も 先端的な研究所の一 つ ・ 現在普及しているプロセス重視のソフトウェ ア・テスト（CMM、ISO-9000 など）では不十 分なため、ソフトウェアの完成品を検査し、 そのパフォーマンスを評価する検査システ ムの構築。 ・ ソフトウェアの品質問題によって生じるビジ ネス上のリスクや経済インパクトについて の調査研究。 科学技術の研究開発における産学の長期 的パートナーシップの構築・ソフトウェア品質 に関わる研究をはじめ、ソフトウェアエンジニ アリングに関わる多岐にわたる研究。 ・ 軍事や宇宙開発への民生用（COTS）ソフト ウェアを利用する場合の信頼性研究。 ・ ソフトウェアのバグを発見する技術に関す る研究。 − メリーランド大学 Fraunhofer Center for Experimental Software Engineering 1998 年 ジョージア工科 大学 Aristle Research Group − ・ ソフトウェア・プロセスの成熟度モデルであ る CMM(Capability Maturity Model)の開発。 ・ CMMI を効率的かつ効果的に導入するた めの、ベスト・プラクティスの紹介。 ・ ソフトウェアのパフォーマンスや信頼性を予 測可能にする研究。 ・ 現在広く用いられているコンポーネント・ベ ースのソフトウェアエンジニアリング・プロセ スやツールを超える次世代ソフトウェア開 発技術の研究開発。 ・ ソフトウェア開発現場での技術向上。 ・ 高い 信頼性のあるソ フトウェア開 発及 び NASA の施設での実証試験。 ・ ソフトウェア・ライフサイクルに応じたソフト ウェア・プログラミングのコード解読技術の 開発・改良。 ・ システム検証の効率的な手法の開発。 独 Fraunhofer が独以 外に持つ世界 57 箇 所の拠点の一つとし て、メリーランド大学 内に設立 ソフトウェアエンジニ アリ ン グ、ソ フ トウェ ア開発プラクティス、 ソフトウェア・プロセス などの研究拠点 ソフトウェア開発・試 ・ ソフトウェア開発・試験・維持管理といった ソフトウェア・ライフサイクルのあらゆる局 験・維持管理といっ 面を自動化させるツールの研究・開発。 たソフトウェア・ライフ サイクルに焦点を当 ・ ソフトウェア出荷後に、恒常的にソフトウェ アのパフォーマンスをモニタリング・分析 てた研究拠点 し、問題の迅速な対処を行うための自動 化ツールの開発研究。 114 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt ３） 我が国における取組 我が国では、本研究会をはじめとして信頼性（ディペンダビリティ）を産官学一体となって 総合的に検討しているところであり、定量的に“見える化・測る化”を進める方向を明確にし た上で、欧州や米国との連携を早急に進めていく必要がある。 我が国の情報システムの信頼性に係る政策体系（図Ⅲ- ２）は、産業構造審議会の情報 経済分科会の下に情報サービス・ソフトウェア小委員会と、情報セキュリティ基本問題委員 会が設置され、これに報告する形で“高度情報社会における情報システム・ソフトウェアの 信頼性及びセキュリティに関する研究会”（本研究会）において検討が実施される体系とな っている。検討課題としては、信頼性に関して 6 テーマ、情報セキュリティに関して 2 テーマ が設定されており、テーマ毎に検討会や研究会等が設置され活発な議論が行われている。 具体的には、信頼性に係るテーマとしては、信頼評価手法、取引適正化、共通認識ツール、 重要インフラ対応、ソフトウェアメトリクスの高度化、ソフトウェア適合性評価の 6 テーマであ る。情報セキュリティに係るテーマとしては、システム LSI セキュリティ評価、電子認証の 2 テ ーマとなっている。各テーマの検討結果を本研究会へのインプットとするとともに、本研究会 での議論をフィードバックすることで、各テーマの検討に反映させることで議論を深化させて いる。 我が国で実施されている情報システムの信頼性に関する“見える化・測る化”においては、 我が国の現状や取組が国際的に見てどのように位置付けられているのか同様の基準を用 いてベンチマークする必要がある。このような“見える化・測る化”のための国際標準化に係 る 取 組 と し て 、 IT プ ロ ジ ェ ク ト を 事 後 評 価 す る た め の “ IT Project Performance Benchmarking Framework”が我が国主導の下で検討が始まっており、ワーキングドラフ トを提示したところである。 運輸・物流・情報通信など様々な分野でグローバル化が進展するとともに、このような重 要社会インフラにおける情報システムの依存性がますます高まってきている。そのため、情 報システムの信頼性が社会に与える影響は、個別の域内にとどまらず全世界に波及する可 能性が日々増していると考えられる。今後とも、我が国における情報システムに係る信頼性 とセキュリティに関する取組を着実に進めるとともに、我が国主導のもと一極だけの取組で はなく、欧州、米国、日本（アジア）の三極で密接に連携しながら、積極的に議論を進めて いく必要がある。 115 第三部 （１） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 産構審情報経済分科会 情報ｻｰﾋﾞｽ・ｿﾌﾄｳｪｱ小委員会 情報ｾｷｭﾘﾃｨ基本問題委員会 報告 高度情報化社会における情報ｼｽﾃﾑ・ｿﾌﾄｳｪｱの信頼性及びｾｷｭﾘﾃｨに関する研究会 • 各検討会の結果をインプット • 研究会での議論をフィードバック 信頼性評価手法 重要インフラ対応 • 信頼性ｶﾞｲﾄﾞﾗｲﾝ及び評価指標改訂検討会 • 信頼性モデル構築に関する調査研究 • 情報システムの信頼性評価手法調査 • 信頼性評価指標システムの構築 • 重要インフラ情報システム信頼性研究会 取引適正化 メ トリクス高度化 • ソフトウェアメトリクスの国際標準と活用方法 の調査及び管理基準の策定 • ソフトウェアメトリクス・動向調査 • ソフトウェア・メトリクス高度化検討委員会（仮） • 情報システム・ソフトウェア取引高度化コン ソーシアム • パフォーマンスベース契約研究会 システム LSIセキュリティ評価 システムLSI等のセキュリティ評価に関す る評価体制の整備 • システムＬＳＩチップ評価技術検討ワーキ ンググループ 電子認証 電子認証に関するガイダンス • 電子認証に関する調査研究（仮） 共通認識支援ツール ソフトウェア適合性評価 • 機能要件の合意形成技法ＷＧ • 非機能要求グレード「ユーザビュー検討委員 会」 • 適合性評価制度委員会 • 欧州におけるDependability&Securityの取組 等調査 図Ⅲ- ２ 我が国の情報システムの信頼性に係る政策体系 （２）主要各国との政策対話の強化 高度情報化社会を支える IT の利活用の成熟度、ネットワークインフラの整備などの状況は各国 によって様々である。しかしながら、グローバル化が進展し、国境を越えた経済活動や交流が拡大 していく中で、高度情報化社会の実現に向かっていく流れはどの国も変わることはない。生活習慣 や文化的特性などを背景に、それぞれの国が実現していく高度情報化社会は様々な姿を見せて いくと考えられるが、そのような社会における“インフラの中のインフラ”である情報システム・ソフトウ ェアの信頼性及びセキュリティは、どの国にとっても重要な経済的・社会的課題となることは間違い のないことである。 したがって、我が国における高度情報化社会を見据えた情報システム・ソフトウェアの信頼性及 びセキュリティに関する取組は、将来世界中の国が同じように取り組むべき課題となることを踏まえ、 現時点から国際的な議論を活発に行い、協調して取り組むべき課題については、その解決に向け て各国が連携して活動を展開することが必要である。 政府・経済産業省には、こうした状況を認識し、他国に対して日本における取組状況や収集・分 析したデータなどを積極的に発信するとともに、対話機会の拡大と連携する具体的な取組の立ち 上げに向けた働きかけを積極的に進めることが求められる。また、政府・経済産業省は、こうした取 組について産業界及び学界と情報を共有するとともに、産業界、学界がそれぞれ加わっている国 際的な議論の状況を産学官で共有するようにし、高度情報化社会に向けた我が国の取組を各国 に対してモデルとして積極的に示していくための取組を進めることが重要である。 116 第三部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt ① 情報システム・ソフトウェアの信頼性及びセキュリティに関する欧米先進 IT 国と の政策対話 １） 欧州との状況 日本と EU は、平成 10 年（1998 年）に IT 分野における日・EU 協力の推進を目的とし て政策ダイアログを設置することで合意し、IT 分野における様々な課題についてこれまで に 7 回にわたって意見交換を進めてきた。また、平成 13 年（2001 年）には日・EU 定期首 脳協議において“共通の未来の構築 日・EU 協力のための行動計画”を取りまとめ、“グロ ーバル情報社会”の構築に向けて情報・通信技術（IT）に関する協力の強化をうたい、平成 16 年（2004 年）には“情報通信技術に関する協力についての共同ステートメント”をまとめ るなどの取組を進め、オープンソースソフトウェアの利活用に係る協力やセキュリティ分野に おける対話を強化し、その協力関係の深化に努めてきたところである。さらに、昨年には日・ EU・ICT 研究協力フォーラムが開催され、ナノエレクトロニクスや情報検索・解析技術など に関する研究開発について意見交換を行った。 しかしながら、昨年報告された“日・EU ビジネス・ダイアログ・ラウンドテーブル（BDRT） 2007 年の提言に対する欧州委員会からのプログレスレポート”では、“ICT インフラの信頼 性、安定性確保に向けた協力”の中で、“国際協力の面では、まだ改善の余地が残されて いる”との指摘がなされたところである。 情報システム・ソフトウェアについては、ソフトウェアエンジニアリングの高度化に向けて、 我が国の IPA/SEC が IESE（Institute for Software Engineering： ドイツ・フラウン ホーファ財団の研究所の一つであり、実証的なソフトウェアエンジニアリングの研究所）と連 携を進めてきているところである。しかしながら、高度情報化社会を目前に据え、情報シス テム・ソフトウェアの信頼性及びセキュリティに関して実効的に管理するための定量的な管 理・評価指標の在り方を含めた諸課題について、十分に意見交換が進められているとは言 い難い。 欧州においては、現在“i2010 戦略”が進行中であり、第７次 EU 研究開発枠組み計画 （FP7）の IT 分野における取組において、情報システムの信頼性及びセキュリティは、取り 組むべき重要な課題として認識され、情報サービスに係るサービス・レベル・アグリーメント （SLA）等に関する研究プロジェクトが進められている。こうした取組は、我が国における情 報システム・ソフトウェアの信頼性及びセキュリティに関する様々な取組との関係が非常に 深いものであり、日・EU の間で緊密に意見交換を進めながら両者が連携して取組を進め ていくことは、お互いにとって効果的であり、来るべき高度情報化社会においても重要な基 盤を提供していくことが可能になっていくと考えられる。 ２） 米国との状況 IT 分野において新たな技術やサービスを次々と生み出してきた米国は、我が国の IT 産 業にも大きな影響を与えながら深い関係を保ってきており、両国の間では、政府、産業界、 117 第三部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 学界などそれぞれが様々な機会を通じて情報交換を進めてきている。しかしながら、欧州と のような形での IT 分野における定期的な政策対話の場は設置されていない。 情報システム・ソフトウェアについては、ソフトウェアエンジニアリングの高度化に向けて、 欧州における場合と同様、我が国の IPA/SEC が、ソフトウェア開発プロセス成熟度モデル （CMMI）などで有名な米国のカーネギーメロン大学のソフトウェア・エンジニアリング研究 所（SEI）と連携を進めてきているが、産業分野や学術活動における交流と比べ、公的な機 関間の連携にはさらなる取組が求められる。 情報セキュリティについては、経済産業省及び IPA セキュリティセンターが、商務省の管 轄する国立標準技術研究所（NIST）と年 1 回定期協議を行うなど密接に連携を行ってきて いるところであり、今後も引き続き、このような関係を維持していくことが重要である。 米国においては、情報システム・ソフトウェアの信頼性及びセキュリティに関して、ソフトウ ェア・アシュアランスやシステム・アシュアランスという言葉を定義づけ、その向上に向けた取 組を進めている。 ソフトウェア・アシュアランスは、システムライフサイクルにおいて故意あるいは偶然に混入 したソフトウェアの脆弱性とソフトウェア機能が意図したとおりに動作するかを示す信頼性の 水準として定義づけられ、政府の各部内でソフトウェア・アシュアランスを適切に管理し、実 現するための取組が進められている。国土安全保障省（DHS）では、“セキュア・サイバース ペースに向けた国家戦略（Action/Recommendation 2-14）”に基づき、ソフトウェア・アシ ュアランス・イニシアティブに取り組んでいるところである。また、ソフトウェア・アシュアランス よりも広くシステムを捉えて信頼性を確保する考え方としてシステム・アシュアランスの検討 も進んでいる。システムの品質の向上に向けた取組はソフトウェアの品質に関する取組と捉 えつつ、ソフトウェアの品質属性を定量的に把握し、アーキテクチャを構築する中で発生す る各属性のトレードオフの関係を重要性と影響度を的確に管理して顧客の期待するシステ ムを実現するという考え方であり、ここでは、開発プロセスの重要性を認識しつつも、それに 極端に依拠するのではなく、プロセス成熟度を踏まえつつ、如何に顧客の期待に応えるソ フトウェア・プロダクトの実現に結びつけるかという観点で捉え、そのためにトレードオフの関 係となる定量的な品質属性を顧客の要求する形で的確にバランスさせて実現するアーキテ クチャの重要性が強調されている。 米国におけるこうした動きは、本研究会で議論されてきたこと=信頼性及びセキュリティが 適切な水準で確保された情報システム・ソフトウェアの実現に向けた取組、と方向を同じく するものであり、我が国における定量的な管理・評価指標の整備などに向けた取組を進め ていく上でも、日米間でより密度の濃い意見交換が行われ、連携が進むことが、グローバル に高度情報化社会を実現していく上でも極めて意味のあることであると考えられる。 118 第三部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt ３） 目指すべき方向 上記のように、欧米においても情報システム・ソフトウェアの信頼性及びセキュリティは情 報化がより進展していく中での大きな社会的課題と認識される中、昨年 10 月、東京におい て経済協力開発機構（OECD）の産業イノベーション起業委員会（CIIE）において進められ ている“ソフトウェア・セクターにおけるイノベーション”の調査研究プロジェクトに関わる会議 が開催された。本会議では、日本の講演者から情報システム・ソフトウェアの信頼性に関す る日本における様々な取組が紹介され、各国の政府・企業関係者、研究者から高い関心が 示された。本調査研究プロジェクトでは、高度情報化社会を目前に控え、IT の利用者の視 点からソフトウェアのイノベーションがどうあるべきかについて議論がなされ、信頼性を如何 に確保し、実現していくかについても重要な課題として積極的に意見交換がなされてきて いる。その中で、本研究会でも議論をしてきた我が国の“情報システムの信頼性に関するガ イドライン”や“モデル取引・契約書”も報告書原案に取り上げられるなど、日本における取 組は高く評価されている。 情報システム・ソフトウェアの信頼性に関して、既に欧州委員会などとは非公式に意見交 換が行われているところであるが、本研究会において議論をした課題である情報システム・ ソフトウェアの信頼性及びセキュリティの“見える化・測る化”のための定量的な管理・評価 指標の整備や取り組むべき技術課題などについて議論を深め、国際標準化や国際連携プ ロジェクトを推進していくため、我が国と同様に高度情報化社会の入り口に立っている欧米 IT 先進各国との間で、定期的な政策対話を開始することが必要な時期を迎えている。 ② 情報システム・ソフトウェアの信頼性及びセキュリティに関するアジア諸国との 政策対話の強化 グローバルな経済活動の進展に伴い、企業の技術情報や個人情報を含む重要な情報資 産が国境を越えて幅広くやり取りされるようになっている現在、国際的な商取引のみならず、 海外の出先機関、現地子会社等を含めた国際的な情報セキュリティの確保が重要な課題と 認識されるようになっている。とりわけ、我が国の産業活動と密接な関係を持つ地域における 情報セキュリティの確保の課題は、地域内における産業活動の一体化が加速していく中で、 国内における情報セキュリティの問題と同じくらいの影響度を持つようになってきており、その 重要性を一層増大してきているところである。 我が国との経済関係が密接であるアジア、特に ASEAN との関係におい ては、日・ ASEAN 包括的経済連携（AJCEP）協定をはじめとする EPA・FTA の締結もあり、今後さらに 域内の経済関係の一体化が予想され、経済・産業活動の実態に合わせた取組の強化が求め られる。 今後、我が国企業がグローバルな競争力を確保しつつ、ASEAN 各国での事業展開を拡 大し、日・ASEAN 間の経済関係を深化させるにあたっては、ASEAN 地域内における知識 集約型産業、高付加価値産業の成長を通じて、地域の知識経済化を進めていくことが重要で 119 第三部 （２） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt あり、そのためには、ASEAN 地域において、企業情報を安全・安心にやり取りできるセキュア なビジネス環境を整備していくことが喫緊の課題である。具体的には、日本と ASEAN 諸国が 協力して、アジア諸国において、技術移転・知識移転の必要条件となる情報セキュリティ対策 を実施していくことが求められ、その際には、技術的な解決策にとどまらず、企業における情 報セキュリティガバナンスの確立を視野に入れた、包括的な対策が必要である。 経済産業省では、昨年の日・ASEAN 経済大臣会合（AEM−METI）において、“アジア 知識経済化イニシアティブ”を提唱し、企業情報セキュリティの確保をその一部として位置付 けた。そして、本イニシアティブに関係する具体的な取組として、東アジア・アセアン経済研究 センター（ERIA）にて、我が国の情報セキュリティ対策ベンチマークを土台に、アジア共通ベ ンチマークの策定に向けた政策研究を実施したほか、JICA や AOTS の枠組みを活用した ASEAN 各国のコンピュータセキュリティ緊急時対応体制の整備に関する人材育成や、企業 の情報セキュリティ対策の現状調査と普及啓発セミナーの開催といった諸施策を実施してき た。 本年 2 月、経済産業省は、内閣官房情報セキュリティセンター、総務省と合同で、ASEAN 諸国の経済・投資関係省庁及び情報通信省庁の参加を得て、我が国にて“日・ASEAN 情報 セキュリティ政策会議”を開催し、上記のような我が国の考え方とこれまでの取組を紹介した。 同会議には我が国経済界及び関係団体も参加し、各々の立場から、情報セキュリティ対策の 必要性や、これまでの活動を通じた情報セキュリティ対策の重要性について説明し、ASEAN 側からも、情報セキュリティ対策の必要性に関する合意が得られたところである。 今後とも、ASEAN 各国における情報セキュリティ対策の進展に向け、政府レベル・民間レ ベルでの対話を行っていくとともに、情報セキュリティガバナンスの浸透に向けたセミナーの開 催や、政策研究、人材育成等の取組を積極的に実施していくことが求められる。 （３）評価・管理指標の国際標準化を目指した産学の連携体制の具体化 ソフトウェアの信頼性に係る国際標準化について、ソフトウェアエンジニアリング分野のプロダクト 評価やプロセスアセスメントに関しては ISO/IEC25000 や 15504 シリーズ、CMMI など既に様々 な取組が導入されている。しかしながら、セキュリティや信頼性に係る分野では、組込み系ソフトウ ェアで活用されている機能安全規格である ISO/IEC61508 などが存在するものの、これら規格は、 自動車、航空機等の設計・開発などのシステムエンジニアリングで用いているハードの信頼性の概 念を基本に、これを援用する形で策定されている。ハードウェアと比較した場合のソフトウェアの特 徴である、無形性、拡張性、非拘束性等を考慮したセキュリティや信頼性に係る議論は、世界的に も不十分であるといえる。ソフトウェアの信頼性の議論を踏まえ、ソフトウェアとしての特性を捉えた 形での情報システムの信頼性に係る標準策定に向けた取組を、我が国主導で実施していく必要が ある。 また、情報セキュリティに関する国際標準については、前述の IT セキュリティ製品に関する ISO/IEC 15408 のほか、暗号モジュールのセキュリティに関する ISO/IEC 19790 がある。国内で 120 第三部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt は、IPA セキュリティセンターが、ISO/IEC 15408 に基づく“IT セキュリティ評価及び認証制度 （JISEC）”、ISO/IEC 19790 の一致規格 JIS X 19790 に基づく“暗号モジュール試験及び認証 制度（JCMVP）”の運用を行ってきており、今後もこれらの取組を着実に実施していく必要がある。 さらに、情報セキュリティマネジメントに関する規格として、ISO/IEC 27000 シリーズがある。現在、 27014（情報セキュリティガバナンス）について検討が進められているところであり、経済産業省の “情報セキュリティガバナンス”68 に関する取組の成果などを通じて、貢献していくことが有益であ る。 一方で、自動車産業における組込みソフトウェア開発69やアセスメントプロセス70に係る標準化の 事例からも分かるように、ソフトウェア産業における現在の標準策定の流れとしては、非競争領域に ついてコンセンサスを取って標準化していくのではなく、競争領域としての自社の製品を標準とす ることで競争力とするという流れになってきている。すなわち、デジュール化のプロセスをデファクト 化のための手段として活用し、競争領域において自社の製品を標準とすることでシェアを拡大して いく戦略を採用している。一方、ソフトウェア開発に係る標準については ISO25000 シリーズ、 ISO1550471などの例にもあるように、例えばソフトウェアの開発プロセスに係る全体概念と枠組み を構築し、標準化した後に個別産業セクタ（自動車業界、医療業界、航空宇宙業界など）に特化し た個別標準が策定されている。このような状況下において、一部精力的な活動が行われてはいる ものの、我が国の標準化に係る取組は十分とは言えない。 ソフトウェアに係る標準は ISO/IEC 化されたものに限ったとしても、2008 年 5 月現在で 101 個 の規格が存在し、51 件の新規規格について検討がなされているが、我が国においては、一部専 門家を除き、ユーザもさることながら情報システムの開発に携わるエンジニアの多くも認識していな い状況である。現在、国際標準は英語で策定されるという言語の格差の問題があるとはいえ、多く の国際標準が日本語に翻訳されていないことからも、その認識の低さが伺える。 国際標準について、現状、どのような規格が有効であり、どのような運用が効果的か、課題は何 かなどを実証・検証するための産学官共同評価体制、標準に関し影響を受ける可能性のあるユー ザ企業を含めた産業界へ、その重要性を浸透させるための普及促進活動体制の構築について、 産学官が連携した取組を積極的に推進していくことが喫緊の課題である。特に、国際標準化の策 定に向けた取組では、個別分野や機能に係る標準化提案を主導するにとどまらず、上位概念とし ての信頼性確保とはいかなるものかをソフトウェアの無形性を考慮したうえで体系化し、信頼性に 68 情報セキュリティガバナンス：社会的責任にも配慮したコーポレート・ガバナンスと、それを支えるメ カニズムである内部統制の仕組みを、情報セキュリティの観点から企業内に構築・運用すること（ 「企業に おける情報セキュリティガバナンスのあり方に関する研究会報告書」 、経済産業省、平成 17 年 3 月） 。 69 徳田昭雄他「車載ソフトウェアの標準化と AUTOSAR の動向」 立命館経営学 第 45 巻 第 5 号 2007 年 1 月 pp 153, 「自動車車載電子制御システムの日欧標準化推進 コンソーシアムにおける標準策定プロセスおよび コンソーシアム運営手法の国際比較・分析」 独立行政法人新エネルギー・産業技術総合開発機構 平成１７年度 産業技術研究助成事業 研究成果報告書 平成 18 年 12 月 70 日経 Automotive Technology 2007 年冬号、IPA 「Automotive SPICE 概要」SEC Conference 2007 2007.10.30 71 Process Assessment and ISO 15504 ISBN 0-387-23172-2、Process Assessment and Improvement ISBN 0-387-23182-X 121 第三部 （３） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt 関する標準の枠組みそのものについてより戦略的な観点から提案を行なっていくことが重要である。 このような国際標準化活動の実施に際しては、既存の国際標準との整合性や提案経緯の説明責 任等に留意して進めることが必要である。 産業界においてもユーザ企業を含め、デジュール化プロセスを活用したデファクト化といったマ ーケット戦略として、あるいは、標準化の受益者としてより良い環境を得るために、標準化を戦略的 に捉えた、産業界全体として積極的に取り組んでいく必要である。なかでも、そのような標準化に取 り組むことが可能な人材として、他国との交渉力に長け、全体の枠組みについてコンセプトを提案 できる人材の育成が課題となる。 標準化に関しては、ユーザ企業を含めた産業界が自身の戦略の一環として主体的かつ積極的 に取り組むことが、我が国の競争力強化に資するものとして期待されており、産業界の取組につい て学界が体系化等のサポートを実施し、官が国内対立の調整を行うといった、産学官のそれぞれ の立場での役割分担を明確化し産学官協働して実施していく必要がある。 特に、産業界における取組としては、ISO/IEC 等の社内への浸透を行った上で、ISO 等の国際 会議における影響力の強化を図っていくことが必要である。開発現場のエンジニアがテクニカルな 部分を、当該領域の事業責任者や CIO クラスが政策的な議論に参加することで、説得感のある提 案ができると考えられる。 （４）国際協力体制を組んだプロジェクトの推進 ソ フ ト ウ ェ ア エ ン ジ ニ ア リ ン グ の 分 野 で は 、 世 界 的 な 研 究 機 関 で あ る SEI （ Software Engineering Institute:米国カーネギーメロン大学の研究所）が、主に米国国防総省からの予算 を受けて、プロセス改善モデルである CMMI（Capability Maturity Model Integration）の 研究を行うなど、世界的な研究所としての地位を確立している。また、欧州においては、IESE （Institute for Software Engineering）が世界的な研究所としての地位を確立している。ソフト ウェアエンジニアリング手法の標準化を進めていく上では、これらの関係機関との連携が不可欠で ある。 そこで、我が国においてはこれまでも IPA/SEC において、SEI との間では、CMMI へのインプッ トと我が国への紹介を行うとともに、IESE との間では、定量的な見積り手法である CoBRA 法 （Cost Estimation, Benchmarking and Risk Assessment）を日本の企業の実際のプロジ ェクトに適用する実証実験を実施し、CoBRA 法の改善・高度化に関する国際的な共同研究を進 めてきている。 今後は、上記のような関係機関とのいわゆる“見える化・測る化”アプローチでの連携に加え、ソ フトウェアエンジニアリング技法の開発に関する連携も検討する価値がある。例えば、ドイツのフラ ウ ン ホ ー フ ァ 財 団 の 研 究 所 の 一 つ で あ る 、 ISST （ Institute for Software and Systemtechnik）においては、組込み系開発プロセス、要求工学、モデリングなどを研究している が、そのような新たな国際的なカウンターパートとの連携を積極的に模索していくべきである。 122 第三部 （５） 書式変更: フォント : (英) ＭＳ Ｐゴ シック, (日) ＭＳ Ｐゴシック, 9 pt （５）ソフトウェアの適合性・相互運用性の評価のための認証機関間の国際連携体制の構 築 「第 1 章（2）⑤オープンな標準に基づいたソフトウェアの適合性・相互運用性等を評価する体 制」において述べたように、我が国では、IPA オープンソフトウェアセンターを中心にオープンな標 準に関する評価基準の策定と、適合性評価実施に向けた取組を実施しているところである。この取 組については、我が国独自の基準を策定してしまうと諸外国との相互運用性確保に問題が生じる おそれがあるため、基準策定においては諸外国との連携が不可欠である。 現在、EU においては、情報システムをよりオープンなものとしていくための我が国と同様の取組 が行われている。その一つとして、欧州委員会においては、情報システムの相互運用性をより拡大 す る た め に 用 い る べ き 技 術 仕 様 の 評 価 手 法 を 、 情 報 科 学 総 局 に 設 置 さ れ た IDABC （ Interoperable Delivery of pan-European eGovernment Services to Public Administrations, Businesses and Citizens）内の CAMSS（Common Assessment Method for Standards and Specifications）プロジェクトにおいて取りまとめている。現在、経済産業省で は、上記取組を EU における取組とより親和性の高いものとするべく、欧州委員会と緊密に情報交 換を行っているところであり、ソフトウェアの適合性・相互運用性を評価するための体制に当たって は、日欧それぞれが設置する認証機関の連携を含めて、協力して事業を進めていくことが重要で ある。 また、北東アジア OSS 推進フォーラムでは、日中韓 3 カ国の協力によって、アジアにおける OSS（Open Source Software）の推進を図っているところであるが、よりオープンで信頼性の高い ソフトウェアの活用を促進していくため、この枠組みを活用し、日本が策定した技術参照モデル（Ｔ ＲＭ）などの成果の共有を進めつつ、今後、検討が進められるであろうオープンな標準に関する適 合性評価を含めたソフトウェアの適合性・相互運用性の評価のための認証機関について、アジア における国際連携体制を構築し、アジアとしてのプレゼンスを高めていくことが必要である。 123 おわりに 高度情報化社会は、あらゆる領域で製品にソフトウェアが組み込まれ、それらが情報システムと つながり、さらに、情報システム同士がつながっていくことで高度なサービスが展開されるという、現 在の我々のイメージを超えた生活空間、情報経済が拡がる社会となっていくだろう。しかし、その深 層では、我々の目からは直接見えない形でのリスクもまた拡がっていくこととなる。 本研究会では、こうした新たな社会を実現するための生活・経済・産業のインフラとなる情報シス テム・ソフトウェアの在り方について、“信頼性及びセキュリティ”という基本的な社会的要請を軸に 据え、信頼性及びセキュリティの“見える化・測る化”によって、如何にして適正な水準を実現してい くのかを集中的に議論してきた。我々は、サービスによる便益とそのリスク、リスクを顕在化させない ためのコストがバランスした状態を社会的な共通認識として形成していくことの重要性を訴え、この 社会的共通認識を実現することを目標として、情報システム・ソフトウェアの活用の在り方、開発・運 用・保守の在り方、取引の在り方、新たな技術の開発やその活用に関して注視していくべき課題、 さらには人材育成に至るまでのあらゆる論点について検討を行い、本報告書を取りまとめた。 本報告書が、新たな社会を実現していくための取組を開始する重要な出発点としての役割を果 たし、そのことが高度情報化社会に向けたイノベーションを生み、国際競争力の強化へとつながっ ていくきっかけとなれば、何よりも喜ばしいことである。 更に重要なことは、本報告書で提言された内容が、速やかに、そして着実に実行に移され、実 現されていくことである。本研究会では、高度情報化社会に向けた社会の動きを睨みながら、提言 した内容についての工程表をまとめている（別紙参照）。工程表は、“見える化・測る化”の推進、適 正な取引の確立、運用・保守の高度化、新たな技術課題への対応、国際貢献の５つから構成され ている。特にはじめの３年間に本報告書で提言された内容を着実に進めていくことで高度情報化 社会への強固な発展基盤を構築することが鍵であり、そのためには、産学官が緊密に連携して速 やかに実行に移していくことが重要であるとともに、政府に対して、本工程表を踏まえた総合的な 取組を展開していくことを強く求めるものである。工程表では明示的に取り上げられていない提言 内容、例えば人材育成については、既に産学人材育成パートナーシップ情報処理分科会を中心 とした実効的な取組が進められているところであり、こうした既存の取組とも連携しながら、より経済 社会に対してインパクトのある政策の展開を求めて止まない。 今後、本報告書第一部で指摘をした社会的共通認識の必要性が受け止められていく中で、情 報システム・ソフトウェアを通じたサービスの最終利用者が、サービス内容とその潜在的リスク、それ を抑制するためのコストのバランスを考える“賢い最終利用者”として存在感を増し、より広く、深く 社会的共通認識の形成に関与していくことが求められる。そのためには、本報告書で指摘したとお り、サービスを提供する企業がマスメディアなどを通じながらより密度の高いコミュニケーションを図 り、“賢い最終利用者”の啓発を進めていくことが重要であり、そのような取組と並行して、最終利用 者が積極的に社会的共通認識の形成に参画していくための環境の在り方について検討を進めて 124 いくべきである。 既に述べたとおり、今般取りまとめられた報告書は、新たな社会の実現に向けた出発点である。 その歩みを確かなものとしていくために、本研究会は、社会が変化していくことに対応して、本報告 書で示した方向性を継続的に見直し、アップデートを図っていくべきであると考えている。 最後に、本研究会の発したメッセージが、高度情報化社会において様々な情報システム・ソフト ウェアを巧みに連携させながら創造的で高度なサービスが生み出していくことが期待されるＩＴ分野 に関わるユーザ企業、ベンダ企業の人々、学識経験者、法曹関係者や政策担当者のみならず、 広く我が国の人々、さらに、他の国々に対しても有意義なものとして受け止められ、高度情報化社 会の実現に向けた協働作業を生み出す端緒となることを願っている。 125 英字略語等 ADR Alternative Dispute Resolution（裁判外紛争解決手続） AITTS Advanced IT Training System AJCEP ASEAN-Japan Comprehensive Economic Partnership（日アセアン包括的経 済連携） AOTS Association for Overseas Technical Scholarship（財団法人海外技術者研修協 会） API Application Programming Interface（ソフトウェアを開発する際に利用でき る命令や関数） ASEAN Association of Southeast Asian Nations（東南アジア諸国連合） ASP Application Service Provider（アプリケーションサービスを提供する事業者） ATM Automated Teller Machine（現金自動預払機） AWS Amazon Web Services（Amazon社が提供しているWebサービス） BCP Business Continuity Plan（事業継続性計画） BDRT The EU-Japan Business Dialogue Round Table（日・EUビジネス・ダイア ログ・ラウンドテーブル） B-Method （Bメソッド：Jean-Raymond Abrial を中心としてフランスおよびイギリス で開発された形式手法の一種） BPO Business Process Outsourcing（業務のアウトソーシング） BSI Build Security In CAMSS Common Assessment Method for Standards and Specification CC Common Criteria（コモン・クライテリア：ITセキュリティ評価及び認証の ための国際規格。2.3版がISO/IEC 15408:2005となっている） CCRA Common Criteria Recognition Arrangement（CC承認アレンジメント：CC に基づいたセキュリティ評価・認証の相互承認に関する国際協定） CEO Chief Executive Officer（最高経営責任者） CIIE Committee on Industry, Innovation and Entrepreneurship（産業イノベーシ ョン起業委員会） CIO Chief Information Officer（最高情報責任者／IT担当役員） CMM Capability Maturity Model（能力成熟度モデル。CMMIの前身） CMMI Capability Maturity Model Integration（能力成熟度モデル統合） CoBRA Cost Estimation Benchmarking and Risk Assessment（定量的な見積り手法 126 の一種） COMIFIN Communication Infrastructure Middleware COTS Commercial off-the-shelf（市販製品） CRM Customer Relationship Management（顧客関係管理） CSAJ Computer Software Association of Japan（社団法人コンピュータソフトウェ ア協会） CSTB Computer Science and Technology Board（コンピュータ科学電気通信委員 会） DHS Department of Homeland Security（米国国土安全保障省） DOD Department of Defense（米国国防総省） DOL Department of Labor（米国労働省） DVD Digital Versatile Disk（デジタルデータの記録媒体の一種） EA Enterprise Architecture（全体最適化の手法） EC Electronic Commerce（電子商取引） EIF European Interoperability Framework EPA Economic Partnership Agreement（経済連携協定：経済条約の一種。FTAよ りも幅広い内容を含む） ERIA Economic Research Institute for ASEAN and East Asia（東アジア・アセア ン経済研究センター） ERP Enterprise Resource Planning（統合的に経営資源を管理し、経営の効率化を 図るための手法・概念。一般に統合型（業務横断型）ソフトウェアを指すこ とが多い） EU European Union（欧州連合） FAA Federal Aviation Administration（米国連邦航空局） FDA Food and Drug Administration（米国食品医薬品局） FEC Federal Election Commission（米国連邦選挙管理委員会） FP7 Seventh Framework Programme（第7次EU研究開発枠組み計画：EUが行う 研究開発助成の中心的な政策手段） FTA Free Trade Agreement（自由貿易協定） HaaS Hardware as a Service（ハードウェアをサービスとして提供するもの） HCSS High Confidence Software and Systems（高信頼ソフトウェア・システムズ） 127 for Monitoring Financial Critical IaaS Infrastructure as a Service（情報処理のためのインフラをサービスとして提 供するもの） IC Integrated Circuit（集積回路） ICT Information and Communication Technology（情報通信技術） ID Identification（個体識別、利用者識別のための符号） IDABC Interoperable Delivery of pan European eGovernment Services to Public Administrations Businesses and Citizens IESE Institute for Software Engineering（ドイツ・フラウンホーファ財団の研究 所の一つ） IFIP International Federation for Information Processing（国連ユネスコの提案 で組織された情報処理国際連合） IPA Information-technology Promotion Agency（独立行政法人情報処理推進機構） IPA/SEC IPA Software Engineering Center（IPAソフトウェア・エンジニアリング・ センター：エンタープライズ系ソフトウェアと組込みソフトウェアの開発力 強化に取り組むとともに、その成果を実践・検証するための先進ソフトウェ ア開発プロジェクトを産学官の枠組みを越えて展開するIPAの組織） IS Information System（情報システム） ISO International Organization for Standardization（国際標準化機構：国際規格 を策定するための非政府組織） IEC International Electrotechnical Commission（国際電気標準会議：電気及び電 子技術分野の国際規格の作成を行う団体） ISO/IEC/JTC1 ISO/IEC Joint Technical Committee 1（ISOとIECの第一合同技術委員 会：37個のSub Committee（SC）に分かれている） ISST Institute for Software and Systemtechnik IT Information Technology（情報技術） ITA International Telemedia Associates, Inc. ITCA IT Coordinators Association（特定非営利活動法人ITコーディネータ協会：産 業構造審議会情報産業部会情報化人材対策小委員会の中間報告において提唱 された｢戦略的情報化投資活性化のための環境整備の試み｣の趣旨を踏まえ設 立された法人） ITIL Information Technology Infrastructure Library（イギリス政府により公表さ れているITサービスマネジメントにおけるベストプラクティスをまとめた書 籍群） ITO Information Technology Outsourcing（一般事務ではなく、プログラム開発や 運用等のIT関連のアウトソーシング） ITSSG IT Security Group （ 米 国 連 邦 政 府 の 大 統 領 重 要 イ ン フ ラ 防 護 委 員 会 128 （President's Critical Infrastructure Protection Board： PCIPB）の組織） JCMVP Japan Cryptographic Module Validation Program（暗号モジュール試験及び 認証制度：電子政府推奨暗号リスト等に記載されている暗号化機能、ハッシ ュ機能、署名機能等の承認されたセキュリティ機能を実装したハードウェア、 ソフトウェア等から構成される暗号モジュールが、その内部に格納するセキ ュリティ機能並びに暗号鍵及びパスワード等の重要情報を適切に保護してい ることを、第三者による試験及び認証を組織的に実施することにより、暗号 モジュールの利用者が、暗号モジュールのセキュリティ機能等に関する正確 で詳細な情報を把握できるようにするために設置された制度） JCSSA Japan Computer System Seller Association（社団法人日本コンピュータシス テム販売店協会） JEITA Japan Electronics and Information Technology Industries Association（社 団法人電子情報技術産業協会） JICA Japan International Cooperation Agency（独立行政法人国際協力機構） JISA Japan Information Technology Services Industry Association（社団法人情 報サービス産業協会） JISEC Japan Information Technology Security Evaluation and Certification Scheme（ITセキュリティ評価及び認証制度：IT関連製品のセキュリティ機能 の適切性･確実性を、セキュリティ評価基準の国際標準であるISO/IEC15408 に基づいて第三者（評価機関）が評価し、その評価結果を認証機関が認証す る我が国の制度） JPCERT/CC Japan Computer Emergency Response Teamコーディネーションセンター JTI Joint Technology Initiative（共同技術イニシアティブ） JUAS Japan Users Association of Information Systems（社団法人日本情報システ ム・ユーザー協会） JVN Japan Vulnerability Notes（日本で使用されているソフトウェアなどの脆弱 性関連情報とその対策情報を提供し、情報セキュリティ対策に資することを 目的とする脆弱性対策情報ポータルサイト） KPI Key Performance Indicator（重要評価指標：目標達成の度合いを測るための 指数） LSI Large Scale Integration（大規模集積回路） MDA Model Driven Architecture METI Ministry of Economy, Trade and Industry（経済産業省） NASA National Aeronautics and Space Administration（米国航空宇宙局） NASED Association of State Election Directors（全米州選挙管理者協会） NIST National Institute of Standards and Technology（米国国立標準技術研究所） 129 NRC Nuclear Regulatory Commission（米国原子力規制委員会） NSF National Science Foundation（全米科学財団） NSTC National Science and Technology Council（国家科学技術委員会） ODC Office of Device Evaluation OECD Organisation for Economic Co-operation and Development（経済協力開発機 構） OMB Office of Management and Budget（米国行政管理予算局） OS Operating System（基本ソフトウェア） OSS Open Source Software（オープンソースソフトウェア） OSTP Office of Science and Technology Policy（米国科学技術政策室） PaaS Platform as a Service（IaaSに加え、仮想サーバ等を適切に管理するミドル ウェア等もあわせてサービスとして提供するもの） PBC Performance Based Contracting（パフォーマンスベース契約：情報システム の生み出す付加価値に着目して価格を決定する契約） PC Personal Computer（パーソナルコンピュータ） PDCA Plan, Do, Check, Act（計画、実行、評価、改善） PIM Platform Independent Model PKI Public Key Infrastructure（公開鍵暗号基盤：利用者の身元について信頼でき る第三者が審査を行い、秘密鍵と公開鍵を用いて認証を行う仕組み） PMO Project Management Office（プロジェクトマネジメントオフィス） PRM Performance Reference Model（パフォーマンス参照モデル） PSM Platform Specific Model QCD Quality, Cost, Delivery（品質、コスト、納期） RESERVOIR Resources and Services Virtualization without Barriers RFP Request For Proposal（提案依頼） RODIN Rigorous open development environment for complex systems RTCA Radio Technical Commission for Aeronautics SaaS Software as a Service（アプリケーションをサービスとして提供するもの） SAMATE Software Assurance Metrics And Tool Evaluation SAS70 Statements on Auditing Standards No.70（米国監査基準第70号：米国公認 会計士協会（AICPA）が定めた受託業務にかかわる内部統制について評価す る監査人の業務に関する基準） 130 SCC Sustainable Computing Consortium SE System Engineer（システムエンジニア（和製英語） ） SecurIST Secure Information Society Technology SEI Software Engineering Institute（カーネギーメロン大学のソフトウェア・エ ンジニアリング研究所） SEL Software Engineering Laboratory SEMIC.EU Semantic Interoperability Center Europe SERC Software Engineering Research Center SFIA Skills Framework for the Information Age SIer System Integrator（システム・インテグレータ） SLA Service Level Agreement（サービス・レベル・アグリーメント：利用者にサ ービスの品質を保証する契約） SMV Symbolic Model Verifier（Carnegie Mellon大学で開発が開始されたモデル検 査ツールの一種） SOA Service Oriented Architecture（サービス指向アーキテクチャ） SOI The Service Oriented Infrastructure SPIN （ベル研UNIXグループで開発されたモデル検査言語の一種） SQuaRE Software Quality Requirements and Evaluation SSA Social Security Administration 米国社会保険庁 SSL Secure Socket Layer（インターネットでの通信を暗号化するために最も一般 的に用いられている方式。公開鍵暗号方式に基づいており、認証にも用いら れる） SwA Software Assurance SysTrust （情報システムの信頼性について、米国またはカナダの公認会計士により提 供される保証） TRM Technical Reference Model（技術参照モデル） UISS Users' Information Systems Skill Standards（情報システムユーザースキル 標準） UVC User Vendor Collaboration VDM Vienna Development Method（形式手法の一種。その仕様記述言語である VDM-SLはISO/IEC 13817-1として標準化されている） VM Virtual Machine（仮想マシン） WG Working Group（ワーキンググループ） 131 WP Work Program（ワークプログラム） XP eXtreme Programming（アジャイル型開発手法の一種） Z Notation（Z 記法：Jean-Raymond Abrial により開発が始められた仕様記述言語。 ISO/IEC 13568:2002 として標準化されている） 132 削除: 別紙 情報システム・ソフトウェアの信頼性・セキュリティ向上のための工程表 2009年度 2010年度 2011年度 2012年度以降 世の中の動き 様々なサービス・製品が つながり、何の不安もなく 自在に活用できる 高度情報化社会の実現 オンライン サービスの利用拡大 プログラム行数が 飛躍的に拡大 クラウド・ コンピュ ーティング の普及 自動車組み込みソフトは、 2000年当時は100万ステップ程度 で あったが、今や1,500万ステップを 超える【中間報告書参照】 2013年度政府重点手続において、 オン ライン利用率72％以上 【 オンライン利用拡大行動計画目標】 自動車の組み込みソフトは、2015年頃には 1億ス テップに 【中間報告書参照】 ク ラウド・コンピューティング第１フェーズ（限定的利用）（∼2011年） ク ラウド・コンピューティング第2フェーズ（魅力ある技術に）（2010∼2013年） ク ラ ウド・コンピューティング第3フェーズ（コモディティ化）（2012∼2015年） ﹁ 見える化・ 測る化﹂ の推進 社会的共通認識の形成 ◆ 客観的な評価指標の策定 客観的な評価指標の策定 ◆ 非機能要件の 定義手法の確立 非機能要件の合意 手法の実証ﾌﾟﾛｼﾞｪｸﾄ 国際標準化の推進 ◆ 検証スキーム／評価制度 評価スキーム検討 適正な 取引の 確立 ◆ 情報セキュリティ上の 信頼点の確保 電子認証ガイドライン策定 ◆モ デル取引・契約書の普及 ◆ 新しい契約形態への対応 モデル契約書の普及 運用 保守 高度化 ◆ 障害事例対策分析 普及促進 非機能要件の合意手法の高度化・ツール整備 適合性評価のためのテストベッド構築 等の環境整備 普及促進 普及促進 システムＬＳＩチップの評価体制の構築 システムＬＳＩ評価の促進 パフォーマンスベース契約、アジャイル型など多様な開発手法に関するモデル契約書の策定 障害対策事例の収集、 分析、共有体制の構築 新たな 技術課題へ の対応 国際 貢献 ◆政策対話 の推進 仕様検討・体制整備 日本からの情報発信の強化 国際的な政策対話の土壌形成 ユーザ・ベンダ間の 明確な責任関係の下、 信頼性・セキュリティが 確保される産業構造 障害対策事例のデータ収集、情報提供 ◆高信頼クラウド基盤の確立 ◆形式手法など開発技法やテス ト手法の開発・実証 ◆連携するシステムの高信頼設 計ツールの開発 利用者が安心して 利用できる信頼性・ セキュリティ水準 がわかる社会 開発・実証 133 国際的な政策対話の強化 大規模化、複雑化 する情報システム・ ソフトウェアの 信頼性水準を高度化 米国、欧州、アジア との連携体制の確立