ITエンジニアの物語開発工程の説明メモ
ITエンジニアである私が小説を書こうとした結果、自然発生した開発工程。
執筆というより、設計→製造→検査→改善の流れに近いため「開発」と呼んでいる。
とカッコつけていますが、要はこうしないと私は書けないんですという独白ですね。
工程の説明、工程毎の成果物をこちらで書いていこうと思います。
1. 物語要求整理
1.1.目的
何を書きたいのかを決める。
細かく決めない。
全部決めようとしない。
ノリと勢いを大切にする。
1.2.決めること
一言で言える願望やテーマ。
例
貴人の恋愛を書きたい
現代の恋愛を書きたい
竜を倒す物語を書きたい
箸の使い方をドラマ仕立てにしたい
左折だけでたどり着ける店に車で行く安心感をねっとり語りたい
1.3.ポイント
短くてよい
カッコ悪くてもよい
後で変わってもよい
2. 物語要件定義
2.1.目的
要求を成立させるために必要な資源を洗い出す。
2.2.決めること
登場人物
場所
世界観
道具
状況
時代
関係性
など。
例
要求
「左折だけでたどり着ける店に車で行く安心感を書きたい」
要件
店：ケーキ屋、食料品店
誰と：妻
いつ：休日午前
移動手段：車
道：左折だけで到着できる
2.3.ポイント
ここではドラマを作らない。
必要な部品を並べる。
3. 物語設計
3.1.目的
要件に流れを与える。
3.2.決めること
起承転結
シーン構成
人物配置
関係変化
障害
見せ場
3.3.ポイント
要件を「物語」へ変換する工程。
抽象度は高くてよい。
4. 台本原案（基本設計）
4.1.目的
物語設計をシーン単位まで具体化する。
4.2.内容
イベント一覧
シーンの順序
各シーンの目的
登場人物
キメ台詞（これを言わせたいねん！）
キメ情景（ここを見せたいねん！）
例
シーン1：店へ向かう
シーン2：通行止め
シーン3：回り道
シーン4：到着
5. 台本（構造設計）
5.1.目的
シーンに構造を与える。
5.2.決めること
ト書き
心情
モノローグ
会話
アクション
情報開示順序
5.3.ポイント
読者に何を見せるかを決定する工程。
6. 台帳（詳細設計）
6.1.目的
構造を運用可能な状態にする。
6.2.管理対象
キャラクター状態
関係性変化
伏線
回収
世界観との整合
EID
TID
依存関係
ポイント
物語の整合性を維持するための設計資産。
7. 検査
7.1.目的
破綻や矛盾を発見する。
例
キャラらしいか
動機があるか
伏線は成立しているか
世界観と矛盾しないか
伝えたいものが伝わるか
8. 小説化（実装）
8.1.目的
設計資産を読者向け文章へ変換する。
8.2.内容
地の文追加
描写追加
温度調整
湿度調整
文体変換
8.3.ポイント
小説は設計成果物ではなく実装成果物。
以下は、一言でようやくしてみる。
一言版
物語要求整理
→ 何を書きたい？
物語要件定義
→ 何が必要？
物語設計
→ どう動かす？
台本原案
→ どんなシーンが必要？
台本
→ 読者に何を見せる？
台帳
→ 破綻しないよう管理する
検査
→ 壊れていないか確認する
小説化
→ 読者が読む文章へ変換する
