なぜカケハシは、評価制度をボトムアップでつくったのか？

カケハシ人事担当の黒田です。

2022年4月、カケハシは全社的に人事評価制度をリニューアルしました。今回の制度リニューアルでは、ビジネス職とサービス開発職それぞれに個別の評価制度を設けることになり、特にサービス開発職においては、各職種の代表者とともにプロジェクトチームを組み、完全なるボトムアップで制度設計を行いました。

なぜわざわざそんな（面倒な？）ことを実践したのか。背景にある思いと、具体的なプロセスを公開することで開発組織の文化をお伝えできたら……ということで、記事にまとめてみたいと思います。

※リニューアルした評価制度の全体像については、こちらにまとめていますので併せてご覧いただけると嬉しいです。

今回のプロジェクトが生まれた背景
制度の”開発”プロセス
1.キックオフ（12月初旬）
2.評価制度の思想に関するアンケート（12月中旬）
3.ロングミーティング（1月中旬）
4.オープンドア（2月中旬）
5.大詰めミーティング・リリース（2月後半～3月）
さいごに
制度の根っこにある「思想」の整理こそ丁寧に。
プロジェクトマネジメントではなく、プロダクトマネジメント。

すべて表示

今回のプロジェクトが生まれた背景

まず、CTO海老原が社内説明会で発した言葉がこちら。

我々が行っている「開発」には定まった正解がなく、いつ不測の事態が起こるか分からない。複雑な関係性の中でより正しさに近いものに向かって試行を重ね、漸近的に近づいていく営為の典型です。

VUCAの世界で、思考「だけ」の領域には正解も致命的な危機回避のための予見もありません。サービスにおける「真実」が、顧客や市場の中にしかないのと同じです。

そのような世界観の中で常に最も重要なのは、「思考」と「実践」を限りなく近い距離に置くことだと考えています。

海老原節で少々難しい言葉が並んでいますが（笑）、この実践の現場における判断を重視するというスタンスが今回のプロジェクトの背景であり、カケハシの開発組織の文化を最も強く表しているポイントだと思います。

これは言うは易しというか、実際にやってみるとつい経営の方針を聞きたくなるケースも多々あったのですが、海老原には一貫してレビュアーの立場を貫いてもらいました。

制度の”開発”プロセス

プロジェクトメンバーは、ソフトウェアエンジニア・SRE、プロダクトマネージャー、デザイナー、ディレクター（スクラムマスター）、ドメインエキスパートそれぞれの代表者1名ずつに、HRBPなど人事メンバー3名を加えた計8名。

合計17回、約24時間のディスカッションで制度設計を進めました。

1.キックオフ（12月初旬）

まずは各々が何を気にしているのか、現在地の確認からスタートしました。

現制度への課題提起に加えて、そもそも評価に時間を取られたくない（そのぶん開発に集中したい）といった意見もありましたが、「それでも評価というものを実施するのか？実施するのであればその意義は何か？」を思想の部分から考え尽くすために、「我々はどういう組織でありたいか？どういった人材であるべきか？」という問いで、あるべき組織のイメージを整理していきました（オンラインで実施）。

2.評価制度の思想に関するアンケート（12月中旬）

キックオフでの議論を受けて、プロジェクトメンバーがキーワードの叩きを作成。それに対して現場メンバーへのアンケートを実施しました。

さまざまな観点からのフィードバックとともに、今回のプロジェクトへの期待についてもコメントが寄せられました。一部抜粋してご紹介します。

何のための評価制度かが明らかになると良い。報酬体系がフェアなものになると良い（何がフェアなのかの価値観の差があると思いますが……）。

個々の生存バイアスによる局所最適が発生しない制度設計を期待したい (難しいですが)

評価労力の削減。

これは目標の設定次第なのかもですが、施策を打ってから事業的な成果が出るのは、少しディレイがある（当期の施策の成果が出るのが次期だったりする）ので、そういったところが考慮されると良いなと思いました。

「探索的思考」を重視するなら、半年前の目標なんて陳腐化して当然だよね、という前提で最初から評価制度が組まれていると、個人的にはとても分かりやすいです。

3.ロングミーティング（1月中旬）

