行ってきました!「ソフトウェアテストシンポジウム2011東海」

2011年11月11日(”1″が並ぶ日)、ソフトウェアテストシンポジウム2011東海(JaSST’11Tokai)に参加してきました。JaSSTに参加するのは今回が初めてです。
JaSSTの理念や当シンポジウムの概要については上記リンクで参照していただけるとして、今回初めて参加してみて、私なりに感じたことや学んだことを書き連ねていきたいと思います。(`・ω・´)ゞ
オープニングセッション
まずはオープニングセッションとして、実行委委員より開催のあいさつ・今回の参加者の内訳などの紹介がありました。(実は電車に乗り遅れてちょっとだけ遅刻してしまいました・・・)
興味深いのは参加者の内訳。職種としては、テストエンジニアと開発者がそれぞれ30%ほどで最も多く、PM職は11%くらいとのことでした。筆者の仕事としては「PM」に分類されるのですが、思ったよりも多いなと感じました。
次に、対象としているソフトウェアの種類で見ると組み込み系が圧倒的に多く(半分以上だったか?)、筆者が携わっているエンタープライズ系はその3分の1程でした。製造業が多いという東海地方の特性が表れていて印象的でした。
ただ、近年はエンタープライズ系の比率があがってきているとのことです。ようやくテストに関する意識が高まってきたということでしょうか・・・(;^ω^)
基調講演 『MRJの開発状況 – Flying into the future -』

jasst11t_01.png

三菱航空機(MRJ)の藤江壮氏による講演です。業務系システム屋の自分にとっては、「え、航空機?(´・ω・`)」というのが最初の率直な感想でしたが、お話を聞いているうちに「ものづくり」に関わる人間として、非常に引き込まれるものがありました。
内容は、MRJがリージョナル旅客機(ある一定の地域内での運行を想定した小型機)の市場に参入した背景や現在の状況、今後のビジョン等についてのお話です。
ソフトウェアテストに直接関わる内容ではないのですが、同じ「ものづくり」を行うものとして参考になる点が多かったので、簡単にご紹介します。
■リージョナル旅客機開発のコンセプト
今回開発したリージョナル旅客機のコンセプトとして、次の三本柱を打ち立てました。

  1. [乗客]快適な客席
  2. [環境]優れた燃費と低騒音
  3. [エアライン]優れた経済性

シンプルではありますが、乗客の満足度、環境への配慮、エアライン各社への売り込みを意識した、バランスが良く非常に分かりやすいコンセプトであるといえます。
また、このコンセプトを実現するための具体的な施策(例:先進的なエンジンを採用、材質に工夫 etc)についての説明もありました。
■差別化
他メーカーとの差別化を図る施策の1つとして、荷物の積み降ろしを素早くできるために、貨物室のスペースを広めに設計したという話が紹介されました。
リージョナル機はハブ空港を中心に1日の離発着をいかに多くこなすかが重要なので、着陸から次の出発までのリードタイム短縮を狙った戦略です。
私が従事する業界と分野は異なりますが、「顧客(この例ではエアライン)にとって何が嬉しいか」を考慮した上でのコンセプトづくりという点で、非常に参考になるトピックスでした。
■ソフトウェアにまつわる話
「ソフトウェアテスト・シンポジウム」ということで、ソフトウェアに関する裏話も紹介されました。
航空機が制御を失う三大要素としては、電気の喪失、油圧の喪失、そしてソフトウェアのミスがあげられるそうです。
普段自分が携わっている業務系システムとは比べものにならないくらい品質に関するプライオリティが高い世界であることを感じさせられました。
その反面、組み込みソフトの新規開発はほとんど無く、派生開発(既存のソフトの改修)が大部分を占めるとのことです。
■最後に
その他、機体の素材やコクピットの設計、環境面の配慮といった開発中の旅客機そのものに関する説明や、現在の開発状況についての説明がありました。
最後に、旅客機の開発にはMRJだけではなく多くのパートナー企業が関わっているのですが、その大部分がこの東海地方を拠点としているというお話を聞き、改めて東海地方は製造業がメイン産業であることを実感しました。
普段エンタープライズ系のシステム開発メインに関わっている身にとっては、非常に新鮮で有意義なお話でした。
特別講演 『製品、ソフトウェア、プロジェクトの前提と品質の関連付け』

