オウンドメディアの運営体制——編集長・担当者・専門家の役割分担

オウンドメディアの記事が止まるとき、人数不足だけが原因とは限らない。全員が確認者になり、誰も決定者になっていない。専門家へ原稿を渡したものの、どこを見てほしいか伝わっていない。担当者が休むと、代わりに企画を進められる人がいない。こうした滞留は、組織図より意思決定の設計に起因する。

運営体制は「何人置くか」からではなく、「誰が何を決めるか」から設計する。最低限必要なのは、決める、進める、つくる、確かめるという四つの機能である。同じ人が複数を兼ねてもよい。ただし、企画採否、専門的事実、公開、訂正など、判断ごとの最終責任者は一人にする。期限、代替者、境界外の判断を上げる先まで決めれば、少人数でも記事を次へ渡せる。

運営体制は、人数より「誰が決めるか」から設計する

編集会議へ事業部、広報、法務、専門家、経営が参加しても、それだけでは体制にならない。それぞれが意見を述べた後、誰が採否を決めるのか。専門家の返答が遅れたとき、誰が期限を調整するのか。公開後に誤りが見つかったとき、誰が非公開や訂正を決めるのか。この三つが不明なら、会議の参加者が増えるほど待ち時間も増える。

GOV.UKのService Manualは、service ownerに全体の意思決定権と継続改善の責任を置き、product managerに優先順位、delivery managerに進行を妨げる障害の除去、content designerに利用者需要に基づく計画・制作・レビューを割り当てる。[1] 政府デジタルサービスの職種を企業メディアへそのまま移す必要はない。参考になるのは、責任、優先順位、進行、専門作業を別の機能として定義している点だ。

品質は全員で守るが、最終責任は誰かという問いも分けられている。同資料は、品質をチーム全体の責任としながら、最終責任はservice ownerにあるとする。[1] 「全員で責任を持つ」を「全員の承認が必要」と読み替えない。協力者は複数でも、判断のownerは一人にする。

編集方針の記事では、企画を公開・修正・見送りへ分ける六つの確認を整理した。運営体制は、その各判断を誰が担い、何を受け取れば次へ進められるかを定める。

編集長・運営担当・専門家の役割を、四つの機能へ分ける

企業ごとに肩書は違う。「編集長」が原稿もCMSも分析も一人で担う場合もあれば、広報責任者が最終公開だけを判断する場合もある。肩書から始めると、自社に同じ職位がないだけで設計が止まる。まず四つの機能を置く。

編集責任者は「決める」を持つ。運営担当は企画を次の状態へ動かす。執筆・編集担当は、ばらばらの情報を読者が使える原稿へ変える。専門家や法務は、依頼された範囲を確かめる。経営スポンサーは毎回の文面承認者ではなく、予算、人員、優先順位、編集部の境界を超えるリスクを支える。

GOV.UKの別の手順は、必要なスキルと人数はサービスの段階、規模、複雑性で変わるとする。公開後も保守、改善、利用者対応を続けられる持続可能なチームが必要だ。[3] オウンドメディアも、立ち上げ時の執筆人数だけで体制を数えない。公開後の訂正、更新、計測まで処理できるかを見る。

判断ごとに最終責任者を一人だけ置く

役割表だけでは「この原稿は誰待ちか」が分からない。企画から公開後まで、判断の種類ごとにownerを置く。

ここでいう最終責任者は、何でも一人で行う人ではない。GitLabは公式ブログのManaging EditorとDirectorをDRIとし、企画の承認・改善・不採用、blog team review、必要なlegal review、CMSへの入稿、公開後変更の経路を分ける。[4] 組織固有の流れではあるが、一人の編集者が全工程を独占するのではなく、各工程の責任と受け渡しを明示した例として読める。

