決定を残す

決めた日と当時の条件を残す

設計の記録で落ちやすいのが日付です。席の予約サービスが動いていても、いつの条件で選んだ構成なのかは、動作を見ただけでは分かりません。

予算が月5万円の時点で選んだ案と、予算が増えた後の案では、判断の前提が違います。日付と背景が揃うと、どの時点の条件を確かめればよいか分かります。

動いていることは、当時の理由を教えません。運用の担当者やピークの負荷が変わったら、前提がまだ成り立つかを記録から確かめます。

こうした決定を残す文書を ADR と呼びます。長い報告書を作るより、1つの決定について必要な項目を短く揃えるほうが読み返せます。

背景と結果を落とさない

項目は番号、日付、題、背景、決定、結果の6つです。背景に理由を置き、結果には得たものと引き受けた負担を書きます。

決定だけだと、同じ案を選び続けるべきか判断できません。背景には規模や予算に加え、困っていたことと、選ばなかった案の理由を入れます。

予測できる代償は、その時点で書けます。「保存先が2つになるので監視が増える」は、実際に障害が起きる前でも分かる結果です。

予測と実測は区別します。予測が外れたら確認した日と新しい判断を別の記録に残し、古い判断の前提を消さないようにします。

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

同じ利用者がどのアプリの台に届いてもログインを保てるよう、セッションの保存先を決めます。次は、その決定を6項目で残した見本です。

この記録なら、3台を入れ替える必要と、引き受けた保存先の負担を読み取れます。日付と背景を省いた「共有先に置く」という結論だけでは、その必要が今もあるか判断できません。

将来、共有先の障害対策を変えるなら、新しい番号と日付で決定を足します。以前の記録への参照も付ければ、判断が変わった理由を順に辿れます。