外国のカンファレンスで話をしたときのこと

これは、2010年10月21日にmixiに書いた日記の転載です。韓国のテストカンファレンスで英語で講演をした時のことを書いてます。（写真は私がしゃべっているところです）

先週の土曜日の午前中に若い人と話をしてたときに2:6:2の話をして、この日記に書いたスチュワートの講演を思い出して、この話をしたかったのですが、いろいろ忘れてて面白さを瞬時に伝えられないと判断し、勝手に自分の心の中で微笑んでたのですが、気になったので改めて読み返しました。今の若いテストに関わる人が読んでも面白いと思うし、共有した方が良いと思うので、転載します。

真面目なこのカンファレンスのレポートはASTERのサイトにも載ってます。こっちの日記はもっと軽いタッチで書いてるのですが、私の心の中のコメントってことで、そういう感覚で読んでください。

日記　【テスト】韓国一日目

今日（2010年10月19日）から韓国のソウルに来ています。

ツイッターでも○○さんから、yumoると書かれたように、飛行機の時間を間違えていて（12時5分発だったのを12時55分だと思っていた。武蔵浦和*1 について電車に乗る前にEチケットを見て気付いた..）、当初の予定では、埼京線の始発に乗って、座りながら大崎まで各駅でゆられて行き、京急で行こうと思っていたのを、その直前の劇込みの通勤快速にのって、京急ではなく、モノレールに乗るために赤羽で超満員の京浜東北線に乗り換えて行くと言った策を講じて、なんとか飛行機に間に合うという出だしから波乱の旅行となりました。

*0 補足　当時は武蔵浦和に住んでました。

韓国で泊っているホテルは2007年にISTQBのGAで行った時と同じホテルなのですが、ソウルの地理がさっぱり理解できていない上に、韓国語がさっぱり読めないために、タクシーでホテルへ行きました。（けど案外安く、3000円程度。）

明日のカンファレンスの主催者であるWonilが7時くらいから夕飯でもどうだとメールが来ていて、「いいよ」と答えておいたら、6時前にホテルに来てくれて、2人でwonilの好きなサウロンタンというのを食べにいき、その後、車でなんか観光地的な場所を案内してもらい、韓国のold teaが飲める喫茶店へ行き、お土産屋を連れて回ってもらい（Wonnilは今回の外人連中へのお土産を買っていた）、最後はホテルのそばのセブンイレブンでマッコリを買って、店の前で飲みながら話をしてお別れしてきました。

当初は21時くらいには戻りたいんだよねーと話していたのに、戻ったら23時半と... まぁ、翌日英語でスピーチしなきゃいけない人を何だと思ってるのかがわかりませんが、楽しく過ごしました。韓国語で家族の名前の書き方を教えてもらったり、リスクベーステストのチュートリアルを日本でやりたいんだけど、そのためにはどうすればよいか？というWonnilの想いを元に議論したりといった感じで、最後にはWonilの将来の夢まで語っていただき、明日に備えてたくさん英語を話したのでよい事前レッスンになったかなと。

リスクベーステストに関しては、それはそれで良いんだけど、そのリスクアイテムとテストケースまでをちゃんと繋げて、ちゃんとチューニングしたり、フィードバックするためのテスト分析、テスト設計がちゃんとできるかどうかが本当の問題であることを力説しておきました。

ということで明日のための練習して寝ます。

日記　【テスト】韓国二日目

昨日（2010年10月20日）は、韓国のソフトウェアテストカンファレンスの日でした。

私は朝から今日話す英語のカンペを2回全部通して読んでから会場にいきました。 会場はホテルからタクシーで10分程度のところ。けど、スチュワート、ヤーロン、エリック、ジェフ、BJは会場から1時間半もかかるところだったらしいです。クラウスは私の泊ったibisから1キロ程度先のホテルらしかったです。

まず、最初はBJの講演。
  ■How We Test At Microsoft　BJロリソン

この講演は10時までの予定になっていて、私は9時50分くらいに会場に着いたのですが、まだスライドにして3枚目のところで、絶好調に話していました。

彼のセッションは、マイクロソフトのテストはどういうものか、という話だったのですが、テストアーキテクトとはどういう仕事かという話と自動化の話が印象的でした。 

