この記事は Akatsuki Games Advent Calendar 2025 11日目の記事です。
アカツキゲームスサーバーエンジニアの @haruby863 です。
自動E2Eリグレッションテストの運用をしています。
CEDEC 2025にて 「長期運営ゲームをあと10年続けるための、0から始める自動テスト ~4000項目を50%自動化し、月1→毎日実行にした3年間~」(発表資料) で登壇させていただきました。
この発表の際にご質問をいただいた、レポートや通知の具体的な内容についてご紹介します。
現在2種類のレポートを使用して運用しています:
Airtest内蔵のレポート
Slack通知でのレポート
この記事は Akatsuki Games Advent Calendar 2025 10日目の記事です。
QAエンジニアの山﨑(@tomo_tk11)です。 私のチームでは、生成AIを活用した業務効率化や、品質保証プロセスのシフトレフトに取り組んでいます。
今回は、運営型モバイルゲームの開発において避けては通れない「マスターデータ」の品質を、生成AI（GitHub Copilot / Claude）*1を活用してどのように高めていくか、という事例を紹介します。なお本事例は、学習データとして利用されないオプトアウト設定済みの環境で行っています。
運営期間が長いタイトルほど、その裏側にあるマスターデータは複雑怪奇な進化を遂げがちです。 サービス開始当初はシンプルだったテーブル構造も、数多のイベントや新機能の実装を経て、「この表現をするためにカラムAに特殊なフラグを立て、カラムBにはJSONを入れる」といった複雑な運用ルールが積み重なっていきます。
こうなると何が起きるか。「人の認知限界」を超えてしまいます。
ドメイン知識を豊富に持つベテランプランナーなら回避できる落とし穴に、チームにジョインしたばかりのメンバーは為す術なく落ちてしまい、結果として設定ミスによる不具合が混入します。 それを防ぐQAチームもまた、テストを行うために高度なドメイン知識が要求され、疲弊してしまいます。
「人の理解を超えた複雑なデータを、人が目で見てチェックする」
これには限界がありますし、何より関わるメンバー全員が辛い状況になりがちです。
そこで、AIを活用して品質と生産性を向上させる方法はないか？ と模索した結果、一つの解に辿り着きました。
AIを活用しようと考えた際、最初に思いつくのは「詳細な仕様書やルールブックをAIに読み込ませる」ことかもしれません。 しかし、私はその道を選びませんでした。理由は単純で、「ドキュメントをメンテナンスしたくないから」 です。
マスターデータは生き物です。日々変化する仕様に対し、ドキュメントを常に最新に保つコストは計り知れません。古いドキュメントをAIに参照させれば、それは嘘を教えることになってしまいます。
では、「絶対に嘘をつかない最新の情報」 はどこにあるのでしょうか？ 私は、答えは以下の2つだと考えています。
「こういうデータを設定したい」という意図に対し、AIには「スキーマ定義ファイル」と「過去のマスタデータファイル」を探索させ、そこからルールを逆算してもらいます。
必要な情報がどこにあるかという「地図（指示書）」 だけを渡し、あとはAgentに任せる、これが今回紹介したいアプローチの肝になります。
ここで一つ、疑問が浮かぶかもしれません。「AIに参照させるための『指示書（プロンプト）』を書くのが大変ではないか？」と。 複雑なテーブル構造やリレーションのルールを、人間が一つ一つプロンプトに書き起こしていては、それこそドキュメント作成と同じ手間が発生してしまいます。
そこで、その「指示書（地図）」の作成自体もAIに行わせています。指示書の型さえ決まればメタプロンプトによる指示書の自動生成を行うことができるので、抽象度の高さは重要視しています。
実際に私が使用しているプロンプト（指示書）の設計を紹介します。 ポイントは、テーブル単位ではなく「運用仕様（やりたいこと）」 単位で指示書を作成することです。今回は、ゲームによくある「ミッション機能」の運用を例にお話しします。
作業を開始する前に、AIに対して「どのファイルを、どのような観点で読み込むべきか」を定義します。
# ミッションデータ設計・検証用 AI Agent 指示書 ## 役割(Role) あなたは熟練のデータ設計スペシャリストです。DBスキーマと過去のマスターデータを参照し、正確なデータ設計・検証を行います。 ## 事前準備：データ参照先の学習 作業開始前に、以下の情報を読み込んで「ミッションデータの構造」と「実運用ルール」を学習してください。 ### 1. 構造の理解（スキーマ定義） **参照先**: データベース定義ファイル（スキーマファイルなど） **確認内容**: - ミッションを構成するテーブルの定義 - 各カラムのデータ型、NULL制約、デフォルト値 ### 2. パターンの学習（実データ） **参照先**: 現在稼働しているマスターデータのリポジトリ（CSV/JSON/YAMLなど） **学習内容**: - ミッション系テーブルに入っている実際のデータ - 報酬設定の組み合わせパターンや、説明文のフォーマット ### 3. リレーション解決ルールの定義（IDの逆引き手順） **目的**: ミッション条件に設定されたIDと、ユーザー向け説明文の整合性をチェックするため。 **探索ルート（例: 特定コンテンツの達成条件の場合）**: 1. ミッションデータの条件値から `target_content_id`（対象コンテンツID）を取得 2. `contents_master`（参照先テーブル）を参照して `id`が一致するレコードを特定 3. そのレコードの `content_name`（コンテンツ名称） を取得 ## データ参照の優先順位 1. **最優先**: スキーマ定義 (構造の絶対的な真実) 2. **第2優先**: 実マスターデータ (実際に使われている正解パターン) 3. **第3優先**: ロジックコード (ビジネスロジック上の制約)
このように、単に「データを作って」と言うのではなく、「リレーションの辿り方」や「参照ファイルの優先順位」を明確にした指示書（地図）を読み込ませた上で、以下の3つのアプローチを実行します。
プランナーが「こういうイベントミッションをやりたい」と思いついた時、データ構造やロジックの観点から実現可能性を即座に判定させます。
## 概要 **目的**: 企画案の実現可能性を判定し、実現可能であればマスターデータ案を提示 ### 実行手順 1. **スキーマ定義**で関連テーブルの構造を確認 2. **過去のマスターデータ**から類似するミッションタイプを検索 3. 必要に応じて**ビジネスロジック**を確認し、制約を把握 ### 入力形式 企画案を自然言語で記述 （例：「指定のコンテンツを、特定の条件（種別や属性など）を満たす対象を用いて10回達成する」） ### 出力形式 **判定**: [可能 / 条件付きで可能 / 不可能] **根拠**: - スキーマ上の制約（必要なカラムの有無） - 過去データ内の類似実装例 - ロジック上の制限事項 **懸念点**: - パフォーマンスリスク - 複雑すぎる条件設定による不具合リスク
単に「できます」と答えるだけでなく、「過去に類似事例があるか」「スキーマ的に無理がないか」を根拠に回答させる点が重要です。これにより、実装不可能な企画がデータ作成段階まで進んでしまう手戻りを防げます。
ここが最もQAコストを下げられる部分だと感じています。単なる型チェックだけでなく、「意味的な整合性」 まで踏み込めるからです。 例えば、「特定のコンテンツ『A』を攻略する」 というミッションの場合、データ上の設定ミスにより、内部で指定している参照IDと、ユーザーに見せる説明文の内容が食い違っていることがあります。 これを人がチェックするには、IDから参照先の定義テーブルなどを跨いで確認する必要がありますが、AIなら一瞬で判断できます。
## 概要 **目的**: 作成したマスターデータの整合性を検証し、問題があれば指摘 ### 入力形式 新規マスターデータ（CSVまたはJSON形式） ### チェック項目 **1. スキーマ整合性**: - カラム定義、NULL制約、データ型、カラム順序の遵守 **2. 外部キー参照**: - 設定されたIDが、参照先テーブルの実データとして存在するか **3. JSON構文と論理**: - 達成条件を記載するJSONカラムの構文エラーチェック - 該当するミッションタイプで使用可能なキーが含まれているか **4. 過去データとの整合性（外れ値検出）**: - 報酬量や数値設定が、過去の類似データと比較して極端に逸脱していないか - 日付の前後関係（開始日が終了日より前か） **5. 高度な整合性チェック（リレーション逆引き）**: - **例：特定コンテンツ参照型ミッションの整合性** - 手順: 条件定義内の `target_content_id` をキーに、参照先の `contents_master` テーブルを逆引き - 検証: ミッションの `description`（説明文）に記載された「コンテンツ名称」が、逆引きした実情報と一致しているか確認 - 判定: 不一致の場合は「説明文と設定IDが食い違っています（IDはXXを指していますが、説明文はYYになっています）」と警告を出力 ### 追加ルール記述欄 ※ 絶対にバリデーションしたいルールがある場合は、ここに追記してください。 ※ 基本的には過去データから自動的にルールを理解します。 ### 出力形式 **判定**: [OK / NG / WARNING] **指摘事項**: - [カテゴリ] [エラー箇所]: [修正案またはエラー理由]
「IDは正しいが、コピペ元の説明文が残っている」「報酬の桁を間違えている」といったミスは、人間が大量のデータを目視していると見落としがちです。 AIに「データが意味するところ（Semantics）」を解釈させ、レビューさせることで、こうしたヒューマンエラーを機械的に検出できます。
過去のデータ（実データファイル）は、最高のテンプレートです。AIに面倒な一括変換やID採番を任せることで、プランナーは「値の設計」に集中できます。
## 概要 **目的**: 既存データをベースに、変更点を反映した新しいマスターデータをCSV形式で生成 ### 入力形式 **ベースデータの指定**: - ベースとして利用するデータのID **変更点**: 自然言語で指示（例：「イベントIDを変更」「報酬をアイテムXに変更」） ### 実行ルール **1. アイテムIDの調査**: - 指示された「アイテム名」から、アイテムマスタを検索してIDを特定する - 見つからない場合は `[要調査: アイテム名]` として出力 **2. ID採番ルール**: - **重要**: 既存データの最大IDを確認し、重複しないように連番で採番すること - ユーザーがIDを指定しない場合は、「新規IDの開始番号は〇〇からで良いですか？」と確認を求める（勝手に採番して重複させないため） **3. CSV/JSON出力フォーマット**: - 区切り文字: タブ（`\t`） - NULL値: `NULL` または空欄 - **JSONのエスケープ処理**: - JSONフィールドはダブルクォートで囲む - 内部の `"` は `\` でエスケープし、改行なしの1行で出力すること ### 出力形式 以下のテーブルをCSV形式（ヘッダーあり）で出力: ※ ミッションに関連するテーブル名を指定してください
複雑なJSONの変更やミッション開始時間の一括変更を手作業でやるとミスが頻発します。 「フォーマットはAIに任せ、人は中身（企画意図）だけを指示する」という分業により、データ作成の速度と品質を同時に向上させることができます。
今回紹介した事例で最もお伝えしたかったのは、AIアプローチそのものではなく、AIへの情報の渡し方（コンテキスト設計） についてです。
運営型モバイルゲームのように仕様が絶えず変化する(追加される)環境において、AIに「現在の正しいルール」をすべて教え込もうとするアプローチはあまり取りたくありません。プロンプトに細かな仕様を書けば書くほど、そのプロンプト自体のメンテナンス性が人の限界を超えてしまうからです。 だからこそ、アプローチを変える必要があると考えています。
この「地図を渡す」というアプローチの最大の利点は、高い汎用性と拡張性 にあります。 今回は「ミッション」を例にしましたが、この手法はログインボーナスやコンテンツ報酬設定など、あらゆる機能に適用可能です。なぜなら、どのような機能であっても、そこには必ず「スキーマ（構造）」と「過去データ（実例）」が存在するからです。
私たちが設計すべきは、個別のルールではありません。AIが自律的にリポジトリ内を探索し、ロジックを逆算するための「探索ルート」 です。
「正解は常にコードとデータの中にある」。
この前提に立ち、AIを「データを検索・模倣・検証するAgent」として振る舞わせることこそが、複雑化・巨大化する運営開発において、品質と速度を維持し続けるための普遍的な解になるのではないか、と信じています。
この記事が、複雑なマスターデータと戦うプランナーやQAの皆さんの助けになれば嬉しいです。
*1:要件を満たせばCopilotにこだわる必要はありません。
こんにちは！ アカツキゲームス クライアントエンジニアのSuです。
この記事は Akatsuki Advent Calendar 2024 11日目の記事です。
昨日の boke0 さんの踊り文字についての記事は面白かったです。一歩一歩 → 一歩々々という書き方は初めて知りました。とても勉強になりました！25日の解決編も楽しみですね！
自分は学生時代からエディターの拡張に興味があり、Blenderエディターの関連研究も少し関わりました。現在もチーム内のクリエイターさん達が効率的に作業できるように改善活動を日々頑張っています。
今回はデザイナーさんからちょっと複雑な自動化要望があったので、Photoshopスクリプトを書いてみました。本記事はPhotoshopスクリプトを書くための環境構築、デバッガー、実際に書くの流れを紹介したいと思います。
Photoshopの中にすでに自動化機能があります。簡単かつ重複的な操作ならアクション、バッチ、変数・データセット機能でカバーできると思いますが、もし操作が条件によって分岐したい場合、スクリプトを書くには一つの手と思います。
ここの「スクリプト」というのは、Adobe社が開発したスクリプト言語および関連ツールキット ExtendScript です。ベースは ECMAScript 3 なので JavaScript や ActionScript に似ている。Photoshop、InDesign、After Effects などのアプリケーション内のツールにアクセスしてプロジェクトをバッチ処理することができます。
テキストエディターさえあれば書けますが、快適に書ける方法を紹介します。
公式拡張機能があるので、エディターは Visual Studio Code がおすすめです。
自動補完が大事なのでまずは IntelliSenese ですね！こちらの動画を参考しました。
下記の ExtendScript の TypeScript をプロジェクトフォルダに入れて、jsconfig.json ファイルを設定し、IntelliSenese を実現する方法です。
現在、Apple Sillicon ネイティブでデバッガーを実行できないため、Intel 版の Visual Studio Code をインストールして Rosetta で起動する必要があります。
Mac → zip「Intel chip」の方をダウンロードし、展開した実行ファイルを Visual Studio Code(Intel) にリネームして実行します。
次は「ExtendScript Debegger」という拡張機能をインストールします。現時点最新の v2.0.3 は自分の環境で問題なく動きました。
VSCode のデバッグボタンをクリックします。launch.jsonを作成します。
ExtendScriptを選択します。
launch.json が作成されて、左のパネルに「Launch Script in ExtendScript Engine」の選択肢があればそれに切り替えして、これで設定完了です！
では実際にコードにブレイクポイントをセットします。
ここではウィンドウを出すコードの2行目の2の左をクリックすると、ブレイクポイントをつけます。
さっきのデバッグパネル「Launch Script in ExtendScript Engine」左の実行ボタンを押して、使用するPhotoshopを選んでコードが実行されます。
ちゃんとブレイクポイントに止まりました！
ウォッチ式も使えますね。便利です！
実行し続けるなら下記のようなダイアログが出てきます。
楽しく ExtendScript を書ける環境セットアップは以上です！
今回の記事で使ったコードをGithubにまとめました。よかったらどうぞ！
この記事読んだ君の役に立てればいいですね〜
明日は周さんのAI Chatと関連する内容です。楽しみですね！
アカツキでは一緒に働くエンジニアを募集しています。
カジュアル面談もやっていますので、気軽にご応募ください。
この記事はAkatsuki Games Advent Calendar 2024の8日目の記事です。
新卒4年目を迎えようとしている、クライアントエンジニア田﨑です。今年の4月から、新卒社員と中途入社の社員（計3名）を対象にアクティブブックダイアログ（ABD）を実施してきました。12月の今、3冊の本を読み終え、改めてこの活動が組織にもたらした効果を振り返っています。
私たちの組織は、現在大きな変化の中にあります。そんな中でも、自分が心から大切だと思う会社の文化をしっかりと残したい。アカツキ / アカツキゲームスでは、有志のメンバーが主体的にABDを運営しており、その取り組みに刺激を受けました。このABDは、単に知識を共有するだけでなく、新卒や中途入社の方々に「こんな素晴らしい文化があるんだ！」と感じてもらい、共に実践するきっかけを作る場にしたいという思いで始めました。
ABD（アクティブブックダイアログ）とは、本を分担して読み、それぞれが要約を準備して共有する読書会の手法です。以下がその基本的な流れです：
分担読書
本を章ごとに分担し、各自がその部分を読み込みます。
要約作成
担当部分を簡潔に要約し、他のメンバーにもわかりやすく説明できるよう準備します。
発表と対話
要約を順に発表し、その後グループ全体で対話を行います。対話の中で他者の視点を知り、自分の理解を深めることができます。
ABDの大きな特徴は、読書を個人の活動に留めず、チームでの対話を通じて学びを共有し、広げられる点です。単なる知識の共有にとどまらず、チーム全体の価値観や文化形成にも役立つ方法です。
内容のポイント
優れたチームを作るためのコラボレーション、信頼、リーダーシップの重要性を解説した一冊です。
経緯と学び
新卒・中途の新規JOINメンバーがいち早く会社のカルチャーを理解できるようにと、私から提案しました。特に、Team Geekの中で言及される「HRT（謙虚・尊敬・信頼）」は、私たちアカツキ / アカツキゲームスのコアバリューでもあり、会社の公式サイトにも掲載しています。
参加者からは、「共感できる部分が多く、読んでよかった」という声が多く寄せられました。また、私自身もリーダーシップを発揮するための重要な原則を改めて学び直す機会になりました。
内容のポイント
エンターテインメント業界の進化を俯瞰し、革新を生み出す要因を探る一冊。
経緯と学び
「エンタメ業界で働くなら、業界全体を俯瞰的に理解しておくべき」という考えから、メンバー全員で本書を選定しました。ゲーム業界の歴史や市場動向を学べただけでなく、他のエンタメ業界からも多くの学びを得ることができました。また、業界を超えて共通する成功要因に気づくことで、視野が広がりました。
読書後、メンバー一同が「世界に誇る素晴らしいエンタメを届けたい」という強いモチベーションを共有できたことが、この本を通じた大きな成果となりました。
内容のポイント
プログラミングを効率的に行うための実践的なルールや哲学を紹介した一冊。
経緯と学び
技術的なスキルを学びたいという新卒メンバーの期待から選定しました。
現在読み進めているところです。技術的なスキルを学びたいという新卒メンバーの熱意に私自身が刺激を受けると共に、中途メンバーや私から現場で起きた「あるある」を伝える機会になっています。
文化への共感が深まった
各本のテーマを通じて、会社の大切な価値観や文化を共有することで、新卒・中途の垣根を越えた共感が生まれました。それぞれのバックグラウンドが異なるからこそ、多様な視点が交わり、共通のカルチャーを再確認する場となりました。
対話がもたらす新しい気づき
異なる経験や視点を持つメンバー同士のディスカッションを通じて、「自分一人では気づけなかったこと」に多く出会うことができました。特に、バラバラなチームで構成されているからこそ、各チームの知見を共有する貴重な場にもなっています。また、新卒メンバーのキャリア相談や、個人的な悩みの共有といった、より人間的なつながりを育む機会も生まれました。
カルチャーの実践が始まった
読書会で培った価値観をもとに、メンバー自身が文化的な活動を率先して行う主体へと成長しています。最近では、社内カンファレンス「Akatsuki Dev Meet Up」の運営を主体的に担うなど、新たなカルチャーづくりに貢献する動きが広がっています。
ABDを通じて、「読書を超えた文化の共有と実践」ができることを実感しました。来年も新しい本をテーマに活動を継続し、さらに深い対話と実践の場を作っていきたいと考えています。
今年のABDで感じたのは、文化は「伝えるだけでなく、一緒に作り上げるもの」だということです。組織の変化が激しい中でも、共通の価値観を持つ仲間が増えることで、会社としての軸がより強固になっていくはずです。この取り組みが、組織全体の未来を支える一歩となればと思います。
この記事は Akatsuki Games Advent Calendar 2024 6日目の記事です。
昨日は NaoyaKohda さんの 自宅の消費電力を可視化してみた でした。 モジュールを使えば個人でもスマートメーターから値を引っ張ってこれるんですね。
アカツキゲームスQAエンジニアの山﨑 @tomo_tk11 です。ゲーム開発のプロジェクトで QA 効率化をミッションに掲げ活動しています。最近リスクベースドテストを実践してみたんですが、このテスト戦略の使い所やメリットが少しだけ分かった気がしたので書き留めておこうと思います。
JSTQB AL のテストマネージャシラバスには次のように書かれています。
リスクベースドテストでは、プロダクト品質リスクを使用してテスト条件を選択し、それらの条件に合わせてテスト工数を割り当て、作成されたテストケースを優先度付けする。リスクベースドテストには、収集するドキュメントにおける重要性の種類と度合いによるバリエーション、および適用する公式度合いによってさまざまな技法が存在する。また、リスクベースドテストには、明示的または暗黙的に、テストにより品質リスクのレベル全体を引き下げる、特にリスクレベルを受け入れ可能なレベルにまで引き下げるという目的がある。
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.24
リスクベースドテスト、JSTQB シラバスを読んだときは言葉として理解はできるものの、なんだかとても重厚な戦略だなと感じていました。リスクを扱うテストなので仕方がない面もあるのかなと思います。とは言っても重たい…。使い方が想像できない…。
また、リスクベースドテスト戦略は4つのプロセスで成り立っています。
リスクベースドテストは、次の 4 つの主な活動で構成される。
• リスク識別
• リスクアセスメント
• リスク軽減
• リスクマネジメント
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.24
特に、リスクベースドテストでどのようなテストを実施すべきかは、リスクマネジメントを除く3つのプロセスで検討されると思います。し、識別…？アセスメント…？難しそうです。
そして、リスクベースドテスト戦略の中で取られるテスト手法には公式で重い技法として、ハザード分析、エクスポージャーコスト、故障モード影響解析、フォールトツリー解析*1が例に挙げられています。シラバスのリスクベースドテストのページに書かれていることを実直にやろうとするととても大変そうです。
プロジェクトチームで話をしていたときに、「この機能、次のバージョンに入れたいんだけど、テストに時間がかかるらしくて難しいらしい。なんとかならないか？」という意見を聞きました。所属しているプロジェクトでは、テスト分析、設計を経て、比較的ローレベルなテストケースを実装し、テスト実行する、というテストプロセスです。通常、機能追加を行う際はそのバージョン開発開始時点で計画されます。リリースまでのマイルストーンに間に合うように開発するため、テスト工数の問題は発生しません。ただ、「この機能入れたいんだよね〜。」の要望は計画外のところからやってくるのが常です。機能入れたいんだよね、を提案する方のモチベーションはユーザのためであることがほとんどです。この機能を入れることでプロダクトがもっと良くなる、ここでユーザに提供できないと機会損失が生まれてしまう、だから入れたいんだ！という思いなはずです。その意思を尊重したい気持ちはありますが、いかんせんテストプロセスが重たく、「テスト工数が足りません…。」と返答せざるを得ません。この状態はなんとか解決したいです。
ここで注目すべきは、チームとして持ち合わせているテスト戦略が1つしかない、という点です。なのでテスト工数が少ない戦略を増やすことで解決できそうです。
ここでリスクベースドテストの話に戻ってくるのですが、リスクベースドテストの本質は「やらないテストを決められること」にあると思っています。本来テストというものはリスクを回避、軽減、認知するための手段である、という考え方をしています(個人意見)。リスクベースドテストを知ったときも、リスクを基にテストを考えるのって普通じゃ？くらいに思っていました。多分それは間違いで、リスクに対して他のテストよりも向き合っているのがリスクベースドテストなのかなと感じています。時間が無限にある中では洗い出されたリスクに対して対策を講じれば良いと思いますが、時間が限られているのが普通です。切羽詰まっているときだってあります。
そのときに効果を発揮するのがリスクベースドテストです。洗い出されたリスクの中で優先度を設定し、限られた時間の中で対策したいリスクだけを選択する。選択したリスクに対してテストスコープを決め、そのリスクを軽減するための過不足ないテストを計画する。そうすることで、普段のテストプロセスよりも少ない時間で品質を保証することが可能です。
つまり、リスクベースドテスト戦略の使い所は「限られたテストコストの中で機能を追加した上で品質を保証し、なんとしてでもプロダクトをリリースしたいとき」です。
冒頭で、リスクベースドテストは重厚である、という話をしました。リスクについて考えるのでどうしても時間をかけて行うことを想像してしまいます。実直にやろうとすると時間がかかるのです。一方で使い所は、限られたテストコストの中で機能追加してなんとしてでもリリースしたいとき、とも言いました。この矛盾を解決しなければ、使い所は分かっても使えません。
軽量な技法は、より公式な技法と同様に可能性および影響の要因に対する重み付けを使用して（たとえば、テストの精緻さの度合いなどに応じて）、ビジネスリスクまたはテクニカルリスクを強調できる。ただし、より公式な技法とは異なり、軽量な技法には次の特徴がある。
• 可能性と影響の 2 つの要因のみを使用する。
• シンプルで定性的な判定と尺度を使用する。
これらのアプローチは、軽量という特性により、柔軟性と広い範囲のドメインへの適用性、あらゆる経験とスキルを持つチーム（非技術要員および若手要員を含む）へのアクセシビリティを持つ。
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.28
JSTQB では公式で重い技法の対比で軽量な技法が紹介されています。重いならば軽くしましょう。リスク識別(洗い出し)、リスク判定(優先度付け)、リスク軽減(過不足ないテスト計画)、このプロセスにかかる時間をどれだけ早くできるか、がリスクベースドテストを実務に活かすポイントだと思います。
これは既に上で話しましたね。リスク判定を行うことで過不足ないテストを計画することができます。それにより、不可能だったリリースが可能になります。
「この機能入れたいんだよね〜。」という話とセットで言われるのが、「この機能を入れることによるリスクある？」です。リスクまで洗い出された状態で機能追加の提案を受けることは少ないんじゃないかなと思っています。その提案を受けるタイミングはたいてい切羽詰まっている状況なはずだからです。しかしながら、テストを計画する立場としてはリスクは考えなければいけません。Hotfix であれば不具合修正したコードの影響範囲を確認する必要があります。この作業を QA だけで行うのは大変です。リスクベースドテストを用いることでエンジニアなどの関係者と話し合いのもとリスクを洗い出し、優先度までつけることができます。助かりますね。
関係者と話し合って決めた「やらないテスト」なので、そこにはきっとロジカルな理由が存在します。それを使ってリリース判断するプロダクトオーナーやプロジェクトリーダーに説明することで、やらないことへの正当性が生まれます。つまり、「やらない」ということをチーム全体で合意できたことになります。リスクベースドテストはやらないテストを決めて合意形成するまでの一連のプロセスを含んでいます。これにより、コミュニケーションコストがぐっと下がると思います。
影響範囲の少ない Hotfix 程度であればリスクの洗い出し、優先度付けまでスピーディーに進めることができます。実際私が行ったときは2時間くらいでテスト計画まで終えることができました。しかし、大きな機能に対してや複数の機能に対してリスクベースドテストを適用しようとすると途端に重たくなるはずです。
私のプロジェクトチームでは使い所は「限られたテストコストの中で機能追加してなんとしてでもリリースしたいとき」に限っています。なので、追加される機能も自然と小さなものに限られるはずです。その場合は軽量化された戦略でスピーディーに意思決定すれば良さそうです。
逆に、大きな機能であれば検討する時間の余裕があるはずなので、リスクに向き合う時間も確保できると思います。より重い技法を使うこともできるはずです。
公式に軽量化したリスクベースドテストというよりは、概念を理解したうえで実務に活かすにはどうすればいいか？から考えたので、オリジナルな要素が強い戦略になってしまいました。ただ、理論は実践するのが大切だと考えているので、理想を掲げるだけではなく今のプロジェクトに即した形にチューニングして実戦投入したことは今のところ後悔していません。価値を出すことが何よりも大事です。
リスクベースドテストは重厚なテスト戦略ですが、軽量化することで「限られたテストコストの中で機能を追加した上で品質を保証し、なんとしてでもプロダクトをリリースしたいとき」に効果的に活用できます。
軽量化されたリスクベースドテストのメリットは以下の通りです：
ただし、大規模な機能や複数機能への適用は難しく、使用シーンは限定的です。理論を実践に落とし込む際は、プロジェクトの状況に合わせて柔軟にチューニングすることが重要です。
また、今回リスクベースドテストを実践するにあたりJSTQB シラバスの他に、ソフトウェアテストのセオリーという書籍も大変参考になりました。テストプロセスに関連する情報を網羅的に紹介していくれているのでかなりオススメです。