範囲は争う場ではなく、一緒に選ぶ場だ
一言でいうと
範囲の判定ルールと前提元帳をファイルに固めておけば、新しい要望に「できません」ではなく「では何を外しますか」と答えられます。
なぜ必要なのか
着手の最初の週に決めた範囲は、2週目から漏れ出します。漏れる場所はいつも似ています。物流チームがSlackで「これだけお願いします」と送り、経営支援チームが会議の終わりに「それをやるついでに」と付け足し、私たちは断る根拠をその場で見つけられません。合意書は引き出しの中にあり、読んでみても、この要望がその文に当たるのかがあいまいです。
2つ目の場所は前提です。「夜間バッチは02:00から04:00までしか動かない」という話を着手会議で聞き、それを前提にメンテナンスウィンドウを決めます。3週間後にその前提が間違っていたとわかりますが、そのときにはすでに、その上にスケジュールと変更計画が載っています。前提が議事録にしかなければ、誰も再確認しません。
3つ目の場所は答え方です。範囲外の要望に「それは範囲ではありません」と答えると、会話が終わって関係が悪くなります。顧客の立場では、必要だから尋ねたのであり、私たちは助けに来た人です。
どう動くのか
3つとも同じ方法で直します。判断を人の頭の中からファイルへ移します。
範囲ルールは、順序のある一覧として書きます。ルールごとに条件と結果(内・外)と理由を書き、要望1件を上から順に当てはめて、最初に当てはまったルールが勝ちます。順序がそのまま優先順位なので、狭いルールを上に、広いルールを下に置きます。「個人情報に触れる作業は範囲外」を一番上に置けば、その下の「倉庫システムの作業は範囲内」より先に当たります。
ここで重要なのが判断保留です。どのルールにも当たらない要望は「範囲外」ではなく「まだわからない」です。当たらなかったものを自動的に範囲外へ押しやると、ルールの抜けが永遠に見えません。保留として残しておけば、その一覧がそのまま次の会議の議題になります。
判定には、どのルールが決めたかも一緒に書きます。これがあれば、顧客が「なぜこれはできないのですか」と尋ねたときにルールを1つ見せればよく、ルールが間違っていればルールを直せば済みます。人を説得する代わりにファイルを直す会話になります。
前提元帳は、前提ごとに4つのことを書きます。
전제 "야간 배치는 02:00 부터 04:00 까지만 돈다"
깨지면 점검 창이 배치와 겹쳐 서비스가 멈춘다
확인법 crontab 과 최근 30일 실행 로그의 시작 시각을 견준다
확인일 2026-08-20 (유효 14일 → 2026-09-03 까지)
「壊れたら何が崩れるのか」を書くことが、この元帳の核心です。それを書いてみると、ある前提は間違っていても何も起きず、ある前提はその上に計画全体が載っているとわかります。そして、確認に有効期間を付けます。顧客の環境は私たちが見ている間にも変わるので、一度確認したことが永遠に正しいとは限りません。期間が過ぎた前提は「間違っていた」ではなく「再確認が必要」です。
現場での姿
1つ目に、断る文章の代わりにトレードオフ表を出します。範囲外の要望が6日分なら、「これを入れるには6日かかります。いま合意している作業のうち、この2つを外せば釣り合います。どちらにしますか」と答えます。顧客は断られたのではなく選択肢を受け取ったのであり、たいていは自分で優先順位を立て直します。
トレードオフ表を出すときに守ることが2つあります。外そうと提案する作業の束の合計が新しい要望のコスト以上であることと、その束からどれか1つを外すと足りなくなることです。余裕を持たせて多く外そうと言うと、顧客は私たちが仕事を減らしたがっていると感じます。そして、必ずやるべき作業(合意書が明記したもの)は、交換の対象に入れません。
2つ目に、判断保留の一覧を隠しません。保留が5件なら、ルールに抜けが5つあるという意味で、それをそのまま報告すれば顧客が一緒に埋めてくれます。保留を勝手に範囲内や範囲外へ押し込むと、その決定を私たちだけで下したことになります。
3つ目に、前提の持ち主を書きます。「夜間バッチの時間」の持ち主が運用チームのチェ課長と書かれていれば、再確認するときに誰に尋ねるかを悩みません。持ち主のいない前提は、確認期間が過ぎても誰も確認しません。
4つ目に、ルールと元帳を成果物として渡します。契約が終わるときに渡すものがレポートだけなら、次の人は同じ場所からやり直しになります。ルールファイルと前提元帳は、そのまま次の契約の出発点になります。
実務で本当に大切なこと
- 最初に当てはまったルールが勝ちます。順序がそのまま優先順位なので、狭いルールを上に置きます。
- 当たらなかったものは範囲外ではなく保留です。保留の一覧がルールの抜けを示します。
- 前提には、壊れたときの結果と有効期間と持ち主を一緒に書きます。
- 範囲外の要望にはトレードオフ表で答えます。外す束は、足りなくも余りもしないように選びます。
次のラボですること
(架空の)テソン食品の着手資料一式を手にします。要望25件と合意済みの作業10件、そして合意書で範囲を扱った6行です。範囲ルールを順序のあるファイルに書き、判定ツールを作って、範囲内・範囲外・保留に分けます。採点ツールは、毎回違うルールと要望で作成した判定ツールを実際に動かして、判定と根拠のルールを照合し、狭いルールと広いルールの順序を入れ替えて優先順位が守られているかも確かめます。そのあと前提元帳を作り、確認の期限が切れた前提を見つける道具を作ります。最後に、新しく入ってきた範囲外の要望についてトレードオフ表を作り、レポートにして出します。