頭の中にある判断を、製品の側に移す。言うのは簡単だが、いざやろうとすると、自分が何を基準に決めているのかが、まるで言葉になっていないことに気づいた。
「この案件は受けていい」と私は一瞬で判断する。でも、なぜそう思ったのかを書き出そうとすると、手が止まる。長年の勘で決めていたものを、ルールに翻訳する。そこからの作業だった。
まず、判断を四つに分けた
事業に残っていた判断を並べて、四つに整理した。
受注していいか。出力をお客様に出していい品質か。いくらで、どこまで提供するか。次に何を提案するか。
この四つを、それぞれ「人が決める」から「製品が決める」に移せるかどうか、一つずつ検討した。全部をいきなり移すのは無理だ。移せる判断と、当面は人に残す判断を分けるところから始めた。
勘を、条件に書き下す
いちばん時間をかけたのは、自分の勘を条件文に直す作業だった。
たとえば受注の可否。私は無意識に、業種、相談内容の具体性、予算感、緊急度、過去に似た案件で苦労したかどうか、といったものを見ていた。それを一つずつ取り出して、「この条件ならそのまま進めてよい」「この条件なら一度止めて確認する」という線を引いていく。
最初に引いた線は、たいてい粗かった。実際の入力を通してみると、明らかに変な結果が出る。そのたびに条件を直す。これは、自分の判断を外から眺める作業でもあった。十数年やってきた決め方を、初めて他人に説明できる形に並べ直した感覚だった。
数字は計算させない
判断を製品に移すとき、はっきり線を引いたことがある。文章や説明はAIに任せるが、金額や工数の計算はAIにやらせない。
削減できる時間や費用は、お客様から聞いた実数をもとに、決まった式でプログラムが計算する。AIがやるのは、その数字が「なぜそうなるのか」を言葉にすることだけだ。数字とAIを混ぜない。これは第1部でも触れた、信頼を守るための土台だった。
判断の自動化でも、この線は効いた。「受けていいか」の判断には、しばしば金額や規模が絡む。そこを曖昧なAIの感覚に委ねると、結果がぶれる。だから判断に使う数字は決まった計算で出し、その数字を条件に当てて可否を決める。判断のうち、計算でできる部分と、文脈の読み取りが要る部分を、はっきり分けた。
知識ベースに、順序と優先順位を持たせた
もう一つやったのは、診断士としての知識を、製品の中に置くことだった。
AIは一般論なら何でも答える。けれど「どの業務から手をつけるか」「同じ課題でも、この会社ならどの順序が現実的か」という判断は、一般論では出てこない。そこには現場で積んだ順序と優先順位の感覚が要る。
そこで、自分が大事にしている考え方を、いくつもの小さなまとまりにして製品に持たせた。AIはそれを下敷きにして答える。ただのAIの回答ではなく、私の方法論を通した回答になる。しかも、その答えがどこから来たのか、お客様が入力した数字なのか、私の方法論なのか、外部の一般論なのかを、区別して示すようにした。根拠の出どころが見えると、判断は信用される。
全部は移さない、と決めた
ここで一つ、自分にブレーキをかけた。判断を全部、製品に移そうとしないことだ。
高額で、影響が大きく、前例のない案件。こういうものまで製品に決めさせると、いつか大きく外す。だから移すのは、件数が多くて、型がはっきりしていて、外しても傷が浅い判断に絞った。残りは人に置く。ただし「毎回」ではなく「例外のときだけ」人が出る形にする。
判断を製品に移すというのは、人を消すことではなかった。製品が普段を回し、人は例外を引き受ける。その線をどこに引くか、という設計だった。
次の回は、その「例外のときだけ人が出る」を、品質チェックでどう作ったかを書く。毎回のレビューをやめる、という勇気のいる決断の話だ。