GitHub：機能追加の意思決定コスト増

以前、小さな機能リクエストにおいて最もコストのかかる部分はコードを書くことでした。しかし今では、そのコードを書くべきかどうかを議論する会議こそが最大の負担となっています。

これは明確な転換点であり、多くのエンジニアの直感を静かに揺るがしています。エンジニアは早い段階から、「小さな依頼」の多くは実際には小さくないことを学びます。テストの実装やリリース計画の策定、エッジケースの検討、そしてリリース後の責任者の確保などが必要です。システムの一部に干渉する変更であれば、2 時間の作業が 2 週間の気晴らしに発展することさえあります。そのため私たちは反発します。「本当に必要なのか」「このリリースに含まれるべきか」「すでに合意した契約を変更するのか」と問いかけます。しかし、この直感を捨てるつもりはありません。

ただし、その直感は「コードの初版を書くことが最もコストがかかる工程である」という前提に依存しています。しかし、この前提が静かに崩れ始めています。ある特定の変化のクラスにおいては、もはやそれが最優先事項ではなくなっています。これらの変化を他のものと区別できるのであれば、「スコープ内か？」という議論を、2 日間の論争ではなく 30 分で答えられる質問に置き換えることができます。

議論のコストはパッチそのものより高いことが多い

私が繰り返し目にするパターンがあります。ある人が、バックエンドにすでに存在する last_active_at タイムスタンプを設定ページに表示するという小さな変更を求めたとします。チームはそのスレッドで 40 分も費やします。一人が「これはリスクがある」と言い、別の人は 2 年前の関連するマイグレーションを思い出します。さらに誰かがデッドラインについて言及します。最終的に結論は「おそらく 1〜2 日かかるが、それ以上になる可能性もある」となり、確信度は低くなります。その主な理由は、誰も実際に試していないからです。

試行錯誤にコストがかかる時代なら、このプロセスは理にかなっていました。作業を中断して文脈を頭に入れ、手動で変更を加え、テストを書き、二次的・三次的な影響を発見する必要があるからです。

しかし、最初の試行が安価になった今、境界を守ろうとするコストの方が、それを破るコストよりも高くなってしまう可能性があります。

エージェントは、スレッドがウォームアップするのと同じ時間で最初の修正パッチを作成できます。もちろん無料ではなく、自動的に正しいとも限りません。それでも十分安価なので、賢明な判断としては、推測を止めて実際の差分（diff）を確認することです。

最初のパッチは製品そのものではなく、価格確認のためのものです。

よくある間違いは、生成されたパッチを最終成果物として扱ってしまうことです。それはそうではありません。これは探査（プローブ）なのです。抽象的な範囲に関する議論を、検証可能な具体的な成果物へと変換します。

• 想定したファイルにのみ触れているか、それとも五つのパッケージにまたがって広がっているか？
• テストは明白か、それとも変更自体がテストしにくいものか？
• 既存の抽象化を維持できているか？
• 新たな製品判断を静かに必要としているか？
• 半年後にこの振る舞いを自分が責任持って引き受けても大丈夫か？

「これがスコープクリープ（範囲の無秩序な拡大）のように感じるか？」という問いよりも、こうした質問の方がはるかに重要です。なぜなら、今やあなたは感覚ではなく証拠に基づいて議論できるからです。もし last_active_at フィールドの変更が 4 行の差分でテストもパスするなら、そのままリリースすればよいのです。 debates（議論）こそが高額なコストだったのです。しかし、同じリクエストが認証ミドルウェアに触れる結果となったなら、その要求は決して小さくはないと学べます。しかも、それを二日かけて学ぶのではなく、たった 30 分で知ることができます。

これは AI に判断を任せることではありません。AI を活用して、人間の判断コストを下げ、より根拠のある判断を下すようにするのです。

「書くのが安い」ことは、「所有（維持管理）するのが安い」とは同じ意味ではありません

ここが罠であり、AI 時代における最も重要な区別です。コード生成に安く済んだからといって、変更自体が安いわけではありません。人間が自信を持ってレビューし、結果を責任持って引き受けられる場合のみ、それは「安い」変更となります。

