人事評価

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

大前提

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

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

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

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

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

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

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

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

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

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

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

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

PrAha Challengeの卒業生がPrAhaを転職先に選んでくれる機会が増えていますが、それも修行中と1人前の給与制度を分けているからこそと言えます。

なので「これからの成長に期待する人にも門戸を開きたい」という思いから新たに修行中枠の給与制度を設け、それに伴い評価制度が生まれました。

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

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

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

人事評価制度の概要

スキルとは？

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

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

スキル1：確動性が高いか？
スキル2：技術者として慣れているか？
スキル3：学習意欲、能力が高いか？
スキル4：質の高い開発ができるか？
スキル5：チームで成果を出せるか？
スキル6：アガルートグループ全体に対してどこまで影響力を持っているか？（正社員のみ）
スキル7：業界全体に対してどこまで影響力を持っているか？（正社員のみ）

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

給料(月額報酬)が上がります。

スキル1〜4を満たすと、「1人前」と呼ばれます。

それまでは「修行中」と呼ばれます。

エンジニアのスキル詳細

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

正社員の場合、要素（✅）を満たすごとに昇給します
- ()の中の金額は、正社員の場合の昇給額です
- たとえば、スキル1の要素を4つ満たすとベース給与618＋(5×4)＝638万円/年になります
業務委託の場合、スキルを満たすごとに昇給します
- 以下はスキルごとの昇給額です
  - スキル1: +32.4万円
  - スキル2: +32.4万円
  - スキル3: +32.4万円
  - スキル4: +32.4万円
  - スキル5: +62.4万円
- たとえば、スキル1,2,3を満たすと、ベース給与768+(32.4+32.4+32.4)＝865.2万円/年になります
このページには記載していませんが、デザイナーも同じようなチェックリストで評価しています

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

✅要素1: ミスが起きた際、自力ですぐに修正できる（+5万円）
- 指摘された箇所をすぐ直せる
- 指摘された問題にすぐ対応できる
- 問題が起きたときのリカバリー方法を事前に考えている
✅要素2: 過去の失敗から学び、同じ失敗をしない（+5万円）
- 過去のやり方や考え方に固執せず、変化し続けられていること
- ミスの原因を考えて対策を講じる
- 何度も同じミスを指摘されない
✅要素3: 1人でも着実に仕事を進められる（+5万円）
- 能動的に動き、誰かから細かく指示を受けなくても着実に成果を出せる
- 正常系の処理が網羅されていないコードを書かない
- 異常系が考慮されていないコードを書かない
- 誤った結果を生み出してしまうコードを書かない
✅要素4: 情報伝達ミスが少なく、周囲と心地よく協働できる（+5万円）
- 相手の意図を正確に把握し、他者に求められた成果物を齟齬なく提供できる
- 必要に応じて確認して認識をすり合わせる
- 進捗を周囲に共有し、チームとしての行動に支障をきたさないように動けるか
- 仮に進捗が遅れているときは適切なタイミングで周囲に共有できているか、リカバリーをできているか
✅要素5: 他者に仕事を頼む際、相手が確動性高く対応できるような明確なコミュニケーションを取れる（+5万円）
- 相手の誤解を生まないよう、具体的な指示を出せるか
- 自身の思考や求める結果を明文化して齟齬なく伝達できるか

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

✅要素1: フロントエンドの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円）
- 基本的な実装（ビューの構築、APIとの連携、feロジックの実装など）を周囲に負荷をかけることなく1人で実装できるか
- バグや不具合などを自力で解決できるか
- 手戻りによるタイムロスなく実装できるか
- 1人で作業を任せてもスプリント（何らかのタイムスコープ）終了時に想定を大きく逸脱しない成果物を出せる
✅要素2: バックエンドの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円）
- 基本的な実装（db設計、アプリ単体で完結するような単純なデータのCRUD、テストの実装など）を周囲に負荷をかけることなく1人で実装できるか
- 以下、同上
✅要素3: インフラの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円）
- 基本的な構築（アプリケーションの実行環境の構築、dbのセットアップ、モニタリングや監視の仕組みの構築など）を周囲に負荷をかけることなく1人で実装できるか
- 以下、同上
✅要素4: 挑戦的な実装を担当しても大きく速度を落とすことなく実装できるか（+12万円）
- チームに知見を持っている人がいないような領域の実装を任されても適切な技術調査を行ない、スプリントで合意した時間内に解決策を実装できるか
- 設計や実装で何か問題が起きた際に、周りの力を借りるなど、素早く必要な対応を取れること
✅要素5: 周囲の速度を落とすことなく立ち回れるか（+12万円）
- 自身の実装速度を高めるために周囲の実装速度を落とすようなことがないか
- 他者に仕事を依頼する際、相手が速度を落とすことなく作業できるような頼み方や、前提の共有をできているか

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

