リライトをするときに、
参考になる考え方がある。
大学理系の数学的授業(特に工学の実用設計)では
よく例題にあがるやつだが、世間ではあまり議論されていない。
この考え方を紹介しながら、
リライトがなぜうまくいかないのか、
ということを考えてみよう。
結論でいえば、
部分に目をとられて大きな部分を見失っているから、
ということなのだが。
関数z=f(x,y)を考える。
難しく考えなくていい。入力が二次元、出力が一次元。
イメージするならば、
「とある地図のエリア」の等高線がイメージしやすい。
ある場所(座標)と、高さの関係を表したと思ってよい。
山登りをイメージしよう。
しかし富士山のような単独峯ではなく、
たくさんの山が山脈にそって連なっていたり、
その山脈は枝分かれしているような、
あるいは谷などもある、
複雑な山地を考えよう。
「そこの地図がなく、全体を見渡せないとき、
最も高い山の頂上へたどり着くにはどうすればいいか?」
というのが問題である。
(これは山にたとえているが、
z=f(x,y)の形ならば、どのような問題にも適用できる。
この複雑なパターンは、新幹線の空力設計や、
株の取引の自動化アルゴリズムなどに使われている)
山の高さは、脚本のクオリティーに比例するとしよう。
あなたは現在地がどこか分からず、
自分の周りの坂の傾きは関知できるとする。
そのとき、最も高い山の頂上へたどり着く一般的方法を発明するのが、
この探索問題である。
容易に想像できるように、
上り坂の一番キツイ方向へ都度進めば、
一番高い部分に到達出来そうだ。
これは、目の前の原稿を見て、
良くなるように良くなるように修正していけば、
いつかベストにたどり着くだろうという、
最も原始的な方法である。
しかし、これまた容易に想像できるように、
あなたは小さな山にいて、隣の大きな山、
山脈の向こうのさらに最高峰は、
見えていないかも知れないという危険がある。
目の前の坂の先はその小さな山の頂上に過ぎず、
「これ以上この付近では高いところに登れない」
という意味での頂点ではあるが、
隣の山のほうが高いかも知れず、
あなたはお山の大将を気取っているだけかも知れないわけだ。
どこが悪かったのか。
目の前の坂しか見なかったからだ。
ある程度の範囲を見て、目の前で仮に下り坂だったとしても、
最終的には大きな山の方に近づくのだから、
下りでも我慢する、というアルゴリズムを採用すればよい。
しかし、それは「その範囲をどれくらいにすれば妥当か」
ということについての答えがない。
目の前の坂以外も広く見れるけれど、
その範囲が大して広くなくて、
結局同じ結果になるかも知れないからだ。
地図のエリアの大きさが最初から決まっていれば、
半分の範囲などと定義できれば探索はベストの解にたどり着きそうだが、
我々の創作というのは、
範囲がどれだけのところで闘っているか分からないから、
創作というのである。
(昨今のパワフルなマシンで、
全ての組み合わせを総当たりで調べる、
という力業も、工学ではよく使われる手法だ。
しかし全ての組み合わせは、創作の場合無限だ)
また、見える範囲を広げれば広げるほど、
その範囲を全て把握するにはコスト(時間もコスト)
が級数的に増加する。
さあ困った。
どうすればいいのだろう。
実は、この探索問題にベストの解は見つかっていない。
あらゆる地形のところで、
常に最高峰にたどり着ける効率のいい方法は、
今のところない。
勿論、全探索して踏破する、最も地道なことをする時間もコストもないと設定する。
人生のすべてをやりつくしてから死ぬには、
我々の人生はあまりに短いわけだ。
従って、
新幹線の空力設計やダイヤを組んだり、
交通網やネットワーク整備したりという、
実用上解を出さなければならない問題では、
「次善策でもいいから、解を素早く見つけること」
という方針で設計が進む。
(途中でさらにいい解が見つかったとき、
工事を中止して仕様変更するか、
そのまま工事を完遂して涙を飲むか、
どちらも苦しい道である)
さて。
我々のリライトも、このような問題と、
ほとんど同じではないか、
というのが本題である。
目の前のことだけ直してベストにたどり着いたとしても、
そこはお山の大将に過ぎず、
これをするくらいならば、
最初に全く別のところを直したほうが、
最終的にはもっと大きな山にたどり着けたということが、
「あとあと考えれば」分かることだった、
なんてことは日常茶飯事であろう。
こういうときに僕は、
この山登りを想像する。
工学では、多点探索というアルゴリズムを使ったりする。
一人で探すから簡単にお山にハマるから、
複数(10とか100とか)のプログラムを、
別々の場所からスタートするようにばらまき、
一番高くたどり着いたやつが、次善の答えだという考え方だ。
創作にたとえるなら、コンテストを開くことに相当する。
それぞれはお山の頂点にたどり着くから、
一番高い山のやつが優勝、というわけである。
しかし我々はコンテスト主催者ではなく、
一人の探索者であるから、
この方法は使えない。
(学生に沢山論文を書かせて、
良かったやつに共同執筆者として名を連ねる教授は、
このアルゴリズムを使っているわけだ)
多点探索を改良して、
それぞれのプログラムが横の連携、
すなわち通信できて情報を交換できるようにする、
というやつもある。
群れにしてしまうやり方だ。
しかし通信形式や、やり取りする内容をどう定義すれば低コストになるか、
通信頻度のコストとリターンの関係について、
定式化された解答がなく、
手探り(つまり勘)でそれを設定するしかない。
(熟練した職人は、作業経験の多さによる勘がすぐれていて、
初心者よりも解にたどりつくのが早い傾向がある。
たとえばJRのダイヤ編成は、職人によって支えられていた。
日本がかつて工業立国だったころは、
そのような職人の勘が役に立った。
しかしコストダウンを言いはじめて職人を切り捨てた結果、
現在の凋落である)
我々の創作でいえば、
コンテスト参加者がそれぞれ連絡を取り合って、
最終作品をつくるということにたとえられる。
しかしそれは、
結局間違った小さな山に集結して終わるエンドもありえる。
群れがひとつの意思を持ってしまうと、
それは一人でやるのと一緒で、
「全く別のところを探索している変わり者の勝利」を、
見逃してしまう危険があるわけである。
ということで、
現在の多点探索は、
両者のハイブリッド、
すなわち、連絡を取り合いながら、
連携したり独自の探索をしたりを切り替える、
という方法を取っている。
最初にランダムに、あるいはグリッド状に、
落下傘部隊のようにレンジャー部隊を投下し、
独自に山登りする時間を与えて、定時連絡をとる、
というイメージが分かりやすいかもね。
勿論、これで最高峰にたどり着く保証はない。
「おおむねベストを尽くした」ということは言えそうだが。
我々がリライトをするとき、
いくつかのバージョンをつくって比較してみるのは、
この多点探索を無意識にやっている結果である。
ということは、
そのいくつかのバージョンは、なるべく違うバージョンをつくるべきで、
目糞鼻糞の違いのバージョンをつくることには意味がないわけだ。
あなたがリライトの迷路にはまっているとき、
この山登りのレンジャー部隊を思い出すといいかもしれない。
目の前のことだけ見ていると、
小さな山の頂上で「もうこれ以上直すところなどない」
と悦に入っているだけかもしれない。
それを防ぐには、
違う山があることを知ることだ。
だから、若いうちは、
なるべく多くの山を知ることをお勧めする。
いろんな素晴らしいものを知り、
それがどのようにして作られているかを知ることだ。
現代だけではなく、映画百年の歴史を知ったり、
映画だけでなくあらゆる芸術文化を知ったり、
一般教養として色んな知識や雑学を仕入れることだ。
「それらと比較して、今自分はこの程度の高さにいる」
という勘を、身につけることだね。
大体、ものを知らないやつほど、
自分の作品がたいしたことないのに気づかないし、
それがたいしたことないことを認められない。
世界の、歴史的、最高峰を知っていれば、
そんなに恥ずかしいものを堂々と誇ることが出来ないだろうに。
リライトの基準は、自分ではない。世界だ。
どこの世界に出しても恥ずかしくないものへリライトするべきで、
あなたの小さな基準でどっちの坂を登るか決めてはいけない。
「客観的な見方をする」という言い方があるが、
自分が今客観的だと思っていても、
まったく主観的であることもある。
自分の感覚は、主観と客観を区別しにくい。
だから、「客観的になる」というより、
ぼくは「外をみる」という考え方を推奨する。
もっと外を見ろ。
世の中には、もっと面白いものがたくさん転がっていて、
かつても転がっていた。
それらを見ながら、
どの方向の山を登るべきか方針をきめるとよい。
以前の作品より劣る作品など評価はされない。
以前よりすぐれた作品だけが絶賛される。
(無知で幼稚な観客ならば、自分の体験だけが基準だから、
たいしたことないものでも「凄い」と感じるのだろうが)
結局リライトの基準は、
「自分史上最高」ではなく、
「史上最高」でしかないということだ。
暗闇を探りながら、その山に登ることだ。
ときどき他のレンジャー部隊に連絡を取るのは、
重要なことかもね。
(あ、話を簡単にするため、
z=f(x,y)と、入力を二次元、出力を一次元に限定したが、
一般にm次元とn次元で考えるものであるよ。
また山登りのような連続体としてfを想定したが、
現実にはfは連続微分不可能な、ギャップがあるかも知れない)
2017年03月31日
この記事へのコメント
コメントを書く
この記事へのトラックバック