自己顕示欲の開放治療所

erg, programming and something.

別名:Laughing and Grief 雑記

Latin and Greekは習ったこともない

真面目な記事の他、特定の方には不快と思われる事柄に関して言及を行うことがあります。ちょっと頑張りますが、Blog内で解決できなかった場合要望があれば別ページに技術記事は書き直します

技術系ラノベについて益体もなく考えていること

この記事はWORDIAN ADVENT CALENDAR 2022の24日目の記事です。

adventar.org

最早クリスマスイブの夜の過ごし方について自虐する年でもなくなった。お気に入りの蜂蜜酒メーカの蜂蜜酒を4種類ほど飲みながら書いている。

ホーム - WICKED WAY MEAD

今年のアドベントカレンダーではカクヨム小説投稿をしている。4日分埋めているタイミングでこの記事を書いている想定だった。しかし上手くいっていないのもそれはそれで想定通りでもある。

先ず、技術系ラノベとは何か。本記事では「技術紹介を軸とした創作小説」を技術系ラノベと称している。別にゴリゴリに技術解説をしている必要は無い。私に、「学習目的や興味を惹くにあたり、リファレンスやガイドが適さないケースで合致する存在が欲しい」という欲求が存在し、類似したコンセプトであろう創作について徒然なるなんちゃらを書くというだけの話である。主観がかなり混じるし評価について公正とは言えないので、ネガティブな評価の作品についてはタイトルの言及などは避ける。

自分の書いているものについて。これは出した後に無限に修正して完成しないところまで含めて心理的な安心感の源であり、仮にキッチリした内容になるまで表に出さない腹積もりであればあと3年は寝かせている。

この箇所のサマリは次であるので、暫く読み飛ばしても構わない。

  • 技術的に誠実であることを制作段階で意識しすぎると
    • 執筆中に資料に当たる頻度が高く一息に書きづらい
    • 会話の流れが組み立てづらい
    • 使用する思考領域が業務と被って疲弊をひきずる

アドカレ開始前に3日分くらいはストックを作ったが、およそ17日で破綻した。これは唯々文章が下手という要素以外に、技術系の内容を指向しているということも無関係とは言えないといってもいいんじゃないだろうか。 つまり技術的に明確に虚偽であることは書かないようにする、誤りがあれば修正していくことを企図しておくことが期待される。

実際、書いている最中に「あれ、これは嘘では?」と思い資料を読みにいって時間を消費するといったことがあった。最初から使う内容について精査し取材し整理しておくということが職業作家のスキルとして大事だろうことは容易に想像できる。作家じゃなくてもライティング・オーサリング・エディットをするなら行って然るべきではあるとは思うが。今回の場合、プロットとメモを用意していても自分の書いた文章への羞恥でまるで読もうとしなかった。自分の文章を直ぐに読むことができるというのは才能であると、つくづく思う。

会話劇を中心にすることにして書いている。後でまた言及するが、これは、創作の色を強めるのであれば「会話の流れ」を綺麗に繋ぎつつ望む方向に誘導することができなければ、「やたら理解の早く体系立った推論を行える初学者」などが誕生し、読者の没入を阻害することは明白であるからリスキーである。実際私も早々に破綻した。

この場合の望む方向とは技術内容についてであるが、実際の技術教導で一言ごとに「なるほど」とか言われたら結構ストレスを感じそうだ。

私は文章を書くとき思考能力が著しく下がる傾向がある。対話的な会話よりはマシであるが。それはさておき、技術的内容を含んだコミュニケーションというのは、平日の業務領域と重なるものである。無論、業務中に執筆などできないので終業後の時間を充てるわけだが、既に業務によって疲弊した領域を鞭打って作業させるのは疲れるのだと実感した。勿論、別に業務と一切関係無いファンタジー創作なら楽勝だったとかいう話ではない。ただ、書くという作業にリフレッシュ効果があまりに無かった。


とまあ個人的話は置いておいて、それを行うに至ったバックボーンが本題である。「お前もできてないじゃないか」というのはまあそれはそう。「やっぱり難しいね」というのが結論なので。

同人誌イベントや商業作品で技術ラノベの方向性を持つ作品は時折チェックしているのだが、多くの場合、こんな風に感じている。ここでは本題前の寸劇マンガが入るもの、会話ボックス(キャラクタのバストアップ画像とセリフをセットに表示するものとする)を含む。

この点、上手くいっていると思うのは『こうしす!』シリーズだ。インジェクションの例示に小説文章を使ったりといった、初学者が想像しやすい置き換えや、インシデントと対応の流れと結果のフィクションの混ぜ具合などが良くできていると思う。

  • 説明的に過ぎて創作としてのシュガーコートが無意味
  • 情報の密度がバラバラ

前者について。セキュリティに纏わるものであれば、起きる障害が典型的で、対処についてもそう。話が進む中でキャラクタの個性が消失していく。話・キャラクタの個性を出すために技術的な誠実さを削るのは本意ではいので、バランスを取るのは難しい。技術的説明をそのままストーリーに導入してしまうと登場人物の個性をないがしろにしかねない。それを行うのが自然なキャラクタ像というのもあるが、新入社員、新入生などのキャラクタをある技術解説のストーリーの中で成長させるのは鉄板だが、「学習した内容を体系的知識として昇華する」までを描写するなどというのは困難である。困難であると思う。でなければ「やたら理解の早く体系立った推論を行える初学者」が頻繁に登場する尤もらしい他の仮説が欲しい。

後者について。技術的内容は密度が濃いという想定を置いている。情報の密度というのは、テキストである方が濃いと決められるものでもないが、薄くなりがちなものもある。「マンガ・会話ボックスで行われるただの会話」だ。会話ボックスについていえば「ただの相槌」はかなり薄いと思っている。フローの中で急に会話ボックスを止めるというのも難しいが、「へぇー」を言わせるために顔画像とセリフの枠線で3行持っていかれたりするのは辛い。適材適所で

先日買った『ちょうぜつソフトウェア設計入門』(田中ひさてる, 技術評論社)のマンガ部分はアイキャッチと導入部分として丁度良い密度になっていると感じた。

また、ストーリー展開が面白すぎて技術解説に割いている箇所が頭に入らないというケースもあり得る。技術系というほどでもないが、中学時代、和訳がセットになっている英語の本で勉強しようとしたとき、続きが気になりすぎて途中から英語を読むのを止めて和訳の箇所のみを読みきり満足して辞めてしまった、ということがあった。理解に時間を要する箇所という点では技術ラノベの技術部分というのは同じ問題を孕む。技術部分の情報密度が高すぎる状態、ともいえるだろう。ラノベ部分の密度が薄いというより、この場合ストーリーによるフローが良すぎると捉えてほしい。 この密度を下げるのは、技術力文章力ともにかなり力量の要る作業であることは想像に難くない。となるとストーリーの進みをゆったりとする方向が考えられる。この点でシノギを削っている最前線はソシャゲのシナリオ部分ではなかろうか。

とりあえず、年末年始で25日分までは書こう。