#はじめに
はじめまして、QAエンジニアの川満です！
2年前までWFモデルの開発工程でテスト担当（QA）を行っていましたが
別プロジェクトに参画する事となり、スクラム開発の現場に配属される事になりました！
昨年1年間の間に経験した異世界転生(ウォーターフォール（WF）モデル開発→スクラム開発)した実体験をここに記したいと思います！
##スクラム開発って？QAはどのように動く？？
これまで案件開始の要件定義段階から参画しドメインスキル（仕様把握力）や検証観点を持って機能のあるべき姿を提案しつつ、テスト計画を立てスケジュールを設計～実行・不具合管理を下流工程のテストフェーズに実施する。という流れをWFモデルで実践してきました。
ある程度期間を頂きながらテストという工程の役割を果たす。という所に重きを置き、
業務に励んでいました。・・・ところがスクラム開発に入ると考え方・動き方が全然違いました。
まず、テストという工程の役割を果たす。という考えを改めさせられました。
**対象のプロダクトがユーザーに価値を届ける為にはどうすればよいのか？**という議論を
プロダクトオーナー、開発者、デザイナー、QAが真剣に突き詰めていく必要があり、
”テスト”という工程の考えだけでは十分ではないと感じさせられました。
さらに進捗状況の確認や振り返りを行うスクラムイベントに参加することになりましたが、
横文字がいっぱい。。。不安がいっぱいでしたが・・・・・？？？！
#スクラムイベント
初めはわからないことだらけでしたが、
進んで実践したり声を上げることで**「楽しい！面白い！」**が増えていきました！
実践して気づいた部分を記します！
##リファイメント
プロダクトバックログ（製品が保有している課題）に対して
課題解決する為のタスクの明確化、見積もり、優先度付けを行う場。
※ここでQAとしてはユーザーが利用するケースを想定し、要件やタスクに不足があれば声をあげる。
##スプリントプランニング
リファイメントで決めたタスクを次回のスプリント（実装～設計～テスト）で
どこまでやるか決め、スプリント成功基準（ゴール）を決める。
例：今回は機能Aと機能Bを実装し、QAしよう！なので
ゴールはユーザーに〇〇をさせるサービスのQAまでを行うにする！
※工数的に達成可能か不可能かを判断しながら、QA側のスケジュールも考慮してもらう。
##デイリースクラム
プランニングで決めたタスクの進捗状況を確認し、現在のタスク消化推移をチェック。
※毎日参加し、タスクを進めるうえでの課題が出たらこの場で報告・相談する。
##スプリントレビュー
スプリント内で作成した機能のお披露目会を ステークホルダー（上長や営業さん等）向けに行う。
※自分たちのチームだとPOがファシリテートして成果物を動かしながら会を進めていました。
##レトロスペクティブ
振り返り会です。
今スプリントで何をやって、何を想ったかを共有し合い、
チームが目指すゴールに近づけているか？をみんなで振り返ります。
※会のファシリテートは持ち回りで行いました。
#イベントを通して
結果から言うとここまでか！と思うほど
コミュニケーションを取る必要があり、臆さず発言する勇気が必要です。
ただ、いろんなメンバーと検討しながら良いモノを作ろうとする取り組みは凄く勉強になります。
相手への理解が深まり、自身の存在価値を証明出来る素敵な場だと感じました。
#工夫した点
Wikiに改修内容等を纏めて頂く事もありますが、基本的に仕様書などはない場合が多いです。
なのでスクラムイベント内で出たタスクをみて求められる要件（実装される機能）を把握し、
項目書の設計を行いQA実施するという業務の流れになりました。
ただ、、
1.緊急を要する案件だと1スプリントで設計～実施を完了させる必要がある。
2.要件から項目書作成を行うも認識合わせがうまく出来てないと手戻りが発生する。
また要件をみても具体的に何が求められているか
わからない（QA側の観点から深堀が足りない）なんてことも・・・・・
※例として自動販売機のプロダクトバックログ・リファイメント内容のイメージ
そこでデシジョンテーブル等のマトリクス表を用いて、
項目書の設計をする前にマインドマップを利用してチーム全員でQAをするなら
どんな機能が必要か？どんなパターンをQAしないといけないのか？を話していきました！
すると**ツリー構造上に広がる観点が見やすい！**ということで
沢山の観点を頂きながらパターンがあれよあれよと出来ていきました。
チーム全員でQA観点をつくっていくことで、
**「次のスプリントではこうしないといけないね。」**なんてお話も出て、
チームの結束力も強まったと感じることもできました。
このマインドマップを基にマトリクス表にQA観点を落とし込み、
項目書の実装を行った後にQAを実施するというサイクルが出来たことで自信ついていきました。
その結果、難しい納期や依頼に立ち向かう事が出来る様になりました。
#最後に
とっつきにくいイメージがあったスクラムですが、
いざやってみると、貪欲に学んでいきたくなるほど素敵な開発手法でした。
またこのご時世、リモートワークの中でも活かせるチームビルディングの方法等もあるので、
強固なチーム作りが出来るという点も魅力の一つだと思います。
あなたもスクラムを怖がらずに、挑戦する機会があればぜひ挑戦してみてください！
**異世界転生(WF開発→スクラム開発)しても一向にかまわんッッ！**と思えるでしょう。
以上、最後まで読んでくれてありがとう御座いました！