外科医のようにコードを書く

213日前原文(geoffreylitt.com)

概要

AI活用 によって「全員がマネージャーやエディターになる」という見方は 不完全
外科医型 の働き方を目指し、重要なコア業務に集中する発想
AIエージェント による雑務や補助作業の自動化・効率化
自律性スライダー でAI活用方法をタスクごとに調整
Notion での実践と、知識労働全体への展開の可能性

AI時代の「外科医型」コーディング

「AIが全員を マネージャー化 する」という意見への危機感
外科医 のように、自分が得意な重要業務に集中する働き方
サポートチーム が準備や雑務、管理業務を担当するイメージ
AIコーディングツール で100%価値ある作業に集中する目標
UIプロトタイピングの場合は デザイン検討 が主なコア業務

AIに委任できる補助・雑務

コードベースの ガイド作成 （大きな作業前の準備）
大規模変更の 試作（スパイク） ：結果をそのまま使わなくても方向性確認用
TypeScriptエラー や明確なバグ修正
ドキュメント作成 （作っているものの説明等）
これらは 非同期でバックグラウンド実行 が有効
- 例：昼食中や夜間にAIエージェントが作業

「自律性スライダー」で使い分け

コア業務 （デザイン検討等）には手動作業や細かいAI活用
- 迅速なフィードバック・高い可視性が重要
- 例：Cursorのタブ補完
補助作業 にはAIエージェントによる長時間の自動実行
- 完了までのスピードや可視性は重視しない
- 例：Claude CodeやCodex CLIの活用
Andrej Karpathy の「自律性スライダー」概念との類似性
タスクごとに AI活用の姿勢・ツール を変える必要性

AIエージェントと「地位ヒエラルキー」の解消

「外科医型」組織は The Mythical Man-Month でも提唱
- かつては人間スタッフが補助役
AIの普及 でこのモデルが経済的に実現可能に
「雑務＝下位メンバー」の発想が AI導入で不要に
- 成長機会を与えつつ、純粋な雑務はAIへ委任
24/7のAI利用 で人間の働き方を拡張
- 例：深夜にAIへ調査依頼

Notionでの実践と知識労働への拡張

AIコーディングツール活用を推奨 する職場環境の価値
- 大規模コードベースへの新規参加でも生産性向上
Notion製品 としての展望
- プログラマー以外の知識労働者にも「外科医型」働き方を普及
- コア業務に集中し、雑務をAIに委任する働き方の推進

Hackerたちの意見

ジェフリー・リットのAIコーディングツールに関する新しいアナロジー、めっちゃいいね！

「個人的には、外科医のようにコーディングしようとしてる。」外科医はマネージャーじゃない、実際に手を動かす人だよね！でも、彼らのスキルや時間は、準備や二次的なタスク、管理を担当するサポートチームによって大いに活用されてる。外科医は、自分が特に得意な重要なことに集中できるんだ。それに、これは「神話のマン・マンス」を思い出させるね。大規模ソフトウェア工学に関する初期の影響力のある教科書だよ。

チーフプログラマーチームの構造がまた流行ってるのか。今度はエージェント付きで。フレッド・ブルックスの考えが今こそ重要だね。

└

そうそう、投稿の中でブルックス（と、アイデアの元のようなハーラン・ミルズ）を引用してるよ！

└

これがもっと人気がないのがちょっと驚きだな。10倍の成果を出す人を特定して、優秀なチームを与えれば、会議に出たり、Jiraのチケットを埋めたり、顧客にプレゼンしたりして時間を無駄にする高給取りを減らせると思ったんだけど。彼らにたくさんお金を払ってるのに、ちゃんとその分の価値を得られないのはおかしいよね。正直、どの仕事でも、自分の仕事に関係ないことを理解するのに異常な時間を使ってる（「ここではJiraのチケットのすべてのボックスをチェックして、Zephyrのチケットにリンクさせて、GitのPRにリンクさせる必要があるから、添付ファイルやコメントを追加することは気にしないで！」みたいな感じで）。

ダン・ノースのトークのスライドを思い出した - たぶんこれかな。 https://dannorth.net/talks/#software-faster? その中の一つだと思うけど。重要な引用は「ソフトウェアは手術のように、問題を解決するために必要な最小限のものであるべき」という感じだった。まあ、このブログ記事はその雰囲気には沿ってないみたいだけど。

└

