0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WACATE初参加レポート:WACATE2025夏 〜動かすだけじゃだめですか?〜

Last updated at Posted at 2025-07-06

はじめに

 本記事は、現役QAエンジニアが ”内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ” WACATE に初参加したという内容のレポートです。
 内容はWACATEへの参加記録および学習したことのアウトプットですが、初参加者目線としてWACATEに興味のある方むけのナマなお話も含んでいます。WACATEに興味のある方・参加してみたい方もぜひ読んでいただければ幸いです。なお、感想や学びの部分は長いので折りたたみました。

参加の目的

後述するポジションペーパーでも記載した
・ガラパゴス状態を、打破せよ!
・コンフォートゾーンを、打破せよ!
が参加の目的そのものですが、これらの目的を1行でまとめると「QAエンジニアとしての停滞を打破し、自分の行っているテストプロセスで弱い部分を補強するためのインプットとする」です。

ワークショップ概要

日時;2025/06/28(土)〜06/29(日) ※合宿のようなイメージです!
参加者;60名(12名増枠した上にすべて埋まったとのことです!大人気!!)
場所;トーセイホテル&セミナー幕張
公式サイト;WACTE公式サイト
      WACATE2025夏 〜動かすだけじゃだめですか?〜

ポジションペーパー

 参加申請時にポジションペーパーの提出必須とのことで、人生で初めてのポジションペーパー(立場表明書)を書きました。最初の自己紹介時に使用する自己紹介ペライチのような立ち位置ですね。
 ポジションペーパーのテンプレをベースに、自己紹介・参加への意気込み・持ち帰ろうとしていること・問題提起・議論したいことなどなどを書くものとのことで、持ち帰りたいことを主軸に「感じませんか?停滞を! TMR, 打破せよ!」というタイトルで記載しました。ちなみにタイトルの元ネタはポケモンレジェンズ アルセウスでのとあるセリフです。
 WACATE当日、皆さんの様々なポジションペーパーが立派に製本さされていて驚きました。自己紹介や意気込みを文章で書いている方はもちろんのこと、ほぼQRコードとイラストの方、推しの本の記載のある方、図を中心にしている方など十人十色で個性豊かです。冊子を眺めているだけでも時間が過ぎていきます。

セッション内容と学んだこと

各種セッションを振り返りつつ学んだことをアウトプットします。
全セッションに生成AI禁止令が出されたので人の思考のみの勝負となります。

BPPセッション

 前回のWACATEでBPP賞(Best Position Paper賞、参加者の投票で決まる”最もポジションペーパーの内容が良かったで賞”)を受賞したyamaさんの発表からWACATE2025夏の火蓋がドンと切って落とされました。

このセッションでの学び・感想  新卒QAとしての様々な課題とそれをどう乗り切ったかを語るリアルで臨場感のある笑いあり・学びありなお話でした。堂々と発表しており、2年目とは思えないほどの上手すぎる発表に手が爆発するくらいの拍手です!  QAは開発の敵、そんな事例について思い当たる事案が脳内でフワフワと出てきながら聴講していました。さらにチャットコミュニケーションでのリアクションを2つ付けるなど、QAエンジニアが抱えがちなコミュニケーションに対する具体的な回答もあり学びがありました。チャットコミュニケーションでは積極的にリアクションを今後もつけていきたいですね。そして何よりも「QAエンジニアの中立性」について触れられており、改めて中立性について考えるきっかけになりました。 るかもという学びもありました。

ワークセッション

架空のアプリの要求仕様書と受け入れテスト計画書をテストベースとし、セッション用にテーラリングされているとされながらも実践さながらのテストプロセスを体験しました。グループごとにディスカッションしながらテスト分析〜テスト完了までのプロセスを行いました。

テスト分析

要求仕様書と受け入れテスト計画書を3色ボールペン法でメモを書き込みながら読み込んで要求や制約を理解したあと、何をテストするのか(=テストスコープを決める)・どの優先順位でテストをするか・どのテスト技法を使うかを明らかにするセッションです。

このセッションでの学び・感想  普段は仕様書をPDFで読みつつ気になる点を片っ端から仕様書指摘表に書き込んでいくフローなので、3色ボールペンを使った仕様書読み込みは研修以来のワークだったかもしれません。短時間で書けるだけ書きはしましたが、後日書きこんだものを振り返ってみると受け入れテストフェーズでの指摘ではないような細かい指摘や機能改善提案がちらほらありました。受け入れ検査というより機能検査の観点ですね。テスト種別の意識切り替え、大事。  実際の業務で、テストスコープや優先度付けが甘いままテスト実施フェーズまでもつれ込んでテスト実施フェーズで結局は実施内容を削ることがたまに観測されるので、テスト分析フェーズで優先順位ややらないことの定義をきっかり行えば全体的なテスト工数のつながるよなあと手を動かしながらフと思いました。  チームで議論しながら分析を行ったので、自分が漏らしている観点を他の人が指摘してくれていることがありました。私はある程度ひとりでテスト方針を引いてからテスト設計・テストケース作成指示を出すスタイルが多いので、メンバーと議論するほうが方針策定や分析フェーズでの観点漏れが少なくなるかもという学びもありました。

