フィードバックシートは「設計図」だ。
ライターに原稿を発注して、上がってきたものを読んで、赤入れして、戻して、また上がってきたものを読んで——このループを何往復もやっている人、多いと思う。つまり3ヶ月前の私だ。
Writers-hubでライターさんのディレクションを担当し始めた頃、私は「丁寧にフィードバックすれば品質は上がる」と信じていた。実際、1人のライターさんに対しては確かにそうだった。でも5人、10人と外注先が増えた瞬間、同じ指摘を別のライターさんに繰り返している自分に気づいた。「ここ、ですます調に統一してください」「見出しの粒度を揃えてください」「数値の出典を明記してください」——毎回、毎回。
米山さんに相談したら、こう言われた。「それ、お前の頭の中にしかないルールを毎回口頭で伝えてるだけだろ。仕組みにしろ」
……正直、刺さった。
フィードバックシートというのは、要するに「何をどう直すか」の判断基準を、ライターと自分の間で事前に共有するためのドキュメントだ。修正依頼のたびにゼロから説明するのではなく、共通のチェックリストと評価軸を持つことで、指摘の工数も、ライターの迷いも、同時に減らす。
この記事では、私がWriters-hubで実際に使っているフィードバックシートの設計思想と、コピペして明日から使えるテンプレートを共有する。
フィードバックシートの設計原則——「お願い」を「仕組み」に変える
フィードバックシートを作る前に、設計思想を3つだけ押さえておきたい。ここを外すと、ただのチェックリストが増えるだけで終わる。
1. 主観を排除して、判定基準を明文化する
ここ、一番大事。
「もう少し読みやすくしてください」——これ、フィードバックとして機能しない。ライターからすると「読みやすい」の基準がわからないから、自分の感覚で直すしかない。結果、こちらの期待とズレて、また修正が発生する。
フィードバックシートの項目は、YesかNoで判定できる粒度まで落とす。「読みやすい」ではなく「1文が80文字以内か」「接続詞で始まる文が3連続していないか」。判定に迷う余地がないレベルまで具体化する。
（「でも、文章の良し悪しって主観じゃない？」と思った方——その通り。だからこそ、主観で判断すべき部分と、機械的にチェックできる部分を分離するのがシートの仕事なんだよ）
2. 優先度をつける。全部大事は何も大事じゃない
これもめちゃくちゃ大事。
「『全部大事だから全部チェックして』は、『何も大事じゃない』と同義だよ」——これは米山さんの受け売りだけど、本当にそうだと思う。
フィードバック項目には必ず優先度をつける。私は3段階にしている。
- MUST（必須）: これを外すと公開できない。事実誤認、トンマナ逸脱、SEO要件の未達成
- SHOULD（推奨）: 品質に直結するが、初稿では目をつぶれる。見出し構成の最適化、内部リンクの配置
- NICE（理想）: あれば嬉しいが、なくても通せる。表現の洗練、独自の切り口
ライターさんに「全部直してください」と渡すのと、「MUSTだけ先に直してください、SHOULDは次回から意識してもらえれば」と渡すのでは、修正の速度もモチベーションも全然違う。
3. フィードバックは「ダメ出し」ではなく「仕様書の補足」
ここ、意識しないと簡単にズレる。
フィードバックシートが「あなたの原稿のここがダメでした」リストになると、ライターさんは萎縮する。萎縮したライターは冒険しなくなる。冒険しないライターの原稿は無難でつまらない。つまらない原稿はSEOでも勝てない——負のスパイラルだ。
シートの立ち位置は「発注時の仕様書で伝えきれなかった部分の補足」。ライターが悪いのではなく、こちらの指示が足りなかった、という前提に立つ。実際、修正が多い原稿の原因を掘ると、8割はこちらの発注時の情報不足だったりする（正直、これに気づくまで半年かかった）。
テンプレート——コピペして使える項目設計
実際に私がWriters-hubで運用しているフィードバックシートの項目を公開する。Googleスプレッドシートで管理しているが、Notionでもエクセルでも構造は同じだ。
基本情報エリア
- 項目: 記事タイトル（対象記事のタイトル）
- 項目: ライター名（担当者）
- 項目: 納品日（初稿の納品日）
- 項目: FB担当者（フィードバックする人）
- 項目: FB日（フィードバック返却日）
- 項目: ステータス初稿確認 / 修正依頼 / 修正確認 / 公開OK
チェック項目エリア
ここが本体。カテゴリごとに分けて、各項目にOK/NGと具体的なコメント欄を設ける。
【MUST】公開ブロッカー
- 1. 事実・数値に出典があるか
- 2. ターゲットKWがタイトル・H2に含まれているか
- 3. 指定された構成案（見出し構成）に沿っているか
- 4. ですます/である調が統一されているか
- 5. コピーコンテンツ判定をクリアしているか（コピペ率30%以下）
【SHOULD】品質向上
- 6. 1文が80文字以内に収まっているか
- 7. H2直下にリード文（2〜3文）があるか
- 8. 具体例・事例が各セクションに1つ以上あるか
- 9. メタディスクリプションが120文字以内でKWを含んでいるか
- 10. 画像のalt属性が指定されているか
【NICE】加点ポイント
- 11. 独自の視点・経験に基づく記述があるか
- 12. 内部リンクの提案があるか
- 13. 読者のネクストアクションが明示されているか
総合コメント欄
ここにはチェック項目に収まらない、全体的なフィードバックを書く。ただし「全体的に良いと思います」のような情報量ゼロのコメントは禁止。必ず「何が良かったか」「次回に活かしてほしいことは何か」を具体的に書く。
悪いフィードバック vs 良いフィードバック
シートがあっても、書き方がまずければ意味がない。実際にやりがちな悪い例と、それをどう直すかを並べてみる。
悪い例:
全体的にわかりにくいです。もう少し具体的に書いてください
これ、言われた側は何も動けない。「全体的に」がどこを指すのかわからないし、「具体的に」の具体がない（皮肉じゃなく、本当にこういうフィードバック、やりがちなんだよ）。
良い例:
H2『導入手順』配下の第2段落（"まず設定画面を開き〜"の部分）が、操作手順なのか概念説明なのか判断できませんでした。手順であれば番号付きリストに変更、概念説明であれば手順セクションの前に移動してください。参考：同カテゴリの既存記事〇〇のフォーマット
違いは3つ。場所が特定されている。何が問題かが言語化されている。どう直すかの選択肢が提示されている。
つまり、良いフィードバックの構造はこうだ。
- Where（どこ）: 該当箇所をピンポイントで指定する
- What（何が問題か）: 主観ではなく、基準に照らして何が外れているか
- How（どう直すか）: 修正の方向性を示す。正解を1つに決めつけず、選択肢を渡すのがベター
この3点が揃っていないフィードバックは、どれだけ丁寧に書いてもライターを迷わせるだけだ。
運用のコツ——シートは「育てる」もの
テンプレートを作って終わり、にすると確実に形骸化する。運用で押さえておくべきことを3つ。
初回は一緒に埋める。 新しいライターさんとの初回フィードバックでは、シートを一方的に渡すのではなく、Zoomなりチャットなりで一緒に見ながら説明する。15分で終わる。この15分をケチると、その後の修正ラリーで3時間失う。
NGが多い項目は発注書を直す。 同じ項目で3回NGが出たら、それはライターの問題ではなく、発注時の指示が足りていない証拠だ。フィードバックシートの改善ポイントを発注書（構成案やレギュレーション）にフィードバックする。これが回り始めると、修正そのものが減っていく。
良かった点も記録する。 シートがダメ出し一覧になるのを防ぐために、NICE欄で「ここが良かった」も書く。ライターさんのモチベーション管理という意味もあるけど、それ以上に「この人はこういう表現が得意だ」という情報が蓄積されて、次の発注時のアサイン判断に使える（これ、最初は面倒だと思ったけど、半年続けたら発注精度が明らかに上がった）。
修正コスト半減は仕組みの問題
正直に言うと、フィードバックシートを導入しただけで修正コストがゼロになるわけじゃない。ライターとの相性もあるし、テーマの難易度にも左右される。
でも、「何を直すか」の認識合わせにかかる時間——これは確実に減る。Slackで長文の修正依頼を書く時間、「ここってどういう意味ですか？」の確認ラリー、同じ指摘を5人に5回する非効率。こういうコストが仕組みで吸収される。
仕組みで守るべきことをお願いで済ませるな——これが半年間ディレクションをやって、一番身に沁みた教訓だ。
シートのテンプレートは上に載せた通りだ。コピペして、自社のレギュレーションに合わせて項目を足し引きするだけで使える。全項目を一度に導入する必要はない。MUSTの5項目だけでも、まず回してみてほしい。
（全項目を完璧に運用してるディレクターがいたら、それはそれで別の意味で心配だけどね）