エンジニアの人事評価はどうやっても不満が出るもの--ベテランCTOが語る給与制度の難しさ

採用で自社のサービスが好きかどうかは重要ではない

松尾康博氏（以下、松尾）：ではちょっとお題のほうを変えまして、今までは過去の話でこんなことをしてたって聞いたんですけど、これからみなさん、組織が大きくなっていくと思うんですが。

大きく、もしくは強くしてくってのはみなさん同じだと思うんですけども、これから何か取り組もうと考えているもの、具体的なことでもいいですし、あとはこれはやらないって決めてることがあればお聞きしたいなと思ってるんですけども。

田中慎司氏（以下、田中）：実際にやるかはまだ決めてないところがあるんですけども、今はてなって、はてなブログとかはてなブックマークとか、コミュニティが濃いサービスを提供していて、今入ってもらってるエンジニアもはてなのサービスがすごい好きで。

自分たちもヘビーユーザーだし、それで自分たちで使う新しい機能がどんどん欲しいと思ってるし、エンジニアも新しい機能が欲しいと思ってるので、特にヘビーユーザーの気持ちになってガンガン作って、それで思い入れがあってスピード感のある開発ができるのはいいんですけど。

一歩引いた視線でライトユーザーのことを考えようとか、はてなのメインのソーシャルメディア以外の事業ができてきて、そういうのをいろいろやっていこうと思ってるんだけど、そういう時にあまりにもメインのサービスが好きすぎると、いろんな意味で足かせになることもあるんじゃないかなと思ってて。

そういう意味で、採用基準としてはてなのサービスが好きであることとか、そういうのを重視してたんですけど、あまりそれを重視しなくてもいいのかなとは最近思い始めてます。

松尾：私も結構面接するんですけど「なぜ来たのか」って聞いたときに「好きだから」ってお決まりのように言う人が多いんですけど、それはあまり重視しないっていう。自社のサービスを重視しないように。

田中：もちろん、全然興味がないって言われるとそれは困るんですけど、あまりにも好きな人は配属の自由だとか、そういう意味での難しさが出てくるかなって思ってます。

愛が深すぎると盲目になる

大場光一郎氏（以下、大場）：それって、好きすぎる、愛、みたいになると盲目になってしまうみたいな話だと思うんですけど、面接とかで例えば「クラウドソーシング、便利ですよね」みたいな共感度で採用していいのかどうか、さじ加減が難しいですよね。

田中：会社がワンプロダクトで、規模が小さい間はサービスが好きであることは必須条件にしたほうがいいと思うんですけど、プロダクトがいくつか増えてきて、BtoCの商品が主力なんだけど。

アドテクも手を出してたりとか、企業向けのサービスを出したりしてて「それがやりたいんです。それだけのためにやります」って言われると、ちょっと重いなっていう。

藤川：もともと僕はpaperboyっていう会社にいたんで、昔は家入さんが好きだから来る人ってのがいたんですね。彼の外向けの活動だけ見て面接に来る人で「好きな事をやれるんだ」みたいなふうに来ると「いやいや、あくまでもレンタルサーバーの会社ですからね」って。

面接官はこういう人が来るのを恐れて、構えてしまったりってのは結構ありまね。

松尾：難しいですね。最近ニュースで見たんですけど、鉄道会社が鉄ちゃんは採用しないっていう。（鉄道に対する）愛が深すぎるのでって話を聞いたことがあります。

田中：あと、会社としてサービス方針をぐっと転換しようとすると、サービスへの愛が深すぎる人が変化についてこれないっていうズレは聞いたりします。

ネットベンチャーの人事評価制度はどうすべき？

藤川：今後、ずっとやらないかっていうと今考え中ってやつで、人事評価制度ですね。制度としてどうするかを考えてます。

今まで自分がマネージャーをしていた会社とか、人事評価制度を取り入れて、そうすると半年後のコミットメントみたいなのを決めて数ヵ月後に評価していきましょう、もし変わったら変えていきましょうねっていうのをとりあえず運用するじゃないですか。まず運用してみましょうねと言うと、だいたいそのまま続くんですよね。

