記事構成案の確認をお願いするときは、依頼元の指定形式に合わせ、各見出しで伝える答えと未確定の箇所を示し、この構成で本文へ進めてよいかを確認します。「方向性はよい」という返信が来ても、修正が必要な見出しまで了承されたとは限りません。
この記事では、架空の記事構成案を使って、提出、部分的な了承、修正版の再提出、本文の開始までを紹介します。初回提出と再提出のメールを使い分け、何の回答を待っているかを構成案の版と一緒に残す進め方です。
確認をお願いする構成案の短い記入例
構成案は、見出しだけでなく、どの読者へ何を答える記事かが分かると、依頼元が内容を判断しやすくなります。以下は、説明用に作った架空記事の提出例です。本文の完成稿や実在媒体の記事ではありません。
H2は、記事の大きな節に使う見出しです。この例は、各節の要点まで添えて確認を受ける形にしています。
依頼元から指定された構成案フォーマットがある場合は、そちらに合わせます。指定のキーワードや参考資料の欄を、上の表にないからといって削る必要はありません。
Writers-hubの構成案の記事でも、見出しのみの提出か、各見出しの内容まで必要かを依頼段階で確認する方法が説明されています。初めての媒体なら、構成作成に入る前に提出範囲を合わせると、確認してほしい粒度のずれを防げます。
相手が判断するのは、見出しの言葉だけではありません。H2-3が毎朝の見直しの話なのか、追加依頼への対応なのかで、本文へ盛り込む答えが変わります。未確定の箇所は隠さず、今回選んでいる案と、迷っている範囲を一緒に見せます。
一方、表記や書式など媒体共通のルールは、記事ごとの内容確認と分けて把握しておきます。複数媒体の指定が混ざる場合は、Webライターの媒体別レギュレーション管理も参考になります。レギュレーションとは、その媒体で守る表記や執筆のルールです。
構成案を初めて送る確認依頼メール
初回のメールでは、構成案の共有先と確認する版を示し、判断してほしい箇所を具体的に伝えます。今回の例なら、H2-3の案も含めて本文へ進めてよいかを、一つの依頼にできます。
件名：記事構成案のご確認のお願い
〇〇様
お世話になっております。〇〇です。
「フリーランスが1週間の予定を立てる方法」の構成案を、以下にまとめました。
［構成案_v1_1110の共有先］
H2-3は毎朝の見直しを扱う案にしております。この内容を含む構成で本文の執筆へ進めてよいか、11月12日までにご確認いただけますでしょうか。
11月13日に執筆を開始し、11月17日に本文をお送りする予定で作成しております。
どうぞよろしくお願いいたします。
この日程は架空例です。構成確認の回答日は11月12日、本文の納品予定日は11月17日として、その間に執筆する時間を置いています。本文を送る日だけを伝えるより、構成への回答がいつ必要なのかが相手にも分かります。
「ご確認ください」だけでは、誤字を見るのか、方向性を判断するのか、本文着手の了承を返すのかが曖昧になります。構成案へ記入した未確定箇所に触れたうえで、「この内容で本文へ進めてよいか」と依頼すると、待っている回答が具体的になります。
送る前に、依頼元が構成案の共有先を開けることも確かめます。閲覧できる資料の版と、メールに記載した版をそろえます。別の記事のリンクや古い構成を送った場合は、どれを確認してもらったかが曖昧になるためです。
方向性だけ承認されたら、未確定の見出しを直して再提出する
返答に修正指示が含まれている場合は、了承された範囲と、修正後に確認が必要な範囲を分けます。「方向性はよい」という一言だけを、全文着手の了承へ広げないようにします。
先の構成案に、次の返信が来たとします。
対象読者とH2-1、H2-2はこのままでお願いします。
H2-3は、毎朝の見直しではなく、追加依頼が来たときの調整へ変更してください。
この時点では、読者とH2-1・H2-2は了承されています。H2-3は修正する方向が決まった段階で、修正した内容はまだ見てもらっていません。構成案_v1_1110に対する回答として、その違いを残します。
H2-3を「追加依頼が来た日の予定を調整する」に変え、その節の要点も変更します。架空の記事例では、「既存案件の締切と追加依頼に必要な作業を確かめ、変更が必要な作業日を決める」という内容へ絞ります。
見出しだけ変えて、要点を毎朝の見直しのまま残さないようにします。
修正方向が具体的なので、「追加依頼の話へ変えればよいでしょうか」という確認をもう一通挟む必要はありません。修正版を作ってから、本文へ進むための確認をまとめます。
〇〇様
ご確認ありがとうございます。
H2-3を「追加依頼が来た日の予定を調整する」に変更し、締切や作業日をどう見直すかに内容を絞りました。
［構成案_v2_1112の共有先］
この修正版で本文の執筆に進めてよいか、ご確認いただけますでしょうか。
どうぞよろしくお願いいたします。
v1は消さず、v2と対応が分かるように残します。メールで修正点を伝えても、ファイルを同じ名前で何度も置き換えると、依頼元が開いた内容を後からたどりにくくなるためです。依頼元の指定する版の管理方法がある場合は、その方法に合わせます。
返事が「方向性はよいです」だけで、修正する場所が分からない場合は、構成を作り直す前に「本文へ進む前に、修正が必要な箇所をご指定いただけますでしょうか」と確認します。相手が求めていない変更を推測して増やさず、未確定の内容を確かめてから直します。
すでに了承された節から先に書いてよいかは、案件の進め方によります。部分着手の合意がある場合は、その範囲で進められますが、この例では修正版全体の返答後に本文を始める予定にしています。
構成の回答日と本文の納品日を分けて調整する
構成の確認が続いている間も、本文納品の予定日は近づきます。返事を待つ時間を、本文を書ける時間として数えないようにします。
同じ例で予定どおり進んだ場合は、次の工程になります。
全体の了承が11月15日へ動いた場合、11月17日までに必要な執筆時間を取れるかを見直します。別案件の予定もあるため、回答が遅れた分だけ後ろへ動かせばよいとも限りません。
元の納品予定を自動的に維持すると約束せず、回答日と残作業を踏まえて相談します。
まだ回答が来ていない段階なら、次のように連絡できます。
修正版のご確認待ちのため、本文にはまだ着手しておりません。
ご回答日を踏まえて納品予定を調整したく、構成案_v2_1112で執筆に進めてよいか、ご確認いただけますでしょうか。
この時点で、相手と合意していない新しい納品日を確定扱いにしないようにします。回答が届いたら、執筆に必要な作業時間と他案件の予定を見て、調整する日程を伝えます。
複数記事の確認日と納品日を並べたい場合は、Webライターが複数案件を管理する方法も参考になります。
構成の回答待ちと本文執筆をTASKUL（タスクル）で管理する
TASKUL（タスクル）では、案件にタスクを追加して、説明と期日を残せます。返答待ちの構成と、すでに書き始めてよい記事を、具体的な作業名で区別するために使えます。
この例なら「構成案v2の回答を確認する」をタスクにします。説明には、了承済みの読者・H2-1・H2-2、修正したH2-3、構成案_v2_1112の共有先を残します。期日には、次に返答状況を確かめる日を設定します。
「構成案v2の回答を確認する」を表示したタスク一覧です。データは架空です。
v2全体の了承を受けたら、「了承された構成案v2で本文を書く」を次のタスクにし、合意した納品日を設定します。了承の範囲は依頼元の返答を人が確かめ、回答の記録も残します。TASKULには、その結果に沿って次に行う作業と期日を置きます。
タスクの状態を選ぶメニューを開いた画面です。データは架空です。
まずは一記事について、TASKULで構成の回答待ちをタスクにするところから始めてください。
まとめ
構成案の確認依頼では、各節の答えと未確定箇所を示し、どの版で本文へ進めるかを確認します。部分的な了承は範囲を残し、修正した内容への返答と本文開始をつなげます。いま確認中の記事で、了承済みと未確定の見出しを分けるところから始めてください。
記事構成案の確認依頼でよくある質問
「修正して、そのまま本文へ進めてください」と言われた場合も再提出しますか？
修正後の再確認を求めず本文へ進むことで合意しているなら、その指示に沿って進められます。指定どおりに直せるかが判断の前提です。修正内容に解釈が分かれる箇所が残る場合は、その点を明確にしてから着手し、本文に使った構成の版を残します。
複数人から別の構成案へコメントが来た場合はどうしますか？
どの版を今回の確認対象にするかを窓口とそろえます。古い版のコメントが現行版でも未対応なのか、すでに変更した箇所なのかを確かめてから反映します。別々の版へのコメントを、すべて現在の構成に対する追加指示として混ぜないようにします。
