NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'12 Tokyo

セッションA1）基調講演
「How We Test At Microsoft：マイクロソフトでどのようにテストをしているのか？」
Bj Rollison氏 (Microsoft)

Microsoft社プリンシパルテストリードを務めるロリソン氏が、同社がどのようにソフトウェアテストを行っているのかについて講演を行った。
歯切れのよい語り口に加え、終始にこやかでときどきユーモアを交えながらのプレゼンに、ロリソン氏の人柄を感じながら肩のチカラを入れずに話を聴くことができた。

講演ではテストを軸に多くの側面に対する話題が出ていたが、主なポイントは以下のとおりである。

• 多種、多様な製品群が存在→年間1，500万のバグ
  これに振り回されるとビジネスにならなくなる。
  変化が激しい市場に価値を提供し続ける＝ビジネスとして成立させるには、問題に素早く対応するだけではなく、予防することが必要。

●対応のポイント1：ビジネス価値、市場価値を高めるために

• お客様の利用シナリオを重視。フィーチャ設計もバグ対応優先度付与もそれをベースに行う。
• トリアージ：対処優先順位づけの判断基準は「どのバグが顧客に影響を与えるのか」である。
• ドッグフーディング：責任者自ら製品を使用し、お客様の視点で確認。
• テスト担当の採用基準＝求める資質は、ビジネスに価値を提供すること＋変化に素早く対応できること。
• 優秀なテストエンジニアの流出防止は重要事項。
  管理者とは別のキャリアパス：新ポスト－テストアーキテクトを用意した。

●対応のポイント2：予防的な対応、素早い対応を行うために

• テスト担当を含めた開発に係わるメンバー全員が、開発プロセス全体にかかわる。→社全体で、開発担当者数：テスト担当者数＝1：1
• 組織階層を最小限に＝フラットにすることで密接なコミュニケーションを促進し、判断を迅速化。
• 多くの製品領域で必要なツール化、自動化を進めている。テスト関連ツールはテストのことを最も把握しているテスト担当者が自ら構築する。
• チャーン指標などの効果的な管理指標を目的ベースで、ツールと連携して活用する。
• バグ管理システム：製品ごとに開発環境や開発方法、使用ツールは異なるが、バグ管理システムは全社共通。バグ情報の入力は義務化されている。
  その情報をすべての開発段階に活用。
• ツール活用、自動化、情報共有により作業が効率化し、かつ開発メンバー全員がテスト結果を含めた全体状況を簡潔に把握でき、必要な対応を行える。

講演内容からは、同社がお客様に価値を提供し続ける＝"ビジネス"を継続するために必要な対応を組織全体で一貫して取り続けていること、そしてそのために開発の当初から最後までテストとテストエンジニアが重要な役割を果たしていることが伝わってきた。
そしてこの組織運営が最初から確立していたわけではなく、ビジネスを進めながら関係者間の密接なコミュニケーションと行動により徐々に、段階的に変えてきた結果であり、今後も変化に素早く適応していく、ということがマイクロソフトの強さの源泉になっていると感じた。

セッションA2）テスト開発方法論
「テストアーキテクチャ解説～テストアーキテクチャ設計を実践するには～」
智美塾塾長＋塾生一同

昨年の"テスト開発方法論セッション"の続編である。
受講者には「テストアーキテクチャ設計の提案β版」が配付され、まずは鈴木氏による「テスト要求分析」、次に秋山氏による「テストアーキテクチャ設計」、そして西氏による「アーキテクチャの粒度、テストバスケット間の関係性、設計順序」等を含むより詳細な解説があり、吉澤氏による「アーキテクチャ設計の考慮事項」を経て、湯本氏自身による「ゆもつよメソッドによる具体的事例」が解説された。

解説では、アーキテクチャ設計はメリットばかりではなくデメリットも存在すること、今回説明した事例が唯一の答えでなく別の実現方法が存在することに注意、などこれからテストアーキテクチャ設計に取り組もうとする方達がつまずかないための情報が網羅的に提示されていたように感じた。

