物語エンジニアとは｜「ingenium=工夫する人」から考える兼業作家の新しい肩書き
最近、自分の肩書きを「兼業作家」だけでは少し物足りないな、と感じることがあります。書いているのは小説ですが、頭の中でやっているのはどうもエンジニアの仕事に近いんです。
この記事では、私が最近そっと名乗っている 物語エンジニア（ナラティブ・エンジニア） という肩書きについて、語源と中身を一緒に整理してみます。
読み終える頃には、「あ、これって自分の書き方かも」と思える方が、きっと何人かいるはずです。
エンジニアの語源は「ingenium=才能・工夫」
まず先に、ちょっと面白い話から。
英語の engineer、エンジニアという言葉、もとを辿るとラテン語の ingenium、インゲニウムと読みます、に行き着きます。意味は「生まれ持った才能」「ひらめき」「工夫」。つまりエンジニアは、本来「機械を扱う人」ではなくて、本来は ひらめきと工夫で物事を組み上げる人 を指す言葉だったんです。
中世ヨーロッパで「ingeniator」と呼ばれていたのは、城壁や攻城兵器を設計する人たち。彼らはCADもなければ計算ソフトもない時代に、経験とひらめきと幾何学を組み合わせて、巨大な構造物を立ち上げていました。
この語源を知った瞬間、私は思ったんです。
これって、物語を書く人のことじゃないか。
感性のひらめきと、構造の工夫。両方を行ったり来たりしながら、目に見えない感情の城を組み上げていく。それはまさに、物語の書き手がやっていることそのものです。
「物語エンジニア」とは何者か
そこから生まれたのが、物語エンジニア（ナラティブ・エンジニア） という肩書きです。
ひとことで言うと、こんな存在です。
感性と技術の両輪で、再現可能な感動を組み上げる書き手
「作家」と何が違うの？ と思われるかもしれません。私の中での区別は、ざっくりこんな感じです。
| 呼び方 | 主軸 | 設計図 | 失敗したとき |
|---|---|---|---|
| 作家 | 感性・才能 | 必要に応じて | 「次はもっと頑張る」 |
| 職人 | 経験・型 | 体に染み付いた型 | 「数をこなして直す」 |
| エンジニア | 感性 × 技術 | 明示的に書く | 「設計のどこに穴があったか分析する」 |
エンジニアの強みは、失敗を再現可能な学びに変えられる ところにあります。「ここのプロットは弱かった」「ここのキャラ動機が説明不足だった」と、設計図に立ち返って原因を特定できる。次回作はその学びを反映したうえでスタートできる。
これは、感性だけで書いていた時代の私には、まったく持てなかった力でした。
物語エンジニアが持つ3つのスキル
物語エンジニアと呼べるかどうかの目安として、私はこの3つを意識しています。
1. 分解する力（リバースエンジニアリング）
好きな作品を読んだとき、「面白かった」で終わらせない。なぜ自分はここで泣いたのか、どの伏線がどこで効いたのか を、後から構造として取り出せる。これが分解する力です。
ITの世界で言う「リバースエンジニアリング」と同じ発想ですね。完成品から設計図を逆算する。これができると、自分の創作のために他人の作品から技術を借りてこられるようになります。
2. 設計する力（フォワードエンジニアリング）
書き始める前に、ある程度の設計図を描ける。プロット、感情曲線、キャラクターの役割分担。すべてを完璧に決める必要はありませんが、クライマックスで読者に何を感じてほしいか くらいは、最初に言語化しておく。
設計図があると、書いている途中で迷子になりにくくなります。「あれ、この場面って何のために書いてるんだっけ」となったとき、立ち返る場所があるのは安心感が違うんです。
3. デバッグする力（修正の技術）
書き上げた原稿を、自分でレビューして直せる。これが3つ目のスキルです。
ITエンジニアがバグを直すときには、再現条件・原因・対策 をセットで考えます。物語も同じで、「ここで読者が離脱しそう」と感じたら、「なぜそう感じるか」「どこを直せば改善するか」をセットで考える。場当たり的な書き直しではなく、原因を突き止めてから修正に入る癖をつける、ということですね。
「作家でいい」のに、なぜ物語エンジニアと名乗るのか
ここまで読んで、こう思った方もいるかもしれません。
「別に『作家』でよくない？」。
その通りなんです。一作だけ書きたい人、感性のままに書きたい人にとっては、エンジニアの視点はむしろ邪魔になることもあります。
私が「物語エンジニア」を名乗りたくなったのは、たぶん 長く書き続けたいから です。
感性は波があります。いい時もあれば、まったく筆が動かない時もある。でも技術は、地道に積み上げていけば裏切りません。技術と仕組みで、感性が低空飛行している時期も「とりあえず書ける状態」をキープする。これが、兼業で創作を続けるための私なりの生存戦略でした。
詳しい背景は 物語工学とは何か？ 感覚に頼らず「感情」を設計する技術 に書いていますが、エンジニアという肩書きはその物語工学を 人の側から表現したもの だと思っています。
ITエンジニアと物語エンジニアの共通点
ITの仕事と物語を書く仕事って、見た目は全然違いますよね。でも内側を覗くと、けっこう似ているところがあります。
| 工程 | ITエンジニア | 物語エンジニア |
|---|---|---|
| 要件定義 | 「誰のどんな課題を解くか」 | 「誰にどんな感情を届けたいか」 |
| 設計 | 画面・データ・処理フロー | プロット・キャラ・感情曲線 |
| 実装 | コーディング | 執筆 |
| テスト | 動作確認・レビュー | 自己レビュー・推敲 |
| リリース | デプロイ | 投稿・出版 |
| 運用・改善 | 監視・改修 | 読者反応をもとに次作へ |
並べてみると、本当にきれいに対応します。私は本業で要件定義から運用まで一通りやってきた身なので、この発想を物語に持ち込んだら、書く工程がずいぶん安定したんです。
特に効いたのが テスト工程をちゃんと取る こと。書きっぱなしで投稿していた時代と比べて、自分でレビューする工程を入れるようになってから、明らかに完成度が上がりました。
物語エンジニアになるための3ステップ
「ちょっと自分も名乗ってみたい」と思った方に、最初の3ステップを置いておきます。
Step 1：好きな作品を1本、分解してみる
まずは 『工学的ストーリー創作入門』書評｜才能不要、6つの要素で物語は作れる で紹介した6要素のフレームを使って、好きな作品をひとつ分解してみましょう。「主人公は誰か」「目標は何か」「障害は何か」「クライマックスはどこか」。書き出してみると、感覚で観ていたものが構造として見えてきます。
Step 2：自作のプロットを設計図として書いてみる
次に、自分の作品（過去作でもOK）のプロットを、改めて設計図として書き直してみましょう。感情曲線を1本のグラフで表現するだけでも、見えてくるものがあります。
Step 3：書き終わった原稿に「レビューコメント」を入れる
最後が、自分の原稿に対するセルフレビュー。この場面の目的は？ ここで読者が離脱しそうな箇所は？ といった視点で、コメントを書き込んでいきます。第三者になったつもりで、自分の原稿に意地悪な質問をぶつけるのがコツです。
この3ステップを通った頃には、たぶんもう、ご自身の感覚の中で「物語エンジニア」の輪郭ができているはずです。
兼業だからこそ持てる視点——ITの現場から物語に持ち帰れるもの
兼業作家の強みは、本業で叩き込まれた技術思考をそのまま物語に持ち込めることです。私自身、SEとして培った習慣のうち、特にこの3つは物語の設計に直接効きました。
• なぜを繰り返す発想——トヨタの5Whys分析のように、「主人公がここで動くのはなぜ？」を5回掘ると、薄っぺらい動機が腌りません。詳しくは 5 Whys分析の使い方 を参照してください
• あるべき姿から逆算する——As-Is/To-Beの発想で、クライマックスのTo-Beから現在のAs-Isへ線を引くと、途中の障害が自然と設計されます
• 原因を分解して対策を分岐させる——ロジックツリーで「読者が離脱する原因」を木構造で広げると、1本ずつ対策が打てるようになります
こういう発想は、感性一本で書いていた頃の私には1ミリもありませんでした。本業で毎日やっていることを、意識して物語に転用するだけで、書く工程が驚くほど安定するんです。
物語エンジニアが陥りやすい3つの罠
ただし、エンジニア思考が強すぎると逆効果になる場面もあります。私自身ハマった落とし穴を3つ共有しておきます。
罠1：設計しすぎて書き始められない
プロットを詰めすぎて、ディテールまで全部決めないと1行も書けなくなる症状です。対策はクライマックスと最初の1万字だけ決めて走り出すこと。残りは書きながら設計していけばいい、と割り切ります。
罠2：感性の揺らぎを「バグ」扱いしてしまう
「今日は乗らない」を技術で封じ込めようとすると、筆が進んでも文章の肌触りが死にます。感性の低空飛行は、完全にゼロにせず低空のまま書ける仕組みを用意する方が長続きします。
罠3：レビューを自分で厳しくしすぎる
エンジニア流のセルフレビューは強力ですが、書きながら同時にやると手が止まります。書くフェーズと直すフェーズを物理的に分ける。1日以上寝かせてからレビューに入る、くらいの距離感がちょうどいいです。
まとめ
• engineer の語源は ingenium＝「才能・ひらめき・工夫」。本来は感性と工夫で物事を組み上げる人を指す言葉。
• 物語エンジニア とは、感性と技術の両輪で、再現可能な感動を組み上げる書き手のこと。
• 必要なスキルは 分解・設計・デバッグ の3つ。
• 一作だけ書く人ではなく、長く書き続けたい人 にとって有効な肩書き。
• ITエンジニアの工程と物語の工程は驚くほど対応していて、転用が効く。
• 始めるための3ステップは「好きな作品を分解 → 自作を設計図化 → 原稿にセルフレビュー」。
「作家」という言葉が少し重くて躊躇していた方こそ、「物語エンジニア」というラベルを試してみるのもいいかもしれません。設計図を描き、組み上げ、デバッグする。そう捉え直すと、白紙の原稿にも少しだけ手をつけやすくなる気がします。
どうですか、ちょっと書ける気がしてきましたか。もし悩むことがあったら、このブログに戻ってきてください。同じように初心者だった私が、基礎から応用まで気づいたことを書き綴っています。
さあ、今日も物語を組み上げましょう。あなたの傑作を待っています。
関連記事
• 物語工学の7つのキャラクター類型｜新城カズマの分類で物語を設計する