「エンジニアの評価は、給料を決めるだけのものではない」　“評価＝成長させる羅針盤”だからこそ大事にすべきこと

エキスパートとしても育っていける構想を用意する

今村雅幸氏（以下、今村）：次に評価ですね。エンジニアの評価は、ただ給料を決めるためのものではありません。「エンジニアを成長させるための羅針盤ですよ」と言っています。キャリアパス、評価制度、行動評価みたいなところがあります。

エンジニアのキャリアパスですね。これは最近各社で多くなってきていると思いますが、マネージャーコース1本だけではなく、しっかりとエキスパートとしても育っていける構想を用意してあげる。かつここも給与レンジとしては同じようにするということが非常に重要かなと思っています。

BuySellの場合は、S1、S2みたいなメンバー層もあれば、M1からM3のマネージャーもあれば、エキスパートのE1からE3もあるのですが、このM1からM3、E1からE3は給与のレンジとしては同じ感じになっています。

エンジニアは成果評価と行動評価の2軸で評価する

評価ですね。評価制度は非常に重要です。当然良いエンジニアを採ってきても評価制度がダメだったらすぐに辞めていきますし、今いるエンジニアたちも評価制度が変わらなければどんどん抜けていくみたいなことが起きるので、ここはしっかりと考える必要性があります。個人的に行き着いた先としては、エンジニアは2軸で評価してあげるといいのかなと思っています。

まずは成果評価、もう1つが行動評価ですね。成果評価は、いわゆる部門やチームや個人のOKRみたいなもので、こちらは短期的なパフォーマンス評価になります。一方で、行動評価は短期的なパフォーマンスでは測れないエンジニアの貢献だったり成長だったりはやはりあると思うんですよね。そういうものをしっかりと評価してあげることが、エンジニアの評価、満足度、成長につながると思っているので、成果評価と行動評価の2軸で評価していきます。

行動評価はバリューを分解して、エンジニアとして評価できる項目に落とし込む

行動評価をどうやって作っていきますか？　みたいなところの例でいくと、BuySellの場合は、先ほど紹介したようにHOSPITALITY、PROFESSIONAL、CREATIVEみたいなものがあります。それぞれのバリューを分解して、エンジニアとして評価できる項目に落とし込みます。

（スライドを示して）それぞれのバリューはこういう感じになっていて、HOSPITALITYは連携、育成、採用ですね。PROFESSIONALはインプット／アウトプット、計画性、主体性、品質。CREATIVEは課題解決、変化とか障害対応みたいな感じで分解して、これらの項目軸でどれくらいの行動ができたかを評価していきます。

さらに3つの観点×グレードがあるので、そのグレードに求められる行動定義ですね。このぐらいのグレードだったらHOSPITALITYはこのぐらいのことをしないといけないよねみたいなものを全部定義して、実際のそのグレードに対して期待値を上回るような行動ができたかどうかをやっていく必要があるかなと思っています。これを全部紹介していくと、自分のグレードに対する期待値のずれがなくなるので、いいかなと思っています。

エンジニアの成長につながるような支援を全力で行う

評価制度が整ったら、あとはやはり育成や成長支援です。やはりエンジニアとしての成長実感がないと転職するし辞めると思いますし、そもそもの転職軸として成長できる環境は非常に重要視される要素です。なので会社としてエンジニア採用をするのであれば、エンジニアの成長につながるような支援をそもそも全力でやりましょうとやるべきかなと思っています。

（スライドを示して）このあたりはインターン生や新卒エンジニアの話ですね。例えばメンターをしっかりと置く。あとは社内異動ですね。フロントをやっていたらバックエンドに行けるとか、インフラをやっていてもバックエンドに行けるとか、そういう異動のところもしっかりできるようにする。あとは書籍の購入代を全額補助してあげるとか、インフラのAWSとかGCPなど勉強したいけれどお金がかかるみたいなところも出してあげます。

資格を取ったら手当ですね。資格の金額を全部補助するとか、勉強会やカンファレンス費用は全部会社が負担しますよとか、社内外での勉強会開催は自由に参加していいですよとか、主催をするんだったらいいですよとか。情報発信の支援もしっかりとしたり、こういうエンジニアの成長につながるようなところをしっかりと会社がサポートしてあげる必要があるかなと思っています。

