필사 모드: コードは難しい部分ではなかったという言葉が、なぜあれほど腹立たしいのか

• 会議でその文が出ると部屋の温度が変わります
• 元記事が投げかけた問い
• 腹立たしい本当の理由は語のすり替えです
• だからといって反対側がすべて正しいわけでもありません
• コードを三つの層に割れば論争は終わります
• 自分のチームがどの層に時間を使っているか測ってみる
• 層ごとに道具の値打ちが違います
• では何を練習するのか
• 参考資料

会議でその文が出ると部屋の温度が変わります

四半期の計画会議で誰かがこう言います。「もうコードを書くのは難しい部分ではないので、私たちは何を作るかにもっと集中すればいいのです。」

言った人は善意だったのでしょう。ところがエンジニア側の表情が固まります。反論しようにも適当な文が思い浮かびません。「コードも難しいです」と言えば防御的に聞こえ、そのまま流せば来期の人員計画にその前提がそのまま入ります。

元記事が投げかけた問い

2026年8月8日に公開されHacker Newsで大きく議論された記事で、Senko Rašićはこの文を正面から受けます。彼のやり方は論証ではなく問いを投げることです。

コーディングが簡単なら、なぜプログラマーの需要があれほど高く、賃金があれほど高かったのか。コーディングが簡単なら、なぜClean CodeやThe Pragmatic Programmerのような分厚い本が存在するのか。コーディングが簡単なら、なぜ人は自分のコードが複製されることに腹を立てるのか。そして向きを反転させて、何を作るかを決めることが難しい部分なのなら、なぜあれほど多くのプロダクト担当者が手探りに見えるのか。

結論は二者択一を拒む側です。両方でなければならない、というものであり、理解と判断と共感と目利きをAIに外注するなという文で終わります。

腹立たしい本当の理由は語のすり替えです

この反論に同意しつつも、なぜその文がとりわけ腹立たしいのかは少し違う説明ができます。問題は真か偽かではなく、単語が途中で意味を変えるという点にあります。

「コードは難しい部分ではない」という文で、コードは最初に狭い意味で登場します。文法を知り、APIを調べて打ち込むことです。この意味なら文は正しいです。そして会話が進むにつれて同じ単語がそっと広がります。結論に至るころにはコードはエンジニアリング全体を指しており、そのため「エンジニアリングは難しい部分ではない」という命題が、誰も証明しないまま通過します。

聞く側が腹を立てるのはこの通過のためです。反論するにはまず単語を戻さなければならないのですが、会議中にそれをやろうとすると話が長くなり、そうしているあいだに議論は次の議題へ移ります。

この構造は他の職種でもまったく同じように働きます。「デザインはもう簡単だ」という文でデザインが最初は案を作ることを指していたのに問題定義まで飲み込み、「文章を書くのはもう簡単だ」で文章を書くことが文を整えることを指していたのに論証の組み立てまで飲み込みます。毎回同じ場所で同じやり方で議論がずれるのに、ずれる地点が単語にあるという事実はあまり指摘されません。

だからといって反対側がすべて正しいわけでもありません

ここで釣り合いを取らなければなりません。元の文にも真である部分は確かにあります。

何を作るかを決めることは実際に難しいです。関係者ごとに欲しいものが違い、彼らが言うことと必要なことが違い、要求は作っている途中で変わります。この領域での失敗は、コードがどれほどよくても回収されません。よくできた不要な機能は、ただのよくできた浪費です。

ですからこの論争を「コードが難しい対 要求が難しい」へ引っ張っていくと、双方が半分ずつ正しい場所で終わらず、互いの半分を認めないまま繰り返されます。抜け出す方法は単語を割ることです。

コードを三つの層に割れば論争は終わります

コーディングとひとくくりに呼ぶ活動は、少なくとも三つの層に分かれます。

この区別を入れると、二つの主張がそれぞれどこで真なのかが即座に見えます。コードは難しい部分ではないという言葉は、1層については強く真であり、2層については部分的に真であり、3層については根拠がありません。そして元の文が腹立たしい理由は、1層の真を3層まで引っ張っていくからです。

