第１部：日 本のＱＡの現状

日本と世界のソフトウェア・テストの状況
ソフトウェアテストシンポジウム2003

2003年 ３月 ６日
日立 ソフトウェア・エンジニアリング株式会社
山浦 恒央
yamaur̲t@and.hitachi-sk.co.jp

12

2.日立ソフトにおけるＱＡ方式

1.日立ソフトにおける品質データ:

特別 な方法は使っていない。以下のように 昔からの方法を踏襲。
(1) プログラマは、テスト項目を設計し、テスト項 目を作成し、実行する。
(2) ソフトウェア製品のライフサイクルを通じて、バグ の統計データを収集する。
(3) プロジェクト・マネージャは、バグ の統計データを分析し、プロジェクトを管理する。
(4) 設計部 と独立 したＱＡチームが製品をテストする。

開発 フェーズごとの摘出バグのパーセンテージ
机上
デバッグ

単体
デバッグ

連動
デバッグ

統合
デバッグ

ＱＡチームの テスト

顧客サイト

21.5%

35.1%

28.0%

6.1%

9.3%

0.02%

10,000 件のバグのうち、顧客サイトで出るのは２件。

34(1) プログラマは、テスト項 目を設計し、テスト項目を作り、実行(1) プログラマは、テスト項 目を設計し、テスト項目を作り、実行 (続き)a. プログラマがコーディングを終了すると、テスト項 目の設 計を開始。

テスト項目設計の ガイドライン
b. テスト項目は 全てドキュメント化する。ドキュメント化をすると、以下のような利点 がある。
- テスト項目 の設計 は、仕様を別の視点 から見直すことと同 じ。この見 直しで、プログラム不良だけでなく、仕様関連 の重要バグも見つかる。

a. 基本は 、ソースコード 5 - 15行で テスト項目１件
言語プロセッサ系: 8-12 行で１件
オンライン・ネットワーク系 : 5-10 行 で１件
バッチ系:10-15 行で１件

- テスト自体の 品質を測定できる。
- 同 じテストを何回も繰り返 し実 行できる。
- テストの実 行は、別の 担当者にまかせられる(プロジェクトの日程遅延をb.

回復するために投 入された「素 人エンジニア」にも、テストの 実行可能)。
c. テストの自動実行化( テスト・スイート)を目指す。

5正常ケース
異常ケース
限界・境界環境(別OS等 ): 60% 以下
: 15% 以上
: 10% 以上
: 15% 以 上61(1) プログラマは、テスト項 目を設計し、テスト項目を作り、実行 (続き)(1)プログラマは、テスト項目を設計し、テスト項目を作り、実行 (続き)

マトリックスによるテスト項目 の設 計

a. マトリックスによるテスト項目の利 点

入場料 : ６歳以下 ：無料 ,７歳 〜12 歳：500 円,13歳〜18 歳： 800円 、 19 歳 以 上： 1,000 円
テスト項 目 ID

年齢

入場料

分類
机上テスト
マシンテストZZ-1061218199990円
5 00円
8 00円
1000円
エラー

- 入力条件の 組合 せを網羅 できる。
- 機 械 的に テスト設 計が可 能AD001AD002 AD003 AD004 AD005 AD006 AD007 AD008
XX
X
XXXXX
X
X
X
X
X
X
X
X
異常 境 界 正 常 正常 正常 正 常 正常 異常
5/05 5/05 5/05 5/05 5/05 5/05 5/05
5/06
6/01 6/01 6/02 6/02 6/02 6/02 6/03
6/03

b. マトリックスによる テスト項目の 欠点- テスト項 目 数が増 える(特に 、シンタックス・チェック)。
- 複雑 な条件 の記述 が難しい( 自然言語による テスト項目記述も必要)。
テスト項目 DIZZ
-106

年齢AD001 AD002 AD003 AD004 AD005 AD006 AD007 AD008
X
X
X
X

1218
199990円
50 0円
80 0円

入場料1000円
エラー
分類
机上テスト
マシンテスト

