ブレーンストーミング。小説の書き方とWebアプリの作成の作法を対応させて、小説を段階的に書く手法を確率する。小説の登場人物はWebアプリのDBテーブルに見立てる。小説のストーリーはWebアプリの機能に見立てる。このようにした場合、具体的な小説を例に分解してみてほしい。例えば、夏目漱石の「三四郎」でやってみて。
これはかなり面白いです。
ただし、私はあなたの現在の発想を、
キャラクター = DBテーブル
ストーリー = 機能
という対応だけで終わらせない方がよいと思います。
むしろ、
小説開発 ≒ Webアプリ開発
として工程全体を対応させると、かなり強力な執筆OSになります。
まず「三四郎」を使って分解してみます。
最上位：システム要件
Webアプリなら最初に
何のためのシステムなのか
を決めます。
例えば
勤怠管理システム
書籍販売システム
チケット販売システム
``
など。
三四郎の場合は
system_name: Sanshiro
purpose:
青年を成長させる
output:
青年の精神的変化
になります。
つまり三四郎は、
恋愛小説
ではなく、
青年成長シミュレーター
と見なす。
DB設計
ここであなたの発想を使う。
人物はレコードではない。
人物はテーブル。
Sanshiroテーブル
Sanshiro:
pure
curiosity
love
confusion
growth
三四郎という概念。
Minekoテーブル
Mineko:
beauty
freedom
mystery
distance
unattainable
美禰子という概念。
Hirotaテーブル
Hirota:
wisdom
skepticism
philosophy
observation
広田先生という概念。
ここが重要。
各テーブルは
人間
ではなく、
機能的概念の集まり
です。
機能設計
Webアプリでは次にユースケースを書く。
例えば
ログイン
商品購入
投稿作成
など。
三四郎では
機能1
青年上京機能
move_to_tokyo()
機能2
謎の女性遭遇機能
meet_mineko()
機能3
思想注入機能
meet_hirota()
機能4
恋愛失敗機能
``
lose_mineko()
ここで重要な発見がある。
ストーリー = 機能呼び出し列
普通は
物語
↓
出来事列
と考える。
しかしWeb方式だと
機能A
↓
機能B
↓
機能C
↓
機能D
になる。
三四郎全体は
move_to_tokyo()
meet_mineko()
meet_hirota()
grow()
lose_mineko()
の実行ログとも言える。
シーンはUI
これがさらに面白い。
多くの小説論では
シーンを書く
から始める。
しかしWeb開発ではUIは最後。
例えば
meet_mineko()
``
という機能がある。
そのUIが
列車内
池の周辺
散歩
になる。
つまり
機能が先
シーンは後
である。
三四郎をシーケンス図で見る
Webシステム風に書くと
Sanshiro
|
| 上京
v
Tokyo
Sanshiro
|
| 遭遇
v
Mineko
Sanshiro
|
| 相談
v
Hirota
Sanshiro
|
| 恋愛
v
Mineko
Mineko
|
| 離脱
v
Sanshiro
になる。
長編になる理由
ここがあなたの理論の核心。
もしテーブルが
Sanshiro
Mineko
``
だけなら短編。
しかし
Sanshiro
Mineko
Hirota
Yojiro
Nonomiya
Professor
Friend
`
になると、
テーブル同士の連携が爆発的に増える。
Webアプリでも同じ。
users
しかなければ単純。
しかし
users
posts
comments
likes
notifications
messages
になると急激に複雑になる。
つまり、
登場人物が増える
とは
テーブル数が増える
ではない。
本質は
JOIN可能性が増える
こと。
本文は何か
ここでさらに一段下へ降りる。
Webアプリなら
DB
↓
機能
↓
画面
で終わる。
小説では
DB
↓
機能
↓
シーン
↓
文章
がある。
つまり本文は
実装コード
に近い。
例えば
meet_mineko()
だけでは作品にならない。
その処理内容を
三四郎は池の岸を歩いていた。
そこへ美禰子が現れた。
と文章化する。
執筆OSとして整理
すると小説を書く工程は、
かなり自然に
1. システム目的
↓
2. テーブル設計
↓
3. 機能設計
↓
4. 機能呼び出し順
↓
5. UI設計(シーン)
↓
6. 実装(文章)
になる。
三四郎を完全に一行で表すと
あなたの理論で三四郎を表現すると、
Sanshiroテーブルに対して
Minekoテーブルと
Hirotaテーブルを
特定順序でJOINし、
青年を成長状態へ遷移させるアプリケーション
になる。
そして夏目漱石は、
文章家というより
青年成長アプリのシステムアーキテクト
だったと解釈できる。
このモデルの面白い点は、Roblox開発とほぼ同じ設計手順に落とし込めることです。
NPC設計
↓
能力設計
↓
イベント設計
↓
クエスト設計
↓
マップ設計
↓
セリフ実装
が、
登場人物設計
↓
概念設計
↓
ストーリー機能設計
↓
シーン設計
↓
背景設計
↓
文章実装
にそのまま対応します。
つまり小説を書くとは、「文章を考えること」ではなく、
概念テーブル群とその相互作用を設計し、その実行ログを自然言語にレンダリングすること
だと考えられます。これはかなりOS的で、あなたの構造主義的な発想に合うモデルだと思います。