この引用、好きだな。残念ながら、前の職場の先輩は「5分節約できるなら、ファイルを丸ごとコピー＆ペーストしろ」っていう別の原則を守ってたけど。まあ、私はまだ外科医だよ、ただ切断することが多いだけ。

ソフトウェアエンジニアには「神話のマン・マンス」を読むべきだとずっと主張してきたけど、今こそその重要性が増してると思う。ここ25年ほどで、ソフトウェアの作り方が大きく変わったし、それはウォーターフォールからアジャイルへの移行で明らかだよね。LLMを使った開発（CodexやClaude Code）では、70年代や80年代にソフトウェアを作っていた時のパターンに戻っている気がする。最近の15年間のプロフェッショナルなキャリアよりもね。ある人たちはこれを「仕様駆動開発」と呼んでるけど、そのタイトルは誤解を招くと思う。手術として考えるのも誤解を招くけど、フレッド・ブルックスのアナロジーはまだ良いよね。私にとっては、ボルトや鋼材、どのドアヒンジを使うかに悩まされずに、橋や高層ビル、聖堂の設計に時間を使えるようになった感じ。もちろん、そういう詳細は重要だけど、今はそれを委任できるようになった。以前はそれが非常に高価で壊れやすかったから。

└

橋/高層ビル/聖堂その詳細は重要だけど、今はそれを委任できるようになった。いや... 高層ビルを建てるなら、鋼材やボルトの出所を委任できる世界なんてないよ。少なくとも、その鋼材の特性について気にしなきゃいけないし、プロジェクトで使うすべての部品がその制約に合うことを保証しなきゃ。もしそれを気にしたくないなら、制約が1000倍少ない住宅を建てればいいし、比較的簡単に再建できるよ。内装やフロアの配置を考えてる？それは常に建物のオーナーが対処する別の問題だったから。

└

70年代・80年代のアプローチと今の違いについて、もう少し詳しく教えてもらえる？俺はエンジニアリングに情熱を持つアナリストだけど、職業としてのエンジニアじゃないから、正直言って今が過去とどう違うのかは分からないんだ。

└

ブルックスが間違ってることはあまりないけど、手術チームについてはそうだね。手術チームにはあまりチーム感がない。ソフトウェアはオープンハート手術みたいに、一度に一つのことだけに制限される必要はないから、もっと手が必要だよ。スポーツチームみたいな感じ。でも、私たちは練習したり、レビューしたり、コーチングしたりすることがないから、優れた成果を出すのに時間がかかるんだ。

└

今、ソフトウェアのCAD、つまりCASE（コンピュータ支援ソフトウェア工学）に近づいてるね。コードを何時間も打ち込む代わりに、ソフトウェアのデザインに集中できるんだ。

いい比喩だね、今後使わせてもらうよ。もう一つ例を挙げるなら、絵画のことを考えてみて。レンブラントやルーベンス、ボッティチェリみたいな「古典の巨匠」は、大きなアトリエを持っていて、助手たちがたくさんいて、キャンバスを張ったり、絵の具を混ぜたりするだけじゃなくて、巨匠の指導のもとで実際に絵を描くことも多かったんだ。巨匠が構図をスケッチして、重要な顔（特に目ね）を描いて、あとは助手たちがドレープや風景などを埋めていく感じ。この流れは、1700年代の終わりにロマン主義の時代に変わって、個々のアーティストが一人で創作の瞬間に働きかけて、最初から最後まで一つの傑作を生み出すっていう考え方が出てきた。カスパー・ダーヴィト・フリードリヒやJMWターナーが思い浮かぶね。プログラマーの中には、ターナーみたいに全体をコントロールしたい人もいて、機械が自分と同じように部分的にできるようになると、自分のクリエイティビティが脅かされると感じる人もいる。俺はレンブラントになって、アウトラインを描いて目を塗って、あとはジュニアエンジニアかAIエージェントに任せたいな。好みの問題だね。

└

