以前noteで投稿した記事になります。
今まで、IPO（Initial Public Offering） 前準備（東証グロース市場：2022年4月3日までの東証マザーズ市場）シリーズ期の「スタートアップ」・「ベンチャー」数社のQA組織立ち上げに関わってきました。
そもそも、どのような経緯でQA組織を立ち上げることになったのか？
スタートアップやベンチャーでは、1つ目としてEXIT（IPOもしくはバイアウト）まで持っていくこと。
（VC：Venture CapitalやCVC：Corporate Venture Capitalからの資金調達だと特にリターンが大事になる）なので、IPOもしくはバイアウトまで持っていくプロセスの1つが事業としての品質プロセスです。
（資金調達ラウンドが 「シリーズA」 以降から 「シリーズC」 までは特に）
2つ目として、上場後（EXIT後）は、もっと エンドユーザーに対してのエンゲージメントを高める施策 など。
上記は、それぞれの事業ベースになります。
続いては、プロダクト提供品質についての考え方に
ジョインしたスタートアップやベンチャー企業の「CEO」・「CTO」・「VPoE」との1on1で現時点での状況を聞くと理由の多くは
1️⃣「現時点でのプロダクト品質が悪い」
2️⃣「品質云々以前にテストがきちんとできていない」
3️⃣「テストフローやリリース基準が無いため開発担当者やサポート担当者の個人感覚でプロダクトをリリースしている」
4️⃣「（3番に紐付きますが）新規機能リリースした後に既存機能が動かなくなった」
5️⃣「今まで不具合分析がきちんとできず、同じバグが多発している」
6️⃣「開発のテスト、QAのテストと担保すべき領域が決まっていない」
7️⃣「月を追うごとにChurn Rateが上がっている」
8️⃣「案件の優先度がFIXしていないのでリリース対象が直前まで流動的」
9️⃣「ブランチの運用ルールが決まっていなく開発担当に任せっきり」
🔟「テストの自動化はしているが、日々のメンテナンスが追いついていなく数ヶ月そのまま放置状態」
そのため、UXやUIに問題があり、かつ仕様の詳細もない、また非機能要件も決まっていなく、結果、400番台（クライアントエラー）、500番台（サーバーエラー）となる。
（障害でシステムが止まってしまった場合は損害賠償にも発展する。）
※横の連携も取れていなく（仕様についても、開発マターで実装）となるケースも多々あります。
このような理由で、チームビルディングも兼ねて QA組織を立ち上げる ことになりました。
今でこそ、タックマンモデルでどう考慮すべきかできますが、 立ち上げを初めて経験した当初は勢いだけでどうにかしようとしておりました。
当時は、特に参考となるものがなく、手探り状態でした。
で、社内にQA組織を立ち上げてどこまでQA活動としてカバーできるのか、もしくは解消できるのか。こちらのページにも纏めております。
まず、今後の計画として組織型をホラクラシーとヒエラルキーのどちらにするか。
当然、カルチャーフィットやメンバーのスキルも考慮。
ふと思い出すと、私が関わったプロジェクトは全てヒエラルキー組織でした。
ヒエラルキー組織のメリットは、育成型や未経験の方でもジョインしやすい、報告ルートが明確であること。
当然デメリットもありますが、ここでは割愛します。
まずは、「QA組織立ち上げにどのくらいの期間を使うのか」そして「QAエンジニアの採用」と「QA活動の元となるドキュメント作成」に時間を割きました。
タックマンモデルに照らし合わせると、「形成期」になります。
あくまで参考用
1️⃣QAエンジニア採用 (求人掲載、面接、内定）
2️⃣担当プロダクトの理解
3️⃣QA組織の方向性資料作成
4️⃣開発部のメンバーにQAってこんなことをしますを周知
5️⃣プロダクトQAフロー作成
6️⃣プロダクトマネージャ、開発やインフラとどう関わり
7️⃣1案件トライアル
8️⃣リリース判定材料集め
9️⃣テスト計画を用意
🔟テスト設計
テスト仕様書
ケースレビュー
テスト準備
テスト実施
リリース判定
リリース
KPT（振り返り）
QAエンジニア採用 (求人掲載、面接、内定）
当時、社内の開発エンジニアが20名でQAエンジニアが4名採用の計画でした。
プロダクトによりミニウォータフォールやアジャイルが入り乱れている。
なので正確な人数を弾き出すのは難しく。
なのでQA人材は開発全体人数の2割ぐらいでしょうか。（当然、プロダクトや方向性にもよります。）グラフに人数が記載していないですが、4月（わたし）5月（わたし）6月に1名、7月も1名の計画でしたが実績が伴わず。
当然社内プロダクトは走っているのですから、しばらくは、外部のテストベンダーさんのお力を借りることになりました。
とりあえず計画だけでも提示
結論：4月と5月は、結果が残せていない。6月でやっと9月入社内定を出すことができ内定受諾まで持っていけました。
求人掲載では、どんなスキルをお持ちで、どんな経歴の方が良いのか。
（品質活動のご経験が長いとかテスト自動化経験が必須とか、育成枠だど自分のキャリアを見据えているとか）
そのため、QA採用ペルソナが大事になります。
また、どの採用媒体を使うべきかが悩みます。
QAエンジニアは他の開発エンジニアと同じ媒体を使ってもなかなか母集団を作れないのもあり。
媒体はこちらに纏めております。
面接は、お互いお話しして価値観や観点が大事なのかなと。
また、プロダクトに興味を持って頂くことも大事かなと思っております。
担当プロダクトの理解
担当するプロダクトについて、どんな製品なのか。
抑えておきたい機能や、現状の課題点/改善点を把握しチーム目標の一つとして設定。
BtoB、BtoC、BtoBtoC、SaaS製品だと、導入企業数・同業競合は？
また今後の事業計画や具体的な数値なども含めた説明。
QA組織の方向性資料作成
次に、経営層（ボードメンバー）に、特にCTOに対して。
社内でどのようにQA組織の方向性を示すかプレゼンをしたり。
計画案の承認をもらった上で、進めました。
なんとなくこんな感じだった？？
ロードマップをおおよそで作成（3ヶ月、半年、1年、3年、5年）し、ジョイン想定メンバー数でQAとしてのタスクを増やしていった感じですね。
当然、1名や2名では厳しいので。
先程の計画だけを提示し、開発エンジニアだけ増やしてもと。
開発部のメンバーにQAってこんなことをしますを周知
事業数値（ARR、MRR、NRR、Churn Rate）に触れ、どう改善するか。
ARRの成長率については、SaaS企業この数値が特に大事になります。
上記の事業数値を加味しながら、10枚ほどに纏めたQAプランを用意。
なぜSaaS企業にQA組織を置くべきかを語りつつ、メリット・デメリット。
メリットは、下記の6点（例でありますが）
1.お願いしたいことや、テストレベルによる不具合の可視化。
2.不具合1件につきこれだけの損失がありますよと見せる。
3.リリース後に見つかると、1件：数百万になることも。
（プロダクトや開発・人件費用にもよりますが）ここの数値もきちんと提示することでQAに対してのインパクトにもつながる。
4.テスト自動化も後々やりたいとか、1年後、こうありたいとかを懸命に話す（笑）
5.QA＝テストではありませんよを強く言った気がします。
6.QAはプロダクト全体のQA活動をし、テストはその一環であること。よく、QAは？QAは？ときく方がいますが、大概はテスト設計とテスト実施に対してのみしか考えておりません。
よってQAエンジニア採用も、採用観点がズレてきます。
誰でも良いわけではなく、SaaS企業での経験があり、QAとは何かを最低限理解している。テストケースだけ書ければ良いという理解だと、後々業務を振れなくなる恐れがあります。
デメリットも多少（これも例です）
1.不具合を全て無くすことは難しいというか無理。優先度なりを考える。
2.初期投資は、そこそこかかる。（特に人件費、ツール導入）
3.品質は、短期ではなく長期戦となる。
4.QAの理想論だけではなく、QA投資も考えた上で考える。（投資もせず品質を良くすることは、限界がある
プロダクトQAフロー作成
どこからQAが入るか（企画書のレビューであったり、単体テストのレビューであったり）、テストフローはどうするんだ？（計画書からリリースや運用、不具合分析）誰と誰が関わり、誰にレビューしてもらい、どのステータスになったら進めるのか。
JIRAチケットの切り方や、JIRAのステータスを更新した後、誰にアサインするのか？Slackで誰にメンションするのかなど。
プロダクトマネージャ、開発やインフラとどう関わり
プロダクトマネージャ、開発エンジニアやインフラエンジニアとどう関わるんだ？
定例会議は？
開発には、ここまでテストをしてもらいたいとか。インフラには負荷テストやセキュリティテストをお願いしたいとか。
負荷テスト計画はQAがやりますとか。
アジャイルであれば、スプリント計画、活動領域やMTGの設定、リリースなどなど。
何をゴールとするのか。
スピードと品質の考え方。
・デイリースクラム
・レトロスペクティブ
・リリースプランニング（プロダクトバックログ）
・スプリントプランニング（スプリントバックログ）
1案件トライアル
初めは、簡単な案件からやってみます。
そのあと、フロー改善をしながら回してみる。
改善点の見直し、具体的な手順を用意したりと。
リリース判定材料集め
自社のQAエンジニアって何をしているのかとテスト文化を根付かせるには - QAエンジニア blog
少々、長いタイトルになってしまいましたが「自社のQAエンジニア」って何をしているのか？？
プロダクトによって、リリースして良いものダメなもの。
どこまでQAに裁量があるかによりますが。
例えば、A、B、Cと分けて、Aのチケットはリリースしてはいけない。
Cであれば、今回のリリースでは影響がし少ないのでOKですとか。
当然プロダクトによって違うので、今までリリースを見直す必要がある。
テスト計画を用意
テスト 実装が完了し、リリースに向かって行うテスト 不具合の発生は主に、要件定義や設計書段階であり、検出は受け入れテ
qiita.com
・どんなテストをするのか（テストの種類）機能テスト、セキュリティテストや負荷テスト
・どこまで担保するのか（決めないと、最後でやったやっていないの問題となります）
・テストを中止する場合や再開する基準は（実施環境の設定不備）
・実行環境の確認（例「テスト環境」→「Staging環境」→「本番環境」での確認なのか？）
・テスト結果（「OK」はどこまでの範囲か、「NG」はどこからなどを決める）
・テストツールは使用するのか（使用する場合は、対象案件での使用メリットも記載）
・全体のスケジュール（定例MTGや、各テストの期間、実施担当者）
・組織図（プロジェクトマネージャーやQAマネージャ、QAリーダー、QAテスターの役割の明記）
・どのようなテストデータを用意するか
・仕様変更や、FIX決めの対応
・テストリスク（リスク発生頻度、重大度）と対策事項（リスクレベルの設定）はまとめているか
QAのスケジュールを提出（プロダクトPM）
現時点でのQAリソースとタスク工数
テスト設計
・仕様書から読み取れるレベル（仕様書有が前提）
※仕様書が無い場合、どこまで担保するか線引きをしておく
何をもって確認「OK」とするか、また「NG」とするか。各部署との確認を明確化する。無いからわかりません。やりませんでしたと無いように、テスト準備段階で確認する。
・内部構造を理解し設計するレベル（開発経験がある担当者）
・テスト経験者の勘や知識から実行する探索的テスト（※テスト担当者に依存する）
テスト仕様書
・設計書をもとにテストケースにおこす。もしくは要件定義から。
・無駄なケースが無いか確認する。直交表やAllpair法を使用し、必要なケースのみ。
・前提条件を必ず記載していること。レビュー者の負担もある。
・大項目、中項目、小項目、前提条件、操作方法は、わかりやすく。
※前もって、形式（テンプレート）については社内で共有しておくのがベストです。
レビュー
レビュー担当が誰かは予め決めておく。
PdMなのか、開発担当者なのか、QAなのか。
①机上レビュー
②対面レビュー
テスト準備
①テスト環境が用意されている(※テスト環境に不備がないかどうかも確認)
②Android検証用端末と実行用の「apkファイル」が用意されている
③iOS検証用端末と実行用の「ipaファイル」が用意されている(※リサインが必要であればこれも）
④不具合用親チケットが作成されている
⑤テスター用のアカウントが用意されている
⑥ステータス毎のテストデータが用意されている
⑦テストケースがレビュー済でレビュー修正されている
⑧使用WEBブラウザとバージョンが用意されている
⑨テストツール(Selenium、Jmeter、BurpSuite)が用意されている
※テストツール選定によって異なります。
テスト実施
①テストケースに沿ったテスト
②探索的テスト
③色々と状況にあったテスト
不具合対応
①仕様に沿ったものか
②実装した機能と定義書に差分がないか。そもそも漏れているのか。不具合かの判断も必要。
③チームでの決め事
リリース判定
①プロダクトリリースしても問題がない
（残りの不具合数、不具合の重み、テストケースの進捗度、不具合修正確認）
②リリースと品質の優先度具合
リリース
①本番で簡単に確認（時間を決めて）
KPT（振り返り）
アジャイルだとレトロスペクティブですね。
①良い点
②改善点
案件を回すことによって、そのプロダクトのQA活動がどこなのか？どうコミュニケーションしていくのか（周りのメンバー）
また、何が足りないのか？
簡単ではありますが、 0▶︎1 の組織はここからはじまります。
初めてのQA組織は難しい、そもそも何が正解かわかりませんが、この資料が参考となれば幸いです。