DM11 Holdings · 経営層向けの要約
自動化は、助言から
実行へ移りつつあります。
助言するだけの時代、間違いは会議を 1 つ無駄にしました。記録系へ書き込むようになると、間違いは、会社が自社の顧客・在庫・売上について信じている事そのものを書き換えます。この要約は、その瞬間に開く隙間と、いま何ができるかについてです。
4 分
何が変わったか
判断と変更の間に居た制御が、居なくなりました。
30 年のあいだ、誤った変更に対する歯止めは人でした。誰かが案を読み、誰かがボタンを押し、誰かが結果の違和感に気づく。その人は遅く、この 2 年、業界はその人を外す事に力を注いできました。
代わりに入ったのは、複数の記録系へ同時に、数ミリ秒で通る変更と、「成功した」と書かれた 1 行の記録です。その 1 行を書いているのは、変更を行った層そのものです。
これは自動化への反対ではありません。遅さと一緒に何が静かに外されたか、という観察です。
問題
技術的に完了した事は、業務として正しい事の証拠ではありません。
一括の変更が CRM・請求・権限に届く。どれも成功を返す。件数もすべて一致する。下流のダッシュボードはすべて「完了」と表示する ── どれも同じ API の応答を読んでいるからです。
そこでは業務が測られていません。3 系すべてで有効と記録されながら、ログインする席が 0 の顧客が残り得ます。系どうしは食い違っていません。あり得ない状態で一致しているのです。
この壊れ方が高く付くのは、静かだからです。問い合わせとして、合わない売上の数字として、あるいは「その承認は何に基づいていたのか」という監督官庁の問いとして、後から表に出ます。
“Whilst the data migration itself was successful, the Migration Incident resulted in significant disruption…”
DM11 は PRA とも TSB Bank plc とも関係が無く、推薦も受けていません。公開された規制文書からの引用で、区別をそのまま述べているために引いています ── 移行は成功し、銀行は成功しなかった。
DM11 の層
書き込みの後で、業務の状態を独立に検証します。
DM11 は実行の代わりではなく、実行の後に立ちます。取引が走る前に、それが正しいと言える条件を宣言します ── 欄の値だけでなく、業務の規則を含めて。走った後、DM11 は各系の実際の状態を読み直し、その条件を当てて測ります。
満たされていなければ、検証済みの状態を拒みます。実行層が何を返していても、その取引は成功を名乗れません。そのうえで、実際に影響を受けた記録だけを打ち消し、もう一度測り、回復はその 2 度目の測定から報告します。
出てくるのは受領書です。何を宣言し、何を測り、何を測らず、何を戻したかの機械可読な記録で、DM11 のコードを 1 行も走らせない単体の検証器で検査できます。
いまの証拠
従来の検査はすべて通り、83 人の顧客が製品を使えない。
3 系とも applied = 5,000 で成功を返しました。件数もすべて一致。宣言した 6 つの事後条件のうち 5 つを満たし、欄ごとの検査はすべて通っています。
6 つ目は業務の規則でした ── 有効と記録された顧客は、実際に製品を使えなければならない。83 件がこれを満たしませんでした。DM11 は検証済みとして記録する事を拒み、5,000 件ではなくその 83 件を打ち消し、測り直し、受領書を出しました。
この実行は合成で、受領書の中にそう書かれています。示しているのは仕組みであって、顧客の成果ではありません。
現在地
いま本当の事と、そうでない事。
先に書きます。誤解から始まる評価は、こちらより先にそちらの運営部門の時間を使うからです。
入口
1 つの事業会社の、1 つの業務。
最初の関わりは、信用ではなく証拠で判断できる大きさであるべきです。本番の系には接続せず、誰の仕事のやり方も変えません。
- 既に走っている、複数系にまたがる取引を 1 つ選ぶ ── 一括の有効化、移行の切替、請求や基準データの変更など。
- それが正しいと言える事後条件を、そちらの言葉で述べる。影響の及ぶ範囲も。
- DM11 がそれを模型にし、関係する系の合成の写しに対して走らせる。
- 模型・受領書・検証器と、DM11 なら何を捕まえ何を捕まえなかったかの文書をお渡しする。
- 先へ進む理由が在るかは、そちらの部門が決める。無いという答えなら、その理由が書かれた文書が残ります。
最初の 1 歩はこれで全部です。試験導入の契約も、導入する基盤も在りません。
広げ方
業務 → 会社 → グループ。そして、証拠の上でだけ。
グループの複数の事業会社が似た系を動かしているなら、一度模型にした取引は使い回せるかもしれません。それは最初の実証の後に確かめる仮説であって、初めから多く買う理由ではありません。
下の段はグループでの関わりをどう組むかの設計です。**いま在る製品ではありません** ── DM11 はこのどの段も、顧客と一緒に走らせた事がありません。
- 選別 ── そもそも業務の状態を自動で変えている事業会社はどこか。
- 業務の選定 ── 最初に検証する価値の在る取引はどれか。
- Shadow による保証 ── 触らずに観て検証する。
- 型の標準化 ── 判った事を、使い回せる取引の型にする。
- 選んで展開 ── その型が実際に移せる所にだけ。
会社をまたぐ使い回しは、実装されるまでは候補です。それまで DM11 は「実証済み」とは書きません。グループでの関わりの価格も決めていません。
この要約が書いていない事
この種の文書がたいてい書いて、これが書かないもの。
- 投資対効果の数字はありません。本番で何も測っていないので、書けば作り話になります。
- 市場規模もありません。そちらで効くかどうかを何も言わないからです。
- 顧客の事例もありません。顧客が居ないからです。
- そちらの事業会社にこの問題が在る、とは書いていません。在るかどうかを確かめる事が最初の価値で、それはこちらではなく、そちらの運営者への問いです。
- 限定も、残席も、期限もありません。
次
記録系を持つ人が同席する、1 度の会話。
次に役に立つのは、記録系に責任を持つ人 ── CIO・COO、あるいは既に進んでいる変革の担当者 ── が同席する短い会話です。当てはまるかどうかを見極めるには 15 分で足ります。
当てはまらないなら、それは本当に役に立つ答えで、以後お送りしません。
法人のアドレスから、想定している事業会社または変革の名前を添えてお送りください。dm11holdings@gmail.com から返信します。
DM11 Holdings（札幌）。この要約の数字はすべて /evidence/reality-receipt.json の受領書から読んでいます。裏付けの技術資料は /transaction-assurance に在ります。