この記事は，日本中のテストエンジニアが集う冬のイベント，JaSST’15 Tokyo（ソフトウェアテストシンポジウム 2015 東京）のレポートです。マイケル・ボルトン氏の基調講演を中心に報告します。13回めとなるJaSST Tokyoは2月20，21日に東洋大学白山キャンパスで開催されました。
私はJaSSTには2004年から不定期にスピーカーとして参加していますが，今年は聴講者として参加しました。私が参加したJaSSTの中でも一，二を争う楽しいイベントとなりました。
満員となった基調講演会場
ASTERと学びの機会
JaSSTはASTER（ソフトウェアテスト技術振興協会）が主催しています。ASTERはテストに関わる人々の地位の向上，学習の機会の提供を目的にさまざまな活動をしています。ASTERの主な活動は，JSTQBの運営，各地方での教育の支援，シンポジウムの開催，テスト開発方法論などの先端技術の研究開発，IEEEシンポジウムの誘致などなどです。
開会あいさつを兼ねてASTERとJSTQBの“真の目的”（？）について語るASTER理事長の電気通信大学 西康晴氏
国際的なテストの知識体系と認定資格にISTQBがあります。この日本版がJSTQBです。JSTQBの運営の大きな目的は，ISTQBのシラバスを日本語に訳し無料で配布すること。そしてこれを使って，テストエンジニアが（職場で，あるいは個人で）勉強できるようにすること，次に認定資格を取ることによってテストエンジニアのキャリアアップの助けになることです。
資格取得よりも資料を提供するのが目的というのは素敵ですね。JSTQBは私の周りの人たちも受験／取得しており馴染みがありました。しかし，ASTERにこのような意図があったことは知りませんでした。JSTQBシラバスを使ってみなさんも学習を始めてはいかがでしょうか。なお，日本ではアドバンスドレベルの合格率が低いそうです。これは問題が難しく設定されているため，とのことでした。
基調講演 ─“How To Get What You Want From Testing”
JaSST Tokyoの基調講演は毎年外国人スピーカーを招待しています。ソフトウェアテスト界隈にはいろいろな派閥（スタイル？）がありますが，その中から毎年バランスが取れるようにスピーカーを選んでいます。毎年参加されている常連の方には，開催のたび「色」が違うことに気づくかもしれません。今年はマイケル・ボルトンさん。とても熱い基調講演でした。
マイケル・ボルトン（Michael Bolton）氏
「How To Get What You Want From Testing (for Testers, Developers, and Managers) あなたの欲しいものはどうやってテストから手に入れるか? ～テストエンジニア，開発者，マネージャのために～」この長いタイトルがマイケル・ボルトンさんの基調講演です。
講演は「私はシンガーではありません」という，おそらく定番の導入からはじまりました。テストエンジニア，開発者，マネージャのために，テストについてなにを知っておくべきか，彼の提唱したRapid Software Testingなどからのアイデアを説明しました。本レポートでは，たくさんのアイデアの中から，主だったいくつかを報告したいと思います。
定番のつかみネタ？
マイケル・ボルトン氏
20年以上に渡り世界中でソフトウェアに関するテスト，開発，マネジメント，および執筆活動を行なってきた世界的なテストエンジニアでコンサルタント，そしてトレーナーです。
彼は，不確かで極めて時間が不足しているプロジェクトにおいて，うまくソフトウェアをテストするための方法論と考え方を得られる教育コースである「Rapid Software Testing」をJames Bach氏とともに開発しました。現在は，トロントを拠点にコンサルティングを行うDevelopSenseを率いています。
それ以前は，8年間Quarterdeck社で，世界中を飛び回って同社の主力製品を管理し，社内の，そして世界のプロジェクトチームとテストチームを指揮していました。
（予稿集からの引用）
おかしなソフトウェアとFeeling
彼の見つけた「おかしなソフトウェア」が紹介されました。
aircanada.comのサイトに表示されるエラーメッセージ
aircanada.comの例（This flight inclues a stop in null.）はいわゆるバグかもしれません。nullが含まれていると表示されていますがこれをユーザに見せてどうするのでしょう。
Hywatt Regency HotelのWiFi申し込みページ
またHywatt Regencyの例ではWiFi利用料金が1日ずつより2日間の方が割高になっています。仕様通りかもしれませんが，利用者は混乱します。ほかにもたくさんの「おかしなソフトウェア」を見せてもらいました。
これらのおかしなソフトウェアにもテストが行われていたはずです。テスターはどうしてこれでいいと思ったのでしょうか。マネージャはどうでしょう。これでいいと思ったのはなぜでしょう。これらのソフトウェアには共通点があります。ソフトウェアは秩序立てて作られたのに，大切なものが欠けているのです。
「あれ？この製品，どこかが悪い気がする…」テスターは直感で気づくことができます。このソフトウェアは退屈だな，不親切だな，どこか使いにくいな…そういったフィーリングが大切です。それはなにか悪いものがあることを示しています。
これはソフトウェア製品に対してだけでなく，プロセスなど，あちこちで使えます。ボルトンさんは聴衆に問います。
「テストが退屈と感じるときがある人は？」
退屈と感じる… それはなにか悪いことが起きているのです。たとえばテストを重要じゃないと思っている，そう感じるなにかがある，といった具合です。
フィーリングは，製品のみならず，自分たちの開発そのもの（もちろんテストも含みます）のやり方についても，問題のシグナルとなるのです。
ダッシュボードの問題
メトリクスに固執してしまう問題があります。ダッシュボードの計器ばかり見て外を見ないような状況です。自動車を運転している時，窓が見えないのと，ダッシュボードが見えないのならどっちがましでしょう。数字は重要ですが，数字で表せることばかりではありません。窓の外を見て運転しましょう。
計器ばかりを見ていると…
窓から外を見なくなり，結果…
残念ですが，数えやすいものに魅力に感じ，惹かれてしまうことはありませんか。たとえば，テストケース数や合格数の多さに固執してしまうなど。しかし、数字はいくらでもごまかせてしまいますし，実態を反映しないこともあります。
なぜテスターはテストケース数ばかり気にしてしまうのでしょうか。マネージャーが尋ねるからでしょうか？マネージャはなぜ尋ねるのでしょう？テスターが答えるから？聞きやすいから，答えやすいから，そうなってしまうのでしょう。ここには無限ループがあるようです。たしかに，いろいろなメトリクスが形骸化するのはこういった状況，心理からくるのかもしれません。
こういう場面にも「おかしいな」と感じたいですね。