【クライアントとの相違】記事想定の違いの事例と対応

Webライターの仕事は、同じような題材、同じようなキーワードでもクライアント毎に記事の想定が異なります。

先日依頼があった仕事に「サイト構築」についての記事作成がありました。

類似記事・類似キーワードが多数あり、記事を作成する中で、記事の想定が自分とクライアントでは異なる内容であり、すり合わせを何度もおこない大変でした。

記事想定について、自分とクライアント（記事の依頼主）の相違がある場合どうするべきなのか、また記事作成でクライアントの意図を正しく反映させるにはどうしたらよいのか、参考にしてみてください。

依頼内容

この仕事は、サイト構築について複合キーワードを指定され、それについて構成案作成、提出後に記事本文を作成する、というものでした。

また掲載サイトが指定され、そのサイトを確認しすでに掲載されている他の記事から文章表現などを確認し、記事に反映させるよう指示がありました。

「サイト構築」という題材で、どのような情報が必要であるかは、自分もブログを運営しているため、自分の経験から記事を作成できます。

また、読者想定についても「コーポレートサイトを作成する企業の担当者」とありましたが、自分のように個人でサイト運営する方にも分かるように記事を作成しようと思いました。

作成する記事のキーワード自体は複数あり、自分以外にもこの案件に契約した方がいたので、自分に割り当てられた2記事分のキーワードを指定され、修正を含め納期は1週間でした。

この仕事では、自分に割り当てられたキーワードを基に、他の契約者に対して依頼している記事のキーワードや、すでにサイトに掲載されている記事のキーワードと内容が重複しないように記事を作成すること、これが今回1番大変だったことです。

「AWS ランキング」「クラウド 評判」の2件記事を作成しましたが、他の記事では「AWS メリット デメリット」などAWSについて詳しく解説する記事もあったため、内容が重複しないようにするには細かいリサーチと内容の絞りだしが必要でした。

AWSとは「Amazon Web service」の略で、2006年からAmazonがサービスを開始したクラウドサービスのことです。

構成案作成

AWSやクラウドのようなキーワードは、自分以外の契約者が担当する記事にもあり、内容が重複していまう可能性があるため、その中で自分の記事の内容を細かく決めなければなりません。

クライアントから掲示されたキーワードは「AWS ランキング」のように複合キーワードであり、AWSに対してランキングで補足する、といった感じでした。

しかし、自分以外の契約者が担当している記事に対しての複合キーワードも開示されており、その中でクラウドやAWSについての複合キーワードが8個ありました。

そもそもこのクライアントからの依頼に、記事の掲載サイトが指定されており、そのサイトの読者想定は「コーポレートサイトを作成する企業の担当者」とされています。

サイト作成のために記事を読んでいるわけですから、サイト作成のために必要な情報を集めるために、1つの記事だけに限らず必要に応じて他の記事も確認するでしょう。

そのため、自分が担当するキーワードと開示されたキーワード、すでに掲載サイトに記載されている記事が関連する内容でなければならないと仮定できます。

つまり「AWS ランキング」の記事を読んだ読者が、ランキングからAWSについての有用性を知り、AWSに対してもっと深く知るためにサイト内の他の記事を読む、といった感じになるのが理想です。

となると重複は避けつつ、関連のある内容にしなければならないため、開示されたキーワード全てに対してどのような記事になるのか想定しておく必要があります。

例えば「AWS Webサイト」というキーワードがありました。

これはAWSを利用してWebサイトを作成する際の利点などを解説する記事、あるいはやり方などを解説する記事になるのではないかと仮定できます。

このようにある程度の記事想定を8記事分、1記事で約5分程度かかったため合計40分の時間がかかりました。

記事想定だけであればすぐできますが、8記事分の記事想定と重複を避けるため、見出し作成のために細かいリサーチが必要であり、2記事分のリサーチにまた40分程かかりました。

以上の内容を踏まえ全体の構成案を作成したところ、普段なら2記事分の構成案の作成には1時間程度で終わるところ、2時間程度かかりました。

クライアントとのすり合わせ

キーワードから、タイトル・検索意図・見出しの構成案を作成し、クライアントに提出したところ、自分が想定していた内容が、クライアントの記事想定と異なり、かなり修正がありました。

「AWS ランキング」の記事は問題ありませんでしたが「クラウド 評判」の記事はほとんど修正しました。

というのも、自分の中では「クラウドの評判から見た有用性」といった内容を想定して構成案を作成しましたが、クライアントとしては「評判をまとめること」に焦点をあててほしいということだったのです。

また修正依頼と同時に掲載サイトにある記事の複合キーワードが約20個送られてきました。

その中に「クラウド メリット」「クラウド 運用」のようにクラウドの有用性に対して書いてありそうなキーワードもあり、その内容と重複しないようにと指示がありました。

構成案作成前に、ある程度掲載サイトを確認していましたが、タイトルや見出しを確認する程度であったため、クライアントとしては内容が重複していると捉えられたのだと思います。

これは自分の確認不足であり、自分でも改めて掲載サイトの記事を確認すると重複するような内容の記事があったため、自分の記事を見直しました。

しかし評判をまとめると言っても、悪い評価の内容をいれてしまうと、読者はそれ以上の情報を必要としなくなる可能性があるため、なるべく良い評判をまとめる必要があると考えました。

そうなると必然的に「クラウド メリット」の内容と重複してしまう、どうしたものかと悩みました。

とりあえず自分では「良い評判をまとめ、評価されている点についての総評を入れる記事」を仮定し、クライアントに再度提出してみました。

