この記事はバーニングトライブの運営者による情報発信です。自社サイトへのリンクを含みます。
アプリへの問い合わせを読んだ直後は内容を覚えていても、数日後には「何が起きたか」と「何を直そうとしたか」が混ざりがちです。問い合わせの原文を残す場所と、開発作業へ渡すメモを分けると、確認のために同じ会話を何度も読み返さずに済みます。ここでは、少人数で運営するアプリの記録例を紹介します。
一件に一つの管理番号を付ける
メールとフォームに同じ連絡が来た場合、別々の不具合と数えないよう管理番号をそろえます。「受付日、連絡経路、管理番号」の三つを一覧に置き、返信先などの個人情報は閲覧者を限定した元の記録で管理します。開発メモにメールアドレスを転記する必要はありません。
観察と推測を別の欄に書く
「保存ボタンの後で画面が白くなった」は観察、「通信が原因だと思う」は推測です。端末、アプリの版、直前の操作、再現の有無を分けて控えます。再現できない場合は未確認とし、報告が誤りだと決めつけないことも大切です。
次に確かめる操作を一つ決める
「保存を調べる」より「入力を空にして保存したときの表示を見る」の方が着手しやすくなります。調査中、修正中、確認待ちなど状態を付け、次の担当者と確認する日を記録します。返信済みと修正済みは別の欄にしておきます。
終わった理由まで残す
修正した版と、確認した操作を記録して一件を閉じます。仕様の説明で解決した場合も、その説明を短く残します。似た問い合わせが続くなら機能追加だけでなく、画面の案内やヘルプの説明を見直す材料になります。
運営サイト：バーニングトライブ。関連情報を読む際も、記載の対象や更新日を確認してください。