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

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

Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017

9c87ec93b3b2aff85a03d3b56e7b8db8?s=128

KOGA Masanori

January 13, 2017
Tweet

Transcript

  1. 2.

    ⼩賀 昌法(KOGA Masanori) #CTO #VOYAGE GROUP 2010年7⽉ CTOに就任 ★ 2016年10月26日

    平成28年9月期 通期決算説明資料より抜粋 https://voyagegroup.com/
  2. 3.

    CTO就任からやってきたこと l 新卒採⽤強化 l 中途採⽤強化 l 新卒研修改善 l 能⼒評価制度構築 l

    情報セキュリティ委員会 l アジャイル戦略室 l システム本部⻑ • サービスインフラ • 社内インフラ l 中国開発拠点⽴ち上げ l アドテク⼦会社CTO l HR⼦会社技術強化 l などなど
  3. 9.

    昇格とグレード l 昇格とはグレードが上がること l グレードは4段階 Ø 専⾨職(スペシャリスト)であれ ば P1->S2->S3->S4 l

    誰がどのグレードなのかは 社内に公開されている グレード4 グレード3 グレード2 グレード1
  4. 10.

    実績評価 部署A 部署B 部署C チームを越えた技術⼒評価とは l 例1 Ø 被評価者 •

    部署A 鈴⽊さん Ø 評価者 • 部署B ⼭⽥さん • 部署C 佐藤さん l 例2 Ø 被評価者 • 部署B 村岡さん Ø 評価者 • 部署A 鈴⽊さん • 部署C 佐藤さん 能⼒ 評価 鈴⽊ 佐藤 村岡 ⼭⽥
  5. 11.

    チームを越えた技術⼒評価とは l 評価者は2⼈ l 事前準備 Ø 被評価者は評価会の1週間 前に資料を提出 l 当⽇

    Ø 1時間30分 Ø 被評価者がプレゼン Ø 評価者との質疑応答 l 後⽇ Ø 評価者は評価結果を提出 Ø 被評価者にフィードバック
  6. 12.
  7. 13.

    実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡

    ⼭⽥ l グレードの⾼いさまざまなエンジニアからの指摘 l 中⻑期的な視点を定期的に考える機会 l 他チームの考え⽅や技術的なノウハウを知る [課題] 短期的なスピードの重視
  8. 14.

    実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡

    ⼭⽥ l リスペクトできるエンジニアからの技術⼒評価 l ⾃⾝の⾔葉でしっかり説明できる場 l 評価結果はテキスト&対⾯フィードバック [課題] エンジニア評価の納得感
  9. 15.

    実績評価 部署A 部署B 部署C チームを越えた技術⼒評価の狙い 能⼒ 評価 鈴⽊ 佐藤 村岡

    ⼭⽥ l 評価軸をベースに考える l 質疑応答を繰り返すことで価値観が擦り合う l 評価する側を経験することで新たな視点が持てる [課題] 採⽤・育成・評価の価値観の統⼀
  10. 19.

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

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

    5年間のさまざまな改善 l 全体ガイダンス l スケジュール調整 l 評価者割り当て l 評価軸 l

    サポーター l 評価会の事前資料 l 評価会のすぶり l 評価会の参加者 l 評価結果の公開 l 個別フィードバック l 全体フィードバック • 部⾨⻑へ • ⼈事へ • CEOへ l 全体ふりかえり l などなど
  12. 22.

    2011年の評価軸 l 事業・サービスの理解度 l プロジェクトごとの要件・制約 の理解度 l 変更容易性 l 可⽤性

    l 性能 l セキュリティ l テスト容易性 評価軸を策定するにあたって 下記を意識した。 l ⽂化として根付いてほしいこと l いま重視したいこと
  13. 23.

    l 事業・サービスの理解度 l プロジェクトごとの要件・制約の理解度 l 変更容易性 l 可⽤性 l 性能

    l セキュリティ l テスト容易性 2011年の評価軸 ⽂化として根付いてほしいこと
  14. 24.

    l 事業・サービスの理解度 l プロジェクトごとの要件・制約の理解度 l 変更容易性 l 可⽤性 l 性能

    l セキュリティ l テスト容易性 2011年の評価軸 いま重視したいこと
  15. 25.

    2011年の評価結果テンプレート ▪結果(5段階、5が⼀番良い) - サービスの理解度 :(点数+コメント) - 要件・制約の理解度:(点数+コメント) - 変更容易性 :(点数+コメント)

    - 可⽤性 :(点数+コメント) - 性能 :(点数+コメント) - セキュリティ :(点数+コメント) - テスト容易性 :(点数+コメント) - 総評:
  16. 26.

    評価結果の実例 - セキュリティ - 2011年 l 2点 Ø 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは

    わかりますが、パスワードを⽣で保存している点はさすがにいただけません。 ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応してお くことをオススメします。 l 2点 Ø Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限 をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。 l 2.5点 Ø 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致 命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。
  17. 27.

    • 2点 • 通常のBASIC認証だけではなく、アプリ側で細かいパーミッションを実現で きている点はいい⼯夫かと思いました。やり⽅を統⼀したかったというのは わかりますが、パスワードを⽣で保存している点はさすがにいただけません。 ハッシュ化⾃体はPHPならば簡単に⾏えるので、リリースまでに対応しておく ことをオススメします。 • 2点

    • Oracleに接続するユーザーの権限が何でもありな権限だったのでもっと制限 をかけたユーザーを設定しないと⾏けないのではかと思う。多⼈数にプログ ラムを配布して利⽤するならばなおのことこういった部分で配慮がいるかと。 • 2.5点 • 時刻だけをシードにIDを⽣成しているのが怖かったです。ビジネス的にも致 命的な⽋陥に思えます。コードレビューなどで発⾒できなかったでしょうか。 パスワードを⽣で保存 Oracleに接続するユーザーの権限が何でもあり 時刻だけをシードにIDを⽣成 評価結果の実例- セキュリティ - 2011年 パスワードを⽣で保存 Oracleに接続するユーザーの権限が何でもあり 時刻だけをシードにIDを⽣成
  18. 28.

    l 1点 Ø ⾃動化単体テストコードなどはありませんでした。 l 2点 Ø 変更容易性の項でも触れたが、テスト容易性についてはまだこれから考えて いくようだった。 l

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

    評価軸を⼤幅に⾒直し - 2013年 l 事業・サービスの理解度 l プロジェクトごとの要 件・制約の理解度 l 変更容易性

    l 可⽤性 l 性能 l セキュリティ l テスト容易性 l 実現⼒ • スコープ定義 • システム構築・運⽤ • プロジェクトマネジメント l 改善⼒ • システム的な改善 • ビジネス的な改善
  20. 31.

    • 実現⼒1 • スコープ定義(設計、システム化範囲) • その場しのぎの設計・実装をしてないか、先を⾒据えた設計・実装をしているか • 考え過ぎていないか、スピードを疎かにしていないか • 今必要なものにフォーカスしてるか、必要以上にコストを掛けてないか

    • まだサービスの⽅向性を試しているフェーズに⼤きく投資しようとしていないか • プロダクトライフサイクルに合わせた最適化 • 実現⼒2 • システム構築(実装とかシステム化そのもの) • テスト容易性、変更容易性 • 可⽤性 • 性能 • セキュリティ • 安全な移⾏計画 • 品質 評価軸を⼤幅に⾒直し - 2013年
  21. 32.
  22. 33.

    • 改善⼒1 • システム的な改善 • リファクタリング • 捨てる • ⾃動化テスト

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

    l 実現⼒ • 何が課題で何が必要と考えたか。 • 構築・運⽤したシステムは妥当 か。 • プロジェクトの進め⽅は妥当か。 l

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

    l 実現⼒ • 何が課題で何が必要と考えたか。 • 事業観点、ユーザ観点、技術観点を持っているか。 • その場しのぎで考えていないか。先を⾒据えているか。 • 考えすぎていないか。スピードをおろそかにしていないか。必要以上にコストを掛けてい

    ないか。 • 構築・運⽤したシステムは妥当か。 • テスト容易性、変更容易性を考慮しているか。 • セキュリティを考慮しているか。 • 性能、可⽤性を考慮しているか。 • プロジェクトの進め⽅は妥当か。 • 納期より早く終わらせることを意識してるか。後半に新しい課題に気づくことを考慮して るか。 • リリース後を考慮してるか。運⽤サイドへは事前にヒアリングしてるか。 • 情報共有は適切か。必要な情報が必要な⼈に届いているか。 • リスクを⾒える化しているか。 評価軸を⽂章に変更 – 2014年
  25. 36.

    l 改善⼒ • システム的な改善は妥当か。 • 技術的負債は溜まりすぎていないか。適切に返済しているか。 • 運⽤コストやオペレーションミスを減らすために⾃動化を進めているか。 • ビジネス的な改善への貢献は妥当か。

    • プロダクトのライフタイムを理解しているか。安易にサービス終了までと考えていないか。 • 検証することを事前に考慮しているか。 • 計測だけではなく可視化を意識しているか。 評価軸を⽂章に変更 – 2014年
  26. 43.

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

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

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

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

    全体ふりかえりからの変更点 – 2015年5⽉ l サポーターをマンツーマンにした。 Ø 今までは部署やチーム単位に複数⼈のサポーターをつけていましたが、今回 からは被評価者AさんのサポーターはBさんのようにマンツーマンにしました。 l 評価のコメントを公開する。コメント以外の点数などは公開しない。

    Ø 評価結果(公開版)は、tech-assessmentリポジトリで公開 Ø 評価結果(⾮公開版)は、CTOともう1⼈の評価者に提出 l CTOが参加する評価会は以下とする。 Ø 被評価者が初めて、もしくは評価者のいずれかが評価者として初めて。 l CTOからの個別フィードバックは以下とする。 Ø 初めて評価を受けた被評価者、もしくは初めて評価した評価者 l 被評価者の要望があれば評価者から対⾯でフィードバックを⾏う。
  29. 51.

    全体ふりかえりからの変更点 – 2015年11⽉ l 評価結果(⾮公開版)を廃⽌した。 l 事前にやることを追加した。 Ø 被評価者と評価者2⼈でコミュニケーションする場を作る。 Ø

    評価者は、必要に応じて被評価者およびもう1⼈の評価者とコミュニケーショ ンをとる。また、必要に応じて被評価者のサポーターにヒアリングする。 Ø 被評価者とサポーターが相談し、評価会の質を上げるために本当に必要であ ればすぶりを⾏う。 l 事後にやることを追加した。 Ø 評価会直後に評価者2名ですり合わせを⾏う。 Ø 評価者2名とCTOのすり合わせを⾏う。 l 被評価者と評価者2⼈の対⾯フィードバックを⾏う。 l 評価結果をチームメンバーで共有し、改善に繋げていく。
  30. 65.

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

    掲 個別の課題をもぐらたたきするのではなく 企業⽂化や戦略に基づきながら改善 していこうとCEOおよび⼈事担当役員と話した。 ただし、それには時間が掛かるよね という話とセットで。
  31. 74.

    l 評価軸 Ø 最初は評価者が指摘しやすいものだった。 l 評価結果 Ø 結果の公開に踏み切ったのは4年後だった。 l 対象者

    Ø ⼈数の多かったアプリケーションエンジニアから 始め、インフラ、情シスに広げていった。 ⼩さく挑戦していく
  32. 76.