scoping-changes

変更範囲の設定

必須の前提知識： principal-engineering スキル。

概要

スコープは両方向に逸脱します。過剰な作り込みは、修正範囲をきっかけとなった問題より広げ、黙ってスコープを縮小すると、承認されたタスクが合意した内容を下回ります。どちらも同じ欠陥です。納品された変更が、その原因に合わなくなっています。基本原則は、修正の規模をきっかけとなった問題に合わせ、現実的な事情で削減が必要になったときは、黙って削るのではなく、見える形で分割することです。

きっかけとなった問題に合わせた規模設定

• きっかけとなるのは、チケットに書かれた問題の説明ではなく、欠陥やニーズそのものです。 同じ欠陥が別の経路でも見つかった場合は、スコープに含まれます（別の場所に残ったまま「修正済み」と報告するのは、半分しか真実ではありません）。そのファイルを開いたことで気づいた隣接する改善は含まれません。
• 修正の規模は、きっかけとなった問題の規模に合わせます。過剰な作り込みはせず、到達不能なエッジケースに先回りして対処せず、そのファイルを開いたついでにリファクタリングを持ち込みません。
• 気づいた隣接する改善は実在する課題なので、トラッカーに登録し、この差分には含めません。
• 境界線上の追加を判断するテスト：主な修正が存在しなくても、それ自体の価値でリリースされるでしょうか。そうでなければ、他者の差分に付け加えられた飾りです。そうであれば、独立した変更としてリリースします。このテストに合格しても、別の変更として進めることが認められるだけで、便乗させてよいわけではありません。
• オーナーはスコープを再設定できますが、スコープを統合することはできません。作業のオーナーによる「ついでに含める」という依頼は、正当な形で2つ目のタスクを追加しますが、それも独立した変更としてリリースします。これらのルールは作業の形を定めるものであり、どの作業を行うかはオーナーが決定します。
• 求められていない構造は、デザインパターンをまとったスコープクリープです。実装が1つしかないインターフェース、常に1種類のものだけを生成するファクトリー、誰も変更しない値の設定などが該当します。想定上の2つ目のケースに備えて追加するのではなく、実際に2つ目のケースが登場したときに追加します。
• 現実的な制約を受け入れる意図的な簡素化には、コメントでその制約を記載します。上限と、引き上げる根拠となる条件を記します（「共有キューは1つ。単一のコンシューマーで処理が追いつかなくなったら、テナントごとにシャーディングする」）。上限は現在の制約です。コメントには、判断に至った経緯ではなく、システムが今日どのように動作するかを記します。
• 新しいコードを書く前に、既存のコードベース、標準ライブラリ、プラットフォーム、すでにインストールされている依存関係を使い尽くしてください。新しいパッケージを追加する前に adding-dependencies を参照してください。

黙ってスコープを縮小せず、分割する

• 承認されたタスクが大きすぎると判明した場合、オーナーは削減する境界を明示し、名前を付けた複数の部分に分割します。すべて完了したように見える、黙って「現実的な最小限」だけを納品してはいけません。
• 作成者は、先送りした各部分をオーナー付きの追跡項目として登録します。まだオーナーがいない場合は、「owner pending triage」と明記します。テクニカルライターのプラグインがインストールされている場合、トラッカーの運用ルールは writing-issues に従います。作成者の記憶にしか残っていない未完了作業は、先送りではなくスコープ縮小です。
• 報告では、どの部分をリリースし、どの部分をリリースしなかったかを明確に述べます。一部だけの納品を正直に明記するなら計画ですが、一部だけの納品を完了と表示するなら欠陥です。

完了まで進める

• 承認済みの計画は、「続けてもよいですか？」と途中で確認せずに完了まで進めます。停止するのは、実際のブロッカー、破壊的な操作、またはオペレーターの対応が必要なハードゲートがある場合だけです。
• 一部がブロックされている場合は、ブロックされていない部分を完了させ、ブロッカーの内容と必要な対応を明らかにします。1つのタスクが止まったことで、残りが黙って停滞することのないようにします。
• 決定済みの事項は、実行中もそのまま維持します。新しい情報によって本当に再検討が必要になった場合は、黙って方向転換するのではなく、明示的に再決定します。テクニカルライターのプラグインがインストールされている場合は、recording-decisions を使って記録します。

レビューにおけるスコープ

• レビューする側：たまたま気づいた無関係な欠陥は、レビューで見つけた問題ではありません。トラッカーに一度記録し、差分のレビューに集中してください。
• レビューされる側：差分に対する指摘は修正するか、明示的に回答します。差分の範囲外の指摘は、変更に取り込まず、トラッカーに登録します。

よくある間違い

• 「せっかくここにいるのだから」を正当化の理由にすること。ここにいるのは、トリガーへの対応のためです。
• 締め切りに間に合わせるためにスコープを縮小し、完了したと報告すること。締め切りのプレッシャーは現実のものでした。誠実な対応は、作業を分割し、どちらの半分を出荷したかを伝えることでした。
• システムが到達できないエッジケースを防御して、抜かりなく対応した気になること。到達不能なケースへの防御は、善意から生まれたデッドコードです。
• 少し良いアイデアが浮かんだからと、実装の途中で承認済みの設計を再検討すること。そのアイデアは書き留め、計画を完了させてから、出荷済みの現状を踏まえて提案しましょう。
• レビュー担当者のスコープ外の要望によって差分を拡大させること。記録し、感謝を伝え、トリガーを出荷しましょう。