自分の思考の整理のため、コードを生みだすことの哲学と、審美眼について、人間のソフトウェアエンジニア（この言い方ウケる）としてやるべきだと感じていることを整理しておく。
2026年3月から、CPO/CTOを退任して、別の部署に異動してソフトウェアエンジニアをやっている。現場に戻る。みたいな話ではないけれど、AI開発が当たり前になりすぎてPdM/SWEどちらとしてもこれまでの作り方をアンラーンしないといけないと思う事が多い。
『無価値なコードを書くな』の前提が逆になった
LLM以前の時代は、コードを書くことはとても高価なことだった。Stack OverflowのJeff AtwoodはThe Best Code is No Code At All と言っていたし、37signalsもLess software 最高みたいなことを言っていた。どちらの記事も今でも正しい（いいこと書いてあったんだなと思う、20年前の記事だ...）。けれど前提条件は逆になっている。
昔は『コードを書くことは高価だから、価値のあるコードだけを書こう』というノリだった。乱暴に言うと、ゴミを作るな。コードのROIを考えろということだった。いまは前提条件が真逆になっていて、『コードを書くのが安すぎるから、価値のあるコードだけを書こう』みたいな感じだ。
そしてこれは、プロダクト開発全般に言えることで、昔は『検討/議論時間がもったいないから、議論自体をショートカットしよう』は圧倒的に正しかった。今はもう少しブレーキが必要で、『熟考して幅広く考え、積極的に議論する』ことの比重が上がってるように思う。議論をたくさんすることは（ある意味で）非効率で、摩擦(friction)を生むから、人間のやるべき仕事だからだ。
審美眼は直感ではないようだ
コーディングのほとんどをAIが担うようになって、ソフトウェアエンジニアにとって何よりも重要なのが美学や審美眼になったと思う。これはまあ、色々な人が言っていることだ。フワッとしているし、まあ改めて兜の緒を閉め直すかみたいな気持ちにはなる。
最近大事だなと思うのは、審美眼は直感ではないということだ。
むしろその逆で、審美眼とは好き嫌いや、パッと見て判断する力、みたいな話で決してなくて、蓄積した知識や文脈を元に、差異を見つける力だ。
ソフトウェア開発をビジネスにしている場合は、価値を生み出す差異を見つける力だといえるだろう。意味付けされた差異を見つけられれば、それを実現するのはとても簡単になった。
僕ら人間の役割は、意味のある差を発見・発明することになった。意味のない差を現実に実装しても、無価値の上に無価値が産み出されたり、いまある価値が毀損されるだけだ。そして、そういった無価値の連鎖が起こり負債になるスピードがあまりにも早くなりすぎたのだとおもう。
おもむろに人月の神話を引っ張り出すと、下記のような記述がある。
conceptual integrity is the most important consideration in system design.
概念的整合性（conceptual integrity）は、システム設計において最も重要な考慮事項である
It is better to have a system omit certain anomalous features … than to have one that contains many good but independent and uncoordinated ideas.
多くの優れたアイデアを、それぞれ独立したまま、互いに調和しない形で詰め込むくらいなら、多少例外的な機能をあえて省いたシステムのほうがよい
Brooksもこんなことを言ってたんだと妙に納得する。
これは設計論の話ととらえるのが自然だけれど、体験設計も含めた設計の話と拡大解釈しても差し支えないだろう。しっかり思考しないと見えないところまで考え抜いて差を見つけること＝審美眼を駆使することが整合した（体験）設計を持つシステムを作るためには大切だと思う。
普通の人が気づかないような細部の差（ボタンの文言一つ、説明の文言一つのレベルや、動線の配置などの細かい話も含めて）に、『神は細部に宿る』という古い格言を借りれば、普通の人が気づかない細部にまで神を宿さなければならない。
結局、ソフトウェア開発は簡単じゃなくて、簡単じゃないからこそソフトウェアエンジニアの仕事があるのだと思う（思いたいに近いかもしれない）。あり続ける、と言えないくらいAIの進化は早くて、その最前線にいれることを幸運に思う。
でも、同時にとても残酷な時代だと思う。
摩擦から生まれる手触り感と審美眼
昔ならば作る過程でコードやデザインと戯れながら、その差に価値があるかないかの手触りを確かめられたのに、いまはその手触りを失うことがあまりにも簡単だ。失敗しやり直し、試行錯誤することすら、とても難しくなっているように感じる。少なくとも、手なりで開発している限りにおいては。
周辺領域としてのデザインではこの手触り=試行錯誤のプロセスは、見ることと動くことの往復運動(seeing–moving–seeing)と言われるらしい。
見る→課題を見つける→変更する→また見る→新しい意味を見つける→変更する→...
この繰り返しをして、見るたびにパターンに意味を見いだして、課題が解かれる妥当なところで止めるのだ。
ソフトウェア開発だと、課題見つける→課題を解決する仕様を考える→実装する→動かす→動かなくて困る→実装する→...→違和感を覚える→書き直す→...みたいな一連の流れがあった。別の観点から見ると、実装が難しい（高コスト、それなりに時間がかかる）→ 軽くできないか選別する / 考える / 議論する といった流れがあった。
物理的に手を動かさなければコードは書けなかったし、時間もかかったし、（リモートじゃない時代は）議論も大変だった。たくさんの摩擦(friction)があった。摩擦の中で手触りを掴んでいった気がするし、摩擦があるのが自然だった。何もしなくても摩擦に遭遇するから、その中に放り込まれていれば、意識しなくとも手触り感を得ることができたし、手触り感を審美眼に昇華させることも今より自然に起きていた。 ※この辺の話はAgentic Software Development Created New Friction Points—Where to Find Them, How to Fix Them とか The Collapse of Productive Frictionからの受け売りみたいなところもあるかもしれない。曖昧さのコストみたいな話がされていて面白い記事だ。
なんだか、あらゆるものを全部人手でレビューしなければいけなかった時代が懐かしい。
AI時代は、摩擦は意識しないと手に入らなくなった。 コードよりも摩擦のほうが貴重になった。より多い摩擦はより多くの差異（のきっかけ）を生みだして、審美眼を延ばすための経験値になる。これまでは、摩擦はとても非効率だった。だから摩擦を避ける方が早く進んだ。 今は少し変わって、摩擦を積極的に取り入れなければいけなくなった。とはいえ、摩擦は（ある意味で）非効率だ。
効率化の延長線上に卓越があるとは限らない。60点を高速に作り続けても、その線をどれだけ伸ばしても100点には届かないことがあると思う。 100点は、少し立ち止まり、遠回りし、議論し、試して、捨てるという別の探索過程から突然現れるんじゃないか。
非効率のフロンティア
真剣なものづくりは効率性だけでは測れない。宮崎駿が世の中の大切なことって大抵めんどくさいと言ったのは有名だけれど、卓越した価値を生みだすためには一定のめんどくささが必要なのだと思う。効率が低すぎれば無駄が多く、逆に高すぎれば探索・対話・試行錯誤が失われる。非効率には卓越を生みだすフロンティアがあると思う。
AI時代、むしろその非効率さこそが重要で、どのように非効率で、どういう摩擦があるのかはプロダクト開発組織（や会社）の構造や運営方法に依存していると思う。
そのうえで、一定の非効率を受け入れる土壌をつくり、摩擦を卓越した価値に変換できるような点＝非効率のフロンティアにチームを保たないといけない。 人手で（パワポで）作った図で表すとこういうイメージだ。効率化の果てには60点しかない。
大変な時代だけれど、考えたものをいくらでも生み出せる時代に生きることができて、エンジニアとしては今が一番楽しい。楽しすぎるだろうというくらい。その中で、卓越したモノを生みだしていきたいと思う。
