経歴は盛れる。 証拠は盛れない。

誰の変更か

誰の変更かの区別（帰属の区別）

コミット（変更を記録した1件）ごとに、本人の変更、ほかの人の変更、自動で動くプログラム（bot）の変更、自動で作られたファイルや外から取り込んだコード、コピー元のリポジトリ（fork元）から引き継いだ記録などを、11の分類で分けて数えます。

コードの良し悪しは分かりません。

どの部分を変えたか

変えた部分の区分（作業領域）

変えたファイルの場所と種類から、画面、サーバー側、データ、基盤、テスト、文書、自動化の設定（CI/CD）、監視、設定ファイル、生成物・外部のコード、そのほかの11の区分に分けて、区分ごとに変えたコミットの件数を数えます。

ファイルの名前から機械的に分けるので、職種や得意分野を決めるものではありません。

どんなペースで変えたか

変更のペース（変更リズム）

直近180日のうち、変更を記録した日が何日あったかを数えます。変更と変更のあいだが何日空いたかも、真ん中の値と長いほうから1割にあたる値で示し、2日以内の間隔と30日以上の間隔の割合も出します。

労働時間や勤怠、意欲、納期を守ったかは分かりません。毎日小さな変更を記録すれば日数は増え、まとめて記録すれば減ります。

テストと一緒に変えたか

テストも一緒に変えた割合（テスト併修率）

本番のコード（テストと文書以外）を変えたコミットのうち、同じコミットでテストも変えたものの割合です。

テストが通ったか、テストやコードの質は分かりません。文書や設計が中心の仕事のように、テストが前提でない仕事では低く出るのが自然です。

テストの付け方（検証の形）

テストを触ったコミットの割合、テストの種類（単体・結合・E2E・契約）、不具合の修正（fix・revert）のうちテストも一緒に変えたものの割合を出します。

テストの担当（QA）に向いているかは分かりません。

どんなリポジトリでどう関わったか

リポジトリの様子（リポジトリの文脈）

関わった人の数、いちばん多く変更した人が占める割合（名前は出しません）、取り込み（マージ）の記録の割合、使っている言語、活動の密度など、数値が出たリポジトリの様子を並べます。

個人の能力や、チームの優劣は分かりません。分類であって、序列ではありません。

関わり方

本人の同意が記録されているときだけ、新しいファイルを作ったコミット、既にあるファイルを直したコミット、取り込み（マージ）のコミット、本人が付けたリリースの印の数などを出します。

職種を決めるものではありません。CLIが確かめるのは同意が記録されていることで、同意そのものではありません。

すぐに直したか

傾向の記録で、合否には使いません。

修正でのやり直し（手戻り率）

21日以内に触ったファイルを、修正（fix）や取り消し（revert）などの件名で、もう一度変えたコミットの割合です。

バグの件数や品質ではありません。件名の付け方で出方が変わるので、人と比べたり合否に使ったりしません。

同じファイルへの戻り（磨き直し）

本番のコードの同じファイルに、21日以内にもう一度手を入れたコミットの割合です。

手戻りや不具合の件数ではありません。

いまのコードはどれくらい新しいか

計測を指定したときだけ出します。

コードの新しさ

いまのコードに残っている行が、書かれてからどれくらい経っているかを、180日を目安に重みを付けて平均した値です。1に近いほど、最近書かれた行が多いことを表します。

180日後に残った行の割合や、コードの品質ではありません。リポジトリ全体の値で、一人ひとりの値ではありません。

案件が求めることと、どこで重なるか

案件側が書き出す要求（案件側の宣言）

案件で求める作業の区分、テストの種類、変更のペースなどを、案件側が項目ごとに書き出します。書かなかった項目は「要求なし」として扱い、0や不足にはなりません。

項目ごとの並び（軸ごとの並び）

案件側の要求と候補者の記録を項目ごとに並べ、重なり・範囲外・0件・未観測・要求なしの5通りで示します。総合点・順位・合否・推薦は計算しません。本人が名乗ったIDに同意の記録があるときだけ、面談で確かめたいことを問いの形で添えます。

チームで見るとき（チーム単位の充足）

要求を満たす人数だけを出し、一人ひとりの数値は出しません。3人未満のチームでは集計しません。2人だと、誰が満たしていないかが分かってしまうためです。