一本につき、答える疑問を一つにする
「ゲーム開発のコツ」という広い題名を何本も作ると、内容が重なりやすくなります。「指で隠れる表示をどう配置するか」「保存データは別端末へ移るか」のように、具体的な疑問へ分けます。読後に一つの判断や操作ができることを目標にします。
記事一覧では、タイトルだけでなく概要も並べて重なりを確認します。二つの記事の結論がほぼ同じなら、一つにまとめるか、対象の場面を分けます。文字数を増やすためだけに同じ説明を言い換えて並べないようにします。
経験、提案、仕様を混ぜない
実際に試したことは環境と結果を示し、試していないものは設計上の提案として書きます。商品を使っていないのに使用レビューを名乗ったり、測っていない改善率を載せたりしません。AIが自然な文章として補った経験談も、事実でなければ削除します。
APIやサービスの制限など、変わり得る仕様は公式資料を確認し、参照先を示します。一方、画面設計の意見は意見として説明します。根拠の種類が分かると、読者も自分の環境へ当てはめやすくなります。
公開前に、文章以外も読む
見出しだけを追って内容が理解できるか、リンク先が該当する説明か、スマホで表がはみ出さないかを確認します。記事内で紹介する機能が現在のアプリにあると書くなら、実際の画面や実装も照合します。未来の案を実装済みとして扱わないことが大切です。
- 誰の、どの疑問に答える記事かが一文で言える。
- 体験していないことを体験談として書いていない。
- 仕様の参照先と、筆者の考えが区別できる。
- 広告や商品紹介がある場合は、その箇所で分かる。
- 訂正の連絡先と更新日が見つかる。