判断権限は、通常時だけでなく境界外も書く。GOV.UKのガバナンス原則は、チームが決めてよい範囲と、その外側の判断を誰へ上げるかを明確にするよう求める。責任者は頻繁に判断し、blockerを取り除き、外部の圧力からチームを守る。[2] 企業メディアなら、通常記事は編集責任者、個人情報や重大な法的リスクは指定確認者と経営スポンサーへ上げる、といった境界を先に決める。何でも法務へ送るのではなく、送る条件を決める。

レビュー依頼に範囲・期限・代替者を書く

「確認お願いします」という依頼は、確認者に編集責任まで渡してしまう。専門家は事実だけを見ればよいのか、構成案へ意見するのか、公開の可否を判断するのかが分からない。返答期限もなければ、自分の本業より先に扱う理由がない。

レビュー依頼には五つを書く。

• 判断してほしいこと：数字と適用条件の事実確認、画像権利、個人情報など。
• 見なくてよいこと：語調、章順、別テーマの追加など、編集側が持つ範囲。
• 原稿の状態：構成案、初稿、公開前最終稿のどれか。
• 返答期限と代替者：いつまでに、難しければ誰へ渡すか。
• 未回答時の扱い：延期する、該当箇所を削る、別資料で検証する。自動承認にはしない。

Design in governmentが紹介するdesign critでは、完成後ではなく途中の具体物を見せ、問題、利用者、制約、根拠に沿ってフィードバックする。「好きではない」のような個人の好みは有用な指摘としない。発表者とは別に記録者を置く。[6] 原稿レビューでも、対象と根拠を指定し、意見を記録して編集責任者が採否を決めれば、全員の言い回しを足した文章になりにくい。

専門家が一人しかいない場合も、second reviewをなくす必要はない。DWPのcontent designerは、複合チームで一人だけのcontent担当になる場合がある。公式ブログでは、役割と期待をチームで共有し、別案件のcontent designerによる2iを置く実例も紹介されている。[5] 同じ専門領域の人を常勤で増やせなくても、別部署、外部専門家、過去資料など、確認経路をあらかじめ用意できる。

少人数では役割を兼ねても、確認工程を潰さない

一人または二人の編集部が、編集責任者、運営担当、執筆者を兼ねることは現実的だ。兼務そのものが問題ではない。帽子を替える時点と、他者の確認が必要な時点が記録されないことが問題になる。

たとえば一人編集部なら、月曜に企画採否を「編集責任者」として決め、火曜から執筆者として調査する。初稿ができたら専門家へ事実確認を依頼し、自分は編集責任者として根拠と読者の問いを再点検する。公開後は運営担当としてリンク、画像、計測を確認する。人は一人でも、判断のログと順序は分けられる。

逆に、五人いても全員が企画提案と文面修正だけを行い、公開判断と進行を持つ人がいなければ止まる。体制の最小単位は人数ではなく、四つの機能と判断ownerが埋まっているかで測る。技術広報の運営体制でも、エンジニア、広報、編集者、公開責任者の確認を分けた。一般の企業メディアでは、ここへ事業、法務、経営を常設参加者として足すのではなく、必要条件に応じて呼ぶ。

運営量も執筆可能数だけで決めない。専門確認、画像権利、CMS、公開後の訂正までを一つの処理能力として見る。確認待ちが二本続いたら新規企画を増やさず、依頼範囲、期限、代替者を直す。公開後の修正が滞るなら、次の本数を増やす前に訂正ownerを決める。

2026年に公開された英国政府のcontent design技能見直しは、evidence-based design、iterative design、leading designなどを複数組織で再定義し、contentを後工程の孤立作業ではなく、協働する設計工程として捉える。[7] 役割は一度決めて終わりではない。媒体の段階、扱うリスク、企画量が変われば、必要な技能と受け渡しも見直す。

運営体制をつくる最初の作業は、人名を組織図へ入れることではない。六つの判断にownerを置き、四つの機能を誰が担うかを書き、返答期限、代替者、境界外の上げ先を決める。そのうえで足りない技能や時間が見えたときに、人を増やす。そうすれば、全員が確認しているのに誰も次へ進めない状態を避けられる。