QA・ソフトウェアテスト研修【MIXI 26新卒技術研修】レポート

本記事は、MIXI株式会社の2026年度新卒向け技術研修で使用された資料（全191スライド）です。
ソフトウェアの品質保証（QA）の基本から、テストの考え方、実践的なテスト技法までを体系的に学べる内容となっています。マンガ家でもある登壇者・松谷峰生氏の分かりやすい解説が特徴です。

📑 記事の構成

1. QA（品質保証）とは何か
2. ソフトウェアテスト入門
3. テスト技法（ブラックボックステスト）
4. AI時代とテスト / おすすめ書籍

1. QA（品質保証）とは何か

品質の定義の変遷

品質とは何かについて、複数の定義が紹介されています。

クロスビー：「品質とは、要件に対する適合である」
ワインバーグ：「品質は誰かにとっての価値である」（テスト業界で人気の定義）
石川馨：「狭義の質（プロダクトの質）」だけでなく、仕事・サービス・工程など全てを含む「広義の質」を管理すべき
保田勝通：「品質とは、ユーザーにとっての価値（＝ユーザーの満足度）である」

品質保証の3つのアプローチ

松谷氏のオレオレ定義では、品質保証とは「ユーザーが満足できることを約束すること」。これを実現するためには、以下の3つの層にアプローチします。

対象	アプローチ	具体例
プロダクト	テストやレビュー	アプリの動作確認、コードレビュー
プロセス（作り方）	カイゼン	KPTでの振り返り、TDD、テスト自動化、コーディングルール整備、デプロイパイプライン構築
企業（ブランド）	品質文化の根付け・ポリシー策定	「MIXIのものだから安心」という信頼の積み重ね

重要メッセージ：「QA＝テスト」ではない。品質保証は特定の人のがんばりではなく、みんなで行う組織的な活動。「自分は作るだけ。後は任せた」という状態になってはいけない。

なぜプロセスが大事か：プロセスがイマイチだと、毎回ボロボロのプロダクトができあがり、ひたすらテストで打ち返すことになり、時間もコストもかかる。プロセスの質は、最終的にプロダクトの質・サービスの質として現れる。

ブランドは信頼の積み重ね

「⚪⚪社のゲームだから子どもでも楽しめるはず」「MIXIのものだから面白いはず」—こうしたブランドは、ひとつのプロダクトや1回のリリースで成り立つものではなく、信頼の積み重ねで成り立つ。

2. ソフトウェアテスト入門

2-1. テストの重要性

動かないソフトウェアが引き起こす問題として、以下が挙げられています。

経済的な損失
時間の浪費
信用の失墜
障害や死亡事故

具体例として2つの有名な事故が紹介されました。

事例1：Therac-25放射線治療機事故
操作ミスから発生モード変更時に内部の磁石位置フラグが更新されず、1回180ラドのはずが最大2万5000ラドが照射された。UIの問題（入力受付状態が不明確、エラーの意味が分からない）も重なった。

事例2：アリアン5型ロケット爆発事故（1996年）
64bit浮動小数点数を16bit符号付き整数に変換する際に32,768を超えてオーバーフロー。変換失敗のエラー処理が未実装で、主エンジンの噴射角度が最大に。HotStandby予備系も同じシステムだったため同時にダウン。損失は80億ドル。

2-2. テストの考え方

テストは「仕様通り動くかの動作チェック」だけではありません。以下の3つの活動があります。

活動	目的	イメージ
チェッキング	仕様通り・実装通り動作するかの確認	用意された道（仕様）を歩く。道にある石（バグ）には気づけるが、道から外れた石には気づけない
テスティング	新しい情報を発見するための探索	道なき道を探検する。「ここはこう動くなら、あそこはどうなる？」と問いを立てる
妥当性確認	要求に沿ったものが作れているかの確認	ユーザーのニーズを本当に満たしているか（チョコパフェにウニを乗せて大丈夫？）

マイヤーズの定義：「テストとは、エラーを見つけるつもりでプログラムを実行する過程である」

