「著者の心得」の編集履歴（バックアップ）一覧はこちら
「著者の心得」(2009/11/02 (月) 22:15:25) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
&color(red){★★★このドキュメントは編集中です。★★★}
著者としての心構えや、仕事の進め方などについて。
*まずは一通り書き上げよう
ひとつひとつきちんと片付けていきたい、その気持ちは分かる。
でも、文章は全体を通してのバランスが重要。
おそらくその章（節）を完成させたと思っても、次の章（節）では再び前の章を書き足したい、修正したいというのはよくあること。結局、部分的に完成させていくことは、多くの場合は不可能なのである。
＃それは、リファレンス本やTIPS本などのものでさえ、前後のバランスを見るという意味では同じ。
一箇所で立ち止まるべきではない。まずは一通り書き上げてみよう。
書いている間はどんなに苦痛でも、とりあえず全部書き上げてみると、多くの場合はとりあえずはなんとなく形になっているはずだし、全部を書き上げたところで問題も見えてくるはず。
*仮脱稿は本脱稿だと思うべし
＃仮脱稿とは、本脱稿前に監修による原稿確認のためのステップのこと（一般的な用語では、たぶんない…と思う）。WINGSプロジェクトでは、本脱稿で致命的な戻しが発生するのを避けるために、すべての原稿に仮脱稿を設けている。
仮脱稿はとりあえず監修者（編集者（のフィードバックがあるから、ペンディング事項が残っていてもよしというのは言語道断。
原則として、仮脱稿は著者としての本脱稿として提出するべきだ。
ペンディング事項が残っている原稿を査読しても、結局、適切なフィードバックができないため、お互いのやりとりだけが増えてしまうためだ。
＃もちろん、上記はペンディング事項を著者だけで解決するべき、というものではない。ペンディング事項は仮脱稿以前にきちんと関係者と調整、相談しよう（もちろん、その上で実際の原稿を見て判断しようという成り行きはありうる）。
仮脱稿→本脱稿が当たり前なのではなく、仮脱稿で一発通しするつもりで作業する心意気が大切。
そうした意味で、仮脱稿→本脱稿、本脱稿→予備脱稿?と言い換えても良いかも。
*ペンディング事項は明確に伝達する
本脱稿時点で残っているペンディング事項が、原稿内の著者註としてひっそりと書かれている場合があるが、これは原則として不可。
そのひとつ前の仮脱稿原稿の出来具合にもよるが、本脱稿では必ずしも通しで見るとは限らない。
時として、前回問題になっていた箇所だけを確認することもありうるため、その場合には、ペンディング事項が見落とされてしまう原因にもなる。
＃最悪、校正タイミングでは気づくはずだが、それでは遅すぎる。
もしも本脱稿時になおも残っているペンディング事項は（前項でも述べたように、原則として事前にすべてクリアにすべきであるが）、必ず連絡メール本文、もしくは、原稿先頭に目立つように申し送ること。
これは本脱稿の場合だけではない、仮脱稿でも大きなペンディング事項は、漏れが出ないように確実に伝えることを心がけていただきたい。
*フィードバックの内容はその場だけを見てもダメ
査読フィードバックは、あくまで気になった箇所をポイントポイントで指摘しているのみ。
もちろん、全体的な構成についても指摘することはあるが、単に指摘ポイントだけを修正しただけでは、原稿全体としてバランスが悪くなってしまうことはよくある話。
フィードバックの反映にあたっては、必ず原稿全体を見直し、場合によっては説明の順序やシカケの追加／変更を行うことは欠かせない。
*執筆者は監修の下請けではない
時折、自ら「下請け」と名乗ってしまう方がいるのは残念だ。
あくまで執筆者はその記事の文責であり、監修は原則として技術的側面からのチェックを行っているに過ぎない（本来は構成面でもそれほど口出しする立場ではないと考えている）。
そうした意味で、執筆者は構成面、内容面で自分なりの方針を持って作業を進めていただきたい。
もしも監修方針が受け入れられない場合にも、十分に議論を尽くして、納得した上で作業を進めよう。「納得できないけど、下請けなのでとりあえず作業は進めた」は絶対に不可。
*積極的に提案すること
上記に関連するが、執筆者は積極的に編集＆監修に提案を行うこと。
執筆者によっては、これはどのようにしますか、あれは～とWhat、Howの質問を列挙する方がいるが、個人的にはこれは不可であると考える。
一見、丁寧に作業をしているように見えるが、実は自分の意見がないのだ。
まずは自分としてどうしたい、このようにしたい、というのがありき。
「このようにしたいが、OKか否か」という質問がより正しい。
つまり、Yes／Noで回答可能な質問をできるだけ心がけるべきだ。これによって、そもそも自分のやりたい方向に持っていけるという効果もある。
上記の繰り返しであるが、あくまで文責は著者であり、著者の主張がまず先にあるべきなのだ。
＃もちろん、だからといって、自分なりの考えが出せないから質問ができなかった、とりあえず成り行きで作業を先行させた、というのは、それ以前の問題なので絶対不可。どうにも方向性が分からない場合は、What／Howの質問も可能である。
*テーマ／構成案は著者の責任
もちろん、ある程度、構成がかなり固まった状態で執筆依頼が行く場合もあるので、一概には言えないものの…。
基本的に、書籍／記事の構成案は、本文同様、著者の責任だ。構成やお題目が与えられた状態で依頼が来た場合にも、疑問がある場合には、これを明確にし、自分なりに消化した上で執筆作業に着手すべき。
「与えられた舞台（お題目）の範囲で最善を尽くせば良い」は通じない。
＃もう構成やテイストは変えられない、と思っていても、実際に疑問や意見を出してみると、まだまだ変更の余地があった、というのはよくあること。
*構成案もまた成果物
言うまでもないが、原稿そのものだけではなく、構成案や進捗管理表なども出版社に提出するものはすべて成果物である。〆切は原稿同様に管理すべきであるし、内容も厳に精査されたものを提出するべきだ。
時として、原稿さえ提出すれば他の作業や報告はどうでも良い、という作業をしている著者もいるが、これはおかしい。
もしも執筆以外に他の仕事を持っているならば、最終的な納品物を提出していれば、取引先への報告書や上司へのレポートをおざなりにして良いものか、今一度考えてほしい。
*構成案の大きな変化は早めの報告を
書籍や長い連載をやっていると、当初の構成案に変化が出てくることはよくあることだし、また、変化はあってしかるべきだ。
＃構成案に沿ってあとは文字を埋めていくだけ、という作業ほど面白みのないものはない。
しかし、作業途中での変化を構成＆進捗管理表で管理し、リアルタイムに編集者＆監修と共有することは必須。変更はしたが、これを報告せずに、（仮）脱稿段階で「報告はしなかったけど、こんなので作ってます」は絶対に不可。
変更内容がそのまま受け入れられれば良いが、それが却下となった場合、書いている自分も大変であるし、編集者＆監修にも無駄な確認の時間をかけさせることになる。
*締切は厳守！
最低限の心得。
特に複数人が参加しているプロジェクトについては、監修側がまとめて査読できないため、実質的な作業量が膨らんでしまう。是非とも厳守をご協力いただきたい。
もちろん、単独執筆のものでもズルズルと締切が遅れるのは厳禁。
WINGSプロジェクトでは、納期調整は（事前に限って）可能としているが、結局納期調整のメールだけが重なるのは負担であるし、納期調整にばかり頭がいってしまい、成果物（原稿）が二の次になってしまうのは本末転倒である。
基本は納期調整は
「締切前1週間以上前、かつ、1つの締切について1回のみ」
というのを原則にしたい。
＃いや、厳守が大前提で、上記もあくまで「最悪やむを得ない場合は」ということなのだが。
*納期遅れは他にも多大な影響を与えている
締切が遅れることで、編集者、DTP作業者のスケジュールが狂い、結果として、並行して動いている他の作業案件にも影響を与えることを決して忘れないように（刊行時期に、直接影響を及ぼす可能性があるのは当然。特に期末の刊行予算が絡んでいる場合には致命的）。
*連絡は密にとろう
基本中の基本であるが、なかなか難しいらしい。特に締切が迫っている（最悪、超過してしまった）場合には迅速な連絡が欠かせない。
また、なにかしらの理由ですぐに回答ができない場合も、後刻改めて連絡をする旨、伝えるだけでもその後の対応はまったく違う。
特に報告しにくい事項こそ迅速に連絡することを心がけられたい。
もちろん、その際に自分なりの代替案、善後策を提案することは欠かせない。
*スケジュールはなるべく長いスパンでたてる
やや逆説的に思えるかもしれない。短いスパンでマイルストーンを定め、そのスケジュールを確実に消化していくことは重要だ、一般的には。
しかし、書籍や記事の執筆では往々にして予期しないトラブルに見舞われることが多い。
短スパンでのスケジュールを設置しても、なしくずしになる可能性は高い。
そのような場合に、短スパンでスケジュールを立てておいても、スケジュール自体役に立たない、のみならず、自分にとって常にスケジュールに追われているというストレスの原因となるのだ。
そこで、長いスパンでスケジュールを立てておく。
すると、たとえばサンプルコードの作成では時間がかかったが、文章の作成では比較的スムーズに進んだ、というようなケースはよくある。
結果的にスケジュールを遵守できる確率が高くなるし、そもそもスケジュールの間が長いので、比較的、精神的にかかるストレスも少ない。
注意すべき点はもちろんある。
スケジュールのスパンが長ければ長いほど、遅れたときのインパクトは大きい。
長いスパンでスケジュールを立てれば立てるほど、そのスケジュールを遵守する重要性は高くなる。
また、初めての（慣れない）仕事で、長スパンのスケジューリングを行っても、算出した工数自体が当てにならないことが多いので、これまたリスクが大きい。
あくまで最初は短スパンでできるだけ厳密な管理をする（これによるストレスは産みの苦しみと耐え忍ぼう）、これは基本。
でも、いつまでも短スパンのスケジュールで自分を縛り付けておくことはない、そういうことだ。
*スケジュールに遅れた場合には代案を
スケジュール遅れは致し方がないこともある（ただし、連続で遅れる人は除く）。
ただし、その場合にも「では、いついつまでならば出せる」「このように進め、全体スケジュールへの影響を少なくしていきたい」という説明は欠かせない。ただ、「遅れます」という報告では、ほとんど意味がない。
*編集者への相談時には「Yes, No」または三択で応えられる質問を＆自分の提案を必ず添えること
よく「●○についてどうしましょうか」という相談を見かけるが、これは不可。
質問時には、まず著者自身の考えを添えるのが最低限。
そのために、質問は「Yes、No」で応えられるものか、もしくは「1.、2.、3.のいずれにしましょうか」という類のものが好ましい。これによって、相談のポイントは格段に絞り込まれるので、議論が散漫になるのを防げる。
＃「●○についてどうしましょうか」と質問に対して、一から答えたのに「いや、それは私の方でも考えたのですが…、これこれで不可です」などというやりとりは、あまりにも不毛だ。
また、いずれの場合にも、最終的に「私としては1.でいきたい」のような意見を添えるべき。相談に応えるにも、著者がどう考えているのかが分からなければ、そもそも議論が始まらない。
*議論がぶつかったときには？
著者の意見と、編集＆監修の意見がぶつかったときには？これは難しい。
編集＆監修がこう言ったからと言って、自分の意見をすべて曲げる必要はないが、議論を尽くした上でメリット／デメリットが五分五分であれば、編集＆監修意見に従うべきと考える（場合によっては、編集：著者＝3：7であっても）。
多くの場合、編集＆監修は、予算やシリーズの他の書籍との兼ね合いなど、より広い視点で判断している（もっとも、相手があまりに書籍内容とは離れた要素で判断しているように見える場合には要注意だ）。
ここで重要なのは、意味ある議論ができたかという点だと思う。
著者として議論のポイントを絞り込めたか、編集＆監修からの反対意見があった場合にはその意図をくみ取った代替案を提示できたか。
*ひとつの仕事に時間をかけない
程度問題はあるが、多くの場合、原稿の質は執筆にかけた時間の量に反比例するようだ。
もちろん、最低限必要な工数は確実にあるので、実作業時間がそれを下回った場合には、質は低下する。
だが、時間をじっくりかけて書けばよい原稿になるかというと、どうやらそうでもないらしい。
必要以上に時間をかけて書いた原稿は、以下のような問題を抱えることが多い。
-文章がぶつ切れ（接続詞や指示代名詞が多く、流れを感じない）
-表現やキーワード、言い回しに統一感がない（本人も前に書いたことを忘れているようだ）
記事の執筆とは、多くの場合に勢いであることが多い。調査や検証には時間をかけるとしても、執筆はできるだけ短時間集中が基本である。
*納期を守れば良いというものではない
時として、納期順守を優先するあまりに、本来書くべきである内容をカットしたり、後回しにしたりといったケースがあるようだ（特に仮脱稿時）。
しかし、これは本末転倒。納期を守るとは、当然、本来書くべき内容をすべてまとめた上で期日に間に合わせるということ。
もちろん、全体的な記事バランスから内容のカットや整理はあってしかるべきであるが、納期を理由に記事の内容が判断されるのは絶対に不可。
＃結局、カットしたものは本脱稿で対応しなければならなくなり、スケジュール遅れの原因になったり、本脱稿で初見のテキストを確認することになるため、再三の戻しにつながることにもなる。
著者としての心構えや、仕事の進め方などについて。
*まずは一通り書き上げよう
ひとつひとつきちんと片付けていきたい、その気持ちは分かる。
でも、文章は全体を通してのバランスが重要。
おそらくその章（節）を完成させたと思っても、次の章（節）では再び前の章を書き足したい、修正したいというのはよくあること。結局、部分的に完成させていくことは、多くの場合は不可能なのである。
＃それは、リファレンス本やTIPS本などのものでさえ、前後のバランスを見るという意味では同じ。
一箇所で立ち止まるべきではない。まずは一通り書き上げてみよう。
書いている間はどんなに苦痛でも、とりあえず全部書き上げてみると、多くの場合はとりあえずはなんとなく形になっているはずだし、全部を書き上げたところで問題も見えてくるはず。
*仮脱稿は本脱稿だと思うべし
＃仮脱稿とは、本脱稿前に監修による原稿確認のためのステップのこと（一般的な用語では、たぶんない…と思う）。WINGSプロジェクトでは、本脱稿で致命的な戻しが発生するのを避けるために、すべての原稿に仮脱稿を設けている。
仮脱稿はとりあえず監修者（編集者（のフィードバックがあるから、ペンディング事項が残っていてもよしというのは言語道断。
原則として、仮脱稿は著者としての本脱稿として提出するべきだ。
ペンディング事項が残っている原稿を査読しても、結局、適切なフィードバックができないため、お互いのやりとりだけが増えてしまうためだ。
＃もちろん、上記はペンディング事項を著者だけで解決するべき、というものではない。ペンディング事項は仮脱稿以前にきちんと関係者と調整、相談しよう（もちろん、その上で実際の原稿を見て判断しようという成り行きはありうる）。
仮脱稿→本脱稿が当たり前なのではなく、仮脱稿で一発通しするつもりで作業する心意気が大切。
そうした意味で、仮脱稿→本脱稿、本脱稿→予備脱稿?と言い換えても良いかも。
*ペンディング事項は明確に伝達する
本脱稿時点で残っているペンディング事項が、原稿内の著者註としてひっそりと書かれている場合があるが、これは原則として不可。
そのひとつ前の仮脱稿原稿の出来具合にもよるが、本脱稿では必ずしも通しで見るとは限らない。
時として、前回問題になっていた箇所だけを確認することもありうるため、その場合には、ペンディング事項が見落とされてしまう原因にもなる。
＃最悪、校正タイミングでは気づくはずだが、それでは遅すぎる。
もしも本脱稿時になおも残っているペンディング事項は（前項でも述べたように、原則として事前にすべてクリアにすべきであるが）、必ず連絡メール本文、もしくは、原稿先頭に目立つように申し送ること。
これは本脱稿の場合だけではない、仮脱稿でも大きなペンディング事項は、漏れが出ないように確実に伝えることを心がけていただきたい。
*フィードバックの内容はその場だけを見てもダメ
査読フィードバックは、あくまで気になった箇所をポイントポイントで指摘しているのみ。
もちろん、全体的な構成についても指摘することはあるが、単に指摘ポイントだけを修正しただけでは、原稿全体としてバランスが悪くなってしまうことはよくある話。
フィードバックの反映にあたっては、必ず原稿全体を見直し、場合によっては説明の順序やシカケの追加／変更を行うことは欠かせない。
*執筆者は監修の下請けではない
時折、自ら「下請け」と名乗ってしまう方がいるのは残念だ。
あくまで執筆者はその記事の文責であり、監修は原則として技術的側面からのチェックを行っているに過ぎない（本来は構成面でもそれほど口出しする立場ではないと考えている）。
そうした意味で、執筆者は構成面、内容面で自分なりの方針を持って作業を進めていただきたい。
もしも監修方針が受け入れられない場合にも、十分に議論を尽くして、納得した上で作業を進めよう。「納得できないけど、下請けなのでとりあえず作業は進めた」は絶対に不可。
*積極的に提案すること
上記に関連するが、執筆者は積極的に編集＆監修に提案を行うこと。
執筆者によっては、これはどのようにしますか、あれは～とWhat、Howの質問を列挙する方がいるが、個人的にはこれは不可であると考える。
一見、丁寧に作業をしているように見えるが、実は自分の意見がないのだ。
まずは自分としてどうしたい、このようにしたい、というのがありき。
「このようにしたいが、OKか否か」という質問がより正しい。
つまり、Yes／Noで回答可能な質問をできるだけ心がけるべきだ。これによって、そもそも自分のやりたい方向に持っていけるという効果もある。
上記の繰り返しであるが、あくまで文責は著者であり、著者の主張がまず先にあるべきなのだ。
＃もちろん、だからといって、自分なりの考えが出せないから質問ができなかった、とりあえず成り行きで作業を先行させた、というのは、それ以前の問題なので絶対不可。どうにも方向性が分からない場合は、What／Howの質問も可能である。
*テーマ／構成案は著者の責任
もちろん、ある程度、構成がかなり固まった状態で執筆依頼が行く場合もあるので、一概には言えないものの…。
基本的に、書籍／記事の構成案は、本文同様、著者の責任だ。構成やお題目が与えられた状態で依頼が来た場合にも、疑問がある場合には、これを明確にし、自分なりに消化した上で執筆作業に着手すべき。
「与えられた舞台（お題目）の範囲で最善を尽くせば良い」は通じない。
＃もう構成やテイストは変えられない、と思っていても、実際に疑問や意見を出してみると、まだまだ変更の余地があった、というのはよくあること。
*構成案もまた成果物
言うまでもないが、原稿そのものだけではなく、構成案や進捗管理表なども出版社に提出するものはすべて成果物である。〆切は原稿同様に管理すべきであるし、内容も厳に精査されたものを提出するべきだ。
時として、原稿さえ提出すれば他の作業や報告はどうでも良い、という作業をしている著者もいるが、これはおかしい。
もしも執筆以外に他の仕事を持っているならば、最終的な納品物を提出していれば、取引先への報告書や上司へのレポートをおざなりにして良いものか、今一度考えてほしい。
*構成案の大きな変化は早めの報告を
書籍や長い連載をやっていると、当初の構成案に変化が出てくることはよくあることだし、また、変化はあってしかるべきだ。
＃構成案に沿ってあとは文字を埋めていくだけ、という作業ほど面白みのないものはない。
しかし、作業途中での変化を構成＆進捗管理表で管理し、リアルタイムに編集者＆監修と共有することは必須。変更はしたが、これを報告せずに、（仮）脱稿段階で「報告はしなかったけど、こんなので作ってます」は絶対に不可。
変更内容がそのまま受け入れられれば良いが、それが却下となった場合、書いている自分も大変であるし、編集者＆監修にも無駄な確認の時間をかけさせることになる。
*締切は厳守！
最低限の心得。
特に複数人が参加しているプロジェクトについては、監修側がまとめて査読できないため、実質的な作業量が膨らんでしまう。是非とも厳守をご協力いただきたい。
もちろん、単独執筆のものでもズルズルと締切が遅れるのは厳禁。
WINGSプロジェクトでは、納期調整は（事前に限って）可能としているが、結局納期調整のメールだけが重なるのは負担であるし、納期調整にばかり頭がいってしまい、成果物（原稿）が二の次になってしまうのは本末転倒である。
基本は納期調整は
「締切前1週間以上前、かつ、1つの締切について1回のみ」
というのを原則にしたい。
＃いや、厳守が大前提で、上記もあくまで「最悪やむを得ない場合は」ということなのだが。
*納期遅れは他にも多大な影響を与えている
締切が遅れることで、編集者、DTP作業者のスケジュールが狂い、結果として、並行して動いている他の作業案件にも影響を与えることを決して忘れないように（刊行時期に、直接影響を及ぼす可能性があるのは当然。特に期末の刊行予算が絡んでいる場合には致命的）。
*連絡は密にとろう
基本中の基本であるが、なかなか難しいらしい。特に締切が迫っている（最悪、超過してしまった）場合には迅速な連絡が欠かせない。
また、なにかしらの理由ですぐに回答ができない場合も、後刻改めて連絡をする旨、伝えるだけでもその後の対応はまったく違う。
特に報告しにくい事項こそ迅速に連絡することを心がけられたい。
もちろん、その際に自分なりの代替案、善後策を提案することは欠かせない。
*スケジュールはなるべく長いスパンでたてる
やや逆説的に思えるかもしれない。短いスパンでマイルストーンを定め、そのスケジュールを確実に消化していくことは重要だ、一般的には。
しかし、書籍や記事の執筆では往々にして予期しないトラブルに見舞われることが多い。
短スパンでのスケジュールを設置しても、なしくずしになる可能性は高い。
そのような場合に、短スパンでスケジュールを立てておいても、スケジュール自体役に立たない、のみならず、自分にとって常にスケジュールに追われているというストレスの原因となるのだ。
そこで、長いスパンでスケジュールを立てておく。
すると、たとえばサンプルコードの作成では時間がかかったが、文章の作成では比較的スムーズに進んだ、というようなケースはよくある。
結果的にスケジュールを遵守できる確率が高くなるし、そもそもスケジュールの間が長いので、比較的、精神的にかかるストレスも少ない。
注意すべき点はもちろんある。
スケジュールのスパンが長ければ長いほど、遅れたときのインパクトは大きい。
長いスパンでスケジュールを立てれば立てるほど、そのスケジュールを遵守する重要性は高くなる。
また、初めての（慣れない）仕事で、長スパンのスケジューリングを行っても、算出した工数自体が当てにならないことが多いので、これまたリスクが大きい。
あくまで最初は短スパンでできるだけ厳密な管理をする（これによるストレスは産みの苦しみと耐え忍ぼう）、これは基本。
でも、いつまでも短スパンのスケジュールで自分を縛り付けておくことはない、そういうことだ。
*スケジュールに遅れた場合には代案を
スケジュール遅れは致し方がないこともある（ただし、連続で遅れる人は除く）。
ただし、その場合にも「では、いついつまでならば出せる」「このように進め、全体スケジュールへの影響を少なくしていきたい」という説明は欠かせない。ただ、「遅れます」という報告では、ほとんど意味がない。
*編集者への相談時には「Yes, No」または三択で応えられる質問を＆自分の提案を必ず添えること
よく「●○についてどうしましょうか」という相談を見かけるが、これは不可。
質問時には、まず著者自身の考えを添えるのが最低限。
そのために、質問は「Yes、No」で応えられるものか、もしくは「1.、2.、3.のいずれにしましょうか」という類のものが好ましい。これによって、相談のポイントは格段に絞り込まれるので、議論が散漫になるのを防げる。
＃「●○についてどうしましょうか」と質問に対して、一から答えたのに「いや、それは私の方でも考えたのですが…、これこれで不可です」などというやりとりは、あまりにも不毛だ。
また、いずれの場合にも、最終的に「私としては1.でいきたい」のような意見を添えるべき。相談に応えるにも、著者がどう考えているのかが分からなければ、そもそも議論が始まらない。
*議論がぶつかったときには？
著者の意見と、編集＆監修の意見がぶつかったときには？これは難しい。
編集＆監修がこう言ったからと言って、自分の意見をすべて曲げる必要はないが、議論を尽くした上でメリット／デメリットが五分五分であれば、編集＆監修意見に従うべきと考える（場合によっては、編集：著者＝3：7であっても）。
多くの場合、編集＆監修は、予算やシリーズの他の書籍との兼ね合いなど、より広い視点で判断している（もっとも、相手があまりに書籍内容とは離れた要素で判断しているように見える場合には要注意だ）。
ここで重要なのは、意味ある議論ができたかという点だと思う。
著者として議論のポイントを絞り込めたか、編集＆監修からの反対意見があった場合にはその意図をくみ取った代替案を提示できたか。
*ひとつの仕事に時間をかけない
程度問題はあるが、多くの場合、原稿の質は執筆にかけた時間の量に反比例するようだ。
もちろん、最低限必要な工数は確実にあるので、実作業時間がそれを下回った場合には、質は低下する。
だが、時間をじっくりかけて書けばよい原稿になるかというと、どうやらそうでもないらしい。
必要以上に時間をかけて書いた原稿は、以下のような問題を抱えることが多い。
-文章がぶつ切れ（接続詞や指示代名詞が多く、流れを感じない）
-表現やキーワード、言い回しに統一感がない（本人も前に書いたことを忘れているようだ）
記事の執筆とは、多くの場合に勢いであることが多い。調査や検証には時間をかけるとしても、執筆はできるだけ短時間集中が基本である。
*納期を守れば良いというものではない
時として、納期順守を優先するあまりに、本来書くべきである内容をカットしたり、後回しにしたりといったケースがあるようだ（特に仮脱稿時）。
しかし、これは本末転倒。納期を守るとは、当然、本来書くべき内容をすべてまとめた上で期日に間に合わせるということ。
もちろん、全体的な記事バランスから内容のカットや整理はあってしかるべきであるが、納期を理由に記事の内容が判断されるのは絶対に不可。
＃結局、カットしたものは本脱稿で対応しなければならなくなり、スケジュール遅れの原因になったり、本脱稿で初見のテキストを確認することになるため、再三の戻しにつながることにもなる。
