HN 日本語サマリー

← 一覧へ戻る
キャリア

「職人プログラマー」と自称するのをやめよう

Don't call yourself an artisanal programmer (purplesyringa.moe)

19 pointsby emschwartz19 コメント

要約

この記事は、ソフトウェア開発における「職人プログラマー」という言葉の使われ方と、それが本来のエンジニアリングの精神と乖離している現状を論じています。著者は、コードの信頼性や正確性を重視する姿勢こそがエンジニアリングの本質であり、AIツールへの依存が進む中で、この本質が失われつつあることに警鐘を鳴らしています。

全文翻訳

「職人気質(アーティザン)」プログラマーを名乗らないでください

2026年9月13日

以前から書きたいと思っていたことについて、あるテーマに深入りしてしまい、自分がそれに影響されるようなプロパガンダの対象になってしまったのではないかと、今では少し怖くなっています。

ソフトウェア開発のAIに関する議論でよく見られるのは、「最終結果を最も重視する『真面目な』エンジニア」と、「最終製品よりもコーディング体験を重視する『職人気質(アーティザン)』コーダー」という二項対立です。この二項対立は、私自身やおそらく多くの他の人々を正確に描写するものではありませんが、ここではひとまずそれに乗っかってみましょう。

私はプログラムに信頼性を持たせたいのです。そのためには、忍耐と注意深さが重要な要素です。プログラムを一から設計し、時間をかけることで、それが正しいと「確信」でき、どんな間違いもタイプミスによるものだとわかります。単体テスト、LLMレビュー、証明器はコードが99%正しいことを保証できますが、100%正しいこと――つまり、最適で、保守可能で、読みやすく、文書化されていない準拠しない動作に依存せず、またそれによって壊れないこと――は保証できません。私はその100%を求めています。これを達成するには、コードとの深い繋がりが必要ですが、LLMは私を重要な低レベルの詳細から切り離し、構築による正しさを保証できないため、私はLLMの使用を拒否します。

対比

ここで、二項対立が私の目には崩壊します。本質的には、私は職人気質(アーティザン)のコーダーです。なぜなら、LLMを使用しないからです。しかし、業界が「職人気質プログラマー」の対義語を「ソフトウェアエンジニア」と呼ぶなら、私はエンジニアではないという含みがあるのではないでしょうか。これは些細な点に見えるかもしれませんが、無意識のレベルでは重要です。注意深さ、配慮、そして精度こそがエンジニアリングの決定的な特徴です――なぜこの言葉が、ますますマネージャーに近づいている人々に横取りされてしまうのでしょうか?

昔は(ええと)、開発者は技術的負債の処理に時間を割かないマネジメントを嫌い、「速く動いて壊せ」という姿勢は幼稚だと考えられていました。今日では、開発者の間では「バイブコーディング」(ここでは緩い意味で使います)が一般的であり、信頼性作業に時間を費やすのは真面目ではない、というのが常識になっています。どちらが正しいのでしょうか?

用語の再定義

私にとって、答えは明白です。ものを無造作に構築することで、ソフトウェアエンジニアの称号を得ることはできません。エンジニアは自分が何をしているかを知っているべきです。しかし、このトピックについてより知識のある人に聞いてみましょう。

2021年、Hillel Wayneはクロスオーバープロジェクトを実施し、他の工学分野からソフトウェアエンジニアリングに転身した多くの人々にインタビューを行いました。彼の目標は、「両方の分野で実際の経験を持つ人々は、私たちの仕事をエンジニアリングと見なすか?」という問いに答えることでした。答えは「はい」でしたが、私がより興味を持っているのは次の部分です。

