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

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