人事評価

株式会社PrAhaの人事評価について紹介するページです。

大前提

目先のお金とか評価を気にして働く会社ではなく、ものづくりを楽しむ人の会社を作りたいと考えています。

「不自由なく暮らせる程度のお金がもらえたら、あとはものづくりに集中したいよね」というのがPrAhaの考え方なので、社内のジュニアとシニア層の報酬差はそこまで大きくありません。

会社の調子が良ければ全員昇給するし、調子が悪ければ全員減給する。そんな基本コンセプトに基づいて人事制度を考えています。

そもそもなぜ評価制度が必要なのか

PrAha的には評価制度を作りたくありません。隙さえあればなくしたいと考えています。

誰もが評価を必要としているわけではないし、評価にかかる時間をコード書いたりデザインを作る時間に充てたいし、他人を評価すること自体がおこがましいし、低く評価するのは心が痛みます。

そうした理由があるのにもかかわらず、PrAhaで人事評価制度を作っているのは、以下の2つの理由があるからです。

幅広い経験の人と働けるようになる
会社の方向性を揃えられる

幅広い経験の人と働けるようになる

「1人前の人しか採用しなければ評価しなくても済むのでは？」というのが創業当初のPrAhaの考え方でした。

ただし、この考えだと以下の問題がありました。

母集団が小さすぎて採用が進まない
「人柄も申し分ないし、これから間違いなく伸びるから、一緒に働きたいなぁ」と思う人でも、報酬額と比較するとコストが高すぎて採用できない

PrAha Challengeの卒業生がPrAhaを転職先に選んでくれる機会が増えていますが、それもその時点のスキルに応じた給与で迎えられる仕組みがあるからこそと言えます。

なので「これからの成長に期待する人にも門戸を開きたい」という思いから、スキルを会得するごとに昇給していく給与の仕組み、つまり評価制度が生まれました。

会社の方向性を揃えられる

開発やデザインのプロとして、必ず身につけなければいけない能力や振る舞いがあると考えています。

その要素を全員に日常的に意識してもらうためには評価に組み込むのが効果的だと考えてたので、会社の方向性を揃えるために評価制度を設けています。

人事評価制度の概要

スキルとは？

PrAhaが考える「1人前の社員として必要な能力」のことです。

たとえば、エンジニアの場合は以下の通りです。

スキル1：確動性が高いか？
スキル2：技術者として慣れているか？
スキル3：学習意欲、学習能力が高いか？
スキル4：先見性を持ち、想像力を働かせながら開発できるか？
スキル5：チームで成果を出せるか？
スキル6：アガルートグループ全体に対してどこまで影響力を持っているか？
スキル7：業界全体に対してどこまで影響力を持っているか？
スキル8：ユーザー体験と事業価値の両立を見極められるか？

スキルを会得すると何が起きるのか

給料が上がります。

エンジニアのスキル詳細

それぞれのスキルを満たすために、具体的にどんな要素（✅）を満たせばいいのかを記載しています。

要素（✅）を満たすごとに昇給します
- ()の中の金額は昇給額です
- たとえば、スキル1の要素をすべて満たすとベース給与676＋(5＋22＋12)＝715万円/年になります
このページには記載していませんが、デザイナーも同じようなチェックリストで評価しています

スキル1：確動性が高いか？

✅要素1: 1人でも着実に仕事を進められるか（+5万円）
- 能動的に動き、誰かから細かく指示を受けなくても着実に成果を出せる
- 自分の担当範囲で、扱うべき正常系を見極め、取りこぼさず実装に織り込める
- 異常系として起こり得ることを想像し、対応の要否を判断したうえで設計できる
- 自分の成果物が意図どおりに機能することを、自分で確かめ、レビュアーに証拠として示せる
✅要素2: 適切なコミュニケーションを取れるか（+22万円）
- 端的に要点をまとめて意見を伝えたり、質問に答えられる
- 自分の要望を伝えて他者の協力を得られる
- 利害や優先順位が異なる人の意見をまとめて、開発を円滑に進められる
- 相手に不快感を与えないコミュニケーションを取れる
- 相手の状況や場の空気に配慮し、心理的負荷の少ないコミュニケーションを取れる
✅要素3: 納期などの制約、不確実性に対して適切にアプローチできるか（+12万円）
- 技術的な不確実性や事業的な不確実性を認識し、適切な調査・対応を実施できる
- 関係者の期待値と自身が提供できる価値とのギャップを調整できる
- 関係者と合意した期間内に価値を提供できる

