想定キーワード
- MVP 修正依頼
- 開発 フィードバック 書き方
- AI 開発 修正指示
- バグ報告 テンプレート
- Codex 修正依頼
- プロダクト改善 要望
試作アプリを作った後に大事なのは、修正要望の出し方です。
「ここを直して」
「なんか変」
「使いにくい」
「いい感じにして」
このような要望だけでは、開発者にも文章や作業を手伝う道具にも伝わりにくいです。
試作アプリを直してほしい時は、感想だけでなく、同じ手順で問題を確かめられる説明が必要です。
悪い修正要望
この画面が微妙なので直してください。
これでは、何が問題なのか分かりません。
- 見た目なのか
- 文言なのか
- 次に進むまでの流れなのか
- 動作なのか
- スマホ表示なのか
- 訪れた人のうち、使い始めるなど目的の行動をした人の割合なのか
受け取る側が推測することになります。
良い修正要望の型
目的:
何を改善したいか
現状:
今どうなっているか
問題:
何が困るのか
期待動作:
どうなってほしいか
優先度:
使えないなど今すぐ直すもの / 使い始めるまでの流れなど次に直すもの / 細かな文言など後で直すもの
確認方法:
直ったことをどう確認するか
この型を使うと、修正精度が上がります。
例文
目的:
スマホユーザーがトップページからすぐに作成開始できるようにしたい。
現状:
スマホ表示だと、開いて最初に見える範囲に試し始めるための主なボタンが見えていない。
問題:
ユーザーが下までスクロールしないと作成開始ボタンに気づかないため、離脱が増える可能性がある。
期待動作:
スマホ幅375pxでも、開いて最初に見える範囲に「無料で試す」ボタンが見えるようにする。
優先度:
次に直すもの
確認方法:
スマホ幅375pxでトップページを開き、開いて最初に見える範囲に試し始めるための主なボタンが表示されることを確認する。
これはかなり伝わりやすいです。
文章や作業を手伝う道具に投げる時の注意点
文章や作業を手伝う道具に修正依頼を出す時は、最後に必ず確認報告を求めます。
最後に、修正したファイル、確認した動作、未確認リスクを報告してください。
文章や作業を手伝う道具は「完了しました」と言いがちですが、何を確認したのかが分からないと危険です。
試作アプリの修正要望チェックリスト
□ 目的を書いたか
□ 現状を書いたか
□ 問題を書いたか
□ 期待動作を書いたか
□ 優先度を書いたか
□ 確認方法を書いたか
□ 画面の画像やURLを添えたか
□ 影響範囲を指定したか
□ やらないことも書いたか
□ 未確認リスクの報告を求めたか
まとめ
試作アプリの修正要望は、感想だけでは伝わりません。
目的。
現状。
問題。
期待動作。
優先度。
確認方法。
この6点をセットにすると、開発者にも文章や作業を手伝う道具にも伝わりやすくなります。
試作アプリは作って終わりではありません。
修正要望の質が、改善速度を決めます。
次にできること
文章や作業を手伝う道具や開発者に修正依頼を出す時は、テンプレート化しておくと、毎回の説明負荷を減らせます。