やっぱりネットベンチャーって半年後に自分たちが何をやってるかってわからないし、実際変わってるんですよね。そうすると半年前にやろうと決めたことが無駄で、半年後にこういうことがあったよねって評価するんだったら、いらないじゃんって思って。

さっきも言ったように、各個人個人パーソナライズして目標設定してる。目標設定っていうか、改善ポイント。先日面談したときは、たった1つだけ一人ひとりに改善して欲しい事を伝える。あとはグッと我慢するってのをやってきてるんですけど。

何かこれをやればこういう給料になりますよっていうのを、まだ決める時期じゃないかなって思って。どっかで人が増えてくればそうはいかないだろうから、下の人が評価するってなれば、もうちょっと形つくらなきゃいけないだろうし。そういうことを考えながら基礎となる仕組みを勉強したいなと。

大場：給与テーブルみたいなところで、今でも忘れられないおもしろい話で、グリーの田中良和社長が楽天時代にすごい社員から不満が多くて「いったい何をやれば給料があがるかわからない」と。そういう制度がなかったんですね。

「そうか」って言っていろんな会社の制度を見て、うちの給与テーブルはこうやったらこうなって、いくらになりますよって全部決めて出したら、今度は社員から「何年後にどうなるか、見え過ぎてつまらない」って。結局不満は出続けるっていう。

あとは今やってる線形的に伸びていくものと、ストレッチした向こうにあるジャンプした何かの、両方の設計が必要なのかなと思いつつ悩んでると。

松尾：竹内さん、どうですか？

技術と営業、どちらかが強くなり過ぎるとバランスが崩れる

竹内真氏（以下、竹内）：うちは今年の春から夏にかけて人事評価制度を結構ガチッと作りこんだんですよね。エンジニアのほうはいわゆるスキルのほうと、そうじゃないマネジメント寄りの2軸を作って、できる事を加点していって評価する、加点主義な評価を作ったんですけど。

スキルのほうは技術力だけで評価するのは本当難しいので、次にマーケティング力だったり、ビジネスインパクトだったり、そういう一人のマネジメントにならなくても一人の力で上げていける、ちゃんとスキルを持ってきて、かけ算になんないと生きないような感じのものができました。

マネジメント側の人間力ってのも、言語化はできてるんですね。なかなかみなさん手にすることができないと思うんですけど、本当に大企業の営業系の組織だったりとか、人材系の会社とかって、すごいしっかり考えてあるんですよ。なので、それはさっき言ったような会社さんを参考にして作らせてもらったんですけど。

言語化はされたんですね、そちら側は。スキルのほうは何となく別に、経営を学びたいときにまず財務の勉強をしましょうとか、マーケティングの良い本とかもあって、手に入れようと思えば手に入る、こうしなさいっていうのも言いやすいんです。

スキルのほうはそうなんですけど、人間力ってすごい難しいんですよね。いわゆるマネジメントってところも、DISC分析とか、どういうところに自分って位置するのか、どういう人と合うのか、合わないのかとか、最初のレイヤーのマネジメントは合う人をちゃんとマネジメントすることだったり、合わない人までマネジメントできるか？　みたいな。

そこまではまだいいんですけど、当社はホールディングスのCTOみたいな形でカンパニーのCTOみたいなのが更にいるんですね。

彼は僕をコピーしてくれていて、気持ちもちゃんと理解して、CTOとしてすばらしい判断ができると思ってるんですけど、ビジョンだったりとか、何かへの執着心からくるメッセージだったりとか、そういうのってなかなかどう伝えていいか、どう持ち上げたらいいか。先天性って言ったら終わってしまうんですけど、それを言ったら何もできないので。

何とかそこを教育プランで、カリキュラムでもトレーニングでもいいんですけど、作っていきたいなと思っていて。こういった部分は、ハイレベルになるほど、なかなかメソッドがあんまり世の中に確立されてなくて、すごく難しいかなというのがありますね。

そこは今、やっていきたいというか、探して言語化して、トレーニングプランを作っていきたいっていうことですね。

