テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

東京出張って何やってんの?QAという組織で働くこととプロジェクトチームで働くこと

 

わたしは、だいたい2〜3ヶ月に1度のペース(時期によってはもっと)で東京に出張しています。
それにはいくつか理由があるけど、ざっくりいうと、自分の社内外の所属が大体東京だから。って感じだからです(ざっくり)

社外活動については大体会議で来ています。
今回は社内の方でなにやっているかを怒られない程度に書いてみます。

 

QAという組織で働くこと

わたしは、今の会社でQAという組織に所属しています。
そこには、色んなタイプのQAのメンバーがいます。
その組織は東京にあるため、QAのイベント(社内)があるときに東京に行くようにしています。
このあとプロジェクトチームについても書くのですけど、QA組織が横断的におこなっているような活動についても リモートで活動しています。

 

プロジェクトチームで働くこと

いつもは地方オフィスで働いています。そこには、プロジェクトの各ロール(プロジェクトマネージャーやエンジニア)がいて、一緒に働いています。
わたしたちのプロジェクトチームは(とくに今は)ずっと同じチーム、同じプロジェクトで働いています。
なので、ドメイン知識はこのプロジェクトのドメインをぐんぐん吸収中です(たぶん)。
このチームのQAオーナーというか、QAに関する責務は自分が担っているつもりでやっています。
さらに、スクラムマスターであったり、PMのお手伝いなども、やったり(やれてなかったり)しています。

東京で得るもの

さきほど、プロジェクトチームのQA(やスクラムマスターとか)はわたしが責任を持ってやっていると書いたんですけど そうすると、3ヶ月に一度くらいで行き詰まったり、迷ったり、悩んだりすることが少なからずあるんですよね。
これは、今の会社が3ヶ月に一度ふりかえり時期があるからでもあるんですが 自分のやっている活動に価値をだせているのか、方向性があっているのかとか結構ずっと悩んでいます(そういうと、今の会社だけでなくて、ずっと悩み続けてはいるかも)
なので、東京にいる間はわりと、その悩み相談をしたり、色んな人と1on1をしてみたり、相手の考えを教えてもらったりすることが多いです。
基本的に相手はQAのメンバーなんですが、ときどき全然違うロールの人とすることもあります。

声掛けをするときは、明確な目的があるよりも、そのときにちょっと今回この人と話したいってノリで決めることも多いです。
(声かけていただけるとうれしいけど、そんなお誘いはそうそうないという。。そりゃそうか)

例えば今回の出張では、二日間で以下のアクティビティを(結果として)やってました。

  • メインイベント1つ
  • リモート活動しているQAのミーティング1つ
  • 1on1ベースのアクティビティ4つ
  • 他のプロジェクトや組織のあさかい2つ
  • 立ち話(1分とか)はちょこちょこちょこちょこ(ありがたや。QAではない人が多いかも)

出張のときは、大体こんな感じ(メインイベント、サブイベント、空きがあれば人と1on1)が多いかもしれないです。
そういえば、以前してた勝手に社内勉強会イベントはやってないなぁ・・・近いうちにやる気になったらやれるといいかもしれない。
(自分の勉強会に価値を見いだせていないのかもしれない。新作はよ)

 

話してみるとわかるもの

他の人からみた、わたしやわたしのプロジェクトチームのイメージ(大体良い感じに言ってくださいます。チームはよいけど、自分自身のことは課題だらけだと思っているのですけど。。)
もしかしたら、隣の芝生は青く見えていることもあるのかもしれないし、わたしも青くみているかもしれないって思える。

みんな自分や自分のチームに課題感を持っていることがわかる
普段はチームでの共有会はあるので、その粒度のことは理解しているつもりだけど それが個人単位でどういう課題感があるのか、どう感じているのか、が理解できるのがありがたい。
ちなみに、やれていることについては、それが当たり前なのでわざわざ言わないんだろうなとおもう
(どう?すごくね?って話しも聞きたいなぁ。今度リクエストしてみよう。なんとなくQAという性質もあってか 自画自賛を得意としていない人が多いのかもしれないってふと思った)

 

わたしがやろうとしている目論見について、なぜ現時点でできていないかがちょっとだけわかる。
大体はお話し相手の知見を聞くことで自分との乖離とかがわかるつもりになるからなのかなと思う。

 

おわりに

わたしは2箇所にふたつの大事な意味のあるところにいることができてすごいしあわせな環境なんだなと、書いていてあらためて思いました。

