AI が実行を担う時代、人材評価の軸をどう更新するか — 「設計者のように考える」5つの実践

AI にコードを書かせる前に仕様書（要件・行動ルール・非目標・失敗条件）を書く工程を、正式なワークフローに組み込むかどうか——組織が決めるべきはこれだ。筆者が5つの実践パターン（要点3）の最初に挙げるのが、まさに「着手前に仕様書を書く」ことである。友人リマインダーアプリの例では、機能要件だけでなく「行動ルール」（いいね・リアクション・一言の返信は連絡とみなさない、3週連続で提案しても行動しなければ優先度を下げる）「非目標」（ゲーミフィケーションはしない）「失敗条件」（義務感を感じさせたら失敗）まで書き下ろしている。これは個人の趣味アプリの話ではなく、AI にコードを書かせる前提が全社的になった組織がそのまま直面する問題だ。自分の組織でこの工程を組み込むなら、誰が仕様書を書く責任者になるのか、仕様書の質をどう評価するのか、レビューは何をチェックするのか（筆者は認証・トークン失効・決済失敗パス・レート制限など「実装の中身」ではなく「意思決定の中身」を5つの質問で問う）を制度化しなければならない。ここまで踏み込むと、人材評価の軸を「実行の速さ・正確さ」から「仕様書と質問の質」に更新するかどうかという、評価制度そのものの改定判断に行き着く。