新卒でIT業界に入ってから5年ほど経ちました。
元はドのつく文系だった自分ですが、だからこそ気づくコーディングと、小説や物語の執筆活動の類似点という点について、（こじつけながら）ここに残したいと思います。
とはいえ、文理関係なくまとまった文章を書いてきた人であればだいたい気づく内容だとは思います（予防線）。
※元は社内向けのLT資料となります。
※preziというプレゼンツールを使った資料だったので、スライド画像にすると若干見づらいかもしれませんがご容赦ください。
ド文系度
文系エンジニアは珍しくもありませんが、
その中でも私はド文系側の存在と自負しています。
高校では、現代文・古典、英語などの文系科目は考査の大きな点数ソースで、当然の文系選択でした。
大学は教育学部でしたが教員免許を取ることが目的の課程ではなかったので、勉強はろくにせずひたすら本を読み漁っていました。
また、たまたま取った心理学や社会学の講義で興味を持って学術系の入門書や論文を読むことも多かったです。
それでも余った時間には自分で短編小説を書くようになりました。
地元の地方新聞に寄稿した短編は新人賞として紙面に載せていただいたり、
ネット上の短編小説賞で小さい賞をもらったりと、素人とはいえある程度文章は書いてきたと自負しています。
類似点
さて、私のド文系度がどれくらいかを説明したところで、
そんなド文系だからこそ気づく執筆とコーディングの類似点、という本題に入っていきたいと思います。
執筆ルール ≒ コーディング規約
当然ながら小説、いや作文レベルであっても執筆のルールがあります。
スライドに書いているようなことは暗黙のルールと化しており、小説賞などの応募要件として明文化されることはあまりありませんが、
これらのルールが守られていることは前提とされています。
コーディングでも同様にルールが存在します。
と言ってもPythonのインデントなど言語仕様として守らなければいけないルールのことではなく、
コードの書き方として統一性を図り、読む人に読みやすく、書く人に書きやすくするためのルールのことです。
複数人で開発するときはもちろんですが、個人で開発する時でも（規約として明文化するかは別として）ルールを設けておくことで書き方で迷ったりすることも減りますし、あとから自分で読み返す時にも読みやすくなるはずです。
めちゃくちゃググる
これは人によるかもしれませんが、私は文章を書くときとにかくググります。
言葉の意味や使い方はもちろんですが、時代考証、科学考証（考証というほど大したことはしていないけど）、
さらに地理的な情報集めなどにもネットの情報を利用します。
もちろんネットの情報は信憑性に劣る部分があるので、より正確な情報収集を目的とするときは論文や学術書などの文献も当たります。
コーディングにおいても度々ググりますが、
これも関数の意味や使い方はもちろん、ベストプラクティスやデザインバターン、言語仕様、
その他様々なTipsを調べながらコーディングします。
ネットの情報がすべて正しいわけではありませんが、普通のコーディング上の悩みはググれば大抵何とかなります（暴論）。
少なくとも自分ひとりで悩んであれこれ試してみる暇があれば、ググってコピペしたほうが早く済みます。
身に着けるための勉強は、その場を凌いでからでもいいはずです。
プロット ≒ 設計
小説におけるプロットとは構成や筋書きのこと、
または、作中で描かれる登場人物の心理描写、背景描写を指します。
ここでは構成の意味で取りますが、ある程度の長さの文章を書くときには大抵プロットを先に考えます。
これはコーディングにおける概要設計（外部設計）やクラス設計に置き換えることができます。
コーディングは予め決めたプロットに沿って文章を綴る作業と言えます。
ただし、小説におけるプロットではあえて意外性のある構成にすることで読者へのインパクトを与える方法があります。
ミステリにおける叙述トリックなどですね。
こういった意外性のある構成、つまり設計は原則コーディングにおいてはしてはいけません。
意外性のあるコードは読みづらいし、直しづらいし、テストもしづらいものになるからです。
他に実装しようがないときには仕方ないかもしれませんが、そんなときは大抵その上流工程で何かが間違っていることを怪しむべきです。
言葉の選択 ≒ 関数の選択
この点はあまり書くことはありません。
執筆における言葉選びは、複数ある類義語のなかからどの言葉を使うかの選択です。
より正確な意味を取ることもできるが、文体として固くなりすぎないか、とか
この登場人物はこの言葉は知らなさそうだから使わないだろう、とか
正確な意味からはズレるかもしれないが、ダブルミーニングを狙えるからこの言葉を使おう、とか
コーディングにおいては同じ処理結果になる関数やメソッド、書き方が複数あることもありますが、
速度を優先するか、可読性を優先するかなどが選択要因になります。
三項演算子で書けば一行で書けるけど、見づらくなる場合はif文で複数行書こう、みたいなことですね。
可読性を意識する
ここまでの類似点でも度々言及しましたが、可読性への意識は重要です。
小説の場合、章立て、段落が適切にされていないものは、まず一目見てウッてなります。
さらに不適切な句読点や婉曲表現、比喩表現がされている場合はちゃんと読んでも読みづらいです。
もちろん敢えてそういう文体にしているものもありますが、
それは読みづらいことを自覚したうえで書いているはずだから許されるし演出になり得ます。
コーディングにおいても人が読むものであるという前提を意識した書き方が重要です。
読む人が初学者なのかベテランなのかは分かりません。
コーディングにおける可読性は最優先事項です。
相違点
さて、類似点を述べてきた最後に、執筆とコーディングの決定的な相違点を提示したいと思います。
すなわち、「個性を出してはいけない」という点です。
小説における個性は重要です。
個性的でない小説は退屈だし、売れないし、ブランド力もつきません。
しかしコーディングにおいて個性は最も注意すべき敵です。
個性的なコードとはつまり、パターンやルール、広く認知されている常識的なコードから逸脱したものを指しますが、
少なくとも一般的なエンジニアが、コーディングにおいて個性（言い換えると創造性）を出すのは避けるべきだと考えます。
理由はもちろん可読性を下げるからです。
可読性が下がると読むのに時間がかかるし、バグは見つけづらくなるし、触りづらくなります。
自分はもちろん、読む人、直す人の時間を無駄にしないためにも、可読性は最重要視されるべきです。
私のような一般エンジニアが個性・創造性を発揮するのはコードではなく、
アーキテクチャ設計やリソース構成など、もっと上流工程であるべきではないかと思います。