コーディングが難しい部分なのか? AI時代におけるプログラミングの価値を議論する

ソフトウェア開発業界は現在、大規模言語モデル(LLM)の台頭により、根本的なアイデンティティの危機に直面しています。「コードは決して難しい部分ではなかった」という主張が一般的になりつつあり、これはソフトウェアエンジニアリングの真の難しさはプロダクトの発見、要件定義、およびステークホルダー管理にあり、実際のコードを書く行為は些細なことであるということを示唆しています。

この主張は非常に議論の分かれるものです。多くの人々にとって、それはプログラミングという技術に対する侮辱であり、他の人々にとっては、構文を入力する行為と複雑なシステムを設計する行為を区別するために必要な区別です。

コーディングが困難な技術であるという主張

高品質で信頼性が高く、保守可能なコードを書くことは、深い専門知識を必要とする熟練した技術です。コーディングが「簡単」であるという主張は、いくつかの業界の現実によって否定されています。

  • 経済的価値: 「10x developers」に対する歴史的な高い需要と高額な給与は、複雑なロジックを実装する能力が希少で価値のあるスキルであることを示唆しています。
  • 技術的深さ: The Art of Computer ProgrammingStructure and Interpretation of Computer Programs (SICP) のような基礎的な文献の存在は、「些細な」作業をはるかに超える理論的および実践的な複雑さを示しています。
  • システムの安定性: バグの蔓延とレガシーシステムの保守の難しさは、実装がめったに単純ではないことを証明しています。
  • 「天才」の要因: 業界は、John Carmack や Fabrice Bellard のような個人を、ステークホルダーと話す能力ではなく、その並外れた技術的な実装スキルによって評価し続けています。

反論:コーディング vs エンジニアリング

多くの経験豊富な開発者は、「コードは決して難しい部分ではなかった」というフレーズは定義の問題であると主張しています。彼らは「コーディング」(既知の解決策を構文に変換する行為)と「プログラミング/エンジニアリング」(問題を解決する行為)を区別しています。

コーディングは翻訳である

ある問題が技術的な仕様に完全に分解された後では、コードを入力する行為はプロセスの中で最も簡単な部分であると主張する人もいます。この見方では、コーディングは外科手術における最後の「切開」に似ています。不可欠な最終ステップですが、それは99%の重要な意思決定の後に続くものです。

「非コード」作業の複雑さ

組織的な観点から見ると、ボトルネックはコードの行数そのものではなく、むしろ以下のようなものです。

  • 要件の曖昧さ: 顧客が実際に何を必要としているのかと、彼らが言いたいことの差を理解すること。
  • アーキテクチャとモデリング: 自身の複雑さによって崩壊することなく進化し続けられるシステムを設計すること。
  • 分散システムの課題: CAP theorem のトレードオフ、クロック同期、および exactly-once delivery の管理。
  • 組織的な整合性: 複数のチームやステークホルダーが方向性に合意するように調整すること。

"コードを書くことは難しくありません。正しいコードを書くことは難しいのです。支払う顧客がいる環境で何が正しいかを判断することは、一般的にそれらの顧客との対話を含みます。"

AIが開発者の役割に与える影響

LLMは、開発者が時間をどのように使うかというシフトを加速させています。AIが数千行のコードを生成できる一方で、それは「難しい部分」をさらに上位のスタックへとシフトさせる新しい複雑さを導入します。

書くことから検証することへ

開発者は、コードの作成者から、エディターやアーキテクトへと移行しつつあります。課題はもはや関数を書くことではなく、AIが生成したコードがセキュリティの脆弱性やアーキテクチャの乖離(architectural drift)を引き起こさないようにするための、ハーネス、アーキテクチャ仕様、および検証システムの設計です。

「Vibe Coding」のリスク

「vibe coding」に関する懸念が高まっています。これは、開発者が基礎となるメカニズムを理解せずに、動作しているように見えるコードをAIで生成することです。これは、開発者がシステム内でのデータの流れや、なぜ特定の設計が選ばれたのかを説明できない、脆弱なコードベースへとつながります。

激変する時代を生き抜く方法

価値を維持し続けるためには、開発者は技術的な深さと、ビジネスやユーザーエクスペリエンスへのより広い理解のバランスを取らなければなりません。

シニア開発者へ

技術的な専門知識を深めるだけでは不十分です。シニアは、ユーザーエクスペリエンス (UX)、顧客インタビューの技術、およびビジネス戦略といった隣接分野に投資すべきです。機能が「なぜ」構築されているのかを理解することは、それを「どのように」構築するかを知ることと同じくらい重要です。

ジュニア開発者へ

構文の自動化が進んでも、基礎知識は依然として重要です。ポインタ、メモリ階層、ネットワークプロトコル (HTTP)、およびデータ構造を理解することは、AIが生成したハルシネーション(hallucination)をデバッグし、効率的なシステムを設計するためのメンタルモデルを提供します。

不変の変数

ツールセットに関うわらず、ソフトウェアに関する特定の真実は変わっていません。

  • エントロピー: Bit-rot とソフトウェアの複雑さは常に増加します。
  • ユーザーの曖昧さ: ユーザーは、自分のニーズを articulate する(明確に伝える)ことに引き続き苦労するでしょう。
  • メンテナンス: ソフトウェアは、長期的な保守と進化のために、常に人間の判断を必要とします。

最終的に、目標は「判断力、共感力、およびセンス(taste)をAIにアウトソーシングすること」を避けるです。最も成功する開発者は、システムの深い理解と、ユーザーの課題に対する深い理解の橋渡しができる人々です。

Sources

関連