Upgrade to Pro — share decks privately, control downloads, hide ads and more …

最近評価が難しくなった

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.
Avatar for Mitsui Mitsui
July 08, 2026

 最近評価が難しくなった

AIによって成果が速く・細かく出るようになり、エンジニアの評価は過大評価にも過小評価にもズレやすくなりました。ただ、評価項目そのものは変わっていません。AIが圧縮したのは「作業」で、「判断」と「責任」は圧縮されていない。変わったのは項目間のウェイトと、成果の見え方です。

量・速度・苦労といった代理指標が機能しなくなった今、見る側は成果物の裏にある判断を直接見に行き、見せる側は自分がどこで価値を出したかを言語化する。そのための目標の合意、KPT や Brag Documentといった運用の工夫について話しました。

Avatar for Mitsui

Mitsui

July 08, 2026

More Decks by Mitsui

Other Decks in Technology

Transcript

  1. あるSlack での出来事 # 雑談- 成果報告 M member 今日 14:32 こんなことやりました!🎉

    問い合わせ対応で毎回手作業だった集計、自動化しました。今後は誰でもワンクリックで出せます。 👍 2 🎉 1 問題提起
  2. エンジニアの仕事の全体像 ① 課題発見・定義 何を解くべきか → ② 解法の設計・判断 どう解くか → ③

    実装・遂行 形にする → ④ 検証・価値確認 価値になったか → ⑤ 運用・保守・品質 回し続ける 参考: ソフトウェア開発ライフサイクル(SDLC ) aws.amazon.com/jp/what-is/sdlc / Dropbox Engineering Career Framework dropbox.github.io/dbx-career-framework 5 つの段階
  3. AI はどこを圧縮したか ① 課題発見・定義 調査・情報収集 一部圧縮 → ② 解法の設計・判断 判断は人が担う

    圧縮されない → ③ 実装・遂行 生産速度が上がる 大きく圧縮 → ④ 検証・価値確認 テスト生成 一部圧縮 → ⑤ 運用・保守・品質 責任は人が持つ 圧縮されない AI が圧縮したのは「作業」 。 「判断」と「責任」は圧縮されていない。 変化の中身
  4. だから、ウェイトが移った 評価項目は変わっていない。変わったのは比重。 これまで ① 課題発見 ② 設計判断 ③ 実装・遂行 ④

    検証 ⑤ 運用 これから ① 課題発見 ② 設計判断 ③ 実装 ④ 検証 ⑤ 運用 作業から、判断と責任へ 比重の変化
  5. もう一つ変わったもの ── 「見え方」 これまで実力を推定してきた「ものさし」 実装量 PR 数 作業時間 苦労の見えやすさ 時間がかかっていた

    = 難しいことをしていた、という推定が、それなりに機能していた ✕ AI はこの推定を無効化した AI が壊したのは評価項目ではなく、代理指標。 だから、判断そのものを直接見に行くしかない 代理指標
  6. 評価項目は、各社どう書いているか それぞれの言葉、それぞれの切り方のまま並べる Dropbox dropbox.github.io/… Results Direction Talent Culture Craft SFIA

    国際標準 sfia-online.org Autonomy Influence Complexity Business skills Knowledge メルカリ github.com/mercari/… Commending Bold Challenges Vision Focus on the Mission Teamwork Professionalism Continued Learning Move Fast for Engineers CyberAgent cyberagent.co.jp/techinfo/… 専門性 戦略性 業務遂行力 オーナーシップ フォロワーシップ 技術だけを見るラダーは、存在しない どのフレームワークも、技術とそれ以外の能力・責任で人を見てきた 実例
  7. 主張を、さっきの図に置いてみる ① 課題発見・定義 → ② 解法の設計・判断 → ③ 実装・遂行 主張はここ

    → ④ 検証・価値確認 → ⑤ 運用・保守・品質 ① その難しさは、どの課題が要求したのか ② もっと簡単な解はなかったのか。なぜこれを選んだのか ④ 結果、何が変わったのか ⑤ その難しさは、運用に耐えるのか 難しさは、判断とセットで初めて価値になる ケース
  8. 目標という「共通プロトコル」 目標を通じて、これを合意しておく 1 期待 何を任せ、何を期待しているか 2 現在地 何ができていて、何が足りないと見ているか 3 期待超えの定義

    何をもって「期待を超えた」とするか 目標が実態とズレた・形骸化した → 評価を曲げるのではなく、まず目標を見直す 成果が速く細かく出る時代 → 目標のメンテナンス頻度も上げる 実践の土台
  9. AI 時代の「成長」とは 評価が「判断を見る」ことなら 成長とは、判断を任せられる範囲が広がること ジュニア 定義された課題を完遂 + 自分のことばで説明できる ミドル 曖昧さを含む課題を設計〜検証まで

    + スコープを判断できる シニア 課題領域ごと持つ + 人とAI のシステムの設計者になる レイヤーの定義は不変。AI で各レイヤーに渡せる抽象度が一段上がった。 評価から、育成へ