Cursorでポケモン図鑑をテストしたら、個人的なプロダクトリリースまでの理想を思いついた話。

ポケモンについていけなくなったアラサー、ポケモン図鑑を作る

1998年生まれ。執筆時27歳の私。
世代でいうとルビーサファイア/ダイヤモンドパール世代なのですが、年齢を重ねるにつれて、みんなポケモンバトルや、それに伴う育成に熱量を注ぐようになり、完全にゲームに対しての気持ちが薄れてしまったアラサーです。
ただ、ポケモンセンターに行くことは好きだったり、新しく発見されたかわいいポケモンをどんどん知りたいという気持ちは昔と変わらずあるのでポケモン図鑑を作ってみようと思いました。
実際にAIに作らせてみて、AIがどの程度まで開発からリリースまでの判定に関与できるのか。
プロジェクトを推進していく中で、どういう進め方をしていくのが理想的なのか。

たった一人のアラサーが重い腰を上げ、ただポケモン図鑑を休日に作っただけで、プロダクトに対するデカめな理想をただ掲げる。
今回はそんな話を書いてみました。

とりあえず作ってみよう

仕様書作成

まずは、どういう図鑑が必要になるのかを考えてみた。

・PCで表示するのでポケモンの一覧表示を20/50/100件でほしい
・タイプ別や発見された世代、大きさ、重さごとにフィルタをかけられる
・お気に入り機能が欲しい

これらの情報や、冒頭で触れた背景をClaudeに伝え、仕様書を作ってもらった。

なぜclaudeにしたか。
テキストベースの処理に強いため。また、アウトプットをそのまま羅列するだけではなく、右側のパネルに成果物としての形を載せてくれるのがエラいので。

Githubにつながります

記載されたアウトプット	概要
デザイン要件	HTML/CSSでのお作法
技術スタック	フレームワーク、ライブラリ
ファイル構成	ファイルの中にどのようなフォルダが入っているか
機能仕様詳細	画面構成,各画面での仕様
日本語仕様	作成に当たって使用したPokeAPIが英語になっていたので日本語に変更してもらうようにした
データ取得・管理仕様	フィルタリングの仕組みやその実装手順
ページ状態の保持機能	ポケモン図鑑の詳細ページから戻るときに保持する情報の説明
フィルタモーダルの実装	コンポーネント設計の詳細
API取得の最適化	段階駅なデータ取得
実装チェックリスト	実装において最低限の機能に取りこぼしがないかの確認

仕様書を作ってもらったが、後半はかなりコーディングについての記載があったため、実装者には優しいが、ほかの職種の人との読み合わせには向かないものができてしまった。

仕様書を読み込ませて作らせる

ここからCursorの出番。

なぜCursor？
VisualStudioCodeベースで作ったエディタがついているので、そのままコーディングとGithubへのマージができてめっちゃ楽だから。
PowerShellがデフォルトターミナルで個人的にあまり好みではなかったので、cmdに変更したら使いやすくなった。

プロンプトとしては以下を依頼

あなたはベテランエンジニアです。仕様書をお送りするので、それに合わせてポケモン図鑑を実装してほしい。

わからない項目があれば質問して

ということで紆余曲折ありながらも完成

↓ポケモン図鑑一覧。エスパータイプでフィルタリングし、ヤドンを見つけた。

ヤドンの詳細ページ。基本情報や進化チェーンなどの詳細が書かれている。

Youtubeにデモを挙げてみております。よしなに。

テストしてもらおう

とりあえずQAフローをたどってもらう。
JSTQBに記載されているテストプロセスは以下

1.テスト計画
2.テストのモニタリングとコントロール
3.テスト分析
4.テスト設計
5.テスト実装
6.テスト実行
7.テスト完了

この中で実際に資料化するものは以下
・テスト計画
・テスト分析
・テスト設計

テスト計画

プロンプト

仕様書をもとにテスト仕様書を作ってよ。

テスト分析

プロンプト

仕様書を読み込んでテスト分析書を作成してほしい