それでも、多くのクロスオーバーした人々は追加の資格を加えていました。ソフトウェアエンジニアリングは本物のエンジニアリングですが、ソフトウェアを書いている多くの人々はソフトウェアエンジニアリングを行っていません。これは彼らの問題ではなく、私たちの分野の問題です。私たちがやっていることを話すための語彙が十分に豊かではありません。電気を扱う人すべてが電気技師になるわけではありません。多くは電気工(electrician)になります。そして、それは問題ありません。[…] しかし、私たちは「プログラマー」「ソフトウェアエンジニア」「ソフトウェア開発者」といった言葉を互換的に使っています。ソフトウェアエンジニアとソフトウェア開発者の違いは何でしょうか?「ソフトウェアクラフトマン」という言葉を提案する人もいます。

私が注目するのは、Wayneが使用する肩書きが、現在人気のあるものと完全に逆であることです。彼は、気配りをする人々、つまり今日私たちが「職人気質(アーティザン)コーダー」と呼ぶ人々を「エンジニア」と呼び、その反対に、私たちが「バイブコーダー」と呼ぶ人々を「クラフトマン」と呼んでいます。少なくとも私には、こちらの方が直感的で分かりやすい命名です!手書きでコードを書くよりも、プロンプトエンジニアリングの方が芸術的と言えるかもしれません。

「職人気質(アーティザン)」は、「バイブコーディング」の対義語として歴史的に意味がありましたが、この言葉を主張することで「エンジニア」という言葉が自由になり、バイブコーディングがエンジニアリングの一形態であるかどうかの議論を事実上放棄してしまいました。バイブコーディングは明白なデフォルトとなり、職人気質(アーティザン)コーディングは例外となりました。どうしてこうなったのでしょうか?

話題

この変化を「常識」として探すと、どこにでも見つかります。「唯一」「正しい」アプローチは劇的に変化しました。なぜ私たちは以前PVS-Studioの記事を宣伝資料と見なしていたのに、今では自動レビューツールを崇拝しているのでしょうか?なぜ私たちは強力な型システムから自由形式の仕様へと、これほど急速に移行したのでしょうか?

プログラミングコミュニティでこのようなことが起こったことはありません。確かに、どの型システムやWebフレームワークが優れているかについての議論はあり、一般的な意見は時間とともに変化しましたが、これは異なります。強力な型システムの熱心な信奉者は、PHP開発者を愚か者と見なすかもしれませんが、それでも開発者とは見なします。たとえ風刺的なRustの熱狂者でさえ、Rustプログラマーでした。そして、議論は、一方の選択肢が他方よりも信頼性が高いか、使いやすいか、学習しやすいかという点に基づいたものであり、信頼性や誤用についてまったく心配すべきかどうかという点ではありませんでした。

これは異なります――バイブコーディングは、より良い解決策としてではなく、唯一の健全な解決策として描かれており、過去の経験を侮辱しています。LLMを使用しない人はソフトウェアエンジニアではなく、職人気質(アーティザン)コーダーなのです。それはアイデンティティへの攻撃です。

歴史

用語を再定義し、自分自身を健全な側として描き、他者を考慮に値しない存在として描くことは、ソフトウェアの世界では新しい戦術です。しかし、私はこれを以前にも見たことがあります。それは、ファシストの戦術に非常に似ています。

私たちは皆、「バイブコーダーの対義語はソフトウェアエンジニアだ」と冗談を言っていた時代を覚えています。そして、1ヶ月も経たないうちに、誰もが自分自身を職人気質(アーティザン)プログラマーと呼ぶことに慣れ、「ソフトウェアエンジニア」という言葉を「責任ある」AIユーザーに譲ってしまいました。この言葉はミームの速度で広まり、自然な理由なしに広まったようです。

これは心理作戦(psyop)だとは思いませんが、私たちは自分自身を何と呼ぶかについて、もっと注意を払うべきだと思います。なぜなら、言葉には力があるからです。本物の作曲家は、自分自身を「職人気質(アーティザン)の作曲家」ではなく「作曲家」と呼びます。AIライターは「AIライター」と名乗らなければなりません。しかし、「プログラマー」という言葉は議論されておらず、これには現実世界の結果が伴います。

