JaSST’06 Osaka

第１部： ソフトウェア開発とピラミッド建築

テストほど知的で、創造的な仕事はない！

2006年５月12日
東海大学情報理工学部ソフトウェア開発工学科
山浦 恒央

1

１. ピラミッドの建築

2

・最悪のチームは、いきなり、巨石を押し始める。

・２０人で、100日以内に10km離れた現場まで、ピラミッドの巨石を運搬したい。
・毎日、100ｍ動かしてもよいし、数日で一挙に運んでもよい。

・賢いチームは、前準備に時間をかける。

3・さらに賢いチームは、貴重な時間を前準備にかけ、効率よく運搬する。

4・銀の弾丸(ツールや方法論)に依存しすぎると、プロジェクトは崩壊する。

561

1. 日本型 vs アメリカ型の製品出荷戦略
1.1 従来の日本型

第２部： ソフトウェア開発を取り巻く背景

大きさ

市場へのインパクト

大製品の品質的な成熟度

小早い

出荷のタイミング

遅い

アメリカ・インド型

日本型

早期出荷でシェアを確保するため、 未成熟製品出荷による手戻り作業
品質が未成熟のまま出荷やコストを削減するため、品質の成熟を待って出荷
コスト＜納期＜品質

コスト＜品質＜納期
78

1. 背景その１： 日本型 vs アメリカ型の製品出荷戦略

1. 日本型 vs アメリカ型の製品出荷戦略
ソフトウェア開発で優先順位が違う。

1.2 これからの日本「日本型」 対 「アメリカ・インド型」 = 「品質」 対 「市場性」

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

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

大きさ

売れなきゃ意味がない

大

市場へのインパクト

製品の品質的な成熟度

宗教が違う !?
小早い

遅い

アメリカ・インド型

出荷のタイミング

コスト＜品質＜納期

アメリカ・インド型

日本型

日本型

9

1. 背景その１： 日本型 vs アメリカ型の製品出荷戦略

２．背景その２： ソフトウェア開発方式の変化

1.2 これからの日本・コスト削減、納期短縮のため、全て自社開発するのではなく、既に市場に・リリース時期を早めつつ、品質を上げねばならない。

大きさ

大

10

市場へのインパクト

存在する製品を組み込む。
→ 組み込む製品にバグがあっても、タイムリーに修正してもらえない。

製品の品質的な成熟度→ 「バグ」を仕様としなけらばならない場合が多い。

・技術の特殊化、特化により、他社に、製品の一部の開発を依頼せざるを得ない(例えば、携帯電話用のブラウザ)。
→ 製品の総合的な品質は、他社発注製品の品質次第。

小早い

アメリカ・インド型

遅い

新日本型 従来の日本型

出荷のタイミング→ 自社の品質保証方式を強制できない（強制しても、やってくれない）。

コスト＜品質＝納期
11122

３．背景その３：. ソフトウェア開発関係式
ソフトウェア開発での工数、開発期間、機能総量、生産性、品質の関係式

第３部： テスト・プロセスの進化

無限に開発要員やテスト技術者を増やしても、短縮できる期間には限りがある。

工数
大

最短開発時間

最長開発時間不可能領域
非現実的領域現実的開発時間

小短い

長い

開発期間

1314

２. 従来の品質保証の進化過程 (その１)

１. 従来のテスト・プロセスの進化過程

第１世代：プログラマが自分でテストする。
・「自分のプログラムは正しく動くはず」症候群

第１世代：プログラマが自分でテストする。

・単なるデバッグの延長

第２世代：設計部内にテスト・チームがある。
第３世代：社内に、設計部とは独立したテスト・チームがある。

●デバッグとテストの違い
デバッグ：ソフトウェアが正しいことを証明すること。
・テスト項目を全件実行させ、検出したバグを修正し、修正を確認する。

テスト：ソフトウェアが正しくないことを証明すること。
・テスト項目を１件実行させ、致命的なバグがあった場合は、「品質未成熟」とみなし、以降のテストを打ち切ってよい。
15

16

２. 従来の品質保証の進化過程 (その2)２. 従来の品質保証の進化過程 (その3)第２世代：開発チーム内にテスト・チームがある。

第3世代：開発チームとは独立したテスト・チームがある。

「自分のプログラムは正しく動くはず」症候群は、ある程度、除去できるが、…

現在の、テスト・プロセスの最先端。
プロジェクト・マネージャ

・テスト担当者(もとは、開発者)にテストの技術や能力がない。
・開発チームの意見に影響され、やはり、「プログラムは正しく動く」と思い込む。
・品質に問題があっても、開発チームの意見や、顧客の要請に押し切られる。

①テスト依頼②テスト③出荷・開発者だけでなく、テスト担当者に、「テストは、ソフトウェアを開発する上での必要悪」との考えが広がる。 → テスト担当者の士気の低下

③出荷拒否

ＱＡ技術者

開発技術者
要求仕様 概要
定義
設計

詳細 コー
デバッグ デバッグ テスト
設計 ディング 項目設計
項目
設計

テスト

第３世代の品質保証プロセス
17183

２. 従来の品質保証の進化過程 (その３)
２. 従来の品質保証の進化過程 (その３)第３世代のテスト・プロセスの欠点

第３世代のテスト・プロセスの利点

・テスト部門が、開発部門とは独立にテスト項目を設計し、実施するため、開発側が同じテスト項目を作り、テストを実施していても、有効利用できない。

・開発チームとの「親密な関係」がなくなり、「性悪説」にもとづいて、テストを・テスト部門は、開発側が実施するデバッグと類似の作業をすることになるた
め、人と時間が重複することになる。

