編集会議は記事企画の採否と、制作を進めるための次の行動を決める場です。 候補を持ち寄るだけで終えず、読者の問い、答えを支える材料、担当者と期限を確認します。材料が足りなければ、何を確かめてから再検討するかを決めます。
新製品の紹介や社員インタビューなど、書けそうなテーマは出た。それでも会議の後に、誰が何を調べるかが決まっていない。企業のオウンドメディアを少人数で運営するなら、企画の数と同時に、次の作業へ渡せる状態かを確かめたいところです。事前資料から会議後の記録まで、使える形を整理します。
アジェンダ・記録は編集部の提案で、例は架空のものです。カバーはAIで制作したイメージで、実際の会議や顧客資料を撮影したものではありません。
編集会議では、今回決めることを先に共有する
編集会議では企画を採用するか、進行中の記事のどこを見直すかなど、その回で決めたい判断を議題にします。 会議の終わりに何が変わっていればよいかを、招集する段階で示します。
「来月の記事について」だけでは案を広げるのか、候補から選ぶのかが分かりません。たとえば「新製品の記事案を比べ、先に取材する一件と確認事項を決める」なら、持ってくる資料と必要な参加者を考えられます。話す項目と順序をまとめたものがアジェンダです。
最初は次の三種類から、今回必要な議題を選びます。
| 議題 | 会議で決めたいこと | 持ってくる材料 |
|---|---|---|
| 新しい企画の選定 | どの読者の問いに、何を使って答えるか | 企画案、読者の疑問を示す情報、使える資料 |
| 進行中の記事の判断 | 何が止まっていて、誰が判断するか | 該当する原稿・図版、未確認事項、選択肢 |
| 公開後の見直し | 記事や届け方のどこを確かめるか | 対象記事、読者の反応や計測記録、比較条件 |
すべてを毎回扱う必要はありません。進捗を読むだけなら事前の共有で済ませ、関係者の考えを確かめたい箇所を会議に残す方法があります。GitLabの公開ハンドブックも、会議の前に文書で進められないかを考え、招待にアジェンダへのリンクを含める運用を示しています。1 同社の遠隔勤務の指針であり、企業メディアの必須ルールではありません。
企画案は「読者の問い・答え・根拠」をそろえて持ち寄る
企画を比べる前に、誰が何を判断するための記事かと、今ある材料でどこまで答えられるかを短く書きます。テーマ名に加えて、この二つを見せると、採用・追加調査・見送りの理由を検討できます。
GOV.UKの「Identify user needs」は利用者が誰で、何をしようとしているか、どこに困っているかを既存の証拠から調べるよう案内しています。必要性の記述も、利用者・したいこと・その理由に分けています。2 行政コンテンツ向けの考え方を、企業記事の読者と目的を確かめる参考にします。
新製品紹介を扱う架空例で考えてみます。
- テーマ：新しい検査装置の紹介
- 読者の問い：導入を検討する現場担当者は、自社の工程で使えるかを何で確かめればよいか
- 記事で答えたいこと：使える対象と条件、導入前に確認する事項を整理する
- 手元の材料：公開仕様表と、開発担当者へ取材できる見込み
- 不足している材料：実際の運用条件、比較できる事例、図版の掲載可否
- 会議で決めたいこと：先に担当者へ条件を確認するか、別の企画を優先するか
この段階で「作業時間が短くなる」といった効果を、見込みだけで答えに入れないようにします。取材で分かりそうなことと、すでに裏付けのあることは分けます。検索語も読者の問いを探す材料ですが、検索数が大きいだけで、答えられる企画になるわけではありません。
切り口そのものを考えるときは記事の切り口の作り方へ、採否の軸をそろえるときは編集方針のひな形へつなげます。会議では、その軸に照らして今回の案を比べます。
アジェンダは、判断が必要な順に並べる
議題は、先に決まらないと次へ進めないものから並べます。たとえば読者や記事の役割が合意できていないなら、タイトルの言い回しより先に確かめます。制作の着手可否を決めたい回で、本文の細かな表現まで一度に直す必要はありません。
次は、企画の選定と制作中の記事を扱う回のアジェンダ例です。各段階で決めることを添え、扱い切れない議題は次の確認へ分けます。時間や頻度の標準を示すものではありません。
今回決めること：先に着手する企画と、確認待ちの記事の次の作業
1. 前回から残った確認事項
何が分かり、何がまだ判断できないか
2. 新しい企画の比較
読者の問い、手元の根拠、既存記事との差を確認
採用・保留・見送りと、その理由を決める
3. 制作中の記事の判断
原稿の該当箇所と選択肢を示す
追加確認、構成変更、日程変更のどれを進めるか
4. 次の行動の読み合わせ
担当、期限、再検討する条件、記録の置き場を確認
参加者には自分に何を確かめてほしいかも伝えます。製品仕様を確認する担当者と、掲載する企画を選ぶ担当者では見る資料と判断する範囲が違います。欠席する人の専門判断が必要なら、担当者を決めて別途確認し、出席者の推測で了承したことにしません。
会議の結論をライターや取材先へ渡す際は、記事制作の依頼書へ目的・範囲・確認事項を移します。議事録を渡しただけで、依頼する作業まで伝わったと判断しないようにします。
保留した企画には、不足している情報と再検討の条件を残す
材料が足りない企画は、不足している情報・確認する担当者・期限・再検討する条件を記録して保留します。 会議中に仮の答えを埋めるより、次に何を確かめるかを具体化します。
先ほどの検査装置の記事なら、「企画はよさそう」で終えず、たとえば次のように残します。
架空の記録例： 運用条件が分からないため保留。編集担当Aが開発担当へ、対象工程と公開できる仕様資料を11月6日までに確認する。資料がそろえば、対応できる範囲を軸に構成案を再検討する。導入効果は未確認なので、効果を断定する見出しは採用しない。
一方、媒体の対象読者から外れる、既存記事と同じ問いに同じ材料で答える、と判断した案は、見送る理由を残します。保留と見送りが同じ欄に積み上がると、もう一度調べる案と、調べても今回の方針では採用しない案を区別しにくくなります。
会議後は、決定と次の行動を制作予定へ反映する
会議後には決めた内容と担当・期限を同じ記録にまとめ、制作予定へ反映します。GitLabの同ハンドブックも会議後に記録から行動項目を拾い、継続する会議では未完了・完了の状態を追う運用を示しています。1 以下の記録項目はその考え方も参考にした編集部の提案です。
対象の企画・記事ID：
今回決めたこと：
判断した理由・参照した資料：
まだ確かめていないこと：
次に行う作業：
担当者・期限：
保留の場合の再検討条件：
結論を伝える相手・記録の置き場：
採用した企画はコンテンツカレンダーへつなぎます。会議での着手判断と、取材・執筆後の公開判断は別です。企画が採用されても、原稿の事実や画像の権利が未確認なら、公開できる状態にはなっていません。
一人で運営する場合も、この記録を自分のために残せます。すべての判断に会議を設定する必要はなく、資料を読んで決められることは文書で進め、意見の違いや条件をすり合わせる必要があるときに話す場を設けます。会議の頻度は、そのような判断がどれだけ生じるかと、制作の進み方から見直します。
次回は新しい案を並べる前に、前回決めた確認が終わったかを読み直します。企画が増えたかに加え、誰が何を進められるようになったかを確かめると、会議の進め方も見直せます。
参考資料
2026年11月2日に確認。遠隔勤務の会議運営と行政コンテンツの指針を参考に、企業メディアの企画会議へ応用した提案です。特定企業の会議の成果や、最適な人数・時間を実証した記事ではありません。
- GitLab Handbook：All-Remote Meetings — 会議の必要性、事前のアジェンダ、会議後の行動項目。
- GOV.UK content and publishing guidance：Identify user needs — 利用者・行いたいこと・理由と、必要性を支える証拠。
