エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017

Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017

Transcript

1. ΤϯδχΞͷٕज़ྗධՁ͸೉͍͠ʁ
   ೥ؒӡ༻͖ٕͯͨ͠ज़ྗධՁ੍౓ͷվળͷྺ࢙ r
   খլ ণ๏ !NBLPHB
   
   +BO !3FHJPOBM4$36.("5)&3*/(5PLZP
   

   View Slide

2. ⼩賀 昌法(KOGA Masanori) #CTO #VOYAGE GROUP
   2010年7⽉
   CTOに就任
   ★
   2016年10月26日 平成28年9月期 通期決算説明資料より抜粋
   https://voyagegroup.com/
   

   View Slide

3. CTO就任からやってきたこと
   l 新卒採⽤強化
   l 中途採⽤強化
   l 新卒研修改善
   l 能⼒評価制度構築
   l 情報セキュリティ委員会
   l アジャイル戦略室
   l システム本部⻑
   • サービスインフラ
   • 社内インフラ
   l 中国開発拠点⽴ち上げ
   l アドテク⼦会社CTO
   l HR⼦会社技術強化
   l などなど
   

   View Slide

4. http://techlog.voyagegroup.com/entry/2015/12/24/125931 https://seleck.cc/834
   ⼩賀 昌法(KOGA Masanori) #CTO #VOYAGE GROUP
   

   View Slide

5. Agenda
   Part 1. 技術⼒評価会を始めたきっかけ
   Part 2. 5年間の改善の歴史
   Part 3. 制度を改善していくコツ
   

   View Slide

6. l 短期的なスピードの重視
   l エンジニア評価の納得感
   l 採⽤・育成・評価の価値観の統⼀
   CTO就任時に感じていた課題 – 2010年7⽉
   

   View Slide

7. このような課題の解決策として
   チームを越えた技術⼒評価制度
   『技術⼒評価会』を検討した。
   

   View Slide

8. 技術⼒評価会とは
   l エンジニアによるチームを越えた技術⼒評価の仕組み
   l 評価結果は昇格に⼤きく影響する
   l 半年に1度実施
   l 2011年から継続
   

   View Slide

9. 昇格とグレード
   l 昇格とはグレードが上がること
   l グレードは4段階
   Ø 専⾨職(スペシャリスト)であれ
   ば P1->S2->S3->S4
   l 誰がどのグレードなのかは
   社内に公開されている
   グレード4
   グレード3
   グレード2
   グレード1
   

   View Slide

10. 実績評価
    部署A
    部署B 部署C
    チームを越えた技術⼒評価とは
    l 例1
    Ø 被評価者
    • 部署A 鈴⽊さん
    Ø 評価者
    • 部署B ⼭⽥さん
    • 部署C 佐藤さん
    l 例2
    Ø 被評価者
    • 部署B 村岡さん
    Ø 評価者
    • 部署A 鈴⽊さん
    • 部署C 佐藤さん
    能⼒
    評価
    鈴⽊
    佐藤
    村岡
    ⼭⽥
    

    View Slide

11. チームを越えた技術⼒評価とは
    l 評価者は2⼈
    l 事前準備
    Ø 被評価者は評価会の1週間
    前に資料を提出
    l 当⽇
    Ø 1時間30分
    Ø 被評価者がプレゼン
    Ø 評価者との質疑応答
    l 後⽇
    Ø 評価者は評価結果を提出
    Ø 被評価者にフィードバック
    

    View Slide

12. 狙い
    

    View Slide

13. 実績評価
    部署A
    部署B 部署C
    チームを越えた技術⼒評価の狙い
    能⼒
    評価
    鈴⽊
    佐藤
    村岡
    ⼭⽥
    l グレードの⾼いさまざまなエンジニアからの指摘
    l 中⻑期的な視点を定期的に考える機会
    l 他チームの考え⽅や技術的なノウハウを知る
    [課題] 短期的なスピードの重視
    

    View Slide

14. 実績評価
    部署A
    部署B 部署C
    チームを越えた技術⼒評価の狙い
    能⼒
    評価
    鈴⽊
    佐藤
    村岡
    ⼭⽥
    l リスペクトできるエンジニアからの技術⼒評価
    l ⾃⾝の⾔葉でしっかり説明できる場
    l 評価結果はテキスト＆対⾯フィードバック
    [課題] エンジニア評価の納得感
    

    View Slide

15. 実績評価
    部署A
    部署B 部署C
    チームを越えた技術⼒評価の狙い
    能⼒
    評価
    鈴⽊
    佐藤
    村岡
    ⼭⽥
    l 評価軸をベースに考える
    l 質疑応答を繰り返すことで価値観が擦り合う
    l 評価する側を経験することで新たな視点が持てる
    [課題] 採⽤・育成・評価の価値観の統⼀
    

    View Slide

16. このような狙いを持ち、
    2010年にフィージビリティを⾏い、
    2011年から正式な制度として
    技術⼒評価会を5年以上継続している。
    

    View Slide

17. Agenda
    Part 1. 技術⼒評価会を始めたきっかけ
    Part 2. 5年間の改善の歴史
    Part 3. 制度を改善していくコツ
    

    View Slide

18. 全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    技術⼒評価会の流れ – 2011年
    

    View Slide

19. 2011年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    2016年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    全体
    ふりかえり
    改
    善
    改
    善
    改
    善
    改
    善
    改
    善
    

    View Slide

20. 5年間のさまざまな改善
    l 全体ガイダンス
    l スケジュール調整
    l 評価者割り当て
    l 評価軸
    l サポーター
    l 評価会の事前資料
    l 評価会のすぶり
    l 評価会の参加者
    l 評価結果の公開
    l 個別フィードバック
    l 全体フィードバック
    • 部⾨⻑へ
    • ⼈事へ
    • CEOへ
    l 全体ふりかえり
    l などなど
    

    View Slide

21. 5年間で変えたことから3つを抜粋
    l 評価軸
    l 全体ふりかえり
    l 評価結果の公開
    

    View Slide

22. 2011年の評価軸
    l 事業・サービスの理解度
    l プロジェクトごとの要件・制約
    の理解度
    l 変更容易性
    l 可⽤性
    l 性能
    l セキュリティ
    l テスト容易性
    評価軸を策定するにあたって
    下記を意識した。
    l ⽂化として根付いてほしいこと
    l いま重視したいこと
    

    View Slide

23. l 事業・サービスの理解度
    l プロジェクトごとの要件・制約の理解度
    l 変更容易性
    l 可⽤性
    l 性能
    l セキュリティ
    l テスト容易性
    2011年の評価軸
    ⽂化として根付いてほしいこと
    

    View Slide

24. l 事業・サービスの理解度
    l プロジェクトごとの要件・制約の理解度
    l 変更容易性
    l 可⽤性
    l 性能
    l セキュリティ
    l テスト容易性
    2011年の評価軸
    いま重視したいこと
    

    View Slide

25. 2011年の評価結果テンプレート
    ■結果(5段階、5が⼀番良い)
    - サービスの理解度 ：(点数＋コメント)
    - 要件・制約の理解度：(点数＋コメント)
    - 変更容易性 ：(点数＋コメント)
    - 可⽤性 ：(点数＋コメント)
    - 性能 ：(点数＋コメント)
    - セキュリティ ：(点数＋コメント)
    - テスト容易性 ：(点数＋コメント)
    - 総評：
    

    View Slide

26. 評価結果の実例 - セキュリティ - 2011年
    l 2点
    Ø 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で
    きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは
    わかりますが、パスワードを⽣で保存している点はさすがにいただけません。
    ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応してお
    くことをオススメします。
    l 2点
    Ø Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限
    をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ
    ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。
    l 2.5点
    Ø 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致
    命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。
    

    View Slide

27. • 2点
    • 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で
    きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは
    わかりますが、パスワードを⽣で保存している点はさすがにいただけません。
    ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応しておく
    ことをオススメします。
    • 2点
    • Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限
    をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ
    ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。
    • 2.5点
    • 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致
    命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。
    パスワードを⽣で保存
    Oracleに接続するユーザーの権限が何でもあり
    時刻だけをシードにIDを⽣成
    評価結果の実例- セキュリティ - 2011年
    パスワードを⽣で保存
    Oracleに接続するユーザーの権限が何でもあり
    時刻だけをシードにIDを⽣成
    

    View Slide

28. l 1点
    Ø ⾃動化単体テストコードなどはありませんでした。
    l 2点
    Ø 変更容易性の項でも触れたが、テスト容易性についてはまだこれから考えて
    いくようだった。
    l 2点
    Ø OracleやNetezza、Dataspiderが絡んでいるのでテストは相当しにくいと思
    うが可能な範囲でテストコードを書いても良かったと思う。
    l 2点
    Ø 本⼈も⾃覚しているとは思うが、まずは書きなれていないというのが原因の
    気がするのでもっとテストを書いて、いろんなテストの書き⽅を経験すると
    良いと思います。また、現状から⼤きく変えないとテストコードがかけない
    というわけでは無いので、きちんと経験を積んでください。結合テストも条
    件をきちんと仕様書、項⽬書に起こしてテストしてたほうがよいです。
    評価結果の実例- テスト容易性 - 2011年
    

    View Slide

29. 評価軸 - 5年間で変えたこと
    技術⼒評価会を2年間運⽤して
    変わったこと、⾒えたこと
    [+] 全体的な技術⼒が上がってきたため、わかりやすい指摘点が減った。
    [++] 特にテストやセキュリティまわり。
    [-] 評価が分けづらい評価軸がある。
    [-] 運⽤・保守案件は説明しづらい。
    

    View Slide

30. 評価軸を⼤幅に⾒直し - 2013年
    l 事業・サービスの理解度
    l プロジェクトごとの要
    件・制約の理解度
    l 変更容易性
    l 可⽤性
    l 性能
    l セキュリティ
    l テスト容易性
    l 実現⼒
    • スコープ定義
    • システム構築・運⽤
    • プロジェクトマネジメント
    l 改善⼒
    • システム的な改善
    • ビジネス的な改善
    

    View Slide

31. • 実現⼒1
    • スコープ定義(設計、システム化範囲)
    • その場しのぎの設計・実装をしてないか、先を⾒据えた設計・実装をしているか
    • 考え過ぎていないか、スピードを疎かにしていないか
    • 今必要なものにフォーカスしてるか、必要以上にコストを掛けてないか
    • まだサービスの⽅向性を試しているフェーズに⼤きく投資しようとしていないか
    • プロダクトライフサイクルに合わせた最適化
    • 実現⼒2
    • システム構築(実装とかシステム化そのもの)
    • テスト容易性、変更容易性
    • 可⽤性
    • 性能
    • セキュリティ
    • 安全な移⾏計画
    • 品質
    評価軸を⼤幅に⾒直し - 2013年
    

    View Slide

32. • 実現⼒3
    • プロジェクトマネジメント
    • 納期より早く終わらせることを強く意識しているか、後半に⾒えていないタスクが出てく
    ることを意識しているか
    • 開発以外のタスクを意識しているか、運⽤サイドへヒアリングしているか
    • 進捗を可視化しているか、遅れに早めに⼿を打てているか
    • ⾔われたまま作っていないか、よいよい解決策を提案しているか
    評価軸を⼤幅に⾒直し - 2013年
    

    View Slide

33. • 改善⼒1
    • システム的な改善
    • リファクタリング
    • 捨てる
    • ⾃動化テスト
    • ⾃動化ビルド、デプロイ
    • レガシーコードの改善
    • 運⽤コストを削減
    評価軸を⼤幅に⾒直し - 2013年
    • 改善⼒2
    • ビジネス的な改善
    • 課題から改善案(仮説)を創出
    • より早くユーザからフィードバック
    をもらう⼯夫をしているか
    • 仮説を検証
    • 検証結果から改善案を創出
    • Build→Measure→Learn→Build→・
    ・・
    

    View Slide

34. l 実現⼒
    • 何が課題で何が必要と考えたか。
    • 構築・運⽤したシステムは妥当
    か。
    • プロジェクトの進め⽅は妥当か。
    l 改善⼒
    • システム的な改善は妥当か。
    • ビジネス的な改善への貢献は妥
    当か
    l 実現⼒
    • スコープ定義
    • システム構築・運⽤
    • プロジェクトマネジ
    メント
    l 改善⼒
    • システム的な改善
    • ビジネス的な改善
    ⼀般的な⽤語ではなく⾃分たちに適した⽂章に変更した。
    評価軸を⽂章に変更 – 2014年
    

    View Slide

35. l 実現⼒
    • 何が課題で何が必要と考えたか。
    • 事業観点、ユーザ観点、技術観点を持っているか。
    • その場しのぎで考えていないか。先を⾒据えているか。
    • 考えすぎていないか。スピードをおろそかにしていないか。必要以上にコストを掛けてい
    ないか。
    • 構築・運⽤したシステムは妥当か。
    • テスト容易性、変更容易性を考慮しているか。
    • セキュリティを考慮しているか。
    • 性能、可⽤性を考慮しているか。
    • プロジェクトの進め⽅は妥当か。
    • 納期より早く終わらせることを意識してるか。後半に新しい課題に気づくことを考慮して
    るか。
    • リリース後を考慮してるか。運⽤サイドへは事前にヒアリングしてるか。
    • 情報共有は適切か。必要な情報が必要な⼈に届いているか。
    • リスクを⾒える化しているか。
    評価軸を⽂章に変更 – 2014年
    

    View Slide

36. l 改善⼒
    • システム的な改善は妥当か。
    • 技術的負債は溜まりすぎていないか。適切に返済しているか。
    • 運⽤コストやオペレーションミスを減らすために⾃動化を進めているか。
    • ビジネス的な改善への貢献は妥当か。
    • プロダクトのライフタイムを理解しているか。安易にサービス終了までと考えていないか。
    • 検証することを事前に考慮しているか。
    • 計測だけではなく可視化を意識しているか。
    評価軸を⽂章に変更 – 2014年
    

    View Slide

37. 評価軸を改善してきたことで
    事業を⽀える技術について
    コードレビューとは別の側⾯を持つ
    本質的な議論ができる場になった。
    

    View Slide

38. 評価結果の実例 – 2016年
    評価会中では「バッチの安全性」についてい
    くつか議論をしました。締め処理の安全性が
    「適切に負荷を抑えること」という議論に最
    初なっていましたが、やはり「正確に締め処
    理ができること」にスコープをもっていける
    と良いように思います。
    

    View Slide

39. 評価結果の実例 – 2016年
    システムを作ることは当然⼤事ですが、稼働後
    のシステムが安定して動き続けることもまた⼤
    事です。次はその"何か嫌なこと"を想定し、そ
    れに気がつくため、またはそれが起きても⼈が
    何もせずとも⼤丈夫なようにするためにはどう
    すれば良いのかという視点を持てるとさらによ
    くなるのではないかと思います。
    

    View Slide

40. l 短期的なスピードの重視
    l エンジニア評価の納得感
    l 採⽤・育成・評価の価値観の統⼀
    改
    善
    改
    善
    改
    善
    CTO就任時に感じていた課題 – 2010年7⽉
    

    View Slide

41. 評価軸 – 5年間で変えたこと
    状況に合わせて変えることは必然。
    これからも⾃分たちの課題に向き合い
    評価軸を改善していく。
    

    View Slide

42. 5年間で変えたことから3つを抜粋
    l 評価軸
    l 全体ふりかえり
    l 評価結果の公開
    

    View Slide

43. 2011年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    2016年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    全体
    ふりかえり
    改
    善
    改
    善
    改
    善
    改
    善
    改
    善
    再 掲
    

    View Slide

44. 2011年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    2016年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    全体
    ふりかえり
    改
    善
    改
    善
    改
    善
    改
    善
    改
    善
    再 掲
    全体
    ふりかえり
    

    View Slide

45. 全体ふりかえりのきっかけ
    2015年3⽉にCTOが、グレードの
    ⾼いエンジニアを10⼈ほど集め、
    技術⼒評価会の改善案について議論
    エンジニア全員に声をかけ
    オープンにディスカッションする
    ことにした。
    

    View Slide

46. 全体ふりかえり - 5年間で変えたこと
    2015年4⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その1
    

    View Slide

47. 2015年4⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その2
    全体ふりかえり - 5年間で変えたこと
    ※CCFBとは
    CREED
    Competency
    Feedbackの略で、
    経営理念である
    「CREED」に対し
    て、⾃⾝の⾏動に
    周囲のクルーが
    フィードバックし
    てくれる仕組みで
    す。
    

    View Slide

48. 全体ふりかえりからの変更点 – 2015年5⽉
    l サポーターをマンツーマンにした。
    Ø 今までは部署やチーム単位に複数⼈のサポーターをつけていましたが、今回
    からは被評価者AさんのサポーターはBさんのようにマンツーマンにしました。
    l 評価のコメントを公開する。コメント以外の点数などは公開しない。
    Ø 評価結果(公開版)は、tech-assessmentリポジトリで公開
    Ø 評価結果(⾮公開版)は、CTOともう1⼈の評価者に提出
    l CTOが参加する評価会は以下とする。
    Ø 被評価者が初めて、もしくは評価者のいずれかが評価者として初めて。
    l CTOからの個別フィードバックは以下とする。
    Ø 初めて評価を受けた被評価者、もしくは初めて評価した評価者
    l 被評価者の要望があれば評価者から対⾯でフィードバックを⾏う。
    

    View Slide

49. 2015年11⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その1
    全体ふりかえり - 5年間で変えたこと
    

    View Slide

50. 2015年11⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その2
    全体ふりかえり - 5年間で変えたこと
    

    View Slide

51. 全体ふりかえりからの変更点 – 2015年11⽉
    l 評価結果(⾮公開版)を廃⽌した。
    l 事前にやることを追加した。
    Ø 被評価者と評価者2⼈でコミュニケーションする場を作る。
    Ø 評価者は、必要に応じて被評価者およびもう1⼈の評価者とコミュニケーショ
    ンをとる。また、必要に応じて被評価者のサポーターにヒアリングする。
    Ø 被評価者とサポーターが相談し、評価会の質を上げるために本当に必要であ
    ればすぶりを⾏う。
    l 事後にやることを追加した。
    Ø 評価会直後に評価者2名ですり合わせを⾏う。
    Ø 評価者2名とCTOのすり合わせを⾏う。
    l 被評価者と評価者2⼈の対⾯フィードバックを⾏う。
    l 評価結果をチームメンバーで共有し、改善に繋げていく。
    

    View Slide

52. 2016年3⽉にCTOから⼤きな変更案を出した。
    全体ふりかえり - 5年間で変えたこと
    評価者を2⼈から1⼈に変更する。
    

    View Slide

53. 2016年3⽉にCTOから⼤きな変更案を出した。
    全体ふりかえり - 5年間で変えたこと
    評価者を2⼈から1⼈に変更する。
    撃沈 ><
    評価者がかなり時間を使うので⼤変という声が継続してあがってくるので思い切っ
    て評価者を1⼈にすることを提案したのだが、ほぼ全員からダメだしされ、評価者2
    ⼈は継続された。
    

    View Slide

54. 毎回30-40⼈が参加し、いろいろ改善案が出た。
    ⽿が痛い意⾒もあったが、ふりかえりは重要。
    全体ふりかえり - 5年間で変えたこと
    

    View Slide

55. 5年間で変えたことから3つを抜粋
    l 評価軸
    l 全体ふりかえり
    l 評価結果の公開
    

    View Slide

56. 評価結果の公開 - 5年間で変えたこと
    GitHubで
    評価結果を
    社内に公開
    

    View Slide

57. 被評価者 166⼈
    x
    評価者 2⼈ずつ
    300以上
    の評価結果が社内に公開されている。
    

    View Slide

58. 評価結果の公開 - 5年間で変えたこと
    l 評価結果が公開されることで「評
    価者もまた評価されている」とい
    う側⾯が強くなった。
    l 「評価結果を書くのがすごく⼤
    変」という声も出ている。
    https://twitter.com/nekoya/status/781689637811081217
    http://b.hatena.ne.jp/entry/s/seleck.cc/834
    

    View Slide

59. 評価結果の公開 - 5年間で変えたこと
    評価結果の公開に合わせて、評価軸ごとの点数を廃⽌し、
    総評とアドバイスをしっかり書くようにした。
    被評価者の納得度と評価者の成⻑
    につなげていく。
    

    View Slide

60. Agenda
    Part 1. 技術⼒評価会を始めたきっかけ
    Part 2. 5年間の改善の歴史
    Part 3. 制度を改善していくコツ
    

    View Slide

61. 制度を改善していくコツ
    l 期待値を合わせる
    l ケツ持ちを明確にする
    l ⼩さく挑戦していく
    

    View Slide

62. 制度を改善していくコツ
    l 期待値を合わせる
    l ケツ持ちを明確にする
    l ⼩さく挑戦していく
    

    View Slide

63. CEO、⼈事担当役員、
    その他ステークホルダーと
    期待値を合わせる。
    

    View Slide

64. l 短期的なスピードの重視
    l エンジニア評価の納得感
    l 採⽤・育成・評価の価値観の統⼀
    CTO就任時に感じていた課題 – 2010年7⽉
    再 掲
    

    View Slide

65. • 短期的なスピードの重視
    • エンジニア評価の納得感
    • 採⽤・育成・評価の価値観の統⼀
    CTO就任時に感じていた課題 – 2010年7⽉
    再 掲
    個別の課題をもぐらたたきするのではなく
    企業⽂化や戦略に基づきながら改善
    していこうとCEOおよび⼈事担当役員と話した。
    ただし、それには時間が掛かるよね
    という話とセットで。
    

    View Slide

66. 期待値を合わせる
    CEO、⼈事担当役員、その他ステークホルダーと
    ゴールイメージと期間の
    期待値を合わせる。
    

    View Slide

67. 制度を改善していくコツ
    l 期待値を合わせる
    l ケツ持ちを明確にする
    l ⼩さく挑戦していく
    

    View Slide

68. 297回
    被評価者とCTOが1on1で
    結果フィードバックmtgを実施した回数
    

    View Slide

69. ケツ持ちを明確にする
    最初から数回は
    CTOがほぼ1⼈で運営
    

    View Slide

70. l ルール策定、評価者割り当て、スケジュール調整
    l 評価会の参加、結果確認、被評価者へのフィードバック
    l ⼈事へのフィードバック、事業責任者へのフィードバック
    ケツ持ちを明確にする
    2011年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    

    View Slide

71. CTOが運営し、現場を巻き込みながら
    改善していくことで、
    能⼒評価は⼈事だけが決めるのではなく
    エンジニア⾃⾝で考えていくこと
    という⽂化が根付いた。
    ケツ持ちを明確にする
    

    View Slide

72. 制度を改善していくコツ
    l 期待値を合わせる
    l ケツ持ちを明確にする
    l ⼩さく挑戦していく
    

    View Slide

73. コピペは危険！！
    5年かけて改善してきた今のかたちを⾒て、
    そのままコピペするのは危険ですよね。
    

    View Slide

74. l 評価軸
    Ø 最初は評価者が指摘しやすいものだった。
    l 評価結果
    Ø 結果の公開に踏み切ったのは4年後だった。
    l 対象者
    Ø ⼈数の多かったアプリケーションエンジニアから
    始め、インフラ、情シスに広げていった。
    ⼩さく挑戦していく
    

    View Slide

75. 状況に合わせて⼩さく挑戦し続け
    5年で⼤きく改善できた。
    2016年
    全体準備
    全体
    フィードバック
    評価会
    実施
    評価結果
    確認
    被評価者への
    フィードバック
    全体
    ふりかえり
    改
    善
    改
    善
    改
    善
    改
    善
    改
    善
    

    View Slide

76. まとめ
    

    View Slide

77. エンジニアの
    技術⼒評価は
    難しい？
    

    View Slide

78. エンジニアの技術⼒評価は難しい？
    簡単ではない
    

    View Slide

79. エンジニアの技術⼒評価は簡単ではない
    ですが
    

    View Slide

80. エンジニアの技術⼒評価は簡単ではないが
    関係者と期待値を合わせ
    ⼩さく挑戦していくことで
    ⼤きく改善していける
    ご清聴ありがとうございました
    

    View Slide