セッション終了後に受講者数名にヒアリングしてみたが「昨年よりも用語やテスト実践事例との関連づけが分かりやすくなった」「かなり理解が進んだが、自分のテストに照らすとまだピンとこないところがある」などのコメントが寄せられた。現場での実践にはまだ継続したアプローチが必要であろう。

今回配付された資料は、今後の議論・検討結果を反映して書籍化、もしくは冊子化される可能性があると思われる。書籍発刊を含めた今後の活動展開によりテストアーキテクチャ設計の実践がより促進されることを期待したい。

セッションD4）「Ｗモデルとは何か」
秋山 浩一（富士ゼロックス）・鈴木 三紀夫（ASTER）・吉澤 智美（日本電気）
モデレータ：西 康晴（電気通信大学）

要求・設計・コードの品質向上とともに、手戻りを減らし、全体生産性をあげるための開発プロセスモデルの一つ：Ｗモデルの解説と受講者との質疑応答が主な内容であった。
個別セッションとして最も多い300名を超える受講者が集まり、会場は熱気に包まれた。

鈴木氏によるＷモデル解説、演習、導入事例に基づくアプローチ、そして鈴木氏に加え、秋山氏、吉澤氏、西氏による質疑応答は、それぞれの経験・実績・研究に裏打ちされた内容であり、成功に必要な要因だけでなく、製品分野ごとの注意事項、よくある誤認識や形式的対応・部分対応などによる弊害等、Ｗモデル導入時のポイントの理解が進んだ。
筆者が受け取ったＷモデルのポイントは以下の通りである。

• Ｗモデルに期待する事項は、納期短縮、バグ・手戻り削減、全体生産性向上など、人、組織によって異なる。
• Ｗモデルでの実践内容に対する認識は、テストアクティビティの前倒し、設計レビュー時のテスト担当者参画、など、さまざま（まちまち）である。
• Ｗモデルでは、テスト設計に習熟したテスト技術者が開発の上流フェーズにも深く関与することが前提となる。テストは簡単＝新人にやらせればよいという考え方や、単なる"テストの前倒し"、形式的な対応では効果は出ない。
• Ｗモデルは、エンプラ、パッケージ、組込みなど分野を問わず有効であるが画一的なアプローチは存在しない。
  既存の利害関係者の考え方や行動パターン、開発ポリシー、製品の特性を含めた現在状況と目指す成果などにより、どこから手を付けるのか、どのような段階を経て進めるのかが異なる。自組織に合うプロセス改善アプローチを採用することが重要。

以上であるが、Ｗモデルとその導入に関してリアルで詳細な情報を獲得できる非常に貴重な機会であった。
今後はこれらの情報を参考にして、受講者の中からＷモデルによる効果獲得の事例が出て来ることを期待したい。

セッションA5）テスト設計コンテスト
「テスト設計コンテスト」
委員長：湯本 剛 (日本HP)　審査委員：テスト設計コンテスト担当チーム

前回のJaSST'11東京で初めて実施されたテスト設計コンテストであるが、今回は全国各地で選出・推薦された5チームと前回の覇者が出場し、題材である「話題沸騰ポット要求仕様書」に対するテスト設計結果の充実度や設計過程の創意工夫を競い合った。
1チーム8分間プレゼン＋2分間質疑応答で発表したが、それぞれのチームが自らの持ち味を存分に出していたのではないかと感じた。
一方、ほとんどの発表内容がテスティングプロセスの説明が主体となっていて、"テスト設計"についての説明が不足していたとの指摘もあった。

コンテストの結果はクロージング時に発表されたが、その際のコメントにもあるように、1年間でテスト設計レベルが相当上がっていて、僅差で受賞チームが決定するほど実力が拮抗している内容であった。
賞を受賞した、しないにかかわらず、各チームの良さ、特徴を共有し、今後もテスト設計のノウハウを高めていってほしいと思う。