jasst11t_02.png

静岡大学の森崎修司氏による講演です。独特のユーモアあふれる語り口で楽しませていただきました。(´∀`*)
まずは冒頭で、ひとつのサンプルが題材として紹介されました。
ソフトウェア開発の現場で、Aさんは「機能の豊富さが大事」と考えているのに対し、Bさんは「品質が最重要」と主張する、というストーリーです。


何故このような相違が生じるかというと、同じソフトウェアでもAさんは「スマートフォン」を思い描いていたのに対し、Bさんは「自動車のECU」を想定していたのが原因だった、というオチです。
この例からも分かるとおり、コミュニケーションにおいて、両者のコンテキスト(背景、前提)が異なることにより、思わぬ誤解を招いたり議論が噛み合わなかったりすることが日常でも良くみられます。
ソフトウェア開発の世界でも、例えばあるプロジェクトで「テストの自動化」を導入して成功した事例があったとして、別のプロジェクトでもそのまま同じやり方で導入したら失敗した、というケースが結構見られます。
これは、自動化が成功したプロジェクトのコンテキストを十分検証しないまま、異なるコンテキストを持つ別のプロジェクトに適用するのは極めて危険であることを示唆しています。
ではコンテキストを抽出するのにはどうしたら良いでしょうか?
本講演では「エンピリカル アプローチの三段階」という手法が紹介されました。

  • 第一段階:観察(実験や調査により現象を確認する、現象が表現できる)
  • 第二段階:法則の発見(現象が起こるコンテキストを理解する、現象を予測できるようになる)
  • 第三段階:理論の確立(因果関係を明らかにする、現象を説明できるようになる)

ソフトウェア開発のように多種多様なステークホルダーが関わるプロジェクトでは、各々のコンテキストの違いを理解しないことにより認識の相違を生み出し、それに気づかないまま思わぬトラブルを発生させることが多々見受けられます。
コンテキストを抽出することで各関係者の背景や前提を認識することの重要さについて気づかされました。
経験発表 『探索的テストの適用事例』

jasst11t_03.png

三菱電機メカトロニクスソフトウエアの都築将夫氏による講演です。ソフトウェアテスト現場の臨場感が伝わってくるお話でした。
組み込みソフトウェアの複雑化・規模の肥大化に伴い、残存バグのリスクが年々高まってきています。このような背景のもと、従来のスクリプトテストを補う目的で「探索的テスト」の事例が紹介されました。
まず探索的テストの長所として、(1)テスト仕様の記述工数が軽減 (2)少ない手数で多くのバグを検出 (3)テスト実行時のマンネリ感を解消 といった面で効果があると言われます。
逆に探索的テストの弱点は、(1)テスト実行の網羅性に欠ける (2)アドホック(場当たり的)になりがち (3)テスト仕様をどの程度記述すれば良いか迷う の3点があげられます。
本講演では、これらの短所をいかに克服するかという点において、実際にテストの現場で工夫された手法について詳細な説明がなされました。
■弱点(1)「テスト実行の網羅性に欠ける」の対策
各種ドキュメント(仕様書、マニュアル、テスト仕様)から「操作」「動作」「出力」「設定」「構成」の5つの要素を整理し、テスト実行マトリクスを作成するという手法が紹介されました。
要求仕様書をただ読むのではなく、このように5つの要素の分解して整理することで、テスト観点の抜け・漏れを防止するだけでなく、テスト設計の属人化を防ぐ効果もありそうですね。
■弱点(2)「アドホック(場当たり的)になりがち」の対策
(1)で作成したテスト実行マトリクスからテスト実行候補を選定して、テストの目的を明確にした上でテストケースナンバーを付与して管理するという方法が紹介されました。
また、過去のBTSに登録されたバグ報告から製品の弱点を特定して、テスト実行候補のあたりをつけることも有効であるとのことです。
確かに製品の弱点があらかじめ明確になっていれば、テストの目的もはっきりしますよね。
■弱点(3)「テスト仕様をどの程度記述すれば良いか迷う」の対策
ここでもテスト実行マトリクスを使います。整理した5つの要素をそれぞれ1つのテストケースとして記述することで、記述のバラつきが抑えられるという効果があります。
いわゆる5W2Hではないけれど、押さえておくべき要素を明確にしておけば文章のバラつきも解消されるような気がします。
「探索的テスト」というと、経験豊富なテストエンジニアが勘を働かせて既存のテスト仕様の弱点や漏れを発見する、という場面をイメージしていましたが、本講演で紹介された内容は「スクリプトテストの対極としての探索的テスト」という文脈が見て取れました。
5つの要素で整理することで、「勘」に頼るのではなく、ある程度パターン化された手法でテスト仕様の漏れを発見できるというのは、テスト設計をする上で参考になる方法だと感じました。
いずれにしても、1度作成したテスト仕様であっても継続的に見直して改善していくサイクルを回すことが重要であり、それが探索的テストの本質なのではないかと思います。
スポンサーセッション、ポスターセッション
3つの講演の後、このシンポジウムのスポンサー企業によるセッションが行われました。
食事休憩を挟んだ後は、ポスターセッション(ホワイトボードなどに資料を張り出して説明を行う形式のセッション)です。
実は、当日は雨にも関わらず昼休みに外に出てしまい、食事ができる所を探して彷徨ったためポスターセッションを聞くために会場に戻ったときには既にびしょ濡れでした。・゚・(つД`)・゚・
肝心のポスターセッションですが、そんな状態だったので服を乾かすのに気を取られて、ちゃんと見て回ることができませんでした。。。
SIG 『ソフトウエアテストと人間の感情について』
「SIG」とは「Special Interest Groups」の略で、いくつかのセッションの中から自分が興味あるものを1つだけ選ぶことになっています。
私は「ソフトウエアテストと人間の感情について」を選択しました。このセッションは事前の募集では最も希望者が多く、何人か自主的に他のセッションに移っていただいたことで、ようやく定員内に収まりました。(移っていただいた方には本当に申し訳ないです・・・)
このセッションは、ソフトウェアテストの手法ではなく「人間的側面(特に感情の部分)」に着目した点が特徴的です。
私がこのセッションを選択した理由も、開発・テストの現場における「感情に起因する問題」に興味があったからです。
セッションは10人程の参加者が誕生日順にテーブルを囲んだ後、まずは講師である酒井卓也氏(産業カウンセラー)による「交流分析」の説明です。
交流分析の特徴として「自我状態」「対話分析」「ジョハリの窓」が紹介されました。
詳細は割愛しますが、自分の感情の中にある P(親)、A(オトナ)、C(子供)の3つの状態を見極めることで、他人とのコミュニケーションを円滑に進められる、といった内容でした。
また「ジョハリの窓」の説明において、他人がものを言い易い雰囲気を作ることや、自己をオープンにすることが推奨されています。私自身も「話しかけづらいときがある」と良く言われるので、心がけたいものです。。。
■事例検討
「ソフトウェア・テスターによる報告メール」を題材に、報告の仕方の問題点や、このテスターの心理状態、どう対応すれば改善できるか、といったことについて、2グループに分かれてディスカッションしました。
他の人の意見を聞くことで、自分一人ではなかなか得られない「気づき」を得ることができました。
情報交換会
ひととおりのセッションが終わった後クロージングセッションが行われ、情報交換会(懇親会)に突入しました。
セッションの講師の方や多くのテストエンジニア・開発者の方々とお話することができて、非常に楽しい有意義な時間を過ごすことができました。
最後に感じたのは、JaSST実行委員会の方々の物凄いエネルギーと運営力。これだけ多くの人を動員して楽しませることができるのは本当に凄いことで、刺激になりました。あと料理が美味しかったです(笑)
(終)