制約

動かせない条件をそろえる

制約は、今回の設計で守らなければならない条件です。席の予約サービスなら、月の予算は5万円まで、公演初日まで8週間、既存の利用者情報を引き継ぐ、といったものです。

要件が「実現したいこと」なら、制約は案を選べる範囲を決めます。欲しい機能を満たしても、予算や期限を超える案は、そのままでは採用できません。

交渉して合意が変わったら、制約を更新します。合意する前から予算が増えるものとして設計すると、必要な費用を払えず、作り直しになります。

既存資産も同じです。引き継ぐ必要がある利用者情報を、作りやすいからという理由で捨てることはできません。

案を落とす理由を残す

採用しない案にも、超えた条件を記録します。月額と期間をそれぞれ比べ、両方を超えたなら理由を2つ残します。

「不採用」とだけ書くと、予算が増えた日にその案を見直してよいか分かりません。理由を分ければ、今回動いた条件に関係する案から確認できます。

制約は、その時点で合意した条件です。変更後も古い条件で落とし続けると、今なら使える案を見逃します。

予約サービスで解いてみる

DAU 3万人、1人6回の要求なら、平均は約2 QPSです。ピーク係数50で100件/秒、1台40件/秒を前提に、必要な性能を持つ案を比較します。

性能を満たす見込みのある3案について、月5万円と8週間の制約を順に確かめます。月額は比較用の見積もりで、実際には関連する費用も含めます。

ここでは既存の予約基盤を選びます。専用サーバーは速く準備できても費用が払えず、自前の決済は安くても公演初日に間に合いません。

その後、予算だけが月20万円に増えたとします。まず予算超過で落とした専用サーバーを拾い直し、今も性能と期間の条件を満たすか確かめます。

期限は8週間のままなので、自前の決済はまだ候補に戻せません。もし月8万円かつ12週間の案があれば、予算を満たしても期限超過の理由が残ります。

予算が増えたことは、落とした案をすべて採用できるという意味ではありません。どの条件が変わり、どの理由が残ったかを読むと、再検討する範囲を絞れます。

記録には条件の値と更新日も残します。古い予算で比較した表を使い続けないよう、見直した案の判断も同じ表に反映します。