※当サイトはアフィリエイトプログラムによる収益を得ています。

大きな原稿は、ウサギ方式かカメ方式か


unsplash-logoKolleen Gladden

倉下忠憲執筆の進め方、特に大きな原稿の進め方には、大きく二つのタイプがあるのではないでしょうか。

一つは、「Rough&Go」。もう一つが「ACS(Almost Complete Step)」です。言い換えれば、前者は五月雨ウサギ方式、後者はじっくり亀方式です。

Rough&Go

「Rough&Go」は、ようするに「書けるところから書いていく」方式です。

たとえば、第一章に掲載したい項目が10個あるとして、そのうち書けるものが5つなら、まずその5つだけを書いてしまう。しかも、それすらも不完全でよしとする。書ける分だけを書き、書けないところはスルーして、ずんずんと前に進んでいく。

他の章に関しても同じです。とりあえず書けそうな部分だけを書いて、文字を埋めていきます。そうして手を止めることなく、書けるだけのものを書ききってから、その後に追記したり、修正したりといった作業を加えることで完成品へと近づけていく方式です。

ACS(Almost Complete Step)

ACSは、それとはまったく逆になります。頭から書き出して、一つひとつを「ほぼ完成」まで仕上げてから次の行なり段落へと進んでいく方式です。

もちろん、文章というのはいったん書き上げてから推敲するのは当然の工程なので、そこでいう完成は仮のものでしかありません。

それでも、後から大手術が必要な箇所は残さないように、言い換えれば、一通り読める文章として仕上げながら進めていくのがACSです。

方式の比較

二つの方式を比べると、いくつかの違いが見てとれます。

まず初期段階の進捗に関しては、圧倒的にRough&Goが有利です。何せ手を止めないように進めていくのですから、どんどん原稿が進むのは当然のことです。

対して、ACSは一カ所でもぶつかる壁が出てくると、著しく進捗は停滞します。まったく一行も進まない、ということすら珍しくありません。

また、Rough&Goであれば、早い段階で全体の概要が見えてきます。文章というのは書き出してみないとわからないことが結構あるわけですが、とりあえず書き出してみることで早期にその「わからないこと」をあぶり出せます。

対してACSでは、書き始めた直後は、どれだけ「わからないこと」があるのかすらわかりません。闇は深いものです。

見えないデメリット

以上の比較を参照すると、Rough&Goの方が優れているように感じますが、そんなに単純な話でもありません。

Rough&Goでは、中盤以降の進捗に問題が発生します。最初に「書けるだけのところ」は書いてしまっているので、残っているのは「なかなか書けないところ」です。しかもそれが山のように残っています。

お弁当で好きなおかずだけ食べてしまって、残りは嫌いな野菜だけ、みたいな状況に近しいでしょうか。お弁当なら残せば済みますが、原稿の場合そうはいきません。

ここでは二つの認知的な問題が生じます。まず、「なかなか書けないところ」ばかりが残っているので、執筆作業に取りかかる意欲が湧きにくいこと。次に、仮に取りかかったとしても、どこから手をつけていいのか決められないことです。ここに自由制度の危うさがあります。

「あれと、これと、それをやらなければいけない。でも、どれもあまりとりかかりたくない。さて、どれからやろう」について答えを出すのは簡単ではありません。問題の難しさというよりも、認知的困難さが伴います。

ACSの場合、引っかかる問題は常に一つです。何について考えればいいのかは、文章の最前線にはっきり示されています。よって、いやおうなしにその問題に直面します。しかし、自由に進めていくやり方の場合は、「どの問題について考えるのかを選ぶ」こと自体が問題となってしまい、なかなか原稿の問題に取りかかれないことが起こりえるのです。

いろいろ書き散らかしたけど、それをなかなかまとめられない、という人はこの手の状況に陥っている可能性が大きいと言えるでしょう。

ハイブリッド

ACSは、ゆっくり進むロードローラーのようなものです。進捗はじんわりとしか出てこない。でも、生まれた進捗についてはもはや思い悩むことはない。また、遙か先のことも考えくてもいい。とりあえず、目の前の文章にだけ集中できる。そういう特徴があります。

対するRough&Goは、早期に原稿(文字数)が生まれ、書かなければわからなかったことが見えてくる反面、頭の中のタスクリストは項目で膨れあがります。そこから迷いが生じ、進捗の手が止まってしまうこともあるでしょう。

よって、それぞれに長所・短所があると言えます。そこでハイブリッド方式を考えてみましょう。

まず、「頭の章から書き始める」と決めます。その章でも頭の項目から書き出していきます。その際、書けない部分については何かしらのマーキングを残しておいて、書ける分だけで先に進みます。そうして第一章のラフ原稿を書き上げます。

それを繰り返して、最後の章まで進めていきます。

それが終われば、次に修正・追加の工程に入ります。ここでも、「頭の章から直し始める」と決めます。章内でも頭の項目から書き直していきます。もし、そこでも書き直し切れないならば、マーキングを上書きして(たとえば最初が★ならば、次は★★など)、先に進みます。あとはそれを最後の章まで繰り返していくだけです。

これが終われば、次に「再修正・追加の工程」に入ります。手順はまったく同じです。再帰的に繰り返します。

このやり方をしていると、自分が今取りかかる問題(≒今解決すべき文章上の課題)が一つに定まります。上のやり方なら、★の数が一番少ない先頭の項目がそれです。

それについて考えて、文章が「ほぼ完成」したら★を消し、ダメなら★を増やして次に進む。そうやって、できるところから解決していきながらも、問題の選択肢が拡大してしまうのを防ぐわけです。

もし、大きな原稿の進め方に悩んでいる方がいらっしゃるなら、参考にしてみてください。「限定化」が一つの鍵です。

▼今週の一冊:

少し前の本ですが、いまさらながらに手にとってみました。いかにして良き進捗を素早く生むのか。プログラマに限らず、文章書きでも必要なノウハウですね。もちろん、そのまま通用するとは限りませんが。


▼編集後記:
倉下忠憲



私はよく上のようなことを考えています。それはなぜかというと、まさに「まったく原稿が進まない、手がつけられない」状況が起こるからです。つまり、実際的な問題なんですね。


▼倉下忠憲:
新しい時代に向けて「知的生産」を見つめ直す。R-style主宰。