5/26(金)に行われたJaSST'23 Tohokuにオンラインで参加してきました。
www.jasst.jp
今年のテーマは「アジャイルとテストと私たち ～明日「アジャイル」と言われたときに困らないためのヒント～」です。基調講演やtohokuお馴染みのワークまで、アジャイルについて色々な角度から話を聞けたり模擬体験ができました。
「アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発」
川口 恭伸 氏（YesNoBut／アギレルゴコンサルティング）
ユーザーストーリーマッピング
こちらの本の話です。
発表資料はこちら
- アラン・クーパー
- ペルソナの提唱者
- ユーザーストーリーマッピングの序文を書いた
「開発とデザインには共通の言葉が欠けている＝Jeff Pattonは二つの立場をつなぐ」
- Vacation Photo 共有知的なもの
- 図とかをの共有知がある前提の上で共有知を思い出すためのトリガーとして付箋を書く
- 付箋などを使いながら会話する。インタラクティブでエネルギーにあふれたもの
- みんなで一緒に地図を描き、共通理解を作る
- 地図は全体像をとらえられる、詳細も必ずリンクされている
- やり方の種類
- 計画実行型 科学的計画法
- 自己責任 お金があると人は利己的になりやすい
- 自己組織化 意欲に満ちた人々を集めて計画する
- 全員がそれぞれに、この場所にいることを選択している
Q. 実際のプロジェクトでは人の入れ替わりが激しい場合があると思いますが、その場合のストーリーの共有はどのように行うのでしょうか
A. できるだけ変えないようにする。Long Stable Team. 変更したら計測できない
定期的な配置転換してたらテスラには勝てないと思います
- ストーリーのやり方
- 時系列でチケットを並べる
- 1stリリースでやることを絞る。削れば削るほどリリースできる可能性は上がる（期間内にやることを詰め込まない方がいい）
- ウォークスルー：ユーザーの立場に立って使えるかどうか試してみる
- 全体像と詳細を行ったり来たりする。たくさん話す、話し合うきっかけ
- 0章（Jeff Pattonの言いたいこと）
- ストーリーを使う目的はもっといいストーリーを書くことではない
- 製品開発の目標は製品を作ることではない（作って終わりではなく、お客さんがよかったと思うこと
- フォーマット（ユーザーストーリーのカード）
- 誰がなぜ必要なのかを書く
- プロダクトバックログ
- 全体像は別に作っておく（全体像を見失いやすいので）
- 機能について会話するとき
- 誰のためのものか
- 現状ではどうなっていて、リリースによってどう変わるか
感想
ユーザーストーリーマッピングがどういう理由で始まったか、どうして必要なのかを分かりやすく説明してもらえてよかったです。
「ワークやります」からの、計画実行型、自己責任、自己組織化の説明への繋ぎに引き込まれました。オンライン参加でしたが、会場参加だったらまんまと誘導に引っ掛かった自信があります。
「インスプリントにおけるQAの取り組みとハーモナイゼーション」
長田 亮介さん（freee）
インスプリントでの取り組み
- Ready条件
- 開発チケットやQAチケットのDoneの定義（開発Doneが必ずしもQA開始可能と限らないので誰がどこまでやるか認識揃えておく）
- MVP特定
- 要件レベルで指摘していく
- リスク洗い出し会
- 関係者をできるかぎり巻き込んでリスク洗い出し
- プロダクトバックログリファインメント
- スプリントプランニング
- QAのゴールの設定
- インスプリント
- スプリントレビュー
- スプリントレトロスペクティブ
ハーモナイゼイション
- debug API
- ここまで来るまでには、しっかりQAし続けたり、APIレベルでレビュー指摘をあげたりなどの地道な積み重ねがあった
- それこそ最初の頃はあまりQAの話を聞いてもらえないという時期もあった
感想
開発にQAが入り込んでテスト活動してるのが素敵でした。QA用のAPIを開発してもらえる開発との関係性を作るまでの地道な努力もすごいなと思います。QAの疑問まとめシートは自分のところでも似たようなことはやっていますが、チームで話す時間はとってなかったので真似させてもらおうと思います。
「スクラムチームにアウトスプリントで関わるテスターの取り組み事例」
大平 祐介さん（JaSST Tohoku 実行委員会）
※アウトスプリント この講演では別チームからスクラムチームに関わりスプリント外でテストしている
- 担当しているシステム
- チームのリリース戦略
- トランクベース開発
- ショートトレイン：1スプリントで完結する機能改善
- ロングトレイン：顧客影響の大きい、複数スプリントのにまたがる機能改善
- 意識している2つのこと
- プロダクト品質のシェルパ
- いいチームでいたい。「いいプロダクトはいいチームから」
- スプリントプランニング
- スプリントレビューで何を見せたいかをメンバー全員で認識を合わせる
- デイリー
- エンジニアがテスト設計、実施するためのガイド、E2Eのレビューなどなど
- スプリントレビューの準備
- メンバー全員でプランニングで決めた欲しいフィードバックからアジェンダを作る
- スプリントレビューのFB郷友会
- レビューで感じた雰囲気の共有、フィードバックからの改善を考える
- ふりかえり
- 積極的にチームのいいところを話す、困ってること、気になっていること
- コミュニケーション
- メンバー全員と1on1、飲み会など
- テスト設計&実施（メイン業務）
- ユースケース、負荷テスト、SLO、マニュアルテスト、バグバッシュetc
- メンバーと勉強会
- チームビルディング
- ドラッカー風エキササイズ
- プロダクト品質はみんなで向き合うと楽しい
- そのためにプロセス品質（チームの品質）をよくする
- がっつりテスト以外にも、いろいろやれることはあるかも
感想
意識している2つのことで上げられていた「プロダクト品質のシェルパ」「いいプロダクトはいいチームから」がよくわかる講演でした。コミュニケーションが生まれるよう仕組みづくりを楽しくされてるのがすごいと思います
「Struggling with Agile Testing, in Rakuten」
半谷 充生さん、中村 祐輔さん（楽天グループ）
- サービス：R Messe
- 半年でリリースできた
- とある日、メール誤送信のバグが発生
- 開発案件を全部止め、UnitTestを書く
- トラブル減、リードタイプ伸びる、リリース頻度減
- ローパフォーマー（LeanとDevOpsの科学）
- DevOpsのテストのような活動をしたいとQAに相談
- 課題
- QAは独立した組織、各サービスからテストの依頼が来る
- 提案
- ドメインナレッジを融資、開発・PdMと一緒に品質を向上させることができる人を置く
- 採用活動
- テストを自分で設計・実行できる。コミュニケーションが取れる、エンジニア経験があるetc
- 攻めたサポートができるQAエンジニア
- ShiftLeft活動からスタート
- 仕様の検討段階からQAメンバーが入る
- 仕様の不明点を聞く、他サービスの情報のシェア
- 開発側のMTGに混ぜてもらう
- Daily Huddleへの参加、トラブルのふりかえり
- 仕様の検討段階からQAメンバーが入る
- 開発とより近い距離でありながら、従来のQAプロセスに乗せる
- QAから仕様不明点を確認することで認識合わせの機会になる
- テストエンジニアの強みを生かす
- 営業日・時間に合わせて応答メッセージを変える→テストエンジニアの組み合わせのナレッジ
- 3amigosの導入
- 役割分担 PdM、QA、DEV
- コミュニケーションをとる、フィードバック
- 開発段階での仕様・スケジュールに対する認識間違いが少なくなった
- 気軽に相談できる関係性の構築
- 役割分担 PdM、QA、DEV
感想
「推しQA」という言葉を流行らせたいです。開発のバックグラウンドを持つQAを採用してShift-Left活動しているのがいいなと思いました。組合せなどテストに関する知識を提供しているなどいい関係性ができているのも素敵だと思います。
ワーク
今年のメインワークは、「経路検索アプリがない世界で経路検索アプリをリリースするとしたら」というお題でユーザーストーリーマッピングを行いました。
参加者は4人程度のチームに分かれて、お題を進めていく形です。
ユーザーストーリーに使うチケットは実行委員によって既に用意されていました。オンラインの参加者はMiro*1を使って同じ付箋を見ながら話していきます。各チームはチケットの中から、1stリリースのコンセプトを達成するのに必要なMVP（Minimum Viable Product）、2ndリリースのコンセプトを達成するのに必要なMVP、をそれぞれ選んでいく形式で進めていきました。
感想
当初私のところの音声がうまく入らずチームのみなさんにご迷惑をおかけしました…。チャットとかも併用しつつサポートしてもらえてすごく助かりました（ユーザーストーリーマッピングのワークは練習とメインで2回できるようになってるたですが、1回目は音声いじっててあまり参加できてない…）
ユーザーストーリーマッピングは初めてやったのですが、MVPに絞るとかなりの機能がそぎ落とされることに驚きました。機能を入れる、入れないは付箋を見つつ議論していたので、基調講演で触れられていた「みんなで一緒に地図を描き、共通理解を作る」とはこのような感じかなと模擬体験できました。
他のチームの成果物も見られたのですが、リリースに最小限な機能ということで大きなずれはなかったものの、各チームで選んでる機能に少しずつ違いがあって面白かったです。
全体的な感想
オンラインでもオンサイトでも楽しめるように設計されていてありがたかったです。質問やリアルタイムの感想とかはDiscordでまとめてられてて、オンラインの参加者もみんなでワイワイやる感じが味わえました。
テーマである「アジャイルとテストと私たち ～明日「アジャイル」と言われたときに困らないためのヒント～」に沿って各講演やワークが進められ、「基調講演で言ってたこと、今ワークでやってるこのことかな？」みたいな繋がる感じもあってすごく楽しめました。
登壇者、実行委員、参加者のみなさま、ありがとうございました！
*1:アジャイル開発ツール用のテンプレートもある：https://miro.com/ja/agile/
