給与改定プロリクについて申請時に却下されるケースについて

リリース

給与制度の考え方詳細

給与は自己決定・人事評価やノルマはなし｜Ray Kataoka｜note

ゆめみの当たり前 より （参考）給与自己決定制度について ゆめみでは、給与や賞与を決定するための、 目標設定や人事評価は存在しません。過去はどちらかというと目標管理制度に基づき、 きっちり真面目に 目標をたてて、実績に基づいた評価で、昇給、賞与がダイレクトに決まる仕組みを取っていました。 ...

note.com

給与決定方法について

• ゆめみの給与決定方法は最終的にはX-pointの人事稟議＞稟議書（給与改訂）で申請を行い承認（追認）された内容で確定されます
• 一方で、何の根拠や申請内容の情報なしに申請をしても承認される確度は低いです
• 従って、申請した内容が承認されやすくなる確率・確度を高めるための方法が給与自己決定のプロセスとなります
• しかしながら、給与自己決定のプロセスは確度を高めるためのプロセスであり、必ずしもそのプロセスを全く経なくても、直接X-pointを申請して結果承認されれば、昇給は実現されることを明記しておきます

給与自己決定プロセス

決定方法

• プロリクで行う
• コミッター
• 本人と902_salary チームのコミッター
• コミッターを追加して自分の給与を他の人に決めてもらう事もできる
• 自己決定の意味
• 本人含むコミッターを自己と定義して自己で決められるという意味
• プロリクを行うSlack チャンネル
• 902_salary_engineer　エンジニア
• 902_salary_creator　デザイナー
• 902_salary_sales_marketing　営業・マーケティング
• 902_salary_management　プロジェクトマネージャー、EM
• 902_salary_corporate　コーポレート

プロリク方法

メンバー本人がチームに対してレビューをもらう方法

参考）給与プロリクテンプレ

STEP1：キャリアプランの作成

• Notionでキャリアプランを作成すること
• 参考）
• 中途：
• 新卒：
• フォーマット）

STEP2 ：年収額のレビュー

• 902_salary に関連する各種職種ごとのSlackチャネルに「年収額」をレビュー依頼する
• その際にキャリアプランを提示すること
• キャリアプランが分からないと、それに沿ったレビューやコメントがしにくいため
• スレッドで３人以上からレビューをもらう事

STEP3：

• STEP１でレビューを受けた年収額で、X-pointの人事稟議＞稟議書（給与改定）から変更後「年収」欄に記載して申請

メンバー本人が社内のキャリアコンサルタント担当にレビューをもらう方法

• キャリア面談をSlackで依頼する
• @Shingo Matsuda 　松田 新吾
• 松田さんが外部のキャリアコンサルタントとのブリッジとなって市場年収相場をフィードバックする場合があります
• @Fumiko Sakuma 　佐久間 史子

備考

• レビュー後、年収改定のコミット（X-point申請）をコミッターが直ちに行わないこともあるが、プロリクは半年間有効として、その期間の間に申請すれば良いとする
• 給与の変更は申請がされた翌月から、支給額の変更は翌々月の15日の給与支払いのタイミングからとなる。
• 申請日についてのFAQ

給与改定(X-point)申請条件

改定申請には以下の条件を満たすことで申請内容の承諾確度があがります

条件１：YUMETAMI（星取表・職位）の更新

条件２：キャリアプラン（職位ガイドラインに沿った自己評価含む）作成・更新

前回の改定以降、Notionの個人のページに「キャリアプラン」を記載する

• デザイナー職についてはポートフォリオを含めることとする
• エンジニア職については、職位ガイドライン詳細に沿った自己評価とLapras URLを含めることとする （注意：プライベートリポジトリの活動もLapras評価に反映させること：方法）

条件３：キャリア面談の実施

前回の改定以降、キャリア面談を受けることが必要となる

条件４：プロジェクト貢献の記載

営業職・PM職・EM職以外の職種のリード職位までの人はプロジェクト貢献指標の自己評価を行うこと

1. 💰給与自己決定制度（公式ドキュメント） - プロジェクト貢献指標 評価
2. プロジェクト貢献内容の具体的なものはキャリアプランシートに記載する