なお、チームのテスト設計成果物はシンポジウム期間中、会場の通路に貼り出され、休憩時間などに受講者が自由に参照し、フィードバックコメントを収集できるようになっていたことを付記しておく。

セッションA7）招待講演
「ソフトウェア・テストの30年前と30年後」
山浦 恒央 (東海大学）

30年前からこれまでを振り返りつつ、今後30年にソフトウェアテストがどのようになるのか、どのように考えて対応していくことが必要かを予測し、そのための基本的な対応方法を提言する講演であった。
ソフトウェアはこれまでに人間の生活や社会に深く浸透し、大規模化、複雑化、複合化が加速。その結果、テストが必要な規模もますます増加している。ところがソフトウェアを開発する人間の生産性、規模当たりの欠陥作り込み数、また管理技術、テスト技法なども基本的に変わっていないことから、今後も画期的な開発技術・品質制御技術は期待できないと前提条件を設定。
この状況を打開するため30年後には、「品質のレベル分け」「応用分野別の品質情報データベースの確立」「リスク管理をベースにした品質制御プロセスの確立」「品質のカプセル化」が一般的になると提言した。

「品質のレベル分け」は、食品などで実現されている成分表示の様にソフトウェアそのものに"品質レベル表示"を行うというもの。テストの網羅レベルなどソフトウェア品質に対してお金を払う時代をイメージすることができた。
また「品質のカプセル化」は"いかにテストをしないか"のために必要な手段で、できるだけ新たにソフトウェアを作らない＝テストをやらずに済ますことができる。その実現のため、データ、処理方式に加え、"品質"もカプセル化することで、このソフトウェアとテストの大規模化に対応していくことができるとした。

個人的には、"これまでにないテスト技術"がどのようなものなのかを期待していたが、ソフトウェア開発全体の方向性としてはその視点も必要になることを改めて認識することができた。

セッションA8）クロージングパネル
「ソフトウェアテストの近未来を大いに語り合おうぞ」
パネリスト：Bj Rollison（Microsoft)　山浦 恒央 （東海大学）　西 康晴 （電気通信大学)
モデレータ：大西 建児 （ガイオ・テクノロジー)

クロージングパネルはモデレータ：大西氏が進行し、それぞれのポジション確認のあと、提示されるテーマにパネリストが回答し、テストの近未来を大いに語り合った。今回取り上げられたテーマは以下のとおりである。

• テーマ1：テストプロセスはどう洗練していくか
• テーマ2：テストの技術はどのように進化していくのか
• テーマ3：これから10年で進化していくのか

その結果、これからは以下のような考え方と対応＝パラダイムシフト／考え方の進化が必要であるとの見解が出された。

• 今後も大規模化が進んでいくためテストだけで解決するのはムリ。
  バグを作り込まない、テストをしなくても済む方法を考えるべき。
• いろいろな規格や基準が発行・検討されているが、まずは自組織が現状でどのようなテストプロセスなのかを明確化・理解して、それを洗練させていくことが必要。誰かが規格や基準を発行してしまう前に自らやってしまおう！
• 各国の価値観や得手不得手を理解したうえで、国際的な連携、協調対応が必要になる。場合によっては国際的な分業をやっていけばよいのではないか。
• 開発者・テスト担当・顧客など関係者全員がすべての過程で連携・協調・情報共有することが必要。
• テストそのものが「ものづくり」になる。
• 開発とテストの融合（例：Ｗモデル）が必要。
• 人間の感覚と感情、価値観も"品質"として取り扱う。

以上の結論として、国や立場、役割、既成概念を超えて連携・協調・情報共有しながら１０年後の未来を自分達で創っていこう！と締めくくられた。
自らなりたい姿＝欲しい成果に必要な対応を取っていく、その姿勢と行動が未来を創ることにつながると信じて対応していきたいと感じた。