top of page

Chapter 1　
ADD / CHG / DEL による判断区分ルール

Chapter 1

このChapterで定義するのは、
コードの書き方でも、作業手順でもない。

 

コード変更を「作業」として扱わせないためのルールである。

 

開発現場では、
「少し直した」「ついでに変えた」「一旦消した」
といった曖昧な言葉で、判断が実装に混ざりやすい。

 

しかし本Wikiでは、
コード変更はすべて「判断の結果」であり、
判断には必ず種類があると定義する。

 

その判断の種類を、
ADD / CHG / DEL の3つに限定し、
コード上に明示的に固定する。

1-1. ADD / CHG / DEL は「作業区分」ではない

ADD / CHG / DEL は、
Git差分や作業内容を表す記号ではない。

 

本Wikiにおいては、
判断の種類そのものである。

  • ADD：新しい判断として「追加する」と決めた

  • CHG：既存の判断を「変更する」と決めた

  • DEL：既存の判断を「削除する」と決めた

ここで重要なのは、
実装者が何をしたかではなく、
どの判断が行われたかである。

1-2. なぜ判断の種類を固定するのか

障害調査や仕様確認の場面では、
最初に知りたいのは次の一点である。

​

「これは追加なのか、変更なのか、削除なのか」

 

この区別が曖昧なままでは、

  • 影響範囲の特定が遅れ

  • 過去判断の追跡が困難になり

  • 誰の判断だったのかが不明確になる

判断の種類を固定することで、
調査の入口が一瞬で定まる。

1-3. 判断は Backlog、コードは結果のみを持つ

判断の正本は Backlog にある。
理由・背景・合意・経緯は、すべてそこに集約される。

 

コードに書くのは、
判断の理由ではなく、判断の結果のみである。

 

そのためコード上では、

  • なぜそうしたか

  • どんな議論があったか

といった説明は不要であり、
どの判断（ADD / CHG / DEL）かが即分かればよい。

1-4. ADD / CHG / DEL を曖昧にしてはいけない理由

「ついでに修正」
「後方互換だから問題ない」
「前と同じだから変更ではない」

 

これらはすべて、
判断を曖昧にする言い訳である。

​

本Wikiでは、

  • 少しでも挙動が変わるなら CHG

  • 挙動を消すなら DEL

  • 新しい責務が生まれるなら ADD

と、必ず一つに分類する。

​

分類できない変更は、
判断が未整理であることを意味する。

1-5. 実装者の裁量を排除するためのルール

このルールの目的は、
実装者を縛ることではない。

​

実装者に判断させないためである。

​

  • これは追加か？変更か？

  • どこまで影響するか？

といった判断は、
すでに Backlog で終わっている。

​

実装者は、
指定された判断を、指定された形でコードに反映するだけでよい。

1-6. 調査と責任追跡を最短にする

ADD / CHG / DEL が明示されていれば、

  • どの種類の判断か

  • どのタイミングで入ったか

  • どこを見ればよいか

が即座に分かる。

 

結果として、

  • 調査が速くなり

  • 説明が短くなり

  • 責任の所在が明確になる

これは、
スキルではなく構造によって得られる効果である。

​まとめ

  • コード変更は作業ではなく、判断結果である

  • 判断には必ず種類がある

  • ADD / CHG / DEL は判断の分類である

  • 分類できない変更は、判断が未整理である

  • 実装者の裁量を排除することで、調査と責任追跡が速くなる

Chapter 0：開発ルール総論

 

Chapter 1：ADD / CHG / DEL による判断区分ルール

 

Chapter 2：管理番号（Backlogキー）・日付付与ルール

 

Chapter 3：コード内タグ（START / END）運用ルール

 

Chapter 4：Gitをバックアップに限定する設計

 

Chapter 5：開発環境構成ルール

 

Chapter 6：デモ環境運用ルール

bottom of page