熟練者の「なんとなく」を、
どう実装するか。

例えば、ある見積書を読んだ経験者が、少し手を止めます。数字の誤りはありません。それでも、短い納期と外部への依存が重なる箇所に、確かめたいことがあります。この仮想の場面から、判断知の継承を一緒に考えてみましょう。

その「なんとなく」を引き出すには、結論に至る手前をたどる必要があります。どこを先に読み、何と何を組み合わせて見たのでしょうか。どの条件が変われば、別の判断になるのでしょうか。正解だけでなく、気づきが生まれる順序まで、対話を通じてたどります。

違和感を、確かめられる問いへ。

「外部依存が多いから危険」と一行にまとめると、肝心な文脈が消えてしまいます。依存先の返答時期が読めないのでしょうか。それとも、遅れを吸収する余地がないのでしょうか。担当者が気にしていることを、具体的な確認項目に分けていきます。

この例なら、「納期の起点は合意されているか」「相手からの情報提供が遅れた場合、どの作業が止まるか」と尋ねることができます。問いと一緒に、そう考えた記載や過去の例を残します。次の担当者は、結論を受け取るだけでなく、自分の案件との違いを確かめられます。

AIに渡す仕事を、具体的にする。

このスタディでは、AIの役割を、共有が認められた記録から比較材料を集め、相違点と不足情報を整理するところに置きました。「似ている」という結果には、根拠の箇所を添えます。見つからなかった条件は、推測で埋めず、確認すべき項目として人に返します。

引き受ける条件を決めるのは担当者です。その判断と理由、実際に起きたことを記録できれば、次の案件で比較する材料が増えます。こうした蓄積は、経験を固定するためではなく、新しい状況に合わせて問いを更新するために生かしていきたいと考えています。

設計は、何を残すかの選択でもある。

今回は、案件を一つの点数で示す構成を採りませんでした。まず、何を比べているかを読めることを優先したためです。一方、比較材料が多すぎれば、確認の負担が増えます。どの粒度で示せば役立つのかは、実際の担当者と検証する必要があります。

検証では、重要な相違点を拾えたか、根拠が正しいか、不明点を不明のまま示せたかを確かめます。加えて、担当者が判断を説明しやすくなったかも確認します。人の経験とAIの実装をつなぐ仕事は、その確かめ方を設計するところから始まります。

残したいのは、
次の人が考え始められる手がかりです。