制約だけでは何を作るか決まらない

規制対象のプロダクトを作るチームは、ソフトウェアの言葉で書かれていない規則、社内方針、専門家の意見を受け取ります。自然な反応は、すべての文章を機能要件へ変えることです。バックログは増えますが、規則、リスク、証拠のつながりは見えにくくなります。

プロダクトの定義は、解決策を詳しく描く前にこのつながりを作る必要があります。プロダクトチームだけで規則を解釈することでも、専門家が画面を設計することでもありません。各分野が判断と根拠を一緒に確認できる共通の対象を作ります。

義務を観察できる状況として書く

有用な記述は、誰が、何に対して、いつ、どの情報を使って行動し、どの記録を残すかを示します。この構造は曖昧さを明らかにします。また、解決策がプロダクト、人の手順、組織上の統制、またはそれらの組み合わせのどこにあるかを示します。

「追跡可能性を保証する」だけでは一般的すぎます。対象となる出来事、閲覧を許される人、記録が有用な期間、行動に異議を申し立てる方法、情報が欠けた場合のシステム動作を決める必要があります。

この具体性は専門家の検証を置き換えません。確認または修正できる対象を専門家へ渡します。

重要な判断は四つの要素につなげます。

この連鎖は二つの失敗を防ぎます。一つ目は、どのように満たすかを示せないまま適合を宣言することです。二つ目は、減らすリスクを説明できないまま高価な仕組みを作る過剰な適合です。

記録は短く、更新され続ける必要があります。網羅的でも古いデータベースは提供を助けません。元に戻しにくい判断、未解決の仮説、まだ作られていない証拠を優先します。

重要なプロダクトでは、自動化と人の判断の境界を明示します。規則は操作を自動的に停止することも、確認する信号を出すことも、異議を申し立てられる判断を提案することも、単に記録を残すこともできます。

これらは利用者、運用、責任に異なる影響を与えます。実装の都合で偶然決まるべきではありません。インターフェースも、システムが知っていること、推測したこと、人が決めることを分けて示します。

一般的な定義では正常な経路を最初に描き、例外を後から加えます。規制のある状況では、例外に本当のリスクが含まれます。欠けたデータ、不確かな本人確認、過ぎた期限、矛盾する情報源、異議を受けた判断、利用できない外部サービスなどです。

これらを早く扱うと、欠けている責任が見えます。誰が停止を解除するか。どの情報を表示するか。どの遅延まで許容するか。後の確認にどの記録を使うか。答えは利用体験だけでなくアーキテクチャにも影響します。

最初の増分ですべての規制を扱う必要はありません。狭い範囲で完全な連鎖を閉じます。現実の状況、意思決定、証拠、異議申立てまたは復旧の方法、そして運用できるチームを含めます。

この範囲は長い仕様書より強い議論を生みます。専門家は実際の動作を確認できます。技術チームは証拠の費用を把握できます。業務チームは規則が日々の仕事をどう変えるかを評価できます。

良いプロダクト定義は、規制上の不確実性をなくしません。不確実性の場所を示します。確認された判断、まだ助言が必要な判断、作成する証拠、解釈が変わったときに修正する部分が明確になります。文書化された適応能力は、固定された適合の約束より長く役に立ちます。