外注ライターへのフィードバックシートの作り方｜テンプレートと返し方

「丁寧に赤を入れて返せば、ライターの原稿は良くなっていくはず」。1人のライターと続けて仕事をすると、指摘した箇所が次の原稿で直っているので、赤入れの丁寧さが品質を決めるように見えます。ところが、ライターが増えると同じ指摘を人ごとに書くことになり、修正の往復は人数分だけ増えていきます。往復を減らすのは赤入れの丁寧さではなく、何をどう直すかの判断基準を、発注の時点で渡しておくことです。

本記事では、フィードバックシートの設計原則とそのまま使えるテンプレートから、指摘の書き方、編集側で直す範囲、返すタイミングまで、累計8,000記事以上を制作してきた記事制作会社の視点で順を追ってお伝えします。

フィードバックシートの3つの設計原則

フィードバックシートは、何をどう直すかの判断基準を、ライターと発注側で事前に共有するための文書です。設計の原則は次の3つで、外すと確認項目が増えるだけで修正は減りません。

判定基準を明文化すること

「もう少し読みやすくしてください」という指摘は、フィードバックとして機能しません。ライターには「読みやすい」の基準がわからないので、自分の感覚で直すしかなく、期待とずれて再び修正が発生します。

シートの項目は、YesかNoで判定できる粒度まで落とすのが原則です。「読みやすい」ではなく「1文が80文字以内か」「接続詞で始まる文が3つ続いていないか」のように、判定に迷う余地がないところまで具体的に書きます。

経営者

文章の良し悪しは、結局は読む人の主観ではないでしょうか？

Writers-hub
編集部

主観で決める部分は残ります。だからこそ、主観で判断する部分と、YesかNoで判定できる部分を分けるのがシートの役目です。判定できる部分をシートに任せると、確認する人は独自の切り口や表現の良さといった、主観で見る部分に時間を使えます。

優先度を3段階で付けること

確認項目には、必ず優先度を付けます。全部が大事だと伝えると、ライターはどこから直せばよいかを判断できないためです。優先度は次の3段階に分けます。

「全部直してください」と返すのをやめ、「MUSTだけ先に直してください。SHOULDは次回から意識してもらえれば大丈夫です」と返すと、ライターが先に手を付ける箇所がはっきりします。

仕様書の補足として返すこと

シートの位置づけは、ダメ出しの一覧ではなく、発注時の仕様書で伝えきれなかった部分の補足です。「あなたの原稿のここがダメでした」という一覧になると、ライターは萎縮して冒険しなくなり、NICEに挙げた独自の切り口が原稿に出てこなくなります。

修正が多い原稿は、ライターより先に発注時の情報の不足から原因を探します。ライターが悪いのではなく、こちらの指示が足りなかったという前提に立つと、直す先が原稿から発注書に移ります。

関連記事：SEO記事の品質基準を統一する方法｜制作体制の最適化とチェックリスト活用術

フィードバックシートのテンプレート

フィードバックシートのテンプレートは、基本情報、確認項目、総合コメントの3つの欄でできています。Googleスプレッドシート、Notion、Excelのどれで作っても、構成は同じです。

基本情報の欄

基本情報の欄には、次の6つを書きます。

• 記事タイトル：対象の記事のタイトル
• ライター名：担当したライター
• 納品日：初稿の納品日
• FB担当者：フィードバックする人
• FB日：フィードバックを返した日
• ステータス：初稿確認、修正依頼、修正確認、公開OKのどれか

確認項目の欄

確認項目の欄は、優先度ごとに分けた13項目です。各項目の右に、判定（OK・NG）と、NGのときのコメントを書く列を設けます。

80文字や30％といった数値は例です。自社のレギュレーションと、使っているコピーチェックツールに合わせて書き換えます。全項目を一度に入れる必要はなく、MUSTの5項目だけで回し始めても構いません。

総合コメントの欄

総合コメントの欄には、確認項目に収まらない全体へのフィードバックを書きます。「全体的に良いと思います」のような情報の無いコメントは書かず、「何が良かったか」と「次回に活かしてほしいことは何か」の2つを具体的に書きます。

悪いフィードバックと良いフィードバックの違い

悪いフィードバックと良いフィードバックの違いは、ライターが読んですぐに直せるかどうかです。

悪い例