X
X
X
X
X

X
X
X
X

X
X
X
異常 境界 正常 正常 正常 正常 正常 異常
5/05 5/05 5/05 5/05 5/05 5/05 5/05
5/0 6
6/01 6/0 1 6/02 6/0 2 6/0 2 6/0 2 6/03 6/0 3

78(3) プロジェクト・マネージャによるバグ・データ分析(2) ソフトウェア製品のライフサイクルを通じて、バグの統計データを収集- 品質向上をするための最善の戦略を決定する。
- 製 品のリリース日を予測する。

プログラマは、全てのバグを文書でプロジェクト・マネージャに報告する。
a. 報告開始時期
コーディングが終了し、コンパイル・エラーがなくなった時 点(机上デバッグに入る条件が整ったとき)

テスト項 目の数

プロジェクト・マネージャ が目 標の 曲
線を引 き、統計データをプロットす る

未実施 の テスト
項目数 ( 目標)b. 報告内容- バグを摘出したとき
ID番号、バグの 症状、バグの摘出者、摘出年月日、バグの重要度等

未実施 の テスト
項目数 ( 実際)

- バグを修正したときバグがあったモジュール名、バグの原因、修正者、テスト担当者、修正前コーディング、修正後コーディング等

摘出バグ 累計( 実際)摘出バグ 累計( 目標)
テスト項 目の追加

時間
12/30

9

1/5

1/12

1/19

1/26

2/2

2/9

10

(3) プロジェクト・マネージャによるバグ・データ分析 (続き)(3) プロジェクト・マネージャによるバグ・データ分析 (続き)

統 計データのパターンによる問題点 の分 析
残存テスト項目数

分析する内容実際

目標
実際(1) モジュールごとの 不良分析 (90%の不良は、10%のモジュールに集中する傾向にある)(2) 機能固有の 不良解析
(3) 個人ごとの不良分析 ( 個人の不良作りこみの癖を分析)

目標

残存テスト項目数

目標
実際

目標

実際

摘出バグ数
理想的なパターン

摘出バグ数

前フェーズの品質が低い

実際
目標

残存テスト項目数

残存テスト項目数
目標

実際

目標
摘出バグ数

目標
実際

テスト担当者の能力不足
11

摘出バグ数

実際

・テスト項目の品質が低い
・プログラム の品質が良い122

(4) 独立 したＱＡチームが製品をテスト(3) プロジェクト・マネージャによるバグ・データ分析 (続き)

社内に、設計部と完全に独立 したＱＡ部がある。

製品のリリース(ＱＡ部への)条件(1) 未実施のテスト項目がない。
(2) バグの摘出が頭打ちになった。
(3) バグが全件、修正されている。
(4) 48 時間耐久テストに合格した。
テスト項目の数

Q1: ＱＡ部には、何人のＱＡエンジニアがいるか？
A1: 全 エンジニアの約８％ がＱＡエンジニア(4,000人中、330人)
Q2: ＱＡエンジニアは、何をテストするか？
A2: 設計部が作成 した物全 て (仕様書、設計書、テスト項目、コード等 )未実施のテスト項目数 (目標)

未実施のテスト項目数 (実際)

Q3: ＱＡエンジニアにどんな権限があるか?
A3: ＱＡ部の「合格印」がなければ、製品は リリースできない。ＱＡ部は、合格印を押した製品 がリリースされると、その後 の品質に関 し、全責任を負う。

摘 出バ グ数 がフラットQ4: ＱＡエンジニアは、どのように テストをするのか ?
A4: 顧客 の視点 でテストを実施(従って、ブラックボックス・テストが中心)。ＱＡ部は、摘出バグ累計(目標)
未実施 の テスト
項目 なし
時間

12/30

1/5

1/12

1/19

1/26

2/2

設計部 とは全く独立に、テスト項目を設計・実施する。

2/9
1314

3. 品質のコスト (品 質は無 料ではない !)質問: 99.98% バグがない製品をなぜ開発できるのか？
他 社より優れているためか？