「正しい動作」にフォーカスすると一般的な操作に終始しがち。「バグを見つける」にフォーカスすると、イレギュラーな操作が増える。考え方ひとつで行動が変わる。

バグの多くは「忘れもの」

バグは開発の各段階で「忘れもの」として発生します。

要求→要件：要件定義漏れ、偉い人との認識齟齬
要件→仕様：仕様漏れ、PdMとの認識齟齬
仕様→設計：設計の間違い、影響箇所の把握漏れ
設計→実装：実装の間違い、実装の漏れ

仕様通りのチェックだけでは、仕様に書かれていない「小道」にあるバグは見つからない。ユーザーは様々な使い方をするため、本番でそのバグを踏むことになる。

2-3. テストレベル

テスト活動を系統的にグループ化したものが「テストレベル」。目的に応じて最適なレベルを選ぶことが重要。

テストレベル	対象	主な目的
コンポーネントテスト（ユニットテスト）	最小構成単位	ロジックのテスト（スタブ/モック使用）
コンポーネント統合テスト（結合テスト）	コンポーネント間	インターフェイスの相互処理
システムテスト	システム全体	振る舞い、全体的な能力
システム統合テスト	他システム/外部サービス	システム間の相互処理（管理システム連携など）
受け入れテスト	ユーザーのニーズ	妥当性確認

テストレベルで考える最適化の例：「Frontも通したシステムテストで全パターンチェックすると3日かかる」場合、ロジックの確認ならコンポーネントテストで、データ連携の確認なら結合テストで、とテスト目的に応じて最適なレベルを選ぶことで大幅に効率化できる。

3. テスト技法（ブラックボックステスト）

テストは時間とお金が有限。QCDF（Quality, Cost, Deliver, Feature）のバランスを取り、効率的に十分なテストケースを作るための技法。以下の5つの技法が紹介されています（今回はブラックボックステストが中心）。

3-1. 同値分割法（テストケースを合理的に少なくする）

同じ処理がされるはずのグループ（パーティション）にデータを分割し、各パーティションから1つの代表値をテストする技法。

有効パーティション：システムに受け入れられる値（例：1〜9）
無効パーティション：システムに拒否される値（例：0以下、10以上）

1桁の正の整数2個の足し算なら、81通り全てテストする必要はなく、各パーティションから代表値を選べば少ないテストケースで網羅できる。

パーティションは入力だけでなく、出力、構成、時間、インターフェースパラメーターなどからも識別可能。重複がなく、空でない集合でなければならない。

3-2. 境界値分析（バグを狙って見つける）

同値パーティションの境界をピンポイントで狙う技法。不等号の実装ミス（「>」と「>=」の書き間違い）や、アリアン5号のようなオーバーフローを発見できる。

2値BVA：境界値と隣接パーティションの最も近い値（例：0と1、9と10）
3値BVA：境界値と両方の隣接値（例：0と1と2、8と9と10）

3値BVAのメリット：「age >= 20」と書くべきところを「age == 20」と書いてしまった場合、2値BVA（19, 20）では発見できないが、3値BVA（19, 20, 21）なら age=21 で期待結果と不一致になり発見できる。

演習例（short int 16bit符号付き、if(a<0) と if(7<a)）の解答：

同値パーティション：-32769以下 / -32768〜-1 / 0〜7 / 8〜32767 / 32768以上（5個）
境界値：-32769, -32768, -1, 0, 7, 8, 32767, 32768（8個）

3-3. デシジョンテーブルテスト（漏れなくテストする）

ロジックを「条件」と「動作」に分けてマトリクス表で表現し、条件の全組み合わせを網羅する技法。条件が複雑に（AND/ORで）絡み合う場合に有効。

書き方の手順：

条件を抽出（例：水曜日か否か、22時以降か否か）
動作を記載（例：20%割引、10%割引、割引なし）
Y/Nを機械的に並べて全組み合わせを作る（条件が増えるごとに1→2→4→8→16…と倍増）
条件を見ながら結果を記入（当てはまる項目にX、当てはまらない項目に-）