技術的にはテストにパスする 1000 行の差分でも、誰もそれを責任持って管理したくないなら、それは安価な変更ではありません。むしろ、コストの先送りです。その場合の分岐点は、「エージェントがこれを書けるか？」ではなく、「人間がこれを検証できるか？」という点にあります。

バックエンドに既に存在する表示フィールドを追加するのは、通常は安価です。

認証ロジックの変更は、差分がどれだけ綺麗であっても、安価ではありません。

テスト済みのヘルパー関数のリファクタリングは、通常は安価です。

データ保持のセマンティクス（意味）を変更することは、安価ではありません。

コードが些細なものでも、明確に「ノー」と言うべき変更は依然として存在します。具体的には、製品の契約条件を変更するもの、サポート負担を増大させるもの、あるいはプライバシー、請求処理、コンプライアンスに関わるものです。AI は候補案を作成するコストを下げますが、その候補案を引き受ける（所有する）コストを下げるわけではありません。

スコープ管理の基準を証拠に基づいたものへシフトする

従来、スコープ管理は実装が最も高価な工程だったため、実装前に厳格に行われていました。しかし現在では、その一部をレビュー段階に移行することが可能になっています。これは計画を省略してよいという意味ではありません。重要なのは、「どの程度の計画が実際に効果を生むのか」を明確にすることです。

小さな変更について再議論する前に、まずは制約条件付きでの試行を求めましょう。この「制約条件」こそが本質的なポイントです。

可能な限り最小限のパッチを作成してください。既存の機能フラグ（feature flag）の背後に隠し、パブリックな契約を変更しないようにします。テストを追加または更新し、変更したファイル一覧を明記して、リスクのある箇所を特に指摘してください。

エージェントがこれらの制約条件下でクリーンなパッチを生成できない場合、その要求はあなたが思っていた以上に大きく、コミットする前にすでに実質的な所有コスト（オーナーシップ・コスト）を伴うものであることがわかります。逆に、生成できたとしても何らかの示唆があるはずです。いずれにせよ、「これはスコープ内にあるのか？」という問いを、「これにはどの程度のコストがかかるか。支払う価値はあるか？」という問いへと置き換えることができます。

新しいスキルは不確実性の価格設定

AI を活用する世界において、最も優秀なエンジニアとは、すべての依頼に「はい」と答える人でもなければ、反射的に「いいえ」と拒絶する人でもありません。彼らが真に優れているのは、不確実性を素早く評価できる点にあります。

具体的には、実装の仮面を被った製品上の判断であるリクエストを見極めたり、コードレビューが作成自体よりも困難になる局面を理解したり、小さな変更であれば「試してみる」ことが最も責任ある対応だと判断する力です。この最後の能力こそが、以前とは全く異なる新しいスキルセットです。

かつての「試してみて結果を見てみよう」という言葉は、他の作業から開発者を引き剥ぐことを意味していました。しかし現在では、適切なタスクに対してはそのような行為ではなく、エージェントに範囲を限定された課題を与え、その結果に基づいてより良い判断を下すことを指します。推測に費やす時間が減り、監督に充てる時間が増えます。実装をブラックボックスとして扱う時間が減り、具体的な成果物を評価する時間が伸びるのです。

スコープの拡大（スコープ・クリープ）という問題は依然として現実のものですが、「新しいコードはコストが高すぎるのでダメです」という拒絶理由は、2 年前に比べてはるかに説得力を失っています。コードを生産するコストは低下した一方で、そのコードを理解し、レビューし、責任を持つコストは下がっていません。したがって、問うべき質問も「これは作業量が増えるのか？」から「本当のコストはどこにあるのか？」へとシフトしました。場合によっては、小さな範囲限定の変更に対する本当のコストとは、単に結果を確認するまでのプロセスそのものなのです。

「はい」と言うことのコストは変わりました。「いいえ」と言うことのコストも、それに合わせて変わるべきです。

（※本記事は The GitHub Blog に掲載された「The cost of saying yes has changed」の続編です）