見出し画像

評価制度とは一体なんなのか。チームで成果を上げ、会社やメンバーの可能性を広げたい

会社にとっても、社員にとっても、100%ハッピーな評価制度なんて存在しえないのかもしれない。そう思ってしまうほど評価制度の設計は難しく、公正で納得感がある制度運用を目指すことは更に難易度が上がります。2021年4月、フクロウラボにも評価制度が本格的に導入されました。各社様々な制度体系がある中、どのような思いで制度がつくられたのか。CTOの若杉竜一郎(わかすぎ・りゅういちろう)さんにその策定背景を聞きました。

少し長い記事です。すべて読み込むのは骨が折れるかもしれません。改めて、制度を作る側の想いや文脈というのは、なかなか伝えきれないものだなと感じます。社内メンバー、フクロウラボにちょっぴり興味を持ってくれた方、これから面接を受けていただく方などに、フクロウラボの芯に流れている想いに触れていただければ嬉しいです。

課題解決の手段としての評価制度

画像1

——創業から8期目、評価制度が必要だと考えた背景を教えてください。

以前から、社員規模や階層が一定基準に達したら評価制度が必要になってくるという認識はあり、想定はしていました。実際にその基準に近づくにつれ、僕自身が肌で感じていたことはふたつあります。

ひとつは、頑張った人がきちんと評価される仕組みがあり、秩序があること。制度導入前は、給与がどういう基準で決定されているのかメンバーにとって疑問があったと思います。

もうひとつは、採用の場面ですね。面談の中で、エンジニア業務がどういう基準で評価されるのかを聞かれるシーンは意外と多い。営業職は数字が上がれば評価につながりやすいですが、エンジニアリングは見えにくい業務が多いため、そこが理解されるのか気にする人は多いのかもしれません。制度を整えて運用し、候補者にポジティブに捉えてほしい思いがありました。

上場を見据えて通らなければいけない道だというのもありますが、開発部においてはこのふたつを解決するため、評価制度が必要だと感じていました。

良い行動、良い仕事とは?

画像2

——評価制度を導入するとなると、会社として何を評価するのか、というのが重要なポイントですね。

全社目標を全員で達成すること、また、個々人の成長がそこに紐づいていることの目線合わせのための制度でもあるので、それに対する貢献度や達成度を評価することが前提ではあります。僕個人としては、良い行動や仕事を評価したいなと設計時に思っていました。

——良い行動、良い仕事というのは抽象的で、人によっても解釈の幅がありそうです。若杉さんにとっての良い行動とはどんなものですか?

周りを巻き込んで成果を上げたり、チームの生産性が上がるなど、周囲に良い影響を与えるような行動ですね。自分が成果を上げるのはもちろん良いこと。加えて、例えばチームメイトの評価が上がるような、連鎖的なアクションができるとなお良いと思います。

——若杉さんのインタビューでは、チームというキーワードがいつも出てくる印象があります。過去の経歴の中でチーム作りが大事だと感じた背景はありますか?

これまで、マネジメントされる立場でもする立場でも、いろんなチームに所属してきました。うまくワークしていなかったチームにいた時は特に、チームワークの難しさを感じたり、チームワークなんて必要ないのではと思っていたことさえありましたね。

ただ振り返ってみると、役割分担という共通点が見えてきます。チームワークの定義は組織によって異なると思いますが、個人的には“チームの中で役割がきちんと与えられ、個がそれぞれの役割を全うすることで、チーム全体の目標にも貢献していること”ではないかと考えています。

特にチーム内での役割分担が重要。これまでの経験から、チーム内で役割分担のバランスが良い時はうまくいっていたし、逆に役割が曖昧な場合や複数のメンバーで同じ役割がかぶっている時は、うまくワークしなくなっていたなと。

——目標設定をする際に役割や期待値について対話を深め、評価制度を通して役割分担を明確にすることもできますね。会社として、個人プレーをあまり歓迎しない文化がありますが、若杉さんがチームで成果を上げることにこだわる理由を聞いてみたいです。

僕は、チームで成果を上げることが最終的にいちばん大きな成果を上げられると思っています。現実的に、メジャーリーガーのようなハイパフォーマンス人材ばかりを集めることは難しく、チームで戦わざるを得ない一面もありますが、個人的にチームプレーが好きというのもありますね。単純に、1人でうまくいったときよりも、チームでうまくいったときの方が、楽しいんです。

また、もしハイパフォーマンス人材をたくさん採用できたとしても、パフォーマーが集まると今とは全然違うカルチャーになります。そうすると振り切ったカルチャーになりがちで、そのコントロールをするのは難しかったり。総合的に考えて、チームで事を成すのが良いなと。

——なるほど。だから成果目標以外に、組織貢献に関する評価項目もあるんですね。

そうですね、そこで“配慮しあう”というフクロウラボのバリューが生きてくる。評価制度の設計をする上でも、組織貢献の項目を入れたい気持ちは大きかったです。

会社が大きくなればなるほど、一人では実現できない、力を合わせてチームで戦う必要があるミッションが増えていきます。自分のことだけ考えるのは簡単ですが、チームがより良くなるように活動する視点を、必ず持ってほしい。

ただ、そういった行動はわかりやすい成果が出にくい場合も多く、万一評価されないとなると、メンバーとしてはなかなかアクションに移しづらい面があると思います。積極的に動きやすくなるよう、組織貢献につながるアクションもきちんと評価される仕組みにしたいと考えました。

画像5

——もうひとつ、課題解決に関する評価項目がありますが、その意図を教えてください。

