オウンドメディアの編集方針は、理念や文体を並べるだけでは機能しない。必要なのは、会社が伝えたい企画を、読者が使える記事として「公開する」「直して公開する」「見送る」に分ける基準である。

企業の目的を消す必要はない。目的は、媒体が扱う領域と優先順位を選ぶ。一方、読者の用事は、その企画を記事として公開してよいかを決める。本稿では、この二つを混同せず、企画判断に使える編集方針へ落とし込む。

企業の目的と読者の用事を編集判断へ集め、公開・修正・見送りへ分ける図
企業の目的はテーマを選び、読者の用事は公開条件を決める。 — Visual: CONTEXT編集部

編集方針は、記事の採否を決められて初めて機能する

編集方針、媒体理念、スタイルガイドは役割が違う。媒体理念は「なぜ発信するか」を示し、スタイルガイドは表記や語調をそろえる。編集方針は、個別の企画を記事にするかどうかを決める。

英国国家統計局(ONS)のコンテンツ手順は、誰が何をする必要があり、なぜ必要かという「user need」を証拠から定める。明確な需要と上位目的がなければ公開しない。GitLabのブログ運用も、企画を approve、improve、not a fit に分け、ブログチームの確認なしに公開しない。[1][2]

両者の組織目的は企業メディアと同じではない。ただし、「よい記事にする」という曖昧な合意ではなく、公開しない条件まで決めている点は参考になる。編集方針に「誠実である」とだけ書いても、発売情報を急いで載せるべきか、根拠を待つべきかは決められない。

たとえば事業部から「受賞を記事にしてほしい」と依頼されたとする。これは架空の例だ。受賞名と担当者の喜びだけなら、ニュースリリースの役割に近い。審査基準、評価された取り組み、読者が応用できる条件、限界まで確認できるなら、記事として成立する余地が生まれる。編集方針は、この分岐を担当者の好みから切り離す。

企業目的はテーマを選び、読者の用事は公開条件を決める

企業は、自社が知見を持つ領域、事業上重要な課題、専門家へアクセスできるテーマを選んでよい。むしろ、目的が曖昧な媒体は企画が散らばる。先に「誰のどの判断を助けるか」を定める考え方は、コンテンツ戦略の記事でも整理した。

ただし、事業目標だけでは公開理由にならない。読者の用事は「経営者に読んでほしい」ではなく、「新しい発注先を選ぶ担当者が、比較条件と導入リスクを判断する」のように、行動まで書く。そうすれば、必要な根拠と削ってはいけない条件が見える。

比較表
企業が決めてよいこと編集方針で制限すること
どの事業課題や専門領域へ資源を置くか読者の用事がない社内報告を記事へ見せかけない
どの時期に情報需要が高まるか発売日だけを理由に根拠不足で公開しない
どの専門家や一次資料へアクセスするか不利な条件や代替案を落として宣伝へ変えない
何を成果として測るかPVのために誤認を招く見出しや主張を使わない

読者価値は、企業に不利な内容だけを書くことではない。製品が向く条件と向かない条件、判断の過程、根拠の限界を同時に示せば、企業の専門性と読者の判断は両立する。境界は「企業を出すか」ではなく、「読者が判断するための重要事項を企業都合で落としていないか」にある。

公開・修正・見送りを六つの欄で決める

理念を実務へ変えるには、企画ごとに六つの欄を埋める。空欄があれば、原稿の長さや表現を直す前に、企画そのものへ戻る。

編集方針を六つの確認から三つの判定へつなぐ判断票
六欄のどこが不足したかを示せば、修正は書き直しの無限ループにならない。 — Diagram: CONTEXT編集部(ONSとGitLabの公開基準を参考に整理)
  • 企業の目的:なぜ今、この媒体が扱うのか。
  • 読者の用事:誰が、何を判断・実行するために読むのか。
  • 記事の答え:発表文や営業資料にはない、確認できる答えは何か。
  • 根拠と限界:一次資料、比較対象、数字の条件、未確認事項は何か。
  • 利害と権利:自社・取引・広告の関係と、画像・引用条件をどう示すか。
  • 公開後:訂正窓口、更新条件、責任者は誰か。