テスト設計

テスト分析でのアウトプットをもとに、テスト技法(デシジョンテーブルや状態遷移図など)必要十分かつ効果的なテストケースを導出するセッションです。

このセッションでの学び・感想  ペアで組みながら状態遷移図・状態遷移表を書きました。そのなかで状態遷移表で「未定義」となる状態があり、お互いに「これは分析フェーズで漏らしてしまったなあ」と言っていました。状態遷移についてのテストは仕様書からガーッと書きがちですが、こうして状態遷移図・状態遷移表を書くことで未定義となる状態を検出でき、図表を書くことによる網羅性の確保の威力と重要性をあらためて認識しました。

テスト実装

テスト設計のアウトプットをもとに、テスト分類・テスト内容・前提条件・手順・期待結果・実行結果を記載してテストケースに落とし込むセッションです。

このセッションでの学び・感想  時間がないとはいえ、手順を端折って書きすぎたところがあり、ペアの方に指摘を受けました。時間がないとわりと手順を適当に書きがちな業務での悪い癖が出てしまったと猛省しています。確実にテストケースを組んだ人がそのままテスト実施を行うなら手順を書かなくてもよいのですが、テストケースを書いた人とテスト実施を行う人が違う場合はテスト目的がブレる可能性が出てくるので面倒でも手順を最低限は書くべきなので、今後の業務でも気をつけるポイントだなと感じました。

テスト実施

テスト実装のアウトプットであるテストケースをもとに、実際に手を動かしてテストを実行するセッションです。なんと今回は本物さながらのWebアプリがデプロイされており、実際に触ってテストできるといういたせりつくせり!でした。感動、感動。ついSQLインジェクションなどで壊したくなりましたがセキュリティ系テストはスコープ外なのでしません。

このセッションでの学び・感想  ウッキウキでPCとスマホを同時に触りながら状態遷移系のテストを行いましたが、未定義とされた部分の異常遷移や同時予約のような排他の部分までテストケースからは不具合がヒットしませんでした。くやしい、くやしい。あ、そういう話じゃなかったですね、受け入れテストなのでOK品質ですね。またテスト目的が迷子。  テスト実施もペアでやってくださいとアナウンスがありましたが、いつも基本的に一人でのテスト実施が多いもので、つい一人でテスト実施してしまうことがありました。反省します……。同時に、ペアでのテスト実施の良さを体験できました。テスト実施時の減少の漏れを指摘しあえるという可能性を感じました。

テスト完了(振り返り/発表)

一連のテストプロセスを振り返って気づきとリリース判断を共有してチームとしての意見をまとめ、各チームのテスト分析・テスト設計・テスト実装の一部を軸にリリース判断を行うまでの一連の流れを発表するセッションです。

