「プログラマに向いているのは、理系か？それとも文系か？」
IT業界に長く身を置いていると、よくこんな質問を受けます。勤続30年、現役のSE（システムエンジニア）兼プログラマとして現場を見てきた私の結論は、**断然「文系」**です。
そして、当サイトでの掲載作品が100の大台に乗った今、改めて確信していることがあります。それは、日々の業務でシステムを構築する際の脳内プロセスは、私が趣味としている「小説執筆」と、ほぼ完全に一致しているということです。
今回は、一見すると対極にあるように思える「プログラミング」と「小説執筆」の意外な共通点について、現役エンジニアの視点から紐解いてみたいと思います。
1. 現代のプログラミングは「数学」ではなく「言語」である
「プログラマ＝理系」というイメージは、おそらく高度な数学的知識や科学的アプローチが必要だという先入観から来ているのでしょう。しかし、こと「一般のプログラミングの現場」に関しては、それらはほぼ必要ありません。
アセンブラ時代とは違う「1を10にする」作業
もちろん、アセンブラやCOBOLが主流だった時代は、ハードウェアの制約も厳しく、理系的な能力が強く求められた側面はあります。理系の思考は、言わば「数学の公式を発見する」ような、0から1を生み出すイメージです。
しかし、現代のプログラミングは全く異なります。あらかじめ用意されたフレームワーク（言語の文法）に則って、筋道の通った文章を書き連ねていく作業がメインです。つまり、1を10に拡張していくイメージであり、これは極めて「文系的」な特徴だと言えます。
使うのは論理的思考力と「言語野」
現代のプログラミングにおいて最も酷使される脳の領域は、計算を司る部分ではなく、明らかに**「言語野」**です。
主語があり、述語があり、条件分岐（もし〜ならば）がある。プログラミング言語という外国語を使って、コンピュータに「こう動いてください」と論理的な指示書（ストーリー）を書いているに過ぎないのです。
2. 小説執筆とコーディングの「脳内処理」は同じ
言語野を使って論理を組み立てるという点で、プログラミングと小説の執筆は同じ箱の中にあります。具体的な作業の感覚も、実はそっくりなのです。
伏線の未回収は「システムエラー」
小説を書く際、最初にプロット（物語の骨組み）を練ります。登場人物を配置し、事件を起こし、結末へと向かう道筋を立てる。これはシステム開発における「基本設計」そのものです。
もし、物語の前半で張った伏線が回収されなかったり、登場人物の行動に矛盾があったりしたらどうなるでしょうか？ 読者は混乱し、物語の世界から弾き出されてしまいます。これはプログラムで言うところの**「システムエラー（バグ）」**と全く同じです。論理の破綻は、システムも物語も一瞬でクラッシュさせてしまうのです。
読者のために物語を「リファクタリング」する
プログラミングには「リファクタリング」という作業があります。外から見た動作は変えずに、内部のコードをより整理して綺麗にする（読みやすく、後から改修しやすくする）プロセスです。
小説の推敲もこれに似ています。「読者（ユーザー）にとって面白いか？ 使いやすい（読みやすい）か？」「無駄な描写（冗長なコード）はないか？」。この視点を持ち、システムからバグを取り除く「デバッグ」の感覚で文章を洗練させていく。この工程を経ることで、読者の心にバグなくスッと届く物語が完成します。
3. プログラマと作家に共通する最強の資質「良い意味での怠惰」
もう一つ、システム開発と創作活動を長く続ける上で、決定的に重要な共通の資質があります。それは**「良い意味での怠惰さ」**です。
「めんどくさがり屋」こそが効率化を生む
優秀なプログラマは、総じて『めんどくさがり屋』です。「毎回この手作業をやるのは面倒くさいな……よし、自動化するプログラムを組もう」という欲求こそが、効率的で美しいシステムを生み出す最大の原動力になります。
小説執筆も同じです。「いかに隙間時間で効率よく書けるか」「スマホの単語登録やツールを使って、いかに入力の手間を省くか」。この「書くための準備」を徹底的に効率化する、良い意味での怠惰さこそが、継続の秘訣なのです。
ただし、間違ってはいけないのが、「作品」に対して「怠惰」であるということではありません。
むしろ、入力の手間や環境のストレスという「余計なバグ」を排除するのは、作品の質を高めることに全神経を集中させるため。創作という聖域を守るために、それ以外の工程を徹底して合理化するのです。
上司には評価されにくいけれど……
もっとも、この『めんどくさがり屋』という才能は、過程よりも目に見える「作業している感（汗をかいている感）」を重視する上司には、なかなか評価してもらいにくいという大きな問題があるのですが……（苦笑）。
見えないところでシステムを自動化し、涼しい顔をしているエンジニアほど、実は高度な仕事をしているものです。
4. まとめ〜論理の枠組みで「感情」を描く〜
「IT（論理）」と「文学（感情）」。一見すると水と油のようですが、思考の手順や脳の使い方は驚くほど似ています。
論理という頑丈なフレームワーク（骨組み）があるからこそ、その上に「人間の繊細な感情」や「日常の機微」という予測不能なデータを乗せても、物語が破綻することなく読者のもとへ届くのです。
私が日々、バグのないコードを書きながら、同時にショートショートの構想を練ることができるのは、こうした思考の共通項があるからに他なりません。
そんな現役SEである私が、頭の中を「デバッグ」しながら、現代社会のストレスや小さな感情の揺れ動きをプログラミングするように紡いだ物語たちがあります。
▼ プログラマの視点で組み上げた、おすすめのオリジナル短編小説
コーヒー1杯分の隙間時間で、ぜひ「バグのない物語」の実行結果（結末）をテストプレイしに来てください。
……あ、ごめんなさい。「バグのない物語」は少し言い過ぎました。
今後もし物語に辻褄の合わない部分が見つかりましたら、ITシステム屋の伝家の宝刀**「仕様です」**を差し上げますので、どうぞお納めください（笑）。
100作品を迎え、これからもより精度の高い、そして心地よい物語をお届けしていきたいと思います。
今後とも、どうぞよろしくお願いいたします。