開発・点検・保守を分ける

変更を伴う開発、読み取り専用の点検、挙動を変えない保守は、別の業務として扱います。分ける理由は事故の防ぎ方にあります。点検のついでに修正すると、確認していない変更が混ざります。開発の途中で範囲がひとりでに広がると、差分が読めなくなります。だから弊社では、業務ごとに開始の条件と許される操作を変えています。

開発

要望や不具合の整理から、設計、実装、変更に必要な検証、文書更新、合意した完了地点までを一つの仕事として扱います（開発の進め方）。開発中に、リポジトリ全体の監査や無関係な保守候補の修正へ自動的に範囲を広げません。

横断点検

人が明示的に開始する、読み取り専用の作業です。product:checkは変更範囲または上限付きの候補を点検し、全件監査（full）は人間が明示した場合だけ実行します。仕様と実装の接続、文書のずれ、コードの健全性、開発環境を確認しますが、その場で修正、削除、Issue起票をしません。

見つかった不具合は新しい開発として、挙動を変えない整理は新しい保守として、範囲を決め直してから着手します。検出と修正を分けることで、修正の一つひとつが人の判断を通ります。

定期巡回

起動の時刻だけを自動化が受け持ち、独立したワーカーが、動いている製品を限られた範囲で見て回ります。例えば、指定した権限で主要画面を巡回し、コンソールエラー、4xx・5xx、白画面、表示崩れを確認します。一回の巡回で扱う検出数を制限し、コードは変更しません。自動起票する場合は自動検出であることを明示し、人が再現性と優先度を判断できる証拠を残します。

保守

確認済みの候補に対する、挙動を変えない変更です。人が対象を指定してproduct:maintainを開始し、code、docs、READMEなど一つの系統に絞ります。保守は機能開発より広い範囲へ触れやすいため、通常開発の途中で見つけても自動着手しません。作業中に機能追加や不具合修正が必要になった時点で、保守のまま続けず開発として扱い直します。