--- name: sdd-dogfooding description: 動いている製品を利用者として操作し、未知の不具合や使いづらさを証拠付きで見つける。「初めて使う人として試して」「使いづらいところを探して」「ドッグフーディングして」と依頼されたときに使う。仕様の網羅的な照合はsdd-qaで扱う。 --- # SDD利用体験の確認 実際の製品を使い、利用者が目的を達成できるか確かめます。見つけた問題は日本語で説明し、ユーザーが別の言語を指定した場合はそれに従います。 ## 1. 製品と利用者の目的をつかむ 明示されたURLやアプリを対象にします。指定がなければ、現在のプロジェクトの案内や起動方法から対象を探します。複数の製品があり対象を決められない場合だけ、ユーザーに確認します。 利用者と目的が指定されていれば使います。指定がなければ、画面で案内される主な操作を対象にし、想定した利用者を明記します。初めて使う人の確認では、ソースコードや隠れた仕様を使って正しい経路を先回りせず、画面に見える案内から判断します。 | 利用者が達成したいこと | 開始する画面・状態 | 実際に進んだ操作 | 結果・証拠 | 未確認の範囲 | | --- | --- | --- | --- | --- | | 目的を記載 | 初期状態を記載 | 見える案内に沿った手順 | 画面や観察記録 | 残件があれば記載 | ## 2. 実際に操作して調べる ### 操作するツールを準備する Webアプリでは、接続済みのPlaywright MCPやCLI、使えるブラウザーセッションを先に調べます。不足する検証用ツールの準備は、この作業に含めて進めます。Node.js・npm・npxを確認し、アプリの外にある利用者専用のツールフォルダーで、必要な場合だけ次を実行します。アプリの`package.json`やロックファイルは変更しません。 ```text npx --yes --package @playwright/cli@0.1.22 playwright-cli --help npx --yes --package @playwright/cli@0.1.22 playwright-cli list npx --yes --package @playwright/cli@0.1.22 playwright-cli install-browser chromium ``` 既存のブラウザーが使えれば再導入しません。使用中のCLIと同じ版のブラウザーを使います。新規導入や接続変更があれば、チームの`setup`のPlaywright手順と確認用ページを使えます。単独で使う場合も、ツール用フォルダーに外部送信しない確認用ページを作り、`127.0.0.1`だけで配信します。CLIでブロックされる`file://`は使いません。実際に開いてボタンを押し、表示の変化とスクリーンショットを確かめます。操作方法はCLIの`--help`で確認します。既存の接続を使う場合は、対象アプリでのスナップショット取得から進めます。画像の内容まで確かめ、ダウンロード成功だけで動作確認を終えません。このページの成功と、製品を使った結果は分けて記録します。 既存セッションへ`open`を実行すると再起動されるため、先に`list`で確認します。操作前のスナップショットにある参照を使い、画面が変われば取り直します。終了時は今回作ったタブや専用セッションだけを閉じ、`close-all`・`kill-all`は使いません。証拠は`output/playwright/`など既存の保存規則に合わせます。 Node.jsやOSの必要条件は[公式案内](https://playwright.dev/docs/intro#system-requirements)を確認します。準備に必要な権限やネットワークが足りなければ、その条件を具体的に示し、実行していない操作を報告します。シェルがない場合は使えるブラウザー機能を使い、メンバーのPCへPlaywrightを導入したとは報告しません。iOSなどのネイティブアプリは既存のXcode・シミュレーター等で操作し、モバイルブラウザーの確認だけで済ませません。CLIの詳細は[Microsoftの公式案内](https://github.com/microsoft/playwright-cli)を参照します。 ### 利用者として画面を進める 既存のアプリ、ブラウザー、ログイン済みセッションを使い回します。操作のたびに画面の変化を見て、目的を達成できたかを確かめます。操作部品が通常の情報取得で見つからない場合は、画面と利用可能な視覚操作やネイティブ操作を使います。 主な利用経路を進めた後、表示や機能に関係する範囲で、戻る、やり直す、空の状態、入力不備、画面幅の違い、読み込み中などを試します。破壊的な操作や本物のユーザーに影響する負荷を勝手に加えません。固定のテスト手順を通すだけで終わらず、見える画面から生じた疑問や行き止まりも追います。 未知の問題を探す段階では、実装ソースから欠陥を探しません。起動先を調べるための設定、手順、プロセス出力は確認できますが、初めて使う人の役には内部情報を与えません。再現原因を調べる必要があれば、体験の観察を記録してから別の調査工程に分けます。画面の観察を補うためにコンソールや通信情報を使った場合は、その証拠を分けて示します。 ## 3. アクセスとデータの範囲を守る 画面の閲覧、移動、スクロール、送信しない一時的な入力を基本とします。保存、投稿、アップロード、削除、支払い、保存される設定の変更は、ユーザーが依頼した範囲で行います。自動保存されるか不明な入力は、必要な確認をしてから扱います。 - ログインが必要なら、既存の認証済みセッションか、今回の利用が認められたアカウントの通常のログインを使います。ログイン情報、MFA、権限が足りなければ、対象の操作と必要な協力を具体的に伝えます。認証を回避したり、秘密情報をチャットへ貼らせたりしません。 - 必須の目的にデータ変更が必要なら、既存の許可を確かめます。なければ、操作、アカウント、環境、変わるデータを示して、その操作の許可か既存の確認用データを求めます。その項目を無断で対象外へ移しません。 - 待っている間は独立した操作を進め、前提がそろえば同じセッションで再開します。ログイン画面を見ただけで、認証後を含む確認が終わったとは報告しません。 利用体験の確認だけでは、コード、テスト、仕様、アプリの設定・依存関係、保存データの修正を始めません。上記の検証用ツールの準備と、記録用のスクリーンショット、動画、レポートの保存は行えます。終了時は今回起動したプロセスや一時資源だけを片付け、共有資源は保持します。 ## 4. 再現できる証拠を残す 気づいた時点で、開始状態、操作、期待した結果、実際の結果を記録します。繰り返しても安全な問題は再現を一度確かめます。再現できない観察も削除せず、未再現であることを示します。 表示の問題にはスクリーンショットを付けます。操作や時間、状態の変化に関する問題には、前後の画面と再現手順を残し、対応するツールが使える場合は動画も記録します。撮れていない証拠を作ったことにしません。秘密情報や個人情報が証拠へ写り込んでいないか確認します。 各発見は、次を分けて報告します。 - 観察した事実と、再現する手順・証拠。 - 利用者への影響と、その大きさを判断した理由。 - 原因についての解釈と、まだ確かでない点。 - 改善案と、必要なら追加で確かめること。 「使いづらい」という感想だけで終えず、どの操作で何が分からなかったかを示します。AIが利用者役をした結果は、人による調査のための仮説です。実際のユーザーの感情、離脱率、需要を測定したことにはしません。AIの思考時間を、人が迷った時間として報告しません。 ## 終了時の報告 試した目的、達成できた範囲、優先度順の発見、証拠、未確認の操作、再開に必要な条件を示します。問題の件数を目標にせず、見つからなければ、その範囲で問題を観察しなかったと報告します。探索した範囲だけで製品全体の合格を宣言しません。 既知の要件を満たすかは品質確認、コードの問題は実装、不明な動作は仕様の検討へ渡します。修正まで依頼されていれば、元の観察と証拠を残してから修正工程へ進みます。