なぜ自力実装は続かないか — PRテンプレートのWhy欄が形骸化する理由

「PRテンプレートに、なぜその変更をしたかを書く欄を作ろう」という提案は、レビューの負担が増えたと感じたチームがまず思いつく対策の一つだ。実装は簡単で、.github/PULL_REQUEST_TEMPLATE.md に見出しを一行足すだけで始められる。

問題は、始めた後に起きる。ある開発者ブログでは、『考える技術・書く技術』の「状況・複雑化・結論」という構成をPRテンプレートに導入した経緯が公開されている。導入直後は機能していたが、時間が経つにつれて記入内容は「困る」「直す」という最小限の言葉だけで埋められるようになっていった(出典)。テンプレートの見出しは残っているのに、そこに書かれる情報量だけが先に失われていく。これが典型的な崩壊の過程だ。

なぜ「なぜ欄」は書きにくいのか

別のチームの記事では、改善前の「なぜ（Why）」欄が抱えていた問題がそのまま言語化されている。

大抵、このようなテンプレートにある**なぜ（または Why）**が書きにくいと思うんです。なぜって……チケットにやれって書いてあるから……みたいな

(出典)

これは記入者が怠けているのではなく、欄そのものの設計に無理があることを示している。タスクがチケットで既に指示されている状況では、「なぜやるか」は「上流で決まったから」以外の答えを持たない。書く側からすれば、存在しない理由を捻り出すか、当たり障りのない一文で埋めるかの二択になる。このチームは「なぜ」を独立した項目ではなく「やったことに紐づいた補足説明」に位置づけ直すことで解決しているが、逆に言えばこの再設計をしなかった大多数のテンプレートは、同じ理由で形骸化していく構造を抱えたままになる。

崩壊のパターンを分解する

この2つの実例から、自力実装される「記録する運用」が壊れていく過程はいくつかの型に分解できる。

  1. 表面化パターン：欄自体は埋められ続けるが、内容が「困る」「直す」のような最小限のトークンに収束する。テンプレートの見た目は機能しているように見えるため、壊れたことに誰も気づきにくい。
  2. 形骸化パターン：「チケットに書いてあるから」という以上の理由が存在しない項目は、そもそも書く動機を持たない。導入時点で既に破綻の芽がある。
  3. レビュアー無視パターン：欄は書かれ続けていても、レビュアーがそれを読む工程がレビューフローに組み込まれていなければ、書く側は次第に「読まれていない」ことに気づき、書く努力を止める。
  4. インセンティブ崩壊パターン：記録するコストを払うのは変更を書いた本人で、その記録から便益を得るのは半年後に同じコードに触れる別の誰かである。コストと便益を負う人が一致しない構造は、締め切りの圧力の前で真っ先に削られる。
  5. ツール過多パターン：PRテンプレート、Design Doc、Wiki、Slackスレッドと記録場所が分散すると、どこを見れば判断の経緯が分かるのかという参照コストそのものが上がり、結局誰も参照しなくなる。

これらは互いに独立した現象ではない。3（レビュアー無視）が起きると4（インセンティブ崩壊）が加速し、4が進むと1（表面化）に落ち着く、という順序で連鎖することが多い。根にあるのは常に4で、「書くかどうかを本人の裁量に委ねている限り、書く努力は競合する他の仕事に負ける」という一点に収束する。

Parry自身のWhy欄も、まだ検証されていない

この記事を含め、Parryが記事をレビューに出す際も、実は同じ形の「なぜ欄」を経由している。ParryのPR作成ツールには why（なぜこの変更が必要か）というパラメータが必須で存在し、埋めなければPRそのものを作成できない。

正直に書いておくと、Parryの開発自体は2026年7月に始まったばかりで、この記事を書いている時点でまだ3週間ほどしか経っていない。上に挙げた崩壊パターンが3〜6ヶ月というスパンで顕在化する想定なら、Parry自身のwhy欄がその期間を生き延びるかどうかは、まだ何も証明されていない。この記事は「Parryなら形骸化しない」という宣伝ではなく、「なぜ形骸化するかの構造」を先に言語化しておく記事である。

Parryが取っている対策は一つだけで、「なぜ欄を書きやすくする」ことではなく、「なぜ欄を埋めない限りレビューという次の工程に進めない」という制約を先に作ることだ。書く側の裁量に委ねる限り形骸化は避けられない、という上記の結論から機械的に導かれる対策であり、真新しい発想ではない。摩擦をどこに置くかだけの違いである。

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

崩壊のパターン自体は他チームの実例から裏が取れているが、「摩擦を先に作れば崩壊しないのか」はまだ検証していない。摩擦自体が別の形で回避される可能性（テンプレートを無効化する、形式的な一言で通過を試みる等）は当然あり得る。もし今、PRテンプレートのWhy欄を導入して3ヶ月前後で似た崩壊を経験した、あるいは経験しつつあるなら、それがどのパターンに近いかは知りたいところだ。