こんにちは、とのの（@tonono2587）です。
JaSST Online Anemoneに参加してきました。
今回のテーマ：JaSST Online Anemone 参加レポート
2020-06-20 13:00~
大きく2部構成になっていて、それぞれオンラインならではの内容となっていました。
- オープニング
- ライブテスト分析前半（2スプリント）
- ライブテスト分析後半（2スプリント）
- OST(Open Space Technology)：20分ずつ3セッション
- クロージング
ライブテスト分析
かんばんリストというシステムを題材に、
マインドマップを使いながらペアでテスト分析する様子を視聴しました。
■前提条件
これらの前提のもと、深堀りしながら、次へ進みながら、課長にファシられながら、
振り返りと休憩をはさみつつテスト分析が進んでいきました。
スプリント1
- 仕様の全貌をみるため、仕様書目次を参考に枝をはやす
- かんばんリストシステムらしい機能に注目(タスク機能)
- タスク機能の表示系と操作系に分ける
重要と思うところからチェック(深堀り)
30分くらいやってみてつかめたこのスピード感で、どこまでどういう方向で進んでいく？ →今回は初回リリースなので全体を舐めるように見ておきたい。
- 途中「論理/物理」というキーワードが出たが、テストケースへ繋げづらいためかマインドマップから抜けてしまった
- 仕様書を見ながらやると転記したり細かい記述を追ってしまいがちだが、ふたりともあまり見すぎていなかったのでよい状態だった
- 創造的な感じがあった
MEMO
- リズムを大切にする。
- (どっかに書いてなかった？など)気になったところはいちいち確認せずに、とりあえず気になっている状態で残しておく
- 確認していると時間を取られてリズムが悪くなるため。
スプリント2
- タスクまわりがまだ検討をやり切っていない？
- かんばんリストとして重要な機能なので、このくらい深くてよい派
- その代わり他の機能を見るときはもっと浅くする
タスク機能の表示系をチェック/検討
はるすぷさんは仕様把握ができていて、見えていないものが見えている感じでよい
- プログラマ的視点をユーザー的視点にブレイクダウンできている
- 細かく深堀りしてしまうところをぱいんさんが止めてくれる
- 一応スプリント1で「全体を見る」という方針だったが、やりながら深堀り型へ切り替えていた
- どうして全体を見ずにこだわったか？
→ほかを浅く検討するより、いま検討している機能のほうが重要だと思った
→コアな機能を見切れていないためもっと考えたかった - 「QAする」ってなんだろう？
- 大きく2種、バグを見つけること(深く)。製品が提供する価値を保証すること(全体寄り)。
- どちらを目指して、どこに向かおうとしているか決めよう？
「全体を見る」、「全体」ってなんだろう？
開発者マインドが強くバグだし能力が高いため、どうしてもそっちに寄ってしまう
- システム共通としての観点は実は出ている：負荷/ユーザービリティ/クロスブラウザ
- 機能を軸にした気になりごとではなく、気になりごとを軸にしてみるのは？
MEMO
- 客観的に見ていると、「バグを見つけにいっている」という感じが強かった
- テストしバグを出すことで品質アップすること、へは繋がりそうな検討の仕方だなと思った
- テストがもう始まっている感じ…？
- バグを出す方向だと、手段としてのテストを検討している感じとは離れてしまうんだなと思った （なんかうまくいえてない。。）
スプリント3
- 前半でちりばめられていた非機能観点をまとめたい=全体で気にすること
- 粒度がバラバラなのである程度揃えたい
ユーザー管理や権限が気になる
マインドマップというツール上、各枝の抽象度がそれぞれ揃ってないといけないような気がしてしまう
挙げることを優先してとりあえず気にせず進んでみる
個別の機能の仕様を見ると仕様の細かいところが気になって、どういうテストをするのかが気になってしまう
- 「全体をみる」を意識したら使っている人のイメージや風景が見えてきた◎
- ではラストスプリントどうするか。何を達成するか
- 仕事において、達成感を得られる成果物はなんだろう？
- 残り時間でできそうな簡単なことがしたいのか？それともやるべきことがしたいのか？
- 今回はテスト分析なので、全体的なバランスを見たり決めたりしたいと思う
- ゴール：この範囲に関してはテスト分析ができたね、と思えること
MEMO
- 脳みそを転記する！
- このスプリントはハイパーライブ感あってめっちゃ楽しかった
- 残り時間でできそうなこと VS やったほうがいいこと
- やったほうがいいことやってくれ〜〜〜！って思いながら見ていた
- できる範囲で、やるべきことをやるという落とし所が見ているこちらでもわかった
- 進むべき方向の納得感があった
ラストスプリント4
- 前半で挙げたタスク機能まわりについて、表示系と操作系になっているため軸を変えたい
- 今回のゴールにとって要る/いらないを削除/追加していこう
- 上から削除/追加の検討をしたけど、ゴールするにあたって何が足りないか、またこれでよいのか2人の合意がとれた状態にしたい
- 5W1Hに沿って洗い出しとかよくやる
- うまく出ない。。
スプリント全体の振り返り
- はじめから全体を見ていたらマインドマップは広がらなそうだったので、全体と局所両方を見れたのがよかった。
- 具体的なところを掘り下げることで、全体へつなげることができた
- ものをつくっている感じがした！
ーーー
SEやエンジニアはテストに対してものづくりはあまり感じない
一方でテストエンジニアはテストにものづくりと同じ脳みそをつかっている
それが今回実感できたのがよかった
■次回やるとしたら気をつけたいこと
- 全体的にゴール設定を見失いがちなので、はじめに決めて進んでいきたい
- 業務システムだから、という濃淡がつけられなかったので改善したい
- かんばんリストだから/業務システムだから気をつけなきゃいけない部分の検討が足りてなかったかも
- ユーザーの目線に立ってテストする場合、その目線で濃淡をつけて検討したほうがいいのでは？
■よかったところなど
- 全体がだんだん見えてきたところがよかった
- 借りてきた形式(今回の5W1Hレビューとか)ではうまくいかず、自分たちが納得してしっくりくるかが大事
- ペア2人はお互いに敬意をもっていた
- そのため変に気遣いすぎるなどなく、効率のよい言葉でコミュニケーションが取れていた
MEMO
- はじめから間引いた結果が出てしまうのはよくないので、「わからない」「関係なさそう」などをあえて残すのは大事
- 残しつつ、しっくりくる納得できる形で解決させる必要がある
- しっくりいかない(Red)を納得(Green)にしてRefactorする
OST
テスト分析、設計、どうやって教育する？（とろ）
- テスト分析をきちんと習ったことがある人はほとんどいなそう。
- マインドマップを描いてもらってから、それをレビューする形で教えている
- 描いてもらうときはどうやって導入する？
→マインドマップ自体の説明を軽くしてから、自己紹介を題材に実際に描いてもらう。慣れてからステップアップする - 就活の企業分析の延長で、担当製品の企業を分析してもらったらうまくいった
- 趣味を整理して分析してもらったら結構よかった
- 好きなこと、身近なことからはじめてもらうと思考が広がりやすく、とっつきやすい
- やり方に正解はないから、やりやすいところから慣れてもらうのがよさそう！
- とはいえ急に「好きなもの」とかは聞きにくいので、チームビルディングを装ってすすめるのよさそう
MEMO
理想として分析のやり方や設計技法などを直接伝える/教えることをイメージしていたけれど、
慣れてから、だんだん本当にわかってほしいことへ繋げていくほうがうまくいきそうだと思いました。
テスト分析自体にも明確な「正解はない」というのはたしかに…
それなら正しい教え方なんてないのもそのとおりだなー
ほかのセッションはだいぶ力尽きてしまいあまりがっつり参加できませんでした(T_T)
全体の感想
時間で切ってこまめに振り返りがあったため、状況が見えて話が入ってきやすかったと感じました。
話が入ってきたこと、マインドマップや相談内容を聞きながら思考を追うことで
自分もやっているようなライブ感がありました。
一緒にめちゃくちゃ疲れました
ライブを体感して思ったのは、仕事でのレビューや検討は思考の結果をみることが多く、
「思考中」から時間が経ったものを見ていたためにすり合わせコストが高くなっているのかなと思いました。
「思考中」そのものや、思考から時間が短いもの(考えの範囲が狭いもの/まとまりが大きすぎないもの/小さい単位)
の段階で認識合わせするようにすれば、結果が大きく逸れてつらくなるようなことは減るのかなと思いました。
とはいえどこで切るかとか、あまり頻度多すぎてもとか、そんな時間取れないとか
いい塩梅にするのもまた大変そうだな…
暗黙知がテーマということで、なかなか見れないものを見れて/体感できて刺激的な一日となりました。
お疲れさまでした