営業職・PM職・EM職および、それ以外の職種のシニア職位以上は以下を記載すること

1. プロジェクト貢献として成果実績を必ず記載（売上・利益率・受注率・提示単価・顧客満足度・育成成果他）
2. プロジェクト貢献内容の具体的なものはキャリアプランシートに記載する

条件５：ランク及びレンジ内年収額のプロリク

• （必須）年収額についてのレビューが３件以上ある
• 上記のレビューが３件以上ない場合はX-pointの給与改定の申請が却下される
• １件以上は、昇格後のランク以上の人からのレビューを含むこと （2024/4/1〜）
• 例：現在プロフェッショナルのランクのエンジニアの人がサブリードのランクへの昇格の給与プロリクを行う場合は、サブリード以上のランクの人からのレビューをもらう必要がある
• ただし、昇格後のランク以上の人が社内にいない場合は、社長からのレビューをもらうことが可能

• （必須）プロジェクト貢献についてのレビューはプロジェクトオーナー（通常はPdM、シニアプロデザイナーなど）からのレビューを必須とすること

条件６：シニア職位の場合「リーダーシップアセスメントの実施」

• シニア職位以上での給与プロリクを行う場合に、リーダーシップサークルプロファイルというアセスメントを実施した上で専門コーチとのコーチングを受けること
• ただし、給与プロリクを行ってから１ヶ月以内に申し込みする形でも良い
• 申込はコーチングチャンネル（#201_coaching）に依頼する

1. 稼働時間
2. 単価期間あたりの生産性
3. 役割・職務範囲にこだわらない動き方
4. 能動的な仕事の進め方

合計ポイントとレンジの関係性

• 合計4〜20pointの中でレンジの中での給与を自己決定（12pointがレンジの中央値）
• 4項目のそれぞれに対して、1-5pointでの自己評価をする
• 合計が4pointであればレンジの下限に近く、合計20pointであればレンジの上限近くを、あくまで目安とした上でプロリクを出す
• 加点評価も加えて、合計20pointを超える場合でもランクで定められたレンジの上限を超えないものとする

例として、職位ガイドラインに基づいて、チーフプロフェッショナルのランクを決定した後、ランク内の給与レンジ（６００〜６５０万）については、合計ポイントに基づいて決める

ただし、合計ポイントには、以下の加点要素を反映させる

加点要素

プロジェクト貢献（加点要素）

• 顧客から指名で自身が評価を得ている、かつ項目4がSS評価以上 +1point

組織貢献（加減点要素）

• メインに所属しているギルドの過去半年間の平均案件稼働率実績が85%を超えている、かつ自身の項目1がSS評価以上 　+1point
• 項目1、項目3の評価が両方ともSS評価以上かつ、社内プロジェクトの稼働率も10%以上ある場合 　+1point
• メインに所属しているギルドの過去半年間の平均案件稼働率実績が80%を下回っているかつ自身の項目1がA評価以下 　-1point（2025/2/1〜予定）
• メインに所属しているギルドの過去半年間の平均案件稼働率実績が75%を下回っているかつ自身の項目1がA評価以下 　-2point（2025/2/1〜予定）
• メインに所属しているギルドの過去半年間の平均案件稼働率実績が70%を下回っているかつ自身の項目1がA評価以下 　-3point（2025/2/1〜予定）

給与プロリクによる昇給・昇格・昇進条件

給与プロリクを行う際の条件としては以下がある

昇給・昇進条件

以下に明記した条件が必要

🎯ゆめみターゲット（成果基準）ver0.17

ランクアップ（昇格）とは

• プロフェッショナルランク→チーフプロフェッショナルランクのようにランクを上げることを指します
• 従って、プロフェッショナルランク内での昇給（年収アップ）として、540万→550万のようなランクアップを伴わない昇給については対象外となります

ランクアップ（昇格）条件

• 過去1年間（新人の場合は入社時から起算）の中で、他者に対してEGNフィードバックを月平均1回以上行っていること
• 例えば直近1ヶ月で12回フィードバックしていれば条件達成
• フィードバックをもらいたい人に対して、給与プロリクを出す前にEGNフィードバックを行うことを推奨します

申請方法

