評価基準をCSVでGit管理するのは、まだ半分しか正しくない

DMM.comが公開しているリポジトリの一つに、可観測性の成熟度を測るモデルがある(出典)。CMMI（能力成熟度モデル統合）の考え方を可観測性の領域に応用し、組織の実践を5段階、6つの評価軸で採点できるようにしたものだ。

READMEには次のように書かれている。

組織のオブザーバビリティ実践を体系的に評価し、継続的な改善を推進するためのフレームワーク

(出典)

リポジトリの作りに、まず目が行った。

評価基準そのものは csv/observability-maturity-model.csv に置かれ、閲覧用のPDFはそこから生成される派生物という位置づけになっている。2025年11月の初回コミットから2026年7月まで、合計8件のコミットで改訂が重ねられ、CC BY 4.0で公開されているため、誰でも変更履歴を追える。

評価基準をコードと同じ扱いにする発想

評価基準をレビュー対象にすべきだという発想は、Parryが2026年7月に開発を始める前から、こうした形ですでに実践されていた。評価基準をスプレッドシートの添付ファイルとしてどこかのフォルダに置くのではなく、Git管理下に置き、差分と履歴を追える状態にする。コードに対して当たり前にやっていることを、評価基準にも適用しているだけだ。

最初にこのリポジトリを見たとき、これで十分ではないかと思った。差分が取れて、履歴が残り、変更を提案として出せるなら、それ以上に何が要るのだろうか。

実際のコミットを読む

その考えは、実際のコミットを一つ具体的に見ると崩れる。

2026年7月14日にマージされたPRは「成熟度モデルCSVに組織やチーム等の名称定義を追加」というタイトルで、CSVの冒頭に「組織」「チーム」「プロジェクト」「サービス」という4つの用語定義を挿入する、+6行-1行の変更だった(出典)。diffを見れば、この4行が新しく挿入されたことは正確にわかる。

しかし、なぜこの4つの単位で切ったのか、なぜ「部門」や「サブチーム」のような他の粒度を採らなかったのかは、diffのどこにも書かれていない。コミットメッセージも「名称定義を追加」の一行で、判断の理由には触れていない。

最初は、評価基準の変更くらいならこの程度の記録で十分だろうと思っていた。しかし、これはコードレビューで起きているのとまったく同じ欠落だ。何を変えたかは残るのに、なぜその選択肢を選び、他の選択肢を捨てたのかは、コミットログの外側に置き去りにされる。評価基準だからといって、この構造が免除されるわけではない。

frontmatterというもう一つの評価基準

この欠落は、規模の大きい組織のリポジトリだけの話ではない。このブログのfrontmatterも、記事を審査するための評価基準のようなものだ。

2026年7月に書かれた記事のfrontmatterには status と createdAt はあっても publishedAt は存在しない。一方、8月に入って書かれた記事には publishedAt が新しく加わっている。公開予約の機能に合わせて、いつ公開を確定させるかを別フィールドとして持たせる必要が出てきたためだ。

この変更もdiffとしては数行で済む。しかし、なぜ publishedAt という独立したフィールドにしたのか、なぜ status の値の種類を増やすだけで済ませなかったのかは、YAMLの差分だけでは分からない。

Parryの四軸のうち、WhyとContextはまさにこの部分を埋めるための欄だ。評価基準やスキーマという、コードそのものではないが組織の判断を左右するファイルにも、同じ欄が要るはずだと、このfrontmatterの変更を通して考えるようになった。

ここまでで検証できていないこと

ただし、評価基準やスキーマの変更頻度は、コードの変更頻度よりずっと低い。変更のたびに四軸を埋める手間が、その低頻度に見合うコストなのかは、実際に運用してみないとわからない。

月に一度あるかないかのフィールド追加のために、Why、Risk、Confidence、Contextを毎回埋めさせるのは、レビューという名の過剰装備になる可能性もある。