AIで成果は増えた。自分は何を学んだのか　#3

悪循環3：次の担当者による調べ直し

　対応件数は右肩上がり。なのに、同じ原因を毎回一から調べている。これは組織でも起こる食い違いです。

　似たトラブルが再発したとき、以前の記録は検索されたでしょうか。手順が残っていても採用理由がなければ、今回も使えるとは判断できません。外した候補、途中の誤り、急ぐと抜けやすい確認。次の担当者が知りたいのは、結論に至るまでの情報でもあります。

　似たトラブルのたびに調査をやり直すと、対応を終えて過去の記録と比べる時間が減ります。比較をしないままなら次の再発でも使える記録が見つからず、また調べ直します。AIでその場の対応が速く終わっても、空いた時間をすべて次の対応へ回せば、記録を整理する時間は取れません。

　記録を残しても、それを読めば同じ判断ができるとは限りません。言葉で説明して人に伝えられる知識と、経験の中で身につく見分け方には違いがあります。後者は暗黙知と呼ばれます。熟練者がプログラムのわずかな違和感に気づく力は、設計原則を読んだだけでは身につきにくいです。

　実際の変更と失敗だけでなく熟練者の実演、対話、模擬練習も学習の機会になります。ただし、どの方法でも、自分の予測と結果を比べなければ、「これは危ない」という判断基準が残ったかを確かめられません。

　調べ直しを減らすには、次に記録を使う場面から考えます。タスクを終えたら次の3つの観点で記録を短く残し、どんな兆候が出たら読み返すかを添えます。

• 何が問題だったか
• 自分は何を予測したか
• 結果とどこが違ったか

　月に一度、似た対応を並べる場合も、記録を増やすことより次に使えるかを確かめます。条件が同じなら、次の担当者も以前の調査を使えるでしょうか。記録は検索されているのに調査のやり直しが減らないなら、記録の有無ではなく扱っている条件の違いや説明の不足を調べます。

　個人が学んでも、チームが同じ失敗を続ける場合があります。障害対応の記録に注意点が追記されても、次の担当者やAIが最初に読む対応手順へ届かなければ、同じ確認が抜けます。詳しい人がその都度補えば復旧は進みますが、手順を直す時間を配らない理由にもなり得ます。対応件数だけを評価すると、共通部分を更新する仕事より、再発した問題を速く片づける仕事へ時間が戻ります。

　そこで、記録を残した後に誰が現行手順へ反映できるかまで確かめます。手順を管理する人が同じ条件で繰り返された抜けを読み、何を変更し、次の担当者がどの版を使ったかを追います。自分に変更権限がなくても、同じ説明を何度補ったかと、そのとき参照した手順は残せます。

　更新後の手順が使われても同じ調査が必要なら、手順への反映漏れだけでは説明できず、障害の条件や確認方法の違いを調べ直します。振り返りを書いたことと、次の人が同じ失敗を避けられることの間には、共通の手順を変える仕事があります。

　同僚と結論が食い違うなら、同じ元データを見て採用理由を比べます。数字の読み違いか、重く見る利用者の違いか。AIの説明に各自が納得していても、前提がそろっているとは限りません。そこで見つかった未確認の条件を次の資料でも確かめれば、個人の振り返りを共同作業の判断へつなげられます。

次の熟練者が判断を学ぶ機会

　学習の問題を若手がAIに頼りすぎる話だけで終えると、仕事を配る側が見えなくなります。エンジニアにとって調査の整理、障害報告の初稿、関係者への説明は判断を試す入口でもあります。

　その工程を自動化して難しい例外だけを人へ戻すとします。入口の仕事を経験しないまま例外を任される人は、その間の判断をどこで練習するのでしょうか。「自分で考えてほしい」と言う側が、考えて結果を確かめる仕事を渡しているかも問われます。

　たとえば障害報告なら、AIが作った文章を全部書き直させる必要はありません。実際の記録から一件選び、AIが作った文章と経験者の文章の二つを見比べられます。比べるのは、どこまで影響が確認できているか、どの情報が欠ければ断定を保留するかです。

　AIには説明の候補を出してもらい、利用部門が次の対応を判断できる内容かを確かめます。支援によって、以前なら一人では整理できなかった事例を学習材料にできる面もあります。

　この時間を勤務時間の外へ追い出すと、今日の処理件数だけが評価される仕組みは変わりません。仕事を配る人が対応を終える時間と、判断を確かめる時間の両方を確保します。経験者の確認に待ち時間が集中するなら、共通の事例を一緒に扱う場や、判断理由を再利用できる記録も必要です。次の似た報告で、支援を受けながらでも不足情報に気づけるようになったかを見ます。

　熟練者の仕事が速く終わっても、新人が判断を練習する時間まで増えるわけではありません。

三種類の負債と対処

　コードを直せば済む問題と、人の理解や記録を補う必要がある問題は対処が異なります。Margaret-Anne Storeyは、三種類の負債を区別しています（原論考、2026年）。処理をやり直す再試行の設計なら、次のように分かれます。

Margaret-Anne Storeyによる三種類の負債

負債	どこに問題が残るか	対処の例
技術的負債	プログラム。同じ処理が複数箇所にあり、変更を妨げる	重複した処理を整理する
認知的負債	チームの共有理解。再試行で処理が重複する条件を見通せない	予測を比べ、実際に試す
意図の負債	目的や理由の記録。待ち時間を短くした理由が残っていない	利用者の条件や過去の障害を調べ、確認できた理由を残す

　一つを直しても、残る二つまで解消したとは限りません。

　「理解負債」は後払いの比喩で、この三つと一対一には対応しません。一人が説明できなくても詳しい人をたどり、チームで確かめられるなら状況は異なります。また、意図の負債は理由が残っていない状態であり、先送りを意識して選んだかどうかとは別です。現在の動作からAIが説明を作れても、それだけでは過去の採用理由を取り戻した証拠になりません。