テストアーキテクトとは、新しい技術に対してどうテストをするべきかを作っていく人だとのこと。実際にプロジェクトをマネジメントする仕事はしないとのことでした。 

後、自動化ですが、全てのプロセスを上手く回すために自動化が必須でやらないという選択肢があり得ないとのこと。 テストで大事なことは計測とフィードバックで、全てがバグの予防につながるようにしなければならないと。彼の書いてあるスライド通りにテストができれば最高です。

質問では、何種類のメトリクスをとるのが妥当なのか？という質問がありましたが、「わかりません」と。「それはあなた次第。何をしたいかで決めなさい」とのことでした。

まぁ、ここですでに30分以上の遅れ。 次は、
■TMMi – how are we doing as an industry?　ジェフトンプソン

基本的にTMMiはどういうものかということの説明。
ポイントは２つ。
・これは商業ベースのモデルでないため、みんなが使えるよ、ということと、
・アセスメントをするとほぼすべての会社はレベル1か2だという話。ジェフは、このときにBJへ「マイクロソフトもアセスメントさせてよ。レベル5だよ。」と話しかけて笑いを取ろうとしていましたが、今一歩。

で、いろいろな数字で、実情を説明していましたが、バグ分析の話で、バグの分類をしている会社は80%近くいるがちゃんとフィードバックしているのは25%しかないという話がいちばん「だよね」と思いました。

で、いよいよ。
■A practical approach for test Analysis and Design　私 
私は事前に、同時通訳の人に今日話す原稿を渡しておいて、「これを翻訳してください」とお願いしておきました。
その後、エリックが「がんばって。オレも英語で話すのにナーバスになっているけどね」とさらにオレを緊張させてくれました。その後ジェフトンプソンが来て、「大丈夫、おれだって英語の通じない聴衆に話すから通じているか不安になったよ」とさらに追い打ちをかけてくれて、発表時間になりました。

基本的に原稿を読むという作戦に出ましたが、最初の韓国語でのあいさつは結構受けました。
まぁ、何とか無事にプレゼンは済んだのですが、韓国語のツイッター（ハッシュタグ付きでつだっている人たちがいたので）を読むと、「アメリカ英語、イギリス英語、日本語英語と楽しんでいます」とか「日本人の人原稿を読んでるよ」とかつだられていました。

内容は、
　なぜゆもつよメソッドが必要か？→それってどんなものか→リスクと繋げるならどうやるの？

という流れで進めました。結構みんな集中した感じで聞いてくれてました。質問時間は時間が推しているためカットされましたが、その後多くの人が質問しに来たので、よかったのかと思います。

■ATP- The Factors behind Success　ヤーロン

ヤーロンのプレゼンは「受け入れテストのプロシージャ」です。
テストを請け負っている人たちへのアドバイスです。受け入れテストがなんで必要かをISTQBの定義を基に説明し、ロバストな手順が大事だよと ISTQBのプロセスを基に、自分の経験談をハイライトとして話すって感じでしたが、まぁ正直がっかり感は否めません。韓国語のつだりを翻訳して読んでたら、「正直世界のレベルもこんなもんだと先が思いやられる」といったものがありました。

テストドキュメントのサンプルを会場で見せてましたが、テスト対象がimodeで、おまけにテスト仕様書も典型的な日本のものと同じでした。大中小項目の表で、これをヤーロンは、「ユモトが言ったようにカテゴライズが大事だ、こんな感じで」と説明していました。。（ちょっと違うんじゃね？と言いたかったけど。。）

またクラウスが隣に座っていたのですが、「これって何か特別なものはあると思う？」と筆談で聞いてきて、「全然ない」と私が答えたらニコッと笑っていました。

■Agile testing – pushing quality upstream…working with dev on unit/component level tests, etc 　BJロリソン

お昼はBJの隣だったので、「あなたの本を読もうと思いました」とあいさつをしたら、日本語でありがとうと言ってきてびっくり。なんでも1994 年までの13年間日本に住んでいたそうです。今は年に1回くらいしか日本語を話す機会がないため、かなり忘れたって言ってましたが、ちょっと話してみてって他の人に言われて、私に話しかけたのはかなりちゃんとした日本語でした。九州と沖縄に住んでいたっていってましたが、なんか沖縄の文化がかなり好きなようで、その話をみんなに聞かせていました。

