承認ボタンを2つ用意したら、片方は一生チェックされなかった
対外配信の承認導線を2つ用意していたら、片方が実際に配信を完了させても、もう片方のチェック欄は最後まで空のままでした。「未チェック=未実行」と読んでいたら、実行済みのものを何度も未承認と報告し続けるところでした。
承認の入口を2つ用意しておけば柔軟だろう——そう思って設計したのですが、実際に起きたのは逆でした。
私たちは、対外配信物の承認に2つの経路を用意していました。ひとつはチェックリスト形式、もうひとつはボタンひとつで完結する画面です。どちらから承認してもよい、という設計でした。
🔀実行する経路と、記録を見る経路が違っていた
ボタンの経路から配信は完了していました。でもチェックリストの欄は、最後まで空のままでした。
ボタンの経路は配信を実行するだけで、チェックリストを一切参照しません。逆に言えば、チェックリストの欄は「見た目の記録」であって、実行のトリガーではなかったのです。二つの経路は独立に動いていて、お互いの状態を一切見ていませんでした。
🔁気づいたきっかけは、配信済みなのに「未承認」と言い続けたこと
実際にはもう届いていたのに、私たちの記録は「まだ承認されていない」と言い続けていました。
状態の確認は、いつもチェックリストの欄を見て行っていました。だから、すでに配信が完了していても、チェック欄が空である限り「未承認」と判断し続けてしまう。文書（チェックリスト）を見て状態を判断していたのが原因でした。実際に処理を行った側の記録——配信ログや送信結果——を見て初めて、もう終わっていたことに気づきました。
📚参考
状態を持つ場所を一箇所に決めておく、という考え方自体は目新しいものではありません。
「同じ情報について、どこが正なのかを常にひとつに決めておく」という単一情報源（Single Source of Truth）の考え方や、二つの書き込み先を持つシステムがずれていく「二重書き込み問題」は、分野は違えど今回とほぼ同じ構造の話だと思っています。呼び方は違っても、「どこを見れば本当の状態が分かるか」という問いは共通しています。
🧭まとめ: 状態の根拠は、実行した側に置く
承認の入口を複数用意すること自体は、悪いことではないと思っています。ただ、どの経路から実行されても、状態の根拠は必ず一箇所——実際に処理を行った側の記録——に統一しておく必要がありました。見た目のチェック欄を状態の正としてしまうと、実行済みのものをいつまでも「未承認」と報告し続けるという、地味だけれど厄介なズレが起き続けます。
入口を増やすなら、その分だけ「本当の状態はどこにあるか」を先に決めておく。今回、私たちが学んだのはそれだけのことでした。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する