コードを書く手で、物語を紡ぐ。IT副業×ライトノベルのすすめ
こタイトルを見て「あ、これ自分のことだ」と思った方、ようこそ。
ITエンジニアがライトノベルを書く。あるいはWeb小説を書く。聞けば意外な組み合わせに思えるかもしれませんが、実際にこの二足のわらじを履いている人間は少なくありません。私自身がその一人です。
日中はコードを書き、帰宅後は物語を書く。この生活を続けてきて確信したことがあります。プログラミングと小説執筆は、表面上の違いとは裏腹に、思考の根本構造が驚くほど似ているということです。
プログラミングと小説執筆の共通構造
「コードを書く」と「物語を書く」。使う言語は違います。片方はPythonやJavaScript、もう片方は日本語です。しかし、その裏で動いている思考プロセスには、明確な共通点があります。
設計フェーズの類似性
ソフトウェア開発では、いきなりコードを書き始めません。要件定義、基本設計、詳細設計を経て、初めてコーディングに入ります。良いソフトウェアは、コードを書く前の設計段階で品質の大部分が決まっています。
小説もまったく同じです。プロットを練らずに書き始めた小説は、設計書なしで作られたシステムと同じ末路をたどります。途中で整合性が破綻し、保守（推敲）が困難になり、最終的にプロジェクト自体が頓挫する。なろうで「エタる」作品の多くは、このパターンに該当しているのではないでしょうか。
エンジニアであるあなたには、設計の重要性が骨身に染みているはずです。その感覚は、そのまま小説のプロット設計に活きます。
デバッグと推敲の思考法
コードにバグがあったとき、エンジニアは何をするか。まず再現手順を確認し、ログを追い、原因箇所を特定し、修正案を複数検討し、影響範囲を調べてから修正を適用します。
小説の推敲も、本質的にはこのデバッグ作業と同じです。「この場面、なんか違和感がある」——その違和感は、物語におけるバグです。キャラクターの行動が設定と矛盾している。伏線が回収されていない。感情の流れに飛躍がある。これらの原因を特定し、修正し、修正による副作用（他の場面への影響）がないかを確認する。
エンジニアが日常的に行っているデバッグの思考法は、推敲の技術にそのまま転用できるのです。
入力設計がキャラクターの動機設計に変わる
システム設計における「入力設計」は、ユーザーが何を入力し、それに対してシステムがどう応答するかを定義する作業です。不正な入力に対するバリデーション、エッジケースの処理、ユーザー体験の最適化——これらすべてが「入力」から始まります。
小説においてこの「入力」に相当するのが、キャラクターに与えられる「動機」と「状況」です。主人公に何が入力されたら、どんな行動を出力するのか。その行動が次のキャラクターの入力になり、連鎖的にストーリーが進行する。
この「入力→処理→出力」のモデルでキャラクターの行動を設計すると、ご都合主義を排除しやすくなります。「なぜこのキャラクターはこの場面でこの行動をとったのか」に対して、入力（動機・状況）から論理的に説明できる行動であれば、読者は納得します。説明できない行動は、システムでいうバグです。
ITエンジニアの「弱点」と対処法
ここまで共通点を強調してきましたが、エンジニア出身の書き手には固有の弱点もあります。正直に言います。
論理性の罠——感情を「処理」してしまう問題
エンジニアは問題を解決することに慣れています。バグがあれば直す。エラーが出れば原因を潰す。これは仕事では素晴らしい姿勢ですが、小説では弊害を生むことがあります。
キャラクターの感情を「問題」として処理してしまうのです。主人公が悲しんでいる→早く解決してあげなければ→次の場面で立ち直らせる。しかし、読者が求めているのは「問題解決の効率」ではなく、「感情の体験」です。主人公と一緒に悲しみの底にいる時間こそが、物語の旨味です。
対処法は意外とシンプルです。「この感情は、何行で解決すべきか」ではなく、「この感情は、何行かけて味わうべきか」と問いを立て直すこと。スプリント計画ではなく、感情の滞在時間を設計するのです。
設定過多——世界観を「仕様書」にしてしまう問題
エンジニアは設計が好きです。だから、ファンタジー小説を書くとき、魔法体系を数式で定義し、経済システムを表計算ソフトで管理し、地図をCADで描きたくなります。
これ自体は悪いことではありません。むしろ、緻密な設定は作品の強度を高めます。問題は、その設定を全部本文に書こうとすることです。設定資料集は読者が読むものではなく、作者が参照するものです。5,000文字の魔法体系の説明を冒頭に置いたら、99%の読者がブラウザバックします。
対処法は「必要な情報を、必要な場面で、必要な分だけ」というAPI設計の原則を適用することです。情報は呼び出されたときに初めて返す。全データを初期ロードしない。RESTfulな情報開示が、小説では「自然な情報の出し方」に変わります。
副業作家としての時間設計
ITエンジニア×副業作家の最大の課題は、時間です。
本業のシステム開発は脳の体力を大量に消費します。8時間コードを書いた後に帰宅して、今度は小説を書く。同じ「書く」作業でも、使う脳の領域が微妙に異なるとはいえ、疲労は蓄積します。
ここで、エンジニア的な発想が役立ちます。時間管理をシステム設計として捉えるのです。
まず、一日の中で「創作に使える可処分時間」を正確に測定します。通勤時間、昼休み、帰宅後の自由時間。これを分単位で把握する。次に、その時間を「インプット」「設計」「執筆」「推敲」の四つのタスクに分類し、それぞれに適した時間帯を割り当てます。
たとえば、通勤電車の中は「インプット」に最適です。本を読む、なろうの作品を読む、映画のレビューを読む。昼休みの後半15分は「設計」に使う。スマホのメモアプリにプロットのポイントを箇条書きにする。帰宅後の1時間を「執筆」に充てる。週末の朝に「推敲」を行う。
2025年になろうが開始した「チアーズプログラム」は、Web小説作家への収益還元制度です。これにより、副業として小説を書くことの経済的インセンティブが以前より明確になりました。もちろん、チアーズプログラムだけで生活できるほどの収入を得るには相当の読者数が必要ですが、「趣味が少しでも収入になる」という事実は、モチベーションの維持に確実に貢献します。
プログラマーの思考が活きる具体的テクニック
最後に、エンジニアの思考法を創作に直接活かせる具体的なテクニックをいくつか紹介します。
バージョン管理を原稿に適用する
GitHubを使っているなら、原稿管理にもGitを使えます。各章をコミット単位で管理し、大きな修正にはブランチを切る。「あの表現に戻したい」というときの安心感は格別です。テキストファイルベースで書いていれば、diff機能で変更箇所を一目で把握できます。
テスト駆動開発ならぬ「伏線駆動執筆」
テスト駆動開発（TDD）は、先にテストを書き、それを通すコードを後から書く手法です。これを小説に応用すると「先に回収シーンを書き、それに向けた伏線を後から仕込む」という手法になります。結末から逆算して物語を構築する方法です。ミステリー作家がよく使う手法ですが、エンジニアにはTDDの概念が身体に馴染んでいるので、直感的に理解できるはずです。
コードレビューの精神を推敲に活かす
チームでコードレビューを行うとき、「このロジック、もっとシンプルに書けませんか」というフィードバックをもらった経験はないでしょうか。同じ目を、自分の原稿に向けてみてください。「この場面、もっと短く書けないか」「この台詞、もっと直接的に言えないか」。コードレビューで鍛えた「冗長さへの嗅覚」は、文章の推敲において強力な武器になります。
コードを書く手で、物語を紡いでいい
ITの世界で「ものを作る」ことに慣れている人間は、物語を「作る」ことにも向いています。設計し、実装し、テストし、リリースする。そのサイクルを回す体力と習慣がすでに身についているからです。
足りないのは、「自分にも物語が書ける」という確信だけかもしれません。
仕事で使っているのと同じ手で、キーボードの同じキーを叩いて、今度は物語を立ち上げてみてください。通勤電車でAPI設計を考える代わりに、主人公の行動原理を設計してみてください。ランチタイムにバグの原因を推測する代わりに、物語のプロットホールを探してみてください。
あなたの技術者としての思考法は、創作においても間違いなく武器になります。それを信じて、まずは第1話を書いてみてください。
関連記事
• 可処分創作時間の設計｜兼業作家が「書く人間」でいるための時間戦略
• プロットで悩んだらこう考えろ｜設定と展開を選ぶ3つの基準
• プロットが書けない？ 「ネタだし40」と「年表」で燃え尽きない方法
IT業界の方は↓も是非プレイしてみてください！必ず心に引っかかる部分があるはずです(笑)