要件の明確化・質問リスト
テスト可能性の評価
テスト対象の優先度付け

テスト条件リスト

テストすべき機能・条件の一覧
リスクベースのテスト項目抽出

トレーサビリティマトリクス

要件とテスト項目の対応表
カバレッジ確認用

テスト設計

プロンプト

テスト計画書と仕様書をもとに、テスト観点とテスト仕様書をそれぞれ作成して。
観点書はmd方式。テスト仕様書はcsv形式でアウトプットしてほしい

テスト実施とテスト完了報告
テスト実施について、PlayWright mcpを使用してテストをしてもらうため、事前準備が必要になってきます。
CursorでPlaywright MCPを使う方法こちらの記事が非常に役に立ちました。

プロンプト

これからテストをしてもらいます。
Playwright　MCPをつかって、ポケモン図鑑をテストしてください。

テストの実行結果をテスト仕様書CSVにOK、NGのステータスで振り分けをしてほしい。
NGになったテストケースが原因でブロッカーになっているものは保留のステータスをつけたうえで、備考欄に保留の理由を記載して。

テストが完了したら不具合になった項目を教えてほしい。
また、テスト完了のドキュメントとして、以下を記載したドキュメントを作って。

テスト完了レポート（Test Summary Report）

テスト実施サマリ
品質評価
未解決の問題
リリース判定

テストメトリクスサマリ

総テストケース数
実行率・合格率
バグ検出数・修正率
カバレッジ

教訓・改善提案書（Lessons Learned）

うまくいった点
問題点と改善策
次回への提言

アウトプットはこちらGithubにつながります

良かった点

仕様書が詳細に描けていれば、詳細にテストを分析してくれるのは非常に良いと思った。
「既存サービスに追加でこの項目を追加して実装する」が多いと思うので、それに関しての画面仕様書などの事前インプットは実際のサービスにおいてはかなり重要になってきそう。

微妙な点

・冗長なテストケースがありそうなので、レビューは必ず必要だなと思ったこと
・結局人間の目で探索テストは必要になるので、当然だが、完全に依存していくとよくない。
・AIの精度がすごいという認識で変なバイアスがかかりそう。若干テスト結果も疑わざるを得ない気がする。

AIにテストを全部任せることはできるの？

結論できはするけど、完全ではない。

　今回は要件定義からテスト実施まですべてAIでやったので、理解が通りやすかったような気がしている。
人間が作ったものに対してはどこかしらに躓きポイントがあるし、結局AIが作った仕様書をそのままなぞっただけだからそりゃOKばっかりになるよねっていう話。

　実際のプロジェクトでは要件定義も定かではなく、模索しながら実装している場合もあるので、すべてをAIにテストしたら抜け漏れは必ず出てくると思うし、不都合な部分はテストせず、結果として冗長な成果物を生み出す可能性は往々にしてある気がする。

ただ、やってみて、大枠ができることによるQAフローの省略化はかなりうれしい。これをもとにこまごまとしているテスト項目をFBしていき、よりよいテスト設計のための脳のリソースを確保するのはとても良い気がする。

結局上流工程が順調に進んでいればことがうまく進むのはAIも同じ。

　AIも人間と同じく、わからない情報はわからない。なので与えられるインプットの精度が活用していくうえでかなり重要なことが改めて理解できた。
QAがテストをしていく前の仕様書レビューなどのリソースが潤沢になるように仕向けられれば、AIの活用がかなり効果を得られる気がする。

結局いいジャンプはいい助走からですよ。みなさん。

　PM、実装者、デザイナー、QAなどがキックオフをした後に要求書などの成果物を一緒に作っていくことが結構理想に近いのでは？と思うと、人間が最後にできる仕事は、創造のはじめの一歩を肩を並べてしていくことに着地するのでは？という考えを持った。

全員で品質を作りこみ、AIを経由して最後にみんなでプロダクトをゴールさせるような未来ならうれしい。

最後に

お前、ライコウなのか...?