やらないと決めていることもあります。うちは400人くらいなんですね、全員で。技術が強くなり過ぎても、営業が強くなり過ぎても、すごくバランスが崩れると思ってるんです。なので、やらないと決めてることって、さっきの「ウェーイ」じゃないんですけど。

技術、本当に大きな力で「うちはIT企業だから黙れ」みたいにやろうと思えば多分できちゃうのもあると思うんですけど、そこはお互いを尊重しながら、バランスを取るということですね。

強過ぎたら下がるし、低過ぎたら向こうにも下がってみたいなバランスを取ろうと思ってるので、やっぱりエンジニアってちょっとこう、営業の方に対して苦手意識がある人が多いと思うんですよ。

強い人が特に。なのでそこはやらない方向「こういうふうにうちはやるんだよ」ってことをやらないようにっていうか「バランスを取りなさい」っていうのを話していきたいなと思ってます。

エンジニアの納得感が重要

松尾：時間も少なくなってきたんですけども、お話を聞いた中で、質問とか何でもいいんですけども、会場から何かありましたら。

質問者：評価の話が興味深いなと思ってます。私も相当悩んでいて、今まで営業職と同じように四半期で目標を設定してやってたんですけど、人間によって定量的な評価って難しいなと思っていて、どうしても定性的なものばかりになってしまうなと。

最近メンバーを説得して、全部そういうシートを無くして話そうってことにして、制度にしても個々の納得感が重要なのかなって思っていて、そういうのってどういうふうに皆さんふまえているのかなって思っているんですけども。

僕はエンジニアの納得感が重要かなと思っていて、そこは話して解決しようと思ってるんですけど、エンジニアの何を気にして、どういう施策を打ってるかを教えていだければと思います。

竹内：ちゃんとお答えできるかわからないですけども、納得感はまさにその通り、僕も同じように思っていて、納得感以外何もないと思ってるぐらい、納得感をどう熟成するかってことを考えてやっています。

定期的な、いわゆる1on1みたいな形で、不満があるのかないのかっていうこともあるんですけど、半年に1回ミッションシートみたいなのがあって、これはリクルートさんの仕組みをかなり真似ているんですが。

リクルートさんの中では「Will Can Mustシート」と呼ばれていて「Will」自分がなりたい姿をまず書いて「Can」自分が今、何ができるか、何ができないかってのを書いて。

「Will」になるために、何ができなきゃいけないかってのを割り出して、それが業務の中でできるようになるものをミッションに変えて、これができるようになりましょうねっていうので、次のクラスはそれができるようになることって定めてますね。

これエンジニアだけじゃないと思うんですけど、それがちゃんとリスペクトできる先輩から定められたものだと、ある程度納得感はあるのかなと。それはいわゆるエンジニアとして、だいたい28歳未満の方たちまでがやってくるようなランクで、それ以降は数字ですね。

マーケティングとかのインパクトがどれくらいあったのかっていうことで評価していく感じになってくるので、35歳の方にスキルの設定をってなると、結構悶々とするんだろうなと思うんですけど、そこはみんな突破しながら数字の世界に入ってきてくれる人が多いかなと思います。

ユーザーのために何をやってきたかを見る

藤川：スタートアップとして短期的にある1つの成功を目指すという前提の組織だと思っていて、そういう中で昇級する幅って何かっていうと、結局期待感に対して昇給するものかなと思ってます。

「次の期にこのくらいのことをやってくださいね」ってことをお願いして、その分に対して昇給幅を設けるっていう。現状それがまだ許されてる状況なんで。会社がうまくいかなくなったら矛盾が出てきそうな気がするので、成長が前提なんですけどね。

そういう感じで捉えているので、期待を乗っけて評価をして、その期待がどうだったか、そして次の半年どう期待するかっていうので評価をしたいなと思うので。

今後期待をして駄目だった場合は、給料を減らすこともあるじゃないですか？　その時には「この時の期待感が期待通りじゃなかったから」っていう体でいこうかなってのを考えています。