3時間×2回のミーティングで、新制度の骨子を練り上げました。ここでは、特に熱く議論した内容をいくつか取り上げたいと思います。

【論点1　チーム評価を採用するか？】
「チームの相互作用」というキーワードを踏まえ、個人評価とは別に「チーム評価」を導入してはどうか？というアイデアが出てきました。ユーザーへの価値提供を異職種のチームで成すこと、チームを大切にするカケハシらしさという点が意見の背景です。

一方で、プロダクト開発ではない横断組織（例えばSREやドメインエキスパート）でそれがうまく機能するか、という点が議論に挙がりました。横断組織では個々人がプロジェクトベースで動くため、チームの成果≒個人の積み上げとなり、チーム評価で誘引したい価値（相互作用）が実現できるのか？という懸念です。

結果的には、横断組織においてもチームとしての相互作用最大化に向けてトライするという結論に至ったのですが、これはPJTメンバーの「実験として思想にトライしてみよう」という一言で前に進みました。

【論点2　ノーレイティングを採用するか？】
探索的学習を重視するという方針に、半年前の個人目標を基準とした評価はマッチしないのでは？という問いからスタートした議論です。絶えず変化する開発組織の業務において、期初の目標設定よりもリアルタイムの目標設定・フィードバックがマッチするであろうことは皆が感じており、「ノーレイティング」の採用について話し合いました。

結果的には、ノーレイティングは査定の難易度と運用負荷が跳ね上がるので、もう一つの方針である「開発に集中できる時間を確保する」という観点を優先し、報酬配分のルールを設定することでレイティングを採用しました。一方で、リアルタイムの目標設定・フィードバックの思想は取り入れることとし、評価者と被評価者による定期的な個人面談（1on1）のガイドラインとして策定しています。

4.オープンドア（2月中旬）

評価制度の骨子ができたタイミングで、被評価者となる開発メンバーに向けたオープンドアを実施しました。オープンドアとは、誰もが自由に質問したり疑問を投げかけたりすることのできる意見交換の場です。

今回は1時間×2回の場を設けて、骨子の紹介とQ&Aセッションを実施。加えてフィードバックシートを設けて、説明会の後でも疑問を解消できるようにしました。

5.大詰めミーティング・リリース（2月後半～3月）

最後の1ヵ月はプロジェクトメンバーで集まる頻度を増やし、オープンドアで寄せられたフィードバックをもとに、制度の詳細や運用イメージの詰め、個人面談（1on1）ガイドラインやコミュニケーションデックの作成などを進めていきました。

レイティングのラベルについても、個人評価とチーム評価との混同を避けるために、社内のクリエイティブディレクターを巻き込んで作りこみました。

結果、どのような評価制度になったのかは、別の記事にまとめていますのでぜひご覧ください。

さいごに

今回のプロジェクトは、人事として学ぶことの多い貴重な機会でした。最後に、特に強く感じた3つのポイントをお伝えして結びにしたいと思います。

制度の根っこにある「思想」の整理こそ丁寧に。

まずは、制度設計の前段にある「思想」の整理を丁寧に行うこと。言わずもがなですが、抽象と具体を行き来するにあたって、「そもそも何を促進したいのか？それはなぜか？」という部分が曖昧だと制度に一貫性がなくなります。一般的にはここが経営層からのメッセージなどになるケースも多いと思いますが、ボトムアップで行うときにはなおさら丁寧に時間をかけたほうがよいと感じました。

プロジェクトマネジメントではなく、プロダクトマネジメント。

制度設計を「達成・終わり」を意識するプロジェクトマネジメントの思考ではなく、「継続・改善」を意識するプロダクトマネジメントの思考で進める意識が強くなりました。制度もプロダクトと同じく、価値提供に繋がっているかという観点で突き詰められるべきであること。そして、継続的な改善への意識が重要であること。実際にプロダクト作りを担う開発メンバーと一緒にプロジェクトを進められたことで、その重要性を感じる場面が多くありました。

オープンドアのススメ。

もちろんすべての意見を吸収できるわけではないのですが、参加者の反応によって“制度がしっかり運用されるかどうか？”の感覚を掴むという意味で、非常に有用な取り組みだと感じました。また事前にオープンドアがあったことによって、制度リリース時の説明会でのスムーズな理解に繋がったと感じています。