スキル2：技術者として慣れているか？

✅要素1: フロントエンドの実装・設計において、品質の良し悪しを見極められるか（+12万円）
- パフォーマンス・使いやすさ・セキュリティなど、良いフロントエンドとは何かについて深い知見を持っている
- エッジケースや細部の作り込みなど、フロントエンドのプロでなければ気づけない品質に気を配ることができる
✅要素2: バックエンドの実装・設計において、品質の良し悪しを見極められるか（+12万円）
- パフォーマンス・使いやすさ・セキュリティなど、良いバックエンドとは何かについて深い知見を持っている
- エッジケースや細部の作り込みなど、バックエンドのプロでなければ気づけない品質に気を配ることができる
✅要素3: インフラの設計・修正において、品質の良し悪しを見極められるか（+12万円）
- パフォーマンス・使いやすさ・セキュリティなど、良いインフラとは何かについて深い知見を持っている
- エッジケースや細部の作り込みなど、インフラのプロでなければ気づけない品質に気を配ることができる
✅要素4: 前例のない問題に対して、答えを生み出せるか（+33万円）
- 既存のものを真似るだけでなく、自分たちに固有の問題のために、まだ存在しないものを作ることができる
- 前例やライブラリがない状況でも、解決策を構想できる
- 構想した解決策を、実際に動く形に落とし込む技術力がある

スキル3：学習意欲、学習能力が高いか？

✅要素1: 新しいものに関心を持ち続けているか（+13万円）
- 新しいツールや手法に対して強い関心を持っている
- 関心を持つだけにとどまらず、手を動かして試している
- 手を動かすことで、業務に生かすための知識を得られている
✅要素2: 学びを仕事に還元できているか（+13万円）
- 学びから得た知識を業務で活かせる場所を見つけられる
- 学びから得た知識を業務で活かせる計画を立てて、挑戦できる
- 学びから得た知識を業務で活かして、実際に業務を改善できる
✅要素3: 自分と異なる視点を他者から学ぶ姿勢を持っているか（+13万円）
- 自分と異なるやり方に出会ったとき、否定でなく「なぜそうしたか／前提の違いは？」と問いを立てられる
- 意見の否定を自身の否定と捉えず、議論を学びの機会にできる
- 議論を通して、異なる意見をマージし、自分1人では辿り着けなかった答えに辿り着ける

スキル4：先見性を持ち、想像力を働かせながら開発できるか？

✅要素1: 責務を明確にして高凝集・低結合なコードを書けるか（+15万円）
- 新たに作成したコード（ないしシステムの一部）は、常に責務が明確になっている
- テスタビリティが高いコードを書ける（あるいはシステムの一部を作れる）
- 変更容易なコードを書いたり、システムの一部を作れる
- システムの複雑性を過度に増加することなく開発できる
- 後々の開発者が理解に苦しんだり、改修する際に苦労しないよう、既存のサービスに手を加えられる
✅要素2: 将来的に起こり得る問題を事前に想定して対処できるか（+15万円）
- 現時点では起きていないものの将来的に起きうる問題を見つけられる
- 1人前エンジニアでなければ気づかないような複雑な問題を見つけられる
- 見つけた問題に対策を講じられる
✅要素3: 既存サービスをリファクタリングして技術負債を減らせるか（+15万円）
- 既存コードを高凝集、低結合なコードに書き換えてテスタビリティや認知的負荷を改善できる
- コードに限らずシステムの構成要素を改善して、より高い非機能要件を満たせる状態を作れる
- デグレを起こさないよう必要な対策を講じた上でリファクタリングできる
- ボーイスカウトルールを忘れず、既存コードを少しずつでも構わないので改善している

スキル5：チームで成果を出せるか？

