ソフトウェア品質監査制度について -...

Information-technology Promotion Agency, Japan

Software Engineering Center

Software Engineering Center © 2012, Information-technology Promotion Agency, Japan

ソフトウェア品質監査制度について～ソフトウェア品質説明力の強化～

2012年9月28日

独立行政法人情報処理推進機構技術本部ソフトウェア・エンジニアリング・センター

統合系プロジェクト研究員田中和夫

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Software Engineering Center © 2012, Information-technology Promotion Agency, Japan 2



（出典）次世代エネルギーシステムに係る国際標準化に関する研究会報告書（2010年1月経済産業省）

統合システムの事例スマートグリッド

3



統合システムの事例スマートハウス

4

（出典）エコーネットコンソーシアム資料



統合システムとしてのスマートハウス

スマートハウスの電源制御システムは複数の装置メーカから提供されるソフトウェア制御のサブシステムから構成される統合システム ⇒ 全体システムとしての信頼性の確保は？

5

出典）http://www.smartenergy.co.jp/project.html に加筆

制御ソフト

制御ソフト

制御ソフト

制御ソフト

制御ソフト

情報系ソフト

制御ソフト

http://www.smartenergy.co.jp/project.html

http://www.smartenergy.co.jp/project.html



製品出荷後の不具合発生製品率の推移

6

IPA 「2011年度ソフトウェア産業の実態把握に関する調査」及び経済産業省組込みシステム産業の実態把握調査

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

2005会計年度

2006会計年度

2007会計年度

2008会計年度

2009会計年度

2010会計年度

なし 10％未満 10～20％未満 20～30％未満 30％以上



組込みソフトウェア開発の課題

7

1番目の課題Top10の推移（2007～2012）

0% 20% 40% 60%

設計品質の向上

開発コストの削減

開発期間の短縮

生産性の向上

新製品の開発

開発能力（量）の向上

新技術の開発

市場の拡大

製造品質の向上

規格認証等への対応

事業環境の変化への対応

製品安全性の確保

品質説明力の強化

開発拠点のグローバル展開

その他

1番目 2番目 3番目

2007 2008 2009 2010

開発期間開発期間

新技術

開発コスト開発期間新製品新製品

設計品質設計品質設計品質設計品質

新技術生産性開発期間開発期間

新製品開発コスト開発能力開発能力

市場拡大開発能力開発コスト生産性

開発能力新技術生産性開発コスト

製造品質市場拡大市場拡大

製品安全新製品新技術新技術

生産性市場拡大製品安全製品安全

製造品質製品安全製造品質製造品質

新製品

設計品質

開発コスト

市場拡大

開発能力

生産性

製造品質

事業環境変化対応

2011

開発期間

新技術

新製品

設計品質

開発コスト

市場拡大

開発能力

生産性

製造品質

規格認証

2012

2012年組込みソフトウェア開発の課題

IPA「2011年度ソフトウェア産業の実態把握に関する調査」及び経済産業省組込みシステム産業の実態把握調査



統合システム関連の対応状況

8

統合システム実現の課題（組込み）統合システム関連の対応状況

0% 20% 40% 60% 80% 100%

組込み

エンタプライズ

ほとんどのシステムが統合化

一部のシステムが統合化

現在統合化を進めている

今後統合化を進める予定

統合化に関る予定はない

わからない

0% 10% 20% 30% 40%

ビジネスモデルの構築

全体の品質の確保

利用者・利用目的・利用シーンの定義

他産業・他分野の文化や技術の理解

信頼できるパートナーの選定

障害発生時の対応

利用者に対する全体の品質説明

パートナー企業のシステムや製品・品質が不明

関係する規格への適合、認証取得

特にない

その他

わからない

1番目 2番目 3番目

IPA「2011年度ソフトウェア産業の実態把握に関する調査」



1. 高い品質のソフトウェアを作ること

仕様通りソフトウェアを正しく作る

用途に適合した正しいソフトウェアを作る

安心・安全なソフトウェアに向けた２つの視点

2.高い品質を客観的に説明できること

ソフトウェア品質監査制度（仮称）

9



ソフトウェア品質監査制度（仮称）の概要

10

利用者【国民】（第二者）

事業者（第一者）

監査機関（第三者）

【国民生活の安全・安心】第三者である監査機関の意見を参考に製品・サービスを安心して利用できる

監査対象：ソフトウェアが重要な役割を担う製品・サービス（例：スマートコミュニティ、自動車など）

独立検証機関設計書など

【監査のための証拠】製品・サービスのテスト結果、設計書、開発手順などの証拠

必要に応じて専門家にテストを依頼し、そのテスト結果を確認

監査を受けることで製品・サービスの顧客信頼度向上

万が一の事故の場合でも品質の説明ができる証拠がある

