ライターが記事を書く前に、メディアと取り決めておいたほうが絶対に良いこと

ライティングと、ソフトウェア開発はよく似ている。
だから、トラブルの種も、まったく同じ原因だ。

それは、いずれも「成果品が完成してみるまで、その質を判断できない」という点にある。

もちろん、事前に発注側は「こんな記事（ソフト）が欲しい」という要望を出す。
だが、往々にして「すべての要望」を出し切るのは不可能だ。
よって「これはイメージと違う」という話が、どこかで必ず出る。

例えばシステム開発における「使い勝手」などは、その代表例だ。

発注側としては「使いやすいものを」としか言えないのだが、開発側としては「使いやすさ」というのは曖昧過ぎて具現化が難しい。

そこで、開発者は「使いやすい、とは具体的にどのようなことでしょう？」と聞く。
だが、発注側も「使いやすさ」を事前に完全に言語化できるわけではない。

もちろん発注者と開発者は、様々な事例などを持ち出して何とかすり合わせを行うだろう。
しかし、事例はあくまでも事例であり、定義は完全ではない。
したがって、システムが完成してから「イメージと違う」といった話が、必ず発生する。

これは記事でも同様だ。
「メディアとライターの記事のイメージ」は往々にして違うし、「ライターが書きたい記事」と「よく読まれる記事」も違う。

つまり、単純に言えば、メディアとライターの双方にとってイメージ通りの記事を得るためには、品質管理を何かしらの手法で強化せねばならない。

イメージをすり合わせるための「レギュレーション」

そこで登場するのが「要件の文書化」だ。

ソフト開発ではもはや当たり前の作業ではあるが、記事を作る際にも、メディア側と、ライター側のイメージをすり合わせるために、お互いに記事のイメージを文書に落としておく。

我々はこれを「記事レギュレーション」と呼んでいるが、ライター募集から、記事の納品まで一貫してこれが役に立つ。

「面倒じゃない？」と言われることもあるが、のちのトラブル処理のほうがよほど面倒であり、継続して記事を依頼する（あるいは書く）のならば、これ無しでのメディア運営は考えられない。

また、レギュレーションは「作っておしまい」ではない。
メディアとライターのイメージの齟齬が生じるたびに、その部分についてすり合わせ、文書化していく。

そうすればメディア側とライター側の双方にノウハウが蓄積され、品質は継続的に向上していく。

まとめると、「レギュレーション」のメリットは以下の4つになる。

1．文書作成ルールの統一
人によって違う常識を、ルールとして可視化し、誤解を生まないようにする

2．「後だしルール」の禁止
メディアがライターに記事の修正や書き直しを依頼する際に、「こういうつもりだった」といった、後出しルールではお互いが不幸になる。
事前に示したルールによる差し戻しならフェアである。

3．追加料金やペナルティの発生の判定が可能に
レギュレーションに記載されていない要求をされた場合、ライターは追加料金を請求できるようになる。
逆に、レギュレーション通りに仕事を遂行しない場合は、ライターはペナルティを受ける。

4．読者ニーズの明確化
「べからず集」「禁止事項」だけではなく、読者ニーズをレギュレーションに記載すれば、メディアとライターの双方にメリットがある

「レギュレーション」のサンプル

以下は当社が実際に使用している、レギュレーションのサンプルとなる。
これはメディア側がライターに対して示すものだが、ライター側からのチェックリストとしても使うことが可能だ。