エンジニアもセールスも活躍に導く。多様な職種における「人事制度・評価制度」のつくり方

2020.05.26

イベント

人事制度全般

【対談】組織ステージやタイプごとに考える「強い人事制度」とは？ #2/3

スタートアップの人事責任者を経験した3名を招き、「組織規模やビジネスモデルごとに考える、強い人事制度とは何か？」というテーマでトークセッションを開催しました。全3回に分けてお届けする本セッションのレポート、 #2/3では、職種の特性を生かしながら最適な人事制度をどのように作っていくか？具体例を交えてご紹介していきます（モデレーター：株式会社コーナーCOO 小林幸嗣）

▽参加者プロフィール

西島悠蔵 氏株式会社土屋鞄製造所人事本部人材開発課課長 ANAにて3年間パイロットとして勤務した後、リクルートキャリア社にて中途採用リーダー、その後ベルフェイス社の人事・広報チームマネージャーとして、社員数10名から80名への組織拡大に貢献。2019年7月より現職。 >>twitter

木元豪 氏株式会社NALU 代表取締役 Web受託開発会社の経営に携わった後、リクルート社にて開発マネジメント⇒人事部門へ異動。その後独立し、スペースエージェント社のCHROを担う。自身の会社では人生の選択肢を広げるプラットフォーム『KIZKI』を開発。 >>『KIZKI』

Huydung Lequang 氏リフリード株式会社取締役レバレジーズ社にて採用コンサルティングに従事した後、サイバーエージェントグループにて人事を約6年経験。その後、ベンチャー企業数社の人事コンサルティングを行いながら複数社を経営し、旅行用品のレンタルサービス『flarii』などを運営。 >>『flarii』

職種の特性を見ることで生産性に貢献

小林：西島さんは、これまで経験されてきた会社それぞれで、職種のバリエーションがかなり異なりますよね？

西島：そうですね。セールス、エンジニア、店舗、製造・・など、これまで人事として関わる職種のバリエーションは多かったですし、そもそもの働き方が全然違う職種が集まる組織も経験しました。

小林：職種の振れ幅が大きいと、人事施策の難易度も高そうですよね。どんなことを意識すると良いのでしょうか。

西島：やはり、人事の目線というよりも、売上や利益の観点から考えて進めることだと思います。というのも、一例ですが、職種別で見ていくと、業務のコアになる時間がそれぞれ異なるケースが多いですよね。
なので、「9-18時」のようなという固定勤務時間を設けることによって、ある部門によっては夜に業務が必要で遅くまで働いているが、午前中は手が空いていて・・という無駄な動きが出てきたりします。

これだと、会社全体の残業代は上がり、トータルでの生産性は下がりますよね。

その時に人事施策として、この状態を是正するために、フレックス制度を入れて、「どこの時間で集中して業務を行うか」というのを部門ごとで判断できるようにすると、会社全体のコストを抑えることができます。従って、職種ごとの特性を人事が把握すること、その上で、全社の生産性を起点に考えることが重要だと思います。

市場価値で評価を決める

木元：ちなみに西島さんはベルフェイスにいらっしゃった時に、開発側の生産性と評価はどのように考えていましたか？

西島：そこは難しかったです。ベルフェイスは初期フェーズはセールスがメインで、開発はアウトソースしていた。なので、基本的にセールス職をメインで人事制度を作っていたところに、エンジニア増やすことになりました。

そうなると、エンジニアのメンバーから「評価されているのか分からない」という声が上がってきたので、市場価値をもとにした評価制度を入れることになりました。

※参考インタビュー記事：【インタビュー】給与を決めるのは市場価値。ベルフェイス式人事制度は未来のスタンダードになりえるか？

木元：分かります。事業を作る場合に、最初のうちはセールスメンバーを揃えて、モノを作る部分はアウトソースというのは多いですよね。その後に自社でエンジニアを採用したタイミングで、改めてエンジニアの評価制度を設計しないといけない。その時に、「自社にとってあるべきエンジニアはこういう人だ」という評価基準を定義できる人材が社内にいないケースが多いですよね。なので、市場価値での測り方をするということですよね。

西島：おっしゃるとおりです。中で決めることが難しいのであれば、市場価値を提唱することで納得感がある評価制度になるかなと。

配属による評価の不公平を減らすには

小林：他にも、職種ごとに人事制度を変えるという観点だと、「開発チームの評価を売上で行う」という事例もレクアンさんから頂いていましたね。

レック：インセンティブの分配方法を変えた話ですね。僕の場合はプロダクトがヒットした時に、開発チームに多くインセンティブを渡せるようにしました。プロダクトを作るのは開発チームなので、彼らを評価して、豪華な達成祝いを開発チームに渡したり、「組織貢献」という評価軸を作って、開発に貢献したメンバーのベース給をアップできるようにしました。当時は「開発チームを評価しやすくする」と決めて進めた形でしたが、結果、これによって上手く回りましたね。

小林：プロダクトの成熟度合いにもよりますが、統一した制度とか報酬体系って限界がありそうですね。そうしないと、例えば新規事業が既存事業よりも評価されづらくなったりしますよね。