私はレンブラントになって、アウトラインを描いて、目を塗って、残りはジュニアエンジニアに任せたい。君が言ってないのは、コードは最終製品じゃないってことだよ。それは最終製品の設計図なんだ。最終製品は、プロセスが動いてニーズを解決すること。ソフトウェアが素晴らしいのは、どれだけ簡単に洗練できるかってこと。ソフトウェア工学の全体のポイントは、設計図が良いことを確信し、変更のコストが大きくないことを保証することなんだ。早くコードを書くことや、壁を越えて投げて終わりじゃない。君が描いているプロセスは、いくつかのリフをメモして、数分の曲を完全に作曲して、ランダムな人たちにフルシンフォニーを完成させるようなものだよ。たくさんの楽譜があることが重要じゃなくて、良い音楽があることが大事なんだ。楽譜はアイデアを指揮者に伝えるのに役立つから重要だけど、聴衆はそれを気にしない。だから、ユーザーもコードを気にしないけど、バグや機能がないことには気を使う。そういったフィードバックに対処するには、良いコードが必要なんだ。君のプロセスで良いコードが得られるなら、それでいいけど、まだ証明を待ってるよ。

初めてのコーディング、まるで外科医みたい。スクリプトを実行して、俺の近くで。

└

やめてくれ、DynamoDBを扱うたびにザッパが頭にこびりつくのは十分悪かったんだから。

└

待って、マドンナをパロディにしてるの？それともウィアード・アルのメタパロディ？

この比喩は根本的に間違ってる、文字通りにも比喩的にもね。外科医はマネージャーじゃなくて、実際の作業をする人だよ！でも、彼らのスキルと時間は、準備や副次的なタスク、管理を担当するサポートチームによって大いに活用されてる。外科医は自分が得意な重要なことに集中するんだ。まず、文字通りの話。外科医は自分が行う手術のマネージャーで、彼らが働く外科チームに大きく依存している。著者が手術について何か知っていれば、重大な手術で最も重要な人は外科医ではなく麻酔科医だって理解するはず。次に比喩的な話。著者は「雑用」を「知的に満たされない、創造的でない作業」として特定するのに力を入れているけど、どんな定義の仕事でも価値が判断なしに評価されるなら、「雑用」なんて存在しないってことを理解していない。でも、もし誰かが「外科医」として自分を特定し、他の人を「準備や副次的なタスク、管理を担当するサポートチーム」として捉えるなら、その投稿は自己中心的な視点から理解できる。

└

麻酔科医がより重要な理由は何？ > もし誰かが「外科医」として自分を特定し、他の人を「準備や副次的なタスク、管理を担当するサポートチーム」として捉えるなら、その投稿は自己中心的な視点から理解できる。彼らは他の人をサポートチームとして扱っているわけじゃない。AIツールをサポートチームと呼んでいるんだ。

└

大手術で最も重要な人は麻酔科医であって、外科医ではない。もう少し詳しく説明してもらえる？外科医がいなければ手術はできないから、外科医が一番重要だと思うんだけど。麻酔は今の形になってから比較的新しい発明だし、歴史的には麻酔なしで大手術が行われていたし、緊急時には今でも麻酔なしで手術できる（もちろん、激しい痛みやリスクが高くなるけどね）。

└

似たようなアナロジーが多くて、結構間違ってると思う。あるフレームワークのランディングページ（どれかは覚えてないけど）に、プログラマーを木工職人に例える説明があったんだ。信頼できる熟練の職人が、同じ注意を払って家具を作るって書いてあったけど、実際はそうじゃないことが多い。例えば、背面パネルが未仕上げのままで、荒く削られた跡が残ってることがよくある。だから「このフレームワークでソフトウェアを木工職人のように丁寧に作れる」っていう前提は成り立たないんだよね。

└

あなたは『神話のマン・マンス』を読んでないと思うけど？著者はフレッド・ブルックスの既存のアナロジーを引用して、それを基にしてるんだ。確かに、今の麻酔科医は部屋で最も「重要な」人かもしれないけど、それがアナロジーの本質じゃない。外科医が「手術チームに大きく依存している」って強調することも、ブルックスの考えにとって同じくらい重要なんだ。「チーフプログラマー」はチームのサポートがあってこそできることだからね。著者が指摘している「グラントワーク」は、主に「コ-pilot」（アシスタントプログラマー）に与えられるタスクに焦点を当てているけど、他のサポート役（管理者、編集者、秘書、事務員、ツール職人、テスター、「言語弁護士」）には具体的な言及がないんだ。多くはSaaSツール（Github、Jira、Notion、Docusaurusなど）に置き換えられたり、他の役割（PM、SDETなど）で埋められたりしてる。さらに、著者はこうも言ってる：> 「チームの低ステータスのメンバーにすべてのグラントワークを任せるのは嫌だ。」確かに、ジュニアメンバーはグラントワークが多くなることが多いけど、彼らが成長できるように興味深いタスクも与えられるべきだよね。著者は明らかに、経験の少ないプログラマーをメンターとして見ていて、ただの雑用係として扱っているわけじゃない。アナロジーは完璧じゃないかもしれないけど、「AIコーディングツール」についてのメッセージは、判断なしに評価されるべきだと思うよ（自己中心的な考えの非難なしにね）。 [0]https://en.wikipedia.org/wiki/The_Mythical_Man-Month