たぶん、定期的に違う環境、場所のインプットが社内でできるってとても恵まれているんだなと思いました。

 

そして、これらの活動のほとんどが自発的に勝手にやっちゃってよい会社って、この会社規模ですごいなってあらためて思いました(出張報告は出してるけど、予定はメインくらいしか上長確認はないので、ほぼ事後報告)

つまりその分ちゃんと成果につなげないと!つまてことだと思います。がんばらねばー

2020今年の抱負

SNSにもあげていたけど、今年の抱負をちゃんとここに書いておこう。

  • チームについてちゃんと考える
  • 伝わるアウトプットをする
  • 本を読む

ほんとはこれに英語も追加したり、健康とかも入れた方がいいんだろうけど とりあえず3つにした。

チームについてちゃんと考える

昨年わたしが公私で関わる複数のチームで、自分はチームにどうかかわるべきか考えさせられる出来事があった。
これは、チームにとって悲観的ではないかもしれないが(実際うまくいっているものもある)
わたしにとっては、かなり大問題だと思っている。

チームによって自分の立ち位置はさまざまで、いままでそれで正しいとかよい位置に立てていると思っていたものもあるけど
きちんと考えたときに、わたしはチームとして成り立てていないのではないかと自分を疑うようになった。
これは、今も疑っているし、まだ整理も全くできていないし、整理もできていないからこれからどうあろうとすべきかすら考えきれていない。

ということで、これは一年かけてちゃんと考えて行動できるようにならなきゃなって思っている。
去年最大の問題。

伝わるアウトプットをする

 上にも関連することもあるかもしれないけど、わたしはアプトプットの量はそこそこ多い(ツイートなら12万を超えている)のだけど
質についてはとくに気にしていない(それよりも、まず出すことに価値があると考えている)傾向にあるなと思っている。
それはそれで出さないよりはいいのだろうけど、
それではいつまでたっても、人と理解しあうことがない(またはニッチに私に理解を示してくれる一部の人たちだけ)と思う。

それを証拠に、わたしのスライドであったり、ブログであったり、数値としてはまったく喜ばしくない数字にしかならない。

もちろん数字がすべてではないけど、そろそろ人に伝わるような成果を出すことをした方がいいと思う。
ということで、2つ目の目標はこれにした。

本を読む

 これは2つ目のためのインプットにも関連しそうだけど、とにかく本を読まなさすぎる。詰み本が多すぎるのをいい加減払拭しなければならないと思った。
わたしの尊敬する上司たちや、エンジニアや仲間たちは、すごく本を読んでいる傾向にありそう(これは技術書とは限らない。魅力的なエンジニアたちはあらゆる本を読んでいて、映画なども観る人達が周りに多い)
 また、昨年からABDという読書会を少しずつおこなっていて、一人でも読書するブースターになりそう。
 ということで、ABDをブースターとして、ファクトフルネスを読んでいる。
 さらにちゃんと一年で読んだものを可視化しようと思って、アカウント登録しただけになっていたブクログも再開することにした。
今読んでいるのは、ファクトフルネスと実践アジャイルテスト。ちょっとJSTQBアジャイルシラバスも読まないといけない。

本を読むためのざっくりとしたルール

  • 可視化するために読書サービス(今回はブクログにした)を使う
  • 読むジャンルは問わない。できるだけジャンルを混ぜたい
  • 本は前に読んだものでもよいことにする
  • 読ん(でいる)だ本は、ブクログに感想をメモする
  • できるだけ3日で読む(新しく読む場合)
  • 読みかけでも他の本も読んでよい(一冊読破はルール化にしない)

成果としては、1番目のは、どこかでブログ書くか登壇すれば成果になるはずで
2番目はおそらくスライドおよび比較的公式なブログで成果が出せるはずで
3番目はブクログが成果になるはず。

ということで、一年ちゃんとまじめに生きようと思います。

2019年ふりかえり

恒例の今年ふりかえりエントリー

今年のブログはこれをあわせて27本らしい。(会社でも1つ書いたから28かな)

連投のものもあるので、軒並み例年通りっぽい。

月ごとのふりかえり

1月

ブログ2本

ファシリテーション勉強会って1月だったのか。。春くらいかと思っていた。
このエントリーではファシリテーション力が会社で使う機会がないって書いてあるんだけど
このあと、めちゃくちゃ必要になっているというね。いつどこで役に立つかわからんもんだね。