デシジョンテーブルの最小化：同じ動作になる共通条件を持つルールはまとめられる。「-」（任意＝YでもNでも動作が変わらない）を活用して、テストケース数を減らす。注意：条件の処理順が記載順と同一の場合のみ最小化可能。

演習例（うるう年判定）：「4で割り切れる年はうるう年。ただし100で割り切れる年は平年。さらに400で割り切れる年はうるう年」という仕様でデシジョンテーブルを作成し、テストケース（2000年＝うるう年、2100年＝平年、2020年＝うるう年、2019年＝平年）を導出。

3-4. 組み合わせテスト（ペアワイズ法）

組み合わせが膨大になる場合に、テストケースを合理的に少なくする技法。

具体例：

装備4通り×装備3通り×ネックレス4通り×ブラウザ4通り = 192パターン → ペアワイズ法で18パターンに！
支払い手段4通り×期間2通り×モード4通り×OS4通り = 128パターン → 17パターンに！

なぜ減らせるのか：研究論文（Kuhn et al., 2004）によると、組み合わせのバグの大部分は2つの要素の組み合わせまでで説明できる。医療機器で97%、ブラウザサーバーで93%など。3因子間のバグは確率的にかなり低い。

田口玄一博士の著書では「1因子でのバグ発見率がρなら、2因子間はρ²、3因子間はρ³」と低減する。

ペアワイズ法は「2つの項目（因子）が全て組み合わされるように」テストケースを作る。確率の高い2因子組み合わせを網羅し、確率の低い3因子以上の組み合わせは捨てる戦略。

因子：項目（パラメーター）にあたる部分（例：IHコンロ、システムキッチン）
水準：値にあたる部分（例：なし、できれば、必須）

ツール推奨：ペアワイズ法で効率の良い組み合わせを作るのはツールがないとほぼ無理。GIHOZ（無料）というツールが紹介された。因子と水準を入力するだけでテストケースを生成。制約（禁則）の設定や、3因子以上への拡張も可能。

3-5. 状態遷移テスト（漏れなくテストする）

状態遷移図と状態遷移表をもとに、遷移パスを網羅してテストする技法。「コレからアレになったらどうなる？」という状態変化をテストしたい時に使う。

適用例：ログイン状態/非ログイン状態、エアコンのモード切替、画面遷移でのデータ保持/クリア、Therac-25のような問題も拾える可能性。

状態遷移図：状態とアクションによる遷移を図示。全体を俯瞰できる
状態表：状態と入力の関係を表で明確化。状態遷移図には現れない無効な遷移（N/A）を発見でき、仕様の抜け漏れ防止に有効

Nスイッチカバレッジ：

0スイッチカバレッジ：1回のイベントで遷移する経路を全て網羅（リンク網羅）
1スイッチカバレッジ：状態を一つ経由する遷移（2回のイベント）を網羅

選び方の目安：まずは0スイッチカバレッジを行う。怪しいところやバグがあった場合に1スイッチカバレッジを実施するか判断。「一度計測開始すると2回目以降スタートボタンで開始できない」「設定画面に戻って再度設定に行ったらデータが保存されていない」などは1スイッチでしか発見できないバグの例。

4. AI時代とテスト / おすすめ書籍

AIを使えば良いのでは？に対する松谷氏の考え

AI時代になっても、実現手段は変わるが「実現したい事、根本、考え方は変わらない」と強調。

活動	AIの得意・不得意
チェッキング	AIが使いやすい領域。ただし機械的に確認しづらいところは限界あり
テスティング	一般的な実装・設計ミスはAIで対応可能。ただし一般的でないドメイン知識やコンテキスト漏れはAIが気づけない
妥当性確認	自分たちが作りたいものを作れているかの確認は人間の仕事

テストレベル別のAI活用：ユニットテスト・結合テストはコードベースなのでAIが強い（ただしAIが書いたテストが妥当かのレビューは必要）。システムテスト以降はAIがどこまで手を伸ばせるかでコストが変わる。受け入れテストは人間の仕事。AI時代だからこそテスト技法を学ぶ意義は「AIが書いたテストが妥当か判断できるようになるため」。