仮定 : 10人のプログラマがいるプロジェクトで、12ヶ月にＣ言語で100,000行のソフトウェアを開発する。
(1) 各開発フェーズに要する月数- 仕様分析・仕様決定- 設計- コーディング

答え: そうだと良いと思うが、実際の主 な要因は以下の通り。
- このＱＡ方式を30年以上も変えていない(方式に変化がない限り、毎年、良くなるのは当たり前)。
- レビューがうまく機能している。
- 退職率が低い。例えば、平均的なプロジェクト・マネー
ジャは 、勤続15年以上が普通 (アメリカは、２〜３年)。

: 2 ヶ月: 3 ヶ月: 2 ヶ月- デバッグ: 3 ヶ月- テスト (QA 技術者による) : 2 ヶ月
(2) 3 ヶ月のデバッグ ・フェーズの詳細- 100,000 行のソフトウェアに10,000 件のテスト項目が必要 (1,000件/プログラマ).
- 10,000件のテスト項目を設計するのに10日 (１日１人あたり100件)- 1,000件の机上デバッグ に10日 (１日１人あたり10件)- 10,000件のマシン・デバッグ に40日 (１日１人あたり25件)
1516

4. 本QA 方式の 異なる開発方式への 適用性

第２部：日 本のＱＡと、アメリカ、インドのＱＡ(1) ウォーターフォール・モデル
本QA 方式は、極めてうまく機能する。この理由として：- 製品開発 のライフサイクルが数ヶ月から数 年に及ぶ(長い)。
- 各開発フェーズの、開始・終了が明確。
- 各開発フェーズに順序性がある。
(2) オブジェクト指向- クラスやメソッドに本ＱＡ方式を適用(若干の 変更あり)- 本ＱＡ方式がオブジェクト指向での最良の 方式かどうかは、現在、分析中。
(3) スパイラル・モデル
開発のライフサイクルが非常に短い場合(例えば、毎週、新しい製品をリリースする)、本ＱＡ方式は適当 ではない。

17183

質問: 日本式ＱＡは、アメリカやインドでも適用可能か？

質問: なぜ、日本式 ＱＡは、アメリカやインドで適用不可能か？
答え: 以 下の理由による(日本式ＱＡの課題？)。
(1) ソフトウェア開発での優先順位の違い(2) ソフトウェア開発方式の変化(3) 国民気質 の違い

答え: もちろん、不可能

19

1. ソフトウェア開発における優先順位の違い

20

2. 日米 の販売戦略の違い (従来の日本 )「日本型」 対 「アメリカ・インド型」= 「品質」 対 「市場性」

大きさ

品質は製 品の一部。
品質 こそ全 て ！

市 場へのインパクト

製 品の品 質的 な成熟度

売れなきゃ意味がない宗 教が違う !?
アメリカ・インド型

日本型

コスト ＜品 質＜ 納期

コスト ＜納 期＜ 品質

出荷のタイミング

アメリカ ・インド 型

日本型

21

2. 日米 の販売戦略の違い (これからの 日本：その２)

2. 日米 の販売戦略の違い (これからの 日本：その１)・マーケティング戦略の変化 ：重厚長大から軽薄短小 へ (数を売るには、販売タイミングが非常に重要。例えば、ボーナス商戦に間に 合わないと売れないない等 )・顧客の強い要求 ( 例：会計年度に間に合 わせる)

大きさ

市 場へのインパクト

アメリカ・インド型

22

・リリース時期を早めつつ、品質を上げねばならない。

大きさ

市 場へのインパクト

製 品の品 質的 な成熟度製 品の品 質的 な成熟度日本型

出荷のタイミング

アメリカ・インド型

新日本型 従来の日本型

出荷のタイミング
コスト ＜品 質＝ 納期

コスト ＜品 質＜ 納期
232442. 日米 の販売戦略の違い (これからの 日本：その２)

3. ソフトウェア開発方式の変化

質問：では、なぜ、インドでＣＭＭレベル５を取得した会社が、世界 で一番多いのか？ 品質が本当に良いためか？

