※テスコンが何なのか、テスコンの背景などは全く書いてないただの感想ブログです
テスコンの詳細はこちらをご参照ください→テスト設計コンテスト
■テスト設計コンテスト（現地参加）に行ってきた
いやー行って良かったです。
行く前は場違い感とかテスコンに挫折した気持ちとか色々考えていた時期が私にもありましたが
現地で得られた熱意と熱意と熱意にあふれた情報が私には良かった（語彙がない）
情報って言い方をすると無機質になっちゃって私が感じたことをマイナス5％くらいでしか表せないので具体的なところを羅列してみます。
■何が良かったかを羅列する
①成果物を見られること
②リアルプレゼン
③会場の熱気
④成果物を見て熱心に語る人々（①と③の合わせ技）
順に書きます。
①成果物を見られること
えるしっているか テスコンはプレゼン以外の成果物がたくさんある
成果物というのは、テスト要求分析に使ったアーキテクチャの図や要求を導き出した資料、実際のテスト実装まで終わらせた成果物などです。
プレゼンに掲載されているのはほんの一部なので、これの実物を見る事ができるのは貴重でした。
特に今回のU30のように同じテストベースについて複数チームがテスト設計していると、
「大体この過程は通る」というところと「ここは各チームで取捨選択した腕のみせどころ」というところが見えるようになります。
これを見比べることができたのが良かったです。
また、お仕事としても他社の方のお仕事の直接の成果物を見る機会など殆どないので
「こ、、これが、、テスト設計、、！！」みたいな感慨があってもう10時間くらい成果物みてても良かったです。
②リアルプレゼン
プレゼンの技術（発表から質疑応答まで）を見られたのがよかったです。
オンラインの発表とは違い、反応が見えるので緊張するんじゃないかな、、発表者の方すごかったです。
資料の説明はもちろんなんですが聴衆を世界観に引き込んでくぞ！みたいなところが「うまいな～」と思いました。
③会場の活気
発表者の方、実行委員の方も勿論なのですが、
会場にかなりの人数の方がいらしていたのと、あとはうまくいえないのですが熱気を感じました。
休日にテスト設計の仕方について見に来る、というモチベーション？興味？なんだろう。目に見えない何かが熱気を生み出している感を覚えました。
一言で「みんなテスト設計見るの楽しー！」と思ってる確信度合いが高いみたいな・・
④成果物を見て熱心に語る人々
①や③とも被ってますが
「実際の成果物がある」＋「実際に作った人がいる」＋「興味がある人がいる」→話尽きない！みたいな感じでした。
そうだよね、どうやってこう作るかとか聞けるのとか、それについてワイワイ話せるのとか、楽しいですよね・・
プレゼンでは聞けない細かい内容を聞けたりとか、それを聞いてるだけでも楽しかったです。
■各チームの発表について感想とか
今回のテスコン決勝戦はU30（30歳以下のチーム）とOpen（年齢制限なし）の同時開催でした。
U30は4チーム。
Openは当初2チームの予定だったものの、ゆりかもめトラブル？の影響かわからないのですが、1チームのみの発表になってしまいました（超残念）
順に記載します。
◇U30クラス
①尚文クラブさん
企業・法人チームの方でした。
チーム名は課長さんの名前が由来だそうでユニークだと思いました。
方針は、アジリティ重視開発のためのテスト活動工数縮小、そのためにリスクベースドテストを選択しておられました。
アーキテクチャの根拠も優先度（とそれに基づく実行順）。
プレゼンにおいて、資料の見やすさが良かったです（どういう理由で何を選択し、どういう流れかが分かりやすい）
一方、分かりやすいがために、弱点も分かりやすかったように思えます。
例えば、画面×機能で全体像を洗い出した後にリスク分析しているため、画面と機能の掛け合わせ以外のリスクが考えにくくなる（かも）など。。
それでも「分かりやすさ」＝「伝わりやすさ」なので、結構好きでした。
②雪海桃山さん
今回唯一の個人チーム参加の方でした。
このチームの方は、上流（テストを詳細化する前の分析）をとても丁寧に行っている印象でした。
プレゼンの資料には分析の一部しか載っていないのですが実際はもっと作っていて「分析丁寧だなぁ、、」という感想（語彙なくてすみません）でした。
テスト対象の分析においてプレゼンで3つに分けていた通り、多角的に見ることの多角的とは何か？を言語化できていたんですよね。ここがすごい。
コンテナはシステムテスト。アーキテクチャの根拠は重要度。
ここの重要度の考え方が連携などの複雑でバグりやすい方からなのが面白かったです。
（逆に条件機能とか単純なところの出来が悪かったらつらみがあるかも）
テスコンというかテスト作成において重要な「根拠」に常に立ち戻られている姿勢が尊敬でした・・
③IKKAさん
企業・法人チームの方でした。尚文クラブさんと同じ会社の方です。
方針は「ピンポイント性（テストレベルのうちシステムテストに焦点を当てる）」「保守性の向上」でした。
このチームで面白かったのは最初の仕様分析でテストケースを作るところをとっかかりに使っていたところです。
観点出しで思考を発散させるとき「きれいに作ろう」「何か正解のとっかかりないか・・」などで躊躇してしまうことがあると思います。私はあります。
一番思考を出しやすい手段に、テストプロセスにおいては究極にボトムな成果物のテストケースを選んだことが発想の柔軟さがあってむしろ自分も真似したろ！って思いました。
あと全体的に反省を発表でおっしゃっていたことが多かったものの、ユーザーの使い方、機能、テストで重点的に何で割ればわかりやすいかを考えるコンテナなど、、
作成方針は全然ずれてないよな、と思って聞いていました。テクニカルな部分は、、あとからでもいける！
保守性の面について、機能の変更があったときに作成された成果物のどこを変更すればいいだけだから保守性が高い！を見られるといいかも、と思いました。
とはいえ、最初の発想、チャレンジする姿勢など全部、よかったです。
④きつつき 1.0さん
企業・法人チームの方でした。
プレゼン資料とプレゼンがすごすぎました。ライブかと・・
また、プロジェクト要求の詳細化からきつつきメソッドへの段階的詳細化
とにかくトレーサビリティが分かりやすかったです。
また、その方針も、スクリプトテスト＋バグ重点確認＋ユーザーの使い方と、オーソドックスな感じで完成度めちゃくちゃ高かったです。
このチームの特徴はバグ分析のイメージのしやすさのため実際に動かせるアプリを作成していたことだと思います。
アプリの作成って使い勝手の確認などで作成するイメージだったので、バグ分析で使うのは「おお・・・」と思いました。
質疑でもアプリについての質問が多かった印象です。
アプリの作成して得たかったことがバグ分析の観点ならば、究極的には「アプリを作るコスト＜アプリを作ったことによって出せたバグ観点で防げたユーザー不利益のコスト」だと思います。
もし既存のBTSなどでバグ情報の蓄積などがあったり、今まで類似のアプリを触ったことがある人がいれば、バグ観点出しについてはアプリを作る以外でもいける気もしました。
私がUPPER40なのでそう発想してしまうのかもしれません。
U30のチュートリアルでいっていた「見えるようにすることで発想が広がる」を実践されていたのだと思います。
とにかくこのチームは資料、プレゼンといい全体的な完成度が高く、とても見ごたえがありました。
◇OPENクラス
①AVATESさん
企業・法人チームの方でした。
今回OPENクラスで決勝に参加された唯一のチームです。
成果物全体から、テストを構築する「技術力」があるなあと感じました。
多面的に見る力、テストに技術を適用する力は群をぬいており、お仕事を依頼したいというときにこの提案書なら技術について申し分ない…と思いました。
一方で、要求→どうテストするかの掘り下げ方がすごすぎて、元の要求へのつながりが遠い日々になるな、みたいなところは少しあったかもしれません。
多面的に見て実装することと、トレーサビリティを確保するようなシンプルな見せ方をすることの難しさを感じました。
成果物自体はかなりボリュームが多く、OPENはこのくらいの成果物にはなるのだなあ・・としみじみしました。
発表を見ていてテスト会社たるもの、このくらいできなければだめだ、、と襟を正さなければ～という気持ちになりました。技術は力なり。
■まとめ
今回は企業チームが多く、お仕事を依頼されるレベルってこういうことだなあというのを、U30・Openの優勝チームには感じました。
入賞しなかったチームも含め、アーキテクチャの意味を考えることを皆実践していて、プレゼンや質疑も堂々としていて素晴らしかったです。
私は以前にテスコンに挑戦したときに、アーキテクチャの構築で「俯瞰」と「共通」程度しか考えられなかったので、
今回聴講することでアーキテクチャに目的を持たせるということを沢山見せてもらえて本当に良かったです。
また、成果物をじっくり見る事で、最初のとっかかり（どうやって全体を分析するか）と、詳細設計についてはある程度共通点があり、
その間の「何に着目し整頓するか」が正解はないけれど、それこそが腕の見せ所なんだなと再認識することができました。
準備、審査をされている実行委員の方、1年間頑張られた出場チームの方々に拍手と感謝です。
貴重な戦いをみせていただき、ありがとうございました。
