本記事は、現在参加中のワークショップ（１日目終了時点）のざっくりとした感想メモです。
正式な感想記事は明日のセッション終了後に改めて直して投稿する予定です。
文体・構成ともに非常に乱れている部分がありますが、ひとまず記録として残します。
ーーーーー
# BPPセッション（yamaさん）
非常に示唆に富む発表だった。最初に話すこと、話さないことを明示していただけたので「こういう話をされるんだな」と予想がつき、聞きやすかったのもあるし、とにかく実際に働いているQAエンジニアとしての実感が強くこもっていたのが印象的だった。またQAエンジニアの大切な特徴である「中立性」にも触れており、普段の自分の働き方をふりかえる機会にもなった。特に、Slackのリアクションを２つつけてみる、朝会のファシリテーションで気の利いた一言を言ってみるといった具体的な試みもとても勉強になった。
ーーーーー
# ワーク（講義ターン）の感想
杞憂さんの発表を聞いて、やはりJSTQBの標準プロセスは抽象度がすごく高いなと感じた。標準なので当たり前だが。
個人的には、私が最近失敗したのはテスト実装プロセスをないがしろにして失敗したのだなと感じた。こうして、どこを失敗したのかを明確に振り替えられるという点でも、プロセスを適切な粒度に分解するというのは大切だと感じた。
また、これも私個人の実務をふりかえってのことだが、完了→スタートへのつながりをうまく作れてないな、という反省もできた。こうした気づきを得られただけでも参加した意義はとても大きかった。と同時に、けっこう基礎的と思っていたこともまだまだ全然できていないなと反省した。
話を聞いていて、実際に役立つプロセスとは「その組織が自走するために使えるガイド」なのかなと感じた。細かすぎても重すぎることになるし、抽象的過ぎても「じゃあ結局何したらいいの？」となる。
graatさんのアジャイルに対応したテストプロセスは非常に有用そうなので、後でじっくり調べてみたいと思った。
ーーーー
# ワーク実践ターンの感想
テスト設計技法を予習してきてくださいというアナウンスが大事だった理由がよく分かった。ワークの中では適切なテスト設計技法を選択するという場面があったが、この時に、どの技法が何に使えるのかというところから議論が始められるととても話が早い。というか、確かに実務においては技法が先に来るのではなくてシチュエーションが先にあってそれに合う技法を選ぶことがほとんどなのだから、そういう意味でも非常にリアルなシチュエーションだと感じた。
ワークそのものはチームメンバーにも恵まれてすごくいい雰囲気で進められている。モチベーション高い参加者が集まっていて、とっても進めやすい。そして、実際に実行を見据えているという点でも、実行を見越して設計の妥当性をみるという視点がでるので、すごく勉強になる。実務でも実行工数が限られているというのはめちゃくちゃあるあるなので、やっぱりワークショップとしてとてもよくできていると感じた。
ーーーーー
# 分科会などでの感想
分科会ではプロセス改善について議論したが、いろいろな人の意見を聞けた。特に、プロセス改善の上手なチームはそもそもプロセスの抽象化・具体化が上手いということを指摘している方がいて、確かにと思った。やはり、抽象・具体の行き来をコントロールするスキルはかなり汎用的に使えるのだろうと感じた。
ーーーー
# 実行委員の方へ向けた感想
今回も非常に練られたワークショップで、とても楽しめている。特に、チームでグランドルールを決め、それを見える位置に貼っておくというのは非常に効果的で、ふとした瞬間に目が止まる、さらには具体的行動に落とし込まれているので、即時的フィードバックが得られて、とてもいいなと感じた。
あと、私が実行委員をしているJaSST東北に比べて、休憩時間が適切に組み込まれており、長時間のわりに疲れが少ない。純粋に疲れすぎると集中力も切れがちになるので、これは見習いたいと思った。会場も非常にワーク向きな印象で、机も広くて作業しやすかった。
仕様書の範囲の限定の仕方も巧妙で、「これくらいならぎりぎりこの時間でも終わらせられなくもないな」という絶妙なラインだと思った。アプリとしては結構本格的な題材にして「ここはスコープ外です」と明示的に示すことで、けっこうリアルな規模感で試すことができていいなあと思った。一方で、スコープ外とかスコープに入るみたいな話が出てくると「これはスコープ外なのか、範囲内なのか」という不毛な議論が発生しがちなのは難しいな～と感じた。本来注力すべきところではないから一定のところで切るべきなんだろうけど、まあなんというか、けっこうメタ的にワークを参加者がどうとらえるかみたいな話になるので、やっぱこの辺は難しいなと感じた。
2日目に続く
