Webディレクター心技体 - 原稿整理・校正 (前編)

※この記事は読者によって投稿されたユーザー投稿のため、編集部の見解や意向と異なる場合があります。また、編集部はこの内容について正確性を保証できません。

Webサイト制作のスケジュールで、「原稿整理」や「校正」となっているタスクがあると思う。具体的には、クライアントやライターから受け取った原稿・素材が揃っているかチェックをしたり、原稿内の表記ゆれを統一する作業を行う期間だ。

これらの作業のうち、動的ページの原稿・素材が揃っているかのチェックはどの制作会社でも行うが、静的ページや表記ゆれのチェックには手が回らないことが多い。場合によっては、ほとんど行われない (管理されていない) ことさえある。

誰にでもできる原稿整理は、なぜ中途半端になるのか?

原稿整理は誰にでもできる。プログラムは書かないし、Illustratorでデザインをするわけでもない。この誰にでもできるタスクが中途半端になってしまう理由を考えるためには、プロジェクト中盤以降の各タスクに優先順位を付けていったときのことを思い出してほしい。

スケジュールは遅れ気味で、開発は始まっているのにビジュアルデザインの細かいフィードバックが入っている。プログラムはいくつか潜在的なバグを抱えていて、テストも順調には進んでいない。ToDOの数は増える一方。そのような (ある意味、通常通りの、よくある) 状況で、静的ページの原稿整理や校正は重要なタスクと言えるだろうか?

Webサイトをローンチするという目的において、原稿整理や校正はクリティカルパスではない。そのため、原稿整理を行うはずだった期間でスケジュールの遅延をカバーしたり、コストとスケジュールが折り合わないため、やむを得ず完全原稿を受領する (一文字も直さずそのまま入れる) といった前提条件を見積書に記載して、原稿整理自体を行わない制作会社も多い。

クリティカルパスではないからいつも中途半端でいいのか?

静的ページの原稿や表記ゆれといった細かいところまではチェックしきれないというのは、現実的に仕方のない問題だと言えなくもない。また、優先順位に従ってプロジェクトを遂行していくのは当然のことだ。

しかし、重要なのは、いつもそうなっていないかということだ。一度満足にできなかったことを、次のプロジェクトでも繰り返していい理由はない。コストやスケジュールが変わらない限り、満足にできないと決め付けていないだろうか?

原稿整理には明確な方法論があり、最初の段取り次第でディレクターを楽にもするし、逆に首を絞めることにもなる。前編は、原稿整理で最も重要なスケジュール管理について説明していきたい。

原稿整理は最初の段取りが命

原稿整理に関してクライアントから取っておいた方がいいコンセンサスは、大きく分けて2つある。ひとつは前編で話す「スケジュール」。もうひとつは後編で話す「体裁」だ。これらのコンセンサスは、原稿を書いてからでは遅い。取るのが非常に難しくなる (もう書いてしまった) し、時間もかかる (直している時間がない)。

では、プロジェクトが始まってどのタイミングから原稿整理について考えならければならないのか? それは最初のキックオフミーティングからだ。得意先の気心知れたクライアントでもない限り、キックオフミーティングより前に原稿整理に関するコンセンサスを取っておくことはできないし、この時期が原稿を書き始めている可能性が最も少ない。

多くのディレクターは、原稿整理について考えるタイミングが遅すぎるし、そんなに早くから考えなくていいと思っている。それは大きな間違いだ。クライアントやライターが原稿を書き始める前に、まずは原稿の提出ペースとスケジュールを決めておく必要がある。

総ページ数に関係なく、原稿はできるだけ分割して貰う

制作しているWebサイトが50ページに満たなかったとしても、原稿はまとめて一気に貰うのではなく、できるだけ分割して貰ったほうがいい。校正を行った経験のある人は心当たりがあると思うが、初校原稿には大小問わず様々な問題が潜んでいる。重要なのは、それらの問題にいつ気付くかということだ。

原稿を分割して貰うと、ディレクターが一度に校正する原稿の量を抑えられるし、その都度結果をクライアントに伝えることで、それ以降に届く原稿は校正結果が反映された状態で貰うことができる。

プログラムのバグ (言うなればゴキブリ) と同じで、ある原稿で見つかったひとつの小さな問題は、他の数10ページでも見つかる問題だと思って間違いはない。塵も積もれば山となる。筆者の経験上、原稿の修正・変更量が多ければ多いほど、クライアントと詰まらないタスクの擦り付け合いになる可能性も高くなる。そうしている内にローンチが迫ってくると、他のタスクとの優先順位争いに負けて、この問題から目を逸らすようになる。

原稿管理リストは原稿整理の要

原稿管理リストは、文字通り「原稿 (ページ)」を「管理」するためのシートで、Excelで作られていることが多い。
※制作会社によっては、「コンテンツリスト」「ディレクトリリスト」と呼ばれることもある。

