問題の切り分けをする

エンジニアの常識は、たぶん他の業界の人は知らないことだと思う。

シナリオは工学という説もある。
エンジニアの手法が、使えるときもある。


問題の切り分けとは、
ある問題があったときに、
何が原因なのかを知るために、
色んな間違い現象を起こして、
どこが問題かを探っていくことである。

キーボードでたとえると、
「キーを押しても入力出来ない」という問題があったときに、
キースイッチが故障しているのか、
回路が断線しているのか、
キーボード内のマイコンがおかしいのか、
USBケーブルが断線しているのか、
PC内の認識がおかしいのか、
ひとつひとつ検証していくことである。

このときに、「特定のキーだけが入力できない」のか、
「列だけが入力できない」のか、
「ある条件下で、特定のキーだけが入力できない」のかで、
原因の特定が速くなることがある。

そして故障個所さえ特定できれば、
電気回路は再び動くようになるものだ。
これはプログラミングのバグ取りでも同じで、
ひとつひとつ条件を変えて実験して、
問題の箇所のエリアを狭めていく手法である。

文系の人は「故障した」しか言わないから、
問題の切り分けが難しく、
修理に手間がかかることが多い。
壊したことで怒られると思っているのかもしれない。
エンジニアは怒らない。故障しているのは事実だから、
それのどこが問題かを知りたい。

だから、情報が少ないほうが機嫌が悪くなる。
問題の切り分けからテストしていかないといけないからだ。
そうではなく、
「ここをこうしたときにこのようにおかしい」などの、
すでに切り分けられた症状があれば、
問題の特定は早くすむ。

これは医者でも同じで、
「なんだか怠い」だけでは分らないから、
熱があるとか咳の有無とか、最近何かへんなものを食べたとか、
そういうことを問診するわけだ。
これは問題の切り分けをしているわけだ。

これは、
「回路はパーツからなり、おかしな箇所があるならば、
そのパーツに問題がある。
それを正しくすれば問題は解決する」
というモデルに基づいている。

電気回路も、電化製品も、プログラムも、
人体の仕組みも、
そのようにできている複雑系である。

そのパーツを正しくしても問題が解決しないモデルもあると思う。
芸術はその傾向があるように思える。
それは「もともと正しい姿がわかっていない」ということと関係あると思う。
電気回路やプログラム、人体は、
「正しい完成形がわかっている」状態だ。
（人体はすべて分っていないが、分っている部分に関しては分っている）

だけどある程度の法則性は分っていて、
それが三幕構成であるとか、
キャラクターの造形とか、
伏線の管理とか、
行動と動機とか、
主人公とメアリースーとかのことだ。

いわゆる脚本論は、
こうした「正しいパーツの正しい機能」についての説明書だと思うと分りやすくなる。
それらが機能する限り、
ストーリーは機能するだろう、というモデルのことである。


いまシナリオに問題を感じているならば、
どういう症状があるのか、
問診してみよう。
そして問題を切り分けるのだ。

ここに問題があると仮定する。
そうしたらこういう不具合も出るはずだが、
どうか。
書き直してみてそうなりそうなら、
その仮定はあっているということだ。
エンジニアもわざと故障を再現して、仮定の正しさを検証することがよくある。

問題のあるシナリオを、
ああでもないこうでもない、こうしたらどうか、
という素人のアドバイスがあまり機能しないのは、
こうした問題の切り分けが出来ていないことが多いからだ。


まず問題がどこにあり、
どのように機能すれば問題は解消するのか、
診断を正しくできないと修理はできない。

キーが正しく入力されないのは、
キーキャップがうまくはまっていないからなのか、
キースイッチの金属リーフが曲がっているからなのか、
基盤の銅線が切れているからなのか、
ダイオードがおかしいのでは、
マイコンの半田が取れているからなのか、
ケーブルが断線しているからなのか、
エミュレータの設定が間違っているからなのか、
問題をひとつずつ切り分けていかないと判断できないのだ。
（ちなみに全部体験ずみ）

主人公に感情移入できない、
という症状があるとして、
内面を描いているかとか、
感情移入に至るエピソードに無理があるとか、
ご都合主義であるとか、
メアリースーであるとか、
行動しているかとか、
その動機に妥当性があるかとか、
そうしたことをひとつずつ切り分けていかないと、
真の原因は特定できないものである。

それで、たとえばメアリースーのせいだと分ったら、
すべての態度を改めないとむずかしくて、
一から再構築したほうが早い、
ということだってあり得るだろうね。

シナリオドクターという職業が成立するのは、
シナリオが人体や回路に似ている構造モデルをしていて、
エンジニアや医者の「問題の切り分け」技術が通用するからだと思う。

問題の特定さえできれば、手術をすればよい。
手術の腕、つまり筆が立つかは、医者次第だともいえるが、
診断そのものが間違うことはほぼない。
それくらい、問題の切り分けというのは客観性がある。


ただ問題があるからなんとかしたい、
というだけではダメだ。
「〇〇に問題があるのではないか」という仮説に基づいて、
それをこう変更したが、やはり同様の症状になっている、
などの「こうしてみたがだめだった」という情報は、
問題の切り分けに重要な示唆をもたらす。

「原因は〇〇ではない」はドクターの診断を待つべきで、
ひょっとしたら〇〇が△△だったから機能しなかったのかもしれず、
〇〇を××にしたら機能したかもだからだ。

そのように自力診断できるためには、
色んな失敗をして、
色んなリカバリー体験を積むしかないだろう。

日本でシナリオドクターが機能しないのは、
シナリオが分解して再組立て可能な、
工業製品に近いものだという認識が、
プロデューサーの間に広まっていないからかもしれない。

単純に文学的なもので、文学は分解できない、
という理解ではシナリオは理解できない。
また、ドクターが手術したから完璧になった、
という誤解も甚だしくて、
それは機能するだけになったから病院を出られるだけで、
リハビリ、
つまり人の心を動かすようになるまでリライトはつづけたほうがいいと思うがね。

そのように、
機能する／しない、と、
心を動かす／動かさない、は、
分けるべきだと思う。
前者はエンジニア的手法でコントロールできる。
後者は文学的な実力が必要だ。

そして、たいていの脚本論は、
前者を扱っているということに気づこう。



問題を切り分けてみよう。
何が問題か？
〇〇が問題だというならば、
それをどのように書き直せば、機能するものになるのか？
それをやってみたらどうだったか？

それの繰り返しが、
問題と修理にたどり着く、ほとんど唯一の方法だ。

そしてそれが見えていない人は、
シナリオの改良を提案するべきではないと思う。