成果物が形になってきた頃、自分でそれを読み返していて、ふと不安になった。
「この数字は、どこから出たんだったか」。自分で作った仕組みなのに、結論だけを見ると、なぜそうなるのかが追えない瞬間があった。作った本人が追えないものを、買った人が信じられるわけがない。根拠を、残さないといけないと思った。
結論だけでは、信じてもらえない
有料の成果物は、稟議や、社内の説明に使われる。
「AIがこう言いました」では、通らない。上司に出すなら、なぜその効果見込みなのか、どの前提で計算したのかを、説明できないといけない。結論の数字だけが立派でも、根拠が辿れなければ、ただの占いと同じだ。むしろ立派な数字ほど、根拠を問われる。
実際、ある利用者から「これ、社長にどう説明すればいいですか」と訊かれたことがある。数字は出せても、その一言に詰まるようなら、まだ売り物になっていない。根拠は、おまけではなく、商品の一部だった。
判断のそばに、根拠を貼る
そこで、一つひとつの判断に、根拠を貼り付けることにした。
この結論は、どの回答から来たのか。どの資料の、どこを見たのか。どの計算式で出したのか。それを、結論と一緒に持たせる。後から「なぜ」と訊かれたら、その場で示せる。AIに「それっぽい理由」を書かせるのではない。実際に使った入力と式を、そのまま残しておく。
推定と、事実を分ける
もう一つ、こだわったのは、推定と事実を混ぜないことだ。
資料で確認できたことと、こちらが仮に置いた数字は、性質が違う。なのに、同じ顔で並べると、全部が確かなことのように見えてしまう。だから、これは資料で確認した事実、これはこういう仮定の上での推定、と分けて書く。仕様化の成果物では、資料がなければ、その分は売らずに、診断や手前の商品に戻すことにした。確かでないものを、確かなふりで売らない。
根拠は、次の商品にもつながる
根拠を残し、推定と事実を分ける。これは、その成果物一つのためだけではなかった。
判断のための稟議資料も、実装のための仕様書も、結局は「何が確かで、何が仮定か」がはっきりしているほど、使える。仕様の成果物なら、確認できた事実と、置いた仮定を分けて書いてあれば、それはそのまま、外注や自社実装への指示書になる。根拠の整理は、後の工程の質を、まるごと引き上げた。
出す前に、品質を検査する
根拠を残したうえで、納品の前に、もう一段の検査を置いた。
必須の項目がそろっているか。根拠がついているか。効果の式と仮定が示されているか。出してはいけない表現が混じっていないか。この検査を通らないものは、顧客に渡さない。通らなければ、いったん作り直す。それでも駄目なら、返金の列か、人の確認に回す。
手間はかかる。でも、人が一件ずつ目視しない以上、検査の網は、仕組みで持つしかない。根拠を残し、推定と事実を分け、品質を検査する。この三つで、無人でも「なぜ」に答えられる成果物にした。
次の回は、その判断を、後からそっくり再現するための、版の固定について書く。