見出し画像

【雑記】プログラムとミステリー

私は現在IT会社を経営している。
会社は企業用の業務パッケージソフトを開発して、それを販売している。
もともとはバリバリのプログラマだ。

中学生の時から、数学は大好き。理科も当然物理化学。大学も工学部という絵に描いたような「理系」だ。
当然会社に入ってからも、プログラムを作り続けて、いまに至っている。
いまでもプログラムを作っている。

小説を書くと言ったとき、大学時代の友人たちは「頭でもおかしくなったのか」という顔をした。
よく交わされる言葉が、
「おまえ、国語得意だったっけ?」
実は国語はずっと得意だった。共通一次(いまのセンター試験)でも、現代文なら満点だった(はず)。
「それにしても、プログラムと小説って、関連性がまったくないじゃん」

ところが、ミステリーを書き始めてから、プログラム作成とミステリー執筆にはかなりの共通点があることがわかった。

少し古い開発手法だが、プログラムを制作する際には、まずどのようなプログラムを作れば売れるのかを考える(製品企画)。
次に、ユーザーが欲するものを実現するために、プログラムでの大まかな仕様を決める(要件定義)。
そして実際のプログラムを制作するのに必要なライブラリを考えたり、プログラムの主な動き決める(基本設計)。
次に各入力や、出力(帳票)の細かい部分まで設計する(詳細設計)。
そして実際にコーディングして(プログラム実装)、テストする(検証・デバッグ)。
プログラムを制作するときには、だいたいこの流れで進んでいく。

ミステリとプログラムの類似性



一方、ミステリー小説を執筆するとき、あくまで私の場合だが、まずはメイントリックを考える。ミステリーで言う「ハウダニット」だ。今までに使われたことのないトリックをいろいろ考える。これはプログラムで言う「製品企画」に相当する。
トリックを決めたら、大まかなあらすじ(プロット)を決める。プログラムで言う「要件定義」だ。
次に、登場人物や大きな物語の流れを考える。「フーダニット」、「ホワイダニット」はこの段階で決めることが多い。これは「基本設計」に当たる。
長編の場合、この段階でメインストーリーが決まっているので、次に登場人物に膨らみが出るように、メインプロットとは直接の関係のないサブストーリーを考えていく。このときに何章あって何節あるのかまで細かく決める。いわゆる「詳細設計」だ。
そこまでストーリーを決めたら、あとは一気に執筆する。プログラム開発で言うコーディング(プログラム実装)だ。
書き終わったら、最後に読み返して推敲する。論理矛盾や登場人物の性格でやりそうにない行動を見つけたら、書き直す。いわゆる「検証・デバッグ」作業だ。

そして執筆の場合、この「検証・デバッグ」作業を繰り返すのである。
途中で論理矛盾に気づいたら大変だ。ここを直したら、今度は別の場所で矛盾が出てきて、それを直すと、さらに別の場所で……なんてなこともある。
バグを見つけて直したら、別の場所に影響が出てきて、大わらわ、みたいな。
プログラム作成で言う「リグレッションテスト」を執筆の場合、延々繰り返すのだ。
プロットやキャラクター設定でいい加減に設計していると、推敲段階で地獄を見ることになる。これもプログラムと同じか。

それなので、小説推敲中は「またバグか」という独り言や、「ちゃんとリグレッションテストしないと」なんて、普通の人が聞いたら、「は?」となるような言葉が交わされる。あくまで自分の場合のみだと思うが。

「プログラムとミステリー」、本当に類似性があるのかはわからない。
私が勝手に類似性を見つけているだけなのかもしれない。
もし私が勝手に類似性を見つけているだけだとすると、長年プログラムを作り続けてきた「職業病」なのかもしれない。

私の小説の登場人物も言っていたが、労災に認定されないかなあ。

小説が面白いと思ったら、スキしてもらえれば嬉しいです。 講談社から「虫とりのうた」、「赤い蟷螂」、「幼虫旅館」が出版されているので、もしよろしければ! (怖い話です)