具体的には下記の目的によって作成される。原稿整理だけでなく、あらゆるタスクの指標となる資料であり、プロジェクト中盤以降は、この資料に基づいてディレクションが進んでいく。コストやスケジュールに関わらず、これらの目的に応じた資料は、必ず作らなければならない。

  • Webサイトの総ページ数を正確に測る
  • 各ページの原稿の提出予定日を把握する (例: 第1ブロック 10/10提出分)
  • 各ページの原稿の提出状況を把握する (例: 提出・未提出)
  • 各ページの原稿の執筆状況を把握する (例: 新規追加ページ・既存ページのリライト・既存ページを流用...)
  • 各ページの動的・静的区分を把握する (例: 動的・静的)
  • 各ページの原稿の執筆者・部署を把握する (例: ○○さん・広報部・社長室...)
  • 既存サイトの内容を流用するページと、流用元のURLを紐付け、把握する
  • 各ページにIDを振り、適宜原稿と紐付け、把握する
  • 各ページのtitleを決定・把握する (例: よくある質問 > サイトにログインできない | サイト名)
  • 各ページの格納ディレクトリを決定・把握する (例: /category/sub_category/)
  • 各ページのファイル名を決定・把握する (例: index.html)
  • 各ページのトピックパス・階層構造を決定・把握する (例: ホーム > カテゴリ > サブカテゴリ > リーフ)

原稿管理リストから1日あたりの平均執筆量を逆算し、詳細スケジュールを作成

原稿管理リストができたら、まず始めに原稿執筆タスクを詳細化したスケジュールを作成しよう。
一から執筆しなければいけない原稿、リライトが必要な原稿、流用する原稿がそれぞれ正確に何ページあって、その内、早めに貰わなければいけない動的ページの原稿と、その後に貰う静的ページの原稿がそれぞれ正確に何ページあるのかということは、原稿管理リストができるまで誰にもわからない。

原稿管理リストができる以前に作成したスケジュール (特に原稿執筆タスクの部分) は、新旧サイトの総ページ数に、クライアントとディレクターの感覚値 (このページ数であれば大体何週間ぐらいで終わるか) を加味した、あくまで暫定的なものに過ぎない。この信憑性に欠けるスケジュールを見直さずにこの先も利用し続けると、後で必ず痛い目に遭う。

ほとんどのクライアントは、新しいWebサイトの原稿を執筆するために働いているのではない。日々の通常業務をこなしつつ、空いた時間、もしくは原稿執筆に当てる時間を残業という形で通常業務に上乗せしている (ライターの原稿をチェックする時間も同様)。

重要なのは、クライアントに「後でまとめて一気に頑張ればどうにかなる」と思わせないことなのだ。「どうにかなる」という思いは、原稿を執筆するために必要な時間とページ数の関係を理解していないために起こる。この関係をクライアントに理解させるには、下記の4つの計算が有効だ。

  • クライアントが1日に執筆できる時間 × 人数 (例: 2時間×3人)
  • 一から執筆しなければいけない原稿を執筆するために必要な時間 × ページ数 (例: 3時間×35ページ)
  • リライトが必要な原稿を執筆するために必要な時間 × ページ数 (例: 1.5時間×70ページ)
  • 流用する (予定の) 原稿をチェックするために必要な時間 × ページ数 (例: 0.25時間×207ページ)

最低限、このように1日当たりの平均執筆量を逆算して考えていかないと、現実的なスケジュールを引くことができず、やがては原稿も遅れるだろう。
※AさんとBさんで執筆する原稿量に偏りがあったり、執筆に割けるリソースが大きく異なる場合は、さらに計算が必要。休暇予定も必ずヒアリングしておく。

原稿執筆期間の見積もりが甘いスケジュールでは意味がない

Webサイトのローンチが延びる理由の中でもとくに多いのが「原稿が遅れたのでローンチも延びます」というものだ。この悪習は、最初から各々のリスクを想定した現実的なスケジュールを引いていないことが原因で起こる。

このスケジュールだと原稿はどうせ遅れるだろうし、クライアントを説得できずに機嫌を損なわせるのを恐れるあまり、最初から無理な期限を設定してしまう。そうすると今度は、原稿が期日通りに到着したらまずいので、締め切り直前まで原稿の進捗をクライアントに確認しないようになる (意図的かどうかはここでは問題にしない)。

これではもはや何のために仕事をしているのかわからない。先延ばしにした問題は、後になって倍の大きさで立ちはだかるということを忘れないでほしい。

後編は、効率的でクオリティの高いWeb制作に必要な、原稿の「体裁」という観点から、クライアントやライターに対して具体的にどのようなコンセンサスをとっていけばいいのか考えていきたい。

この記事の筆者

渡邉 雄介
Webユーザビリティコンサルタント・Webディレクター

ラインズ (現NGIグループ)・キノトロープで、大小様々なWebサイトのコンサルティング・ディレクションに関わる。
ユーザー・クライアント・制作者、関わる人全てが幸せになるWebサイトのビジョンと、それを実現するための制作体制とは何かを日々考えています。

URL: http://yusuke-watana.be/
メールアドレス: contact@yusuke-watana.be

この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

インデックス
検索エンジンがWebページをデータベースに保存しているデータベース。データベース ...→用語集へ

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]