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

なぜ「技術力評価会」の評価者はペアなのか? - 8年半で378組の評価者ペアが835回評価した...

KOGA Masanori
February 13, 2020

なぜ「技術力評価会」の評価者はペアなのか? - 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 - / The VOYAGE GROUP technical assessment system is made by all engineers. and the effect of pair assessment.

2020年2月13日にデブサミ2020( https://event.shoeisha.jp/devsumi/20200213 )で登壇したときのスライドの公開版です。

最初はペアの効果にもっとフォーカスしようと思っていたのですが、作ってみるとペアの話だけではなく、エンジニア全体で「ともにつくる」評価制度の話になりました。

KOGA Masanori

February 13, 2020
Tweet

More Decks by KOGA Masanori

Other Decks in Technology

Transcript

  1. なぜ「技術⼒評価会」の 評価者はペアなのか? VOYAGE GROUP 取締役CTO 小賀 昌法 (@makoga) Feb 13,

    2020 @Developers Summit 2020 8年半で378組の評価者ペアが835回評価した 事例からみるペアの効果
  2. 事 業 貢 献 評 価 技 術 ⼒ 評

    価 VOYAGE GROUPは2011年までは 上⻑だけが評価する制度でした。 上長だけが評価する制度
  3. 事業部A 事業部B 事業部C 事業部D 1回⽬ 1回⽬ 2回⽬ 2回⽬ 3回⽬ 3回⽬

    4回⽬ 4回⽬ 「ともにつくる」評価制度 たとえば、左下の⼈は 2年間で8⼈から技術⼒評価をされました。 事 業 貢 献 評 価
  4. 原因2: 技術の多様化 ・フロントエンド(Web, iOS, Android) ・クラウドサービス(AWS, GCP, etc) ・データサイエンス ・プライバシー

    ・等々… 技術は多様化しており、技術マネージャは全ての技術 においてメンバーより詳しいわけではない。 現在では1つのシステムに 必要な技術は多岐にわたる。 https://www.gartner.com/jp/newsroom/press-releases/pr-20190830
  5. Agenda Part 1. 評価と人事制度 Part 2. 技術力評価会の概要 Part 3. ペアで評価すること、

    組み合わせを 毎回変えることの効果 まずは評価と⼈事制度。 評価というのは⼈事制度の1つなので 最初に全体像をつかんでおきます。
  6. 1.評価と人事制度 グレードの例: VOYAGE GROUP 事業貢献 能⼒ CREED グレード4 グレード3 グレード2

    グレード1 ଓ͖͸"+*50Ͱʂ ฐࣾͷࣗຫͷࣾ಺όʔ"+*50Ͱͷ ΠϕϯτͰ͸͓ݟͤ͠·͢ɻ
  7. 2.技術力評価会の概要 評価の流れ Xxxxx Xxxxx Xxxxx Xxxxx Xxxxx Xxxxx Xxxxx Xxxxx

    ・評価者は評価結果を CTO、担当評価委員、 もう1人の評価者に共有し、 4人ですり合わせ 後日
  8. 事 業 貢 献 事業部A 事業部B 事業部C 事業部D 技 術

    ⼒ 評 価 技 術 ⼒ 評 価 ճ໨  ೥ؒͰਓҎ্͔ΒධՁ͞ΕΔ
  9. 事 業 貢 献 事業部A 事業部B 事業部C 事業部D 技 術

    ⼒ 評 価 技 術 ⼒ 評 価 ճ໨  ೥ؒͰਓҎ্͔ΒධՁ͞ΕΔ
  10. 事 業 貢 献 事業部A 事業部B 事業部C 事業部D 技 術

    ⼒ 評 価 技 術 ⼒ 評 価 ճ໨  ೥ؒͰਓҎ্͔ΒධՁ͞ΕΔ
  11. 事 業 貢 献 事業部A 事業部B 事業部C 事業部D 技 術

    ⼒ 評 価 技 術 ⼒ 評 価 ճ໨  ೥ؒͰਓҎ্͔ΒධՁ͞ΕΔ
  12. 2.技術力評価会の概要 評価軸 ・事業・サービスの理解度 ・プロジェクトごとの要件、 制約の理解度 ・変更容易性 ・可用性 ・性能 ・セキュリティ ・テスト容易性

    ・実現力 ・スコープ定義 ・システム構築・運用 ・プロジェクトマネジメント ・改善力 ・システム的な改善 ・ビジネス的な改善 2011年の評価軸 2013年の評価軸
  13. 2.技術力評価会の概要 評価軸 ・実現力 ・スコープ定義 ・システム構築・運用 ・プロジェクトマネジメント ・改善力 ・システム的な改善 ・ビジネス的な改善 2013年の評価軸

    ・実現力 ・何が課題で何が必要と考えたか。 ・構築・運用したシステムは妥当か。 ・プロジェクトの進め方は妥当か。 ・改善力 ・システム的な改善は妥当か。 ・ビジネス的な改善への貢献は妥当か。 2014年の評価軸
  14. 2.技術力評価会の概要 評価軸 開始から2年後に大幅に見直し、 さらにその1年後に文章を変更した。 ・実現力 ・スコープ定義 ・システム構築・運用 ・プロジェクトマネジメント ・改善力 ・システム的な改善

    ・ビジネス的な改善 2013年の評価軸 ・実現力 ・何が課題で何が必要と考えたか。 ・構築・運用したシステムは妥当か。 ・プロジェクトの進め方は妥当か。 ・改善力 ・システム的な改善は妥当か。 ・ビジネス的な改善への貢献は妥当か。 2014年の評価軸 ・事業・サービスの理解度 ・プロジェクトごとの要件、 制約の理解度 ・変更容易性 ・可用性 ・性能 ・セキュリティ ・テスト容易性 2011年の評価軸
  15. 2.技術力評価会の概要 評価結果テンプレート 2015年から点数を廃止し、 しっかり文章を書くように ▪結果(5段階、5が一番良い) - サービスの理解度 :(点数+コメント) - 要件・制約の理解度:(点数+コメント)

    - 変更容易性 :(点数+コメント) - 可用性 :(点数+コメント) - 性能 :(点数+コメント) - セキュリティ :(点数+コメント) - テスト容易性 :(点数+コメント) - 総評: ▪総評 (しっかり書く) ▪成長へのアドバイス (しっかり書く) ---- (以降は任意) 各評価軸への具体的なコメント ▪実現力1: 何が課題で何が必要と考えたか。 ・[+] 良かった点 ・[?] 気になった点 ・補足 ▪実現力2: ・・・ ▪改善力1: ・・・ 2011年 2015年
  16. もっと技術⼒評価会を知りたい⼈へ • エンジニアの技術⼒評価は難しい? - 7年間運⽤してきた技術⼒評価制度の改善の歴史 - Ø 「5分でわかる技術⼒評価会」の元ネタで、ページ数は2倍くらい。 • 適切な技術⼒評価をするために⼯夫していること。プレゼンスキルだけが⾼い⼈が過剰に評価されないた

    めに。 Ø 上記「エンジニアの技術⼒評価は難しい︖」を公開したときにもらった「プレゼンスキルだけが⾼い ⼈が過剰に評価されるのでは︖」的なコメントへの回答。 • #phpcon2018 でVOYAGE GROUPのエンジニア評価制度ってどんな感じなのか再演しました︕(資料・ 動画あり) Ø ミニ再演の動画リンクがあります。動画だと雰囲気が伝わりやすいですね。 • 技術⼒評価会、外部評価者運営レポート Ø 急遽開催された社外評価者の持ち込み評価会についても記載されてます。 • VOYAGEのエンジニア評価制度の全貌。「技術⼒評価会」による、⼈が育つ組織の作り⽅ Speaker Deckの説明欄に下記説明と資料へのリンクを記載してあります。
  17. 原因2: 技術の多様化 ・フロントエンド(Web, iOS, Android) ・クラウドサービス(AWS, GCP, etc) ・データサイエンス ・プライバシー

    ・等々… 技術は多様化しており、技術マネージャは全ての技術 においてメンバーより詳しいわけではない。 現在では1つのシステムに 必要な技術は多岐にわたる。 https://www.gartner.com/jp/newsroom/press-releases/pr-20190830 再掲
  18. 事業部A 事業部B 事業部C 事業部D 選定 選 定 原因2: 技術の多様化 対策

    被評価者の強みに合わせて、評価者をアサイン ・被評価者の強みに合わせて、 その技術に強い人をアサイン ・上記の人の弱みを補完できる人とペアを組む ・社内にいない場合は社外から招聘
  19. 原因2: 技術の多様化 技術力評価会の評価者は毎回異なる 事業部A 事業部B 事業部C 事業部D 1回⽬ 1回⽬ 2回⽬

    2回⽬ 3回⽬ 3回⽬ 4回⽬ 4回⽬ 原因4: 同じ人が長く評価することでの偏り 対策