技術ブランディングもCTOの仕事

次に技術ブランディングですね。エンジニア採用や内部のエンジニアの技術力向上のために情報発信をしていく必要性があると思っているので、技術ブランディングもCTOの仕事かなと思っています。なので会社としてテックブログを書くとか、個人のブログや記事の執筆を推進していくとか、Twitterで広報活動をするとか、カンファレンスのスポンサーをするとか、勉強会の開催を主催するとか、他社勉強会へ登壇するとか。

やはりこのテックブランディングみたいなことが採用活動においてメチャクチャ重要です。（スライドの）右にCTO協会で昨年リサーチしたデータを載せていますが、エンジニアが「開発者体験がいいな」と思う会社としてだいたいこういう会社が挙げられるんですね。こういうところに名前が挙がるのは、この会社に所属している人たちが日々いろいろなアウトプットを繰り返しているから「あの会社ってやはり良いエンジニアいるよね」とか「働きやすそう」みたいなイメージが醸成されていくと思っています。

なのでここに列挙している行動をたくさん積み重ねていくことによって、技術ブランディングが醸成されていく。それが醸成されることによって、内部メンバーは成長するし、会社としてもより良いイメージが付いて採用が楽になるみたいな、そういう循環が生まれると思っています。

良い開発者体験がある環境に良いエンジニアは集まる

次は開発者体験の向上です。このあたりは先ほど紹介しましたが、良い開発者体験がある会社に良いエンジニアが集まるので、そもそも開発者体験の向上を目指しましょう。

開発者体験はどんな項目を見ていけばいいのか。1つの指標として紹介するとCTO協会が出している「DX Criteria」があるので、それを用いて組織診断を行ってみましょう。

自分たちのチームが本当に開発者体験に良い会社かどうかをチェックするチェックシートになっているので、このあたりは組織をマネジメントする人は一度やってみるといいんじゃないかなと思っています。これがすべてではありませんが、1つの評価指標には使えるかなと思っているので、ぜひ使うといいんじゃないかなと思います。

エンジニアチームの生産性を可視化した上で改善活動を行う

最後ですかね。開発生産性の向上というところで、エンジニアチームの生産性を可視化して、改善活動を行いましょう。これはCTOとして非常に重要な要素だと思っています。特に経営陣とのコミュニケーションにおいて「エンジニアがたくさん増えているけど生産性は上がっているの？」みたいな質問をされることが、まぁあると思うんですよね。

その時にしっかりと定量化されたデータを用いて説明できる能力はCTOにすごく必要だと思っています。なので僕も昔から、エンジニア生産性のアウトプットをどうやって計るかみたいなところをやってきました。例えばGitHubなどの数値を取得して生産性を図る指標、最近だとFour Keysみたいなものがあるので、そういうのをしっかりと可視化して「このへんが改善できているね」というのを見る。

あとはこのあたりの取得から可視化まで、最近は自動化してくれるサービスがたくさん出てきています。「Findy Team+」だったり、先ほど紹介があったような「Offers MGR」など、こういうものを使って生産性がしっかりと向上していっているよと定量的にわかりやすく説明していくのは必要だなと思いますし、それを推進していくのも非常に重要な要素かなと思っています。

まとめ

少し長めに話してきましたが、まとめとしてCTOの役割というのはフェーズごとによって変わります。ただし各フェーズにおいても技術戦略やエンジニアリング組織マネジメントに関しては非常に重要です。今日ここに紹介しているのはごく一部だと思っていて、実際はもっといろいろあります。

細かく言えばもっともっといろいろありますが、実際に僕もいろいろなところで試してきて、すごく意味があるなと思ったものを今日は紹介しているので、ぜひ参考にしてもらえればなと思います。技術的な側面から中長期のビジョンの策定と実行、事業を成長させていく仕組みを作っていくというのがやはりCTOとしては非常に重要な要素なので、その場限り・その場しのぎの対応というより中長期的にきちんと成長していくための仕組みを書く。

ここに紹介した仕組みをどれだけ作っていけるかが重要だなと思っています。これらを実践していけば確実に会社のテックカンパニ―化を推進していけるかなと思っているので、ぜひ参考にできるところから始めていただけるといいんじゃないかなと思っています。ちょっと長くなってしまいましたが、以上です。

（次回へつづく）