皆さまこんにちは。ぐるなびで主に会員系サービスのフロントエンド開発を担当している小松です。主務はフロントエンドですが、開発部内で組織間連携分科会という活動も行っており会長も務めています。他にも肩書が増えてしまいましたが…今回はその組織間連携分科会での取り組みについてご紹介したいと思います。
この分科会は、長年、開発部の中でエンジニアとディレクター・デザイナー間などで課題となっていたコミュニケーションの認識齟齬や組織をまたいだ連携に関する課題に取り組むため発足しました。実は現存する分科会の中でも長く活動している分科会の1つです。 以下の内容は分科会メンバーの多大なる協力で執筆することができました。ありがとうございます。
コミュニケーションの課題
開発する中でそれぞれの役割ごとに異なる視点や専門知識を持つメンバーが協力し合うことは、プロダクトの成功に不可欠です。しかし、現実には以下のような課題が存在していました。
- 仕様書フォーマットがバラバラ
- テスト項目書作成にかかるコストの増大
- Jira運用ルールの統一認識がないことによる混乱
など、情報共有やタスク管理において非効率が生じていました。また、これらの非効率性が原因で、ディレクターと開発者間のコミュニケーションにも齟齬が生じることが少なくありませんでした。
これらの問題は、単なる非効率性を生むだけでなく、手戻りの発生による開発の遅延や、認識のズレによるプロダクト品質の低下にもつながっていました。
仕様書フォーマットの標準化
この課題を解決するため、私たちはまず「仕様書フォーマットの標準化」に着手しました。仕様書の書き方や構成を統一することで、以下の3つの目的を達成しようと考えました。
- 連携齟齬の解消: 誰が読んでも理解しやすい仕様書を目指す
- 作成工数の削減: テンプレート化により、作成やメンテナンスの負担を軽減する
- 品質向上による迅速なリリース: 手戻りを減らし、プロダクトをより早く、高い品質でユーザーに届ける
この取り組みは一定の成果を上げましたが、一過性の取り組みにならないよう、さらなる改善の可能性を模索していました。
生成AIによる業務改善
生成AIの進化のタイミングで、きっかけとなったのが、社内で発足した「生成AI CoE業務改善プロジェクト」です。このプロジェクトの一環として、当分科会は「ディレクターと開発が連携する箇所のAI化」というテーマで参加することにしました。 これにより、活動方針は標準化とAI活用へと大きくシフトしました。
最重要テーマの設定
AI活用の具体的なテーマを検討する中で、私たちは特に工数がかかっている業務として「仕様書からのテスト項目書作成」に着目しました。この作業は、仕様の正確な理解と、テスト観点の網羅性が求められる重要なプロセスであり、多くの時間と労力を要していました。
このテーマは、私たちが当初から抱えていた「連携の円滑化」や「工数削減」といった課題に直結するものであり、AI活用の最重要テーマとして設定するにふさわしいものでした。
テスト項目書作成のプロセス
ここからは、私たちがどのようにしてAIによるテスト項目書作成を実現したのか、その試行錯誤のプロセスをご紹介します。
最初のステップと直面した壁
まず私たちは、Geminiに仕様書（Googleスライド）を直接読み込ませ、テスト項目書を生成させるというシンプルな方法を試しました。しかし、この初期アプローチはすぐに3つの大きな壁にぶつかりました。
- ツールの壁: 多くのテスト項目書がスプレッドシートで管理されていましたが、当時のGeminiはスプレッドシートを直接読み込むことができませんでした。一度PDFに変換する必要があり、この一手間が非効率でした。
- 知識の壁: AIは、仕様書に明記されていない弊社独自の概念やドメイン固有の暗黙のルールを理解できませんでした。例えば、弊社サービス特有の時間表記ルール「25時」という予約時間表記を、AIは翌日の午前1時とは解釈できず、単なる無効なデータとしてテスト項目から除外してしまいました。
- 観点の壁: AIは仕様書通り「12文字以上のパスワードが設定できること」という正常系のテストは作成できましたが、「11文字のパスワードではエラーになること」といった境界値テストや、記号を含んだ場合の異常系テストの観点がすっぽりと抜け落ちていました。
解決策の探求：精度向上のために
私たちは発想を転換し、AIにすべてを教えるのではなく、AIを「知識を持つ賢い専門家」に育て上げるという発想に切り替え、NotebookLMとカスタムGemを連携させるというアプローチをとることにしました。
このアプローチは、大きく分けて「知識の集約」と「タスクの実行」の2つのフェーズで構成されます。
フェーズ1: NotebookLMによる「ドメイン知識」の集約
まず、テストケース生成の精度を上げるために、プロダクト固有の知識を「NotebookLM」に集約しました。具体的には、用語集、過去の障害ログ、議事録、非公式な運用ドキュメント、暗黙のルールといった、仕様書には現れない情報をすべて投入してみました。
このプロセスは、AIにあらかじめ「前提知識」を与えるための重要な準備段階となりました。これにより、AIは単なるテキストデータではなく、私たちのプロダクトの文脈を理解した上でタスクを実行できるようになります。
フェーズ2: カスタムGemによる「テスト項目書」の生成
次に、NotebookLMで整理・集約したドメイン知識を活用し、「テスト項目書作成支援Gem」という専用のカスタムGemを構築しました。このGemは、以下の2つの要素で構成されています。
- カスタム指示: 「あなたはベテランのQAエンジニアです」といった役割設定や、出力形式（例: Markdownテーブル形式）、テスト観点（例: 境界値、異常系を必ず含める）など、普遍的なルールを定義します。
- 知識ファイル: NotebookLMで集約したプロダクト固有の用語集やルールなどを、参照ファイルとしてGemに読み込ませます。これにより、Gemは私たちのプロダクトに特化した知識を持ってテスト項目書を生成できるようになります。
成果
この「テスト項目書作成支援Gem」を、あるメンバーが実際に担当案件で試したところ、予想以上の成果が生まれました。
メンバーが担当したセキュリティ強化案件でGemを試したところ、Gemは仕様書には明記されていなかった「ログイン失敗が規定回数に達した場合のアカウントロック」に関するテスト項目を提案してきました。ここに重要な発見がありました。 当たり前の要件として実装はされていましたが、仕様書に明記されておらず、このAIからの「指摘」をきっかけに、私たちは仕様書に暗黙知を明記する文化の重要性を再認識し、テスト項目書と仕様書が互いを補完するフィードバックループになるのではと思います。
形になった「テスト項目書作成支援Gem」
分科会として提供する「テスト項目書作成支援Gem」は、Googleスライドで作成された仕様書から、テスト項目書を効率的に自動生成するツールです。 成功のカギは「準備」にあり、AIが理解しやすいように仕様書を記述することが重要です。
以下に、4ステップの利用手順をご紹介します。
- 準備：仕様書の「スピーカーノート」に詳細を記述する。最も重要なステップです。AIは図や画像を正確に理解できない（現在は精度が向上していますが、確実性を期すため）ため、補足情報やロジック、要件などをスピーカーノートにテキストで詳細に記述します。また、不要なスライドはタイトルに「参考資料」「検討資料」などを含めると自動で処理対象から除外されます。
- Gemの起動と連携 チャット画面からGoogleドライブにある仕様書（スライド）を選択します。「テスト項目書を作成してください」といったシンプルな指示を送信するだけで、Gemが処理を開始します。
- AIの生成内容を確認・修正 生成されたテスト項目書を確認し、AIの判断が正しいかレビューします。もし期待通りでなければ、仕様書やプロンプトを修正して再実行します。この対話的なプロセスが、成果物の精度を高めます。
- スプレッドシートへ出力して完成 生成された内容に問題がなければ、所定のテンプレート（スプレッドシートなど）に貼り付けて完成です。
つまり、読み込ませる仕様書のフォーマットや情報についての整理が成果物の精度を左右する、とても重要なポイントになります。 これまで我々が取り組んだことが全部繋がっているということですね。
おわりに
今回ご紹介したAI活用は、あくまで手段の一つであり、目的としては組織連携の強化です。 AI活用を推進するプロセスの中で、ディレクターと開発者が互いの業務における「暗黙知（テスト観点や仕様の意図）」を出し合い、共通の課題に向き合えたことが何よりの成果でした。
同様の課題を抱える他のチームや企業の皆様にとって、少しでも参考になれば幸いです。
