■wacate2025いってきた
行ってきました。怒涛の2日間でした。ジェットコースターのような。。
wacateが何であるか、技術的な内容がどうであったかはさておき、私はひたすら自分の感想だけを残そうと思います。
■感想を簡潔に書くと
・うおー！忙しい、、、！！！
・みんなすごい話す！すごい！
・説明するとは、、分析するとは、、かように難しいことか
・頭の中で具現化できないことがある
・プロセスに沿う事とはつまり、具現化することで、説明できることではないのか
全然感想になりませんでした。以下は超長文が続きます。
■1日目：6/28
朝9時くらいに新習志野につきました。2025年の6/28は快晴。控えめに言っても暑かったです。
駅からワークの会場までは徒歩で7分くらい。駅からホテルが見えます。茶色い建物です。
ロビーでまったりしたあと受付へ。
私は参加回数が今回3回目だったのですが、一番参加が多い方になってました。wacateの参加者は輪廻しているのです。
しばらくしてオープニングの始まり。
並木さんの「加速はひとそれぞれ」100回聞いても身にしみます。。。
1回目のポジションペーパーによる自己紹介が終わり、席替え後、またポジペを使用して自己紹介しました。私は、かつて初めて参加したときにベテランの人がそうしてくれたように緊張しなくてもよさげなふいんき(なぜか変換できない)を作れたかとか謎なことが気になってましたが、結論としては私がどうとかじゃなくても班の方はみなしっかりした良い人でした；；wacateの空気パ、パワー、！
BPPセッション(yamaさん)
ポジションペーパーセッションが終わり、最初はyamaさんによるBPPセッションでした。
新卒でQAに入られたときの悩み、やがてQAの魅力を腹落ちするまでの話がかわいいイラストとともに臨場感たっぷりで語られました。
開発に感謝されてチームとして連携していることが分かった・・の下りがとっても好きです。
同時に、とても良い先輩がいらっしゃるんだなと聞いていて思いました(QAの中立性や大切さを説いてくれる先輩)
QAやテストに関わる人が自分を卑下せず、きちんと自分やこの仕事の価値を腹落ちして後任にも伝えていけることが大事なのだろうと…
昼ご飯(1日目)
BPPセッションが終わった後はお昼ご飯でした。ビュッフェ形式です。
自分の知らないドメインの話を聴けたのが良かったです・・
心の中でφ(. . )メモメモ（古の絵文字）していました。
セッション1：テストプロセス(杞憂さん)
午後は杞憂さんによるテストプロセスのお話から始まりました。
ときたま、各用語の語源の話に触れながらISTQBのテストプロセスや、プロセスを定めていないとどうなるかなどについてのお話がされました。
Test.SSFについて私はスキルセットの表しかイメージがなかったのですが、今みたらプロセスも書いてありますね。。
Test.SSF、ISO/IEC/IEEE29119-2、マインドマップ本、ISTQBのテストプロセスの比較の表がめちゃくちゃ面白かったです（語彙がない
マインドマップ本は仕様分析が計画よりも先なんですね。他プロセスと並べてみると計画より先なのが不思議な感じでした。
でも今マインドマップ本を読んでみると「まずテスト対象にまつわる色々を理解しよう」に見えるので、他プロセスでは暗黙で計画の前提条件になっているところなのかもしれない…と思いました。
そしてこの次からテストプロセスのワークが始まりました。
セッション2：仕様書読み込み
要求仕様書、ワークのお題、受入テスト計画書が配布され、最初は3色ボールペンを使用して仕様書読み込みをしました。3色ボールペン法、ソフトウェア技法ドリルの最初に載ってますね。
赤が最も重要、青がまぁ重要、緑が疑問点だったと思います。
私は微妙に使い分けられなかった＋時間内に読み込みが終わりませんでした。
仕様書とテスト計画書の細かいところに目がいってしまいがちでした。
セッション3：テスト分析ワーク
そのあとはテスト分析のフェーズで、まずはユーザーがシステムで出来てほしいこと、業務上起こりえることを考えました。
ユーザーがシステムで出来てほしいこと…が要求で、業務上起こりえることがプロダクトリスクなのかな…と考えていました。
自分は「できてほしいこと」は細かいところまで考えていませんでした。ただ半面、妙なところにも捉われていました。
妙なところの一例を挙げると、受入テスト計画書の「スタッフ用の管理機能」はテスト対象外の機能なのに
予約するときに自分の指定のスタイリストを選べるのってわりと美容院では重要だろうから、完全には切り離せないのではなど…
全体的に視点をぐっと上げる事ができてなかったかもです（今ワークのお題の紙をみるとホロホロしてしまう）
ここまでの2つの情報を踏まえ、その次はどのようなテストが必要かについてを考えました。
(思い出すためだけの記載)これは確か大きな模造紙に付箋をぺたぺたしたワークでした。
ここは「テスト」という言葉の粒度が自分は考えづらかったです。
細かいところまで定義するのか、それともふわっとテスト「観点」をあげるのか・・
ここは班の方の挙げられた内容をみて「おお～確かにな～」とうなずいてばかりいました。
そこから、テスト計画も考慮して必要なテストを選ぶワークへ。
この時にテスト計画書をみて、班の方達と「テストの実行時間超短い」って思ったことを私はあと30年忘れません。
ここで実行時間が短すぎるので、自然と優先度をつける流れになりました（エッジケースは捨てる感じに）
ここで金額表示について「あくまで予約であって決済じゃないんだよね…」って話した気がします。
この段階で結構優先度を決めていたので、次のワークの優先度を決める、は大体このままでした。
。。だったかな？もしかして私忘れてる、、？？
セッション4：テスト設計ワーク
だいぶ夕方も近づいたころ、テストすることを決めた事について使えそうなテスト技法を選択しました。
テスト技法…テスト設計技法とは何だろう？と考えていた時間です。ユースケーステストは設計技法なのか…など考えながら、状態遷移図、デシジョンテーブル、あたりをあげて1日目が終わったと思います。
超忙しい休憩時間
ずっと前に参加したwacateも、この休憩時間(1日目ワーク終わり～晩御飯まで)が忙しかった記憶があるのですが今回も相当忙しかったです。
実質30分くらい？の間でルームキーを貰い、部屋にチェックインして、などを行いました。
夜ご飯
お昼のメンバーとは別のメンバーと食べてみよう～が推奨されます。
今回のwacateにおいて、ご飯と分科会が会話できる貴重な機会でした。(一緒にご飯した方ありがとうございました)
ちなみに夜ご飯はビュッフェではありませんでした。
ハンバーグと揚げ物的な何かと明太子的な辛い何かがありました（雑な説明）
晩御飯を食べ終わった後は分科会まで時間があるので、分科会で飲んだり食べたりするものの買い出しへいったりします。
ホテルのロビーにはあまりアルコールなどが置いていないので、駅前の商業施設に買い出しにいくのがよさげでした。
2025年のベルクスには檸檬堂が売っていなかったので檸檬堂好きな人は気を付けてください。
この時月がキレイでした。弓張月と言うそうで、おおー三日月も識別するとそんな素敵な名前があるのか…と思いました。
分科会
えるしっているか 分科会の部屋は20時まであきません
分科会はワークの部屋と同じ会場です。椅子です。
なんでわざわざ「椅子です」と書くかというと、私のはるか昔の記憶、2019年のwacateは畳の部屋でみんなちゃぶ台みたいなところに酒を持ち寄って何かをした遠い記憶があるからです。気のせいかもしれません。
テーマによってそれぞれの場所に分かれて談義しました。今回は4，5個の分科会があったかな？
自分は少しまったりしたかったので、比較的少人数だった推しイベントや本を話す机にずっといました。
色々な人と話したのですが、wacateが最初に来たイベントだという方が多かった印象です。wacateだからか…
一緒にいた坂(ばん)さんが色々おすすめしてくださっていて自分も行きたいな～と思いました。特にスクラムフェス、XP祭りあたり。
実際に行かれた方の経験談を聞くとぐっと行きたい気持ちが強まります。多分「どんなイベントかわからない」っていうところからハードルが下がるんですね。
分科会ではないですが、本のおすすめの話でコードレビューの本の話を聞いて「買うか～」という気になりました。
なんでもそうですが当人が熱意を持ってお勧めしてくれることが一番です。
あんまり移動しなかったのですが23時半くらいまでいました。
私は多分ここで見たトリスハイボール(濃いめ)と、聞いたお悩み、うまく答えられなかった自分に具現化できない部分があったこと、ウイスキーの味が全然違ったことを忘れないと思います。（何の話…？
部屋に戻ってから一生懸命ポジションペーパー読みました。
■2日目：6/29
朝ごはんは各自で起きて朝食会場へ。
内容は28の昼とは少し異なるビュッフェでした。
モーニングセッション(かおりっとさん)
自分の普段の観点を思い浮かべて、何故それをテストしたかを2人1組で話すというワークでした。
PFDをかいたのですが途中で「何故」がループしてしまいました。とほほ
インタビューから普段の仕事についてぼんやり考えてる部分に向き合えること、どこまでが設計と考えているのかに向き合えること、何よりも他社の方の事例が少し見えて、ああ似ていたり異なったりするんだなあと実感できる、ぎゅっと詰まった楽しいワークでした。
テスト設計ワークの、、続き…
私はログイン周り、状態遷移図？を考えよう、とがやがやしていたのですが
画面なのか、それとも表示が切り替わるだけなのか、（それが画面なのか）ヘッダーからの遷移はどうするかとか悩みました。ログインで通りがちなフローとは。。
今思うと状態遷移図に複数の意図を持たせていたかな？と思います。ログインできること然り、戻りの遷移しかり。
遷移を網羅したいのか、それともお客様が通常取り得る動作（そもそも通常とは？）を試したいのかでも変わってくるのかな、、と頭の中でうまく言語化できてない部分があったかもしれません。
書いていても難しいです。
テスト実装ワーク
実際のテストケースに落とし込むワークだったのですがExcelは偉大という感想が…
ここで悩んだのがテスト分類とテスト内容。
画面で分類すると思うとテスト技法ごとで割れているからなかなか表現しづらい。
テスト分類を技法とすると今度はテスト内容が見えにくくなる？気がしてどうしたものかと思いました。
テスト実行ワーク
実物のバグの多さに捉われるワークでした。プロダクトのバグの埋め込みが秀逸すぎて。。
良く作ったな～～という感想です。
リリース判定・発表
発表はとにかくお疲れ様でした。ありがとうとお疲れ様を100万回言いたいです。
私がいた班は、リリース判定が分かれたことが特徴だったと思います。
リリースできる・できない、どちらの考え方もアリだと自分は思っていました。
その上で自分が考えたところ。
自分は「バグを全部発見しきる」というのは無理だと考えています。その上で、バグの数は現在のプロダクトの状況を図る指針と捉えています。
今回、見つけたバグを全て直せる前提でリリースしても良いと考えるのもありだとは思いましたが、実際に関わっているプロダクトで、軽微ではない複数のバグが発見され続けて、その内容も仕様書に定義されてたところが単純に間違えてるだけなどではなく、作りを根本から考えたほうがいいものが多かったのでそれだとリリースしないかな…と判断しました。
とはいえ、(スタートアップのように)リリースしないと始まらないという状況があるのなら、リリース後の運用・バグが出たときの対策(再リリース然り代替手段しかり)を打っておくことなどでリリースするのもアリだとも思います。
招待講演(NEC 吉澤さん)
テストプロセスという言葉がまだなかった頃からの話、テスと設計コンテストが始まる前の前身の話など、様々なお話をしてくださいました。
今変わりゆく時代だからこそ、かつて過去どのようにして今につながるテストのコミュニティが始まったか、テスト設計コンテストはどう始まったか、標準の策定の苦労などの話が聴けてよかったです。
私がなぜ昔の話を知りたいのかというと、当時にそこに込められた思いに感情移入したいからなのだと思います。
プロセスを「そうあるべきもの」として認識するより「良いよね～」と腹落ちすることで知り、使っていきたいのです。
当時の生き生きとした、貴重な体験談をお話しいただいたことに感謝します。
そして今につながるここまでの知識体系を整備していただいたことにも…
総括
行ってよかったです。
あんまり文もまとまらないのですが
ワークの設計が秀逸なのはいわずもがな、自分が言語化できない、説明できない箇所をすごく意識する機会になりました。
プロセスで順序だって考えるということは説明をできる事の第一歩で、それを頭の中で自然とできるようになりたい。それは一朝一夕で出来ることじゃなくて意識して少しづつやっていくしかない。
例え設計や実装がAIに置き換えられたとしても、根拠を説明するのは自分で、合意するのもAIではなく人間なので、いつまでも根拠を自分で考える事だけはやめてはいけないのだと思います。
あと自分は実はまったく若手ではなかったのですが、そんな自虐をしている暇はまったくありませんでした。とにかく、駆け抜ける感がすごい2日でした。実行委員の方、ご一緒の班だった方、お話してくださった方、ありがとうございました。