比較表
判定条件次の行動
公開する六欄が埋まり、反対材料を含めても答えが成立する最終確認と公開へ進む
直して公開する読者の用事はあるが、根拠・比較・開示・権利の一部が不足する不足欄、責任者、期限を記録する
見送る社内告知だけ、検証不能、重要な利害や限界を示せないリリースや社内報など本来の形式へ戻す

一つの記事に採用、営業、技術共有を同時に背負わせると、六欄の答えが複数になる。技術ブログの記事で見たように、目的を分けることは情報量を減らすためではなく、読者の用事を明確にするためである。

事業部は事実を確認し、編集責任者は記事の答えを決める

編集方針があっても、レビューする人の権限が曖昧なら機能しない。ONSはpeer reviewで構成やuser needを見て、stakeholder reviewでは誤り、誤解、不足の指摘を求める。GitLabも編集責任者をDRIとして置き、法務などの確認が必要な場合には保留できる仕組みを持つ。[1][2]

資料とノートPCを囲み、異なる役割の参加者が議論するワークショップ
DWPとGDSのワークショップ。異なる立場の要望を利用者の場面と初稿レビューへ変えた。 — Photo: Government Digital Service / Crown copyright, Open Government Licence v3.0(掲載ページ、原画像をWebP変換)

企業メディアでは、事業部や専門家が数字、製品条件、機密、不足を確認する。法務・コンプライアンスは公開リスク、必要な表示、許諾を確認する。編集責任者は、読者の問い、構成、タイトル、根拠の十分性、公開判定を決める。事実確認を受けることと、都合のよい結論へ書き換えることは別である。

Thomson Reutersは、独立性を理念だけでなく組織上の権限へ結びつけている。[5] これは報道機関の制度であり、企業メディアが同じ独立性を名乗れる根拠ではない。学べるのは、方針の実効性には「誰が止められるか」が必要だという点だ。経営が媒体目的と重大リスクの範囲を決めても、個別記事から不都合な事実を消す依頼は例外として記録し、編集責任者が公開判定をやり直す。

利害・訂正・更新を、公開後の付記にしない

利害関係は、読了後に見つかる奥付へ隠さない。米国FTCの公式解説は、広告を独立・中立なコンテンツのように見せないこと、誤認を避けるための開示を明瞭かつ目立つ形で示すことを求める。[3] これは米国の事業者向け資料であり、日本法の助言ではない。それでも、自社記事、広告、寄稿、取引関係を読む前に判断できるようにする編集原則は採用できる。

訂正も同じである。APは、オンライン情報を検証して原典へ帰属させ、事実誤認の訂正を読者に見える形で示し、単なる「軽微な編集」と呼ばない。[4] 企業メディアが報道機関と同じ規則を持つ必要はないが、重要な誤りを黙って上書きすれば、読者は変更前後を判断できない。訂正日、訂正内容、影響範囲を記事末尾へ残す。

共通コンテンツ基準を作るワークショップ参加者の付箋
基準は文書だけでなく、協働と変更履歴で運用される。 — Photo: Government Digital Service / Crown copyright, Open Government Licence v3.0(掲載ページ、原画像をWebP変換)

GDSとDWPの事例では、チームごとに異なるガイドが利用者体験を分断した。過去の標準化が定着しなかった反省から、企画段階の協働、何を証拠とするかの合意、変更を記録する仕組みを組み込んだ。[6] 編集方針も、公開後を六つ目の欄として先に設計する。訂正が起きたとき、事業が変わったとき、読者の用事や根拠が変わったときに見直し、変更理由を履歴へ残す。

編集方針の完成形は、美しい宣言文ではない。「この企画はなぜ公開でき、別の企画はなぜ直すのか」を同じ六欄で説明できる状態である。企業の目的を入口にし、読者の用事、根拠、利害、権利、公開後の責任を通過させる。そこで初めて、企業都合と読者価値の境界が、毎回使える判断になる。

まず一枚の判断票で、直近の企画三件を再判定するとよい。公開済みの記事を一括で書き換えるのではなく、これから出す企画について、六欄のうち答えられない箇所を記録する。見送りが続くなら、担当者を責める前に、媒体目的が広すぎないか、必要な一次資料へアクセスできるかを見直す。修正が続くなら、不足欄と修正責任者が結びついているかを確認する。方針の価値は、公開本数を増やすことではなく、公開しない理由と直せば公開できる条件を共有できることにある。

Sources / 参考資料