全体的にわかりにくいです。もう少し具体的に書いてください

この指摘を受けても、ライターは何も直せません。「全体的に」がどこを指すのかがわからず、「具体的に」の中身も書かれていないためです。

良い例

H2「導入手順」の下の第2段落（「まず設定画面を開き〜」の部分）が、操作の手順なのか概念の説明なのか判断できませんでした。手順であれば番号付きリストに変え、概念の説明であれば手順の節の前に移してください。

良い例には、ライターが直すのに要る次の3つの要素がそろっています。

• Where（どこ）：該当箇所を見出しと段落で特定する
• What（何が問題か）：主観ではなく、基準に照らして何が外れているかを書く
• How（どう直すか）：直し方を示し、正解が1つでなければ選択肢を渡す

3つの要素のどれかが欠けた指摘は、丁寧に書いてもライターを迷わせます。形の手本にしてほしい記事があるときは、Howにその記事のURLを添えます。

ライターに返す指摘と編集側で直す箇所

ライターに指摘を返すかどうかの基準は、次の原稿でも同じ直しが要るかです。次も要る直しはシートのコメントで返します。その原稿の中だけで済む直しは、編集側で直してしまうほうが往復は減ります。

1回きりの直しでも、書き手にしか直せないものは必ず返します。取材で聞いた内容が足りない箇所や、数字の情報源がわからない箇所は、編集側では直せないためです。

経営者

ライターがAIを使って書いた原稿は、見分けて差し戻したほうがよいでしょうか？

Writers-hub
編集部

見分けるより、シートのMUSTを満たしているかで判定するほうが確実です。弊社は、AIが書いたかどうかより、検索した人の知りたいことに答えているかが問われると考えています。ただ、生成AIの文章には、もっともらしい誤りの数字が混ざることがあるので、MUSTの1番（出典の確認）は念入りに見ます。

見落とされがちですが、編集側で黙って直すと、ライターは直されたことを知らないまま、次の原稿でも同じ書き方をします。直した箇所はGoogleドキュメントの提案モードやWordの変更履歴で残し、ライターが次の原稿の前に見られるようにします。同じ直しが続いたら、シートの項目に足して返す側に移します。

フィードバックを返すタイミングと運用のコツ

フィードバックシートを使うのは、初稿を確認するときだけでなく、発注から公開後までの5つの段階です。

返却日と修正の回数を発注の時点で決めておくと、ライターは次の仕事の予定を立てやすくなり、確認する側も原稿をためずに済みます。

NICEの欄は、良かった点を記録する場所でもあります。「ここが良かった」を書いておくと、シートがダメ出しの一覧になるのを防げます。「このライターは事例の書き方が得意」といった情報もたまり、次の発注で誰に頼むかを決める材料になります。

まとめ｜修正の往復を減らすのは先に渡す判断基準

外注ライターへのフィードバックで修正の往復を減らすのは、丁寧な赤入れではなく、何をどう直すかの判断基準を先に渡しておくことです。フィードバックシートを入れても修正がゼロになるわけではなく、ライターとの相性や記事のテーマの難しさでも修正の量は変わります。それでも、長い修正依頼を書く時間や確認の往復、同じ指摘を何人にも書く手間は、シートで減らせます。

最初の一歩は、MUSTの5項目と優先度を、次の発注書に添えることです。NGが続いた項目を発注書に書き足していくと、シートの項目は自社のレギュレーションに合ったものに変わっていきます。

私たち合同会社Writers-hubは、累計8,000記事以上を制作してきた記事制作会社です。代表の米山拓真は、これまでに200人以上のライターを育ててきました。記事コンテンツの制作支援では、編集者・ライター・監修者のチーム編成から、レギュレーション策定、品質管理フローまでを構築し、担当者が替わっても品質を保つための体制づくりをお手伝いしています。

関連記事：インタビューの質問テンプレート｜用途別の質問例と深掘りの型を制作現場から解説

関連記事：インタビュー記事のテンプレート｜形式別の構成と見出しの作り方

関連記事：インタビューの仕方｜当日の進行と深掘り質問の出し方

関連記事：WordPressの記事入稿マニュアルの作り方——新人でも迷わないSOP設計

関連記事：コンテンツブリーフの書き方——ライターが「何を書けばいいかわからない」をなくす