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

Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017

Transcript

1. ΤϯδχΞͷٕज़ྗධՁ͸೉͍͠ʁ  ೥ؒӡ༻͖ٕͯͨ͠ज़ྗධՁ੍౓ͷվળͷྺ࢙ r খլ ণ๏ !NBLPHB +BO
   
   
   !
   3FHJPOBM
   4$36.
   ("5)&3*/(
   5PLZP
   
2. ⼩賀 昌法(KOGA Masanori) #CTO #VOYAGE GROUP 2010年7⽉ CTOに就任 ★ 2016年10月26日 平成28年9月期 通期決算説明資料より抜粋 https://voyagegroup.com/
3. CTO就任からやってきたこと l 新卒採⽤強化 l 中途採⽤強化 l 新卒研修改善 l 能⼒評価制度構築 l 情報セキュリティ委員会 l アジャイル戦略室 l システム本部⻑ • サービスインフラ • 社内インフラ l 中国開発拠点⽴ち上げ l アドテク⼦会社CTO l HR⼦会社技術強化 l などなど
4. http://techlog.voyagegroup.com/entry/2015/12/24/125931 https://seleck.cc/834 ⼩賀 昌法(KOGA Masanori) #CTO #VOYAGE GROUP
5. Agenda Part 1. 技術⼒評価会を始めたきっかけ Part 2. 5年間の改善の歴史 Part 3. 制度を改善していくコツ
6. l 短期的なスピードの重視 l エンジニア評価の納得感 l 採⽤・育成・評価の価値観の統⼀ CTO就任時に感じていた課題 – 2010年7⽉
7. このような課題の解決策として チームを越えた技術⼒評価制度 『技術⼒評価会』を検討した。
8. 技術⼒評価会とは l エンジニアによるチームを越えた技術⼒評価の仕組み l 評価結果は昇格に⼤きく影響する l 半年に1度実施 l 2011年から継続
9. 昇格とグレード l 昇格とはグレードが上がること l グレードは4段階 Ø 専⾨職(スペシャリスト)であれ ば P1->S2->S3->S4 l 誰がどのグレードなのかは 社内に公開されている グレード4 グレード3 グレード2 グレード1
10. 実績評価 部署A 部署B 部署C チームを越えた技術⼒評価とは l 例1 Ø 被評価者 • 部署A 鈴⽊さん Ø 評価者 • 部署B ⼭⽥さん • 部署C 佐藤さん l 例2 Ø 被評価者 • 部署B 村岡さん Ø 評価者 • 部署A 鈴⽊さん • 部署C 佐藤さん 能⼒ 評価 鈴⽊ 佐藤 村岡 ⼭⽥
11. チームを越えた技術⼒評価とは l 評価者は2⼈ l 事前準備 Ø 被評価者は評価会の1週間 前に資料を提出 l 当⽇ Ø 1時間30分 Ø 被評価者がプレゼン Ø 評価者との質疑応答 l 後⽇ Ø 評価者は評価結果を提出 Ø 被評価者にフィードバック
12. 狙い
13. 実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡 ⼭⽥ l グレードの⾼いさまざまなエンジニアからの指摘 l 中⻑期的な視点を定期的に考える機会 l 他チームの考え⽅や技術的なノウハウを知る [課題] 短期的なスピードの重視
14. 実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡 ⼭⽥ l リスペクトできるエンジニアからの技術⼒評価 l ⾃⾝の⾔葉でしっかり説明できる場 l 評価結果はテキスト＆対⾯フィードバック [課題] エンジニア評価の納得感
15. 実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡 ⼭⽥ l 評価軸をベースに考える l 質疑応答を繰り返すことで価値観が擦り合う l 評価する側を経験することで新たな視点が持てる [課題] 採⽤・育成・評価の価値観の統⼀
16. このような狙いを持ち、 2010年にフィージビリティを⾏い、 2011年から正式な制度として 技術⼒評価会を5年以上継続している。
17. Agenda Part 1. 技術⼒評価会を始めたきっかけ Part 2. 5年間の改善の歴史 Part 3. 制度を改善していくコツ
18. 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 技術⼒評価会の流れ – 2011年
19. 2011年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 2016年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 全体 ふりかえり 改 善 改 善 改 善 改 善 改 善
20. 5年間のさまざまな改善 l 全体ガイダンス l スケジュール調整 l 評価者割り当て l 評価軸 l サポーター l 評価会の事前資料 l 評価会のすぶり l 評価会の参加者 l 評価結果の公開 l 個別フィードバック l 全体フィードバック • 部⾨⻑へ • ⼈事へ • CEOへ l 全体ふりかえり l などなど
21. 5年間で変えたことから3つを抜粋 l 評価軸 l 全体ふりかえり l 評価結果の公開
22. 2011年の評価軸 l 事業・サービスの理解度 l プロジェクトごとの要件・制約 の理解度 l 変更容易性 l 可⽤性 l 性能 l セキュリティ l テスト容易性 評価軸を策定するにあたって 下記を意識した。 l ⽂化として根付いてほしいこと l いま重視したいこと
23. l 事業・サービスの理解度 l プロジェクトごとの要件・制約の理解度 l 変更容易性 l 可⽤性 l 性能 l セキュリティ l テスト容易性 2011年の評価軸 ⽂化として根付いてほしいこと
24. l 事業・サービスの理解度 l プロジェクトごとの要件・制約の理解度 l 変更容易性 l 可⽤性 l 性能 l セキュリティ l テスト容易性 2011年の評価軸 いま重視したいこと
25. 2011年の評価結果テンプレート ▪結果(5段階、5が⼀番良い) - サービスの理解度 ：(点数＋コメント) - 要件・制約の理解度：(点数＋コメント) - 変更容易性 ：(点数＋コメント) - 可⽤性 ：(点数＋コメント) - 性能 ：(点数＋コメント) - セキュリティ ：(点数＋コメント) - テスト容易性 ：(点数＋コメント) - 総評：
26. 評価結果の実例 - セキュリティ - 2011年 l 2点 Ø 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは わかりますが、パスワードを⽣で保存している点はさすがにいただけません。 ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応してお くことをオススメします。 l 2点 Ø Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限 をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。 l 2.5点 Ø 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致 命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。
27. • 2点 • 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは わかりますが、パスワードを⽣で保存している点はさすがにいただけません。 ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応しておく ことをオススメします。 • 2点 • Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限 をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。 • 2.5点 • 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致 命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。 パスワードを⽣で保存 Oracleに接続するユーザーの権限が何でもあり 時刻だけをシードにIDを⽣成 評価結果の実例- セキュリティ - 2011年 パスワードを⽣で保存 Oracleに接続するユーザーの権限が何でもあり 時刻だけをシードにIDを⽣成
28. l 1点 Ø ⾃動化単体テストコードなどはありませんでした。 l 2点 Ø 変更容易性の項でも触れたが、テスト容易性についてはまだこれから考えて いくようだった。 l 2点 Ø OracleやNetezza、Dataspiderが絡んでいるのでテストは相当しにくいと思 うが可能な範囲でテストコードを書いても良かったと思う。 l 2点 Ø 本⼈も⾃覚しているとは思うが、まずは書きなれていないというのが原因の 気がするのでもっとテストを書いて、いろんなテストの書き⽅を経験すると 良いと思います。また、現状から⼤きく変えないとテストコードがかけない というわけでは無いので、きちんと経験を積んでください。結合テストも条 件をきちんと仕様書、項⽬書に起こしてテストしてたほうがよいです。 評価結果の実例- テスト容易性 - 2011年
29. 評価軸 - 5年間で変えたこと 技術⼒評価会を2年間運⽤して 変わったこと、⾒えたこと [+] 全体的な技術⼒が上がってきたため、わかりやすい指摘点が減った。 [++] 特にテストやセキュリティまわり。 [-] 評価が分けづらい評価軸がある。 [-] 運⽤・保守案件は説明しづらい。
30. 評価軸を⼤幅に⾒直し - 2013年 l 事業・サービスの理解度 l プロジェクトごとの要 件・制約の理解度 l 変更容易性 l 可⽤性 l 性能 l セキュリティ l テスト容易性 l 実現⼒ • スコープ定義 • システム構築・運⽤ • プロジェクトマネジメント l 改善⼒ • システム的な改善 • ビジネス的な改善
31. • 実現⼒1 • スコープ定義(設計、システム化範囲) • その場しのぎの設計・実装をしてないか、先を⾒据えた設計・実装をしているか • 考え過ぎていないか、スピードを疎かにしていないか • 今必要なものにフォーカスしてるか、必要以上にコストを掛けてないか • まだサービスの⽅向性を試しているフェーズに⼤きく投資しようとしていないか • プロダクトライフサイクルに合わせた最適化 • 実現⼒2 • システム構築(実装とかシステム化そのもの) • テスト容易性、変更容易性 • 可⽤性 • 性能 • セキュリティ • 安全な移⾏計画 • 品質 評価軸を⼤幅に⾒直し - 2013年
32. • 実現⼒3 • プロジェクトマネジメント • 納期より早く終わらせることを強く意識しているか、後半に⾒えていないタスクが出てく ることを意識しているか • 開発以外のタスクを意識しているか、運⽤サイドへヒアリングしているか • 進捗を可視化しているか、遅れに早めに⼿を打てているか • ⾔われたまま作っていないか、よいよい解決策を提案しているか 評価軸を⼤幅に⾒直し - 2013年
33. • 改善⼒1 • システム的な改善 • リファクタリング • 捨てる • ⾃動化テスト • ⾃動化ビルド、デプロイ • レガシーコードの改善 • 運⽤コストを削減 評価軸を⼤幅に⾒直し - 2013年 • 改善⼒2 • ビジネス的な改善 • 課題から改善案(仮説)を創出 • より早くユーザからフィードバック をもらう⼯夫をしているか • 仮説を検証 • 検証結果から改善案を創出 • Build→Measure→Learn→Build→・ ・・
34. l 実現⼒ • 何が課題で何が必要と考えたか。 • 構築・運⽤したシステムは妥当 か。 • プロジェクトの進め⽅は妥当か。 l 改善⼒ • システム的な改善は妥当か。 • ビジネス的な改善への貢献は妥 当か l 実現⼒ • スコープ定義 • システム構築・運⽤ • プロジェクトマネジ メント l 改善⼒ • システム的な改善 • ビジネス的な改善 ⼀般的な⽤語ではなく⾃分たちに適した⽂章に変更した。 評価軸を⽂章に変更 – 2014年
35. l 実現⼒ • 何が課題で何が必要と考えたか。 • 事業観点、ユーザ観点、技術観点を持っているか。 • その場しのぎで考えていないか。先を⾒据えているか。 • 考えすぎていないか。スピードをおろそかにしていないか。必要以上にコストを掛けてい ないか。 • 構築・運⽤したシステムは妥当か。 • テスト容易性、変更容易性を考慮しているか。 • セキュリティを考慮しているか。 • 性能、可⽤性を考慮しているか。 • プロジェクトの進め⽅は妥当か。 • 納期より早く終わらせることを意識してるか。後半に新しい課題に気づくことを考慮して るか。 • リリース後を考慮してるか。運⽤サイドへは事前にヒアリングしてるか。 • 情報共有は適切か。必要な情報が必要な⼈に届いているか。 • リスクを⾒える化しているか。 評価軸を⽂章に変更 – 2014年
36. l 改善⼒ • システム的な改善は妥当か。 • 技術的負債は溜まりすぎていないか。適切に返済しているか。 • 運⽤コストやオペレーションミスを減らすために⾃動化を進めているか。 • ビジネス的な改善への貢献は妥当か。 • プロダクトのライフタイムを理解しているか。安易にサービス終了までと考えていないか。 • 検証することを事前に考慮しているか。 • 計測だけではなく可視化を意識しているか。 評価軸を⽂章に変更 – 2014年
37. 評価軸を改善してきたことで 事業を⽀える技術について コードレビューとは別の側⾯を持つ 本質的な議論ができる場になった。
38. 評価結果の実例 – 2016年 評価会中では「バッチの安全性」についてい くつか議論をしました。締め処理の安全性が 「適切に負荷を抑えること」という議論に最 初なっていましたが、やはり「正確に締め処 理ができること」にスコープをもっていける と良いように思います。
39. 評価結果の実例 – 2016年 システムを作ることは当然⼤事ですが、稼働後 のシステムが安定して動き続けることもまた⼤ 事です。次はその"何か嫌なこと"を想定し、そ れに気がつくため、またはそれが起きても⼈が 何もせずとも⼤丈夫なようにするためにはどう すれば良いのかという視点を持てるとさらによ くなるのではないかと思います。
40. l 短期的なスピードの重視 l エンジニア評価の納得感 l 採⽤・育成・評価の価値観の統⼀ 改 善 改 善 改 善 CTO就任時に感じていた課題 – 2010年7⽉
41. 評価軸 – 5年間で変えたこと 状況に合わせて変えることは必然。 これからも⾃分たちの課題に向き合い 評価軸を改善していく。
42. 5年間で変えたことから3つを抜粋 l 評価軸 l 全体ふりかえり l 評価結果の公開
43. 2011年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 2016年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 全体 ふりかえり 改 善 改 善 改 善 改 善 改 善 再 掲
44. 2011年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 2016年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 全体 ふりかえり 改 善 改 善 改 善 改 善 改 善 再 掲 全体 ふりかえり
45. 全体ふりかえりのきっかけ 2015年3⽉にCTOが、グレードの ⾼いエンジニアを10⼈ほど集め、 技術⼒評価会の改善案について議論 エンジニア全員に声をかけ オープンにディスカッションする ことにした。
46. 全体ふりかえり - 5年間で変えたこと 2015年4⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その1
47. 2015年4⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その2 全体ふりかえり - 5年間で変えたこと ※CCFBとは CREED Competency Feedbackの略で、 経営理念である 「CREED」に対し て、⾃⾝の⾏動に 周囲のクルーが フィードバックし てくれる仕組みで す。
48. 全体ふりかえりからの変更点 – 2015年5⽉ l サポーターをマンツーマンにした。 Ø 今までは部署やチーム単位に複数⼈のサポーターをつけていましたが、今回 からは被評価者AさんのサポーターはBさんのようにマンツーマンにしました。 l 評価のコメントを公開する。コメント以外の点数などは公開しない。 Ø 評価結果(公開版)は、tech-assessmentリポジトリで公開 Ø 評価結果(⾮公開版)は、CTOともう1⼈の評価者に提出 l CTOが参加する評価会は以下とする。 Ø 被評価者が初めて、もしくは評価者のいずれかが評価者として初めて。 l CTOからの個別フィードバックは以下とする。 Ø 初めて評価を受けた被評価者、もしくは初めて評価した評価者 l 被評価者の要望があれば評価者から対⾯でフィードバックを⾏う。
49. 2015年11⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その1 全体ふりかえり - 5年間で変えたこと
50. 2015年11⽉に実施した全体ふりかえりで実際に出た意⾒ 抜粋その2 全体ふりかえり - 5年間で変えたこと
51. 全体ふりかえりからの変更点 – 2015年11⽉ l 評価結果(⾮公開版)を廃⽌した。 l 事前にやることを追加した。 Ø 被評価者と評価者2⼈でコミュニケーションする場を作る。 Ø 評価者は、必要に応じて被評価者およびもう1⼈の評価者とコミュニケーショ ンをとる。また、必要に応じて被評価者のサポーターにヒアリングする。 Ø 被評価者とサポーターが相談し、評価会の質を上げるために本当に必要であ ればすぶりを⾏う。 l 事後にやることを追加した。 Ø 評価会直後に評価者2名ですり合わせを⾏う。 Ø 評価者2名とCTOのすり合わせを⾏う。 l 被評価者と評価者2⼈の対⾯フィードバックを⾏う。 l 評価結果をチームメンバーで共有し、改善に繋げていく。
52. 2016年3⽉にCTOから⼤きな変更案を出した。 全体ふりかえり - 5年間で変えたこと 評価者を2⼈から1⼈に変更する。
53. 2016年3⽉にCTOから⼤きな変更案を出した。 全体ふりかえり - 5年間で変えたこと 評価者を2⼈から1⼈に変更する。 撃沈 >< 評価者がかなり時間を使うので⼤変という声が継続してあがってくるので思い切っ て評価者を1⼈にすることを提案したのだが、ほぼ全員からダメだしされ、評価者2 ⼈は継続された。
54. 毎回30-40⼈が参加し、いろいろ改善案が出た。 ⽿が痛い意⾒もあったが、ふりかえりは重要。 全体ふりかえり - 5年間で変えたこと
55. 5年間で変えたことから3つを抜粋 l 評価軸 l 全体ふりかえり l 評価結果の公開
56. 評価結果の公開 - 5年間で変えたこと GitHubで 評価結果を 社内に公開
57. 被評価者 166⼈ x 評価者 2⼈ずつ 300以上 の評価結果が社内に公開されている。
58. 評価結果の公開 - 5年間で変えたこと l 評価結果が公開されることで「評 価者もまた評価されている」とい う側⾯が強くなった。 l 「評価結果を書くのがすごく⼤ 変」という声も出ている。 https://twitter.com/nekoya/status/781689637811081217 http://b.hatena.ne.jp/entry/s/seleck.cc/834
59. 評価結果の公開 - 5年間で変えたこと 評価結果の公開に合わせて、評価軸ごとの点数を廃⽌し、 総評とアドバイスをしっかり書くようにした。 被評価者の納得度と評価者の成⻑ につなげていく。
60. Agenda Part 1. 技術⼒評価会を始めたきっかけ Part 2. 5年間の改善の歴史 Part 3. 制度を改善していくコツ
61. 制度を改善していくコツ l 期待値を合わせる l ケツ持ちを明確にする l ⼩さく挑戦していく
62. 制度を改善していくコツ l 期待値を合わせる l ケツ持ちを明確にする l ⼩さく挑戦していく
63. CEO、⼈事担当役員、 その他ステークホルダーと 期待値を合わせる。
64. l 短期的なスピードの重視 l エンジニア評価の納得感 l 採⽤・育成・評価の価値観の統⼀ CTO就任時に感じていた課題 – 2010年7⽉ 再 掲
65. • 短期的なスピードの重視 • エンジニア評価の納得感 • 採⽤・育成・評価の価値観の統⼀ CTO就任時に感じていた課題 – 2010年7⽉ 再 掲 個別の課題をもぐらたたきするのではなく 企業⽂化や戦略に基づきながら改善 していこうとCEOおよび⼈事担当役員と話した。 ただし、それには時間が掛かるよね という話とセットで。
66. 期待値を合わせる CEO、⼈事担当役員、その他ステークホルダーと ゴールイメージと期間の 期待値を合わせる。
67. 制度を改善していくコツ l 期待値を合わせる l ケツ持ちを明確にする l ⼩さく挑戦していく
68. 297回 被評価者とCTOが1on1で 結果フィードバックmtgを実施した回数
69. ケツ持ちを明確にする 最初から数回は CTOがほぼ1⼈で運営
70. l ルール策定、評価者割り当て、スケジュール調整 l 評価会の参加、結果確認、被評価者へのフィードバック l ⼈事へのフィードバック、事業責任者へのフィードバック ケツ持ちを明確にする 2011年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック
71. CTOが運営し、現場を巻き込みながら 改善していくことで、 能⼒評価は⼈事だけが決めるのではなく エンジニア⾃⾝で考えていくこと という⽂化が根付いた。 ケツ持ちを明確にする
72. 制度を改善していくコツ l 期待値を合わせる l ケツ持ちを明確にする l ⼩さく挑戦していく
73. コピペは危険！！ 5年かけて改善してきた今のかたちを⾒て、 そのままコピペするのは危険ですよね。
74. l 評価軸 Ø 最初は評価者が指摘しやすいものだった。 l 評価結果 Ø 結果の公開に踏み切ったのは4年後だった。 l 対象者 Ø ⼈数の多かったアプリケーションエンジニアから 始め、インフラ、情シスに広げていった。 ⼩さく挑戦していく
75. 状況に合わせて⼩さく挑戦し続け 5年で⼤きく改善できた。 2016年 全体準備 全体 フィードバック 評価会 実施 評価結果 確認 被評価者への フィードバック 全体 ふりかえり 改 善 改 善 改 善 改 善 改 善
76. まとめ
77. エンジニアの 技術⼒評価は 難しい？
78. エンジニアの技術⼒評価は難しい？ 簡単ではない
79. エンジニアの技術⼒評価は簡単ではない ですが
80. エンジニアの技術⼒評価は簡単ではないが 関係者と期待値を合わせ ⼩さく挑戦していくことで ⼤きく改善していける ご清聴ありがとうございました