「趣味のプログラミング」が最強である理由：ドメイン専門職×AIによる内製開発の設計思想

• URL: https://zenn.dev/minipoisson/articles/domain-expert-ai-dev-philosophy
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 製造・医療・法務等のドメイン専門職が自分の業務のためにコードを書く場合、IT業界標準のPRフロー・人間によるコードレビューは必要ないという設計思想を論じた記事。「クソコード」が生まれる構造的条件（所有権の分散・痛みが自分に返らない構造）が最初から存在しないため、PRはその防衛策として不要であり、むしろ心理的安全性を損ない職人の当事者意識を冷やすリスクの方が大きいと主張する。代わりに「職人＋AI」を軸に、コードのテキスト化とGitローカル管理（第1関門）・IDE内AIとの1対1壁打ち（第2関門）を整備し、GitHubを監視場所ではなく「知のカルテ」として使う内製化モデルを提唱している。

詳細

• クソコードが生まれる構造的条件: 所有権の分散（作る人と直す人が別）・外圧による着手強制・評価期限優先・痛みが自分に返らない構造。PRはこれへの防衛策
• ドメイン専門職の開発が「趣味」に近い理由: 所有権が明確（作った人が使い続ける）・仕様を出す人とコードを書く人が同一・品質モチベーションが内側から生まれる
• 人間レビュー不要の理由: 仕様の正解を最もよく知っているのはレビュアーではなく開発者本人。静的解析ツール（第1関門）とAIレビュー（第2関門）で大部分がカバーできる
• 人間が監査側に置かれるリスク: 「指摘できること」の目的化・好みの押し付け・心理的安全性の損壊・職人の当事者意識の冷却
• 第1関門・テキスト化とGitローカル管理: VBA/GASをテキスト化してGitで版管理。GitをAIへのコード受け渡し基盤として使う。GitHubはバックアップと次世代へのバトンであり共同監視の場所ではない
• 第2関門・IDE内AIとの1対1壁打ち: 各自のVS Code等でコードを書く瞬間にAIと壁打ち。AIは感情なく淡々と指摘し職人のプライドを傷つけない
• 属人化リスクへの回答: LLMが「このツールが何をしているか解説して」への優秀な翻訳者として機能するため、かつての「他人のコードは解読不能」問題は現代において大幅に低下
• 育成への応用: 見習い期間は先輩が大局的な相談相手に専念し、基礎的な構文等はAIに外注。独り立ち後は自分のリポジトリを持ちAIを相棒に独立独歩
• 大規模システム開発に残るもの: 認証認可・マスターデータの一元管理等インフラデータ基盤の提供と、現場職人がAIで安全に開発するためのAPI（部品）の提供
• コメント欄でのFDE（Forward Deployed Engineer）言及: Palantir等のFDEモデルを「現場生え抜きの専門職が自律型FDEとして覚醒する」形へ反転させるAI時代のDXとして議論