✅要素1: 自身の守備範囲を広げ、チーム内での貢献手段を増やそうとしているか（+22万円）
- PdMとして円滑なプロジェクトの進行を支援する
- デザイナー、POなど、チーム外のメンバーとのやりとりの窓口を担う
- スクラムマスターとしてスクラムプロセスを改善している
- 他のエンジニアの開発者体験の向上につながる施策に取り組んでいる
✅要素2: 他のメンバーを助けているか（+22万円）
- チーム内、あるいはチームと密接に関わる人が困っているとき、助けを差し伸べている
- 直接助けを差し伸べられない場合も、助けを差し伸べられる可能性のある人に共有するなど、状況の改善に向けて行動している
- 自分の動きが周囲の業務にどう影響するかを意識し、チームの生産性が落ちないよう振る舞える
✅要素3: 課題を自ら見つけ、解決策を提案し、解決しようとしているか（+22万円）
- 仕事を割り振られるのを待つだけでなく、解くべき課題を自ら見つけられている
- 解決したときチームに役立つ課題を見つけられている
- 課題を指摘したり不満を口にするだけで終わらず、解決策を提案できる
- 課題を解決するための段取りを自分で作り、解決に向かっていける
✅要素4: チームの力を活かして問題解決できるか（+22万円）
- 単独で解決できる課題だけではなく、周囲の支援や行動を必要とする挑戦的な課題も解決していける
- 課題を解決する際に孤立せず、関係者を巻き込み、協調して課題を解決できる
✅要素5: 暗黙知を明文化・形式化できるか（+22万円）
- チームの中に埋もれた暗黙知を見つけることができる
- 見つけた暗黙知を、ドキュメント・コードコメント・テストとして設計・運用できる
✅要素6: 失敗を起こさない・繰り返さない仕組みづくりができるか（+22万円）
- 障害・事故・セキュリティ問題・繰り返すミスなど、防ぎたい失敗を見極めることができる
- セキュアバイデフォルトな環境の構築・自動テスト・規約など、失敗を未然に防ぐ仕組みを構築できる
- 一度の構築で終わらせず、振り返りをもとに仕組みを継続的に育てられる

スキル6：アガルートグループ全体に対してどこまで影響力を持っているか？

✅要素1: 自身の所属部署だけでは完結しない大きな課題を解決できるか？（+15万円）
- 運用フローの変更、デザイン作成などの行動を他部署にも求めるような、自身の所属部署だけでは完結しない大きな課題を解決できる
- 他部署の業務改善、成果向上に貢献している
- 自身の成果物が所属するチームに留まらずグループ全体に影響を与えているか
✅要素2: 他部署と良好な人間関係を構築できているか？（+15万円）
- 他部署からとポジティブな形で存在を認識されている
- 他部署からの情報をチームにもたらすハブになっている、あるいはそうした情報がもたらされる仕組みを構築している
✅要素3: グループ全体に関する知識を有しているか？（+15万円）
- 自身の所属部署以外の業務や組織に関する知識を多く有している
- 上記知識を活用して、他部署からのクレームや遺恨を生むことなく、他部署にとっても満足度の高い意思決定を行える
- 上記知識を活用して、解決すべき課題を自ら発見し、解決策を提案し、遂行できる
✅要素4: グループ全体に発信しているか？（+15万円）
- グループ全体の技術力、ITリテラシーを高めるための発信/発表などをしているか
- グループ内で横展開されるような知見（実装方法/技術スタックなど）を提案、実用しているか

スキル7：業界全体に対してどこまで影響力を持っているか？

✅要素1: その人の存在が業界全体で広く認識されているか？（+33万円）
- SNSで技術に関連する投稿を通して多くのフォロワーを有している（Twitterでフォロワー3,000名以上など）
- 技術ブログで技術に関連する投稿を通して多くのフォロワーを有している（Qiitaの年間Contribution1,000以上など）
- SpeakerDeckの登壇資料や自著書籍などを多く有している
- 勉強会コミュニティを運営しているなど、社外のエンジニアと関係性を構築できている
✅要素2: その人の存在が採用競争において優位に立てる要因になっているか？（+33万円）
- 採用につながる広報活動を行っており、成果を上げている（採用1人以上、もしくは多数の面談数）
- グループ全体の認知度を上げるための活動をしており、成果を出しているか
- 開発者としての発信力を上げるための活動（SNS、ブログ）を日々行っている
✅要素3: アガルートグループへの採用影響を問わず、その人の存在が業界全体に良い影響を与えているか？（+33万円）
- 開発者コミュニティ全体に対して有益な情報を発信している
- OSSへの貢献などを通してコミュニティに貢献している

スキル8：ユーザー体験と事業価値の両立を見極められるか？

