スタートアップで非エンジニアが品質管理チームを立ち上げる時のメモ

はじめに

非エンジニアとしてQAを立ち上げたり小さなチームでの経験が多いせいか、立ち上げフェーズの相談をいただくことが多いので、内容のメモを共有します。

もちろん自分ですべて出来たわけではなく、失敗をして「次やるならこうする」というものも含んでいます。
また「自力で立ち上げた」というより「デキる人たちに導かれた」ことが多いので、社内調整的な修羅場も経験してません。

また「臨機応変に対応するか」が大事なので、全てが正しいというわけではありません。
読みづらくなるので断定的な語尾になってますが、あくまで「参考」としておねがいします。また、今後も加筆修正していきます。

一応「立ち上げる人」目線で書いていますが、経営者や開発リーダーでも参考にしていただけるかと思います。

想定している対象（ざっくり）

規模: 社員数は2桁
プロダクト: Web/モバイルアプリなどスピードが重視されるもの
期間: QAを1から立ち上げてから1,2年まで

必要なマインド

「保証」ではない
このメモでは便宜上「QAチーム」と言ってますが、スタートアップの場合「品質保証(QA)」でも「品質管理(QC)」でもないケースがほとんどです。しいていえば「品質改善貢献」「生産性改善貢献」でしょうか。

プロダクトをリリースしないと死ぬ
プロダクトを出していかないとスタートアップは死にます。魚が泳いでないと酸素を取り込めず死ぬのと同じです。まず「作るためのリソース」が優先されることは理解しましょう

QAがいなくても、新機能を早いタイミング出すことで宣伝になり、資金調達ができ、強いメンバーが入り、結果品質が上がるというサイクルもありえます。

新機能は出さなければ価値がゼロです。出したときのプラスがバグのマイナスを大きく超えるなら目を瞑ってリリースする判断も当然あります。ユーザー・社員・投資家は、一緒に夢を見る仲間でもあり、夢を見せる義務があります。マーケット、業種、フェーズを考慮した正しい判断が必要です。

また、自分に給料を払うのと開発者に払うのと、どちらが会社のためになるか？という経営者目線も持つといいです。

品質を上げる活動

テスト
リリース前の新機能のバグチェックがメインになります。「今リリースするんだけど、2,3分だけ見てくれません？」みたいなこともあります。
なので初期ではテストケースを丁寧に書く時間はないですが、余裕が出たらやったことをメモ程度に残すのはアリです。次回同じようなチェックの参考になります。

また、テストに慣れてない人の場合（あと時間もある場合）テスト対象のUIをベースにテストケースを作っていくと網羅的なテストはできます。
「こういう入力フィールドがあって、こういうボタンがあるから、こういう挙動がありえるな」とパターンを上げていくやりかたで、それほど難しくないです。ただ、チェック項目が増えすぎる傾向があるので注意しましょう。

最初はテストケースを書くツールはクラウド上のスプレッドシートで十分です（社内でG SuiteやOffice 365など使っている前提ですが）。編集や共有がしやすいメリットが大きいので、組織が大きくなってもかなり使えます。
将来、テスト管理専用のツールに移行するにしても、csvとして取り込めるものがほとんどなので、無駄にはなりません。

仕様決め段階からの品質改善

チームが小さくても、上流行程での活動はぜんぜんやれちゃいます。関係者を集めてやるリスク洗い出し会は超おすすめです。(参考スライド: freeeで僕がやっているリスク洗い出し会 )
テストケースが作りやすくなるだけでなく、プロジェクトの問題なども洗い出されるので、30分やるだけで未来の数十倍の時間が削減できることも多いです。ちなみにこの会は会社が大きくなっても効果的です。

自動テスト
ブラウザなどを動かす「自動E2Eテスト」は初期でも一定の費用対効果はあります。ただ、「非エンジニア」という前提だとSelenium IDEなどツールが限られますし、メンテの限界は来るのでコードベースのものへの移行は必要になります。
自分はSelenium IDEをきっかけにSelenium、Appiumをある程度書けるようにはなりましたが、プログラミングは好き嫌いはあるので、担当者は決めつけないほうがよさそうです。

エンジニアの力を借りる手もありますが「開発者だからいい自動テストを書ける」とは限りません。「ユーザーを理解している」かつ「メンテがどれだけ大変そうか」がイメージできないと、費用対効果が合わずに運用開始後に挫折することが多いです。ただ、環境構築などのワンタイム的なヘルプは効果的です。

