| 項目 | 内容 |
|---|---|
| ドキュメント版数 | v0.2 |
| 作成日 | 2026-08-09 |
| 更新日 | 2026-08-11 |
| 主な変更 | 実測に基づく追記。 §3.5 に実測スコアと未決 Q-4 への回答、§4.6 に「Gate A では 5 軸が機能しない」という既知の限界を追加 |
| 関連 | 要件定義書 / ソクラテス式エンジン仕様 |
本書は SocraMetry のもう一つの中核を定義する。 問答エンジンが「どう学ばせるか」なら、本書は**「学びをどう測り、どう評価に使うか」**である。
技術力の評価は、これまで次の 3 つで行われてきた。
| 方法 | 限界 |
|---|---|
| アウトプット（コード量・PR 数） | AI が下駄を履かせるため、本人の地力を反映しなくなった |
| 上長の主観 | 説明可能性が低く、接点の多寡に左右される |
| 資格・試験 | 実務と乖離する。年 1 回では成長を追えない |
SocraMetry が測るのは 「詰まったときに、どう考えるか」 である。 これは AI が肩代わりできない部分であり、実務そのものの中で観測できる。
デバッグのプロセスを 5 段階に分解し、それぞれを独立した能力として測る。
| 軸 | 測っているもの | 現場での意味 |
|---|---|---|
| 観察 Observe | エラーを正確に読めるか | 思い込みで読み飛ばさない |
| 切り分け Localize | 問題箇所を絞り込めるか | 実務で最も差がつく。変更点を辿れるか |
| 仮説 Hypothesize | 観察から原因を推論できるか | デバッグの中核 |
| 検証 Verify | 仮説を確かめる手段を選べるか | 思い込みを潰せるか |
| 修正 Fix | 再発しない直し方を選べるか | 対症療法で終わらせない |
5 軸に分けるのは、「技術力が高い / 低い」ではなく「どこが強くて、どこを伸ばすべきか」を 言える形にするためである。単一の総合点は評価者に楽をさせるが、被評価者には何も返さない。
3 ゲート方式における到達ゲートは、 1 セッションあたりの情報量が最も多い指標である。 ただし評価値の主軸には置かない。 主軸は v0.1 では 5 軸スコア、v0.2 以降は成長率（§4.2）とし、 到達ゲートは NFR-F5 が求める「内訳と根拠」の一項目として併記する。
主軸に置くと Gate C が構造的に最低評価になり、NFR-F4「開示の利用を減点の主因にしない」と 両立しなくなる。 §3.2 の算出式でも、到達ゲートは補正係数
gate_factorとして扱う。
| 到達 | 意味 | 評価上の扱い |
|---|---|---|
| Gate A ヒントのみで解決 | 着眼点さえ示されれば自走できる | 最上位。★★★ |
| Gate B 設問の誘導で解決 | 順を追えば辿り着ける | 中位。★★ |
| Gate C 開示を受けて理解 | 自力到達には至らなかったが、学習は成立した | 下位。★ ただし減点の主因にしない（§4） |
| 未完了 | 途中離脱、またはツール外で解決して戻らなかった | 評価対象外（データとして扱わない） |
「未完了」は離脱とは限らない。 ヒントだけで解決してツールに戻らなかった人 （UC-02 = 最良の結末）も同じ扱いになる。両者を v0.1 では区別できない。 そのため自力解決率の分母は「完了セッション」に限り、未完了率は混ぜずに並記する （requirements.md §7.1）。
| 指標 | 定義 | 使い方 |
|---|---|---|
| 正答率 | Gate B の設問における正解数 / 出題数 | 5 軸スコアの素データ |
| 正解までの所要時間 | ゲート到達までの実時間 | 難易度で正規化してから使う（§4.3） |
| ヒント使用量 | 開放したヒントレベルの合計 | 自立性の指標 |
| 取り組み量 | セッション数・総所要時間 | 継続性の指標。能力ではなく姿勢を表す |
| 成長率 | 直近 N 件と過去 N 件の 5 軸平均の差 | 評価の主役（§4.2） |
stage_score = base × hint_penalty × difficulty_factor
base: 1 問目で正解 = 100 / 2 問目 = 70 / 3 問目 = 40 / 未正解 = 0
hint_penalty: ヒント Lv0 = 1.00 / Lv1 = 0.85 / Lv2 = 0.70 / Lv3 = 0.55
difficulty_factor: easy = 0.9 / medium = 1.0 / hard = 1.15
session_score = Σ(stage_score × weight) × gate_factor
weight: 観察 0.15 / 切り分け 0.25 / 仮説 0.25 / 検証 0.20 / 修正 0.15
gate_factor: Gate A = 1.00 / Gate B = 0.90 / Gate C = 0.75
gate_factorの差をあえて小さくしている（1.00 → 0.75）。 ここを 1.0 → 0.3 のように大きくすると、詰まった人が開示を避けて業務を止める。 詳細は §4.1。ただし 0.75 が「小さい差」と言えるかは、5 軸スコアが実際にどのレンジに出るかに依存する。 スコアが 60〜80 に固まるなら、0.75 は実質 −15〜20 pt に相当し、 利用者から見たときに NFR-F4（開示の利用を減点の主因にしない）が成立しない可能性がある。 Day 4 の実測でスコアを並べて判断する（未決 Q-4）。 設定値なので、直すのは 1 行で済む。
所要時間はスコアに直接掛けない。別指標として並記する。
time_index = median(同一問題の全解答者の所要時間) / 本人の所要時間
同一問題（演習モード）でのみ算出でき、1.0 が中央値。 実務モードでは問題がバラバラなので算出しない。
時間をスコアに掛けない理由: 熟考を罰することになるため。 デバッグは「速く間違える」より「遅くても正しく辿る」方が価値が高い。 速さは独立した情報として見せ、評価者が文脈込みで解釈する。
スコア算出に LLM を介在させない。すべて packages/core/src/scoring.ts の純関数で行う。
- 同じセッションデータからは常に同じスコアが出る
- 算出過程を利用者に開示できる
- テストできる
評価に使う数値が、実行のたびに変わってはならない。
係数の妥当性は、値そのものではなく「実際にどのレンジに出るか」でしか判断できない。 実 LLM で通した結果を記録する。
| 実際に起きたこと | 到達 | 5 軸 | 総合 |
|---|---|---|---|
| ヒント Lv3 まで開けて自力で原因に到達 | Gate A | 70 / 70 / 70 / 70 / 70 | 70 |
| ヒント未使用・設問 5 問すべて 1 問目で正解したが原因は外し、解説を読んだ | Gate C | 100 / 100 / 100 / 100 / 100 | 75 |
Gate C の方が高く出た。 「到達ゲートを主軸に置くと Gate C が構造的に最低評価になる」 という懸念（§2.2）は、実測では発生しなかった。理由は係数の幅の差である。
| 係数 | 幅 | 実測での効き方 |
|---|---|---|
gate_factor（到達ゲート） |
1.00 → 0.75（−25%） | 支配的ではない |
hint_penalty（ヒント使用量） |
1.00 → 0.55（−45%） | こちらが支配的 |
未決 Q-4 への回答:
gate_factor0.75 は NFR-F4（開示の利用を減点の主因にしない） として成立している。減点の主因になっていたのは到達ゲートではなくヒント使用量だった。ただしその裏返しとして、ヒントを開けることの重みが大きい。 「ヒントを使うと損」という圧が働くなら、それは §4.1 の歪み #1 と同じ構造である。 ヒント使用量の係数は、Gate A の到達者が増えた段階で再評価する。
この実測の限界を明記する。
| 項目 | 状況 |
|---|---|
| サンプル数 | 3 セッション。傾向は読めるが確定的な根拠ではない |
| エラーの種類 | 同一系統（認証エラー / 型エラー）に偏っている |
| 未計測の帯 | Gate B で詰まった場合（base が 70 / 40 / 0 に落ちる領域）。実利用でいちばん多くなるはずの帯 |
指標は、評価に使われた瞬間に歪む（Goodhart の法則）。 「測定が目的化したときに何が起きるか」を先に想定し、 設計側で潰しておかなければならない。
| # | 起きうる行動 | 起きる理由 | 設計側の対策 |
|---|---|---|---|
| 1 | 詰まっても開示（Gate C）を使わず放置する | 開示すると評価が下がると思うから | gate_factor の差を小さく（1.00〜0.75）。UI で「開示は正しい着地点の一つ」と明示。業務停止時間の方が組織の損失は大きい |
| 2 | 簡単なエラーばかり投げる | 難しい問題は正答率を下げるから | 難易度による正規化（difficulty_factor）。難しい問題に挑むと係数が上がる |
| 3 | そもそもツールを使わず AI に直接聞く | 記録が残らない方が得だから | 実務モードのスコアを横比較に使わない（§4.4）。取り組み量は「姿勢」として別枠で見る |
| 4 | 正解を共有し合う（演習モード） | 順位が付くから | 問題の割り当てを時間差にする。同一問題の再挑戦はスコア対象外にする |
| 5 | ランキング下位者が萎縮する | 序列が可視化されるから | ランキングは既定で無効。有効化してもチーム内・任意参加・期間限定を既定とする |
| 6 | 管理者が単一の総合点だけで判断する | 楽だから | 総合点だけの出力を許さない（FR-27 / NFR-F5）。必ず 5 軸内訳と成長率を併記する |
最も強く推奨する使い方は、スコアの絶対値ではなく成長率での評価である。
| 見方 | 何が分かるか | 問題点 |
|---|---|---|
| 絶対スコア | 現時点の力量 | 経験年数・担当領域に強く依存する。新人が不利 |
| 成長率 | 期間内にどれだけ伸びたか | 経験年数によらず公平。育成の成果が見える |
growth_rate = avg(直近 5 セッションの 5 軸平均) − avg(過去 5 セッションの 5 軸平均)
評価レポートでは成長率を先頭に置き、絶対値はその補助として表示する。
| 難易度 | 判定方法 | difficulty_factor |
|---|---|---|
| easy | 正答率 80% 以上 | 0.9 |
| medium | 正答率 40〜80% | 1.0 |
| hard | 正答率 40% 未満 | 1.15 |
v0.2 は出題者が手動で設定する。 実績が溜まった段階で、実際の正答率から自動算出に切り替える（未決 Q-10）。
| モード | 横比較 | 理由 |
|---|---|---|
| 演習モード | ✅ 可 | 全員が同じ問題を解く。条件が揃っている |
| 実務モード | ❌ 不可 | 遭遇するエラーの難易度・領域が人によって違う。比較すると「難しい担当をしている人ほど不利」になる |
実務モードのデータは、本人の成長の観察と取り組み量の把握にのみ使う。 この区別を UI とレポートの両方で明示する。
| 要件 | 実装 |
|---|---|
| 利用者は自分のスコアの内訳を見られる | 個人ダッシュボードに算出根拠を表示 |
| 算出式が公開されている | 本書がそのまま仕様であり、利用者にも開示する |
| 誰が自分の評価データを見たか分かる | 監査ログ（NFR-S9） |
| 事実誤認に異議を申し立てられる | セッション単位の「この判定はおかしい」報告導線 |
被評価者が算出根拠を確認できないスコアは、人事評価に使ってはならない。 これは制度上の要請であると同時に、利用者の納得（＝継続利用）の前提でもある。
最上位の到達（Gate A = 自力解決）では、5 軸のスコアが全部同じ値になる。
実測（§3.5）では 70 / 70 / 70 / 70 / 70 だった。Gate A で解決した利用者は
設問を 1 問も解いていないため、軸ごとに差がつく材料が存在しない。
値を分けているのはヒント使用量だけで、それは全軸に一律にかかる。
これは次の 2 つと正面から衝突する。
| 掲げていること | Gate A での実態 |
|---|---|
| 「技術力が高い / 低い」ではなく**「どこが強く、どこを伸ばすべきか」を言える形にする**（§2.1） | 全軸が同値のため、強み弱みを言えない |
| 主軸は 5 軸スコア（§2.2） | 主軸が最も機能しないのが最上位の到達者という関係になる |
これは実装の不具合ではなく、評価モデルの構造上の帰結である。 「設問に答えさせずに自力解決させる」ことを最良の結末として設計した以上、 その利用者からは設問由来の観測値が取れない。 測定のために設問を強制すれば、Gate A の価値そのものが失われる。
v0.1 では既知の限界として受け入れる。 セッション数が少ない段階では そもそも 5 軸の比較に耐えない（§3.5）。扱いの候補は次のとおりで、 実データが溜まってから決める。
| 案 | 内容 | 論点 |
|---|---|---|
| A | Gate A のセッションは5 軸を出さず、到達の事実・所要時間・ヒント使用量だけを見せる | 正直だが、セッションごとの表示が不揃いになる |
| B | 5 軸は出すが**「参考値」と明示**し、成長率の算出からは除く | 表示は揃うが、参考値の扱いを利用者が理解する必要がある |
| C | Gate A 到達後に振り返りの設問を 1〜2 問出し、観測値を得る | 測定はできるが、解決した人を引き止めることになる（P2 と衝突） |
どれを選ぶにせよ、「Gate A の 5 軸は他と同じ意味を持たない」ことは 利用者と管理者の両方に明示する。 説明できない数値を評価に使わせない（NFR-F1）とは、 数値の意味が場合によって変わることを隠さないことでもある。
| ブロック | 内容 |
|---|---|
| 取り組み状況 | メンバー別のセッション数・総所要時間・最終利用日 |
| 自力解決率 | Gate A / B / C の分布。組織全体と個人別 |
| 正答率 | 演習モードの設問正答率 |
| 所要時間 | 演習問題ごとの time_index 分布 |
| 5 軸プロファイル | チーム平均のレーダーと、個人の分布 |
| 弱点の集約 | 組織全体で最も低い軸（例:「検証力が全体的に低い」） |
個人の順位よりも、組織としてどこが弱いかが育成投資の判断に直結する。
例: 「切り分け」が全体的に低い → ログの出し方と再現手順の研修を実施する 例: 「検証」が低い → 「思い込みで直して壊す」インシデントの根本原因かもしれない
ダッシュボードの初期表示は組織の弱点サマリとし、 個人ランキングは 1 階層下に置く。何を最初に見せるかが、ツールの使われ方を決める。
| ロール | 閲覧できる範囲 |
|---|---|
member |
自分のデータのみ。組織平均との比較は可（他人の個票は見えない） |
lead |
自チームのメンバー個票 + 組織平均 |
admin |
組織全体。評価レポートの出力が可能 |
順位付けは強力だが劇薬である。既定を安全側に倒す。
| 設定項目 | 既定値 | 理由 |
|---|---|---|
| ランキング機能 | 無効 | 導入企業が文化に合わせて明示的に有効化する |
| 表示範囲 | チーム内 | 全社ランキングは萎縮を生みやすい |
| 参加 | 任意（オプトイン） | 参加しない選択肢を残す |
| 期間 | 期間限定（例: 月次） | 常時の序列固定を避ける |
| 対象 | 演習モードのみ | 実務モードは条件が揃わない（§4.4） |
| 表示形式 | 上位のみ表示。下位は非表示 | 下位者の可視化を避ける |
ランキングが有効に働くのは、新人研修などの期間限定・同質な集団である。 恒常的な全社ランキングは、§4.1 の歪み 1・3・5 をすべて誘発する。 導入時に運用方針を合意する（未決 Q-11）。
┌────────────────────────────────────────────────────────┐
│ SocraMetry 技術力レポート │
│ 対象: 佐藤 / 期間: 2026-04-01 〜 2026-09-30 │
├────────────────────────────────────────────────────────┤
│ ■ 成長サマリ（主指標） │
│ 5 軸平均 62 → 74 (+12 pt) │
│ 最も伸びた軸: 切り分け +21 pt │
│ 伸び悩んでいる軸: 検証 +2 pt │
│ │
│ ■ 現時点のプロファイル（レーダー） │
│ 観察 88 / 切り分け 71 / 仮説 76 / 検証 58 / 修正 72 │
│ ※ 組織平均: 82 / 65 / 70 / 61 / 69 │
│ │
│ ■ 自力解決率 │
│ Gate A 24% Gate B 51% Gate C 25% │
│ ※ 前期: A 12% / B 44% / C 44% │
│ │
│ ■ 取り組み量 │
│ セッション 38 件 / 総所要時間 9.2h / 演習完了率 92% │
│ │
│ ■ 育成の示唆 │
│ 検証力が相対的に低い。仮説を立てた後、確かめずに │
│ 修正に進む傾向がある。ログ出力・二分探索の実践を推奨。 │
│ │
│ ■ 算出根拠 │
│ スコア算出式: docs/evaluation-model.md §3 │
│ 対象セッション一覧: (38 件のリンク) │
└────────────────────────────────────────────────────────┘
| # | 原則 |
|---|---|
| 1 | 成長を先頭に置く（絶対値ではなく） |
| 2 | 総合点を単独で出さない。 必ず 5 軸内訳を併記する |
| 3 | 組織平均との比較を併記し、絶対値の解釈を助ける |
| 4 | 育成の示唆を必ず書く。 評価して終わりにせず、次の行動に繋げる |
| 5 | 算出根拠へのリンクを載せる。 被評価者が検証できる状態にする |
本製品の責務はレポートの出力まで。 評価制度への組み込み方は各社の制度設計に依存するため、 自動連携は行わず、人が解釈して制度に載せる前提とする。
技術要件ではなく運用の合意だが、これを外すと製品が誤用される。 導入企業と初期に握るべき項目を列挙する。
| # | 合意事項 | 推奨する立場 |
|---|---|---|
| 1 | スコアを評価の唯一の根拠にしないこと | 他の評価材料と併用する前提 |
| 2 | 成長率を主指標とすること | 絶対値は経験年数に依存する |
| 3 | Gate C（開示）の利用を咎めないこと | 咎めると業務が止まり、ツールも使われなくなる |
| 4 | 実務モードのスコアで順位付けしないこと | 条件が揃わない |
| 5 | ランキングを有効化するか、する場合の範囲 | 既定は無効。新人研修など期間限定での利用を推奨 |
| 6 | 利用者本人に自分のデータが常に見えていること | 納得と継続利用の前提 |
導入前チェックリストとして、この 6 項目を提示する。 「メンバーを監視・選別する道具」として導入されると、 P-2（利用者）が使わなくなり、結果として P-1（管理者）が欲しいデータも溜まらない。 公平性の設計は、倫理の問題であると同時に、製品が機能するための条件でもある。