自分のチームがどの層に時間を使っているか測ってみる

この区別が有用なのは、測れるからです。論争を勘でやらないためには、自分のチームの分布を知る必要があります。

2週間の実験: 完了した作業ごとにタグをひとつだけ付ける

L1  大半の時間を文法、API、定型的な変換に使った
L2  大半の時間を構造と境界と制約を決めることに使った
L3  大半の時間を不変条件、失敗の様相、移行を検討することに使った
RQ  大半の時間を何を作るかを突き止めることに使った

2週間後に四つの数字を見る。論争の代わりにこの分布を置いて話す。

やってみるとたいていチームごとに結果が大きく違います。新規サービスを作るチームはL1とRQが高く、10年もののシステムを維持するチームはL3が圧倒的です。そしてこの分布が違うために、二つのチームは同じ文を聞いてもまったく違う反応をします。片方にとってその文は事実であり、もう片方には自分の仕事がまるごと消された言葉に聞こえます。

タグは作業ひとつにひとつだけ付けることが重要です。複数を許すと全部に三つずつ付いて分布が消えます。どの層にいちばん時間を使ったかをひとつだけ選ばせると、曖昧な作業ほど選ぶ過程で自分が何をしたのかを自分で整理する効果も生まれます。2週間で足りなければ4週間に伸ばしつつ、結果を個人の評価に使わないことを先に約束しなければ数字が正直になりません。

層ごとに道具の値打ちが違います

分布を知ってしまえば次の決定が楽になります。AI道具の値打ちも層ごとに違うからです。

1層では値打ちが大きいです。ここには論争の余地があまりなく、実際に生産性向上の実感の大半はここから出ます。2層では値打ちが条件付きです。制約を明示的に与えられればよい案を複数もらえますが、制約を言葉に移せなければ無難な既定値が返ってきます。3層では値打ちがもっとも小さいです。不変条件と失敗の様相のかなりの部分がどこにも書かれておらず、人の頭のなかにしかないからです。

ですから3層が厚い組織で「コードはもう簡単だ」を前提に人員計画を立てると、まさにその組織がもっとも大きく傷つきます。逆に1層が厚い組織で道具の導入を遅らせるのも損です。同じ文が組織ごとに違う処方につながらなければなりません。

では何を練習するのか

元記事の結論は、理解と判断と共感と目利きを外注するなというものでした。層の区別を載せると、この助言はより具体的な行動になります。

3層は文書化へ移せる部分が思ったより多いです。不変条件をコードのコメントではなく実行可能な検査にし、既知の失敗の様相をランブックに書き、移行経路を決めるときに捨てた代案を残します。これは道具のためではなく人のためです。頭のなかにしかない知識はその人がチームを去れば消え、その瞬間に組織の3層は本当に空になります。

2層は練習の仕方が少し違います。この層の実力は制約を言葉に移す能力とほぼ同じなので、実装を始める前に守るべき条件を一覧に書き出す習慣がそのまま訓練になります。条件を書けないなら、まだ問題を理解していないということであり、その状態から出た成果物は誰が作ったにせよ検討が不可能です。

そして会議に戻って、次にその文が出たらこう問い返せばよいのです。どの層のお話ですか。この問いひとつで会話は感情の問題から計画の問題に変わり、部屋のなかの誰も自分の仕事を弁護する必要がなくなります。

参考資料

• "Code was never the hard part" is an insult to all programmers — Senko Rašić, 2026-08-08 — 本文に引用した問いと結論は、この記事の内容です。
• Hacker Newsの議論 — 反対側の意見がかなり多く付いており、その反論も併せて読む価値があります。
• このブログの関連記事: 摩擦が消えると目利きが残るのではなく、目利きを育てる道が消えます
• 三層の区別と2週間の実験は元記事に出てくるものではなく、私が整理した枠組みです。