スコープ外にすることと、考えなくていいことは違う

はじめに

「この要件についてはどう考えているの？」と上司に聞かれて、「今回はスコープ外です」と太郎は答える。 上司はいろいろな背景があっての判断なのだろうと考え、「なぜスコープ外にしたの？」「もし必要になったらどう変える？」と続ける。 太郎は答えられない。頭が真っ白になる。

こういう経験、ありませんか？　私はあります。というか、この太郎は私です。

振り返ってみると、あれは説明が下手だったわけじゃなく、そもそも考えていなかったんだと思います。「スコープ外にする」と決めたことを、いつの間にか「考えなくていい」というふうにすり替えてしまっていたんです。

今回は、その反省から考えたことを書いていきます。

要件の3つの状態とその区別

「スコープ外にする」ことと「考えるのをやめる」ことが混ざってしまう背景には、「スコープ外」という言葉の曖昧さがあると思っています。 要件の状態は、次の3つに分けられます。

「スコープ外」という言葉が指すのは②と③です。「今回のデリバリーに含めない」というだけで、②なのか③なのかはこの言葉から読み取れません。

①と②を分けるのは、優先度・コスト・リスクの判断です。Lean/MVPの文脈で言えば「今の制約下での合理的な保留」であって、単なる先送りではない。

②と③を分けるのは、「この変更が来ることは合理的な将来予測の範囲外だ」と自信を持って言い切れるかどうかです。言い切れないものは、すべて②として扱うべきだと考えています。この基準だと、③に落とせる要件はかなり少ないはず。

なぜ起こりそうな変更については②でいるべきか

将来の変更には2種類あります。今の設計の前提と衝突する変更と、衝突しない変更です。

②の状態で軽く考えておくと、どちらなのかにあらかじめ気づけます。

衝突すると分かれば、その前提を変更しづらい形で固めてしまわないように設計できます。③のままだと、衝突する前提を無自覚に積み上げてしまうリスクがある。逆に衝突しないと分かれば、今の実装は変えなくていい。それが分かること自体にも価値があります。

起こりそうな変更は、確率的にやって来ます。「今は優先度が低い」から外したのなら、優先度が上がれば来る。来てから初めて考え始めても、そのときにはもう、衝突する前提が設計のあちこちに積み上がっているはずです。

あとから「ここも変えたい」が来たときの影響は、コードだけにとどまりません。データ移行が必要になることもあれば、API契約の変更が必要になることも。しかも一度に全部は変えられないので、段階的に慎重に進めることになります。設計時に想定していなかった変更は、どこまで波及するか読めないんです。

ちなみに、②で考えていれば「なぜ今やらないか」「来たらどうするか」を聞かれたときに答えられます。冒頭の太郎のような思いをせずに済む。これはあくまで副産物ですが、チームからの信頼にもつながる、うれしいおまけだと思っています。

まとめ

スコープ外にすることと、考えなくていいことは違う。これが今回いちばん言いたかったことです。

実装しないという判断はあっていい。ただ、起こりそうな変更については、軽くでいいから考えておく。今の設計の前提とぶつかるかどうかを、今のうちに見ておきたいからです。

ついでに、聞かれたときにちゃんと答えられるようにもなります。これは副産物ですが、あの気まずさを味わわなくてよいのは気がいくらか楽になる気がします。