判断メモの「使える条件」は、どこまで書く？

判断を残すとき、「こう決めた」までは書けます。難しいのは、その判断を次にも使ってよいのか、です。

自分が残したい条件は、その結論を選んだ前提と、前提が変わったら考え直す点です。あらゆる例外を先回りして書くより、別の場面でそのまま使うと困る境界を残します。

「保存できた」は、何ができたことなのか

たとえば、メモアプリで「保存済み」をいつ表示するか考えます。以下は、判断メモの書き方を示す架空の設計例です。実際のアプリを動かした検証結果ではありません。

「保存先から成功が返ったら、保存済みにする」と書くと、一見それで決まったように見えます。でも、そのメモをどこで使うかによって、必要な成功は違います。

場面	必要な結果	見直したい点
他の人と共有するメモ	共有先に反映され、対象者が見られる	端末内に残っただけで、共有も完了したように見せていないか
通信できない場所で使う個人メモ	まず自分の端末に残し、後で同期できる	サーバーを待つ設計が、記録する目的を妨げていないか

どちらも「保存」という名前を使えます。だからこそ、何が保存先で、どこまで終わった表示なのかを揃えたい。端末への保存と共有先への反映を区別するなら、「端末に保存」「同期待ち」のような表示も候補になります。

なお、サーバーの成功応答だけで、その後も必ず読み出せるとまでは言えません。保存先が何を保証し、再読み込みや失敗時に何が起きるかは、実装で確かめる別の仕事です。

この例を残すなら、次の三つがあると比較しやすくなります。

必要な結果：共有先への反映まで、利用者が確認したい
選んだ前提：端末内の保存だけでは目的を満たせない
見直す条件：オフラインでも記録したい／端末内保存を先に完了できる

ここへ、「今回はサーバーへの反映を待つ案」「待っている間の表示や失敗時の扱いは要検討」と結び付ける。結論と条件を別々の場所へ遠く離すと、結論だけが使い回されやすくなります。

逆に、「通信が成功する場合に使える」だけでは、次に迷ったときの助けとして弱い。通信に失敗したときこそ表示をどうするか決めたいからです。目の前の条件を全部列挙するより、何が変わると設計を選び直すのかを残します。

「この条件なら使えそう」と考えたことと、「その条件で確かめた」ことは別です。

まだ設計だけなら、設計案と書く。動かしたなら、どの場面を試し、何を見たかを添える。新しい条件が見つかったら、元の判断を間違いとして消す前に、使える範囲が変わったのかを見直します。

実際のコンセプト設計の手順でも、「既存手段で足りるかを比べる」に加え、「学習や探索では作ること自体にも価値がある」と明記しました。同じ比較でも、目的が変われば答えは変わります。この改訂がすべての制作で有効だと実証したわけではありませんが、次に考え直す境界として残しています。

次に判断メモを書くときは、「条件が一つ変わったら、自分はこの結論を選び直すか」と考えてみる。選び直すなら、その一つが、まず残したい条件です。