JaSST 2014 Tokyoに行ってきました - 部屋とネルシャツと私

3/7(金)と8(土)の両日、去年初で今回2回目の参加。ソフトウェア開発をテスト中心に掘り下げるとっても濃い2日間でした。

このソフトウェアテストシンポジウム（以下、JaSST）は、昨今のIT業界におけるテストへの注目を象徴するように巨大化・進化を続けているようで、昨年の目黒雅叙園では所狭しと、今年は東洋大学に会場を移動。

※井上円了ホールが満席なら700人参加オーバーか!?

f:id:uhe_uhe_uhe:20140308202508p:plain

ああ、こんなタイミングで戻ってくるとは＼(◎o◎)／

ASAKA Backが懐かしすｗ

しかし、白山校舎がキレイになりすぎ！複雑すぎ！あと、円了ホール寒すぎ...(+_+)

主催ASTERのこともロクに知らない自分ですが、予想以上に（ごめんなさい）心に響くコトや貴重な出会いが沢山あったので、これはblogに書かざるを得ないな、と。

～～～～～～～～～～～～～～～～～

■当記事のアジェンダ

（１）まとめ

（２）プログラム内容メモ

（３）補足・・・関連リンク集とか

～～～～～～～～～～～～～～～～～

（１）まとめ

得られたことは本当に多かった。特に印象的なのは・・・

『インテグレートする能力は、作ってないと失われる』（八谷氏）

SIerにいるからか、インテグレーションという言葉には敏感にならざるを得ない。良く言う技術力の空洞化も踏まえた上で、作る能力（技術力）がないと良い感じなインテグレーションはできないのは事実。この自分自身が漠然と不安に思っていることを、IT業界の中ではなく、飛行具をつくったりしているメディアアーティストの八谷氏から聞けたから余計に印象に残った。

『"技術"を売るようにして、"作業（≒労働力）"を売ることから脱却しなきゃ』（西先生）

これはシステムやソフトウェアの価値ってなんぞやって話に繋がる。結局のところ、SI業界全体に人月単価競争やトラブったら人海戦術、など技術ではなく人（の労働力）で提供するシステムやソフトウェアの価格が決まっている現状。このブレイクスルーには技術を売れるような、技術を持ったエンジニアが超重要と認識。その通り過ぎて言葉が無い。

ということで、テストと一口に言っても、プロセス系、テストテク系、ツール系、現場実践系等々と幅広く、出たいセッションが重なりまくりで選ぶのが正直辛かった。がそれだけ、ネタ盛り沢山だったことでしょう。集まる方々もテストベンダー、サービス開発系、SIer、大学教授を含めた専門家などなど、懇親会も人が多すぎで、話せた人がちょっとだったのが唯一の残念。

ソフトウェアのテスト・品質保証というとプロセス系に目が行きがちで、自分自身もそれに近い業務も行っている。しかしながら「エンジニア育成」という大きな課題は、テストの枠を超えて自分自身もどうしたらよいか日々模索しているところ。そんな中大きなヒントを沢山拾えた。

（２）プログラム内容メモ

※以下、長くなります・・・

　セッション概要・タイムテーブルはこちら

------3/7(金)------

H1「テストエンジニアのモチベーション」Stuart Reid 氏（英国コンピュータ協会）

Asiaのテストエンジニアも欧州を中心とした世界のテストエンジニアも、モチベーションについては同じ傾向があるが、個別に見ると違いある、という話を独自アンケートの統計分析をベースに
ハーズバーグの動機付け・衛生理論の観点
ダニエルピンクのモチベーション3.0の観点
ハックマンとオルダムのMPS(Motivating Potential Score)の観点
プログラマにとって同僚からのFeedbackがマイナス要因になるというのは、コミュニケーション次第では現実的によくある話
管理者層とテストエンジニアで求めるものが異なるGAPにより、Feedbackがマイナス要因になるのも「確かに」と

D2-1「テスト設計のタイミングと手法の変更による品質向上と生産性向上」松浦豪一氏（富士通マーケティング）

口座情報エントリー画面とかモロ経験ありなので、めっちゃ我が身になって考えられた
（今回の例では）プログラム内部の設計と同時にテスト設計して、より最適な設計ができるというメリット
設計時に、組み合わせ数（テストケース数）を意識して、無駄な作り込みを防ぐ話（テストケース漏れの心配はシステムテストでカバ―する考え方）

D2-2「システムテストの自動化による大規模分散検索プラットフォームの開発工程改善」荻野恒太郎氏（楽天）

テスト自動化の実例として、とっても参考になった
楽天の中で、検索プラットフォームに特化したテストケース用言語を開発し、テストケースのメンテナンスコスト減
楽天では、プロジェクト内にテスト自動化部隊（SET）と、組織横断的なテストコンサル部隊の両方があるらしい
ちょうど今読んでいる「グーグルのソフトウェア開発」を参考にしているような部分が随所に見られた
実装TDDの後、自動テストが通るかどうかのスモークテスト（必要最低限の結合を保証するテストという位置づけ）をカマせてから、自動化したシステムテストを実施するというサイクル
かつ、自動化することで開発と並行してシステムテストも実施し、スピードアップ（バグ修正日数が半減とか）
STだけでなくUTのバグ修正日数も減っている！
スピード感と品質リスク管理（テストに工数を費やせば費やすほどスピード感が犠牲になる）のバランスが見事に取れた取り組み事例に感じた
システムテストは自動だけでなく手動もやっていそうだが、詳しく聞けなかったのが残念

F3「Selenium WebDriver で学ぶシステムテスト自動化の第一歩」伊藤望氏（TRIDENT）

JUnit＋Selenium WebDriverのハンズオン系チュートリアル
ついにブラウザベースの自動テストを実行することに成功！恥ずかしながら超感動！！
最後の課題で宿題に残った分はあとちょっとで出来そう
入力画面＋確認画面だけでなく、他の画面も使った画面遷移のテストとか、いろいろ応用できそう（あとでチャレンジしてみよ）
出来の悪い生徒でしたが、沢山のサポート、本当にありがとうございました＾＾；

F4「自らが変化の起点になる！プロセス改善手法SaPID入門」安達賢二氏（HBA Quasol）

テストというよりは、プロセス改善のお話で個人的には超興味あり
もっともっと質問したかったが、懇親会で安達さんを見つけることが出来ずorz
トップダウンなモデルベースプロセス改善（ISO、CMMI、ITILなど）では上手くいかず、かといって、ボトムアップな個別改善（現場QC活動的な）では限界があり上手くいかない。そこでSaPID（さぴっど：初めて知った）の話
SaPIDは、改善に関わる人に注目して「自分の問題としてプロセス改善」を実施するように巻き込んでいくのが特徴
とてもボトムアップイメージ
しかしながら、具体的な成果を短期間で上げるために最初のとっかかりはトップダウンで進めて上手く行ったという事例（700人規模の組織で初年度にプロセス改善に7割以上の人が関わっていた！！！自分の知っている世界ではそんなにうまくイカナイっす・・・）
SaPIDの、問題を構造化する手法やふりかえりでのKPTは、そんなにびっくりするようなやり方ではないから（←表面的な理解だけでゴメンナサイ）、余計に興味が湧いた
チョコのアイスブレイクないす♪（場の空気を作れるファシリテーション技術）