AIで速く書ける時代、エンジニアは“何”で評価されるべきなのか？

▼質問・相談はこちら（匿名OK）

Google Form: https://forms.gle/pUZWDqVUpwKuUYdX9

• AIによってコード生成が高速化する中で、バックエンドのリクエストスペックなど最低限のテストは必須だと感じ、テストとレビューをどう効率化するかを考え始めた

• テストを増やすほどCI時間が長くなるため、DB書き込みを伴うテストを減らす、モック活用、重複テスト削減など「テストのコスパ」を上げる必要性が話題に出た

• CI高速化の手段として、GitHub Actionsのランナー強化やセルフホストランナーなど「お金で解決する選択肢」も現実的だという話になった

• 大規模組織では、CI/CDやオーケストレーション基盤を社内SaaSとして提供し、各チームが利用料を払って使う仕組みがある事例が紹介された

• デリバリー速度を上げる方法として、カナリアリリースと外形監視を組み合わせ、一定条件を満たしたら自動で次のリリース段階に進める仕組みの話が出た

• PR作成からリリースまでのリードタイム短縮がAI時代のボトルネックになりやすく、自動化の価値が高いという認識で一致した

• CIの実行頻度と許容待ち時間について、数分〜1時間まで規模によって感覚が大きく違うという実体験が共有された

• テストをスモール／ミディアム／ラージとサイズで分け、常時回すテストとリリース時だけ回すテストを分離する考え方が紹介された

• 開発生産性の指標として、デプロイ頻度やリードタイムなどの定量指標がある一方、測定コストが高く難しい点が話題になった

• PRのリードタイムやアンケートベースで「集中できているか」を測るツールの事例が紹介され、主観指標の価値が語られた

• 単純な開発スピードではなく、バグ修正コストまで含めて考えると「早い＝生産性が高い」とは限らないという例が挙げられた

• 生産性指標の目的は個人評価ではなく、チーム全体の阻害要因を見つけることだという整理がなされた

• エンジニア個人の定量評価は行動を歪めやすく、アウトプット量だけで評価するのは危険だという意見が共有された

• ドキュメント整備や育成、外部発信など数値に出にくい貢献も評価対象にすべきという話に展開した

• 目標設定（大胆な数値目標）と評価は切り離し、達成度そのものではなく取り組み方や組織への影響を見る考え方が紹介された

• AIが普及するほど、エンジニアの評価制度や報酬の考え方は今後さらに変わっていくという締めに至った

----

少し出遅れてエンジニアとしてのキャリアをスタートさせた2人が

技術に必死にしがみついたり、キャリアについて迷ったり、

色々と試行錯誤して成長しようともがく様子をお届けする番組です

【とっく】

X: https://x.com/tokkuu

Profile: https://www.tokku-tech.dev/

【イルカ】

Twitch: https://www.twitch.tv/irukamind

YouTube: https://www.youtube.com/@irukamind

TikTok: https://www.tiktok.com/@irukamind88

X: https://x.com/irukamind

Instagram: https://www.instagram.com/irukamind88