本記事は、現在参加中のワークショップ（2日目終了時点）のざっくりとした感想メモです。
正式な感想記事は追って再構成・編集する予定です。文体・構成ともに乱れがありますが、思考の記録として残しています。
ーーーーー
# 2日目、モーニングセッションとワーク
2日目はワークの続きをしました。モーニングセッションでは日頃の業務でやっているテストプロセスについても思いを馳せることができてよかったです。
そのままテスト設計の続きと実装をして、実際にテスト実行をしました。いろいろ不具合を見つけて起票したり、リリースできるできないという議論をしました。結局、時間に追われて各プロセスを一所懸命にやるということに終始してしまいました。別に頑張ること自体はいいことなのですが、そういうことではなくて、一個とんでもない見落としを私たちはしていました。
ブロッコリーさんの講評コメントで気がつきました。顧客業務の視点を取り入れられていなかったのです。汎用的な品質の良さにとらわれてしまい、予約のダブルブッキング、ユーザビリティ、画面の見やすさ、操作の間違えにくさ… いずれも表層的なもので、顧客の要求に根差したものではなくなってしまっていたように思います。私は自分でワークショップをやるときは「プロセスをうまくやろうとするのではなく目的を見失うな」と結構言っていたのですが、自分で間違ってしまうのですから始末に負えません。こんなのではとてもじゃないがQAエンジニアを名乗れないぞ、と深く反省する思いでした。メタ的に、自分の思考を眺める、自分の思考をチェックする視点を持つこと。これを忘れずにいたいと強く思いました。
# 吉澤さんの招待講演
最後に吉澤さんの招待講演がありました。長きに渡りテストプロセスや標準に携わられていた方のお話で、色々なことを考えながら聞いていました。
質問も二つさせていただいて、一つはマネジメント的な要求をテストプロセスでどう扱うのがいいか、もう一つは一度広められたプロセスや標準を見直すにはどういう進め方がいいだろうかというものでした。それぞれ、「テスト要求分析とテストアーキテクチャ設計の中で扱うケースが多い」「抜本的に全部見直そうとすると反発が大きくなるので、明確な根拠を持って少しずつ変えていくのがいい」という感じの回答をいただきました。いずれもすぐ答えが出るようなものでもないと思うので、いただいた回答を踏まえて自分でも今後考えていこうと思います。
# まとめ
総括します。
私が特に学んだのは以下の点でした。
- 実務的に、私はテスト実装の解像度が低く、テスト実行に次の瞬間から移れます、というような具体的かつ明確なテスト準備をできていないと感じた。実装は実タスクに近い領域だがテスト実行で変に時間を取らないようにするためにも大切なプロセスなので、まずは基本的なことからきちんと押さえるようにしたい。
- 完了報告〜次のテスト開始への接続もうまくいってないように感じた。自分でも完了報告までは慣れていてある程度の質のものをアウトプットできている感覚があるが、報告しっぱなし、ふりかえりをしただけでは意味がない。次にどうつなげるか、実際に何をどこに活かせていて、改善できているかまで、きちんと見届けないと意味がないと思った。
- 今一度、顧客は何を達成したいのか？と考えてみたい。日頃はテストして品質を確認してリリースの判定をして、というような話をしているけれども実際はお客様は何らかのやりたいことがあって弊社の製品を買っているはずである。お客様が実際何をしようとしててどう使ってるのかを考えることなくして品質を高めようなどと考えてもただの絵空事である。地に足をつけて考えるようにしたい。
- プロセスはもちろん大事で、プロセスを可視化、定義し、良いやり方を広めるのはとても意義がある。一方で、プロセスはすぐに陳腐化したりムダが出てきたり、コンテキストが変わって合わなくなってきたりということが発生する。そういった時に、素早く対応できること。つまり、プロセスを設計し、可視化する一方で、常にプロセスを疑い、時に解体し、望ましい形に作り変えていく。この継続的な構えこそが、真にプロセスを活用するということのためには必要なのだと学んだ。
# 余談１
プロンプトエンジニアリングで英語の翻訳を精度良くやろうという話があって評判が良さそうだったが、個人的には批判的である。というのも、少なくとも私はこの会で紹介されていた翻訳プロンプトを試そうとは思わない。
LLMが精度が良い翻訳をしてくれるということが一体何を指すのか考えてみたことがあるだろうか？LLMの翻訳はgoogle翻訳に文章を突っ込むのとは仕組みが根本的にワケが違っていて、というのも「間違っている可能性」が常にある。（google翻訳も間違うことがあるが、LLMとは構造が違う。）これはどういうことかというと、要するに「間違っていたら自分で気づかなければならないし、自分で直さないといけない」ということだ。
そこでプロンプトエンジニアリングで変に精度だけ上がっていたらどうなる？間違ってても気づきにくい、ということになる。
JSTQBの翻訳がわかりづらいという指摘があるのは良くわかるし、実際私だってそう思う。けれども、翻訳がわかりづらいっていうのはどういうことなのか考えてみてほしい。そもそも翻訳作業は吉澤さんをはじめ業界のプロフェッショナルの皆様が試行錯誤して行っている。その方々がやっても、自然にできなかったのだ。であれば、そこでやるべきは本来「原文を見にいく」ではないだろうか？
JSTQBのシラバスのままであれば、わかりにくいところは本当にわかりにくくなっている。これは非常に大事なことで、「わかりにくいところ」というのがはっきりしているのだ。それが、LLMの「いいかんじ」の翻訳だと、多分全部「自然な感じ」になる。もちろんこれが１００％合ってるのならいいが、残念ながらLLMは「それっぽい文章生成器」でしかないので、１００％正しいということはありり得ない。
そんな感じなので、私はプロンプトエンジニアリングには懐疑的である。使ってもいいだろうが、講演の中でも触れられていた通り「プロンプトは、常に更新されうる」ということと「いくらプロンプトを改良したところで、１００％の正しさを得ることはできない」「間違っていたら、自分で気づいて直さなければならない」というところは気をつけておくべきだと思う。
# 余談２
やはり私はWACATEが大好きだ。これは最初に参加した頃からずっと思っていて、というのも会の理念である「若手の若手による若手のためのイベント」というコンセプトが一貫してずっと守られ続けているところが、組織としても勉強会としても本当に素晴らしいと思っている。これは誰か一人の功績ということでは決してなく、歴代の実行委員の皆様、ひいてはこれまでの参加者皆様など、色々な人の尽力によってもたらされたものであると思う。改めて本当にすごいイベントだ。
# 余談３
これは本当に余談だが、１日目コーヒーを飲み過ぎて夜寝れなかった。というのも、コーヒーのカフェインって半減期の6〜7時間とかで「半減」はするけれども、完全に体内から無くなるには12時間以上、長いと24時間以上かかるらしいのだ。何が言いたいかというと「夕方以降飲んでないから大丈夫」とならなくて、早い時間帯に飲んでても量が多かったら減ってなお残ってるから深夜になっても寝れない、みたいなことになってしまうんだそうだ。
長々と書いたがカフェインはとりすぎると寝れなくなるので注意しようということを思った。