そして、わたしの大好きなメルチャリもまだ使って1年経ってなかった。
これがないと市内を快適に移動できない。
このときも、まだメルチャリの会社が変わることになるとは思わなかった。

2月

ブログ3本。登壇1本。

ブログも登壇も会社関連のことですね。
そうかー、てったんが来てくださったのも遠い昔の感じみがある。

AQA POP TALKの予定は全くないけど、
また福岡で開発とかQAとかのイベントができるといいなぁ(いいなぁ

そして、プロジェクト賞とったときのお話しも過去の栄光にならないように
価値出して行きたさ(今とっても迷走中)

3月

ブログ3本。登壇2つ。

3月はJaSST'19 Tokyoの話ばっかりになってます。
とくにチュートリアルは1月くらいから準備を始めていて、
パートナーに頼りっきりだったけど、よい経験になりました。

個人的には、JaSST後にメンター兼マネージャーとチームが離れることがわかって
夜くっそ泣いたのは(よいかどうかわからんけど)思い出。
わたし、つよく、生きる。

4月

ブログ1本。

ここで、理事をやってみることを決めたって感じのエントリーです(実は)
そして、あわせて、PTAの役員と、こども会の役員も兼務して
自治会は1回目で無理だって思って、夫に投げちゃったであろう月でもあります(ひどい)

5月

ブログ1本

めずらしく読書をしていた。
わたしはひどい詰本族でなかなか読破できないんですけど、
ちゃんと本読んでましたね。

もう1つ読んでいる記憶があるので、今年はちゃんと?最後まで読んでいる本があるのか。すごい。

この月は、このあとでてくるであろう教科書の執筆と、PTAの広報誌作成で
プレッシャーがピークで、突発性難聴みたいなのを発症してました。
初めての経験で、耳の中が海の中みたいでした。
すぐなおってよかった。(今はすこぶる健康です)

6月

ブログ7本。

今年で一番エントリー数が多いのですが、これは言わずもがなWACATEのエントリーを連投したから。 そして肝心のワークセッションがばっちり抜けてますね。完全に優先度間違ってる、わたし。
(そして当然のように、もう書けない・・・ごめんなさい。)

この月に過呼吸的なのを起こしてしまって、体調的にはピークに悪かったかもしれないです。
あんまり記憶ないけど、今は元気です(なんならこのときも元気だったと思う)
WACATEきっと4年ぶりとかに参加したけど(若くない枠は初めて)やっぱりいついってもよい場所だと思う。

7月

ブログ3本+会社の1本。登壇1本

WACATEのも書いていた。
会社の初めて書いたけど、めちゃくちゃ緊張した。会社のエンジニアブログって緊張する。
よかった、ここにふざけたこと書いてもゆるされるブログがあって(というわりに、会社のブログも十分にゆるくてそわそわしてた)

あと、毎年恒例のテスト勉強会も恒例で盛況でありがたい限りです。
自分でも忘れてたけど、その割によそで需要の高まりをまだ感じていない。

8月

何も書いていないし、記憶もない。

9月

ブログ1本。共著教科書。

今の会社でのふりかえり。あと、ずっと重くのしかかってきた初めての本が出版された月。
気持ち的にとても大変だったけど、もっとがんばれたんじゃないの?っていつまでたっても自分を責めると思う。

10月

ブログ2本

教科書が出版されたこともあってのエントリーがあった。教科書の買いなおしって(しかも認定試験のなら)中々しないかなって思うけど
やっぱり今回のは前回よりパワーアップしていると思う。

それと、ゆるい勉強会(というよりほんとにおいしくティータイムをすごす)がノリと勢いで作ってくれたので
ゆるく参加できてとてもうれしい。
(完全に趣旨もお店も東京の人たちをリスペクトしつつパクっているけど、そゆノリが許される優しい世界)
来月もあるから楽しみ♡

11月

ブログ0件。JaSST'19 Kyushu

JaSSTのミーティングしたり、広報誌を作ったりしていたんだと思う。 今回は広報誌ラフスケッチもあったし、スケジュールに余裕もあったから余裕だった。

12月

ブログ3本。勉強会(読書会)のファシリ2つ。

長年続けていた委員会の引退宣言と(ほんとに引退するのか?どきどき)、
そろそろ自分開催の勉強会もまたゆるくはじめようと思って、ABDの読書会をはじめてみた。について書いた。
それと、毎年恒例のアドベントカレンダー

あいかわらず、わたしが技術というか開発とかテストとかのことを書こうとすると けったいなものが書かれるっぽい。 他の人にもわかってもらうには、もっと勉強したり、伝える努力をしないとだめなんだろうなって思う。

来年のわたしは?

去年のエントリーに海外進出をあげていたけど、残念ながらできませんでした。 来年は海外にでているかはわかんないけど、ちょっと国際的になっているといいなって思います。

それと、長年続けてきた委員をやめるつもりで、その代わり、すでに理事的なこととか、
ちょっと新しい委員とか、ちょっとしたプロジェクトとか、
ABDとかの、自分でちゃんと勉強する会とかやってこっかなって思っています。

いいんちょを引退することにした

いいんちょエントリーもこれで5回くらいになるらしい。
と思ったら6回目でした。そうk・・・6年も(共同いれて)委員長てやってきたのか

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

underscore42rina.hatenablog.com

今年のJaSST九州

言わずもがなだけど、今年も大盛会でおわりました。
関係各社のみなさま、ほんとに今年もありがとうございました。

本会については、みなさまがよきブログエントリーを書いてくださっているので、ご覧ください。
わたしは懇親会でチームについていろいろ相談したり
ことばについて質問したりしました。

今年の委員会

今年は共同実行委員長をはじめ、プログラム委員長(って名目もしや出てないのでは・・・今回の一番の立役者です)や
若い委員が主軸となって動いていました。
わたしはほんとに何もやってない年になりました。委員会に参加したくらいの記憶しかありません。
あとお菓子の買い出しと経費精算の監督。

もういいかげん引退したほうがよいと思う

準備の途中から 結構決めていたのですけど、今度こそ委員を引退しようと思っていました。
ほんとは去年くらいから委員長は次にうつるべきだと思っていたので、ほんとはそこで引退したほうがよかったかもしれないです。

わたしの発言の声が大きくなった

委員会ミーティングのときに、私の発言がキッカケで、何度か場の雰囲気が悪くなりました(もしかしたら周りは気にしてないかもだけど、自分はそう感じました)
声の大きい人は、いることで良いことはあんまりないです。助言が命令に感じるなら(しかも自分自身で)その行動を正すか止めた方がいいです。
やめる=発言しない なら、いない方がいいです。

あたらしい雰囲気は大事にした方がいいと思う

今のチームは、開発エンジニアがチームにいたり、委員それぞれが個別に社外活動にコミットしている人たちが増えて
今までとまた雰囲気が(もちろんいい意味で)変わってきているかなって思っています。
それを近くで支えるとかってできるでもいいんでしょうけど、
普通に自走できる人たちなので、新しいチームでさらに爆走していくのを楽しみにしています。

・・・といっても、やっぱりJaSST九州を長年やってきたので、さみしいなぁ。

JaSST九州とわたし

最初にJaSSTに参加したのがJaSST'12 Kyushuで
13年から実行委員をやって(それもなんかぶっ飛ばして働いて)
それからはずっと共同実行委員長と実行委員長をやっていて
色んな方にお世話になって助けられてすごしてきたんだなぁってあらためておもいます。

ていうか、来年から普通に参加できるのか!最高かよ!

引退したらどうするの?

ひとまず、委員長はせずに、委員としても外れる予定です。アドバイザーはリクエストがあればしたいです。
(この辺はわたしがちゃんと残作業をクリアにできるかにもよるかもしれない)

ってことで、他は以下。

JaSST全体のお手伝いをしたい

今年からJaSST全体の担当理事になりました。
現在も少しずつではありますが、JaSST全体でのお手伝いとかをしています。

JaSSTというシンポジウムには、全国に数百人の実行委員がいます。
また15年以上の歴史もあります。
これらをすべてボランティアという形で運営しています。

そのため、まだまだできることがあったり、見えていない困っていることがあったり
せっかくの組織が活かしきれていないこともあったりするかもしれません。

今後はそういうことについて、カイゼンとかお手伝いとかできるといいなぁと思っています。

初心にかえる

最近は全然勉強会とかできてないし、登壇もできてないし、普通に勉強できてないなぁと思います。
もっかい最初からちっちゃく何かはじめられたらいいなぁってお気持ちです。
(それもあってABDはじめました。たのしい❤️

underscore42rina.hatenablog.com

シラバスをABDでやるとおもしろかったよ。って話

すっごく久しぶりに自分で自分がやりたいゆるい勉強会をやりました。

q-te.connpass.com

ABDについては↓を参考にしてください(当日もしました) kuranuki.sonicgarden.jp

なんでABD?

一度ABDの勉強会(しかもオンライン)に参加してみて、
積本常習犯のわたしには すごくあっているなーと思っていました。

それで、自分が読めていない本とかをABDでやってみるとよさそうだなって思って
今回やってみました。

なんでシラバス

ABDをするには、参加者が本を所持する必要があります。
その点、JSTQBシラバスはPDFが無料公開されているので、インターネットに接続すればだれでも無料で手に入ります。

仕事でAgileに関わることが増えたので、今回アジャイルシラバスをテーマにしました。

当日どうだった?

当日は3人しか集まらず、開催してよいか不安でしたが、結果3人でも十分勉強になりました。
ABDは私が一度したことがある程度でしたが、それなりにできたかなって思います。

ABDのよい点は色々ありますが、用意はほとんど必要ないです。
ファシリテーターが用意するもの ]

- 紙(今回はA4用紙にしました。6枚×参加人数分)  
- ペン(太目)人数分  
- 紙をとめるテープ(マグネットでもよかったな)  
- ふせん  
- 練習用の概要を印刷した紙  

ABDのファシリテート用の資料を作りかけたんですが、前述のサイトにABDのやり方サンプルが丁寧に書いてあったので
そちらのサイトを見せながら説明しました。

なので、事前準備はほぼなしでした!

ここがよかった:ABD

  • 読む、要点をまとめる、発表する、ディスカッションできる とアウトプットの機会が短時間にたくさんできた

 1時間半の間に、全員でこれらをするのですが、時間全然足りないし、集中しないといけない時間があってとっても疲れますが
 単に一人で読むより、発表することにより、一人で読むより短時間で理解が深まったと全員が体感できました。
 人が説明することによって、知っていた話や、知らなかった話を共有することができ、その後質問やディスカッションをすることで
 シラバスに書いていないような話も知ることができてよかった。

  • 3人と少人数だったけど、その分全員が共有も話も平等にできた

 人数が少なかった分、全部はまったくできなかったが、3人が同じだけ話したり、全員で共有することができたのがよかった。
 ファシリテーターも慣れていない(ABDファシリは初めてするし)けど、割とスムーズにできたと思う。人数が多かったらもっとわたわたしたかも。

ここがよかった:シラバス

  • アジャイル活動でのテスト担当者のありかたがわかった

 あれ?こんなところまでテスト担当者は入り込んでいいんだ。という気付きがあったのが大きい。
 また、テスト計画の内容なども記載されていて、明日から試してみたいなと思える内容も書いてありました。

  • アジャイルの説明も多く、あらためて勉強することができた

 アジャイルの説明は聞き覚えがあるものも多いのですが、今だからわかることとか
 今課題だと思っていたことのヒントが書いてあったのでよかったです。ちょっともうちょっとちゃんと読んでみよう

次回のABD会は?

来年早々にできたらいいなと思います。
今回1章がおわったので、人数と参加者層によりますが、できれば2章を中心にやりたいです。

探索的テスターがUserstoryを作る話と、UserStoryMappingていいね。って話。

qiita.com

の7日目です。

昨日は tononoちゃんのエントリーでした。

なぜ、こう思ったのか忘れてしまったんですが、
自らお題を決めてしまったので、このタイトルで記事を書きます。

探索的テスターについて

わたしは、テストやQA、品質とかに関わるお仕事を専門として11年くらいになります。
その中でも、開発に入り込んで、「いかに短く」「いかにお客さまに価値のあるものを」「エンジニアにフィードバックするか」
を重要視してテスト実施をしていたため、いわゆる「探索的テスター」になっていました。
(逆に、事前に「テスト設計をする」とか「下積みテスターとして網羅的にテストを行う」とか「エビデンスを残すことを重視する」
といったことをほぼやってこなかったために、できないこともたくさんあります)

UserStoryとは

みてのとおり、ユーザーの物語です。

構成としては、次のようなフォーマットで作成したりします

  • WHO/WHAT/WHYで構成される
  • Acceptance Criteriaがある

さっそく作ってみます。

UserStory1:川へいく
 おばあさんは汚れ物をもって川にいきます。なぜならば、洗濯をしたいからです。  

UserStory2:桃を拾う
  おばあさんは川から流れてきた桃を拾います。なぜならば、とても大きな桃は珍しいですし、手に入ることがなくて興味が湧いたからです。  
 
 UserStory3:桃を切る
    おばあさんは桃を切ります。 なぜならば、 持って帰っておじいさんと食べたかったからです。  
    
  UserStory4:きびだんごを作る
    おばあさんはきびだんごを作ります。なぜならば、桃太郎の旅支度に持たせたいからです。  

はい。桃太郎です。

f:id:underscore42rina:20191204210900p:plain

では、これらにAcceptance Criteriaを入れてみます。

UserStory1
 おばあさんは汚れ物をもって川にいきます。なぜならば、洗濯をしたいからです。  
 Acceptance Criteria  
    川の水は洗濯可能な純度であること  
    川の水は洗濯可能なスピードであること  
    天候が洗濯可能であること  
    自宅から川までの距離が適切であること  

UserStory2  
  おばあさんは川から流れてきた桃を拾います。なぜならば、とても大きな桃は珍しいですし、手に入ることがなくて興味が湧いたからです。  
 Acceptance Criteria  
    川の水は桃を流せる程度の水量・スピードであること  
    桃の大きさが適切であること  
     
 UserStory3
    おばあさんは桃を切ります。 なぜならば、 持って帰っておじいさんと食べたかったからです。  
 Acceptance Criteria  
    桃は包丁で切れる程度の硬度であること  

  UserStory4:きびだんごを作る  
    おばあさんはきびだんごを作ります。なぜならば、桃太郎の旅支度に持たせたいからです。  
  Acceptance Criteria  
    きびだんごの材料は適量であること  
    きびだんごの日持ちが一定期間であること  
    きびだんごは一定以上の味であること  

思いのままに書いたので違うかもしれないです。(きびだんごとかめちゃくちゃ怪しい)
途中で、これはDoneの定義にすべきかもしれないって思うのもありましたが
きっと来年のワタシが答えを持ってきてくれます。

探索的テスターがAcceptanceCriteriaに思いを馳せる

WHYにも思いを馳せるんですけど、おばあさんって重いのもつのが好きなんでしょうか?
というか、桃を持ったときに洗濯物はどうしたんでしょうね。
わたしスタイルの探索的テスターは、妄想をよくします。妄想でテストをします。

どんぶらこの水量やスピードってどんな感じなんでしょうか。
不思議に思ったところはAcceptanceCriteriaないしは、その先のDoneの定義になるかもしれません。
妄想がはかどります。

これを優先度づけしてみます

この3つのUserStoryの優先度をつけてみます。
これを重要だったり、まず価値を届けたいという順にしました。

 UserStory3:桃を切る  
 UserStory4:きびだんごを作る  
 UserStory2:桃を拾う  
 UserStory1:川へいく  

桃太郎でてきませんけど、桃を切るの大事かなって思いました。
次にきびだんごは一つの大事なプレゼンスなので、次に入れました。
そして、桃を拾うところと川へ行くところです。補足っぽいイメージなので、最後にしてみました。

こうして順番を入れ替えていくと、話しがわからなくなってきました。

ここで、そうだ。これを使おうって思ったのが
UserStoryMappingです。

UserStoryMapping

UserStoryMappingはUserStoryを配置してみるものです(雑な説明)

さきほどのUserStoryですが、実は2つのシーン(もしかしたら3つのシーン)がありました。

シーン1:おばあさんが桃を発見して桃太郎がでてくる  
シーン2:桃太郎が鬼退治するのを送り出すためにおばあさんが旅支度をする  

それぞれのシーンでUserStoryを配置します。

シーン1:おばあさんが桃を発見して桃太郎がでてくる  
 UserStory1:川へいく  
 UserStory2:桃を拾う  
 UserStory3:桃を切る  

f:id:underscore42rina:20191202161736p:plain

シーン2:桃太郎が鬼退治するのを送り出すためにおばあさんが旅支度をする  
 UserStory4:きびだんごを作る  

f:id:underscore42rina:20191202161758p:plain

ほんとうはもっとUserStoryがあると思うんですけど、こんな感じになるはず。
そして、これで あらすじはわかるようになって、それぞれのUserStoryはバラバラになっても大丈夫になります。

あってよかったUserStoryMapping
(この理解がどれくらいあっているか、危険かもしれないことかわかっていない)

探索的テスターがuserstoryを作ろうとするとどうなるか

探索的テスターがUserstoryを作ろうとすると、
 ほんとにWHYがWHYなのか考えはじめる
 AcceptanceCriteriaっを本気で考えはじめる
おそらくUserStoryがたくさんできそう。
たくさんできてしまったUserStoryはUserStoryMappingしちゃうと、迷子にならなくていいよ。

・・・これは探索的かどうか関係あったのかな🤔

そもそも探索的テストって

基本的に動かしながらテストを設計して実行してって考えてやっていくスタイルなんですよね。
でもそれを、動かないもの(=お話)に対して、あれこれ考えるって
ふつうの設計(テストですらないのではないかと)なのかなって思いました。

ただ、自分を探索的テスターだと名乗った場合に
別に動いていようと、動いてなかろうと、思考がかわるわけではないんですよね。
動いてくれるほうがヒントがどんどんでてくるので、より確実であったり思考の向き先がそれに引きづられたり
絞り込まれたり、横道にそれたりするだけで
その子たちが出てこないだけで、「あぁかもしれない」「こうかもしれない」は普通にでてくると思うのです。

その普通にでてくるは、テスト設計をしている方にとってはとても普通のことだと思うので
結局一緒じゃん。って思ったのでした。

という、いまさらながらの気付き。

こんなわたしと

Agileなテストの読書会をしませんか?

九州ソフトウェアテスト勉強会のABD Vol.1「アジャイルテスト担当者シラバス その1」というみんなで読む会を開催します。

参加者が4人くらいだったら、パンケーキ食べに行くと思います。

さて明日のアドベントカレンダーは?

まつりちゃんのJaSST九州のお話しのようです。とっても楽しみですね!

メニューをレビューしてフィードバックしよう #テストティーパーティ―

今日はこちらに参加していました

connpass.com

これはこれで、JSTQBの話をしたり、美味しく楽しくお話ししていたんですけど、
ちょっと酒が足りねぇと結局2次会で飲みにいき
そこで後半すごく盛りあがったので、そのお話しを。

最初に載せたメニューの画像をみて、レビューして。フィードバックして。というお題です。
ちょっと考えてみてください。

何かこうするともっといいよね。とか、ここよく考えているよね。って出てきましたか?

ここから、二人で色んな話をしたなかで興味深かったものをいくつかご紹介します。

ビールのメーカーは書くべきなのか

ビールといえば、どこのメーカーのビールか気になります。
このお店のビールのメーカーをわざわざ聞かなければわからない、そして聞いてから好きなメーカーではないとがっかりする。
という話がでました。

お店に複数種類置いてある場合はもちろん書いて欲しいですが、
お店に一種類しかない場合、わざわざ書かなくてよい情報ではないか と話しました。

このメニューはA4用紙で、そこに載せられる情報は限られています。

このお店にきたお客さまは、生かどうか、瓶がえらべるならどちらかを選ぶと思いますが
ビールが飲みたいけど、キリンだったらやめる ということは、あんまりないかなと思ったからです。
(でも、生がアサヒで、瓶がキリンだったら、メーカーで選択しなおすかも・・・)

ですので、メニューに載せる優先度の高い項目ではないと判断してんではないかと思いました。
もしかしたら、日によってメーカーが変わるのかもしれないですね。

ノンアルコールビールのありか

ノンアルコールビールの配置を見てみます。
縦書きのメニューの場合、目線は右上→右下→左上→左下 の順に動きます。

一番最初に頼まれることが多いビールが右上なのはすごく納得するのですが、ノンアルコールビールはこの位置でよいのでしょうか?

このお店は、繁華街ではなく、ベッドタウンの駅前にある居酒屋でした。
この町では、駅の駐車場に車を置いて、電車で通勤人も多いです。

そのため、帰りに一杯といっても飲めないお客さまが繁華街に比べて多いので、この配置にしているんじゃないかな?
と話しました。
これは、この場で考えないと、オフィスで考えてもでてこない発想だなーと思い、面白かったです。

みんな、ビール大好きなんですね。
(さらに、ツイートで教えてもらったのですが、シャンディガフの配置もビール関連で寄せてるのかしら?という話も興味深いです)

チューハイの話

このメニューはカテゴリーに金額が書いてあるものと、もう一つ詳細なメニューに金額が書いてあります。
チューハイの場合、すべて同じ値段なので、カテゴリーであろう「チューハイ」に金額が書いてあるのだと思っていました。

ですが、チューハイという(XXチューハイ)ではない飲み物があると教えてもらいました。
知らなかった。
この場合、ただのチューハイはメニューとして存在するのか、「チューハイ」はメニューなのかカテゴリー名かわからない。
という話をしました。

たしかにー

もしチューハイってメニューがあった場合は、どういう表示がわかりやすいのだろう。。。

日本酒の話

このメニューには日本酒がでてきません。
このお店には「飲み比べセット」という日本酒メニューがあり、
別にある日本酒メニューから3品選ぶことができました。

私はこの日本酒飲み比べセットを頼んだわけですが、
普通に好きな日本酒だけ飲みたい人が、たどり着く経路が用意されていません。 なので、メニューに日本酒も記載したた方がよいのではないかと話しました。

・このメニュー
・日本酒飲み比べセット と書かれた特別メニュー(メニューってか飲み比べという文字と金額が書かれているだけのメニュー)
・日本酒のメニュー(10種類くらいカード式に案内が書いてある。ここに一合の金額も書かれている)←このメニューにたどり着けない

ではどうするべきか。

そもそも、お店として飲み比べメニューを推したいのかな?と思いましたが、 わたしであったら、 このメニューにも「日本酒があること」と「メニューは店員まで」という2行を追加したいなって思いました。

その場所についても、あーだこーだ言って、配置だけなら、ハイボールとチューハイの幅を調整して、
その後ろになんとか2行つけたい・・・て感じにしました(ベストな配置かわからない)
ほんとに日本酒のメニューを載せるべきかもわからない

カクテルを組み合わせ条件表記にしない理由(もちろん二人の妄想)

日本酒の配置の話から出てきた話。そもそもカクテルが冗長すぎではないか。という話がありました。
このお店は うどん居酒屋(ウエストではない)で、カクテルという甘い飲み物は頼まれにくいのではないか?という懸念事項もありました。

たしかに、これであれば
シャンディガフ
・ファジーネーブル
・カシス
・ピーチ
(オレンジ・ソーダ・ウーロン)

のようにまとめることもできます。

そこで、普段このお店に来ているお客さま層の話を思い出しました。
このお店では、仕事帰りに立ち寄ったサラリーマンや、近所で働いているガテン系が多いそうです。

・・・もしや、これを頼むのは、そういう人たち(男性としたら)その恋人などではないのか?と想像しました。
その場合、彼女ってメニューを組み合わせで頼むのは、話す言葉が増えてしまいます。
冗長でも、全メニュー書くことで「指さし」でメニューが注文できるのでは?という妄 想をしました。

そうか。組み合わせにしないことでうまれるよさもあるのだなと(妄想なのに)わかって面白かったです。

システムだとどうするか、お客さまが欲しいものは何か

上のような話は、実際のテストやレビュー時に必ずしもでないと思います。
むしろ、システムを作るのであれば、↓のような指摘をしてしまうかもしれません。
・このメニューのグルーピング(カテゴリー分け)は粒度がそろっていないのではないか
・全項目のメニューに金額をつけるべきではないか(公平性)
・文字が重なっていると金額の可読性が下がっているのではないか
・金額の文字の濃さや太さを 濃く、細くした方が可読性があがるのではないか
・文字そろえが可読性を下げていないか

ですが、お客さまとして見たときに、ビールか焼酎かというカテゴリーがわかれていれば
それ以上冗長なメニューの表示は必要ないですし、
金額も書いていないところは、同じ値段なんだな。と読み取れるのであれば、A4で納めるためにはすごくいい表示だと思いました。

結果、このメニューはいいメニューだと思う

以上の説明があり、このメニューはお客さまの行動をよく考えて作られたメニューなんだろうなと思いました。

最後に、では、これをさらに改善して お店の売り上げに貢献できる(=お客さまもリピーターになってもらう)ことを
このメニューで実現させるにはどうしたらいいだろう?って話を最後にしながら帰りました。

このメニュー談義は、以前友人ともしたのですが、すごく面白いです。(手書きがとくによいです)
わたしは、これに似た思考でテストやレビューをすうことが多いので
今回も学びもあり、とても楽しかったです。(そして、これは実際に指摘できる自信がないなって思いました)

今まではQAな人としかやってないのですが、これがビジネスインパクトを得意としたプロデューサーや、デザイナーだったときは
どんな話になるのかなと思うと、もっと楽しそうですね。