• 給与プロリク実施時に、確認可能なEGNフィードバックの件数と、内容を記載すること
• 内容記載方法例
• 、 、slackチャンネル、figjam、録画動画など何かしら記録されている内容へのリンクを記載

その他：制度・キャンペーン

FAQ

その他給与についての制度・情報

参考

給与自己決定制度の改変（プロジェクト貢献指標について）解説動画

給与決定制度の改変について

ゆめみ の中で「broad」チームと呼ばれる幅広く組織に影響する方針策定などを行うチームが毎週行う定例会議を「徹底的な透明性」の方針に基いて外部に公開しています。一般にはboardメンバー（取締役）と呼ばれる役割ですが、ゆめみではbroadと呼んでいます。

www.youtube.com

以下にご提供の会話内容を整理・要約し、資料としてまとめました。必要に応じてNotionやスライド形式に転記できる構成です。

ゆめみにおける働き方・役割・オンボーディングガイド

1. 入社・職位の初期設定と所属

• ゆめみでは職位（アーキテクト、リード等）は自身で変更可能（プロリクで申請）。
• 初期設定は人事がシステム側へ依頼して行う。
• 所属（ギルド）によりアサインされる仕事が異なる。
• サーバーサイドギルド所属：開発タスク中心。
• PDM（プロダクトマネジメント）ギルド所属：アーキテクト業務や育成計画の対象。
• アーキとして活躍を希望する場合、小野寺さん・大代さんへ相談することが推奨される。

2. ゆめみの働き方の前提

• 社内フリーランス制度：
• 管理職不在、委員会が代替機能を担う。
• 業務獲得は自律的に行う（待っていてもアサインされない）。
• プリセールス参加やプロリク提出で能動的に仕事を生み出す必要がある。
• ターゲット稼働制度：
• 所定の稼働率を達成する必要があり、自らの稼働を埋める動きが求められる。
• 評価制度の特性：
• 明確な評価制度が存在しないため、セルフマネジメント能力が求められる。
• 成果責任を伴わない環境のため、失敗を恐れず挑戦しやすい。

3. リード vs プロフェッショナルの違い

4. 仕事の獲得方法と社内の連携

• セールスワークスペース（鍵付き）へ申請し参加
• 案件情報が集まる「セールス」チャンネルにアクセス。
• プリセールス段階で手を挙げて仕事に参加。
• ギルド・役職別に役割を把握し、適切なチャンネルで動く
• 自主的に動ける人材が求められる。
• 案件が見つからない場合は、営業と連携して案件を作る。

5. プロジェクトの進め方と役割

• 情報アクセス・権限：
• JIRAやConfluenceは全体が見える仕様。
• 実際に必要な資料はGoogle Driveなどで管理されている可能性が高い。
• 見たい情報は「権限ください」と伝えて確認を取る。
• タスク管理：
• SRE支援プロジェクトなど必要に応じて新規プロジェクトを立て、エピック／ストーリーチケットで課題整理。
• 優先度付け・課題レベル（必須、推奨）などを明確化。
• 進捗報告：
• PMによって報告スタイルが異なるが、進捗資料（Notion等）を毎週作成・共有する例も。
• 報告内容例：進捗、依頼事項、スケジュール感、稼働報告、課題・リスク等。

6. 実務上のポイント

• 課題の抽出：
• 技術的調査（バージョン、セキュリティ、レスポンス改善）を実施し、必要タスクを整理。
• 論理設計図や技術的負債の把握・改善提案。
• CCの活用：
• 予算超過やスコープ拡大を避けるため、やり取りはリーダーにCCを付けて実施。
• チケット化→お客様の承認を経て作業着手が基本。

7. 問題になりがちなケース

• 案件を自ら探さない人が放置される → 稼働超過問題、PMの評価低下。
• セルフマネジメント力が不十分なままリード申請 → 成果不十分 → メンタル不調や休職に。
• お客様とのコミュニケーションに不慣れ → 情報過多で不安を与えるケース（例：新卒の自己紹介）。

8. 推奨されるアクション

• 小野寺さん・大代さんへの早期相談。
• セールスWS参加、案件への自発的手上げ。
• 情報の整理とタスクの見える化。
• Notionなどでの進捗報告資料作成（PMの支援資料例を参考）。
• 定例会での課題共有・進捗報告による信頼構築。

