かつて、私は「カッコよさ」に憧れていた。
一見して何をしているのか分からないが、たった一行で複雑な処理を完結させる正規表現の妙技。高度なデザインパターンを駆使し、スマートに抽象化されたクラス設計。それらをスマートに使いこなすエンジニアは、私にとって憧れであり、同時に拭いがたいコンプレックスの源でもあった。
私もそうなりたいと背伸びをし、「自分のやり方」――つまり、自分の知識レベルを誇示できるような、効率的でエレガントな記述を模索した時期がある。
しかし、そのたびに壁にぶつかった。 壁とは、数週間後の自分自身だ。
「あれ、この処理、どうしてこんな書き方をしたんだっけ？」
自分が書いたコードを自分で一発で理解できない。そして、他人が書いた超絶技巧なコードに至っては、デバッグに数倍の時間を要する。これが、凡庸な私に突きつけられた現実だった。
認知負荷という「静かなコスト」
この経験を通じて、私は 「認知負荷」 というものの恐ろしさを知った。
『A Philosophy of Software Design』が説くように、設計の目標は複雑さを減らすことだ。ここで言う複雑さとは、コードを読む人が、その動作を理解するために頭にロードしなければならない情報量のことだ。
カッコいいコードは、この認知負荷を静かに、そして暴力的に高める。 「すごい書き方」は、読み手に「この凄さを理解するだけの知識と集中力」を要求する。
私のような凡庸なエンジニアは、その負荷に耐えられない。そして、私と同じ凡庸なチームメンバーも、その負荷に耐えられない。
私が 「一発で意味を理解できない」 というコンプレックスを持っていたからこそ、逆説的に「一発で意味を理解できる」コードの価値を、深く知るに至ったのだ。
メンタルモデルの形成：誰でもわかることの絶対価値
コンプレックスが裏返った瞬間から、私の設計哲学は変わった。 目標は、「自分のやり方」を残すことから、「誰でもわかるわかりやすさ」を残すことへシフトした。
これは、自分の知識や技術を放棄することではない。 むしろ、その知識を、誰もが理解できるレベルにまで 「翻訳」 する、高度な技術的自己抑制である。
- 正規表現: 複雑な正規表現は使わない。多少冗長でも、if文やシンプルな文字列操作に分解する
- デザインパターン: パターンを使うことが目的にならない。パターンを知らない人でも、処理の流れが直感的に追えるようにする
- マジックナンバー: 一切使わない。定数として、その意味を言語化する
こうして、自分を律し、一歩ずつわかりやすいコードを書き続ける体験を重ねた結果、私の頭の中には一つのメンタルモデルが形成された。
そのメンタルモデルとは、「コードの効率性（実行速度）は二の次で、認知効率性（読みやすさ）を最優先する」という、凡庸なエンジニアにとっての最強の生存戦略だ。
結論：“自分の痕跡”は、不要な負債である
コードは、作者の個性や「自分のやり方」を残すためのアートではない。 それは、組織の資産であり、未来のエンジニアへの引き継ぎ文書だ。
自分が「すごい」と思われたいという承認欲求のために、読者に認知負荷という負債を押し付けてはならない。
シニアになった今、私が目指すのは、自分の痕跡がどこにも残っていないコードだ。 「誰が書いてもこうなる」という、あまりにシンプルで、退屈なほどの当たり前。
自分のプライドを捨て、チーム全体のわかりやすさという「土台」を優先すること。 これこそが、凡庸なエンジニアが、長期的に組織に貢献し続けるための、最も賢く、そして最も美しい生き方だと信じている。