「コードを書くのは簡単」という言葉は、すべてのプログラマーへの冒涜だ

「コードを書くこと自体は難しいことではない」という言説は、開発という複雑なプロセスを過小評価しており、現場のプログラマーに対する敬意を欠いた発言である。ソフトウェア開発の本質は単なる実装ではなく、仕様の理解、技術選定、保守性、そして予測不能なエッジケースとの戦いにある。このフレーズは、プログラマーが日々積み重ねている泥臭い努力を無価値なものと決めつける傲慢な意見に他ならない。

「コーディングが簡単なら、なぜプログラマーは長年高い需要があって、高給を要求できたのか？（ZIRPのずっと前から）」

それは、プログラマーが本来コードを書くために不可欠な、目に見えない別の帽子を被らざるを得ない状況が多かったからだよ。コードを書くこと自体は難しくない。でも、正しいコードを書くのは難しい。金銭を払う顧客がいる現場で「何が正しいか」を知るには、その顧客とやり取りしなきゃいけないんだ。直接、あるいはもっと悪い形でね。優秀な社員に支払われる巨額の給与は、コードを書く能力への対価じゃない。顧客を徹底的に問い詰めて、ようやく本当の要件を引き出す能力に対するものなんだ。

「コーディングは簡単」という問いに対する答えは、Leslie Lamportの言葉を借りるなら「コーディングはプログラミングではない」ということだね。

自分のアイデアをプログラミング言語にエンコードするのは簡単。でも、そのアイデア自体がダメなものだと理解するのは難しい。

バックエンドに複数のデバイスが同時に接続し、パートナーシステムとのやり取りを仲介しなきゃいけないクライアントを抱えている状況を想像してほしい。相手のバージョンは古いまかもしれない。これは分散システムだ。最後に分散システムの教科書を開いたのはいつ？

最後にシステムを構築して、突きつけられた現実に直面したのはいつ？

• クロックを信用できない
• CAP定理の2/3を選ぶ必要がある
• Exactly-once（厳密な一度だけの配信）は不可能
• 稼働を止めずにコードを修正してリリースしなきゃいけない
• ハッカーは楽しみや利益のために攻撃してくる
• マネージャーは上記の解決に時間をかけるのを嫌がる

コーディングなんて一番簡単な部分だよ。

同意だ。「開発者はコードなんて書いていない」みたいなAI擁護論はかなり馬鹿げていた。あと、開発が今後さらに難しくなるという点にも同意する。AIコーディングツールを使いこなした人ならわかるはずだけど、生産性は爆発的に上がる。でも、今度は記憶力が乏しくて落ち着きのないAIという名の「コーダー」たちを、道から外れないように導き、セキュリティ事故を防ぎ、要件と全く噛み合わないものを作らせないように管理しなきゃいけない。もしそれができれば、10倍の成果は出る。でも結局、コードを書く代わりに、コードをガイドするためのハーネスやアーキテクチャ仕様、エージェント構造の構築、統計的なサンプリング、形式検証システムの構築に追われることになるんだ。

「コーディングはもともと難しい作業じゃなかった」なんて言っている連中は、自分の無能さを露呈しているだけだよ。コーディングが「難しく」なかったのは、ほとんどの組織が「本当に難しい」技術的課題に取り組もうとしなかったからに過ぎない。これはプログラミングの基礎や技術の性質ではなく、ビジネス戦略と文化の問題だ。

結局、プログラミングという作業はレバレッジが非常に高いため、技術的に些細で低品質なコードでも経済的には莫大な価値を生むということだ。これは変わらないだろうけど、LLMがそれを格段に安くするかもしれない。（それは大半の人にとって素晴らしいことだ！でも、大量のクソコードが残した悲惨なデバッグやメンテナンスを押し付けられる未来には、全くワクワクしないね）

それに、本質的に難しいプログラミングというものは依然として大量に存在する。これもどこにも消えない。LLMはそこでも役立つけど、現状では斬新で高度な技術的仕事に必要な専門知識を置き換えるには程遠いよ。

理想的な世界では、平凡なコードを安く作れるようになれば、もっと難しい技術的課題に取り組む余裕が生まれるはずだ。でも現実は、常にプログラミングの本質よりも、文化・リーダーシップ・信頼・リスク許容度といった非技術的な要因に左右されてきた。でも、少なくとも今は、LLMの過熱ぶりを口実にして、本来価値があるのに非技術的な上層部にとっては不確実だったり長期すぎたりして手を出せなかった、より深い技術的課題に取り組むチャンスに変えられるかもしれない。

あと、「コーディングはもともと難しいものじゃない」みたいな戯言はもうやめよう。

コードを書くことの方が明らかに簡単だという仕事もあると思う。全員が全員、信号処理や組み込みシステムを扱っているわけじゃないし、会社のデータセンターのためにLinuxカーネルのメモリ割り当て最適化を上流へプッシュしなきゃいけない環境にいるわけでもないからね。

顧客の要求を調整し、市場のニーズと会社の戦略の両方を満たすものを作るのは、信じられないほど難しくてフラストレーションが溜まる問題だ。戦略の実行まで監督しなきゃいけないなら尚更だよ。彼らが何を欲しているかを予測したり、彼らが口にする要求が真のニーズとは違うと見抜けるほどドメイン知識を深く理解するだけでなく、そのソリューションを企業という環境の中で実行に移す計画まで練らなきゃいけないんだから。

『Staff Engineer's Path』のような本が、局所的な最適解やコミュニケーション、計画実行のための合意形成といったトピックを扱うのには理由がある。大企業で複数の国際的な顧客を抱える環境では、コードなんて大抵の場合、一番難しい問題じゃないんだ。

