エンジニアとQAの壁が崩れていくのを眺めていた #scrumosaka
238.3K Views
June 22, 24
スライド概要
スクラムフェス大阪2024の登壇資料です。
スクラムマスターとして、あるチームでエンジニアとQAの間に見えない壁があり、それが崩れるまでを眺めた。しかし、チームは時間をかけて壁を崩すことができ、その結果、よりユーザーと価値に向き合えるようになった。チームの状況は、初めてアジャイル開発やスクラムに触れるメンバーが多くいたよくあるプロダクトチームであった。スクラムマスターは、なぜ壁崩せたのか、なぜ見ていられたのかを語る。この物語は、あなたのチームでも起きうることであり、アジャイル開発に取り組む上での示唆になるはずです。
関連スライド
各ページのテキスト
エンジニアとQAの壁が 崩れていくのを眺めていた asato 2024-06-22 Scrum Fest Osaka 2024 - Kanagawa Track
僕がかつていたチームには エンジニアとQAの間に 見えない壁がありました
しかしその壁は 時間をかけて崩れていきました
僕はスクラムマスターとして それを眺めていました
壁が崩れる中 チームはよりユーザーと価値に 向き合えるようになりました
そんなチームの話をします
自己紹介 ● 名前：髙橋 朝人（asato） ● 所属：株式会社マネーフォワード （今回話すのは別の会社だった頃の話です） ● 職業：スクラムマスター ● 𝕏：@at_946 ● ブログ：https://at-blog.vercel.app
今日話す内容 エンジニアとQAEの壁が崩れていくのを眺めていた
注意事項とお願い ● “How to”ではなく”How I”の話です。正解ではなく一例です。 ● ぜひ感想・経験談・アイデアをdiscord・SNS・ブログで発信してください！ ○ そのアウトプットの最中の思考がこのセッションのアウトカムになります ○ そのアウトプットが隣の人のインプットにもなる ○ そのアウトプットが世界 🌍をちょっとよくします
目次 ● 物語に登場するチームの紹介 ● 物語本編 ~ エンジニアとQAの壁が崩れていった ● あとがき ○ なぜチームは壁を崩せたのか？ ○ スクラムマスターはなぜ眺めていられたのか？
登場人物
よくある？プロダクトチームです ● メンバー：時期により10~15人くらい ○ プロダクトマネージャー ○ デザイナー ○ フロントエンドエンジニア ○ バックエンドエンジニア ○ QAエンジニア ○ スクラムマスター
よくある？プロダクトチームです ● そんなつよつよな人はいない ● アジャイル開発やスクラムはほとんどのメンバーが初めて ○ エンジニアは個人商店型開発の経験者が多かった ○ QAはウォーターフォール型開発の経験者が多かった ● ベテランもいれば若手もいる ● 社員もいれば業務委託もいる つまり、これから話す物語はあなたのチームでも起きうることです
Before → After QA エンジニア リファインメント リファインメント Sprint N プランニング テスト設計 設計 プランニング 実装 9 months コードレビュー スプリントレビュー 設計 実装（UTはペアプロ） コードレビュー テスト依頼/情報共有 テスト環境構築 テスト設計 テスト環境依頼 テスト実行 不具合修正 テスト環境提供 スプリントレビュー テスト実行 テスト結果報告 不具合修正 QA エンジニア Sprint N+M
Before QA エンジニア ● スプリントはエンジニアのもの ● テストはスプリント外 ● テストはQAのもの ● テストで不具合が見つかるのは リファインメント 設計 実装 コードレビュー スプリントレビュー 実装完了から数スプリント先 ● Sprint N プランニング テスト依頼/情報共有 テスト設計 不具合が修正されるのは テスト環境依頼 テスト完了から数スプリント先 テスト環境提供 テスト実行 テスト結果報告 不具合修正 Sprint N+M
そんなチームのAfter QA エンジニア ● スプリントはみんなで過ごす ● テスト実行はやれる人がやる ● 不具合はスプリント中に見つかる ● 不具合はスプリント中に修正する リファインメント テスト設計 プランニング 設計 実装（UTはペアプロ） コードレビュー テスト環境構築 テスト実行 不具合修正 スプリントレビュー
【物語本編】 エンジニアとQAの壁が 崩れていった
【1ヶ月目】 チーム発足
チーム発足 ● 組織変更で、複数のチームから複数人ずつより集められたチーム ○ ● 元のチームは開発対象も開発プロセスもバラバラ 最初の1ヶ月は前チームのタスクの後処理や引き継ぎがメイン ○ すきま時間で、 2ヶ月目から良いスタートを切るための準備 ■ 自己紹介アクティビティ（ドラッガー風エクササイズ＆ワーキングアグリーメント） ■ インセプションデッキ ■ アジャイルマニフェストとスクラムガイドの輪読 ■ ユーザーストーリーマッピングとプロダクトバックログの準備 ■ DoD（Definition of Done：完成の定義）の認識合わせ
DoD（Definition of Done：完成の定義） ● What ○ ● 全てのプロダクトバックログアイテムに共通する完成条件 Related words ○ DoR（Definition of Ready：準備完了の定義） ■ ○ 全てのプロダクトバックログアイテムに共通する開発着手できるかどうかの条件 Undone work ■ DoDには含めていないが、リリースまでに実施する必要のある仕事 ■ DoDはスプリントにおける完成の定義、 Undone workはリリースにおける完成の定義と捉える こともできる ○ 受入基準（Acceptance Criteria） ■ 各プロダクトバックログアイテム特有の完成条件
DoD Workshop スプリント DoR リリース DoD エンジニアとQAで議論して定義してみた Undone work
DoD Workshop スプリント DoR DoD ユーザー ストーリーが 明確に なっている 受入基準が 明確に なっている 受入基準を 満たした プロダクション コードが 書かれている UIデザインの検 討が 完了している リファイン メントと 見積もりが 完了している スプリント レビュー用の 環境に デプロイ されている ・・・ リリース ・・・ Undone work ユニットテスト コードが 書かれている マニュアルの E2Eテストが 完了している パフォーマンス テストが 完了している ピアレビューが 完了している 社内向けの リリース アナウンスが 完了している XX資料が 最新化 されている ・・・
DoD Workshop スプリント DoR DoD ユーザー ストーリーが 明確に なっている 受入基準が 明確に なっている 受入基準を 満たした プロダクション コードが 書かれている UIデザインの検 討が 完了している リファイン メントと 見積もりが 完了している スプリント レビュー用の 環境に デプロイ されている ・・・ リリース ・・・ Undone work ユニットテスト コードが 書かれている マニュアルの E2Eテストが 完了している パフォーマンス テストが 完了している ピアレビューが 完了している 社内向けの リリース アナウンスが 完了している XX資料が 最新化 されている ・・・
ワークショップを通じてわかってきたプロセス QA エンジニア ● スプリントはエンジニアのもの ● テストはスプリント外 ● テストはQAのもの ● テストで不具合が見つかるのは リファインメント 設計 実装 コードレビュー スプリントレビュー 実装完了から数スプリント先 ● Sprint N プランニング テスト依頼/情報共有 テスト設計 不具合が修正されるのは テスト環境依頼 テスト完了から数スプリント先 テスト環境提供 テスト実行 テスト結果報告 不具合修正 Sprint N+M
【2-3ヶ月目】 本格的に開発スタート！ でもチケットが完結しない...
チケットAはいつ完成したと言えるのか？ Sprint N チケットA完了 ・・・ Sprint N’ チケットA’作成 不具合発見 ・・・ Sprint N’’ ・・・ Sprint N’’’ チケットA’完了 テスト完了
テスト完了がDoDに入ってないと ストーリーを完成できたって自信を持って言えなくないですか？ 前のチームでもこのやり方だったから 違和感はない ですね。 それに1スプリントでテスト完了までは無理 ですよ。 なるほどー。 でも不具合対応が何スプリントも後だと、忘れちゃいますよね 。 まずは「実装完了の次のスプリントにはテストを完了する 」を めざしてみませんか？ それはそうですね。 できるかわからないですが、やってみましょう。
そのためには、今のままだとやりにくいことはありますか？ 開発したものを理解してテスト設計し、実施までとなると 1スプリントでできるイメージが湧いてないですね ... リファインメントやプランニングは 何をどう作るかの認識をチームで合わせる場所なので そこを活用していきましょう！ そうすれば実装と並行してテスト設計も進められる かも。 やってみましょう！
対話を通じて実験し始めたプロセス QA エンジニア QA エンジニア リファインメント リファインメント Sprint N プランニング プランニング 設計 設計 実装 実装 コードレビュー コードレビュー スプリントレビュー スプリントレビュー テスト設計 Sprint N テスト依頼/情報共有 テスト環境依頼 テスト設計 テスト環境提供 テスト環境依頼 テスト実行 テスト環境提供 テスト結果報告 テスト実行 Sprint N+1 テスト結果報告 不具合修正 Sprint N+M 不具合修正 Sprint N+2
【4ヶ月目】 誰でもテスト環境を 構築できるようになった
テスト実施したいので、テスト環境の構築お願いします！ 承知しました！ ・・・ できました！ ありがとうございます！ （非同期のやりとりで、 1時間くらいはラグがあるなぁ） （都度フローも途切れるし、なんとかできないかなー）
ちなみに、テスト環境構築って何をやっているんですか？ 実は知らないんですよね。 エンジニアさんがやっているので、難しいことなんだと思います。 デプロイしたいコードと環境を GUIで指定するだけで 自動的に実行されるんですよね。 DB操作が必要な時は少し作業が必要になりますけど。
ちなみに、それって QAさんでもできそうじゃないですか？ 言われてみればそうですね。 デプロイするだけなら画面操作だけですし ... え！そうなんですか！ だったらやり方教えてもらえると嬉しいですね。 いつもお願いするの、少し心苦しかったですし。 でしたら今から教えますねー。
誰でもテスト環境を構築できるようになった QA エンジニア QA エンジニア リファインメント リファインメント プランニング プランニング 設計 テスト設計 設計 実装 実装 コードレビュー コードレビュー Sprint N スプリントレビュー テスト設計 Sprint N スプリントレビュー テスト環境依頼 テスト環境構築 テスト環境提供 テスト実行 テスト実行 テスト結果報告 Sprint N+1 テスト結果報告 Sprint N+1 不具合修正 Sprint N+2 不具合修正 Sprint N+2
【5ヶ月目】 テスト完了をDoDに追加
最近、スプリント中にテストまで終わること増えてません？ QAもリファインメントに参加するようになって スプリント前からテスト設計できるようになっている んですよねー。 なので実装終わったらすぐにテストができているんですよ。 ならもうテスト完了をDoDに入れちゃいましょう よ。 そうですね！やってみましょう！
テスト完了をDoDに追加 QA エンジニア QA エンジニア リファインメント リファインメント プランニング 設計 テスト設計 テスト設計 プランニング 実装 設計 コードレビュー 実装 Sprint N スプリントレビュー コードレビュー テスト環境構築 テスト環境構築 テスト実行 テスト実行 テスト結果報告 不具合修正 Sprint N+1 Sprint N+2 テスト結果報告 不具合修正 スプリントレビュー
【6ヶ月目】 エンジニアも テストを実施するようになった
最近、実装完了からテスト完了までの時間が短い ですよね。 どうやっているんですか？ ストーリー単位のテスト設計はあらかじめ行っているので、 実装後はテストケースを実行するだけ なんですよ。 リファインメントで受入基準も明確になっているので、 不具合も少なくスムーズにテスト完了できています ね。 なるほど！ テスト実行って私たちエンジニアでもできるものですか？ QAさんがお休みの時もあるし、スプリントの見通しを立てるのに できる人がすぐテストをできればバーンアップも綺麗になるかなと。 一応誰でも実施できるようにドキュメンテーションはしています。 読み方とかやり方の認識を揃えられればできると思うので 挑戦してみましょう！
エンジニアもテストを実施するようになった QA エンジニア QA エンジニア リファインメント リファインメント テスト設計 テスト設計 プランニング プランニング 設計 設計 実装 実装 コードレビュー コードレビュー テスト環境構築 テスト環境構築 テスト実行 テスト結果報告 不具合修正 スプリントレビュー テスト実行 不具合修正 スプリントレビュー
【7ヶ月目】 QAもスプリントレビューで デモを披露するようになった
最近、スプリントレビューのスタイルを変えて から よりユーザーのことを考えられる ようになっていい感じ。 あれ、いいなーって思ってました。 私もやってみたいなーって思っていたんですよ！ いいですね！じゃあ次回お願いします！ わかりました！
スプリントレビューのスタイルの変遷 ● ● ● ~ 4ヶ月目：スプリントで完了した全てのチケットの内容紹介デモ ○ 🤔 ユーザー体験の流れを伝えづらく良いフィードバックを得にくい ○ 🤔 細かいチケットまでやっていると なんだか承認を得ようとしている感覚に 5 ~ 6ヶ月目：スプリントゴールをシナリオ化したデモ ○ 😄 どんなユーザー体験を開発しようとしたのかが明確 になり、フィードバックが集まりやすく ○ 🤔 テストデータではユーザーの目にどう映っているのかいまいちつかめず 7ヶ月目 ~：実データライクなデータセットを用意 ○ 😄 ユーザーに近いビューや体感時間 などをデモできるように
QAもスプリントレビューでデモを披露するように QA エンジニア QA エンジニア リファインメント リファインメント テスト設計 テスト設計 プランニング プランニング 設計 設計 実装 実装 コードレビュー コードレビュー 不具合修正 スプリントレビュー テスト環境構築 テスト環境構築 テスト実行 テスト実行 不具合修正 スプリントレビュー
【9ヶ月目】 単体テストは エンジニアとQAのペアプロで
『単体テストの考え方 /使い方』面白かったー。 私も読みました！よかったですよね！ なんか単体テストって、今はエンジニアだけでやってますけど 観点のとことかって QAの得意分野だろうし、 コラボレーションしたい ですよねー。 それできたら面白そうですねー。 一回、ペアプロっぽい感じでやってみますかー。 エンジニアがテストコードを書いている画面を共有して QAが質問をするス タイルのペアプロ に挑戦してみましょう！
単体テストはエンジニアとQAのペアプロで QA エンジニア QA エンジニア リファインメント リファインメント テスト設計 テスト設計 プランニング 設計 プランニング 設計 実装 実装（UTはペアプロ） コードレビュー コードレビュー テスト環境構築 テスト環境構築 テスト実行 テスト実行 不具合修正 不具合修正 スプリントレビュー スプリントレビュー
時間の都合上 他の実験はサマリで！
7 ~ 9ヶ月は他にもこんなことを！ ● ● ● QAもストーリーの見積もりに参戦 ○ DoDにテスト完了を追加したので、テストの観点も見積もりに入れようとなり ○ 😄 実装とテストでどんなことをするのかの知識共有がスムーズに！ 「全員で作ったものを触る会」が誕生 ○ Slackのハドルで、時間を決め、開発中のプロダクトを触り、気になったことを共有し合う ○ 探索的テストを参考に（ストーリーベース、セッションベースド、ランドマークツアー、 ...） 高負荷（大量データ）環境で「触る会」 ○ リリース直前のパフォーマンステストとは別に、早めにサクッと触ってみる ● JSTQBのシラバスの輪読会 ● 開発中のデグレを使って障害訓練 ○ 開発中のデグレ報告をトリガーに、手を止めてみんなでハドルに集まり障害対応！
こんな感じでこんな変化が起きました QA エンジニア リファインメント リファインメント Sprint N プランニング テスト設計 設計 プランニング 実装 9 months コードレビュー スプリントレビュー 設計 実装（UTはペアプロ） コードレビュー テスト依頼/情報共有 テスト環境構築 テスト設計 テスト環境依頼 テスト実行 不具合修正 テスト環境提供 スプリントレビュー テスト実行 テスト結果報告 不具合修正 QA エンジニア Sprint N+M
めでたしめでたし
あとがき
なぜチームは壁を崩せたのか
キーワードは2つの文化 実験の文化 学習の文化
チームが成長するために ● チームが成長するためには、実験から得た体験や気づきが大切 ● より良い実験を思いつくためには、より良い学習（インプット）が必要 インプット インプット 成長 学習 （勉強会、書籍、ブ ログ、etc.） チーム 実験 ふりかえり （学習）
コルブの経験学習サイクル ↑ 実験の文化 ↓ （内省的）学習の文化 画像：経験学習のサイクルとは？活用するメリットや注意点を紹介 | オンライン研修・人材育成 - Schoo（スクー）
文化はどうつくるのか？ 場づくり 言葉選び
場づくり 実験の文化 ● スクラム ● スクラムガイドの輪読会 ● 雑談チャンネル ○ 学習の文化 ● 毎朝10分の学び合いの場 ○ ● こういうのやりたい！を吐き出せる場 ● 立候補者がおすすめのブログを紹介 Just Talk ○ Lean Coffee、焚き火などのふりかえり ○ 常設の雑談ハドル みんなでカンファレンス
言葉選び 実験の文化 ● やってみましょう！ ○ ● ● 🙅 もう完璧ですね それもっと知りたいです！ ○ ● 🙅 失敗でしたね 次何実験しましょうか ○ ● 🙅 やってください うまくいかないことがわかりましたね ○ 学習の文化 これ大事だと思ったのでぜひ！ ○ ● 🙅 （何もフィードバックしない） 🙅 これは知ってて当然ですが 他の人にも教えてあげて！ ○ 🙅 色々知っててすごいですね（ 🔚）
文化形成についてはスクフェス仙台でも発表しました 価値提供を続けるチームはマインドセットに支えられていた | ドクセル
スクラムマスターは なぜ眺めていられたのか？
スクラムマスターは眺めているだけの方が良いの？ ● 良い！ ● なぜなら、チームの活動の多くは、 ScM以外のメンバーが実行責任を負うことになるから ● ScMが積極的に動きすぎると「やらされ感」に繋がる ● 「やらされ感」は実験を遅らせ、成長を鈍化させる ● 責任の引き受けの原則 from XP ○ “責任は割り当てるのではなく、引き受けることしかできない。 ”
“パーキンソンの法則は、ほぼ確実にあなたの部下には あてはまらない。 人生は、だらだら仕事をするにはあまりにも短い。彼ら は楽しく仕事をしているから、仕事を永遠に引き延ばす 気になれない。長引かせると、誰もが心から望んでいる 仕事を仕上げたときの満足感を味わう時期を遅らせる だけである。”
“人は「私は共同体にとって有益なのだ」と思えたとき にこそ、自らの価値を実感できる。 （中略） 共同体、つまり他者に働きかけ、「私は誰かの役に 立っている」と思えること。他者から「よい」と評価され るのではなく、自らの主観によって「私は他者に貢献で きている」と思えること。そこではじめて、われわれは 自らの価値を実感することができるのです。”
自ら考え自ら実践した方が 楽しい仕事になるし パフォーマンスもでるし 自分の価値を感じられる
眺めていてもチームに変化が起きるように気をつけていたこと 踊る・誘う・帰る チームの 理想を引き上げる チームの 選択肢を増やす “眺める”
踊る・誘う・帰る ● 踊る ○ ● ● 場で、まずは自らが踊る（場をフルに活用する） 誘う ○ 自分が楽しそうに踊っていれば、他のメンバーが徐々に誘われてくるはず ○ 来なければ、全体に向けて「 Join us!!」とポストしたり、 1on1で「Join us!!」と伝える ○ 🙅 強制はダメ。あくまで「自分で選択」して踊ってもらう。 帰る ○ 自分がいなくても盛り上がりそうなら帰る（フル活用はやめる） ○ 「いいね！」など、その場を使ってくれている人を盛り立てるくらいの役割で ○ 🙅 踊り続けるのは楽しいけど、自分がいないとチームが機能しなくなるおそれがある
チームの理想を引き上げる ● いわゆるMoonshot ● 実は1ヶ月目から「スプリント内でテスト終わらせようぜ！」って言ってた ○ ● これがなかったらリフレーミングが行われず、おそらく最初のままのプロセスだっただろう 常に「まだこんなことも目指せるかもよ」のストックを持っておく カイゼンのカタの 目標を引き上げる 一歩ずつの歩みも より効果的になる 画像: The Improvement Kata | The Toyota Kata Website
🤔 理想にこだわらない ● 自分の理想通りでなくても、チームが何かに向かっていれば問題なし ● 理想にこだわると「もっとこうして」「もっと早く」という気持ちが出てくる ● そうではなく「チームの自然な成長」を待つことが大事 ○ ● でなければ「やらされ感」や「燃え尽き感」に繋がってしまう 理想にこだわらないために、一度理想を述べたら忘れるくらいの気持ちでいる
チームの選択肢を増やす ● 「知らないことはできない」ので、チームに有益な情報をオープンに ● 書籍、ブログ、登壇資料、動画、Podcast、SNS、情報源は色々ありますね！ Agile Testing Condensed 単体テストの考え方/使い方
学習の5段階 ← 他者への共有の依頼 ← 想起の問いかけ ← 一緒に踊る ← 情報共有で支援 画像: 学習の５段階レベル - NLP学び方ガイド（NLPとは）｜資格セミナー総合情報サイト｜協会 公式
選択肢は少しずつJust In Timeで “一度に多くのことをやろうとすると、長期記憶に定着 せず、知覚能力も低下し、ほかのスキルの全体的な パフォーマンスも低下してしまう可能性がある。そのた め、コーチが一度に1つずつステップを踏むほうが、学 習がより速く進むことが多い。練習の最初に選手がト ライすべきことを5つ与えるよりも、同じ5つのことを練 習全体に分散して順番に与えていくのがいい。”
“眺める” ● 要は「我慢」 ● チームで悩んでいる過程にも価値がある ● 私が考えたことが最良である保証はない、というマインド ○ ● むしろチームメンバーの方が実務に近いのでより良いアイデアを出す可能性が高い もちろん相談には全力で乗る
自然の結末 “親の干渉なしで子供が自分の行動の結末を体験する ことを成長のチャンスとする子育て方 子供は体験を通じて多くのことを学びますが、親は先 まわりしてよくない結果を招きそうな行動をやめさせよ うとします。これは、せっかくのチャンスを逃してしまうこ とになります。”
まとめ
エンジニアとQAの壁が崩れました QA エンジニア リファインメント リファインメント Sprint N プランニング テスト設計 設計 プランニング 実装 9 months コードレビュー スプリントレビュー 設計 実装（UTはペアプロ） コードレビュー テスト依頼/情報共有 テスト環境構築 テスト設計 テスト環境依頼 テスト実行 不具合修正 テスト環境提供 スプリントレビュー テスト実行 テスト結果報告 不具合修正 QA エンジニア Sprint N+M
それはチームに「実験」と「学習」の文化があったから 実験の文化 学習の文化
眺めていてもチームに変化が起きるように気をつけていたこと 踊る・誘う・帰る チームの 理想を引き上げる チームの 選択肢を増やす “眺める”
Thank you