「原稿を書いては消ししている」という状況を解決するには

「原稿を書いては消し書いては消ししていて全然進まない」という話をよく聞きます。

これって「よくない精神状態」にハマり込んでいると思います。

考えてみましょう。人間が脳内で保持できる情報はどれくらいでしょう？原稿に文章Aを書いて、しっくりこないので消して、文章Bを書いた後で、文章Aのことをどれくらい覚えていますか？文章Aを書いている時に何を伝えることが重要だと考えていたか覚えていますか？

「書いて消して」を繰り返している間、時間は消費されていますが、何も蓄積されていません。何も蓄積されないのであれば、問題はやさしくなったりはしません。ずっと同じ難易度のまま、あなたの前に立ちふさがり続けます。

原稿と戦っているうちに視野が狭くなって、自分が「よくない精神状態」にハマり込んでしまっていることを自覚できなくなるのは怖いことです。さらにはTwitterで愚痴ったり、ネットサーフィンをしてこんなサイトに辿り着いたり。それって完全に現実逃避をしていて、作業はまったく進んでいないですよね。

このハマり状態から抜け出すにはどうすればよいでしょうか？

単純なことです。 原稿を消してはいけない 。これが大原則です。

文章Aを書いて、それがいまいち役に立たないクオリティだと思っても、消してはいけません。それは、生まれたばかりの赤ちゃんを「こいつは役に立たないから存在に値しない」と言って、育つ前に殺しているようなものです。今はダメな文章も、良い文章へと育つ可能性を持っています。消してしまうことは、その可能性を摘み取っているのです。

最初から完璧な状態でアウトプットすることはできません。結城浩さんは「文章を書く心がけ」でこう書いています：『自分に「何でも書いていいんだよ」と言い聞かせよう。 校閲作業をしながら書き進めるのはとても難しい。 しょっちゅう、 「それはダメ」 「そんな書き方じゃダメ」 「それは話題が違う」 などと言われながら書けるもんじゃない。』 最初から完璧なものを書こうとして、それで筆が止まってしまうのでは本末転倒です。まずは酷いクオリティのものを書いて、そこから徐々に改善するしかないのです。

何も蓄積せずに、何度もトライしているうちに、運良く「いい文章」が出てくることもあるでしょう。それは運です。超レアカードを引いた記憶にとらわれて、何度も何度もガチャを引くのは合理的な態度ではありません。

プログラミングに例えてみましょう。プログラミングをしようとしている人がいて「この変数の名前はどうするのが正しいか」とか言いながら書いては消し書いては消しをしていたらどう思うでしょうか？「どっちでもいいから一通り書いてみろ」と言いたくなるでしょう。変数名がすんなり決まらないのは、これから書くもののイメージが自分の中で明確になっていないからです。悩んでないでまずは書くのです。書き終わってから眺めれば、変数名の選択が適切でなかったことに気づくかもしれません。気づいたらその時に修正すればよいのです。

実装とリファクタリングは同時にはできないのです。まず実装して、それからリファクタリングです。

「そうは言っても書けないんだから仕方がない」という反論もあるでしょう。少なくとも「書いて消して」をしている人の「書けない」は嘘ですね。書いたものを消しているのと書けないのとは違います。

文章Aを書いて、しっくりこないので消して、文章Bを書いて、やっぱりしっくりこないので消した、という人がここにいたとします。この人は他に何ができたでしょうか？何が彼に足りないのでしょうか？

「しっくりこない」と感じるのがなぜなのか考えましたか？なぜ「しっくりこない」のかを究明することなく、数撃ちゃ当たる的アプローチをしていませんか？「しっくりこない」の貴重な実例を闇に葬っていないですか？

文章Aを消さずにとっておいて、文章Bと比較しましょう。共通点はなにか？共通して書かれていることは、ここで書くことが必要だとあなたが暗黙的に思っていることでしょう。それは正しいのでしょうか？それだけを抜き出して書いたらダメでしょうか？それを置く場所はここでしょうか？他の場所で解説してはダメですか？違いはなにか？AとBの違いは、あなたがAを改善しようとして暗黙的に「変えるべき点」と感じたところでしょう。それはどこでしょう？なぜ変える必要があったのでしょう？本当に変える必要があるのでしょうか？1つの文章に2つのメッセージが入っているのでは？片方を切り出して別の場所に移動できないですか？

「消す」という行為は、こういう思考をするための材料をむざむざ捨てることなのです。

筆者が京都大学のサマーデザインスクールで行った講義の資料がこちらにありますが、これの1日目「大原則: 書いてから考えよう」「断片的情報の構造化」あたりが参考になるかもしれません。つながりが悪いとかを考えずにとにかく書き出して、それから配置を考える、という方法でこの資料自体が作られています。この原則は筆者が「コーディングを支える技術」を書く過程で苦しみながら考えだしたものですが、結果としてこの本はベストセラーになったのでそれなりに有効性があるものと思います。

追記

「完成に至るまで一切消さない」という勘違いをされた方がいるので補足しておきます。文章Aを書いて消して文章Bを書いている状況は「ないことに悩んでいる」であって、「ない」ことが原因なのだから消してはいけないのです。そして消さずに書き続けていると「AでもBでもなく、Cがベストだな」と思う時が来ます。その時にはAやBは消したり、別ファイルに移動したり、脚注に移動したりします。3つを並列で書いたままでは「AやBはCに劣ると判断した」という情報が消えてしまうからです。

AやBを削除するのか脚注に移動するのかは、AやBに対してどの程度価値があると感じるかによって決まります。筆者の場合は原稿をgitで管理していていつの時点の原稿にも遡ることができるので、たとえ削除してもいつでも取り出すことができます。それでも削除しないで移動だけで済ませることもあります。

一通り書き終わって添削する段階では結構バンバン消しています。特にまだるっこしい表現の部分を簡潔な表現に置き換えます。例えば上の段落の「削除するのか脚注に移動するのか」は最初は「削除するのか脚注に移動するだけですませるのか」でした。拙著は書き終わってレビューを聞いた後で1章まるまる削りました。

こちらのコメントについて>私なんかだと、怖くてとてもこんな記事は書けない。「いちおうこうした生活の知恵はありますが、実際のところ、それでもやっぱり原稿が進まないことはありますよ」とか末尾に書き添えないと落ち着かない。

筆者も完璧超人ではないのでやっぱり原稿が進まないことはありますよ。この文章での提案もすべての人の問題を解決する銀の弾丸ではなく、効果には個人差があります。それを書き添えないと落ち着かなくて公開に至ることができないのであれば書き添えればよいと思います。筆者はこういう内容は「著者が完璧超人でないことも提案が銀の弾丸ではないことも自明なことであって書いても情報量が増えない」「著者の恐怖心を緩和するための予防線にすぎない」と思っているので添削で削除することが多いです。