このセッションでの学び・感想  当チームは満場一致で「ハッピーパス(エラーや例外が発生しない、理想的な処理やユーザー操作の流れ)の項目はすべて合格しているのでリリースOK」の判断でしたが、他のチームはリリースNGというところもあり、大変興味深かったです。また特定の条件で発生する仕様不具合を検出したチームがあり、「その状態があったか!」という学びがありました。くやしい、この手で検出したかった……。[私が2日目の最後にフィードバックしたかったこと](https://wacate.jp/2025/07/01/%e7%a7%81%e3%81%8c2%e6%97%a5%e7%9b%ae%e3%81%ae%e6%9c%80%e5%be%8c%e3%81%ab%e3%83%95%e3%82%a3%e3%83%bc%e3%83%89%e3%83%90%e3%83%83%e3%82%af%e3%81%97%e3%81%9f%e3%81%8b%e3%81%a3%e3%81%9f%e3%81%93%e3%81%a8/) にも記載のある「想定外で見つけた不具合こそ振り返りのチャンス」とのことで、あらためて個人で考察を行い振り返ろうと思います。

分科会

1日目の夜に開かれる、いくつかのテーマに沿ってフランクですがテーマによっては濃ゆいお話をする会です。これを目当てにWACATEに参加している人もいるようです。

このセッションでの学び・感想 参加した分科会テーマと少しズレた内容の相談もしてしまったのですが、コミュニケーションに関する学びが多々ありました。QAエンジニアは関係者とのコミュニケーションが多くなりがちなので、立場や関係者が違えど様々なコミュニケーションに関するお悩みやノウハウがありました。  もっとも興味深かったのは、ソフトウェア開発エンジニア視点でのQAエンジニアに対する思いです。開発エンジニアからQAエンジニアに対しての考えは「トラブルの事前共有があると嬉しい。QA側としてもトラブルへの対処が早い段階からできるのでありがたい」、QAエンジニアから開発エンジニアに対しての考えは「品質に関する指摘はプロダクトの品質向上につながるので嬉しい。より良いプロダクトを作るために指摘してほしい」と声がありました。立場が違うエンジニア同士がオツマミを食べつつ酒を飲みながら腹を割って品質について話す機会はなかなか私の周りではないので新鮮な意見に感じました。  あと最も参考にすべきなのは「大阪のおばちゃんコミュニケーション」ということがわかりました。大阪のおばちゃんのコミュニケーション術を参考にしましょう。

招待講演

 日本電気株式会社の吉澤さんによる「ソフトウェアテストの優しい道標:プロセス・標準類の入口の話」というテーマの招待講演セッションでした。

このセッションでの学び・感想 テストプロセスや標準化のレジェンド直々の講演……!普段何気なく業務で使っていたテストプロセスの成り立ちの歴史をはじめとしたお話すべてが興味深すぎて、1時間半があっという間にすぎていきました。  とくにテストプロセスの成り立ちについて、普段なにげなく使用しているテストプロセスは、吉澤さんとはじめとした先人たちの汗と涙と努力と議論が濃密に凝縮された結晶であり、巨人の肩の上にありがたく乗っからせていただいているのだと再認識させられました。先人に感謝感激スコール雨あられ……!そして「なぜテストプロセスがあるのか」「テストプロセスとはベストプラクティスであり組織に合わせ変化させていくもの」を後輩などに説明しやすくなったかもしれません。さらに「良いプロセスと悪いプロセス」に関する考察を深めるきっかけにもなりました。

まとめ

 皆様から様々な刺激を受けてQAに関する書き物をまたしてみようかなというモチベーションアップができたうえに、そして標準的なテストプロセスをワークショップを通じて主体的かつ体系的に学ぶことができました。よって参加目的である「QAエンジニアとしての停滞を打破し、自分の行っているテストプロセスで弱い部分を補強するためのインプットとする」が達成できました。
 特にテスト分析フェーズ・テスト設計フェーズで改善点が見つかっているので早速ふだんの業務で改善していきたいと思います。モチベーションが爆発したので、WACATEの宣伝を兼ねた社内報告会のセッティングをさっそく開始しました。

全体を通した感想

 WACATEは、初めての参加者でもコミュニケーションしやすい雰囲気づくりが徹底されていると感じました。コミュニティができるとリピートさんを中心に身内感が出てきがちなものですが、セッションすべてにおいて初参加の方でも入り込みやすい空気で安心感がありました。次回以降に参加する際もこの良い空気感を守っていきたいです。
 またワークやメモを取ることにいっぱいいっぱいすぎて、Xにハッシュタグ#WACATEをつけて投稿する余裕がなかったです。次に参加するときは盛り上げのためにも投稿したいですね。
さらに書き物へのモチベーションもアップしました。ネタはともかくまた何かアウトプットしようかなという思いが湧いてきました。

おわりに

 遠方住みのため移動や前泊込みで約7万円ほどかかりましたが、標準的なテストプロセスの習得・とても貴重な招待講演・スタッフの方々や参加者との出会い・モチベーションアップどれを取っても7万円以上のリターンがあるワークショップでした。
 当初の参加目的であった「QAエンジニアとしての停滞を打破し、自分の行っているテストプロセスで弱い部分を補強するためのインプットとする」の達成はもちろんですが、WACATE実行委員長ブロッコリー氏の「このシステムならではを意識できていましたか?」というテストに対する本質的な問いかけを得ることができたのも収穫です。テストに夢中になると本質を見失いがちなので、「このシステムならでは の品質や価値とはなにか?」「お客様がこのシステムを使用された際にどのような思いをされるのだろうか?」を常に念頭に置いてテストプロジェクトを遂行していきたいです。

 この記事もAIに出力した文章はいっさい無く、すべて私の手打ち(?)で記載しました。参加のシメとなるこの記事まで「AI使用禁止令」を忠実に守り抜きました。

 業務の忙しさ度合いやテーマ次第ですが、冬のWACATEの参加も非常に前向きに検討中です。さらに冬のWACATEに参加できたならばスタッフとしての参加も考えています。
 参加者の皆様、またお会いしましたらよろしくお願いいたします!
 そしてスタッフの皆様、WACATEを企画・運営・開催していただき本当にありがとうございました!!とても良い経験になりました!!!

新習志野WACATEの虹.jpg

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?