監査結果

【監査機関の意見】＝合理的保証＊１

事業者の主張は適正です。

*1事業者の主張を合理的に保証（assuarance）するもので、障害や事故が発生しないということを保証（guarantee）するものではない。

記述書

【事業者の主張】＝品質説明この製品・サービスは一定の条件下において安全に使えます。

• 製品・サービスの安全、安心に係る品質目標

• 品質目標を達成するために必要な手段

• 手段を実施した証拠 • 品質目標、手段、証拠のトレー

サビリティ

製品・サービス



ソフトウェア品質監査制度（仮称）検討の背景と経緯第三者の検証・妥当性確認による品質説明力強化の必要性

IPA/SECでの活動経緯２010年3月：産構審情報システム・ソフトウェア小委員会にて第三

者による検証・妥当性確認の枠組みの必要性が示される 2010年4月：IPA/SECの統合系プロジェクト内に検討チームを発足 2010年7月：調査活動開始 2010年11月：制度検討委員会発足（主査：名古屋大学高田教授） 2011年9月：第一次中間報告公開

製品の利用者とのギャップの拡大

利用品質低下の懸念：製品・システムの高度化・複雑化と利用者の多様化により、製品・システムと

利用者との間のギャップが拡大

先端技術製品の潜在リスクへの不安

製品品質低下の懸念：技術の急速な進歩により技術標準（規格）に基づく規格認証の対象範囲外となる領域が拡大

品質説明に対する市場意識の変化

品質説明力の不足：当事者企業の技術的主張だけでなく、第三者の裏付け（検証、妥当性確認）による品質説明への要求の増大

品質文化の異なる業界を跨るシステム

残存する潜在リスクの増加：複数の業界を跨るシステムの拡大に伴い、全体システムとしての品質確認の精度が低下

利用者

事業者監査機関


技術ドキュメント

開発エビデンス

監査結果・意見表明

技術説明

第三者による検証・妥当性確認

事業者の技術的主張の妥当性を、監査機関が開発技術水準と利用技術水準を考慮して第三者の立場で評価し、技術に関する専門知識のない利用者にも理解できる形で情報提供する仕組み

（会計処理における会計監査と同等の役割）

11



本制度の狙いと効果

12



品質説明力の原則

品質目標が明確であること

品質目標を達成するために何をしたらよいか（ロジック）が明確化されていること

ロジックを実施した証拠（エビデンス）が存在すること

品質目標、ロジック、エビデンスが相互にトレースできること

13



本制度と品質説明力

14

監査を受けて保証された製品監査を受けても保証されない製品の例

品質目標品質目標明確な

品質目標

不明瞭な品質目標

考慮漏れ不明瞭な品質目標明確な

品質目標

品質目標

設計書設計書設計書

テスト結果

管理されたプログ

ラム

設計書設計書設計書

テスト結果

プログラム

証拠

◆どんな設計をしたら品質目標を達成できるか ◆どんなテストをしたら

目標達成を確認できるか

？？？？？品質目標を

達成する手段



記述法：ＧＳＮ（Goal Structuring Notation）

：文脈

：回答

：ゴール

：戦略

保証のための構造化された議論の記述法（T.Kellyらにより開発）

ー GSN Community Standard Ver.1.0

ゴール指向要求分析方法論KAOSやFTA（Fault Tree Analysis）に似ている

ゴール（Goal）システムにより満足されるべき要件、目標ゴールはさらに詳細なゴール（部分ゴール）に分解される

文脈（Context) 議論の背景、文脈

戦略（Strategy）論証の方法ゴールから部分ゴールを導く際の規則や方針

回答（Solution/Evidence）論証を支える直接的な証拠

15



品質説明の表記イメージ

主張：目標とする品質を

保持すること

文脈：主張が有効である

状況

前提：主張の前提条

件Ａ

戦略：主張の正当性の論証方針

サブ主張サブ主張サブ主張

エビデンス：主張を正当化する証拠

エビデンス：主張を正当化する証拠

エビデンスの具象化要求

以降の論証の進行が求められている

この戦略に従い、トップの主張が

下の３つのサブ主張に分解される

主張

エビデンス

品質説明本体

主張とエビデンスを結びつける説明の論理構造の「見える化」

16



制度フレームワーク

利用者(第二者)

事業者(第一者)


事業責任者の記述書

作成

監査結果報告書

意思表明

活用

＊審査基準策定機関

審査基準書参照

認定機関（＊：認定対象機関）

活用

参照

利用者･利用者情報障害情報

収集

参照

審査基準策定指針

参照

ソフトウェア品質監査人協会

＊独立検証機関検証依頼検証結果

＊監査機関(第三者)

監査

監査人

監査人

認定基準

監査基準