✅要素1: ユーザーを理解し、ユーザーの体験を突き詰めて考えることができるか（+22万円）
- 受講生/アガルート社員が、どんな状況で学び/働き、何に困っているかを考えている
- 依頼をこなすだけではなく、ユーザー体験の違和感を自分で感知できる
- エッジケースや異常系でのユーザー体験にも気を配ることができる
- その理解をもとに、ユーザーにとって本当に解くべき課題を見極めることができる
✅要素2: 事業と業務を理解し、技術判断に活かせるか（+22万円）
- アガルートの事業・収益モデル・製品やサービスが顧客に届くまでの一連の流れを理解している
- 技術的な正しさと、事業としてやるべきかを天秤にかけることができる
- 売上・コストの両面から、利益への貢献を意識して判断・提案できる
- その理解をもとに、事業にとって本当に解くべき課題を見極められる
✅要素3: 仮説を立て、データで確かめられるか（+22万円）
- 課題解決の仮説を立て、小さく作って素早く検証するループを回すことができる
- 何をもって成功とするかを定め、そのための計測・ログを設計できる
- 憶測ではなく、実際のデータに基づいて意思決定できる
- 施策の続行/撤退の判断を、データをもとに下すことができる

どうやってスキルを会得するのか

以下のような流れで会得できます。

スキル通過申請シートを埋めて提出する
- たとえば、Aさんのスキル通過申請シートを提出できるのは、以下のいずれかの人です
  - Aさん本人（自薦）
  - 社員（他薦）
- スキル通過申請シートはいつでも提出できます
提出を受けたら、スキルを会得しているか否か評価者が判断する
- 評価者は、スキル1〜4を会得している水準の社員が担当します

評価のポイント

妥当性

スキル通過を判断する上で妥当な推薦理由になっているか
- 例えばスキル5に対して「コードを書くのが速い」という推薦理由の場合、チーム成果と関係がないので妥当ではない
推薦項目に記載されたことは事実か
- 同じチームで一緒に働くメンバー（PrAha内外を問わず）にヒアリングして確認する

人事制度見直しのタイミング

1on1などで社内メンバーが給与制度に不満を持っていることが判明したとき

この評価制度の問題点

万能の評価制度は存在せず、すべての評価制度には問題がある（不安を抱える人がいる）と考えています。

今の評価制度の問題は以下の通りです。

一緒に働くメンバーが少ないチームにいる人は、評価に使える情報が集まりづらい
フルリモート、かつ各々が異なるチームに関わっているため、少ない情報で判断を下さなければいけない
エンジニアやデザイナーという職種は繰り返し作業が少ないので、具体的な評価項目を作りづらい
- 以前「Vue.jsでコレができたら昇給」というような細かな評価基準を作ったことがあるが、すぐ基準が陳腐化して誰も使わなくなった
そもそも定量的に判断しづらい職種だから、多数の定性評価を集めて定量的な判断を代替しよう、というのがPrAhaの評価制度の根底にある考え方
そのためには多数の定性評価が必要だが、定性評価が集まりづらい条件が揃っている（チーム制、フルリモート）のが今のPrAhaの評価制度の最大の問題点

この評価制度を廃止する条件

評価制度は基本的に撤廃したいと考えています。

以下の課題さえクリアできれば撤廃したいと思っています。

これから間違いなく伸びる！　と感じたジュニア層を採用できる
- 全員給与を一律にすると能力に対する報酬が高すぎるため会社としての経営が苦しくなる
社内の不満が今より減る
- 「なんでこの人自分より圧倒的にスキルが低いのに同じ報酬なの？」という不満が起きない
スキルを伸ばすモチベーションがなくならない
- 報酬が一緒なら頑張らなくてもいいや、みたいな
会社として大事にして欲しい行動を促せる
- チームの成果を最大化することを考えて動くとか、想像力を働かせて働くとか
現実的な負荷で採用面接を実施できる
- 評価をなくすと採用面接で事前に見ておかなければいけないことが増える。ただでさえ重めの面接を実施している＋PrAha自体の知名度が足りないため、そもそも受けてくれる人がいなくなってしまう問題

FAQ

なぜ申請シートを記述するの？

口頭だけで評価を実施してしまうと評価の観点や「何をすれば昇給するのか」などの大切な情報が隠蔽されてしまうから
納得感のある制度を作るためにも過去の決定や検討事項は残しておきたい

スキルを失うことはあるの？

現時点ではないです。

一度の申請ですべてのスキルを通過する可能性もあるの？

あります。

ずーっとスキルが上がらないこともあるの？