世界を動かす技術を、日本語で。

「コードは決して難しい部分ではなかった」というのは、すべてのプログラマーへの侮辱である

2026年8月8日原文(blog.senko.net)

概要

  • AI革命 が進行中で、ソフトウェア開発職も大きく変化
  • 「コーディングが簡単」という見方への 反論 とその根拠
  • コーディングと企画・顧客理解の 両立の重要性 を強調
  • 変化に適応し続けることの 必要性
  • 自己理解・責任感 をAIに委ねない姿勢の推奨

ソフトウェア開発職の現状と誤解

  • AIの登場により ソフトウェア開発業界 が大きく揺れている現状
  • 「コーディングは簡単」という意見への 疑問提起
    • 高い需要と高給、過労や燃え尽き症候群の実態
    • Clean CodeやThe Pragmatic Programmerなど 分厚い専門書 の存在
    • Bootcampや大学の 専門教育 の必要性
    • CarmackやFabrice Bellardのような 天才プログラマー への評価
    • AIや他者による コードのコピー への反発
    • コーディングが簡単なら バグだらけのソフトウェア がなぜ多いのか
  • 「何を作るか決めるのが難しい」という意見への 検証
    • プロダクトマネージャーや市場調査担当への評価の低さ
    • 「顧客理解」が難しいならなぜ ビジネスアナリスト は軽視されるのか
    • 営業が新機能を約束した際の エンジニアの不満 の矛盾
    • コーディングが簡単なら バリエーションを量産 すればよいはず

ソフトウェア開発における本当の難しさ

  • 多くの開発者は 顧客やステークホルダー との対話を好まない傾向
  • 「優先順位の明確化」=「指示がコロコロ変わらなければいい」という現実
  • 「問題解決が仕事」と言いながら 技術的議論 に夢中な開発者の矛盾
  • 「ソフトウェア開発は理論構築」とする意見の存在
  • 顧客理解と 技術的熟練 の両立の難しさ

両立の重要性と今後の展望

  • ユーザー理解と 良いコード の両立がプロジェクト成功の鍵
  • 「コーディングは簡単」「コードは芸術」の 極論 は現実逃避
  • 変化の真っただ中で 適応力 が不可欠
  • LLMやAIの流行に盲従する必要はないが、 変化を認識 し備えることが重要

変わらないもの・変わるもの

  • 変わらないもの
    • ソフトウェアは今後も 複雑化
    • メンテナンスや ビットロット、エントロピーの存在
    • 技術の進化と 抽象化の進行
    • ユーザーの要求水準の上昇と 伝達の難しさ
    • 顧客とユーザー、ビジネスと顧客の ギャップ
    • 時代の流行 や「スネークオイル」の存在
  • 変わるもの
    • パンチカードやCOBOLなど 古い技術の消滅
    • 過去の技術的苦労の 価値の変化
    • 新旧技術の 世代交代

成長・適応のための行動指針

  • 変化を受け入れ、好奇心と批判精神 を持つこと
  • 技術・経済・社会の 変化のスピード を常に俯瞰
  • 隣接分野 (UX、顧客インタビュー、ビジネス戦略など)への理解を深める努力
  • ジュニア開発者は 基礎技術 (ポインタ、再帰、ネットワーク、アルゴリズム)の習得
  • なぜ・どうして を恐れずに追求
  • 推奨書籍例
    • Structure and Interpretation of Computer Programs
    • Cracking the Coding Interview
    • The Mythical Man-Month
    • Working Backwards
    • Team Topologies
    • 7 Powers
    • The Soul of a New Machine
    • Obviously Awesome
    • The Design of Everyday Things
    • Don't Make Me Think
    • Continuous Discovery Habits
    • The Mom Test

最後に

  • 理解・判断・共感・センス をAI任せにしない姿勢の重要性
  • 責任感 を放棄せず、「ただの肉体的な代理人」にならない自覚

Hackerたちの意見

コーディングが簡単なら、どうしてプログラマーはずっと需要が高くて、高い給料をもらっているの?(ゼロ金利政策の前からでも)それは、プログラマーがコードを書くために必要な、見えない追加の役割を担わされているからだよ。コードを書くのは難しくないけど、正しいコードを書くのは難しい。お金を払う顧客がいる環境では、何が正しいのかを理解するために、その顧客とやり取りする必要がある。直接的に、あるいはもっと面倒な形でね。最も生産的な社員に支払われる巨額の給料は、彼らがコードを書く能力によるものじゃない。顧客に徹底的に質問して、真の要件を引き出す能力によるものなんだ。

コードを書くのは難しくない。正しいコードを書くのは難しい。お金を払う顧客がいる環境で何が正しいのかを理解するには、顧客とやり取りする必要がある。これは「車を作るのは難しくないが、使える車を作り、規制をクリアするのは難しい」と言っているようなものだよ。つまり、コーディングは合理的な文脈では難しいんだ。

最も生産的な社員に支払われる巨額の給料は、彼らがコードを書く能力によるものじゃない。顧客に徹底的に質問して、真の要件を引き出す能力によるものなんだ。それは、私が知っている開発者たちには当てはまらないし、特に昔はそうだった。顧客に質問して要件を引き出すのは、マネジメントの仕事だった(彼らも高い給料をもらってたけど)。