コーディングは決して簡単じゃないけど、一番難しい部分だったこともないね。

一番難しいのは、常に「どうやって問題を解決するか」という部分だ。コーディングはその最後の仕上げで、簡単ではないにしても一番の難所ではない。

『The Art of Computer Programming』という本はコーディングの本じゃなくて、コンピュータサイエンスの本だ。つまり、いかにして問題の解法を導き出すかを扱っている。

とはいえ、「何を作るか」を突き止めるのが難しいわけでもないけどね。

「コードはもともと難しいものじゃなかった」というナラティブは、デザイナーやMBA持ち、プロダクトマネージャーたちが強く推し進めてきたものだ。彼らはAI以前から、プログラマーを下層階級のように扱い、自分たちより格下で、コモディティ（商品）のように簡単に代替できるものだと思ってきた。皮肉なことに、今一番入れ替わっているのはプログラマーじゃない。プロダクトチーム全体やデザイナーが次々と置き換えられている。優秀なコーダーは今も需要があるんだ。なぜなら、AIが書いた「それっぽい」散らかったコードの後始末をする人が必要だからさ。デザインには善し悪しの明確な基準がない。デザインが好きか嫌いかだけだ。でもコードは、動くか動かないかのどちらかだ。だから、デザイナーに比べてプログラマーを置き換えるのが常に難しいんだよ。

Claudeやその類がプログラマーを置き換えたか？いや、そんなことはない。置き換えるまでには長い時間がかかるだろう。なぜなら、コードの方向性や、その上に築くべき基礎アーキテクチャを指示する誰かが依然として必要だし、それには本物の人間の経験が必要だからさ。

これはLLM登場後のコーディングのロマンチシズムのように感じる。「Show HN」の投稿で、「週末でTwitterを作れる」なんて言っている人がLLM以前からたくさんいた。LLM以降、そういう発言はむしろ増えている気さえする。

既存のものを見て、要件がすべて定義されていて、エッジケースがすべて決まっている状況であれば、コーディングは確かに簡単な部分だっただろう。人々が「燃え尽きた」のは、SQLを書くのが難しかったからじゃない。要件が絶えず変わり、要求は増え続け、エッジケースが常に発生していたからだ。

「何を作るか決めるのが難しいなら、なぜプロダクトマネージャーたちは無能そうに見えるのか？なぜ彼らには厳格な10段階面接がないのか？」

自分以外はみんなバカだと思っている典型的なエンジニアの意見だね。多くの人がLeetCodeを知的勲章のように見なすようになったけど、実際のところ、あれが文化的な儀式に過ぎないことや、仕事で書くコードが面接のような作業を反映することは滅多にないということを、みんなわかっているはずだ。

コーディングが簡単だとは言わない。苦労している人はたくさんいる。でも、仕事という側面で見れば、JIRAのチケットをひたすら消化するだけのジュニアでない限り、コーディングは仕事の中で最も簡単で、かつ最もやりがいのある部分だったんだよ。

筆者はこの観測の意図を見誤っているかもしれないね。

私や「コードはもともと難しいものじゃなかった」と言った多くの人が指しているのは、個人のスキルについてじゃない。ソフトウェア開発というエンジニアリング・プロセスにおいて難しい部分ではない、ということだ。プログラミング言語にはマニュアルがある。データ構造の多くはしっかりドキュメント化されている。あらゆるものに対してフレームワークが存在する。コードを書くこと自体の難易度はプログラマーのスキルや問題ドメインの複雑さによって変わるけれど、コードを書き、理解することは扱いやすく直接的な問題だ。私は多くの人に教えてきたし、人には学習能力がある。

多くの人が言いたいのは、ソフトウェアを作る上で一番難しいのは、組織が生産過程で行わなければならないあらゆる調整作業だということだ。組織にとって一番難しいのはコードを書くことじゃない。全員に問題を理解させ、協力し合い、要件を収集し、仕様を開発し、リリースを検証し、テストすること……。それはまるで猫を並べるような作業で、おそらくコードを書くことよりも難しい。

違う、それはあなたが単なる構文以上の存在であるという意味だ。

構文を生み出すボットを作っても、それはプログラマーを作ったことにはならない。

ギグプラットフォームの開発者や海外の契約社員のように、成果物がコードファイルというだけで、構文と1対1の仕事をしている労働者もいる。

でも、スタッフ・ソフトウェア・エンジニアの成果物はソフトウェアであり、斬新なアウトプットであり、会議での顔であり、すべてがうまくいかなくなった時に責任を取る誰かであり、チームの一員であり、コーヒーを飲みながら新しい扉を開くような隣接した話をできる相手であるべきだ。営業的な側面で言えば、人に統合を納得させるための出張や、飲み会や対話といった対人スキルも重要だ。GitHubでの苛立ったコントリビューターとの思慮深く、時に感情的なやり取りが革新を生むこともある。これらすべてが、言語モデルが決して真似できない価値なんだ。

さらに言うなら、仮にAIが感情的知性や世界全体をモデル化したとしても、もしAIに「一線を越えたら殴れる顔」がなくて、そしてそれが自分に顔があることを自覚し、それが自分にとって何を意味するのかを理解していなければ、共感という点では常に及第点には届かないだろう。私たちの共感や感情は、野生の中で、恐怖や食料を追い求めるスリル、他者との遭遇、そして今この瞬間の自分の行動の結末を理解する過程で生まれたものなんだから。