とあるQAチームの ⽴ち上げから半年〜1年の お仕事 2019/07/18 BizReach QA Meetup 井芹 久美⼦（Kumiko Iseri） 1

誰︖ • 現職 QA基盤推進室に所属 • QAという肩書きは、ここ半年 • 前職では、エンタプライズ系ソフトウェア開発業務を経験（SE） • 出没先、コミュニティ • JaSSTʻ18 Kyushu にて ワークショップ「ワークを通してじっくり考える同値分割＆境界値分析」担当 http://www.jasst.jp/symposium/jasst18kyushu/report.html • 過去、WACATE（若⼿テストエンジニア向けワークショップ）の実⾏委員として活動 https://wacate.jp/ • など 2

おはなしすること 1. ⽴ち上げから半年〜1年のQAチームがやっていること • 主に、BizReachシステム向けのQA業務の話 • 事業ごとに開発の進め⽅は異なり、QA業務も事業ごとに異なります 2. QAの仕事で役⽴っていること、必要だと感じること 華やかな話はありませんｗ …が、できるだけ、実際の仕事内容が伝わるようお話したいと思います 3

BizReachシステム • 転職サイト • ウェブサイト、スマホアプリでサービスを提供 • 求職者様向け、ヘッドハンター様向けなど • 画⾯の例 • https://www.bizreach.jp/login/ 4

QA＝Quality Assurance って︖ どんな仕事を思い浮かべますか︖ • テストをする︖ • ⾃動エンドツーエンドテストのテストコードを書く︖ • レビューをする︖ • バグ収束曲線を書いたり、データの分析をする︖ 5

QAチームの現在の主担当領域 • テスト • 分析、設計、実⾏を、2週間単位で実施 • エンドユーザが直接触れる範囲 • ブラックボックステスト 6

企画、 要件定義 設計 PGM テスト QAチームは、いつテストを⾏う? 少しずつ、より前の段階から 開発チームと⼀緒に テストの内容や分担を検討することが増えてきている 開発の終盤で、開発チームとは別組織としてテストをする 7 このあたり

リリースのサイクル2週間＝⼤体10営業⽇/1サイクルに従う QAチームは、どんなサイクルでテストする? 8 1つ前の リリース後 n⽇⽬ ★ 1 2 3 4 5 6 7 8 9 ★ 1 2 3 4 5 6 7 8 9 ★ 1 開発チーム QAチーム ★＝リリース⽇ 設計、PGM 設計、PGM 設計、PGM テスト分析、設計 テスト実⾏ テスト分析、設計 テスト 分析、 設計 テスト実⾏ 2週間

QAチームと開発チームの関係は? 独⽴ 協調 独⽴ × 柔軟 協調 × 柔軟 独⽴ × 定型 協調 × 定型 組織は別だが、 ⼀緒にテストを検討することや データの確認など開発チームに協⼒して もらうことも。 リリース都度、 案件内容やスケジュールなどの制約にあわせて QAチームでテストケースを考える。 9 柔 軟 定 型

テストだけ︖ プロダクト 10 • QAによるテスト • テストの内容や分担の相談

QAチームの半年〜1年の取り組み • QAによるテスト • テストの内容や分担の相談 • 開発プロセスの整理 • リリース判定会での報告 • チケットの書き⽅ルール提案 • ⽤語の整備（全社向け） • 勉強会の開催 • 障害分析 プロダクト プロセス プロダクト&プロセス 11

テスト以外はプロセス改善関係が多い 難しく聞こえるかもしれませんが、だいたい以下のいずれか 12 現状を ⾒える化する • 改善が必要な箇 所を特定する ⾒える化の結果 を共有する • どう困るか、 はっきりさせる • 関係者で同じ ⽅向を向く 課題に対応する • 課題と対応内容 が明確な場合は ここから始まる こともある

現状の⾒える化、⾒える化の結果の共有 • 課題があるところ、過去と⽐べた際の変化を確認する • e.g. リリース判定会でのテスト結果の報告 • e.g. 開発プロセスの整理、プロセスの定義の明確化 • 企画されてからリリースされるまで、開発の流れを図⽰ • プロセスの組み替え、追加、変更が必要な箇所はないか︖ • e.g. 障害分析 • ⾒える化する途中で課題を⾒つけることもある • e.g. 分析したいデータがチャット上にしかない 13

課題に対応する • 対応は緩急をつける • 具体的に困っている⼩さめのところから着⼿ • ⽇々の⾏動で少しでも改善できそうな部分 • e.g. チケットの書き⽅のルール提案 • 作業負荷、⼼理的負荷少なく対応できそうな部分 • e.g. 勉強会の開催 • 影響が⼤きい対応は、情報収集しながら少しずつ準備する • 実態を理解した上で対応できるように • e.g. ⽤語の整備（全社向け） 14

改めて、QAチームの現在の主担当領域 • プロダクトのテスト • 分析、設計、実⾏を、2週間単位で実施 • エンドユーザが直接触れる範囲 • ブラックボックステスト • プロセスの改善 • ⾒える化、共有、課題の対応 • 開発に直接関係するプロセスを中⼼に実施 15

おはなしすること 1. ⽴ち上げから半年〜1年のQAチームがやっていること 2. QAの仕事で役⽴っていること、必要だと感じること 16

難しさ • 2週間でテストまで終わらせるスピード感が求められる • 仕様を聞いたその場で、 テストの規模感や想定されるリスクを話したいことがある • 答えを⾃社（⾃分たち）で決めていく • どの機能追加を、どんな優先度で対応し、どんな品質をどこまで求めるか︖ • ⽴場や得意分野の異なる関係組織が多い • QAや、プロダクトをつくるエンジニアの組織だけではない 17

役⽴っていること、必要だと感じること • テスト、品質の基礎知識 • ⾔葉や概念を知っていると、より素早く広く考えやすくなる、説明しやすくなる • テストだけでない、周辺の技術やプロセスへの関⼼ • 品質の向上や安定化に繋がるトピックは、開発プロセスのそこかしこにある • テスト以外で改善する⽅法を提案した⽅がよいこともある • ⽴場の違う⼈へ説明する⼒ • 良いプロセス改善には多様なチームの⼈の協⼒が必要なことが多い 18

QAの経験がない/少ない…という⽅へ 半年間の、QAとしての⽇々で感じたこと。 • 必要な品質は、プロダクトやプロジェクト次第で異なる。 知識を⾝につけることはもちろん、 品質に対して⾃分の考えを持つこと、考える癖をつけることも⼤事。 • やらされ仕事でも、 ⾃分たちで考えて周囲を巻き込み納得感を持って進める仕事でも、 1⽇を終えることができてしまう • QAとしてできることは、思っていたより沢⼭ある。 やりたいこと、その実現に必要なことを、具体的に考えることも⼤事。 • ときどきは肩書きにこだわらず、広く考えてみてはいかがでしょう︖ 19

おはなししたこと 1. ⽴ち上げから半年〜1年のQAチームがやっていること • プロダクト、プロセス両⾯から良いものづくりにつながる取り組み 2. QAの仕事で役⽴っていること、必要だと感じること • テストや品質の知識、周辺の技術やプロセスへの関⼼、説明⼒ • 品質について考える癖、具体的にやりたいことを考えてみるのも⼤事 華やかな話はありませんでしたが、ご参考になれば嬉しいです 20