DM11 Holdings · 企業向けソフトウェア
実行は成功したと答えた。
業務も成功したのかを、DM11 が測る。
自動化が複数の業務システムに書き込むと、どの系も成功を返しながら、顧客だけが使えない状態で残る事があります。DM11 は実行の後に各系を読み直し、実行の前に宣言した条件を当てて測り、満たされていなければ成功として記録しません。
何が抜けているか
API が成功を返した事は、業務が片付いた事ではありません。
エージェントが CRM・請求・権限の 3 系にまたがって顧客を更新する。3 本とも 200 を返し、件数も要求どおり。その応答を読んでいるダッシュボードは、この処理を「完了」と表示します。
しかしそこで測られたのは API であって、業務ではありません。3 系すべてで有効と記録されていながら、ログインする席が 0 のままの顧客が残り得ます。実行の経路上で、それを見ている者が居ません。
従来の検査がすべて緑なので、この壊れ方は静かです。数日後、「有効になりました」と伝えた顧客からの問い合わせとして表に出ます。
なぜ制御が要るのか
移行は成功した。銀行は成功しなかった。
“Whilst the data migration itself was successful, the Migration Incident resulted in significant disruption…”
同じ通知は、計画が拠り所にした確認書をこう評しています。それは“forward looking statements of good intention or expectations, rather than statements of fact…”
イングランド健全性規制機構（PRA）／TSB Bank plc への Final Notice（2022）
DM11 は PRA とも TSB Bank plc とも関係が無く、推薦を受けてもいません。公開された規制文書からの短い引用で、この製品が拠って立つ区別 ── 処理は完了しても、変えたかった業務は変わっていない事がある ── をそのまま述べているために引いています。
実演
すべてが成功を返し、83 人の顧客が製品を使えない。
合成の系に対する 1 回の実行です。ここにあるコードが生成し、機械可読の受領書として出力します。下の数字はその受領書から読んだ値で、手で書いた物ではありません。
- 3 系とも成功を返した。いずれも applied = 5,000。
- 件数はすべて要求と一致した。
- 宣言した 6 つの事後条件のうち 5 つを満たした。欄ごとの検査はすべて通っている。
A customer recorded as ACTIVE can actually use the product (seats >= 1)
Entitlement: 83 records are ACTIVE with 0 seats (e.g. CUST-00001, CUST-00002, CUST-00003)
その時に出た受領書
{
"schema_id": "dm11.reality_receipt",
"schema_version": "2.1",
"transaction_id": "TXN-HERO-0001",
"intent": "Activate 5,000 trial customers: set plan
TRIAL to ACTIVE across CRM, Billing
and Entitlement",
"action_status": "RECOVERED",
"settlement_status": "PARTIALLY_SETTLED",
"outcome_status": "OUTCOME_UNKNOWN",
"final_status": "RECOVERED",
"data_origin": "SYNTHETIC_DEMO",
"trail_length": 15
}1 つの状態ではなく、3 つの軸で書きます。処理は戻せた。業務は一部しか片付いていない。顧客が残ったかどうかはこの実行では測っていないので、推測せず OUTCOME_UNKNOWN と書きます。
仕組み
条件を実行の前に宣言し、実行の後に測ります。
- 意図・対象の系・成功を定義する事後条件を宣言する。欄の値だけでなく、業務の規則を含める。
- 影響の広さを数える。どこから来た数字かが書かれていない値は「測っていない」と報告し、数えた数のように上限と比べない。
- 保証の水準を強制する。要求が満たされるまで、取引は実行できる状態に入れない。
- 実行し、各系が何を答えたかを記録する。
- 各系を読み直し、宣言した事後条件を実際の状態に当てて測る。
- 1 つでも満たされていなければ VERIFIED を拒む。その取引は成功を名乗れない。
- 影響を受けた記録だけを打ち消す ── 5,000 件ではなく 83 件。そのうえで測り直し、回復はその測定から報告する。
- hash で連鎖した記録の上に受領書を出し、何を測って何を測っていないかを書く。
証跡
4 つのファイル。こちらの言葉を信じずに確かめられます。
どれも上の実行が実際に出した物で、この頁のために作った見本ではありません。
Reality Receipt
何を宣言し、各系が何を答え、事後に何を測り、どの事後条件が 1 つだけ落ちたかを示します。
実在の系で起きた事は示しません。data_origin は SYNTHETIC_DEMO です。
受領書を取得独立の検証器
1 ファイル・標準ライブラリのみ・DM11 のコードを 1 行も読みません。受領書に当てると検査ごとに PASS / FAIL / NOT_CHECKED を返します。
業務が正しかった事は示しません。検証器自身がそう書きます ── FAIL 0 は「この検証器が見られる範囲で問題が無い」という意味です。
検証器を取得90 秒の技術要約（英語）
受領書から生成しています。受領書の欄に辿れない数字が 1 つでも入ると、機械の検査が生成を止めます。
性能・費用・顧客の成果の数字は入っていません。どれも測っていないからです。
要約を読む主張の一覧
この頁の各主張と、それを裏付ける試験・実演・ファイルの対応表。裏付けが無いために出していない主張も載せています。
予定日は入っていません。特定の版に向けた約束は何もしていません。
台帳を開くすでに無料で手に入る物
分かりやすい機能のうち 2 つは、こちらに払う理由になりません。
この頁を書く前に市場を測りました。次のものは既に無料で手に入るので、売り文句の先頭に置きません。
- エージェントの操作に対する、持ち出せる署名つき受領書。
- その受領書を検証する単体の検証器。
- 実行前の承認ゲート・最小権限・監査記録・kill switch。
誰も売っていなかったのは、実行が済んだ後の部分です。
- 書き込みが済んだ後に、宣言した事後条件を業務系の実際の状態に当てて測る事。
- 系をまたいで打ち消し、その後に測り直して、打ち消しの呼び出しが返った事ではなく 2 度目の測定から回復を報告する事。
検証の状態
現在地を、そのまま。
誤解から始まる評価は、そちらの技術者の時間もこちらの時間も無駄にするので、先に書いておきます。
適否
誰のための物で、誰のための物でないか。
- 自動化やエージェントが複数の記録系に書き込み、系どうしが食い違い得る。
- 切替・移行・一括変更が本当に着地したかを、誰かが承認しなければならない。
- 中途半端に適用された変更の代償が大きく、どの顧客が影響を受けたかを調べるのに今は数日かかる。
- 成功を定義する業務の規則を言葉にできる ── 変わるべき欄の一覧だけでなく。
- 系が 1 つしかない。照合する相手が居ない。
- Salesforce・SAP・NetSuite への名指しの接続が今すぐ要る。そのアダプタは存在しません。
- 調達を通すために認証を持つ業者が要る。1 つも持っていません。
- 処理量や遅延の保証が要る。どちらも測っていません。
まだ無い物
評価の途中で発見される事が無いように並べます。どれも期日を約束していません。
- shadow 実行 ── やらずに、やったら何が起きるかを見せる事。
- 独立した 2 名の承認者を端から端まで強制する二重統制。
- 商用製品向けのアダプタ（Salesforce・SAP・NetSuite・Stripe Billing）。
- 規模を上げた時の保証の遅延・実行の上乗せ・1 取引あたりの費用。
- ある組織で学んだ失敗の型が、別の組織を守る事。
- SOC 2・ISO 27001 その他いずれの第三者認証。
グループ・複数社をお持ちの方へ
まず 1 社の中で始めます。グループ全体からではありません。
複数の会社を所有・運営していても、最初の関わりはそのうち 1 社の 1 業務です。取引の型が他社へ移せると判った時に初めて、次の会社を見る理由が生まれます。移せるかどうかは最初の評価が答える事で、こちらが先に約束できる事ではありません。
評価
そちらの取引の型を 1 つ選んでの、有償の評価。
既に運用している複数系にまたがる取引を 1 つ ── 一括有効化・移行の切替・請求の変更など ── お預かりし、模型にします。そちらの言葉で成功を定義する事後条件、影響の広さ、打ち消しが何をしなければならないか。
お渡しするのは、その模型と、そちらの系を合成で写した相手に対する 1 回の実行の受領書と、DM11 なら何を捕まえ何を捕まえなかったかの文書です。本番の系には接続しません。
法人のアドレスから、どの取引の型を想定しているかを添えてお送りください。dm11holdings@gmail.com から返信します。
DM11 Holdings（札幌）。この頁はソフトウェアの事業で、このサイトの他の頁が扱うモータースポーツ・映像の事業とは別です。頁の数字はすべて上の受領書から読んでいます。