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

by KOGA Masanori

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

狙い

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

まとめ

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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