品質だけが唯一の変数である
プロジェクトマネージャーの仕事は、スコープ、時間、コスト、品質という4つの変数のバランスを取ることです。古典的な制約の三角形では、4つすべてではなく2つを最適化できるとされています。速くて安くしたい？品質が犠牲になります。良くて速くしたい？コストが増加します。この三角形は、リソースに制約のある環境では有用なメンタルモデルです。
私はリソースに制約のある環境で作業しているわけではありません。推論速度でコードを生成できるAIエージェント、コードベース全体を保持できるコンテキストウィンドウ、そして給与ではなくドル単位のセッションコストで運用しています。制約の三角形は崩壊するのです。
エージェントが数分で機能を実装できるとき、問いは「正しくやる余裕があるか？」ではありません。「なぜ間違ったやり方をするのか？」です。
排除のプロセス
意思決定から時間を排除しましょう。「どれくらいかかるか？」ではなく「完成したとき、どうあるべきか？」と問うのです。前者は納品速度を最適化し、後者は成果物を最適化します。
意思決定からコストを排除しましょう。正確でクリーンな、十分にテストされたコードを生成するセッションは、場当たり的で雑な、テストされていないコードを生成するセッションと同じコストです。APIは品質に関係なく、トークンあたり同じ料金を課します。正しくやることの限界費用はゼロです。
意思決定から労力を排除しましょう。エージェントは疲れません。100番目の関数も最初の関数と同じ能力で書かれます。セッション後半でショートカットを正当化するような人間の疲労曲線は存在しません。出力の品質は、指示の品質と周囲のコンテキストの品質によって制限されるのであって、何時間経過したかではないのです。
時間、コスト、労力を排除した後に残るものは何でしょうか？品質です。品質だけが唯一残る変数なのです。
実践における意味
品質が唯一の変数であるとき、いくつかの一般的なエンジニアリング判断は自明になります。
テストを書く。 特定の関数にテストを書くかどうかの議論はなくなります。エージェントは数秒でテストを書きます。限界費用はゼロ。限界便益は永続的な検証です。テストを書かないのは、何の節約もなしに品質を下げる選択にほかなりません。
隣接するコードも修正する。 バグを修正する際、周囲のコードにはしばしば関連する問題があります：一貫性のない命名、欠落したエラーハンドリング、古くなったパターン。時間に制約のある環境では、バグだけ修正して隣接するコードは「後で」にします。品質が唯一の変数であるなら、触れたものすべてを修正します。「後で」は決して来ません。「今」はタダです。
正しい抽象を使う。 手っ取り早いハックは目の前の問題を解決します。正しい抽象はそのカテゴリの問題を解決します。時間に制約のある環境では、ハックが今日出荷され、抽象は永遠に出荷されません。エージェントが同じセッションでどちらも実装できるなら、ハックに優位性はありません。抽象を選びましょう。
書く前に読む。 時間に制約のある環境では、エンジニアは完全に読んでいないコードを局所的な理解に頼って修正することがあります。エージェントがファイル全体を読み、パターンを理解し、完全なコンテキストで修正できるなら、部分的な理解で作業する理由はありません。ファイル全体を読む。パターンを理解する。そして書く。
先延ばしにしない。 TODO、FIXME、HACKは品質の先延ばしの印です。時間に制約のある環境では、先延ばしは合理的です：時間ができたら後で直す。品質が唯一の変数であるなら、先延ばしは非合理的です。エージェントはここにいます。コンテキストはロードされています。修正のコストは今も後も同じです。今やりましょう。
次郎の原則
小野二郎は70年以上にわたり寿司を握り続けています。彼のレストランはミシュラン三つ星で、席数はわずか10席。メニューも手法も変えていません。70年間、毎日手法を磨き続けてきたのです。
誰かが二郎に寿司が十分に良いか尋ねたとき、その答えはレストランがどれだけ忙しいか、何人の客が待っているか、魚がどれだけ高価だったかに基づくことは決してありません。寿司が彼の基準を満たしているかどうかに基づくのです。基準は絶対的であり、状況は無関係です。
これをエンジニアリングに適用した原則がこうです：基準はコードであり、スプリントではありません。関数は正確でクリーンで十分にテストされているか、そうでないかです。締め切りは評価を変えません。予算も評価を変えません。唯一の問いは、成果物が基準を満たしているかどうかです。
AIエージェントは、ソフトウェアエンジニアリングにおいてこの原則を初めて実用的にしました。エージェント以前、次郎の原則は理想論でした。完璧を追求する人的コストは高すぎたのです。あらゆるショートカットには合理的な正当化がありました：木曜日に出荷する、予算が尽きた、エンジニアが燃え尽きた。エージェントがあれば、正しくやるコストと間違ったやり方のコストは同じです。ショートカットはその正当性を失います。
プライドチェック
すべての重要な変更の後に、5つの質問を投げかけます：
- シニアエンジニアはこれを尊重するか？
- コードは自己説明的か？
- エッジケースは処理されているか？
- 適切なシンプルさのレベルか？
- コードベースを見つけた時より良い状態にしたか？
これらの質問は正確性についてではありません。エビデンスゲートが正確性を扱います。プライドチェックが扱うのはクラフトマンシップです。誰もメンテナンスしたくない正確なコードは質問1に不合格です。理解するためにコメントが必要な巧妙なコードは質問2に不合格です。ハッピーパスは処理するがエラーパスを無視するコードは質問3に不合格です。
質問4が最も難しいものです。「適切なシンプルさのレベル」は「可能な限りシンプル」ではありません。1行のハックは適切な抽象よりシンプルですが、問題が再発するならハックは間違ったシンプルさのレベルです。適切なシンプルさとは、仮想的な将来の問題を解決せずに実際の問題を解決する最小の複雑さです。
質問5は軌道についてです。すべてのセッションは、コードベースを見つけた時より良い状態にすべきです。修正した特定のファイルだけでなく、周囲のコンテキストも：更新されたテスト、整理されたインポート、修正されたコメント、削除されたデッドコード。基準は「タスクを完了したか？」ではなく「自分がここにいたことでプロジェクトは良くなったか？」です。
反論
明白な反論：スピードは重要です。出荷することは重要です。決して出荷されない完璧なコードベースは、実際の問題を解決する雑なコードベースより悪いものです。
この反論は、品質とスピードが逆相関する世界では正しいでしょう。AIエージェントが低品質な出力と同じスピードで高品質な出力を生成する世界では、この相関は崩れます。品質とスピードは独立変数になります。両方を手に入れることができるのです。
残るトレードオフは時間ではなく、注意力です。ファイル全体を読むには注意力が必要です。エビデンスゲートを実行するには注意力が必要です。プライドチェックを適用するには注意力が必要です。エージェントの時間はタダですが、あなたの注意力は有限です。
品質が唯一の変数ですが、品質に対する制約は注意力です。解決策は基準を下げることではありません。基準を維持する注意力コストを削減するインフラを構築することです：一般的な失敗を自動的にキャッチするフック、品質ワークフローをエンコードするスキル、セッション間でコンテキストを持ち越すメモリシステムにより、意思決定を再導出する必要がなくなります。
これは品質のための複合コンテキストです。インフラの各ピースが次のセッションの注意力コストを削減します。十分なセッションを重ねた後、基準はそれ自体を維持するようになるのです。
FAQ
すべてのソフトウェアプロジェクトに当てはまりますか？
この原則は、AIエージェントが実装を行うプロジェクトに最も直接的に当てはまります。完全に人間が実装するプロジェクトでは、時間とコストは依然として現実的な制約です。エージェントの能力が向上し、人間の実装時間が減少するにつれて、この原則はより適用可能になります。
プロトタイピングについては？
プロトタイプは定義上使い捨てです。プロトタイプの品質基準は「調査している問いに答えているか？」です。答えがイエスなら、コード品質に関係なくプロトタイプはその目的を果たしています。この原則は永続するコードに適用されるのであって、廃棄されるコードには適用されません。
これは単なる完璧主義では？
完璧主義は何も満たせない無限の基準です。品質はエビデンスゲートが定義する有限の基準です：正確で、クリーンで、テストされ、リグレッションがなく、実際の問題を解決していること。基準を満たすことは達成可能です。超える必要はありません。基準は高いですが無限ではないのです。
技術的負債はどう扱いますか？
作らないことです。技術的負債は先延ばしされた品質です。品質が唯一の変数であるとき、先延ばしはその正当性を失います。エージェントは今利用可能です。修正のコストは今も後も同じです。エージェントが生成する技術的負債には利子率がありません。なぜなら、それを発生させる理由がないからです。
出典
ここで述べた哲学は、日本の職人技の伝統である「匠」の精神と、AIエンジニアリングシリーズを通じて記録された制作経験に基づいています。参照されている具体的な実装：
- エビデンスゲート：完了検証のための6つの基準
- プライドチェック：クラフトマンシップ評価のための5つの質問
- フックシステム：品質インフラとしての84のフック（Every Hook Is a Scar）
- 複合コンテキスト：品質の注意力コストを削減するインフラ（Compound Context）