全社目標を達成するうえで、個人がどのような成果を出すべきか。数値目標の達成やプロダクトを作るなど、ある程度分かりやすい定量的な目標を持つことも大切です。でも、それ以外の部分でも仕事というのはもちろんあります。定量目標を達成する以外の仕事とはなにか、と考えたときに、多くの割合を占めるのは課題解決なのではないでしょうか。

例えば、チームメイトが困っていたら手助けするとか、バグの原因がわからないから知恵を貸してくれとか。自分を含めた色々な人の課題、組織的な中長期的な改善取り組みなども、課題を解決することが仕事であります。「問題があるからできません」ではなく、それに対してどうやって解決できるのか、そういう認識を持ってほしい。フクロウラボのバリュー、“コトに向き合う”“期待を超える”を実践するということだと思います。

——設計に一番時間がかかったのが、この評価項目を決める部分だったかと。特に迷った点はありましたか?

業績成果に対する評価を組み込むことはイメージしやすいですが、バリューを評価にそのまま組み込むのか、という部分が難しかったです。

一見、そうした方が分かりやすかったのですが、“コトに向き合う”“配慮し合う”“期待を超える”というバリューは、人によって捉え方やアクションが大きく異なりそうな懸念がありました。そのため、バリューをさらに分解し、共通要素となる“課題解決”“組織貢献”に対する能力開発を推奨するような設計にしました。

ここについては、実運用と並行しながらメンバーからもフィードバックをもらい、より会社として目指す方向へ導ける制度となるように適宜バージョンアップしていければと思っています。

実現したいのは、安心して業務に取り組める組織

画像3

——評価制度を設計する際、大切にしたことはなんですか?

安心して業務に取り組めること。

まず、評価があるのか、どうやって評価されるのか不明確な状況下では、安心できないですよね。今の評価制度が完璧じゃないにしても、基準を示すことで、安心して業務に集中しやすい環境づくりを意識しました。これは副産物的な効果ですが、目標が決まればそれぞれの役割が決まり、何をすればいいのかがわかるので業務の効率化も図れます。

また、自分の将来のキャリアみたいなものを普段そこまで考えていなくても、評価制度に付随して自分のグレードが決まるので、次のグレードにステップアップするにはどうしたらいいか、若干考えると思うんです。そういうきっかけになってほしい気持ちもありました。

僕は各メンバーが自分自身のためにも成長すべきだと思っているし、成長できたほうがハッピーだと思います。評価制度を通して自分の課題を見つけ、それに向かって成長するための手助け、道しるべになればと。

——CTOとして、どのような環境づくりを大切にしていますか?

技術面だけを考えてえいれば良いという立場ではないのですが、なるべくエンジニア目線で、常に技術力を磨いていける環境構築は心がけています。また、メンバーの行動をルールで縛るのではなく、メンバーが能動的に考えて行動や改善していけるようにと考えています。

——設計において様々な議論をしましたが、特に印象に残っているのは?

グレードの設計について、特に記憶に残っています。一定のグレード以上になるためには、基本的にはマネージャー以上の役職を求められます。開発部門ではマネジメントをしなくとも、専門性を高める方向でもグレードを上げていけるコースを設計しました。

やはり、エンジニアは専門性が高い職種であるので、職人的に自分の専門分野にこだわり能力を伸ばしていけるパスも必要だと思ったので、提案させてもらいました。

対話を深め、成長のきっかけに

画像4

——今回インタビューをするにあたり、社内メンバーから制度に対する質問を集めました。その中で、「制度設計における苦労話や感情の共有をしてもらえると、メンバーそれぞれが協力してより良い制度を作っていこうという気持ちになりやすいのでは」という声をもらっています。

そうですね、設計にあたり未来を想像し、言葉や骨組みに落とし込んでいく作業はなかなか大変でした。経営チーム内でも考え方の違いがみられる部分があり、ひとつの制度に集約していく難しさがありましたね。目指す方向性は同じでも、部署により人数規模や習熟度も異なるので、働きかけ方は必ずしも同じではないんだなと。

人の力を引き出すような仕組みも重要だけれど、僕自身は能動的にこの会社の役に立ちたいなと思ってもらえるような仕組み、制度にしたい。ミッションなどの理念や行動指針、評価制度などのひとつひとつが、点ではなく繋がってカルチャーになっていくので、うまく設計し大事に育てていきたいですね。

——評価制度を通し、会社やメンバーにどんなふうに進化してほしいですか?

会社としては、周囲から信用され、働きたい会社と思われる一助になってほしい。そしてメンバーには、会社のためだけではなく個人のために、成長機会として使ってほしいです。

評価制度は会社によって個性が様々です。フクロウラボの評価制度がメンバーにうまくマッチして成長のきっかけとなり、会社の内外で活躍の場が増えたり、色々な可能性が広がるといいなと。

——今後、この評価制度はどのように変化していくと思いますか?

メンバーが上げてくれている課題や問題を微調整して、アジャストしていきたいと思っています。Ver.1.1ではまず、型を作ろうという部分にフォーカスしていたので、パーソナルな部分への対応や、個人最適化しやすい仕組みづくりまではあまり考えきれていなかったかもしれません。

目標設定において、苦手なものを補強するのか、はたまた得意なものを伸ばしていくのか。そういったコミュ二ケーションが、評価者・被評価者間でもっと深めていけるといいなと。本人のやりたいこと、つまりWillも含め、総合的に判断して目標設計していけると理想だなと思います。

今は、まずは制度という型を作った段階。これからさらに、細かいブラッシュアップをしていきます。


(文章:コーポレート/紙谷 夏美)