また、（自動に限らずですが）「繰り返し行う系」テストシナリオ追加は、将来にボディブローのように効いてくる（時間を奪われる）ため、慎重になる必要はあります。たとえば前任者のテストケースを「これいらないから消す」と判断するのは非常に難しいです。テストを追加するのはペットを飼うようなものです。「ずっと面倒見れるかな」と自分に問いかけましょう。

ちなみに開発者に「こういうテストを追加したほうがいいですか？」と聞くと、ほぼ「お願いします」となるので（断るインセンティブが無い）、あまり聞かないようにしています。かわりに「リスク」を聞き取って対応は自分で判断するようにしましょう。

ツールの話でいうと、最近はメンテナンスを楽にしてくれるAIを使ったE2E自動テストのサービスが出てきたので、試してみる価値はありそうです。

情報の共有

プロダクトの状態の共有

品質についての情報共有も大事な仕事です。いろんな角度からの数字はあるに越したことはないですが、工数をかけすぎないよう、まずはユーザー報告のバグ件数だけで始めてもいいです。

自分の経験でいうと、普通に「今月のバグは〇〇件でした」と言ってグラフを見せても「今月発生したバグの件数」なのか、「現在直されずに残っているバグなのか」（会計でいうPL、 BSですね）の勘違いが必ずおきるので、この2つははっきり区別してしつこいほどに説明しましょう。

また、「バグ（現象）の数」なのか「報告件数」なのかも勘違いが起きやすいです。



成果の共有

これも無限に数字はとれますが（笑）、バグの流出を止めるチームを作りたいのなら、まずはシンプルに「リリース前に見つけたバグの数」を指標にしましょう。
「私達がいなかったらこれだけのバグが世の中に出ていた」というのは非常に説明しやすい成果です。
メンバー数あたり（もしくは人件費）の効果を説明できれば、チーム拡大の判断材料にもなります。

リスク洗い出し会など、上流行程で止めた問題は数値で示しづらいので注意は必要です。

守備範囲に入れるか悩ましいもの

スタートアップのメンバーは「掃除でも買い物でも何でもやる」という前提はあるとして、QAとして公式にやるか微妙なラインのものも上げてみます

バグ起票でサポートと開発の間に入る？

バグの傾向を把握するのはQAの仕事になります。ただ、その流れで、チケットに「仕様です」と返信したり、サポート・開発間のやりとりをスムーズにする仕事は、感謝はされるもの時間も無限に使えてしまいます。また、インパクトも数値化しづらいので注意は必要です。


バグの重要度・優先度の定義？

「こういうバグはこう扱うべき」と定義したほうがいいか、もよく議題にあがります。
これ系は細かく定義を決め始めるとキリがありません。例えば「レイアウト崩れは優先度下げる」と決めても「メインの画面がめちゃめちゃになっていたら？」となります。
それらのパターンを挙げていくうちに、誰も読みたくない巨大なドキュメントが出来る可能性もあります。
初期フェーズでは細かな定義づくりに時間を割くよりは、「これはヤバい」「そうでもない」という感覚を全社員で共有することが大切です。

チームづくり

チームの思想
スピード感は当然持つとして、見落としがちなのは「変化に強い体制」です。人が一人抜けた瞬間に回らなくならないよう、「情報共有はオープンかつ積極的に」「ツールやワークフローフローでロックインされないように、柔軟性のある体制」「細かいルールで縛るのではなく行動指針を決め、裁量を持って動く」などが必要です。
ま当然PDCAを細かく回すことも大切で、半年くらい変わってないルールがあれば一度疑ってみましょう。
また、コミュニケーションについては前回のnoteで書いていますので参考にどうぞ。


どんな人がいいか
はじめに書いた「必要なマインド」があればQA経験者じゃなくても大丈夫です。サポートメンバーなど、ユーザーやプロダクト理解があり熱い思いがある人はすぐ貢献できるはずです。
逆にいうとテストという業務に思い入れが強くてもプロダクトに興味がない人はフィットしないです。