企業に所属する公認監査人による内部監査も考慮

監査に必要な高度で専門的な検証サービスを提供

産業･製品別の審査基準の策定と維持

利用品質も考慮した品質監査のための基礎情報

監査人の業務査察、能力維持のため継続的な教育研修を提供

17



品質説明力強化に関連するプロジェクトとの連携

利用者

事業者

監査機関

製品、サービス

收集コールセンター

フィードバック

ソフトウェア品質監査制度（仮称）の構築品質確保のための開発手法や監査に有効な開発ツールの研究

共有

要件定義

外部設計

内部設計

実装単体テスト

結合テスト

運用テスト

システムテスト

文書

ツールの提供

Tool Environment for Reliable and Accountable Software

METI 統合システムの推進、国民の安全・安心の確保、国際競争力の強化

監査

助成国際協調

仏LIST

米NIST等

トレーサビリティツール等の開発

利用情報・障害情報

分析結果の情報

クレンジングマイニング

分析

データベース

利用者からの情報を活用要件

推進

18



出典）第一回TERAS成果報告会資料より

19



TIDAコンソーシアムのツールチェーン

開発機能

クレーム

クレームクレンジング

機能

ユーザ情報DB

ダッシュボード機能

モデリング支援機能

モデル要素

ユーザ利用モデリング機能

ユーザ指向テスティング

機能

製品モデリングツール

ユーザ利用モデル

テスト仕様書

音声情報音声解析

ユーザマニュアル

仕様書等

ユーザモデリングツールユーザ指向テスティングツール

ZIPC S１

S3e1

e2

e3

e4 S1 S2 S3

e1 =>S2 × ×

e2 ／ =>S2 ／

e3 ／ =>S3 ／

e4 ／／ =>S1

S2

コールセンターアプリ

クレームポートフォリオツール

ツールPF対応教育基盤

調査情報（PDF）

WEB情報 WEB解析

機能

マルチデータ対応機能

調査情報 DB

WEB DB

ユーザマニュアル

製品ユーザマニュアルモデル

出典）ESEC2012資料 Copyright 2012 TIDAコンソーシアム All rights reserved.

20



障害の未然防止・再発防止・拡大防止の対応状況と利用者情報・利用情報、障害情報・不具合情報の活用

複数回答

0% 20% 40% 60% 80% 100%

セキュリティ規格への対応

機能安全規格への対応

第三者による独立検証・妥当性

確認への対応

アシュアランスケースへの対応

トレーサビリティ管理への対応

対応済み対応検討中対応は不要わからない未記入

0% 20% 40% 60% 80% 100%

開発で活用

運用で活用

経営で活用

活用していない

利用者情報・利用情報障害情報・不具合情報

利用者情報・利用情報、障害情報・不具合情報の活用障害の未然防止・再発防止・拡大防止の対応状況



1. 高い品質のソフトウェアを作ること

仕様通りソフトウェアを正しく作る

用途に適合した正しいソフトウェアを作る

安全・安心なソフトウェアに向けた２つの視点

2.高い品質を客観的に説明できること

22

上流工程の品質強化：形式的仕様記述など



上流工程の重要性

組込みソフトウェアの例

の不具合は要件定義工程で発生する

その内、以上は結合テスト以降に発見される

２５％２５％

５０％５０％

業務ソフトウェアの例

の不具合は要件定義・設計工程で発生する

その内、は統合テスト以降に発見される

３０％３０％

４７％４７％

出展）IPA/SEC「ソフトウェア産業の実態把握に関する調査報告書」

出典）NIST：The Economic Impacts of Inadequate Infrastructure for Software Testing（May 2002）



ＩＰＡ／ＳＥＣ統合系プロジェクトの取組み

統合システム

異種・多様なシステムが接続

利用形態の多様化、当初想定外の利用

不具合の高速な伝搬、甚大化

安全・安心

① 品質説明力強化 ② 上流工程プロセス強化

③ 組織的取り組み強化 ④ 体系的人材育成強化

ソフトウェア品質監査制度(仮称) 形式手法・モデルベース技術その人材育成等

ソフトウェア産業の実態把握に関する調査障害再発防止の組織的マネージメント信頼性自己診断ツール等

共通キャリア・スキルフレームワーク（ITSS、UISS、ETSSの体系化）

24


Software Engineering Center © 2012, Information-technology Promotion Agency, Japan 25

『品質管理も大事だけれども、もっと大事なのは“人質管理”やで。』

（松下幸之助）

Information-technology Promotion Agency, Japan

Software Engineering Center


ご清聴ありがとうございました

「ソフトウェア産業の実態把握に関する調査」へのご協力をぜひお願いいたします。

SECホームページ： http://sec.ipa.go.jp/index.html

ソフトウェア品質監査制度について -...

Documents