実施できる。
・テスト専門の高度な技術集団なので、効率よくテストを実施できる。

・開発とテストを組織上、明確に分離するため、「他人のソフトウェアのテスト」というテスト部門の行為は、開発側の「プログラム作成」に比べると、新規性に欠け、創造的でないとのメンタリティが、テスト担当者と設計者の両方に醸成されている。

・品質が不十分であるのに、出荷時期が迫った場合でも、開発チームや顧客と対等の立場で(あるいは、それ以上の立場で)、議論できる。

・テスト部門が蓄積してきた対象プログラムに固有のテストのノウハウ、技法、着眼点を開発側と共有することが難しい。
・開発部門に、品質管理をテスト部門に依存する傾向が出る。
19

20

1.現状の品質管理の課題
第３部： テスト・プロセスの課題と解決案(1) ＱＡエンジニアの地位が低い？
・ＱＡは、創造的な仕事ではない？
・ＱＡエンジニアはプログラマより能力が低い？
・ＱＡエンジニアは、プログラマの尻拭い？
・ＱＡエンジニアは、システム開発能力がない？
(2) ＱＡエンジニアの士気が低い？
(3) 設計部とＱＡ部は、同じ製品のテストをするが、テスト項目は全く独立に設計・作成し、実行するので、時間と資源の無駄？
(4) 「早い検査」の実現

21

２.テスト・エニジニアに対する不当な誤解

22

２.ＱＡに対する誤解・テストは、創造的な仕事ではない？
・テスト・エンジニアはプログラマより、技術力、能力が低い？
・テスト・エンジニアは、プログラマの尻拭い？
・テスト・エンジニアは、システム開発能力がない？

・例えば、原子力発電所を設計するのは簡単だが、安全性をテストするのは、極めて困難。この困難を可能にするのが、高度な技術力を持ったテスト・エンジニア。
・例えば、期末テストで、テストを受ける生徒が開発エンジニアであり、テスト問題を作る先生は、テスト・エンジニア。
・例えば、予備校の先生が、①生徒の長所、短所を見つけ、②弱い科目、苦手な項目を指摘し、③時系列的に弱点が是正される状況をモニタリングし、④志望校に合格させるというプロセスは、まさに、テスト・プロセスそのもの。

大きな誤解！

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

品質は技術者の良心であり、プライド2324

4４. 品質開発マネージャの導入によるテスト・プロセスの改善(1) 第４世代のテスト・プロセス

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

・第３世代のテスト・プロセスを改善し、品質保証の効率と独立性を上げるために、「品質開発マネージャ」を導入する。
・「品質開発マネージャ」を中心としたテスト・プロセスを確立する。
・品質開発マネージャが、開発プロジェクトの品質を全般的に指揮・制御する。

(1) 品質開発マネージャ制度の導入 (第４世代のテスト・プロセス)(2) 経済産業省の国家資格として、「品質エンジニア」を新設。

品質開発マネージャ

プロジェクト・マネージャ

ＱＡ技術者

開発技術者
要求仕様
定義

25

概要
設計

詳細 コーディング テスト
設計
項目設
計

テスト

第４世代のテスト・プロセス

26

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

４.品質開発マネージャによるテスト・プロセスの改善(続き)

情報処理技術者の上級資格として、「品質エンジニア」を追加する。

(2) 「品質開発マネージャ」が担当するテスト・プロセス(1) テクニカル・エンジニア
・エンベデッド・システム
・システム管理・データベース
・ネットワーク(2) アプリケーション・エンジニア(3) プロジェクト・マネージャ(4) システム・アナリスト

・品質管理の最高責任者として、開発プロジェクトに関与する。
・プロジェクト・マネージャは製品開発の設計、工程管理、品質管理(デバッグ)を実施。品質開発マネージャは、プロジェクトの品質管理(テスト)の責任を持つ。
・品質開発マネージャは、品質に関し、プロジェクト・マネージャを指揮する(会社と経営コンサルタントの関係)。
・従来のテスト・エンジニアは、受身であったが、品質開発マネージャは品質確保に向けて、指揮権を発動し、積極的に関わる(ＱＡ関連の技術者の品質保証技術、モラル、地位を向上させる)。

(5) 品質エンジニア
・入社10年目程度の経験と技術力があること。
・ＱＡ対象システムに最適のＱＡ方式を導入できること。
・システムの正当性、信頼性、機密性、安全性、可用性等を検証、分析する。

27

5. 国家資格、「品質エンジニア」の新設 (続き)28

5. 国家資格、「品質エンジニア」の新設 (続き)新資格、「品質エンジニア」の追加により、期待できる効果
現状(1) テスト技術者交流会がISTQB (International Software TestQualification Board)に加盟。

(1) 日本のＱＡ技術者が、共通の用語や概念を共有 (現在、開発技術の進歩は業界全体で進み、テスト技術は、組織内で進んでいる)。
(2) テスト技術者の大幅な地位向上。
(3) テスト技術者のプロ意識の育成・醸成。
(4) テスト技術者の士気向上。
(5) テスト技術者の技術力のスタンダードを設定。
(6) 会社や組織のテスト能力、技術の客観的な尺度。

(2) 2006年１月に、プロトタイプとしての試験を実施 (試験問題作成はテスト技術者交流会、実施は、日科技連)。
(3) 将来、経済産業省の情報処理技術者試験に統合するのであれば、その方向で検討。

2930

5

まとめ
●品質は、エンジニアの良心であり、プライドである。
「品質の番人」がテスト・エンジニア。
●開発技術者よりも優れた技術力と経験がなければ、テスト・エンジニアにはなれない。
●テストは、高度に創造的で、魅力に溢れた仕事。

31

6