このドキュメントは、ゆめみでのリード/アーキテクト職としての立ち振る舞いと期待される自律性、情報管理、案件推進の実務観点を網羅しています。必要に応じて、各章を資料化・編集いたしますので、お申し付けください。

以下にご提供の会話内容を整理・要約し、資料としてまとめました。必要に応じてNotionやスライド形式に転記できる構成です。

ゆめみにおける働き方・役割・オンボーディングガイド

1. 入社・職位の初期設定と所属

• ゆめみでは職位（アーキテクト、リード等）は自身で変更可能（プロリクで申請）。
• 初期設定は人事がシステム側へ依頼して行う。
• 所属（ギルド）によりアサインされる仕事が異なる。
• サーバーサイドギルド所属：開発タスク中心。
• PDM（プロダクトマネジメント）ギルド所属：アーキテクト業務や育成計画の対象。
• アーキとして活躍を希望する場合、小野寺さん・大代さんへ相談することが推奨される。

2. ゆめみの働き方の前提

• 社内フリーランス制度：
• 管理職不在、委員会が代替機能を担う。
• 業務獲得は自律的に行う（待っていてもアサインされない）。
• プリセールス参加やプロリク提出で能動的に仕事を生み出す必要がある。
• ターゲット稼働制度：
• 所定の稼働率を達成する必要があり、自らの稼働を埋める動きが求められる。
• 評価制度の特性：
• 明確な評価制度が存在しないため、セルフマネジメント能力が求められる。
• 成果責任を伴わない環境のため、失敗を恐れず挑戦しやすい。

3. リード vs プロフェッショナルの違い

4. 仕事の獲得方法と社内の連携

• セールスワークスペース（鍵付き）へ申請し参加
• 案件情報が集まる「セールス」チャンネルにアクセス。
• プリセールス段階で手を挙げて仕事に参加。
• ギルド・役職別に役割を把握し、適切なチャンネルで動く
• 自主的に動ける人材が求められる。
• 案件が見つからない場合は、営業と連携して案件を作る。

5. プロジェクトの進め方と役割

• 情報アクセス・権限：
• JIRAやConfluenceは全体が見える仕様。
• 実際に必要な資料はGoogle Driveなどで管理されている可能性が高い。
• 見たい情報は「権限ください」と伝えて確認を取る。
• タスク管理：
• SRE支援プロジェクトなど必要に応じて新規プロジェクトを立て、エピック／ストーリーチケットで課題整理。
• 優先度付け・課題レベル（必須、推奨）などを明確化。
• 進捗報告：
• PMによって報告スタイルが異なるが、進捗資料（Notion等）を毎週作成・共有する例も。
• 報告内容例：進捗、依頼事項、スケジュール感、稼働報告、課題・リスク等。

6. 実務上のポイント

• 課題の抽出：
• 技術的調査（バージョン、セキュリティ、レスポンス改善）を実施し、必要タスクを整理。
• 論理設計図や技術的負債の把握・改善提案。
• CCの活用：
• 予算超過やスコープ拡大を避けるため、やり取りはリーダーにCCを付けて実施。
• チケット化→お客様の承認を経て作業着手が基本。

7. 問題になりがちなケース

• 案件を自ら探さない人が放置される → 稼働超過問題、PMの評価低下。
• セルフマネジメント力が不十分なままリード申請 → 成果不十分 → メンタル不調や休職に。
• お客様とのコミュニケーションに不慣れ → 情報過多で不安を与えるケース（例：新卒の自己紹介）。

8. 推奨されるアクション

• 小野寺さん・大代さんへの早期相談。
• セールスWS参加、案件への自発的手上げ。
• 情報の整理とタスクの見える化。
• Notionなどでの進捗報告資料作成（PMの支援資料例を参考）。
• 定例会での課題共有・進捗報告による信頼構築。

このドキュメントは、ゆめみでのリード/アーキテクト職としての立ち振る舞いと期待される自律性、情報管理、案件推進の実務観点を網羅しています。必要に応じて、各章を資料化・編集いたしますので、お申し付けください。