はじめに
2026年4月、CBcloud株式会社に「1人目QA」として入社しました。ここではリボ核という名前で進めさせてください。この記事は入社から2か月弱の時点で書いています。
ジョインした段階でQA組織はなく、専任のQAエンジニアもいない。テスト関連の資産として残っていたのは、過去に外部委託で作られた一式の資料でした。
面接で聞いた採用の背景も率直でした。実装が終わった後にテストが始まり、そこから質問が都度飛んでくるので開発が止まる。——だから0から基盤を作って品質を上げてほしい。つまり最初に与えられたミッションは「テストをすること」ではなく、「開発を止めずに品質を上げる構造を作ること」 でした。
この記事は、その資料を全部捨てるところから始めた話です。ここでいう「捨てた」は、過去の証跡を物理的に削除したという意味ではありません。リリース判断に使う現役の品質保証資産としては採用しない、と判断したという意味です。ただし、構築ノウハウの話はほとんどしません。1人目QAにとって本当に最初に必要なのは、ツールでも自動化でもなく思想だった、という話をします。
外注QAの資料を全部捨てた
ジョインしてまもなく、引き継いだテスト資料を20分で読み、捨てる判断をしました。そして今回、このQiita記事を書くためだけに、分析がてら実施済みのテストを確認し直しました。あるリグレッションテストのExcelを例に、観測した事実だけを並べます。
そもそも完了状態を説明できなかった
- 総項目数は数千件規模。うち8割以上が「未実施」のまま放置されていて、最後まで実施されたシナリオは全体の1割程度だった
- しかも集計シート自体が壊れており、母数より未実施数の方が多い行があった。「どこまでテストされたのか」を正確に答えられる人は、もう存在しなかった
実施しても保証範囲を説明できない設計だった
- 資料の冒頭に「入力した内容が反映されることがメインのテスト観点」と明記されていた。実際、期待結果の大半は「入力した内容と一致していること」「画面が表示されること」——手順通りに操作すれば論理的に「落ちようがない」、入力エコーの確認だった
- 1シナリオ数百ステップの一本道E2Eで、どのテストケースがどの仕様・どのリスクをカバーしているのか、根拠をたどる手段がなかった
保守可能な資産としては扱えなかった
- パラメータが1つ違うだけで中身は同一ステップのシートが、コピペで10枚以上量産されていた。概要欄に複製元のシート番号が残ったままのものもあった
- 「(旧)」「工事中」「WIP」と書かれたシートが本番のシナリオと混在し、参照エラーや「◯◯セルと一致していること」という記入前のプレースホルダがそのまま残っていた
- 資料が参照している仕様と、実際のプロダクトの挙動がすでに乖離していた
これらを個別に「ひどい」と評価するつもりはありません。公平のために書くと、すべてが機能していなかったわけでもない。別の案件のテスト方針資料では、仕様の境界を1件ずつ開発者に確認した質問の記録が数十件残っていて、不具合の管理台帳も回っていました。実施当時、現場が真面目に働いていた形跡ははっきりあります。
それでも、期待結果が入力エコーで、カバレッジの根拠がなく、8割が未実施で、現行仕様と乖離した資料について、「この資料は何を保証しているのか」を説明するのは難しいはずです。例えば、テストケースの期待結果が「実機が正です。」となっている場合、それはリリース判断に使える保証ではなく、確認行為の記録に近い。問題は個々人の能力や態度ではなく、「保証を説明できる構造」が最初から存在しなかったことです。
私はこの資料群を、リリース判断に使う現役資産としては採用しないと判断し、oldフォルダに退避しました。理由は後述します。
思想①：テストが機能していなくても、組織は即死しない
ここで不思議なことに気づきます。テストが実質的に機能していなかったのに、プロダクトは動いていて、事業も回っていた。なぜか。
残っていたログや話を聞いて解剖すると、だいたいこうなりました。
- 開発者の頑張りと注意力が、本来テストが受け持つべき領域を肩代わりしていた
- 障害が起きても「QAプロセスの欠陥」とは認識されず、個別の実装ミスとして処理されていた
- ドメイン知識が濃い長期メンバーが、レビューの中で暗黙的に異常系を潰していた
つまり、品質は保証されていたのではなく、属人的な努力と運で支えられていた。そしてこの構造は、組織が小さいうちは案外もちます。即死はしない。
だからこそ1人目QAは、ここから逆算して自分の存在意義を定義する必要があります。「テストを実行する人」が欲しいだけなら、あの検証不能な資料の山をもう一度作るだけです。個人の頑張りと運に依存している品質を、組織の能力に置き換えなくてはなりません。属人化は効率と冗長性のトレードオフです。品質的には過剰ではない程度に属人的であるべきだと私は考えます。
思想②：品質保証とは「証跡と判断基準を残すこと」
テストの実行は、品質保証にはなりません。本体は次の2つだと考えています。
- リリースしてよいかの判断基準を、テストの前に明文化すること
- その判断に使った証跡と、保証しなかった範囲（残余リスク） を残すこと
これを痛感させられたのも、例の外注資料でした。ある案件の進捗管理表は、全テスト観点のステータスが「完了」になっているのに、項目数やOK/NGの集計は外部ファイルへの参照切れで全滅していて、完了報告には進捗率0%のままの数字が残っていました。関数を直してやっと動いてくれます。進捗管理や不具合台帳を見る限り、実施当時はちゃんと回っていたはずなのです。それでも今となっては、「何をどれだけ確認して完了としたのか」を資料から復元する手段がない。テストは実行されたのに、保証は何も残らなかった。実行と保証は別物です。
私はリリース判断を Go / Conditional Go / No-Go の3値で定義しています。訳すなら リリース可能 / 条件付きリリース可能 / リリース不可 です。ポイントは Conditional Go で、「この欠陥とこのリスクを受容した上で出す」という状態を、なかったことにせず記録に残す。
これをやると、組織の会話が変わります。
- 「テストしました」→「何を保証して、何を保証していないかを言える」
- 「本番障害が出た」→「受容済みの残余リスクか、保証範囲の抜けかを区別できる」
- 「リリースしていいですか」→「ゲート(後述)の条件に対して、今どこが満たせていないかを示せる」
1人目QAが最初に作るべきもの——最小の手数で品質保証を実現するために必要なもの——は、テストケースではなくこの判断の構造だと思っています。そもそも全数テストは不可能なのに実施しないテストケースの作成コストは誰が払っているのでしょうか。
思想③：負債は直すより捨てる
外注資料を補修しなかった理由です。
判断基準はシンプルで、「修復コスト ＜ 作り直しコスト」が成立するか、それだけです。期待結果がない・カバレッジ根拠がない資料は、1ケースずつ仕様に照らして検証し直す必要があり、それは実質ゼロから設計するのと同じ工数がかかります。同じ工数なら、トレーサビリティのある構造で作り直した方がいい。
もう1つ大事なのは、「資料がある」ことと「資産がある」ことは別だという認識です。検証不能な資料は資産ではなく、むしろ「テストされている」という誤った安心感を生む分だけ技術負債です。捨てることで初めて、組織は「今は何も保証されていない」という正しい現在地に立てます。
損切りは怖いですが、1人目QAの初手としては、検証不能な資料の延命よりも、「今あるプロダクトの状況」や「開発スタッフの健康状況」という正しい現在地を押さえることの方が、はるかに価値があります。
思想④：QAは開発を止めない——ゲートは後ろではなく前に置く
採用の理由が「テストが開発を止めているから」である以上、同じ構造を再生産したら無意味です。SaaSは顧客へのデリバリーを行うまでのスピード感も重要な要素の一つです。だから取れる手法は必然的にシフトレフトになります。私はいわば波動吸収する形で入ったとも言えそうですね笑
私の現在のスタンスはDevOpsの思想に乗ったQAOpsです。1人目QAとして、開発フロー全体に伴走する。具体的にはこうしています。
- 後出しの質問をしない：仕様の疑問は要件定義・仕様書の段階で潰し切る。実装後に開発者を止めて聞くことを、構造的になくす
- 自明なテストはやらない：論理的に落ちようがない確認や、見てわかるレベルの画面の変更。影響度が軽微で、変更差分と影響範囲から追加確認の価値が低いと判断できるもの。コード変更のたびに全シナリオを回すような無意味なテストは実施しない。「やらない」ことを明言するのもQAの仕事です
- 機能とリスクに絞る：機能面に着目し、影響度の大きい変更だけをリスクベースで提案する。これは開発側に「どこが危ないか」の意識を持たせる効果もある
- ゲートは前に置く：要件定義・仕様書が固まった段階で、TDDの考え方と同じように、テスト設計とテストケースをこちらで先に作り切る。実装は「先に置かれたハードル」を越える形で進む。ゆくゆくは要件定義でも積極参加をしたいですが、２ヶ月弱であることや、QAは距離を置くことも大事ですので一旦経過観察をしています。
ゲート（Go / Conditional Go / No-Go）は開発の最後に立ちはだかる関所ではなく、最初から見えているハードルとして置く。これが「品質保証はスピードの敵」という誤解への、私なりの答えです。
よくある反論は「とはいえ、テスト設計やテストケースの作成に時間がかかるのでは？」です。もちろんゼロではありません。ただ、型があれば「開発を止めるほど重い作業」にはなりません。テスト設計の型はCodex/Claude対応の自作スキルに落としてあり、最短20分、長くても2時間でテスト設計とテストケースを作り切って開発者に渡しています。正常系/異常系も網羅しており、中途半端な成果物を渡しません。自身もゲートを課しているというわけです。しかもこの過程で仕様書の穴が見つかるので、コメントで先回りして追記する。テストで不具合を「検出」する前に、不具合の「作り込み」自体を先に潰せるので、テストケースを必要以上に厚く作る理由がなくなり、案件の期間に応じた軽さで足ります。
そもそも私は1人目QAで、限られた時間とリソースの中、自動テストを大量に実行したり、手動テストを大規模に実施したりできる体制ですらありません。だから、大量にケースを書いて大量に実行し、消化率で語る方式は、最初から捨て切っています。
実装：思想を基盤に落とす
思想が決まると、実装の順番は自然に決まります。私の場合はこの順でした。
- 思想：QAの存在意義とリリース判断の考え方を言語化する（上記）
- 設計標準：テスト観点の導出方法（同値分割・境界値・状態遷移・リスクベースの優先度付け）を型として固定する
- 証跡の残し方：観点→リスク→ケース→ゲート判定→残余リスクが一本の鎖でたどれるフォーマットを決める
- ツール選定：最後にツール。テスト設計の型は自作スキル群に、コード変更からゲート判定への接続は同じく自作のスキルに落としています。
ツールの手順解説自体は、この記事の主題ではないので深掘りしません。ここで言いたいのは順番だけです。私にとっては「思想の実装例」であって、先にツールがあったわけではありません。逆順（ツール→思想）で入ると、ツールにできることが保証範囲の定義になってしまい、外注資料と同じ構造の負債が生まれます。
結び：1人目QAへの提言
1人目QAとして入ると、最初に「自動化はいつできますか」「ツールは何を入れますか」と聞かれますし、私自身もやりたくて仕方ありません。気持ちは分かりますが、その問いに先に答えてはいけない、というのがこの記事の結論です。
- ツール選定やテスト自動化から入らない。成熟度や開発体制に応じたテストプロセスの整備を優先する
- まず「自分たちは品質の何を信じ、何を証跡として残すか」を決める
- 判断基準（Go / Conditional Go / No-Go）と残余リスクの記録を、テストより先に設計する
- テスト設計は実装の後ではなく、仕様が固まった瞬間に作り切る。ゲートは後ろの関所ではなく、見える前方にあるハードルとする
- 検証不能な資料は資産ではない。直すより捨てる勇気を持つ
で、思想を決めて作り直した基盤は、いまは普通に回っています。構築の詳細はそのうち別の記事で書くかもしれません。
ここまで読んでいただきありがとうございました。
最後に：CBcloudで一緒に働きませんか
ここまで読んで、こういう品質保証の作り方に少しでも面白さを感じた方へ、少しだけ宣伝です。
CBcloudは、入社2か月の1人目QAに「思想から作り直す」裁量を渡してくれる開発組織です。物流という社会インフラを支えるSaaSを、このスピード感のまま一緒に作ってくれるエンジニアを募集しています。もちろん、QAエンジニアもです。