・コスト削減、納期短縮のため、全 て自社開発するのではなく、既に市場に存在する製品を組み込む。
→ 組み込む製品にバグがあっても、タイムリー に修正してもらえない。

答え：ＣＭＭは、「品質を向上させるプロセスがあるかどうか 」
をチェックしているだけで、品質の絶対的な尺度は考 慮しない。例えば …

→ 「バグ」
を仕様としなけらばならない 場合が多い。

リトルリーグの野球チームでも、投手のローテーションに気を配り、定期的に選手の健康管理を実施していれば、CMMレベル５を取得
・技術の特殊化、特化により、他社に、製品 の一部の 開発を依頼せざるをできる。一方、大リーグのワールド・シリーズ優勝チームでも、選 手の管理を何もしていなければ、ＣＭＭのレベルは１になる。

得ない(例えば、携帯電話用のブラウザ)。

このように 、ＣＭＭでは、チームの絶対的な投手力、打撃力 (絶対的→ 製品の総合的 な品質 は、他社発注製品の 品質次第。

な品質)と、チーム内の選手管理(プロセス改善能力) は、別物と考え→ 自社の品質保証方式を強制できない（強制 しても、やってくれない）。ている。

25

4. ソフトウェア産業での、日米印の国民性・意識の 差
日本のソフトウェア産業
1. チーム全体の成功が 最重要- 各個人から、「正直な」データを収集可。
- 統 計データを元にした品質管理を適用できる。

26

4. ソフトウェア産業での、日米印の国民性・意識の 差 (続き)アメリカ・インドのソフトウェア産業

1. チーム全体の成功より、個人の 成功が重要。
- 「バグを作りこんだ」＝「無能力」- バグの 情報は、( 無意識に)捏 造

日本のソフトウェア産業

アメリカ・
インドのソフトウェア産業

2. 品質は、コストや納 期に優先

2. 早期リリースにより、マーケットのシェアを独占することは 、品質よりされる。

優先

27

28

5. シェパードの分類による人間の行動パターン
感情的 (熱い)4. ソフトウェア産業での、日米印の国民性・意識の 差 (続き)* アメリカ ・
インドのプログラマ*
日本のソフトウェア産業
3. ソフトウェア開発では「工業化」
を重視- キーワードは、「安全サイド」- 冒険をおかさない製品企画- アメリカ等の斬新な技術の後追いPタイプ (promotional:前進型)

アメリカ・インドのソフトウェア産業
3. ソフトウェア開発では「新規性」と、「次世代の尖端技術」を重視- キーワードは、「挑戦」- 斬新な(斬新過ぎる？)製品企画- 画期的な技術を輩出-自由を求める-常に、賞賛を期待Fタイプ (facilitating: 協調型)
-寛容を求める-常に、受容を期待

支配的

謙虚

C タイプ (controlling: 制御型)
-一貫性を求める-常に、達成を期待するAタイプ (analytical: 分析型)
-正確さを求める-常に、安全性を期待する* 日本のプログラマ*

抑圧的 (クール)
29

30

5

6. シェパードのモデルにおける法則
第３部： 昔からの ＱＡの課題と解決案
Ÿ 同じタイプに属する人同士は、うまくやれる。
Ÿ 違うタイプの人同士は、うまく行かないことがある。特に、対角線のタイプ同士は反発し合うことが多い(すなわち、ＰタイプとＡタイ
プ、ＣタイプとＦタイプ) 。
Ÿ 同一人の中に、対角線の複数のタイプを併せ持っている人もいる。
- Cタイプ とFタイプ
生 まれながらのマネージャ型- Pタイプ とAタイプ
アインシュタイン型
Pタイプ

Fタイプ

Cタイプ

Aタイプ

3132

1.ＱＡに 対する誤解？

1.現状の 品質管理の課題

・ＱＡは、創造的な仕事ではない？
・ＱＡエンジニアはプログラマより能力が低い？
・ＱＡエンジニアは、プログラマの尻拭い？
・ＱＡエンジニアは、システム開発能力がない？

