> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# お客様のフィードバックを実際の改善につなげる

> お客様のフィードバックをReplitで的を絞ったリポジトリの変更に変え、開発プレビューで改善をテストし、チームのレビュー用にプルリクエストを準備します。

お客様がサインアップフォームの必須項目を何度も入力し忘れています。サポートチケットや機能リクエストで終わらせるのではなく、Replitと一緒に現在の動作を理解し、的を絞った改善を提案して、開発プレビューで試しましょう。結果の準備ができたら、チームがレビューできるようにプルリクエストを準備します。

同じワークフローは、分かりにくいエラーメッセージ、壊れたヘルプリンク、ユーザーの専門知識が必要なより大きな改善にも役立ちます。まず1つの問題と、変更がそれに対応できているかを確認する明確な方法から始めてください。

## こんな方におすすめ

* 繰り返し発生するお客様の問題を、修正案にしたいサポート担当者。
* 既存の実装と照らして改善を評価したいプロダクトマネージャー。
* 変更をレビューに提出する前に、実際のワークフローで試行錯誤したいデザイナーやエンジニア。

## コネクタ

GitHubの代わりにGitLabを使用することもできます。サポート用のコネクタは任意です。無害化したフィードバックの要約から始めることも、接続済みで読み取る権限のあるソースをReplitに示すこともできます。

## 始める前に

ワークスペースでリポジトリベースの開発にアクセスでき、リポジトリを読み取る権限が必要です。プルリクエストを開くには、ブランチをプッシュする権限、またはチームが承認したフォークのワークフローを使用する権限も必要です。

具体的な問題を1つ選び、影響を受ける体験を実装しているリポジトリを特定します。例からお客様の個人情報を取り除いてください。アプリを試すときは、実際のお客様のアカウントではなく、テストデータと開発用の認証情報を使用します。

接続の手順については、[リポジトリに接続する](https://docs.replit.com/ja/build/code/connect-your-repository.md)をご覧ください。

## Replitにプロンプトを送る

Customers report that they cannot tell which required signup field they missed.
Review \[feedback source or sanitized summary] and inspect the signup flow in
\[repository URL]. Explain the current behavior and propose a focused improvement
using our existing form components. Keep validation rules unchanged. Ask me to
confirm the approach before editing, then show me a development preview and
relevant test results. Do not commit, push, or open a pull request until I ask.

## 期待できること

```mermaid theme={null}
flowchart LR
    A["Customer feedback"] --> B["Understand the existing code"]
    B --> C["Agree on a focused change"]
    C --> D["Preview and verify"]
    D --> E["Propose it for team review"]
```

**1. 問題を理解する**

Replitは、ユーザーが提供した、または取得を許可したフィードバックを読み取り、
関連する実装を調べます。提案された説明がお客様の問題と一致しているかを
確認してください。いくつかの報告があっても、すべてのお客様が影響を受けている
証拠にはならず、ソースコードだけでは本番環境での動作を確定できません。

**2. 改善内容に合意する**

何を変更し、何をそのままにするかを決めます。この例では、
目標は新しいサインアップ要件の追加ではなく、必須項目のエラーを分かりやすくすることです。
既存のコンポーネントを再利用し、無関係な変更は分けておくようReplitに依頼します。

**3. プレビューで変更を試す**

Replitは開発用のセットアップを準備し、合意した変更を加え、セットアップが対応している場合は
アプリを起動します。プレビューを開き、必須項目を空のままフォームを送信してから、修正します。
エラーメッセージ、レイアウト、操作について具体的なフィードバックを伝えてください。

セットアップに認証情報が必要な場合は、安全なシークレットのフローを通じて、
権限を限定した開発用の認証情報を入力します。モックサービスを承認する場合は、
実際の連携のテストとして扱わず、その制限を明確にしておいてください。

**4. 結果を確認する**

関連するチェックを実行し、成功、失敗、ブロックされたテストを報告するようReplitに依頼します。
diffを確認し、既存の検証動作が維持されていることを確かめます。
関連する場合は、キーボード操作と狭い画面での動作も含めてください。

スクリーンショットは視覚的な変更の説明に役立ちますが、テストやレビューの代わりにはなりません。

**5. プルリクエストを準備する**

結果に満足し、その制限事項を理解したら、次のように依頼します。

Open a draft pull request for this improvement. Follow the repository's
contribution guidelines. Describe the customer problem without including
private customer details, explain the change, and include relevant test
results and visual evidence. Clearly state anything we could not verify.

GitLabの場合は、ドラフトのマージリクエストを依頼します。チームは、既存のプロセスを通じて
提案された変更をレビューします。リクエストを開いても、マージやデプロイは行われません。

最終的に、お客様の問題を実装とその検証の証拠に結びつけた、的を絞ったコントリビューションが完成します。お客様に問題が解決したとお伝えする前に、変更が実際にリリースされたことを確認してください。

## 自分に合わせて活用する

Check whether an open issue or pull request already addresses this feedback
before we start. If it does, summarize that work and suggest how I can contribute
without duplicating it.

The feedback is about a typo in the signup confirmation, not the signup logic.
Correct only that text, preserve the existing styling, and show me the result.

This improvement needs a business rule confirmed by our product specialist.
List the unresolved decisions before implementing anything. Keep confirmed
behavior separate from assumptions.

## トラブルシューティング

> **フィードバックが曖昧で再現できない**
>
> 影響を受けるステップ、期待される動作、実際に観察された動作を尋ねます。
> 無害化した例を使用してください。考えられる説明と、コードおよび開発テストで
> 裏付けられた調査結果を、Replitに区別してもらいます。

> **プレビューを実行できない**
>
> リポジトリのセットアップ手順を確認し、不足している依存関係、サービス、
> 権限を特定するようReplitに依頼します。動作をテストしたと主張せず、
> 引き継ぎの際にブロッカーを報告してください。

> **提案された修正が大きくなりすぎている**
>
> 元の問題に立ち返り、役に立つ最小限の変更を依頼します。
> より広範な再設計や新しい要件は、フォローアップの作業として分けてください。

> **レビュアーが変更を求めている**
>
> フィードバックを評価し、適切な場合は既存のオープンなリクエストを更新するよう
> Replitに依頼します。修正後は、影響を受ける動作を再確認してください。
> リクエストがすでにマージされている場合は、追加の作業を新しいコントリビューションとして扱います。

## 関連情報

> **[お客様のフィードバックを分析する](https://docs.replit.com/ja/use-cases/analyze-customer-feedback.md)**
>
> 取り組む改善を選ぶ前に、繰り返し現れるテーマを特定します。

> **[Replitでコーディングする](https://docs.replit.com/ja/build/code/code-with-replit.md)**
>
> リポジトリベースの開発を理解し、チームで始めましょう。