✅要素1: 個人の時間でも勉強しているか？その結果をアウトプットしているか？（+13万円）
- 個人の時間に絶えず学習を行なっているか
- 周囲が学習意欲を判断できるようなアウトプットを行なっているか（timesへの投稿、技術記事の執筆など）
✅要素2: 日々できることが増えているか？（+13万円）
- 学習結果を活用して新しいことができるようになっているか
- 学習したことが見える形でアウトプットに反映されているか
✅要素3: 学んだことを他者に教えられるほど理解しているか？（+13万円）
- 学んだことを自分の言葉で説明できるか
- 他者に説明できるほど深く物事を学んでいるか
- 学んだことを他者に伝えたり外部に発信できているか
✅要素4: 他者の学習意欲、学習能力も向上させているか？（+13万円）
- 周りの人にメンションして質問したり、勉強会に誘うなどして、自分以外の人の学習意欲を高めているか
- 社内にとどまらず社外の人も参加できる学習体験を生み出しているか

スキル4：質の高い開発ができるか？

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

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

✅要素1: チーム全体の生産性を底上げする努力をしているか？成果を出しているか？（+20万円）
- チームの開発手法を改善する、新しいツールを導入するなどして、チームの生産性向上に貢献しているか
- 自信の守備範囲を広げ、チーム内での貢献手段を増やそうとしているか。
  - 例えば…
    - PdMとして円滑なプロジェクトを進行を支援する
    - デザイナー、POなど、チーム外のメンバーとのやりとりの窓口を担う
    - スクラムプロセスを改善している
    - 他のエンジニアの開発者体験の向上につながる施策をしている
- 自分がいなくなるとチームの成果や成長が止まるぐらい重要な存在になっているか
✅要素2: 他のメンバーを助けているか？（+20万円）
- チーム内、あるいはチームと密接に関わる人が困っているとき、助けを差し伸べているか
- 直接助けを差し伸べられない場合も、助けを差し伸べられる可能性のある人に共有するなど、状況の改善に向けて行動しているか
- 他のメンバーの業務を阻害したり、生産性を低下させる動きをしないか
✅要素3: 課題を自ら見つけ、解決策を提案し、解決しようとしているか？（+20万円）
- 仕事を割り振られるのを待つだけでなく、解くべき課題を自ら見つけられているか
- 解決したときチームに役立つ課題を見つけられているか
- 課題を指摘したり不満を口にするだけで終わらず、解決策を提案できるか
- 課題を解決するための段取りを自分で作り、解決に向かっていけるか
✅要素4: 適切なコミュニケーションを取れるか？（+20万円）
- 端的に要点をまとめて意見を伝えたり、質問に答えられる
- 自分の要望を伝えて他者の協力を得られる
- 利害や優先順位が異なる人の意見をまとめて、開発を円滑に進められる
- 相手に不快感を与えないコミュニケーションを取れる
- チームの雰囲気を悪くしたり、他のメンバーに気を遣わせるなど、周りに負荷を与える振る舞いをしない
✅要素5: チームの力を活かして問題解決できるか？（+20万円）
- 単独で解決できる課題だけではなく、周囲の支援や行動を必要とする挑戦的な課題も解決していけるか
- 課題を解決する際に孤立せず、関係者を巻き込み、協調して課題を解決できるか

スキル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への貢献などを通してコミュニティに貢献している

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

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

スキル通過申請シートを埋めて提出する
- たとえば、Aさんのスキル通過申請シートを提出できるのは、以下のいずれかの人です
  - Aさん本人
  - 何らかのプロジェクトのリーダー
  - 1人前の社員
- スキル通過申請シートはいつでも提出できます
提出を受けたら、「1人前の社員」がスキルを会得しているか否か判断する
- 評価に参加したい「1人前の社員」が評価を行ないます

評価のポイント

妥当性

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

プロジェクトの期間

より長くプロジェクトに在籍しているとプラス
1か月しかプロジェクトに在籍していない場合、まだ難易度の高いタスクが渡されていない可能性がある。一方、同じプロジェクトに3年所属していれば重要なタスクを任されている可能性が高いため。
難易度の高い仕事に挑戦しながらも推薦を受けている人の方が高く評価されるべきだと考えているため、長く参加しているプロジェクトに関する推薦の方が高く評価されやすい

プロジェクトの数

より多くのプロジェクトで推薦されているとプラス
特定のプロジェクトでのみ推薦される人より、プロジェクトを問わず推薦される人の方が高く評価されやすい
より汎用的にスキルを発揮できる人の方が高く評価されるべきだと考えているため

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

評価に関わる1人前社員が8人を超えたとき（全員が集まると会議が非効率なため）
1on1などで社内メンバーが給与制度に不満を持っていることが判明したとき

この評価制度の問題点

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

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

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

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

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

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

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

FAQ

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

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

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

現時点ではないです。

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

あります。

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