レック：たまたま入った開発チームによって売上が変わるから、評価やボーナスが変わる。それで不満が出てくるのですよね。その場合は、会社全体で連帯連動型インセンティブというものを入れていました。ようはそれぞれのチームの目標を同列に見てあげるというものです。
この開発チームだったら売上いくら、カスタマーサポートだったらお客様の「ありがとう」の数、など、指標は違いますがそれを同列の目標として扱います。次に、各チームの目標を9マスのビンゴ形式にして、真面目な項目以外にも「社長がダイエットに成功したら」とか全社で共通の楽しめる項目も入れて（一同笑い）、ビンゴになったら会社全体にインセンティブを支給していました。

どのプロジェクトに行っても、会社のために目標をクリアしたい、というモチベーションが生まれるように工夫しました。

職種ごとのスキル成長を定義して評価に

小林：木元さんもプロダクト開発をしているスタートアップのご経験があると思いますが、セールスとエンジニアの評価方法で課題感はありましたか？

木元：セールスとエンジニアは、評価制度の話でも、日々の業務の中でもぶつかることが出てくると思いますが、これがなぜかと言うと、見ている指標が資産なのかPLなのか、という考え方の違いにあると思っています。

一般的には開発の指標は資産になる事が多いと思いますが、個人的な持論としては、プロダクトディビジョンもビジネスサイドと同様に売上を見るのが適切だと考えているので、数値目標としては売上を設定したいと考えていました。

ただ、エンジニアは自己成長意欲が高く、自身のスキルセットの向上に重きを置いてる方も少なくないので、現場からも「売上評価も良いが、スキルセットの向上も判断軸に入れるべき」という要望が上がってきました。

なのでグレードを策定した際には、会社組織としての指標以外に、ロール（職能）毎のスキルテーブルもマネージャーを巻き込んで作成し、評価の指標としました。

小林：評価制度をエンジニアだけ変えたのでしょうか？

木元：そうではなく、全社での評価制度をベースとしてロール毎の評価軸を分けました。

少し分かりづらいかもしれませんが、僕らの会社は最初MBO（Management by objectives：目標管理制度）を入れていたのですけど、それをOKR（Objectives and Key Results：目標と成果指標）に変えていきました。

OKRは評価と紐付けずに運用したかったので、同じそのタイミングで評価制度を刷新し、会社として最重要であった「バリューの体現」を指標として定めました。
この「バリューの体現」という指標の中で、ロール毎の評価軸を作ったのです。

当時の自社のフェーズはシード、アーリーステージ。まだまだ一つの専門領域のスペシャリティよりも、自社の為にできることはなんでもやるという姿勢が求められていたので、例えばセールスでもの個人業績で評価するっていうのではなくて、とにかく、このバリューに沿っているメンバーを評価する形に変えようという判断をしました。

もちろんセールスのような定量結果が分かりやすい職種の方からすると、そういったものも加味してほしいと当初は反発もあったのですけど。

小林：個人目標での評価をしないのですね。

木元：そうです。個人目標ではなく、チームのOKRに対しての進捗度合いや貢献度合いを見ていました。

ただ、先程お話した通り、やっぱり自分のスキルがあがったことも評価して欲しいという不満が出てくるのですよね。そこで、3つのバリューのうち1つは「自己成長する」という意味合いだったので、職能毎にマネージャーと議論して「こういう風に自己成長していくと良いよね」というスキルセットを定義しました。

バリューとしては共通ですが、その判断軸は共通ではなく、職能によって変えいくことで実現しました。

結果として、評価制度をこのように変えたことで、評価設計に対しての満足度やエンゲージメントのスコアも上がったと思っています。

小林：数値として成果が表れたのですね。OKRが合う組織、MBOが合う組織と言うのも、職種によってやはり変わってきますよね。

西島：そうですね。セールスが中心の組織だと、MBOに思い切りシフトした方が評価の納得感もありますし、短期で業績も伸ばしていけるので強いということもありますね。ただその場合も、人数が増えてくると社員がソルジャーのようになってしまうので、どこかで変化が必要だと思いますね。

小林：組織が拡大していく中での変化は必ずありますよね。ベンチャー初期に個々の裁量や能力で成長してきたところが、MBOを取り入れて拡大したときに、新しく入社する人材のタイプが少し変わってくる。そこで初期メンバーが抜けたり、人材が流動することも起きますよね。

西島：よくありますよね。なので、組織規模によって変えていかないといけないことは必ずあると思います。

小林：会社ごとに職種特性を踏まえて人事制度を作る重要性についてお話しできたので、この後は規模による変化についてお聞きできればと思います。

次回もお楽しみに！

今回は、多様な職種が存在する組織の中で、職種の特性を生かしながら最適な制度をどのように作っていくか？ をお話しいただきました。次回最終回では、スタートアップが拡大期を迎えるフェーズにて、どのタイミングでどのように人事制度を変革させるべきか、組織規模の観点における最適な人事制度をお話します。お楽しみに！