最近、評価が難しくなった ── 変わったのは評価項目ではなく、見方と見せ方_Mitsui

EMのためのAI時代におけるエンジニア育成・評価論ーUPSIDER×TOKIUM×ウォンテッドリーでMitsuiさんが登壇した資料です。
https://wantedly.connpass.com/event/395454/

Transcript

1. 最近、評価が難しくなった ── 変わったのは評価項目ではなく、見方と見せ方
2. あるSlack での出来事 # 雑談- 成果報告 M member 今日 14:32 こんなことやりました！🎉 問い合わせ対応で毎回手作業だった集計、自動化しました。今後は誰でもワンクリックで出せます。 👍 2 🎉 1 問題提起
3. しれっとすごい頑張り、拾えていますか？ ── そして、評価に乗せられていますか？
4. 評価は、両方向にズレやすくなった 過大評価 「短時間でこの量、すごい！」 → AI がすごいだけかもしれない 過小評価 「AI 使ったなら簡単でしょ」 → 本人の判断や工夫を見落とす どちらのズレも、見ているのは「成果物」だけ AI 時代の評価のズレ
5. AI によって、エンジニアの仕事の何が変わったのか Section
6. エンジニアの仕事の全体像 ① 課題発見・定義 何を解くべきか → ② 解法の設計・判断 どう解くか → ③ 実装・遂行 形にする → ④ 検証・価値確認 価値になったか → ⑤ 運用・保守・品質 回し続ける 参考: ソフトウェア開発ライフサイクル（SDLC ） aws.amazon.com/jp/what-is/sdlc ／ Dropbox Engineering Career Framework dropbox.github.io/dbx-career-framework 5 つの段階
7. AI はどこを圧縮したか ① 課題発見・定義 調査・情報収集 一部圧縮 → ② 解法の設計・判断 判断は人が担う 圧縮されない → ③ 実装・遂行 生産速度が上がる 大きく圧縮 → ④ 検証・価値確認 テスト生成 一部圧縮 → ⑤ 運用・保守・品質 責任は人が持つ 圧縮されない AI が圧縮したのは「作業」 。 「判断」と「責任」は圧縮されていない。 変化の中身
8. だから、ウェイトが移った 評価項目は変わっていない。変わったのは比重。 これまで ① 課題発見 ② 設計判断 ③ 実装・遂行 ④ 検証 ⑤ 運用 これから ① 課題発見 ② 設計判断 ③ 実装 ④ 検証 ⑤ 運用 作業から、判断と責任へ 比重の変化
9. もう一つ変わったもの ── 「見え方」 これまで実力を推定してきた「ものさし」 実装量 PR 数 作業時間 苦労の見えやすさ 時間がかかっていた ＝ 難しいことをしていた、という推定が、それなりに機能していた ✕ AI はこの推定を無効化した AI が壊したのは評価項目ではなく、代理指標。 だから、判断そのものを直接見に行くしかない 代理指標
10. 評価項目は、各社どう書いているか それぞれの言葉、それぞれの切り方のまま並べる 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/… 専門性 戦略性 業務遂行力 オーナーシップ フォロワーシップ 技術だけを見るラダーは、存在しない どのフレームワークも、技術とそれ以外の能力・責任で人を見てきた 実例
11. 評価項目が見てきたのは、 成果物ではなく、人に宿る能力 その中身は、AI でも変わらない。変わったのは、現れる場所と見え方
12. 1on1 で、こう言われたら あなたなら、どう評価しますか？ 今回、技術的にかなり難しい実装をやり切りました！ ケース
13. 主張を、さっきの図に置いてみる ① 課題発見・定義 → ② 解法の設計・判断 → ③ 実装・遂行 主張はここ → ④ 検証・価値確認 → ⑤ 運用・保守・品質 ① その難しさは、どの課題が要求したのか ② もっと簡単な解はなかったのか。なぜこれを選んだのか ④ 結果、何が変わったのか ⑤ その難しさは、運用に耐えるのか 難しさは、判断とセットで初めて価値になる ケース
14. 「何を選ぶか」の重みが、上がっている 選択肢を比べるコストが、下がった これまでの判断は、チームの知識と経験の範囲に縛られがちだった。AI 以降、選択肢の網羅的な調査と比較が現実的になった 運用してみないと分からない部分は残る。それでも、以前より把握しやすい ボトルネックが、実装から判断へ移った 作る速さは各社に行き渡り、同質化していく。同じ時間を与えられたとき、何を選ぶかが差になる 積み上げるだけでは、負債になる 作った量は価値を保証しない。アウトカムにつながらない機能は、むしろ問題や負債になる。ビルドトラップと呼ばれる状態 参考: Melissa Perri 『プロダクトマネジメント ― ビルドトラップを避け顧客に価値を届ける』 　www.oreilly.co.jp/books/9784873119250/ AI と意思決定
15. 最近よく見ているのは、取捨選択とその根拠 評価項目を増やしたのではなく、①と②へのウェイトの話 ① 課題発見・定義 なぜ他ではなく、この課題・この順番なのか それを先にやることで、価値の最大化を図れているか ② 解法の設計・判断 選択肢を比べた上で、なぜその解なのか 比較したうえでの理由を、過程ごと語れるか 自分のことばで、説明できるか 個人的な実感
16. ここからは、日々の運用 見る側は見方を、見せる側は見せ方を、 アップデートする Section
17. 評価の納得感には、原則がある AI 以前から、マネジメントの世界で言われてきたこと 手続き的公正 納得感は、評価の結果ではなく、プロセスの公正さと透明性から生まれる 組織心理学で繰り返し実証されてきた定説 No Surprises 評価面談で、初めて聞く指摘があってはならない 評価は期末のイベントではなく、期初の合意と日々の会話の積分 目標設定理論 具体的な目標の事前合意と、継続的なフィードバックが、成果と受容度を高める Locke & Latham この原則は、AI で変わらない。変わったのは、実行の難度と頻度。 評価の原則
18. 目標という「共通プロトコル」 目標を通じて、これを合意しておく 1 期待 何を任せ、何を期待しているか 2 現在地 何ができていて、何が足りないと見ているか 3 期待超えの定義 何をもって「期待を超えた」とするか 目標が実態とズレた・形骸化した → 評価を曲げるのではなく、まず目標を見直す 成果が速く細かく出る時代 → 目標のメンテナンス頻度も上げる 実践の土台
19. KPT で、成果と判断を言語化してもらう 評価をきちんとトラッキングしたいメンバーや、お互いの目線がまだ合っていないメンバーと、2 週間単位でKPT を書き出して一緒に深掘りしている Keep よかったこと・続けたいこと 小さな成果が言葉になる Problem うまくいかなかったこと 困りごとと判断の背景が見える Try 次にやること 次の期待を合意できる 代理指標に頼らず、成果と判断を直接拾う場になる 見る側
20. シニアとの1on1 こそ、成果が埋もれる シニアなメンバーとの1on1 は困りごとベースの会話になりがちで、本人の成果があえて話題に上がらない。自走できる人ほど「しれ っとすごい」が起きやすい。 Brag Document 日々の成果・判断を本人が書き溜め、1on1 のたびに一緒に見る。 シニアなメンバー向けに、いま試そうと思っている取り組み。 埋もれやすい人ほど、成果を残す仕組みで拾う 見る側
21. EM は、被評価者の成果を見逃したくない 1 「作ったもの」ではなく「変えたこと」で語る 2 何を選び、なぜそうしたかを自分のことばで語る 3 目標外の成果こそ、しれっとせずに自分から言う その一言が、評価のズレを防ぐ 見せる側
22. AI 時代の「成長」とは 評価が「判断を見る」ことなら 成長とは、判断を任せられる範囲が広がること ジュニア 定義された課題を完遂 ＋ 自分のことばで説明できる ミドル 曖昧さを含む課題を設計〜検証まで ＋ スコープを判断できる シニア 課題領域ごと持つ ＋ 人とAI のシステムの設計者になる レイヤーの定義は不変。AI で各レイヤーに渡せる抽象度が一段上がった。 評価から、育成へ
23. 今日の話を 3 行でまとめると 1 評価項目は変わっていない 変わったのは、能力が現れる場所と見え方 2 見る側は、取捨選択とその根拠を問う 代理指標は壊れた。なぜこの課題か、なぜその解か 3 見せる側は、判断を自分のことばで残す 目標のすり合わせを土台に、KPT や Brag Document で 総括
24. AI を使ったかではなく、 AI を使って何を前に進めたか。