田中：うちは定量的な評価は一応やってまして、何を基準にやるかっていうと、純粋にエンジニア能力っていうよりは、サービス開発の貢献を定量化するようにしていて。エンジニアなんでだいたいチームで5、6人くらいでやってるのが多いですけど、スクラムをちゃんと回すような、チームに協力する姿勢があったかとか、その中で自分できっちりタスクを回すことができたかとか。

あとはユーザーさんのことを考えて、そういう良い提案ができたかどうかとか、そういうサービス開発を上手く回してさらに加速させるような取り組みが見られたかどうかっていう点で評価することが多いです。

大場：そうですね、今期エンジニア一人ひとりと話して、まさに合意形成は期待するところで「ユーザーのために一体何をやってきたのか」みたいなところをベースにしつつ「もう1つジャンプアップするにはどうするか」みたいなストレッチゴールを一人ひとり徹底して、それができたら次は評価制度にしていくような取り組みをしています。

社内だけではなくて、社外のエンジニアにも良い影響、ライブラリーを公開したりとかそういう情報を発信したりとか、そういうところも含めて評価しますよみたいな話をやってるっていうのがあります。

松尾：納得感、重要ですよね。我々も実はすごい悩んでます。あと残りが1分なので質問お願いします。

ハッカー気質の人材とどう向き合うか

質問者：ハッカー気質の人間をどう組織に組み入れてるのかなってところをお聞きしたいんですけども。どういうふうに組織に入れるか、入れないかっていう。一人で自由にやらせてる分にはすごくおもしろいのを作るけれども、組織にいると全然ダメになっちゃうやつっていると思うんですよ。それをどうすればいいかっていう。

竹内：うちはわりと成功してると思うんですね。ハッカー気質の、本当にニコリとも笑わないような人が最初入社してきたんですけども、結構時間をかけて「人間とは」って説き続けました。変わるんですよ、やっぱり。

それはそれで継続的にやるんですけど、基本的には新事業を一人で立ち上げてもらったりとか、この特定の数字をグロースハックしてもらったりとかっていうようなところからやってもらって、新事業がどんどん大きくなって、マネージメントしなきゃいけなくなって、結果どんどん成長していきますね。

田中：僕がパッと思いついた成功した事例と失敗した事例があって、やっぱりハッカー気質のタイプだと、エンジニア同士だと上手く話せるっていうのが多いでので、直接いろんな人と話す役割っていうよりは、まずはエンジニアの中でちゃんとコミュニケーションができるようになってもらうところから徐々にチーム開発に馴染んでもらって、その役割を広げてもらうって感じで。そこはわりと上手くいったかなって思います。

藤川：うちはサービス理念が「お母さんでも使えるショッピングカートのネットサービス」ってのがあるので、そこでわりとおさえられるんじゃないかと思ってます。いわゆるUXの部分はそこでだいたいどうにかなるので、小難しいものを作ってしまって、ユーザーさんが使えないものっていうのは、組織で止められる。

バックエンドが高度なのはハッピーだと思っていて、そこを評価みたいな話で言うと、プロダクトマネージャーコースと職人コースで分けたいと思っていて。職人コースをプロダクトマネージャーみたいな人がどうコントロールするか、一緒にやってくかっていうのを上手くやっていくチームにしたいと思ってます。

大場：ハッカー気質の人はまだいなくて、直接は困ってないんだけど。G社にはすごい人がいっぱいいて、大きくなるにつれて一部上場とか会社のステージが変わっていく中で、普通の会社のように就業規則徹底が厳しくなってきたところで、そういうハッカー気質の人はいつ出社していいかわからないみたいな状態で。気がついたらサンフランシスコにいるとかって人もいたりして。

そういう人は、もう普通の会社になっていくと自然とドロップアウトしていくみたいなところがあるんで、受け入れる場合はさっきの「人間を説く」覚悟で変わっていただくしかないのかなと。でもクラウドソーシングは、多様性を持った働き手を活躍できるような世界にしていきたいと思います。

松尾：多分答えが出ない話なんで、このあとパーティがありますのでそこで是非パネラーの方を捕まえてですね、いろいろとお話をしていただければと思います。

それではみなさま、どうもありがとうございまいした。