| 1 |
Fail Forwardの「失敗の定義」 |
大型クライアント（ドコモ等）が存在する中で「失敗してOK」を字義通りに適用すると対外リスクがある。Value合宿で確定するが事前に枠組みが必要 |
(A) 「小さく早く失敗」に限定（大型案件は対象外）/ (B) 失敗のスコープを職種・等級別に定義する / (C) 抜擢・新規事業に限って"失敗OK"と明示し、受託業務は対象外とする |
ぽち相談 → 合宿で確定 |
要相談 |
🔴 |
| 2 |
ミッションの大きさの見積もり方 |
等級制度では「規模×難易度×インパクト×不確実性」と定義しているが、実際の評価場面でどの組み合わせを使い、どう数値化するかが未設計。評価のブレの源 |
(A) 4要素を加重平均でスコア化 / (B) 案件ランク★（v2.4で設計）にミッション難易度を紐付けてスコア代替 / (C) 定性記述に留め、1on1で上長が判断 |
ぽち相談（カズキ同席） |
要相談 |
⚠ |
| 3 |
発明の定義（職能別レベル差） |
「発明」は10%（加点）として評価配分に含まれるが「何をもって発明とするか」が職能別に異なる。ぽち/はづきの発明 ≠ インターンの発明（カズキFB）。「いいんじゃにとって発明であれば発明」という相対評価の運用基準が未設計 |
(A) 等級別の発明基準表を作る（等級×職種マトリクス） / (B) 「新しい仕組みを属人化しない形で残したか」の1基準に絞る / (C) 合宿後にValueが確定してから定義する |
ぽち・カズキ相談（金曜MTG） |
設計中 |
⚠ |
| 4 |
給与レンジの粒度・グレード定義 |
現在は「等級×1つの数字（叩き台）」で提示しているが、同一等級内のレンジ（上限・下限）設計が未完。また「B等級とは何者か」を1文で語れる等級の顔も未定義（ぽちFB）。市場ベンチマーク参照・メンバー面談（7月）を踏まえて確定予定 |
(A) 等級×固定額で運用（シンプル） / (B) 等級×レンジ（上限・下限）で運用（柔軟）/ (C) 職種別に別表を設ける（開発・マーケで別建て） |
ぽち主担当（7月メンバー面談後に確定） |
論点・設計中 |
⚠ |
| 5 |
組織貢献の定義（横断の判定基準） |
評価4軸の③組織貢献（15%）は「組織横断が良い」とされているが「何をもって組織貢献とするか」の判定基準が曖昧。採用関与・後輩育成・社内発信の5カテゴリはあるが、組織横断活動のカウント基準が未定（ぽちFB） |
(A) 5カテゴリを点数化（カテゴリ別に1〜3点） / (B) 「組織横断か否か」の判定は上長1人が定性判断 / (C) 組織貢献をさらに細分化して判定基準を作る |
中島設計→経営会議で確認 |
論点 |
⚠ |
| 6 |
AI-native観測方法（朝会以外） |
現状は朝会の「今週のAI活用」共有が一次観測点だが、「見えるAI活用」に偏るリスクがある（v2.4で論点化）。Slack発信ログ・ノウハウ文書蓄積数・ツール導入件数などの定量指標との組み合わせを運用開始（10月）までに設計する必要がある |
(A) 朝会共有のみ維持（運用負荷を下げる） / (B) Slackチャンネル（#ai-native）への投稿数をカウント / (C) 四半期ごとに「AI活用ログ」を自己申告で提出する |
中島設計→ぽち確認 |
論点・設計中 |
⚠ |
| 7 |
案件ランク★表現の最終形・社内浸透 |
v2.4でモンハン方式★1〜★5を導入したが、従来のA/B/C表記との使い分けルール・社内への説明方法が未設計（ぽちFBで設計中として残留） |
(A) ★を主表記にしA/B/Cは括弧で併記 / (B) 社内では★のみ・対外資料はA/B/C / (C) 移行期間を設けて徐々に★に一本化する |
ぽち確認 |
設計中 |
⚠ |
| 8 |
合宿キーマン選定 |
合宿（Value確定・ワークショップ）で全社共通言語を作るには参加者選定が重要。ぽち/カズキ/天野への確認が必要（ぽちFBの宿題） |
(A) 経営陣のみ（3〜5名）で濃く議論 / (B) 経営+各部門キーマン（8〜12名）で幅を持たせる / (C) 全社員参加型（清水さん提案の半日WS形式） |
ぽち/カズキ/天野への確認（宿題） |
要相談 |
⚠ |
| 9 |
5つのValueの確定 |
現在のValue（v0.1）はドラフト段階で合宿で確定する前提。「Fail Forward（大胆に張る）」の失敗の定義（論点1）・サイバーエージェント事例が当てはまるかの検証も含む。Value確定前は Value MVP 表彰も保留中 |
合宿WS（付箋・写真・全社共通言語化プロセス）で確定 |
合宿（経営＋キーマン） |
合宿 |
🔴 |
| 10 |
カルチャーデック＋Value統合 |
カルチャーデック v2 で実施済み。Value v0.1との対応関係を全社に説明できる形に整備 |
— |
実施済 |
— |
✅ |
| 11 |
称賛制度レイヤー再編 |
称賛制度 v0.2 で実施済み。日常称賛の制度化廃止・神ムーブ月次/半期/通期の3層に。ユニット/個人表彰の2系統化 |
— |
実施済 |
— |
✅ |
| 12 |
レビューモデル（上長1人+中島/経営会議） |
等級制度 v2.4 §6 で実施済み。"3名レビュー"表現を全廃 |
— |
実施済 |
— |
✅ |
| 13 |
トラックと職種の図解 |
等級制度 v2.4 §0 で実施済み。冒頭に独立セクション設置・3トラックの価値の出し方を図解 |
— |
実施済 |
— |
✅ |
| 14 |
スキルマップのレーダー図化 |
スキルマップサンプル v0.2 で実施済み。ポケモン図鑑メタファ（タイプ別・レベル1-5）を反映 |
— |
実施済 |
— |
✅ |
| 15 |
初期ゴール「一人前」の定性・定量定義 |
6/17定例で方向確定＝一人前はレベル4（自己主導）＝自律性が土台（スキルより上位）。3条件＝判断軸を発言/have-want折り合い/長期目標を自分で。定量（案件難度×本数×メンター）は部長2名へ宿題。給与≒月40万＝一人前基準→一人前ラインがB かB+ か要確定 |
スタンス＝Lv4自律性＋定量。一人前ライン等級(B/B+)をぽちと確定 |
ぽち相談 |
前進(定例) |
🔴 |
| 16 |
報酬の掛け算係数レンジ |
報酬＝ベース給（グレード）×ミッション係数。係数の具体レンジ・「ベース給×係数」が等級上限を超えた場合の扱いが未定 |
(A) 標準1.0/大1.2/特大1.4の3段階 / (B) ★ランクに連動 / (C) 賞与で変動を吸収しベースは固定 |
ぽち主担当 |
論点 |
⚠ |
| 17 |
評価比率の確定 |
発明を枠外加点に出し、ベースを3軸（ミッション45/等級40/組織貢献15）に再配分 |
(A) 45/40/15 ★中島確定(2026-06-17) / (B) 50/35/15 / (C) 40/40/20 |
中島確定→経営追認 |
✅中島確定 |
— |
| 18 |
Worker/Specialistの境目の運用 |
境目を線で区切らず「自立・自走したら深さで上を目指す人をSpecialist」と連続的に扱う方針。誰がいつ分岐を決めるかの運用が未設計 |
(A) B→B+昇格時に本人＋上長で決める / (B) 半期1on1で意向確認 / (C) 抜擢レーンと同じく経営合議 |
中島設計→経営確認 |
設計中 |
⚠ |
| 19 |
案件難易度ランクのすり合わせ |
6/17定例で案件難易度＝規模(予算)×領域横断×職種、ランク＝SA/A/A-/B/B-/C(6段階)。現行はモンハン★1〜5(5段階)。マッピング未確定 |
(A) SA=★5/A=★4/A-=★3.5…でマッピング / (B) ★を廃しSA〜Cに一本化 / (C) 社内会話は★・正式はSA〜Cの二本立て |
中島→部長2名宿題 |
論点 |
⚠ |
| 20 |
戦闘能力評価モデル |
採用定例6/25：スキルを「マス埋め」で合算（戦略/設計/横断）→一定点で昇格（パワプロ式）。評価軸②等級期待行動・スキルマップの具体化 |
(A) スキルLv合算で閾値昇格 / (B) 突出1点ルートも併設 / (C) 職種別に必須スキルセットを定義 |
土曜ぽち→経営確認 |
論点 |
⚠ |
| 21 |
突出型 vs バランス型の評価 |
採用定例6/25：戦闘力800点の一点突破型と500点のバランス型をどう公平に評価するか＝最難関。例外的突出人材の扱い |
(A) 合計点ルート＋突出1点ルートの2本立て / (B) 突出はその領域Sランク等を条件 / (C) パラメーター(レーダー)で個別判断 |
土曜ぽち→経営確認 |
🔴論点 |
🔴 |
| 22 |
横断スキル評価・Specialist昇格要件 |
採用定例6/25：横断スキルが高い人はディレクション不要モデル(ぽち)。ワーカースペシャリストの横断評価基準が未確定。スペシャリスト昇格に横断要件を追加する案 |
(A) 横断を昇格加点に / (B) Specialistの自走範囲条件に横断を組込 / (C) 横断は別軸で評価 |
中島→ぽち/天野 |
設計中 |
⚠ |
| 23 |
給与の情報開示基準 |
採用定例6/25：年収をメンバー全体に知らせるのは避ける／マネジメント層・評価権者はOK。業務委託金額も権限範囲で開示基準を決める |
(A) 評価権者のみ開示 / (B) グレード×レンジは全体公開・個人額は非公開 / (C) 完全非公開 |
ぽち主担当 |
論点 |
⚠ |