(1) ＱＡエンジニアの地位が低い？
・ＱＡは、創造的な仕事ではない？
・ＱＡエンジニアはプログラマより能力が低い？
・ＱＡエンジニアは、プログラマの尻拭い？
・ＱＡエンジニアは、システム開発能力がない？
(2) ＱＡエンジニアの士気が低い？

例えば、原子力発電所を設計するのは簡単だが、安全性をテストするのは、極めて困難。この困難を可能にするのがＱＡエンジニア。

(3) 設計部とＱＡ部は、同じ製品のテストをするが、テスト項目は全く独立に設計・作成し、実行するので、時間と資 源の無駄？
(4) 「早い検査」の実現

・プログラマより、はるかに高い能力が必要。
・非常に創造的な仕事。
・システムを容易に開発できる能力がないと、テストは 無理。
33

34

2.「現状 の品質管理の課題」 の解決案

3. 品質 マネージャ制度の導 入(1) ＱＡマネージャ制度の導入。

テストの効率と独立性を上げるために、「品質マネージャ 」をアサインする。

(2) 設計部とＱＡ部の資源共有・再利用。
(1) テストの進化過程
第０ステージ：プログラマが自分でテストする。
第１ステージ：設計部内にテスト・チームがある。
第２ステージ：社内に、設計部とは独立したテスト・チームがある。
第３ステージ：「品質マネージャ」が開発プロジェクトの 品質を全般的に指揮・制御。

(3) 経済産業省の国家資格として、「品質エンジニア」を 新設。

35

36

6

3. 品 質マネージャ制度の導 入 (続き)

4. 設計 とＱＡの 資源共有・再利用(2) 「品質マネージャ」の役割
・品質管理の最高責任者として、開発プロジェクトに関 与。

設計側のデバッグ と、ＱＡ側のテストで、テスト項目、テスト・プログラムやテスト担当者を共通化。これにより、以下を実現する。

・従来のＱＡエンジニアは、受身であったが、品質マネージャは品質確保に向けて、指揮権を発動し、積極的に関わ る(ＱＡ関連の技術者のモラル、および、地位を向上させる)。

(1) テスト期間の 短縮 ( 全体の20％を占めるテスト期間の短縮化 )(2) テスト項目の 設計・製造工数 の大幅削減

・プロジェクト・マネージャは製品開発の設計、工程管理、品質管理(デバッグ)を実施。品質マネージャは、プロジェクトの品質管理(テスト)の責任を持つ。

(3) テスト要員の削減

・品質マネージャは、品質に関し、プロジェクト・マネージャを指揮する(株式会社と経営コンサルタント、警察と検 察の関係？)。

資源の共有化、再利用のためには、「品質 マネージャ」の指揮が必 須

・品質マネージャは、他のプロジェクトを掛け持ちしてもよい。
37

5. 国家資格 、「品質 エンジニア」 の新設38

5. 国家資格 、「品質 エンジニア」 の新設 (続き )情報処理医術者 の上級資格として、「品質 エンジニア」を追加する
新資格、「品質エンジニア」の追加により、期待できる効果(1) テクニカル・エンジニア
・エンベデッド・システム
・システム管理・データベース・ネットワーク(2) アプリケーション・エンジニア(3) プロジェクト・マネージャ(4) システム・アナリスト(5) 品質 エンジニア
・入社10年目程度の経 験と技術力
・ＱＡ対象システムに最適 のＱＡ方式
・システム の正当性、信頼性、機密性、安全性、可用性等を検証、分析。

(1) 日本のＱＡ技術者 が、共通の用 語や概念を共有。
(2) ＱＡ技術者の 大幅な地位向上。
(3) ＱＡ技術者のプロ意識の育成・醸成。
(4) ＱＡ技術者の士気向上。
(5) ＱＡ技術者の技術力のスタンダードを設定。
(6) 会社 や組織のＱＡ能力の客観的な尺度。

39407