「マネージャーの間でエンジニアに対する評価基準がバラバラだ」「どのプロジェクトにどのレベルの人が配置されているかわからない」など、ITエンジニアの評価や配置について悩む企業は多いのではないだろうか。
一休のCTOである伊藤直也氏とセゾン情報システムズCTOの小野和俊氏に、エンジニア評価へのデータ活用の可能性を語り合っていただいた。
▲左から、一休 CTO 伊藤直也氏、セゾン情報システムズ CTO 小野和俊氏
目次
自己評価を文章化することで、エンジニアの納得感は増す
お二人ともさまざまな企業でエンジニアをマネジメントされてきた経験がおありなので、こうしたツールへの期待も含めて、エンジニア評価の現状について貴重なご意見がうかがえるのではないかと思います。
まずは、それぞれ現在の会社では、どんな基準や方法でエンジニアを評価されていますか。
小野：アプレッソを含めたセゾン情報グループには約1200人の社員がいますが、私が直接マネジメントをしているエンジニアは、セゾン情報システムズでは20人ほど、それにアプレッソの30人ほどになります。
いずれは一本化したいと考えていますが、現状ではセゾンとアプレッソでは評価制度が異なります。
セゾンはいわゆるSIerですので、IPA（情報処理推進機構）がやっているITスキル標準（ITSS）のようなシステマティックな基準を使っています。これをやっているとたしかに網羅的に幅広い知識を持つ人材が揃うんですが、反面、何か特殊な技術に突き抜けた人材が育たなかったり、発見できなかったりします。
はたしてこれで競争力のある開発チームが作れるのか、という点では少し心配していて、評価の方法を変えようかなと模索しているところです。
一方、アプレッソは、私が新卒で入ったサン・マイクロシステムズの評価方法を参考に、セゾンとは違う方法でやっています。
技術スキル、臨機応変性、協調性、コミュニケーション、革新性、先進性などの項目をまずは5段階で自己評価し、それを上長とすりあわせるという方法。自己評価は単にグレードを記すだけでなく、そのように評価する理由を文章で書き込むようにしています。
それに対する上長からの評価も、文章で行います。評価会議がまるでブログのトラックバックの応酬みたいになるんです(笑)。
エンジニアって他人からの評価以前に、自分の仕事や技術に対する納得感を重視するもの。言語化することで納得感が得られるから、たとえ上長からの評価と食い違っても、そんなに場は荒れませんね。
▲株式会社セゾン情報システムズ 常務取締役 CTO 小野 和俊氏
1976年生まれ。慶應義塾大学環境情報学部卒業後、サン・マイクロシステムズ株式会社に入社。入社後まもなく米国での開発を経験する。2000年より株式会社アプレッソ代表取締役に就任し、データ連携ミドルウェア「DataSpider」を開発。2002年には「DataSpider 」が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2013年3月にはさらなる事業展開を目指し、株式会社セゾン情報システムズの子会社化による資本業務提携を決定。2015年6月より同社取締役CTOに着任する。
評価で最も大切なのは、期待値のすり合わせができること
伊藤：一休のエンジニアは約50人いますが、エンジニアも営業の人も評価制度は一つです。ただ、エンジニアだけは事業部のマネージャーと、エンジニア組織のマネージャーにダブルレポート、つまり2人が評価するようにしています。やはりエンジニアの評価は、エンジニア出身でないとわからないところがあるからです。
基本的には四半期ごとの目標管理が主体で、OKR（Objectives and Key Results）のようなツールも使いながら、会社のミッションから個人のミッションにブレイクダウンしていますが、やり方はなんでもいいと考えています。
重要なことは仕事をお願いしたい人とお願いされる側の間で、期待値のズレがなく、かつそのすりあわせができること。目標管理はあくまでもそのツールの一つにすぎない思います。たいてい人間って、自分は評価が高いと思い込んでいる。それが数字で、自分が思うほどではないと示されると、自己否定を迫られることになります。
評価って、数字を示して自己否定を迫るためにやるわけではない。互いの期待値のズレをすりあわせることで、その人のモチベーションを上げてもらうためにやるものですから。
▲株式会社 一休 執行役員CTO システム本部長 伊藤 直也氏
1977年生まれ。青山学院大学大学院博士課程前期修了後、新卒で株式会社ニフティに入社し、ブログサービス「ココログ」を開発。その後はてなの取締役CTOに就任。はてなブックマークの開発等、同社サービス開発をリード。グリー統括部長を経てフリーランスとして活動。Kaizen Platform, Inc.、株式会社一休、 日本経済新聞社、ハウテレビジョンほか複数社の技術顧問/技術アドバイザーを務めた。2016年4月、ホテル・旅館・レストランの大手予約サイト「一休」に執行役員CTOとして就任。
エンジニアは「風林火山」が必要。だからこそ、評価は多様であるべき
小野：たしかにそうですね。あまりシステマティックにすると公平性は担保されるけれども、何かがずれていく。
目標設定すると、KPIに寄せてチューニングする人が必ず現れますから。例えば、目標設定のうち半分以上は定量設定すべしというルールがあったりすると、社内セミナーを何回やったかがカウントされるようになる。
でも、セミナーは内容が重要なんで、何回やったかって意味ないじゃないですか。
MITラボ所長の伊藤穣一氏も言っているけれど、今の時代は精密な地図をいくら描いても、それを描いている間に状況が変わってしまうぐらい変化のスピードが速い。
だったら、地図を頼りにするのではなく、コンパスだけ持って旅するほうが現実的。地図よりもコンパスの時代なんです。そういうときに組織にはどんなエンジニアがいればいいのか。
僕はかつて「エンジニアの風林火山」という類型化を試みたことがあるんです。
迅速な設計・実装によってチームを加速させる「風」のエンジニア。厳密なエラーチェックと堅牢なプログラミングで成果物の安定性を高める「山」のエンジニア。
突発的なトラブルが発生しても冷静に対処し、チームに乱れぬペースを提供する「林」のエンジニア。
そして、新しい技術・方法・ツールの積極的な導入によってチームやその成果物の競争力を高める「火」のエンジニア。
つまり、エンジニアの優秀さにも特性があって、画一的な基準があるわけではないということ。
セゾンでは「風林火山」を「マルチトラック」と言い替えていますが、守るのが得意な人、攻めるのが得意な人など、自分の適性に応じてそれぞれトラックを選び、その適性を伸ばしていけばいいんじゃないかと思うんです。
──これらの要素がお互いを補い合いながらチームを構成すると組織として強くなりますね。
伊藤：スーパーエンジニアというと、ブログやTwitterで最新技術を発信しているような人ばかりが崇められる傾向があるけれど、そういう人の中には会社ではあんまり仕事してない、なんてこともよくあるんですよ(笑)。
だって、ずっと仕事だけしてたら、Twitterしたり、ブログ書いたりしてる時間ってないですから。とはいえ、そういう外の世界をよく知ってる「火」のエンジニアもいないと、組織の新陳代謝が進まない。
一方で、最新技術には詳しくはないけど、自社の業務知識に深い知見のある「山」のエンジニア、トラブル発生のときにちゃんと社内調整してくれる「風」のエンジニアもいないといけない。
だから画一的な評価基準はない。多様性が大切なので、自分の得意とするところで貢献してくれと、僕も会社では言っています。
小野：「金太郎飴」的な画一的な人ばかりじゃだめですよね。現状の技術だけに最適化しすぎると、時代が大きく動いたときに全滅しちゃいますから。
企業の生存戦略やポートフォリオを考える上でも多様性が重要で、こうしたツールを通してそれが裏付けることができればいいと思います。
スキルマップで現状を固定化してはいけない
──多様性をどうマネジメントするか、ですね。マネージャーがメンバーのそれぞれのタイプを認知した上で、人材をマネジメントするための手助けとしては、データは使えるかなと思います。
伊藤：最近はスキルマップという言葉もよく聞くようになりました。スキルマップを作るのは現状把握という意味ではいいんだけれど、それだけだと、会社の未来が自分たちの想像の範囲内にすべて収まってしまう。
たとえば、どこかの部署のやんちゃなやつが全然スキルマップにもないような勝手に新しい技術を使い出していて、それが結構使えそうとなったら、その人のことも評価したいじゃないですか。
小野：逸脱に対して許容性のあるシステムでないと、会社の新陳代謝が進まないということですね。アプレッソにもスキルマップのようなものはあるけれど、世間で一般的にいわれるものとはだいぶ違います。
僕らはそれを「ラストマン戦略」と呼んでいる。なんでもいいんだけれど、社内では自分は一番このスキルに詳しいということを、エンジニア全員に宣言してもらう。最後はこいつに聞けば大丈夫だという意味でのラストマンです。
ラストマン宣言は新入社員にも課しています。ディスカッションしながら「このスキルのラストマンになろうね、なければ新たに作ろうね。ラストマンを自称するからには聞かれてわからない、じゃだめだよ」。
そうすると誇りが生まれるからどこまでもやれる。突き抜けたところまでやろうという気持ちが生まれる。そういう自負を持つラストマンをマッピングしたのが我が社のスキルマップになっています。
定性評価と定量評価のバランスは難しい
ところで、人材評価でたえず問題になるのが、定性評価と定量評価の使い分けやバランスですが、このあたりはどうお考えですか。
伊藤：営業は数字で評価されるのだから、エンジニアもそうあるべきだという人もいます。とはいえ定量評価だけではカバーできないこともあるから、定性的な評価も入れないといけない。逆に定性評価だけでは心許ないですよね。
開発プロジェクトの定量評価という意味では、例えばアジャイル開発で使われるベロシティ（開発速度）の計測をきちんとやっている会社もありますね。
あれは数値が客観的に出るから評価に使えるかもしれない。ただ、ベロシティを計測するのが難しいんですよね。
小野：アプレッソは教科書通りの完全スクラム開発を導入してからは、ちゃんとベロシティを取っていますよ。フルセットでやるとベロシティを測るのが楽しくなるようです。
でも、評価のための数値化というと難しいですね。試験を受けても、ほんとにすごい人の100点とそうでない人の100点は意味が違うと思うんですが、その差異がなかなか見えない。
伊藤：テストは解答できても、現場で手を動かせない人もいますからね。僕思うんだけれど、エンジニアの重要な要素はリスクテイキングができること。
昔の人がやったことだから変えられないとかじゃなくて、ガンガンやっちゃう人。これは試験のスコアではなかなか測れない。
ただ、どういうデータを取ればエンジニアの評価を客観的にできるようになるかは、これからも追求していってほしいですね。時間軸の中でその人の事業への貢献度とかが図れるとありがたいなとは思います。
小野：ただ、評価システムって、あまり複雑にしすぎたり、システムとして作り込みすぎると失敗するというか、手間ヒマかけただけの成果がなかなか上がらないということはあると思います。
システムありきで考えるとやはりまずいんでしょうね。
自己評価と客観評価のズレは必ずしも悪いことではない
──例えばデータを取ることで、そのエンジニアが自分を過大評価しているのか、過小評価しているのかがわかります。そうした傾向を把握した上で、上司はどういう言葉をかけてやれば、その人のモチベーションを上げることができるか、私たちはそんな研究も進めています。
伊藤：自己評価と客観評価のズレは必ずしも悪いことではないと思います。僕も小野さんも結構自信過剰タイプで、自分を過大評価してきたからこそ、ここまでリスクを取ってやってこれたという面がありますものね。逆に自分を過小評価する人はリスクを取るのを避けがちかもしれない。
小野：たしかに、僕も24歳のときにアプレッソ始めたけれど、過大評価というか、根拠なき自信がなければ、起業なんてできなかったですよ(笑)。
結局、「CODE.SCORE」のようなサービスは、開発チームがまとまらない、評価の基準もバラバラ、人事もCTOも悩んでいるというようなところでは、使えるツールになると思います。
逆にいえば、伊藤さんみたいなすごいCTOのいる会社では、ツールに頼らなくてもいけるかもしれないけれど(笑)。
伊藤：いや、僕が定量と定性のバランスが重要だとか、多様性って大切だよとか言えるようになったのは、やはりこの10年の経験があったから。
以前はこういうツールがなかったから、試行錯誤してきた。いまこういうツールが登場して、エンジニア組織の状態がわりと簡単に見えることができるようになれば、それはそれでいいことだと思いますね。
──伊藤さん、小野さん、貴重なお話をありがとうございました。
※本記事は「CodeIQ MAGAZINE」掲載の記事を転載しております。
8,568通り、あなたはどのタイプ？
グッドポイント診断で、あなたの隠れた強みを診断してみましょう。
診断結果は8,568通り。あなたはどのタイプ？