このアプローチ好きだな。数ヶ月間、Claudeをコーディングプロセスに関わらせようと頑張ってみたけど、自分でコードを書く方がずっと楽しくて効率的だって気づいた。ずっと見守って、Claudeが書いたものを何度も見直してエラーや論理的な欠陥を探すよりもね。実は、サブスクリプションをキャンセルしようと思ってたんだ。でも今月、大きなデータベースをMySQL 8から9にアップグレードする必要があって、数百の長くて複雑なクエリが関わってるコードベースだった。自分が書いたコードだから、何をしているかもスキーマも理解してるけど、いくつかはONLY_FULL_GROUP_BYに違反するかもしれないし、いくつか（どれかは覚えてないけど）はDERIVED_MERGEをオフにしないと歴史的な奇妙さがあった。疑わしいものに対してテストを行う準備をしてたんだけど、ふと思いついてClaudeにコードベース全体とスキーマを渡して、デフォルトのオプションが有効になった場合に壊れるかもしれないクエリを特定してもらったんだ。驚くべきことに、15のクエリを特定して、それが何に違反しているかを説明してくれた。7つは間違ってたけど…その7つは実際には問題なかったし、評価に使った何かが過度に保守的で偽陽性を返したって認めてた。でも、他の8つのクエリは修正可能だった。書き直し方についても少し間違ってたけど、遅くて非効率的な回避策をたくさん作ってしまった。横の結合のアイデアを無視して、インデックスに最適化されたSQLを書かなかったりね。でも、自分でこれらのクエリを見つけるのに何時間も節約できた。俺にとって、LLMにたくさんのコードを潜在的な問題点に変換させるアイデアは、コード自体を書くように頼むよりもずっと価値のある使い方に思える。それが理由でサブスクリプションを続けたんだ。

└

これ、10年もののコードベースでかなり時間を節約してくれてる。スタックトレースを貼り付けて、関連するコンテキストを追加してから、LLMに初回のデバッグをお願いするんだ。そうすると、手動でレビューするためのファイルと行のリストがもらえるし、追うべき初期の手がかりも得られる。パフォーマンスの問題を修正する時にも使える。修正をフィーチャーフラグで切り替えて、新しいコードパスが特定の入力セットで同じ結果を出すか確認してもらえる。こういうことに対してテストカバレッジもあるけど、LLMが一通り見てくれて、テストを実行する前にいくつかの欠陥を指摘してくれるんだ。自動補完を超えて、あまりコードを書いてもらったことはないけど、それでも効率はちょっと上がったかな。

外科医は重要なことに集中している。うわ、これを書いた人の考え方でコードを書くのはやめた方がいいよ。あの「サポート」タスクはめちゃくちゃ重要で、あなたはそれをうまくできないかもしれない。謙虚になって、周りで行われているすべてのことも重要なことだと認識しよう。彼らを同じくらいサポートしてあげて！

それ、実はいい例えだね。初心者の外科医が、看護師や麻酔科のスタッフがミスをカバーしてくれると思って手術をしたら、患者をすぐに死なせちゃうよ。これらのチームがいないと手術がうまくいかないからって、最初に先輩外科医に教えてもらう必要がないわけじゃないし、そもそも先輩外科医が必要なんだよね。悪い麻酔科医や、外科医の視界を妨げる看護師がいると、どんなに腕のいい外科医でも患者を死なせちゃうけど、上手な外科医なら早めに危険を察知して対処できるかもしれない。問題なのは、必要な経験がないのに、どのメスを使うかなんて看護師が渡してくれるから大したことないと思ってる志望外科医たちだよね。だから、もし患者を不必要に死なせるコストが許容できるなら、最初から外科医みたいにコード書けばいいけど、そうじゃないなら、まずは他のみんなと同じように医学部に行くべきだよ。

ハクソク