『ソフトウェアテスト・ミーティング 2009』（9月17日@秋葉原UDX by ITmediaさん）に行ってきました
既にオルタナブログにてお伝えしました通り、
2009/09/01 ITmediaさん主催『ソフトウェアテスト・ミーティング 2009』（9月17日@秋葉原）にエントリーしました
に行ってきました。
秋葉原の再開発以降、一度も行っていなかったので、UDXさえも初ということで。
（最初の創業は、秋葉原エリア＝岩本町だったのですが、最近はめっきり行かなくなりました。）
--
ひとまずですが、プログラムと、twitterでのログをセットでお伝えします。
（「・・・」のあとは私的コメントになっています。）
■プログラム
13:30～13:35 開会挨拶
アイティメディア株式会社
- ITmediaさんのセミナー。・・・ありがたいことに、エビアン付き＆喫煙所あり。 (･_･)y-~~~
13:35～14:35 基調講演
『“めげない、めげさせない”チームマネジメント～“情工哀史”にならないために～』
講演者：デバッグ工学研究所 松尾谷 徹 氏
- 基調講演『めげない、めげさせないチームマネジメント』by松尾谷徹（デバッグ工学研究所）が、スタート。
- しまった、乱視でスクリーンの文字がぼやけてる。
- テスト技法 仕様ベース→リスクベース→構成ベースへ（？）
- 『クリエイティブクラスの世紀』にITエンジニアが含まれるが、日本では新3K業界と言われている。・・・確かに。
- 何故に日本は？＝職場の問題？
- 従業員満足度→パートナー満足度へ
- 社・プロジェクトには1社の社員だけではない。社員以外のメンバーにも満足を。・・・確かに。
- モチベーションドライバー＝自己実現・スキルアップ、自分への評価、リーダーの資質人柄、コミュニケーション、プロジェクト運営体制、業務上のストレス、業務外のストレス
「いきなり仕事」ではなくスタッフィング＆チーム作りを。 チームを作りワークする＝チームワーク。
14:35～15:25 『ソース解析ツールの活用による品質確保と全体品質の管理・統制方法』
講演者：株式会社富士通ソフトウェアテクノロジーズ
Webソリューション基盤サービス事業部第一Webソリューション基盤サービス部
須永 浩史 氏 （ → 村瀬氏 に変更）
- 富士通ソフトウェアテクノロジーズ社の講演スタート。
出荷した製品の２／３に問題。その８割がソフトウェアのバグ。
実装段階＝ソースコードの問題、レビュー不足。 コーティング規約の実態は？
現在化されていない、各プロジェクトに最適化されていないコーティング規約＝× - 適用除外するルール選択と、選択理由の名文化。
- 効果＝品質向上・工数削減 を測り、提示する→達成感へ
※メインの講演内容について、資料が配布されず。後日ダウンロード可能とのこと
15:25～15:40 休憩
- ２コマ目終了＆休憩。 ・・・もちろん(･_･)y-~~~
15:40～16:30 『ツールを活用した高い品質および開発生産性の実現』
講演者：マイクロソフト株式会社
デベロッパー＆プラットフォーム統括本部
開発ツール製品部
エグゼクティブ プロダクト マネージャ
近藤 和彦 氏
- さて、マイクロソフトさんの講演スタート
- 『ツールを活用した高い品質および開発生産性の実現』by開発ツール製品部エグゼクティブプロダクトマネージャ 近藤和彦氏
- Team Foundation Serverによるソースコード管理の段階的導入
- 1.ソースコード管理の効率を上げる
2.自動化の機能を活用し効率的に品質を高める
3.プロジェクト管理と連動し状況の可視化と全体の効率化を図る - システム開発初期段階からの継続的インテグレーション
- そして、「テスト駆動開発の流れ」へ。
- 次は「テスト自動化の意義」
- 回帰テスト、保守でのテストに有効。更に、テストコードの納品を求められる。
16:30～17:30 座談会
『テストツールを活用して“やる気”を引き出すアプローチ』
プロデュース：JaSST'10 Tokyo実行委員会
モデレータ：株式会社豆蔵 大西健児氏
パネラー：
・株式会社ACCESS 松木晋祐氏
・北都システム株式会社 長谷川聡氏
・日本ノーベル株式会社 東大輔氏
- 最後4コマ目は『テストツールを活用してやる気を引き出すアプローチ』by JaSST（モデレータは豆蔵・大西さん）
- 下ごしらえ編 ～ツール導入前にすること～
- ツールに何を任せ、メンバーにどのような意識付けをするか（マネージャやリーダーの視点）
- 現場担当は、ツール導入の負担がある。自分しか使えない状況は避けたい。
- 選定で、オープンソースやフリーのツールでよいのか？
- とりあえず入れる。修得する。 ・・・ふむ。
- 成果目標まで定めた選定。（商用・フリーに関わらず）
- 経営層に説明することが求められる。 ・・・確かに。
- 属人化しないためのツール導入。
- ツール依存してはいけない。
- TestLink vs Excel 的な。
- 現状を変えたくない現場。
- ASQツール導入は？ ・・・キターーーッ
- テストコードを書けなきゃダメ ・・・いやっ、それは違う。
- 設計・分析能力が必要
- 『調理／料理編～ツールの構築方法～』
- まず、テストのリハーサルをやる。
- 準備期間は？
- 高機能の商用ツール、マニュアルわたされ、1～2ヶ月。
- 無償ツールのほうが、もっと掛かるかも。サポートもトレーニングも無いし ・・・ナイスコメント！！
- 最後の最後『おいしくいただくために～用意したツールをどう使うのか』、、、・・・バッテリー切れ
--
さて、本イベントの会場は、超満員で、皆さんのソフトウェアテストに対する興味や課題があるのだろうと、再確認できました。
最初の基調講演では、松尾谷氏によるITエンジニアのおける環境にフォーカスされていたかと思います。
特に、モチベーションドライバーについては、担当者の上長への期待と現実・実際とのギャップから生まれる問題について、わかりやすく解説頂きました。
派遣などでAMに面接して午後からスグに現場 というようなケースについても触れられていましたが、実際にあるような話ですし、そのエンジニアが準備して仕事をスタートできるかというと、なかなかスイッチも入らない状況でしょう。
スタッフィングして、チームを形成して、そこからワークに取り掛かる
数パーセントの時間をチーム形成に費やしたほうが、後々のトラブルに比べれば、実質コストが低いのでは？という点についても、納得させられました。
座談会は、豆蔵・大西さんのトークが切れていて、面白かったです。
豆蔵さんは、当社とセミナー共催していただくなど、お世話になっていますが、やはりこのようなイベントでの大西さんは、豆蔵のエバンジェリストとしての存在感を感じます。
ツカミが、「私は、最近10kg太った某タレントではありません。」「ひらがなで、私の名前を検索してみてください。」 ・・・ オオニシケンジ ＝ ハルナアイ ですから、切れ具合がわかるかと思います。
さておき、JaSSTの実行委員会のパネラーの皆さんが、それぞれ、自社としての立場ではなく、実行委員会としての参加であり、但し、社でのロールや経験をベースに、ツール普及する立場、テストチームのリーダー、テストの現場という視点でのトークバトルは、見る側としても分かりやすく、良いセッションでした。
そして、ASQツールの話になったところで、高機能な商用ツールで、マニュアルをボンと渡されて、習得に2ヶ月も掛るとか、フリーのツールだと、トレーニングやサポートが無いから、もっと時間が掛るといったところ。
------------------------------------------------------------------
まさに、当社のVerisium（ベリシウム）製品が狙う逆のゾーンだなぁと。
Verisiumの場合は、
- 習得に数日～2週間
＝ 俗人化しない、スグに使える - しっかりとしたサポートの提供
＝ 人的なサポート、チュートリアルなどケースの充実、製品以外の周辺ツール提供 - 廉価
＝ 類似する商品の１／３～１／２０
というテーマで展開しており、今までテスト自動化ツールを導入しなかった方々も、高機能なツールを使ってきた方からも、喜んで使用して頂いています。と、プチ宣伝になりますが。
------------------------------------------------------------------
フリーのツールは、開発チームの優秀な方が、俗人的スキルを持って使いこなすことは当然ながらあるかと思いますが、俗人性を排除して、開発を得意としない品質部門の方や、それこそ新人クラスでも使えるツールとなれば、いかに、広範に使われるツールとなるかということだと思います。
習得が大変だったツールの使いこなしノウハウを継承したり、社内・チーム内に広めることはかなりの時間と手間とコストがかかるので、フリーだから良いわけでは無いと。
但し、ツールの効果はどうだろうか？とテスト的に実施するには、予算化するまえでも可能という点で、まずは、フリーのツールでトライしていくことは大事だろうと思います。
そして、ツールありきではなく、何が問題で、何を解決するべきかからツール選定をしていくという話がありました。
高級高機能なツールは、あれもできる、これもできるですが、できる＝使うわけではなく、本来の目的＝品質や効率の向上を見失い、「テスト自動化」に傾倒することが良いわけではないということですね。
機能を絞り込んだツールであっても、その目的にどれだけ適合しているか、という点に着目すると良いかもしれません。
--