確認は承認ではない
問題を一文で言うと： 問題のない確認結果が「進めてよい」という意味で読まれ、後から誰が決めたのか説明できなくなる。
原則
確認が答えるのは、「これは妥当か、何が未解決か」です。
承認が答えるのは、別の問いです。「これを進めてよいか、誰がそれに責任を持つか」。
この2つは、たいてい別の人が、別のタイミングで、別の権限にもとづいて答えます。前者への「問題なし」は、後者への答えにはなりません。
構造
| 確認 | 承認 | |
|---|---|---|
| 問い | 妥当か。何が未解決か | 進めてよいか。誰がそれに責任を持つか |
| 担当 | 作成者以外の人 | その種類の判断について権限を持つ人 |
| 成果 | 所見と未解決の論点 | 記録された判断 |
| 対象 | 実際に読んだ版 | 実際に承認した版 |
| 失効 | 確認した対象が変わったとき | 承認した対象、または前提にした条件が変わったとき |
順序は固定で、各段階がそれぞれの記録を残します。
- 作業を用意する ── 人、ベンダー、またはAIが用意する。
- 確認する ── 1つの版について、所見と論点を残す。
- 承認する、またはしない ── 同じ版について、権限を持つ人が判断する。
- 実行する ── 変更を行う人が、2と3がまだ有効かを確かめる。自分で判断を足さない。
- 結果を読み戻す ── いま実際にある状態を、承認した状態と照らし合わせる。
使う場面
- 確認者の「問題なし」が、実行の合図として読まれている。
- AIやベンダーが作業を用意し、人が「チェックする」ことになっている。
- 承認が、文書の名前に対して記録され、版に対して記録されていない。
- 既存の承認が、何が起きたら効力を失うのか、誰も言えない。
- 権限を持つ人が、変更を実行できる唯一の人でもある。
よくある失敗
確認を承認として扱う。 「確認済み」が、誰も問うていない問いを閉じてしまいます。確認者は妥当かどうかに答えただけで、進めてよいかには誰も答えていません。
動く対象を承認する。 承認の後で、修正や差し替え、ベンダーの新しい版などにより対象が変わります。承認は名前に結びついていて読んだ中身に結びついていないため、黙って引き継がれます。
権限が実行に吸収される。 判断する権限を持つ人が、すべての変更を自分で実行する人でもあるため、時間を節約しようとして2つがまとめられます。判断が別に記録されなくなり、記録には「何かが起きた」ことしか残りません。
実装のメモ
- 記録を1つにせず、確認の所見と承認の判断を別々に残す。
- それぞれの記録を、対象の版に結びつける。その版が変わったら両方とも無効にし、新しい版で確認からやり直す。
- 承認がまだ有効か分からないときは、承認されていないものとして扱う（fail closed）。
- 権限を持つ人が、自分で変更を実行しなくても承認できるようにする。実行する人は、条件を機械的に確かめ、判断し直さない。
- 変更の後で結果を読み戻し、到達した状態が承認した状態であることを記録する。
どれも新しい仕組みは必要ありません。たいていは、いまある文書、チケット、承認の手順で実現できます。変わるのは、それぞれの記録が何を意味してよいか、です。
関連
Practice Note「AIに任せると、仕事の設計が問われる」は、このプロトコルが前提にしている受け入れ条件そのものを扱っています。また、AI出力の受け入れ条件と確認者が決まっているかは、AI Operating Model Diagnostic Kit が直接扱う問いの1つです。
Fragment Practice が扱っていること
Fragment Practice が扱うのは、実際の仕事のなかで、確認・承認・実行がどこにあるかです。誰がどの版を確認するのか、進めてよいという権限を誰が持つのか、何が起きたら承認が効力を失うのか。承認を代わりに引き受けることも、変更を実行することもしません。