しょっぱい川を渡って、JaSST'23 Hokkaidoに参加しました

こんにちは、カトです。弥生でQAエンジニアをしています。
9月8日(金)に開催された、JaSST '23 Hokkaido に現地札幌で参加しました。
2023年の遠征は仙台に続き2回目、自由にフラリとさせてくれる会社には感謝です。成果で返します。

前回の遠征、JaSST'23 Tohoku参加ブログはこちら。
tech-blog.yayoi-kk.co.jp

札幌には3年半ぶりに行きました。上京するまで住んでいた、勝手知ったる街です。仙台遠征の時とは違い、てきぱきと最短距離を狙っての移動ができます。
ニュースで見ていたパセオ・ピヴォ・4プラの閉館を目の当たりにして事実であったことに小さく衝撃を受けながら、街を散策しました。

観光気分でベタな写真を撮ってみた。人のいないタイミングで急いだため傾いている気がしなくもない。

JaSST '23 Hokkaido

「心動かさる"コト"の品質」をテーマに、利用時品質、UI/UX、DevOpsに焦点をあて、ソフトウェアテストと品質の今後のあり方を考える会でした。
「〜さる」は北海道弁で、自分の意志ではなく自然に生じるときに使う用語です。
がんばって「心を動かそう」とするのではなく、「自然と心が動いてしまう」ことを考える、そんな1日となりました。
私は、基調講演・招待講演の他、オンサイト限定のワークショップに参加をしました。


ちなみに、タイトルの「しょっぱい川」は北海道弁で津軽海峡のことです。
とはいっても、泳いで渡ったわけではなく、羽田から新千歳行きの飛行機に乗りました。
機内で仮眠をとっていたので、しょっぱい川を渡ったタイミングは定かではありません。

ワークショップ

概要と感想

2.5時間のUIデザインワークショップでした。
説明後、「早く作って早く試して早く失敗する」を合言葉に、未知の存在である「忍者養成学校」のWebサイトを作るワークを、4人1チームで2時間ほどで実施しました。
存在しない組織のため、どんなものをつくっても不正解ではないけれど、参加者のほとんどが忍者に対する共通理解があるという、非常に工夫されたお題でした。

アクティビティシナリオを作成、ペーパープロトタイピングを作成し、ペーパープロトタイピングを使ってユーザーテストを実施しました。
けっこうあわただしかったのですが、2時間で内容がFIXし「あとは実装してテストすればリリースできる」と言えるような状態まで進んだことにびっくりし、感動しました。
認定スクラムマスター研修を受講した際に視聴した動画で、これからつくるものを手書きで画面を書いてイメージのすり合わせをしている場面がありました。それと似たような作業だなと感じながらワークをやりました。

担当プロジェクトでは、「○○ができること」という要求だけではどういう理由で要求しているのかわからないので、PBI(ProductBacklogItem)にWhyやWhatを書いていこうという取り組みをしています。
Howを最初に決めつけず、背景がわかり何を実現したいのかを共通理解にできるという利点があり、チームのスピードが増す取り組みと感じています。しかし、現状はすべてが文字情報になってしまっていて、リファインメント完了となってから画面やシナリオを検討しています。
いざ、画面やシナリオを検討し始めたあとに不自然なところが出てくると調整には時間がかかりがちだし、何をもってリファインメントを完了したのかがわからなくなってしまいます。
このワークショップを受講後、プロジェクトのPBIの改善の第一歩として、要求者が何をイメージしているのかをリファインメントの前に明確にするために質問をしたり、PBIの内容から私が想像したことを記載して確認したりといった行動をとるようになりました。

UXの専門的なことをすべて把握していなくても、チームが早い段階で合意をとることに近づける行動をとる意識ができるようになり、どんなことに苦労してどうすることがサポートになるのかわからなかったUXチームのことを知る機会になりました。

また、「早く作って早く試して早く失敗する」のはUXに限ったことではありません。QAエンジニアの仕事も成果物を見せることはたくさんあります。
私は、抜け漏れを指摘されたり体裁やフォーマットを指摘されたりすることを恐れて、骨子や初稿の段階で広く共有することを躊躇してしまいがちです。
これは「早く試して」ができておらず、チームにとってのデメリットです。
「どこまでできた、何を見てほしい」とレビューイーがレビュー観点を伝え、今後どういう流れで完成に向けていく予定なのかを明確にすることで、スムーズなコミュニケーションをとることができそうです。
レビューアーとうまく意思疎通ができなくて未対応の内容について指摘があったとしても、「早く試して早く失敗する」をやっているのだと自分に言い聞かせることで、初期の成果物を早く共有し続けることができそうです。

印象に残った言葉

愉しむ
「5グランドルール®︎」というツクリビト株式会社の登録商標の一つで、「たのしむ」と読みます。
私は、今まで「たのしむ」には「楽しむ」の漢字をあてていました。
壁を超え成長する、つらさを超えるようなたのしさが「楽」という字にはない気がしていたので、「楽しむ」の表現に違和感をもちながらも他の言い回しが見つからず使っていました。
今回、「キツさや苦しさも含めてたのしもう」という「愉しむ」という表現を使うことで、ただワークショップが「楽しい」だけではなく、少し大変なことも含めて「愉しい」という感覚を得られました。
「愉しむ」ことを意識して議論の場に臨みたいと感じるようになりました。

「5グランドルール®︎」は、「1.ほめる、2.聴く、3.受け止める、4.待つ、5.愉しむ」の5つで構成しています。
ワークショップそのものからの学びではないものの、業務をするうえで意識し続けることで、チームの雰囲気が変わっていく、よい学びになり、忘れないようにしたいと感じた言葉です。

UXチームは橋渡し
私はよく「QAエンジニアの仕事は橋渡し」と言っています。
エンジニアとビジネスチームとの橋渡し、エンジニアとカスタマーセンターとの橋渡し、双方の情報を集めそれぞれの状況を把握し、プロダクトを前に進めるために、プロダクトとプロジェクトの品質を見ながら、交通整理をし、橋渡しをすることが、QAエンジニアの仕事のひとつだと思っています。
その「橋渡し」という表現を別のロールであるUXの人たちから聞いたことが、非常に興味深く感じました。 そして、ワークショップをとおして、要求を具体化し、実現するエンジニアに適切に伝える、あとから「そういうつもりじゃなかった」をなくすような仕事は、まさに橋渡しの仕事だと感じました。

一方で、自分が「橋渡し」をすると言っているときには感じていなかった疑問も持ち始めました。
エンジニア・ビジネス・カスタマーセンターはそれぞれ独立した島に生きている存在なのだろうか?
橋がなくてもお互いがスムーズに行き来できるように埋め立てをして「領土」を広げることはできないだろうか?
「領土」を広げることはチームでできることが広がることであり、プロダクトに関わる関係者が同じ島にいて自由にコミュニケーションをとることができれば、橋はいらなくなるような気がしています。
まだ抽象的な考えではありますが、橋渡しに奮闘する人たちが架けている橋の距離が短くなるような、そして橋そのものがいらなくなるような世界を模索していきます。
チームがより早くお客さまに価値を届けるために、エンジニアの島にもビジネスの島にも定住していない私だからこそできる仕事を見つけていきます。

おまけ

札幌は気候がよく、お散歩日和でした。
JaSST '23 Hokkaidoの会場となったコンベンションセンターの周りを散策したり、休日に百合が原公園に出掛けたり、リフレッシュすることができました。

札幌で撮った写真たち

私にとって新しい場所もありました。もくにゃんのライバルあらわる?



弥生では一緒に品質に向き合うQAエンジニアを募集しています。 herp.careers