gists

SDR — Shared Decision Records

Your decisions are assets.

概要

SDR は、意思決定を共有可能な形で一箇所に蓄積するための仕組みである。
ADR を起点にはしているが、ADR のような重い設計文書ではない。

SDR の狙いは、立派な文書を書くことではなく、決めたことの痕跡を自然に残し続けることにある。


SDR の基本発想

SDR では、意思決定を以下のように捉える。

つまり SDR は、厳密な decision document ではなく、共有 decision log に近い


ADR との違い

ADR 的に見ると、背景・選択肢・結果・ステータスなどを揃えたくなる。
しかし SDR はそこを本質としていない。

SDR は ADR の軽量版というより、むしろ次のようなものとして考えた方が近い。

違いを一言で言うとこうなる。


SDR の中核

SDR の本体価値は、文書フォーマットではなく capture UX にある。

たとえば次のような体験が中核になる。

$ sdr memo.md

これにより、

という流れができる。

つまり SDR は、書くコストを下げて、集約を自動化する仕組みである。


ステータスを持たないという思想

SDR では、各 DR に status を持たせなくてもよい。

のような状態管理を個別レコード内で厳密にやるのではなく、 変更したいときは新しい DR を追加して言及する

つまり、

という運用になる。

このため SDR は append-only であり、過去を直すより履歴を伸ばす。


Viewer を本体に含めない

SDR は「どう読むか」を本体に含めなくてよい。

考え方としては、

である。

つまり SDR は、決定記録の capture/storage layer に専念する。 検索、一覧、可視化、要約などは後段に任せる。


SDR が向いている場面

ソフトウェア開発

有効である。 ただし重厚な設計文書としてではなく、以下の用途に向く。

クリエイティブなチーム

むしろ相性がよい。

クリエイティブ領域では、

ことが多い。

そのため SDR の

という性質が活きる。


SDR の本質的な定義

ここまでの議論を踏まえると、SDR は次のように定義できる。

SDR は、決定を共有ログとして自動採番・自動集約し、 軽い負荷で継続的に蓄積できるようにした仕組みである。

あるいはもっと端的には、

SDR = Shared Decision Log を運用可能にするための仕組み

と言ってもよい。


独自性

既存の類似物はある。 しかし SDR には次の独自性がある。

つまり SDR の新しさは、記録様式そのものよりも、

軽さ + 集約 + 継続性

の組み合わせにある。


一言でまとめると

SDR は、ADR をカジュアルにしたものというより、

決定の痕跡を、誰でも気軽に、一箇所へ、追加し続けられるようにした共有基盤

である。