契約周り
（ここの経験は浅いのでさらっといきます）
スモールスタートでの新規メンバーを追加する時は、アルバイトの方もおすすめです。また、派遣社員（派遣会社で「テスト・評価」という職種でお願いできる）という選択肢もありますが、コストは結構かかるので急ぎかつ短期の場合がいいかと思います。
また、テストを専門にしている業務委託もコストがかかるので立ち上げ期では難しいかもしれません。
専門の業者に入っていただくと「教科書どおりのフローを知れる」というメリットはあります。ただ、いろんな顧客でも対応できる汎用的な仕組み（服で言ったらフリーサイズ）になっていることが多いので、自分の組織ではどう合わせていくべきかは意識する必要があります。


最適な人数
これはよく聞かれますが、業種やマーケット・チーム体制にもよるので、「分からない」と答えています。0よりも1がいいと確信できるのなら始めてみて、徐々に大きくするのがいいでしょう。
ある程度になったら、同じようなフェーズの同業他社（海外も含む）の情報を参考にするのはありだと思います。

メンバーのロール
最初は一人で何でもやるとして、2人、3人と増えたときも全員がいいテストケースを考えて実行までできる、というのが理想です。ただ、急に大きな案件が入ったときなどは、詳しい人がある程度きっちりテストケースを作り、実行者を増やして（サポートや開発者の手を借りたりして）実行するようなスケールアウトができる体制だと理想です。

また、大きなプロジェクトではテストの実行管理（「あなたは今日この辺を見てください」とお願いしたりコミュニケーションの手伝いをする人）も必要になってきます。テストを作った人がやるのが自然ですが、かなり好みが分かれる仕事なので配慮は必要です。

メンバーの評価

評価が難しい職種なので多角的な判断が必要です。数字も取りつつ、QAチーム内外のヒヤリングも重要です。（ただ、気前よくリリースOKを出す人が高評価されたりするることもありえるので、ソースのバランスを取ることは重要です）

また、業務の対象範囲をクリアにしておくことも大事です。大きな新規リリースだけを見ているのか、他の細かい案件もあるのか、QA以外の業務もあるのか、などざっくりとでも割合を把握して参考にしましょう。

メンバーの成長

プロダクト・ドメイン知識
複雑・特殊な知識が必要なプロダクトの場合は常に学び続ける姿勢は必須です。ただ、法律などの決まりごとを覚えるというよりは「ユーザーが何を解決したいのか」を理解するほうに時間を使いましょう。

開発の知識
これもアウトプットに大きく影響します。単純にプログラミングができればいいという話ではなくて、プロダクトがどういう作りで、どういう流れでリリースされるか、を理解するのが大事です。

自分は「〇〇分で作れる✕✕」みたいな記事をみて一通りやってみるようにしています。 Ruby on Railsアプリの担当の時は遊びでサンプルっぽいWebアプリを作ってみましたし、モバイル担当の時は、iOS・Androidアプリを作りました。（これはくだらなすぎてリンク貼れない）
そのときは、できるだけ開発チームで使っているCIやデプロイ環境を使ってみるのがおすすめです（個人だと無料で出来るサービスも結構ある）。
開発者の会話が徐々にわかるようになってきて、それがリスクに対する判断力も上がっていきます。

業務効率化
ソースコードの管理ツール・バグ管理ツール・スプレッドシート・チャットツール連携などの連携ができるようになると、QA業務の生産性があがりさらに純度の高い品質改善活動が行えます。G Suiteを使う会社ならGoogle Apps Scriptあたりから始めるのがおすすめです。

データ分析
バグ・問い合わせのデータ分析も自分で出来るに越したことはないので、SQLをやるといいでしょう。複雑なクエリがかけなくても、既存のモノを参考にして書くレベルでも（自分はこのレベルです笑）、やれることはかなりあります。
また、プロダクトのデータベースの理解が深まる副次効果もあります。（QA初心者が思っている以上にデータベースはプロダクト品質と密接な関係があります）

最後に

QAは成果の共有が難しい職種ですが、シンプルな数値でいいので可視化を進めましょう。経営者から見ても「なんか頑張ってるのはわかるんだけど、効果が分からないんだよなー」というチームには投資はできません。

また、地味な作業連発で苦しくなった時期も、使っていただいているユーザーをイメージして「自分は世の中の役に立っている」という言い聞かせます（自分もしょっちゅうやってます 笑）。

品質改善をする人も立派なクリエイターです。誇りをもちましょう。
そしていいリリースができたら仲間としっかり打ち上げをして、明日の原動力にしていきましょう！