情熱を持ってアーティストを擁護し、AIを憎む多くのゲーマーも、ソフトウェアに言及すると態度を180度変えます。突然、LLMコードが許容され、明らかに誰もがLLMを使用しており、コードのAI免責事項は不要になります。彼らは専門家ではないので、レトリックは事実よりも重要です。そして、私たちのほとんどはレトリックが苦手です!

なぜ私たちなのか?

私たちはこの教訓をもっと早く学ぶべきでした。そして、すべての職業の中で最初にこの戦いを失った原因の一つは、少なくとも私にはわかっていると思います。この記事を書く前に、教育、ハードワーク、複雑な思考を必要とする「職人気質(アーティザン)」プログラミングがゲームと見なされる一方で、口伝えで広まった方法を使ってtextareaにアイデアを吐き出すことが本物と見なされるのはなぜだろうか、と疑問に思いました。

今、私はそれがソフトウェアコミュニティにおける蔓延する反知性主義によるものだと考えています。

Rustが人気が出る前、そしてその用途がすべての人に知られる前、それに対する最も一般的な反論は何でしたか?それは、まるで生の数学のようで実用的ではない、ということでした。Haskellについても、特にモナドについては同じことが言われますが、Rustは簡単に理解できることを示しました(Result、Option、Futureはモナドです!)。ポインタでさえ複雑だと考えられています。なぜなら、ああ、使用する前に何かを学ばなければならないからです!私たちは簡単な解決策を切望しますが、実際には、読むことを拒否し、StackOverflowからコードをコピー&ペーストしたいだけだ、ということです。ああ、すみません、違う時代でしたね、Claude。私たちは大学で勉強しなければならない職業を見て、「実際、私たちは彼らよりも優れており、世界の運営方法を指示する権利がある」と言います。それが反知性主義でなければ、何が反知性主義なのかわかりません。

だから、もちろん、私たちは教育、ハードワーク、思考、そして時間をかけることの利点を否定します――それらは「意識高い系」であり、私たちはそれよりも優れているからです。/s

今、どうするか?

私たちはもっと良い戦いをしなければなりません。目標は、AIを避けることがソフトウェアを書く唯一の正しい方法だと言うことではありません。それはうまくいかないでしょう。目標は、AIフリーのコーディングが公開の議論でその場を維持し、レクリエーションプログラミングと同等に見なされないようにすることです。

用語に関しては、AIが使用されている場合は「AI支援コーディング」、手作業で行う場合は「AIフリーソフトウェアエンジニアリング」を使用します。これにより、AIの使用に関する通知は維持されますが、プログラミングとエンジニアリングの部分が逆転し、「遊びの一種」と解釈される可能性のある「職人気質(アーティザン)」という言葉が削除されます。これは良いスタートだと思いますが、アイデアを歓迎します。

より一般的には、AI支援プログラミングがコードを書く唯一の健全な方法であるという仮定に異議を唱える必要があります。一般の人々は、AI生成アートをいかなる目的で使用することも「イタい」と感じることを理解しています。私たちは、AI生成コードについても同じ原則が当てはまることを納得させる必要があります。AI「アート」を目撃した人が、絵を描く方法を知らなくても騙されたと感じるなら、プログラムについても同じことが起こらない理由はありません。

私たちは、ソフトウェア開発に注ぐ配慮、コードの設計方法、直面している問題、そして協力の仕方がいかに美しいかについて話す必要があります。グリッチだらけのスピードランが面白いのは、グリッチが理解可能な人間の間違いから生じるのを見ることができるからです。コンピュータアートがいかにクールか、そして開発者がユーザーエクスペリエンスを向上させるためにアプリを磨き上げるのがいかに心温まるかについて話すべきです。私たちは、そしてこれは私たちの得意分野ではないことは理解していますが、私たちの人間性について語る必要があります。

これらの困難な時代を安全に乗り越えてください。