で、BJのプレゼンですが、Agile testingってタイトルの割に、最初の一言が私は良くアジャイルがわかりません。から始まり、昔のやり方と今のやり方という比較することが分からないといい、 アジャイルの本を何冊か読んで、発見したことは、自分のやってきたやり方と多くの共通点があるということで、それを話します。という感じで本題に入りました。

で、ヘイゼルの「test, then code!!」は1987年の言葉だよねとか、バイザーの「The act of designing tests is one of the best bug preventers known 」は1983年の言葉だよねとかいって、自分はどんなことをMSでやっているかという話をしていきました。

「データドリブン単体テスト」「BDD/ATDD」「キーワードオートメーション」「デフェクトプリベンション」「シナリオテンプレート」「リアルタイムカバレッジアナリシス」など。

で、最後にアジャイルテスターに必要だと思われることとして以下を上げていました。
「開発とテストの協調」
「ライフサイクル全体でテスト」
「欠陥を見つけることではなく、予防することを考える」
「分析する」
「継続的に改善する」
「どんどん自動化」

当たり前な感じですが良い話でした。

■How to correlate the TestPlan and the Test Management Tool エリック

続いてエリック。エリックはお昼もほとんど残していました。きっと私以上に緊張していたと思うのですが、カンペを見ず堂々としゃべっていました。やられた。*1

内容はテストマネジメントとツールは切っても切れない関係で使うべき、で、どう使うかという話で、一見当たり前の話なのですが、本当に実践している人なので（彼はオレンジというフランステレコムの携帯事業会社でQualityCentre *2 の推進をずっとやっており、オレンジでは1000ユーザのQualityCentreを持っているようです。）話に重みがありました。

*1補足：エリックはフランス人です
*2補足：テスト管理ツールです

特に重要なのは教育で、ベンダーの教育はもちろんだけど、社内の教育コンテンツも必要で、正しく使い方を学んでもらわないといけないという話でした。

ヤーロンの質問（リアルタイムでつだりましたが）、QCは高すぎるからもっとフリーツールでできないのか？と的外れな質問がありました（自分はエクセルでやっているんじゃんって突っ込みが心の中で入りましたがwww)

■TMMi and experience with the earlier version TMM and benefits to be obtain by working with test process improvement. クラウス

クラウスは日本での話*3 とほとんど一緒。（だと彼が言っていた）

96%の欠陥除去率を達成ってものすごそうに聞こえますが、実は、リリース後90日間までに出たバグとテストの時のバグをを母数にして割り算しているだけでした。90日間なら、そりゃまぁ、、当然じゃないの？って思いました。 あとはテストテクニックが足りないのが大きな問題なんだよという話。

*3 補足　この時、１週間前にJSTQB主催の国際カンファレンスを日本で行い、クラウスはそこでもTMMiの話をしました  

■Testing Professionals of the Future.     スチュワート

最後がスチュワートです。まぁ、正直、とってもおもしろかったです。内容というより話のストーリー展開と小粋なギャグがです。ほんと、内容をそのまま日本語に訳して講演してもかなり笑いを取れるでしょう。

ということで私もこれは結構メモりました。（全部つだりたかったんだけど、Twitterがつながらない時間が多くてあまりつだれませんでした）

まずは20対20の法則をあてはめるという話。世の中は20%のエキスパートと20%のどうしようもない奴と、60%の普通の人たちで構成されている。そういうnaive viewでテスターをあてはめてみてみようとというのを正規分布のグラフで説明。

まずはダメなほうの20%、「結局おれたちは彼らと働かなきゃいけないし、マネジメントしてあげなきゃいけないんだぜ」と。

まず、話のフリとして、プロジェクト内っていうのは人の努力と、人材の能力のバランスで成功が決まるんだよと言ってました。（この話を天秤を使って説明して、笑えるのですがここで説明が困難）

で、ダメなテスターが多いとどんなことが起きるかというと、
・開発者→ハッピー、バグが出ないからコードが良いと勘違いするので。
・テスター→アドホックなのであまりバグが見つからない。
・マネジャー→リリース前にバグが出ないので手戻りが減り、ハッピー。
おまけにテストの原則も言い訳に使えるね、といって
「欠陥を見つけることができるだけ」「全数テストはできない」なんていい例だと皮肉たっぷりに。