直接的に、あるいはもっと悪い形で。うわ、まるで「殺人者が家の中から電話をかけている」みたいな雰囲気だね。でも、電話ゲームの問題は確かにあったと思う。最も重要な問題ではないかもしれないけど、かなり大きな問題だよね。

その通り。コードを書くのは簡単だよ。ジュニア開発者はいつもやってるし、実際、彼らはもっと多くのコードを書いて、早くやってる!私はジュニア開発者の半分のスピードだけど、私が書くコードは5年から10年も持つし、バグも一桁か二桁少なくて、長期的なメンテナンスの負担も少ないんだ。

僕の経験では、しっかり定義されたJIRAチケットをただコーディングするだけで「良い」給料をもらえるのは新卒だけだよ。これは基本的に、複雑で曖昧なプロジェクトを独立してリードできるようになるまでのトレーニング期間なんだ。そこに数年以上いるのは無理だよ。

コードを書くのは難しくない。正しいコードを書くのが難しいんだ。お金を払う顧客がいる環境で何が正しいかを知るには、顧客とやり取りすることが必要だよ。請求書:$1000 ボルトを一つ締めた:$1 どのボルトを締めるかを知ること:$999 > 最も多くの成果を上げる社員に支払われる巨額の給料は、彼らのコーディング能力によるものじゃない。顧客に徹底的に質問して、真の要件を引き出す能力によるものだよ。両方の要素があると思うけど、僕は本当にひどいコードを見てきたから、「ちゃんとコーディングすること」が確かに難しい部分の一つだと言える。でも、解決すべき本当の問題を知ることも重要だよね。(それって営業の仕事じゃない?顧客と一緒に本当に解決すべきことを引き出すことが。)

これを踏まえて、証拠として:もし世界で最高のプロダクトオーナーがいて、何かを作る方法について完全に明確で、すべての失敗の扱い方、すべてのトレードオフ、実装の詳細、リスクが明確であれば、プロダクトはシンプルになる。そうなれば、会社はトップクラスのエンジニアを雇わなくてもやっていける。でも、すべてのスキルや役割を一人の人間(スタッフ+エンジニア)にまとめると、当然高くつくよね。

人は、給料の額が仕事の難しさと関係があると思いがちだけど、実際はそうでもないよね。役割の市場価値には、実際の仕事の難しさ以外にも、需要と供給や資金源など、いろんな要素が影響してる。プログラマーが高い給料を要求できるのは、需要の爆発が供給の爆発よりも早かったからだと思う。プログラマーの仕事はコードを書く以上のものだけど、企業が本当に優れたプログラマーとそうでないプログラマーを見分けられるかは疑問だな。例えば、大企業の多くの人たちは、責任が抽象化されてるから、顧客のことを気にしなくても罰せられないような「チケットを取るだけのコードモンキー」としてやっていけることがあるよね。学校でも、教室に余分な努力をする教師と、ただ出勤して退勤するだけの教師を区別することはあまりないと思う。強いプログラマーは、必要とされる企業で報われると思うけど、どれだけの企業が実際にプログラマーの良い仕事に依存しているのかはまだ不明だね。

そもそも何を書くべきかを知るのが、私にとっては一番難しいことなんだよね。ずっとそうだった。

いや、要件を満たす方法を知るのが課題だったプロジェクトもたくさんあったけど、実際にコードを書くのは本当に難しかった。維持しなきゃいけない不変条件を持つ複雑なデータ構造、共有メモリへの分散アクセス、さまざまな形のフォールトトレランスに対処すること、そして何よりも、複雑なアルゴリズムを許容できる速度で動かすこと - これらはすべて、書かなきゃいけない特定の低レベルのコードの難しさにボトルネックされるんだ。それに、コードが最初に書かれたときには問題がなくても、数ヶ月後に新しい大きな機能を追加しようとしたときに、初期の決定が既存のコードベースにフィットするのを妨げるアーキテクチャの問題が出てくる。正直、そういったことを手伝ってくれるLLMがあって嬉しいけど、過去数十年で自分でそれをやるスキルを身につけたことも嬉しいし、今のプログラマーたちがそういったスキルを身につけられないのはちょっと悲しいな。

これらの「コーディングが簡単なら」という質問への答えは、コーディングはプログラミングじゃないってことだよ(ラモートの言葉を借りれば)。アイデアをプログラミング言語に変換するのは簡単だけど、自分のアイデアが悪いと理解するのは難しい。複数のデバイスが同時にバックエンドに接続して、パートナーシステムとのやり取りを仲介するクライアントがいるんだから。彼らのバージョンが最新でないこともあるし、分散システムだよ。最後に分散システムの教科書を開いたのはいつ?システムを構築して現実を直視したのはいつ? - 時計を信頼できない - CAPの2/3を選ぶ - 一度だけの配信は不可能 - コードはダウンタイムなしで変更・リリースする必要がある - ハッカーが楽しみや利益のために攻撃してくる - マネージャーが上記を正しくやるのに時間をかけてほしくない コーディングは簡単な部分なんだ。

Hacker Newsで議論の続きを見る