「点数も順位もつけない」を実装でどう守るか。Grift CLIが次の版で決めた5つの条件

「点数や順位はつけません」。Griftはgriftai.orgでもcor-jp.comでも、そう約束しています。

ただ、約束を文章に書くことと、ソフトウェアがその約束を守ることは別です。この記事では、2026年10月25日にGrift CLIの中で見つけた食い違いと、次の版（0.8）に課すことにした5つの条件を書きます。発注側の方、紹介会社・SESの営業の方、推薦される側のエンジニアの方に向けて、できるだけ平易に書きました。

現場で起きたこと

Grift CLIには、1つのリポジトリに関わった人を一覧にする出力があります（actor-index）。公開中のv0.7.2では、この一覧に「コミット数で抽出しただけで、品質の順位ではありません」という注記が付いています。

ところが、表の行はコミット数の多い順に並んでいました。

注記は「順位ではない」と言い、表の並びはコミット数で決まっている。読む人の目に先に入るのは、注記ではなく表です。一番上の行の人を「一番よくやった人」と読んでしまうのは、読み手の責任ではなく、並べ方の責任だと考えました。

同じ日の突合では、もう1つ欠けが見つかりました。grift alignは、案件側が宣言した要求と候補者の観測を並べる向きしか持たず、エンジニア側が案件に求めることを宣言する入口がありませんでした。「推薦する人にも、推薦される人にも」と書いてきた約束の半分が、実装にはなかったことになります。

どちらも、Cor.が自分のサイトの文言とCLIの出力を1行ずつ突き合わせて見つけたものです。利用者から指摘されたものではありません。見つけた日のうちに、設計判断の記録（ADR）として書き残しました。

なぜ並び順だけを先に直すのか

コミット数を出すこと自体をやめればよい、という考え方もあります。Griftはそうしませんでした。

コミット数は分母付きの事実です。griftai.orgのデモにある「274件のうち73件」も、母数がなければ読めません。消してしまうと、利用規範の第1条「不在を負に読まない」とも衝突します。消すのは値ではなく、並び順です。

並び順は事実ではなく、見せ方の選択です。誰が多いかを先頭に置くことは、受け取る側に順位として読ませる見せ方です。次の版では、一覧の既定の並びをIDの辞書順にします。コミット数の値は残ります。コミットを増やしても、表の上には来なくなります。

次の版（0.8）に課す5つの条件

0.8系のすべての変更に、次の5つの受入条件を課すことにしました。

1. 観測した量で人を並べない

人を列挙する出力の既定の並びはIDの辞書順にし、コミット数・行数・日数などの観測量に依存させません。値そのものは分母付きの事実として残します。

2. 量で選ぶときは、量であることを名前と注記で明示する

--top Nという選択肢は、観測したコミット数の多いN名を取り出します。これは量による選別です。次の版でも残しますが、ヘルプと出力の注記に「選別の基準はコミット数であり、品質や順位ではない」と書き続けます。名前を変えるか廃止するかは、既存の使い方を壊す変更になるため、その先の版で判断します。新しい選別の仕組みを観測量で作ることはしません。

3. 参照分布上の位置は、頼まれたときだけ出す

Griftには、公開リポジトリの参照分布の中で、そのリポジトリの値がどの帯にあるかを出す機能があります。人ではなくリポジトリの位置ですが、自分で実行した本人には「自分のリポジトリは上位N%」と読めます。率を上げれば帯も上がります。次の版以降では、参照分布の版を明示して頼んだときだけ出し、既定では「参照分布は要求されていない」という理由付きの未観測にします。

4. 数値の「膨らませ方」を開示し、補正はしない

テスト併修率は、テストファイルへの形式的な1行の変更でも上がります。変更した行数は見ていません。直近180日の変更日数は、毎日1件の小さなコミットで埋まります。

こうした経路は数値のそばに固定の文で併記します。重み付けや補正はしません。利用規範の第7条が文脈や難易度による数値の補正を禁じているためです。開示は、読み手が数値の限界を知るためのものです。数値の水増しを見つける機能ではありません。

5. 宣言と観測を混ぜない。両方向で

案件側の要求は「宣言」、候補者のgit履歴は「観測」です。grift alignはこの2つを軸ごとに並べ、重なり・範囲外・0件・未観測・要求なしの5通りで出します。総合点も順位も合否も作りません。

エンジニア側が案件に求めることを宣言する入口を作る場合も、同じ5通りの語と、同じ禁止事項を使います。どちらの向きでも、宣言と観測は別の欄に置きます。

読む立場ごとに

発注側の方へ。一覧の上にいる人が良い人、という読み方は、次の版からはできなくなります。並びはID順です。数値は面談で聞くことを具体にする材料として使ってください。

紹介会社・SESの営業の方へ。候補者本人が共有した記録を順位表に組み替えて使うのは、利用規範に反する使い方です。推薦の理由は値と分母と、観測できなかった理由を添えて伝えてください。

エンジニアの方へ。コミットを増やしても、一覧の上には来ません。出すリポジトリを選んだこと自体は、受け取る側に分かる形で残ります。選ぶことは禁じていません。隠さないことを求めています。

まとめ

約束は文章に書くだけでは守れません。文章と実装が食い違っていたら、実装を直し、直した経緯を公開します。

0.8はまだリリースしていません。並び順を変えると、以前の版で保存した一覧の検算結果が一致しなくなるため、定義の版数を上げる作業と一緒に出します。

参考資料

• Grift - 製品サイト。3つの約束と観測する項目
• grift-cli（GitHub、MIT） - CLIのソースコード
• TEP利用規範（norms） - 第1条「不在を負に読まない」、第7条「重み付け・換算の禁止」、--top Nとgrift alignの扱い
• griftレポートの読み方（metrics-guide） - 指標ごとの平易な解説と十分位の表記規約
• Griftの事例ページ - cor-jp.comの実績紹介