で、ダメなテスターが多いプロジェクトを天秤の例で説明すると、「テスターの能力のだめっぷりはプロジェクト内の人の努力じゃカバーしきれないね」と言ってました。

長い目で見たときに、保守担当も、顧客も、サポートマネージャもみんなが迷惑すると。

で、エキスパートのほうの20%に移ります。

で、たとえばきみがエキスパートだとして、きみはチームに必要とされているか？と問いかけます。（まぁ皮肉たっぷりに）

ユーロスターの調査じゃテストがプロの仕事だと思うって言うのが全体の47%しかいないんだぜと、また皮肉ります。

最後に、中間層に関してです。ここで「do you want a warm body or tester?」というスライドからスタート。

で、「世の中のテスター、開発者の75%は関係する学位を持っていない」という教育的な背景があるよと言います。で、この数値はホストバーのダンサーらの25%が学位を所持しているという事実と一緒なんだよ、と。（ここで大爆笑）

で、いままでテストに関連する本を何冊読んだことがある？という質問とともにユーロスターの調査結果を見せて、18%が読んだことがない、36%が3冊以下、37%が3冊～10冊だよと皮肉ります。更に「アメリカはもっとひどいぜ」と。
#この人 、嫌われるわけだ。こんなことばっかり言ってんだから。

で、大事なことはその中間層の60%の人たちを上げる。要は正規分布のメジアンの位置をより高いほうに持っていくことだと、真面目な話に変わっていきます。

必要なスキルスペースは４つ。
・IT全般のスキル...よく「テクノロジーを知らないほうがユーザに近い視点でテストできる」とか言う人がいるけど、それでいいのか？と。
・ドメインスキル..(ここは何を話しているのか意味がわかりませんでした。）
・テクニック..オレはテクニックが好き「だった」のに、今のテスターはテクニックの名前さえ２，３個しか言えない。。と悲しい顔のマークをスライドに移して「もっと大事なことがある」とつぎに。
・ソフトスキル...これはようはコミュニケーション能力の話です。彼曰く、そういうことを聞くとたいていの人は「馬鹿なことは聞くな！当然そういうスキルは持ち合わせている」って言うんだけどね、と。だけど、実際、医療事故が発生したときなんて、コミュニケーション能力が低い医者ほど訴訟をかけられるものだ。 実際、技術よりも患者の気持ちをつかめるかで決まるんだよ。という例でコミュニケーションの大切さを伝えてました。

実際のプロジェクトなんて工数の90% はドキュメントを書くことに費やすもんだって、コンテキストドリブン推進派のケムカーナーでさえ言っているんだぜ。とも言っていました。

ということを言い放って話は終わりでまとめのスライドは話せず、ありがとうもなく、壇上から降りて行きました。

感想
ということでカンファレンスレポートでした。その後は、懇親会でロッテワールドのあるビルまで言って韓国料理を食べました。その時にWonilの会社の新しいツール「レーダー」を見せてもらいました。（というより、見ろ見ろとうるさいので。）

TPMSのリスク分析モジュールを取りだしたツールですが、やっぱり根本的にわかっていないので、リスクアイテムをもとにテスト戦略を立てるところにちょっとずつ違和感を感じる仕様が入っています。たとえば要求や要件とリスクアイテムがどうつながるか、とか、テスト戦略はテストレベルありきであるとか、戦略の時点でテストレベルごとにテスト技法を入れなきゃいけないとか、リスクアイテムは戦略立案時にプライオリティでカテゴライズされてしまい、プライオリティエリアごとにテストタイプと技法をあてはめるとか。

今回はいろいろお世話になったので、一生懸命おかしいと思うところを説明してきました。開発のリーダになっている女性もちゃんと聞いてくれてました。Wonnilはその場にはいなくて、あとで「どうだった？」と聞いてきたので、「メンバーに説明しておいたよ」と伝えました。

その後は、川辺まで20～30分歩いて2次会。で、最後はそのリーダの女性が私とクラウスをホテルまで送ってくれて、帰ってきたら12時過ぎ。長い一日が終わりました。

いろいろいい経験をさせてもらいました。韓国のみんなに感謝です。

ということで、日本へ帰る準備しまーす。