テストする人。

ソフトウェアテストってわかんない。ソフトウェアテスタ-による、ゆるゆるブログ。

リモートワークを支えている環境

リモートワークについて、過去にもいくつか記事を書いています。

現在のわたしのリモートワーク

今働いている会社は原則オフィス出社なのですが、
時々理由がある場合にリモートワークをしています。(これをWFHといいます。かっこいい)

またそれ以外に副業であったり、社外活動の多くをリモートで活動しています。

今回はそれらをするのに大事な環境についてまとめます。

部屋

戸建ての一室を仕事部屋(いわゆる書斎)として使っています。4畳くらいの狭い部屋ですが、オフィスで考えると一人に与えられる広さとしてはかなり広いです。(戸建ての部屋としては狭いけど)
リフォームするときに仕事部屋として使う用途で考えていたので、クロスとかも好き勝手にしています。
2面がチョーク対応のクロスなので、壁に字を書くこともできます。

f:id:underscore42rina:20200212183203p:plain
カイゼン・ジャーニー読んだときに書いたやつ
子供の落書きと、前に書いたままのものが放置されています。(つまり現在使っていない)

仕事(社外活動なども含む)のときにしか使わない部屋なので、ON/OFFの切り替えに困ることはないです。
休みの日に立ち入らないレベルです・・・(といっても社外活動のミーティングとかで使うけど)

モニター

買った時期未定。たぶん2017年のいつかだと思います。
当時の会社の人に「縦型にできるモニターは(Excel使いには)いいぞ」と言われ、モニターの向きを変えられる24インチくらいのを使っています。
ちなみに、ほとんど縦にしたことはないです😅
某プロジェクトで一覧のデータとにらめっこするときに使ったけど、現在は横のまま利用しています。
経理業とかする人にはいいかも。

今は4Kで、もうちょっとサイズの大きいのがほしいです♡

ヘッドセット

買わねばと思い今に至ります。 リモートワークにオンラインミーティングは必要不可欠で、その際に基本的にイヤフォンをするようにしています。
現在私物のPCのマイクの調子が悪かったり、
ネットワーク(というよりWi-Fi?)の調子なのか相性が悪く試行錯誤中です。

現在、こんな組み合わせのパターンで使っています。

■PCとスマホの2台構成

  • 画面共有・カメラを使う場合:PC接続
  • 音声: iPhone: iPhone用の純正イヤフォン
  • 音声: スマホSONY WF-1000XM3:調子がいいときしかできない。なんらかノイズが入ることがある。外から接続したままのときにこの構成になることが多い。

■PCだけで完結

  • PC × SONY WF-1000XM3:かなり調子がいいときしかできない。なんらかノイズが入ることが多い。
  • 会社貸与のヘッドセット(会社のPCの場合)

基本PCとスマホの2台接続で音声とそれ以外で使うことが多いです・・・
有線は偉大。

椅子

バロンチェアを使っています。
これは、前職に転職する際に「フルリモートワークなので、きちんと投資せねば」と一念発起で購入しました。
まさかあんなに早く再転職するとは思わなかったのです。
でも、そうでもないとさすがに購入に踏み切れなかったと思うので、購入できてよかったです。

白フレームにしたのでかわいい。

前前職の副社長にお下がりをいただいたIKEAのダイニングテーブルを使っています。
ダイニングテーブルなのでめっちゃ大きいです。部屋の半分がテーブルです(まじで)
伸縮できるタイプなのですが、現在180cmくらいにして使ってます。
おかげで物を置過ぎています。
ミシンがけなどの作業デスクとしても重宝しています。

リモートワークとしては、こんなに大きくなくてよさそう。

インターネット環境

普通の光回線を使っています。 そして以下の構成にしています。

  • 1階 3GHz帯のWi-Fi
  • 2階(仕事部屋) 有線LAN 5GHz帯、3GHz帯のWi-Fi

これは、前職で仕事をしようとしたときに、1階にあるWi-Fiだけで、全く仕事にならず そくざに10mの有線Lanケーブルを購入。 現在のお仕事をするときに携帯も使うし、やっぱりWi-Fi強くしないと無理だ・・・ってなって 現在の構成にしています。 有線LanはWi-Fi機につないでいます。

もっとシュッとした構成にできると思うけど(有線ケーブル邪魔だし) まぁ安定しているのでいいかなってなってます。

有線は偉大。

飲み物

なにげに大事かなって思っています。
普段働いている会社のオフィスは飲み物がかなり充実していて
すべてフリードリンクです。
さらに、部活動という会社の仕組みで、コーヒーを淹れたり、紅茶(LUPICIAが多い)とか淹れているので
おいしいものを飲んでいると思います。

ですので、家でもできるだけコーヒーと紅茶は美味しいのがほしいなと思って
コーヒー豆(飲むときに挽いてる)とLUPICIAの紅茶はできるだけ用意するようにしています。

お部屋がせまいので、飲み物の香りが充満するのはQOLの高まりがあります。
数百円からできる贅沢なので とてもおすすめ。

その他

スピーカー

転職祝いでいただいた Alexaが音楽スピーカーとして活躍しています。
アレクサとしての機能つかってないなぁ・・・(Bluetoothスピーカー係)
作業BGMをスピーカーで聞けるのはありがたい。

備品

地味に無印とか、MoMaの雑貨入れとか買ってます。
かわいいものに囲まれる方が気分があがりますよね(それ以上に散らかっているのだけど)

おわりに

今回はお部屋にある物理的な環境についてまとめました。
もちろんリモートワークを支えるには、会社の協力であったり、技術的なものを使った環境整備も必要なのですが
ちょっとの工夫でよりリモートワークしやすい環境になればいいなと思います。

東京出張って何やってんの?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九州のお話しのようです。とっても楽しみですね!