はじめに
2026年1月23日に株式会社 アジャイルウェア 大阪本社オフィスで開催された testingOsaka #7 に参加してきました。testingOsakaは2回目の参加になります！
testingOsakaでは毎度おなじみのスライド
参加前の私
参加前はアジャイルテスティングについての知見はほぼありませんでした。
（「アジャイル開発のなかでどうテストするのか？」という話なのかなと思ってました。。）
ですが、今回のワークショップを通じて、よく耳にする「品質の作り込み」や「Shift Left」という言葉の解像度が上がり、「あ、こういうことか」と少し見えた気がしました。
本記事では「アジャイルな品質保証」を体験したプロセスと、そこからの学びを共有します。
当日の流れ
ワークショップは以下の流れで進行されました。
- 役割分担
- ラウンド1：サイロ化・最後にテスト
- ラウンド2：アジャイルテスティング
- ふりかえり：各自の体験や学びについて共有
当日の資料の画像からもわかるとおり、今回のワークショップではレゴブロックを用いたものづくりチャレンジを通じて、アジャイルテスティングの価値観を体験しました。
1. 役割分担
チーム内で、以下の3つの役割にわかれました。
| 役職 | おもな責務 | 人数 |
|---|---|---|
| PO | ステークホルダーと開発の間のコミュニケーションを行う | 1名 |
| 開発者 | レゴを組み立てる | 2-4名 |
| QA | レゴ基準に基づきテストする | 1-2名 |
私のチームにはそれぞれ、スクラムマスター・開発者・QAエンジニアとして働いているメンバーが揃っていましたが、ワークショップにおいての役割は現職と異なってもよいということでした。
私はQAですが、ワークショップでもQAの役割を担当しました🙋♀️
QAの責務
主催者のひとりのRyoさんより、QAに「レゴの業界基準カード」が渡されました。
この基準をもって、QAは開発者から受け取った成果物をテストしていきます。
レゴの業界基準カード
2. ラウンド1：サイロ化・最後にテスト
ラウンド1は、タイトルに「サイロ化」とあるとおり各役職間のコミュニケーションが限定的で、フェーズごとに分断されているという状況でした。
実際に役職ごとにテーブルが分けられて、QAは品質保証部として1つのテーブルに集まり、開発者は各チームごとにテーブルに集まる形でした。（お互い何をしてるかわからないくらいの距離があった）
ラウンド1の特徴
ラウンド1の特徴は以下のとおりです。
- 【PO】ステークホルダーにインタビューし、インタビューした内容を持ってPBIを作成
- ステークホルダーには、一度しかインタビューできない
- 【開発者】POから渡されたPBIをもとに、隔離された場所で開発（レゴ組み立て）
- PBIに関するPOへの質疑応答はなし
- QAも口出しできない
- 【QA】開発者から渡された成果物をレゴ基準に基づいてテスト （最後にテストする）
- 不具合があれば修正依頼とともに差し戻す
ラウンド1で感じたこと
開発者は「QAが持っている品質基準」を知らされないまま作っているため、テストフェーズになって初めて「仕様と違う」と突き返されてしまいます。
QAとしては悪気があるわけではないけど「ただ事実をもとに突き返す」形となってしまいます。
「サイロ化・最後にテスト」の進め方は、QAが修正依頼の際にどれだけ表現や言葉に気を使ったとしても、開発者 vs QAのような対立ができやすそうだな〜・・・と感じました。
ラウンド1の成果物
各チームの成果物はこんな感じでした。
（PBIの内容は「南国」「スイカ」「清潔そう」「がぶっと食べれる」・・・等）
「スイカ」という大まかな要件は満たしているものの、「これ何？」とステークホルダーから質問されてしまう
3. ラウンド2：アジャイルテスティング
ラウンド1の「サイロ化」による手戻りの多さとストレスを体験したあとは、楽しみにしていたラウンド2です！
ここでは、「開発者・PO・QAがワンチームとなり、短いサイクルでフィードバックを回しながら進める」 という開発スタイルを実践しました。
ラウンド2ではQAやPOも開発者のいるテーブルに移動でき、物理的にも職種の壁が取り払われた状態でスタートしました。
アジャイルテスティング5原則の紹介
ラウンド2に取り組む前に、アジャイルテスティング5原則が紹介されました。
上記のスライドに可愛いイラストとともに紹介されているので是非見ていただきたいですが、とても大事な価値観のため、以下にテキストでも書いておきます。
アジャイルテスティング5原則 🤼♂️
- 最後にテストする よりも テストし続ける
- バグの発見 よりも バグの阻止
- 機能をチェックする よりも チームが理解している価値をテストする
- システムを破壊する よりも 最高のシステムを構築する
- テスターの責任 よりも テストに対するチームの責任
アジャイルテスティングでは、「よりも」の後ろに書かれている価値観を重視します
ラウンド2の特徴
QA視点でのラウンド1との大きな違いは、QAが開発プロセスの中に入りこみ、メンバーや成果物に直接フィードバックできるというところです。（QAは開発できないが、口を出すことができます）
実際には、レゴの業界基準をPOや開発者にインプットするほか、「揺らしても壊れないようになってますかねー？」とか「5色以上はありそうだから大丈夫そうですね。」といったコメントをしていました。
すると、開発者のメンバーはレゴを組み立てながら「片手で揺らしても壊れないこと」や「5色以上のブロックを使っていること」を都度チェックしてくれました。
また、POは開発中にも度々ステークホルダーへヒアリングを行い、「今作っているものが（ステークホルダーが）本当に求めているものか」をフィードバックしてくれたため、成果物のブラッシュアップもできました。
🗣️「作品は大きい方が良いそうです！」「ヤシの実もつけてほしいです！」等の内容を追加で伝えてもらいました。
ラウンド2で感じたこと
レゴの業界基準をインプットしたことで、開発者のメンバーがレゴを組み立てながら「基準を満たしているか」を テストし続けてくれたことで、完成度の高いところまで成果物をもっていくことができました。
完成後にQAによる検証を行いましたが、手戻りはゼロでした。
・・・これが「品質を作り込む」ということなのかも。🤔🔅
なによりも、職種の壁がない状態で一緒に成果物を作り上げていく工程がとても楽しかったです。
ラウンド2の成果物
最終的にチームの雰囲気も成果物のクオリティも、ラウンド1とは全く違うものとなりました。
（PBIの内容は、「南国」「ヤシの木」「葉っぱがモサモサ」・・・等）
大まかな要件は「ヤシの木」。POからの追加要件もそれぞれの形で反映されていますね🫶
さいごに
よく「開発工程の上流からQAが入って品質を作り込もう（Shift Left）」という話を聞きますが、ただ開発の上流に入るだけでは役に立てないことが多いです。私自身も何回も経験しています。
今回のラウンド2でQAの私がやったことは、「他メンバーにQA観点（レゴの基準）を伝えること」だけでした。
しかし、その一つのアクションによって、チームの動きが劇的に変わりました。開発者が自ら品質を確認し始めた光景は、まさにアジャイルテスティング5原則にある 「テストに対するチームの責任」「テストし続ける」 が体現された瞬間でした。
アジャイルテスティングの価値観で仕事をすると、手戻りが減るだけでなく、「職種の壁を超えて、ワンチームでものづくりをする楽しさ」 も感じられて、いいことだらけでした！
アジャイルテスティングの価値観自体は、ウォーターフォール開発でもアジャイル開発でも活かせる行動軸だと感じたので、現場でも実践していきたいです。
株式会社ガラパゴス（有志） 株式会社ガラパゴスのエンジニアを中心に情報発信をしている Publication です。 各記事の内容は個人の意見であり、企業を代表するものではございません。
Discussion