その回答は、評判をまとめるのはそのまま、総評はいらず、メリットやデメリットについては読者の判断に委ねるような記事にできないかと注文がありました。

つまり、私個人の意見はいらず、クラウド利用者の声から良い評判だけを集め、その評価については読者の読み取り方次第、という記事になります。

良い評判をまとめると、メリットについてどうしても重複してしまうのではないかとクライアントに相談したところ、「メリット」という言葉は使わず、メリットと捉えるかどうかは読者の読み取り方次第になるような書き方にできないかと注文がありました。

できないかと言われたらやるしかありませんよ。

完成した構成案では、各見出しで「価格についての声」「サービスについての声」のように内容ごとに口コミを集めて、見出しの最後に口コミからどのような評価がされているのか要約を書く、といった感じになりました。

見出しの最後に「メリット」とは書かずに要約を入れることで、内容としてはメリットや利点のような事ではありますが、その判断は読者ができるようにしました。

しかし改めて記事を書いてみて、メリットデメリットについてまとめた記事がすでに掲載されているにもかかわらず、メリットと読み取れるような評判記事を掲載する必要があるのか、なんて思いました。

これはあくまで個人的な感想なのでクライアントには言えませんが。

改めて今回のことで、リサーチだけでなく、クライアントから記事の掲載サイトの開示があったため、記事の差別化について改めて考えました。

参考サイトのみならず、掲載サイトの開示があった場合はそのサイトをしっかり確認することで、重複を避け、記事と記事の関連を考えて記事を作成することを学びました。

また自分が作成する記事以外で、関連する記事の想定を考えることで自分の記事でもまた別の視点で記事想定ができることも学びました。

記事作成

「AWS ランキング」の記事は、まずクラウドシェア率について、次にAWSが選ばれる理由を書いていく、といった感じの記事になりました。

AWS自体はあまり詳しく知らなかったため、リサーチをおこない記事を作成しました。

調べてみると、AWSが毎年シェア率首位であり常に独走状態、2位との差も約2倍！

価格もサービスも他クラウドと比べかなり高く評価されており、なにより始めてできたクラウドサービスであったため信頼度が段違いでした。

この「AWS ランキング」についての記事はリサーチも早く終わったため、記事作成も早く終わり、3000文字で3時間くらいでした。

問題は「クラウド 評判」についての記事です。

こちらの記事は、クライアントから指示があった通りに見出しを変更したため、自分が最初に想定していた内容から異なっています。

そのため、まずリサーチのし直しから始めました。

クライアントから参考URLを頂いていましたが内容がAWSの評判であったため、AWSの評判をまとめ、その上でクラウドの評判についてまとめる記事にしました。

クライアントから参考URLを頂くことは、クライアントによって異なりますがよくあることです。

特にこのクライアントは、ライターファーストに考えてくれるクライアントだったため、ライターが記事を書きやすいように事前情報を用意してくれたり、記事に対しての相談もしっかりしてくれたりしました。

しかし実際記事にしてみると、AWSの評判からAWSの有用性についてまとめた記事になってしまいました。

これではクラウド全体の評判、という内容とは異なる記事になってしまいます。

仕方なくクライアントに相談したところ、AWS以外のクラウドサービス2つ分の評判が記載された参考URLが頂けたので、それを基になんとか記事を作成することができました。

参考資料集めも簡単ではありません。キーワードに対してそのままWebで検索するだけでなく、関連した内容で検索して資料集めをおこなう必要もあると改めて感じました。

例えばこの記事ですと「クラウド 評判」以外に「クラウド 口コミ」のように評判と言う言葉の類義語や関連ワードで検索すると、ほしい内容が見つかる場合もあります。

「クラウド 評判」についての記事は、リサーチにかなり時間がかかってしまったため、3000文字で6時間くらいかかってしまいました。

記事作成段階での見出し変更

この仕事では、先に構成案を提出しているためタイトルや見出しは基本的に変更することはできません。

しかし記事作成中に、どうしても見出し名を変更及び見出しを追加する必要があると考えました。

「AWS ランキング」の記事の内容でしたが、選ばれた理由について始めは「価格」という見出しがありました。

本文では価格が低いことについて詳しく書いていたため「価格」から「コストが低い」と見出し名を変更した方が分かりやすいのではないかと思いました。

同様に選ばれた理由を書いていく中で構成案では「価格」「豊富なサービス」の2つの見出しがありましたが、あらためて「多くの国・地域で利用可能」という見出しを追加しました。

これはAWSが多くの国で利用できるためシェア率が高いこと、を説明するためには見出しを追加する必要があったからです。

本来先に構成案を提出している場合、見出しを変更することはありませんが、本文作成中に変更及び追加の必要があると判断した場合、クライアントに変更について相談する必要があります。

ライターの独断で変更し記事を提出してしまう、クライアントとの相違が発生し修正になる場合が多いため、相談後に記事の変更をするようにしましょう。

今回の記事では、変更したほうが記事全体を見て分かりやすくなる、ということで変更が認められました。

まとめ

以上、Webライターの実際の仕事を基にクライアントと相違がある場合の記事作成についてまとめました。

「サイト構築」については、自分にある程度の知識があったため、記事の想定がしやすく、自分でもすぐ記事作成ができると思っていました。

しかし、キーワードだけでは記事を作成しようと思うと、自分とクライアントとの記事想定が異なってしまう場合があります。

クライアントがどのような記事想定をしているのか、自分なりに考えることは大切ですが、わからないことはクライアントに相談することで、相違をなくし修正を減らすことにも繋がります。

些細なことでも、自分だけで考えるのではなく、クライアントに質問し記事を作成するとよいでしょう。