テストが設計を駆動するなら、評価は何を駆動する？ 〜テスト駆動開発と評価駆動開発、「先に定義する」ことの力〜

CRANK

テスト駆動開発（TDD）を実践したことがある人なら、テストが設計を駆動するという感覚がわかるかもしれません。t-wada氏の言葉を借りれば、「テストを先に書き、それに対応するコードを書いていくと、使う側の期待に沿ってコードを書くことになります」——結果として使いやすい設計が生まれる。 Development（評価駆動開発 / EDD） です。テストが設計を駆動するように、評価がAIの品質を駆動する——最近改めてそう感じています。（EDD自体、TDDにインスパイアされているので当たり前といえば当たり前なのですが） Beck氏の定義によると、TDDは以下の5ステップを繰り返します。テストシナリオのリスト（テストリスト）を書くリストから1つだけ選び、実行可能なテストコードに翻訳し、失敗することを確認テストを成功させるプロダクトコードを書く必要に応じてリファクタリングで設計を改善テストリストが空になるまで繰り返す or 評価駆動開発（Eval Driven Development / EDD）ではどうでしょうか。assertEqualsだけでは戦えない最初にぶつかるのは、従来のテストだけでは戦えないという点です。TDDが機能するのは、「与えられた入力に対して、決定論的な正解が存在する…