はじめに
NTTドコモ データプラットフォーム部（以下DP部）外山です。
DP部では『あらゆる業務・現場のニーズに応じられる柔軟なデータ活用環境』を実現するために、社内データ活用プラットフォームPochi*1を活用したデータ分析・可視化アプリケーションの開発を推進しています。
社内データ活用プラットフォームPochiとは
私たちDP部は社内のデータ民主化を目指し、StreamlitとGoogle Cloudで圧倒的に使いやすいデータ活用プラットフォームを開発・推進しています。このプラットフォームは、24年度は30万時間もの業務効率化を実現し、直近では5,000人以上の社員に利用が拡大しています。
このデータ活用の民主化を加速させるため、私たちはアプリの量産体制を構築し、開発チームも拡大してきました。しかし、体制の広がりとともに、ある深刻な問題が顕在化してきました。
「テストはしたんですが、その観点は見落としていました」
と、テスト漏れ問題が顕在化する場面が増えてきました。エンジニアは真面目に取り組んでいる。しかし、テスト観点が個人の経験に依存するため、インシデントが繰り返される…。この負の連鎖を断ち切るため、私たちはどうしたのか。本記事では、個人のスキルに頼らず仕組みでテスト品質を担保する、「テストガイドライン × Cline × プロンプトテンプレート」を用いたアプローチとその効果をご紹介します。
なお、本記事に掲載の取組については、DP部鈴木亮太さんに進めてもらっており、以下は、鈴木さんに執筆いただいています。
従来のテスト方法とその問題点
顕在化した問題を分析すると、従来のテスト方法には構造的な課題がありました。これまで私たちのチームでは、エンジニアが個人の経験と判断に基づいてテストを実施していました。具体的には、要件定義書を見ながら「ユーザーはこういう操作をするだろう」と推測してテストケースを作成し、自分が重要だと考える観点を中心にテストを行っていました。
テストケースの数も明確な基準がなく、あるエンジニアは5件程度の簡易的なテストで完了とする一方、別のエンジニアは30件以上の詳細なテストを実施するなど、大きなばらつきがありました。また、「基本的な動作確認はした」という報告はあっても、具体的にどの観点をテストしたのか、なぜその観点を選んだのかを説明できないケースが多く見られました。
この属人的なアプローチには、3つの深刻な問題が潜んでいました。
1. テスト体制の脆弱性
過去のインシデントを分析したところ、特定条件でのテスト不足やデータ突合試験の未実施などが原因となっており、いずれのケースもテストはしたが、観点が漏れていたという共通点がありました。エンジニアが「これで十分だろう」と判断した範囲でしかテストが行われず、体系的な網羅性が欠けていたのです。
また、レビュー体制にも課題がありました。当初、レビューワーは一つ一つのアプリを丁寧に確認できていましたが、アプリの量産化が進むにつれ、一人のレビューワーが同時に複数のアプリをレビューする状況へと変わっていきました。Webアプリという特性上、実際に動作するかが重要な判断基準となるため、主要なユースケースを正常・異常パターンで確認する形でのレビューが中心となっていき、このような状況下では、開発者が作成したテストケースの妥当性まで深く検証することが難しく、結果として開発者の属人的なテストパターンに依存せざるを得ない状況が生まれていました。
2. エンジニアによる品質のばらつき
入力パターンの網羅性やデータ整合性の確認、シナリオテストといった重要な観点が、個人のスキルや判断に委ねられていました。ベテランエンジニアは経験から重要な観点を押さえられる一方、経験の浅いエンジニアは基本的な動作確認のみで完了としてしまうケースもありました。これが品質を不安定にする大きな要因となっていました。
3. インシデント再発のリスク
個別の問題に対応しても、仕組み自体を改善しなければ、別の担当者が同じ過ちを繰り返してしまいます。「前回のインシデントではこの観点が漏れていた」という情報が個人の記憶に留まるだけで、組織全体の学びとして蓄積されておらず、私たちはこの負の連鎖を断ち切る必要がありました。
プロジェクトマネージャー（PM）としての危機感
ある日、重要なステークホルダーから「どのようなテストをしたのか説明してください」と問われました。エンジニアに確認すると、「基本的な動作確認はしました」という回答。しかし、具体的にどの観点をテストしたのか、なぜその観点を選んだのか、明確な説明ができませんでした。
「テストしたつもり」では通用しない。
PMとして、体系的なテストプロセスを構築し、誰が担当しても一定の品質を確保できる仕組みが必要だと確信しました。
テストガイドライン × Cline × プロンプトテンプレートの作成
深刻な課題を前に、私たちは多角的な解決策を模索していました。そんな中、日常的に開発支援で利用していた生成AIサービスに、この構造的な問題を解決するヒントがあるのではないか、というアイデアがふと浮かび、テストガイドライン × Cline × プロンプトテンプレートを組み合わせた仕組みを作成しました。過去のインシデント分析に基づく体系的なテスト観点をガイドラインとして整備し、AIエージェントClineにガイドラインと開発内容を確認させることで、プロンプト1発で標準化されたテストケースを自動生成できるようにしています。
以下の図は、テストガイドライン × Cline × プロンプトテンプレートの仕組み全体を示しています。
システムの動作フロー：
データソース層（左側）
- 開発内容：今回実装した内容（要件定義書、開発内容の箇条書きテキスト、ソースコード差分など）
- Cline用プロンプトテンプレート：Clineへの指示を標準化したテンプレート
- テストガイドライン：過去のインシデント分析に基づく体系的なテスト観点
Visual Studio Code環境（右側）
- テストケース生成用プロンプト：開発内容をテンプレートに統合して完成させたプロンプト
- Cline：AIエージェントがプロンプトとガイドラインに基づいて処理を実行
- ソースコード：Clineが実装ファイルを参照して正確なテストケースを生成
- テストケース：最終的に出力される網羅的かつ具体的なテストケース
処理の流れ： - 開発者は開発内容をCline用プロンプトテンプレートに統合してプロンプトを完成 - テンプレートとClineはテストガイドラインを参照 - Clineはプロンプトを受け取り、ソースコードを確認 - ガイドラインのルールに従ってテストケースを自動生成
この仕組みにより、エンジニアは開発内容を記入するだけで、実装ファイルに基づいた正確で網羅的なテストケースを自動生成できます。
テストガイドラインの内容
テストガイドラインでは、開発タイプごとのテストケース数の目安、記載ルール、具体的なフォーマット例が定義されており、Clineはこれらの観点を踏まえてテストケースを生成します。
テストガイドラインの設計思想
前述の3つの課題（テスト体制の脆弱性、品質のばらつき、インシデント再発のリスク）に対処するため、以下設計思想を踏まえたテストガイドラインを作成することとしました。
- 網羅性の確保：誰がやっても同じテストケースを作れる
例えば、新機能開発なら20〜35件、ライブラリのアップデートなら15〜20件といった開発タイプ別の目安に基づき、過去のインシデント分析から導き出された体系的なテスト観点（入力条件の組み合わせ、データ整合性、エラーハンドリング、シナリオテストなど）を網羅したテストケースが生成されるようにガイドラインを作成する - 属人性の排除：スキルに依存しない品質
地域選択で『東京都』を選択し、期間で『2024/01/01-2024/12/31』を設定し、検索実行ボタンをクリックする。期待結果：3秒以内に5件のデータが表示され、各データにID・名称・カテゴリ・登録日が含まれ、登録日の降順でソートされているというような、誰が読んでも同じ解釈となる具体的なテストケースが生成されるようにガイドラインを作成する - 過去の学びの形式知化：インシデント再発の防止
過去のインシデントから得られた、特定条件でのテスト不足、データ突合試験の未実施、シナリオ検討不足、回帰試験不足の4点を網羅するテストケースが生成されるようにガイドラインを作成する
テストガイドラインの構成
実際のテストガイドラインは以下のような構成になっています。
テストガイドラインの内容（クリックで展開）
1. 開発タイプ別テストケース数指針
| 開発タイプ | 基本機能 | 回帰テスト | データ整合性 | 性能テスト | 合計目安 | 想定工数 |
|---|---|---|---|---|---|---|
| 新機能開発 | 5-8件 | 5-8件 | 3-5件 | 2-3件 | 20-35件 | 2-3人日 |
| ライブラリアップデート | - | 8-10件 | 5件 | 除外 | 15-20件 | 1人日 |
| バグ修正 | 2-3件 | 5-8件 | 2-3件 | 除外 | 10-15件 | 0.5-1人日 |
2. テストケース記載ルール
テストケースを記載する際は、以下のルールを厳守します。
❌ 使用禁止表現（曖昧な表現）
- 適切な条件を入力する
- 正常に表示される
- エラーが発生しない
✅ 推奨表現（具体的な表現）
- 地域選択で「東京都」を選択する
- マップ上の「XXX」にピンが表示される
- 処理が180秒以内に完了する
3. テストケースの標準フォーマット
- **TC-001**: テストケース名 - 前提条件: [実行前に満たすべき条件] - 手順: 1. [具体的な操作手順1] 2. [具体的な操作手順2] 3. [具体的な操作手順3] - 期待結果: [測定可能で具体的な期待結果]
具体例：条件指定による検索機能
- **TC-001**: 条件指定による検索機能 - 前提条件: アプリが起動している - 手順: 1. 「検索」タブをクリックする 2. 「カテゴリ」で「カテゴリA」を選択する 3. 「範囲」スライダーで「50」を設定する 4. 「検索実行」ボタンをクリックする 5. 処理完了まで待機する - 期待結果: 検索条件に一致するデータが一覧表示され、各項目に必要な情報が含まれている
Cline用プロンプトテンプレート
プロンプトテンプレートは、Clineに対する指示を標準化し、一貫した品質のテストケースを生成するための設計図です。
テンプレートの設計思想
高品質なテストケース生成を実現するため、プロンプトテンプレートは以下の4つの設計思想に基づいて構築しています。
- 専門性の明確化
単なるエンジニアやテスト担当者ではなく、Streamlitアプリケーションのテスト設計、データ整合性検証、リスクベーステスト設計といった具体的な専門領域を定義することで、AIの出力品質を向上させます。 - 思考プロセスの指定
実装ファイルの徹底分析、正常系・異常系の両面考慮、過去のインシデントパターンの意識、粒度と網羅性のバランス最適化など、AIに「何を考えながらテストケースを作るべきか」を明示的に指示します。 - 品質基準の厳格化
テストガイドラインの100%遵守、曖昧な表現の完全排除、具体的な数値・状態・期待結果の明記、前提条件・手順・期待結果の3要素必須化など、テストケース生成時に遵守すべき品質基準を明確に定義します。 - 自己検証プロセスの組み込み
生成したテストケースをAI自身がレビューする仕組みを導入します。網羅性チェック、具体性チェック、実装整合性チェックの3つの観点で自己検証を行い、出力品質を向上させます。また、不確実性への対処方法も明確化し、推測に基づく不正確な生成を防止します。
プロンプトテンプレートの構成
実際のプロンプトテンプレートは以下のような構成になっています。
プロンプト本体（クリックで展開）
# テストケース生成・更新プロンプト ## 基本指示 あなたは以下の専門性を持つシニアのソフトウェアエンジニア兼テスト設計者です： **専門領域** - Streamlitアプリケーションのテスト設計（5年以上の経験） - データ整合性検証とエッジケース分析の専門家 - 過去のインシデント分析に基づくリスクベーステスト設計 **開発範囲の情報源に関する厳格なルール** - プロンプトで指定された情報源（ファイル名または「以下の開発内容」等）が**唯一の正しい情報源**です - 指定された情報源のみを参照し、他のドキュメント（開発指示書等）は**絶対に参照しないでください** - 開発範囲の情報を**最後まで確認**し、すべての変更内容を漏れなくテストケースに反映してください **思考プロセス** 1. 実装ファイルを徹底的に分析し、仕様書に記載されていない実装詳細も把握する 2. 「正常系だけでなく異常系」「単一機能だけでなく機能間連携」を常に考慮する 3. 過去のインシデントパターンを意識し、同様の問題が起きないか検証する 4. テストケースの粒度と網羅性のバランスを最適化する **遵守すべき品質基準** - テストガイドラインの全項目を100%遵守（例外なし） - 曖昧な表現（「適切に」「正常に」等）の完全排除 - 各テストケースに具体的な数値・状態・期待結果を明記 - 前提条件・手順・期待結果の3要素を必ず含める **自己検証プロセス** 生成したテストケースについて、以下の観点で自己レビューを実施してください： 1. **網羅性チェック**：開発タイプ別のテストケース数目安を満たし、全観点をカバーしているか 2. **具体性チェック**：すべてのテストケースが「誰が読んでも同じ解釈」になっているか 3. **実装整合性チェック**：実装ファイルの内容と矛盾していないか **制約事項と対処** - 実装ファイルが見つからない場合：必ずユーザーに確認を求める - テストガイドラインと実装が矛盾する場合：矛盾点を明示し判断を仰ぐ - 不明な仕様がある場合：推測せず、明示的に「要確認」とマークする 本アプリのテストケースファイルを、上記の基準に従って作成または更新してください。 1ファイル運用方針に基づいてテストケースを管理してください。 ## テストケースファイルの運用概念 【テストケースのファイル構成や運用方式を記載】 ## 実施手順 【テストケースを生成するまでの流れを記載】 ## 実装調査の徹底 【開発範囲の調査方法について記載】 ## 今回の開発範囲 [ここにエンジニアが開発内容を記載]
テンプレートの使用例
エンジニアは、プロンプトテンプレート末尾の「今回の開発範囲」セクションに以下の項目を記入し、Clineにインプットします。
- 開発タイプ：新機能開発、機能改修、ライブラリアップデート、バグ修正など
- 実装した機能：追加・変更した機能の概要
- 変更ファイル：作成・修正したファイルのリスト
- 特記事項：外部API利用、制約事項など
※コミットのdiff情報や要件定義書なども含めることができます。
Clineが生成するテストケースの例
上記の開発内容をテンプレートに統合してClineに渡すと、以下のような網羅的なテストケースが自動生成されます：
## 基本機能テスト（8件） - **TC-001**: 地域選択による検索 - 前提条件: アプリが起動し、検索画面が表示されている - 手順: 1. 「地域選択」で「東京都」を選択する 2. 「検索実行」ボタンをクリックする 3. 処理完了まで待機する - 期待結果: 東京都のデータが一覧表示され、マップ上に該当地域のピンが表示される - **TC-002**: 複数条件による絞り込み検索 - 前提条件: アプリが起動し、検索画面が表示されている - 手順: 1. 「地域選択」で「大阪府」を選択する 2. 「期間」で「2024/01/01-2024/12/31」を設定する 3. 「カテゴリ」で「カテゴリA」を選択する 4. 「検索実行」ボタンをクリックする - 期待結果: 全ての条件に一致するデータのみが表示され、件数が正しく表示される ## データ整合性テスト（5件） - **TC-009**: 外部API取得データの整合性確認 - 前提条件: 検索結果が表示されている - 手順: 1. 表示されているデータのIDを記録する 2. 外部APIから同じIDのデータを直接取得する 3. 両者のデータを比較する - 期待結果: アプリ表示データと外部APIデータが完全に一致する （以下、シナリオテスト、回帰テストなど、合計35件のテストケースが生成される）
このように、エンジニアが開発内容を記入するだけで、実装ファイルに基づいた具体的で網羅的なテストケースが自動生成されます。
実際の導入効果(エンジニアの声)
テストガイドライン × Cline × プロンプトテンプレートの導入により、エンジニアから以下のような声が寄せられています。個人のスキルレベルに依存することなく、誰が担当しても一貫した品質を目指せるテストが実現できています。
他のエンジニアが作成したアプリのテスト
「別のエンジニアメンバーが作成したアプリを最近改修しているのですが、自分が作っていないアプリのテストケースを作成するのにうってつけでした。テスト手順もわかりやすかったです。
Clineが改修による影響範囲を見つけてきてくれるので、どこをテストすべきか明確になりました。」
網羅的なテストケース生成
「99%くらいのケースは必要性を簡単に理解できるケースが出力されました。今回の改修に特化しているケースも出してくれてすごいと思いました。
ある特定の機能のテストケースは自分で後ほど追加しないといけないと思っていましたが、実装を見て自動生成してくれました。自分の感覚だと不足していると思われるケースはほぼなかったです。テストケースを参考に試験項目書が作りやすかったです。」
生産性向上の実感
「テストケース・シナリオの出力精度が高く、これなら知らないアプリでも容易にテストケースを作成できそうです。まさしくプロジェクトの生産性アップに直結していると感じます。
プロンプトを入力するだけで、アプリに対する包括的なテストシナリオ（37ケース）が作成されました。基本機能、品質観点、データ整合性、エラーハンドリング、シナリオテストと、必要な観点が全て網羅されていました。」
まとめ：属人性の呪縛から「学習する組織」へ
「テストしたつもりでは通用しない」。ステークホルダーからの問いに、明確な根拠を示せなかったあの日の危機感が、私たちの旅の始まりでした。個人の頑張りに依存したままでは、品質のばらつきとインシデントの再発という負の連鎖は断ち切れない。そんな行き詰まりの中で見つけた一筋の光が、生成AIと、私たちが自らの失敗から作り上げるテストガイドラインという羅針盤でした。
AIに組織の知恵を教え込み、常に100点満点のテストケース案を出力させる。この仕組みは、私たちを属人性という長年の呪縛から解放してくれました。もう、「あのベテランがいないと不安だ」という状況はありません。経験の浅いエンジニアも、組織が蓄積した最高の知見をすぐに引き出し、ベテランと同じ品質基準に立つことができるのです。
しかし、この取り組みがもたらした最大の価値は、インシデントを学びの資産としてガイドラインに蓄積するサイクルが生まれたことです。失敗はもはや隠すべきものではなく、組織をより強くするための貴重な糧となりました。私たちは、静的な組織から、自ら学び、進化し続ける「学習する組織」へと変わり始めたのです。
PMの役割とは、ヒーローのように一人で問題を解決することではなく、チーム全員が安心して、かつ高い水準で仕事ができる舞台を整えることだと考えます。この物語が、同じように品質という名の巨大な壁に立ち向かう、すべてのプロジェクトマネージャーやリーダーへのエールとなることを願っています。
*1:Pochiは社内の開発コードネームです
