JaSST'23 Tohoku参加レポート - ロコガイドテックブログ

JaSST Tohoku 10周年

技術部・品質向上グループのきしけんです。5月26日に仙台市で開催されたソフトウェアテストシンポジウム2023東北(JaSST'23 Tohoku)へ参加してきたので、今回はそのレポートをお届けしたいと思います。発表資料や講演の詳しい概要はこちらの公式レポートからご覧ください。

JaSST'23 Tohokuとは
各講演について
ワークショップ
まとめ

JaSST'23 Tohokuとは

毎年5月から6月ごろに東北地方で開催されるソフトウェアテストのカンファレンスです。JaSSTは地方ごとに特色がありますが、JaSST Tohokuは参加者のワークショップを特徴の一つとしています。今回もオンライン、オフラインそれぞれでチームを作り、ワークショップを行いました。記事の後半で詳しく解説します。

各講演について

まずは基調講演と事例紹介のそれぞれのメモと感想を書いていきたいと思います。メモは当日話を聞きながら取ったものになるためやや雑多になっていますが、ご了承ください。個人的に気になったところは強調しています。

基調講演「アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発」

川口恭伸氏（YesNoBut／アギレルゴコンサルティング）

https://speakerdeck.com/kawaguti/userstorymapping

講演のメモ

オライリーから出版されているユーザーストーリーマッピングの本の話
ユーザーストーリーマッピングの本を監訳した、海外カンファレンスに行くかたわら図表を直したりしていた
ユーザーストーリーマッピング
- スクラムフェスでも講演したばかり
- Jeff Patton氏の提唱
- アジャイルにして人員を整理したらモチベーションが下がってしまうということがあった、アジャイルプロダクトマネジメント、マネジメントの知見を足していく
- Jeffさんとは2009年くらいにAgile Conferenceで出会った。Agile AXというトラックを見に行った。
- ユーザーストーリーマッピングのセッションはプロポーザルで落ちたが、OpenJamでゲリラ的にセッションを行なっていた。それをビデオに収めてYoutubeで公開して普及に寄与した。そんな縁がある本
Alan Cooperからの序文
- 「Visual Studioの父」
- デザインと開発が協力し合えば、怪物に命を吹き込むことができる
- プログラミングの言葉ではデザインの意向をうまく表現できず、デザインの言葉では開発の趣旨を表現できない。
- 両者の協調ワークショップを通じて共通理解を作る。
- 言葉の上では一致しているが、各思い浮かべているものが違う → 会話だけでなく図表を使って共通理解を作っていく
- 共有知を思い出すために付箋を使う
- 「あなたたちの共通理解はドキュメントに含まれていない細部をたくさん含んでいる」「場を共有して会話をする」
- 付箋を駆使してみんなで一緒に地図を描き、共通理解になった地図の力を利用する
- 地図を共有しているから楽しみがある。ユーザーの頭の中に入った地図の力を活用して想像力を掻き立てる、裏をかく事もできる（ゼルダの伝説の例）
ここでスタッフが付箋を配り始める → ちょっと待って！
- 実行計画型
  - スタッフが付箋を配る
  - 誰かがちゃんと先に、検討して計画して指示をしておくべき
  - テイラー『科学的管理法』とT型フォード、徹底的な管理と大量生産によるコスト削減
- 自己責任型
  - 各々付箋を取りに行く
  - 自分でやってもらう、勝手にやるだろう、ボーナスは出す
  - 金銭インセンティブは利己性を高める
- 自己組織化
  - 近くにいる人の分まで付箋を取ってくる、順番に渡すなど創意工夫をする
  - そこにいる人を信用するところから始める
  - テスラの決算発表会、役員がフラットに自ら話している
- あなたたちは全員がそれぞれにこの場所に来ることを選択している。皆さんを信用している
Q 人の入れ替わりが激しい場合のストーリーの共有はどうすればいいか？
- A 人の入れ替わりをできるだけしないのがまず第一、同じチームでないと計測ができない。新しい人が来たらゼロベースにする。ベロシティを何%落とすとかはしない。別のチームと考える
ユーザーストーリーマッピングの実例
- 機能、ユーザーのやる事を整理していく
- ファーストリリースの機能を減らすほどファーストリリースに間に合う可能性が増えていく
- プロダクトオーナーは機能を減らすことにフォーカスする
- ウォークスルー、各ユーザーのペルソナを被ってユーザーのストーリーを再現する
- スポンサーとプロダクトオーナーが協調して作業する
- 付箋を壁に貼って議論する
- 機能のスケルトンに対して、動く事を確認する、もっと良くする、リリースできる状態にするなどのラインを引いていく
- チームが全員で壁に向かって付箋を貼っていく
- アトラシアンの人はJIRAを使ってない、壁に付箋を貼っている
ストーリーを使う目的は、もっといいストーリーを描くことではない
- フォーマットなどは本当にどうでもいい
製品開発の目標は、製品を作ることではない
- 作って終わりではない、バリューを出せているか、価値のあるものを作っているか
困っている人がいる -> すばらしいアイデア -> 機能・仕様など -> インクリメンタル開発 -> アウトプットが戻る
- アウトプットは小さく（コストだから）、成果やインパクトを最大化する
- ユーザーの幸福を最大化するのが目的
XP（ケントベック）
- ビジネスとテクノロジーの間の溝を癒すことが原動力だった、納期を決定できると思っている人から力を剥がしたい
プロダクトバックログを作る、開発者が優先度を決める
任天堂（宮本さん）の話
- 何も知らない人にコントローラーを渡してやってもらう。やり方の説明はしない。
- 宮本さんは視点を動かすことに長けている

このあたりでお時間がきました

感想

まず、お話の仕方がとても面白くて聞きながら自然に引き込まれていくような感じでした。講演の内容はテストよりもアジャイル開発とは何か、なぜ・何のためにそうするのかにフォーカスしていたと感じました。ユーザーへ価値をもたらすことの重要性、それを実現するための開発の仕方、チームが協調して進めていくためユーザーストーリマッピングといった形で、とても良いお話が聞けました。ユーザーファーストを掲げるロコガイドとしても開発に取り入れていきたいと思いました。

事例紹介1「インスプリントにおけるQAの取り組みとハーモナイゼーション」

長田亮介さん（freee）

講演のメモ

アジャイル開発でのQAのあり方について
アジャイルQAとは？
- ウォーターフォール型だとQAがチームから独立している
- アジャイルQA型だと開発とQAが一体化している、トータルではリリースが早くなる、チーム内にQAがいる状態
インスプリントでの取り組み
- freeeではQAプロセスを標準化している
- スクラムイベントを開始する前に
  - スプリントバックログに積むための前提条件
    - 受け入れ基準があるかどうか？
    - 開発チケットやQAチケットのdoneの定義
    - 価値探索の段階にQAが入っていく
- リスク洗い出し会
  - そのプロダクトの関係者を巻き込んでリスクを洗い出す、そこで出たリスクをテストケースに含めていく
- リファインメント
  - チケットの受け入れ基準の認識を合わせる
- インスプリント
  - 検証可能な細かい単位でテスト分析やテスト設計を回している
- デイリースクラム
  - ローカルで検証環境を構築している、ローカルで最新のPRを取り込んだりしている
  - マイクロサービスのAPI単位でQAを進めている
  - QAでのバグチケットは重篤度を設定している
- スプリントレビュー
  - デモ会をステークホルダーを招待してやっている、QAが開催役を持っている
- レトロスペクティブ
  - ふりかえりを行う
  - バグの振り返り会を非同期でやっている
開発とQAのハーモナイゼーション
- Debug API
  - 決済・請求機能が重要
  - カード利用の申込みから決済まで一貫した自動テストが必要
  - 本人確認にバッチがあり、完了を待たないとテストができなかった
    - QA用にDebug APIを作ってステータスを進められるようにした
  - カード利用の検証がすぐに終わるようになった
アジャイルQAを行う上で心掛けること
- 最初のうちは相談しても開発側から軽視されることもあった
- しっかりとコミュニケーションをとることが大事
Q スクラム開発する強みは？
- A 強み：細かいところまで繰り返し継続することができる。弱み：方向性が違っていってしまうことがある
Q 複数チームによって進め方は違う？
- A 違う。今標準化を進めている、チームを行ったり来たりしても大丈夫なように
Q バグの重篤度はどうやって決めている？
- A 会計サービスでの基準が昔からあった、これを展開している
Q PdMとQAの役割分担は？
- A 受け入れ基準をQAが作っていっている

感想

プロダクトの関係者を巻き込んで行うリスク洗い出し会など開発とQAが協調して、プロダクトを作っていっているのがわかりました。開発初期からQAがプロジェクトに入っているのはとても良い試みだと思います（自分達もやろうとしているがなかなか難しい……）

事例紹介2「スクラムチームにアウトスプリントで関わるテスターの取り組み事例」

大平祐介さん（JaSST Tohoku 実行委員会）

講演のメモ

イントロダクション
- 某教育会社QAチーム所属
- 好きなプロトコルはLDAP
担当しているスクラムチーム
- 1スプリント = 1week
- toB向けSaaS
- Ruby on Railsで開発された学習サービスの管理画面WEB
  - DHHを信仰している
- テストコードは可読性を大切に
- トランクベース開発を採用
- リリースは2パターン
  - ショートトレイン
    - 1スプリントで完結する
  - ロングトレイン
    - 複数スプリントにまたがる、顧客影響が大きい
    - フィーチャーフラグ、ダークローンチを活用している
- プロダクトのテスターとしてチームと一緒にやる
  - プロダクト品質のシェルパ
  - いいチームでいたい
- 二つの品質
  - プロダクト品質
  - プロセス品質
    - チームのコンディション、開発プロセス
- スプリントプランニング
  - 意識していること
    - スプリント終わりのスプリントレビューで何を見せたいかをメンバー全員で認識を合わせる
    - スプリントゴールを明確にする
    - ユーザーストーリーの受け入れ条件のブレイクダウンして、テスト設計、実行ができるまで落とし込む
    - スプリントバックログアイテムを細かくする、テスト設計や環境準備など
- デイリースクラム
  - エンジニアがテスト設計、実施するためのガイド
  - E2EテストコードのPRレビュー
  - モブプロ参観（ナビゲーター）
  - たまに自分もコーディング（GitHub Copilot頼み）
  - たまに自分もテスト設計、実施
- スプリントレビュー
  - メンバー全員でプランニングで決めた欲しいフィードバックからアジェンダを考える
  - シナリオ作成やレビューをする
  - 自動テストツールを使った環境準備
- スプリントレビューのFB共有会
  - フィードバックの共有
  - フィードバックから改善を考える
  - スプリントレビュー自体を振り返る
- ふりかえり
  - プラスデルタで実施
  - ファシリテーターはScMとQAのどちらかが担当
コミュニケーション
- メンバー全員と1on1をする
- 飲み会に参加する
- チャットコミュニケーション
全体の認識合わせ（メイン業務）
- ロングトレインでリリースする場合
  - 何をどのように作っていくか認識を合わせる
  - ユーザーストーリーマッピングを雑に書いて話してみる
  - リリースまでのプロセスを雑に書いて話してみる
テスト設計実施
- スプリント外で必要なテストを設計、実施する
- リファインメントで共有してメンバーにレビューしてもらう
メンバーと勉強会
- テストに関して共有認識の醸成
- テスト技法練習帳をもとにテスト技法を練習する会
ワークショップの実施
- ドラッカー風エキササイズ
- デリゲーションポーカー
- ワーキングアグリーメント
大きな不具合はゼロ
プロダクト品質はみんなで向き合うと楽しい
そのためにプロセス品質にもフォーカスする

感想

QAとして「プロダクト品質のシェルパ」であること、「いいチームでいたい」というフレーズが印象的でした。QAが開発チームに寄り添っていくという姿勢はとても重要だと思いました。反面スクラムマスター寄りの役割が多くなってくるというのは単純に大変そうであったりQAとはまた違うスキルが必要になりそうだなと思いました。

事例紹介3「Struggling with Agile Testing, in Rakuten」

半谷充生さん（楽天グループ）
中村祐輔さん（楽天グループ）

講演のメモ

R-messe
- Product Discovery作って開発した。半年でリリース
- メールの誤送信の不具合があった、インシデントとなり役員まで報告
- 実施した品質向上策
  - 開発案件を全部止め、Unit testを書く
  - QA工程を全プロジェクト必須にする
- 外部組織（当時）なので、時間がかかる。リリースが1ヶ月遅れる
- 結果としてトラブルは激減したが、リードタイムが伸び、リリース頻度が大きく落ちた
  - LeanとDevOpsの科学で定義されているハイパフォーマーからは遠い
課題
- QAは独立した組織、プロジェクト毎に各サービスからテストの依頼が来る
QA依頼が来て初めて案件を知る
- 「QAをするとリリースが遅れる」
ドメインナレッジを有し、開発-PDMと一緒に品質を向上させる人が必要
エンジニアリングマネージャーと採用活動スタート
- テストエンジニアとしてのナレッジ・経験がある
- テストを自分で設計・実行できる人
- 能動的に動ける人
- 開発エンジニア経験がある人
  - リリーススケジュールに合わすために忙しい
  - テストをする時間がない
  - QAチームからバグばかり押し付けられる
  - → QAエンジニアとして開発の気持ちがわかる人、攻めたサポートができる人
QAチームからのアクション
- Shift-Leftの活動からスタート
- 仕様の検討段階からQAメンバーが入る
- 開発側の打ち合わせに混ぜてもらう
- 開発とより近い距離でありながら、従来のQAプロセスにのせる
テストエンジニアの強みを活かす
- 「店舗の営業日・営業時間に合わせて応答メッセージを変える」というプロジェクト
- 営業日営業時間の設定は複雑、曜日週替わり、特定日、年末年始……
- テストエンジニアには組み合わせのナレッジがある
結果としてQAフェーズでのバグ検出率が低くなった
- 開発者のテストとQAフェーズでのテストが重なっている
- → QAフェーズでのテストスコープを見直し
  - 複数ブラウザ、複数端末、探索的テスト
四半期に一度の品質レポート
3アミーゴスの導入(PdM, DEV, QA)
プロセスを監視し、アウトプットデータを収集しながら効果をはかり、改善していく

感想

採用からスタートしていくのはすごいなと思いました。ここで開発経験がある人に限るなど、開発とQAのコミュニケーションの取りやすさを強く意識しているのがわかりました。テストエンジニアの強みを活かすというのもスキルを活用するという点で良い動きだと思いました。

ワークショップ

ここからはワークショップについてとその感想です。

ワークショップは現地参加の人は近くの机にいる人とチームを組んで付箋と紙で、オンラインの方はMiroやDiscordといったツールを駆使して行われました。

内容としてはユーザーストーリーマッピングを実際にチームで体験するものでした。最初のお題は「朝起きてから何をしましたか？　家を出るまでにやったことをチームで話し合って時系列で並べてください」です。この時点でもチーム内の人でやっていることがかなり違う（朝ごはん食べた／食べないなど）で割と議論になりました。

こちらが一通りできたタイミングで次のお題「5分で家を出るのでこの中から必要なことだけをピックアップしてください」が発表されました。こちらも同じようにチーム内で議論していきました。

これが終わると席を立って他のチームの成果物を見て回る時間になりました。ここが結構面白く、自分のチームとほぼ同じ結果になっていたチームや、自分のチームでは入れるかどうか最後まで悩んで入れなかった項目が入っていたチームなどがありました。

ここでワークの解説が入ります。「5分家を出るために必要な最小限のこと」はMVP（Minimum Viable Product/価値を提供できる最小限のプロダクト）に該当するものであるという説明がありました。

さて、つづいてのお題（これが本番）「乗換案内システムの1stリリースのMVPを選ぼう」になります。

今度は乗換案内システムの機能が書かれたカードが配られました。こちらから最速で1stリリースをするために必要な機能をチームで選んでいきます。こちらは先ほどのお題以上に議論になりました。ユーザーに乗換案内の価値を届けられる最低限の機能は何だろうとみんなで頭を捻りながら作成していきました。

こちらも終わった後他のチームの結果を見にいく時間がありました。自分のチームではかなり機能を絞ったつもりでしたが、他のチームではより少ない機能のところもありました。

つづいて新しい要求を加えての2ndリリースの作成がありました。こちらも同様に必要な機能をしぼっていきます。この後も同じように他チームの共有があったのですが、今回はその判断に至った経緯なども併せて共有しました。同じ成果物になっていても、判断の経緯は違うなど興味深い点が多かったです。基調講演での「地図を共有する」とはこういったことなんだろうかと思いました。