前任者は記憶喪失

書いたものだけが残った

ある日の夜、開発を手伝っている AI のターミナルが落ちました。

立ち上げ直すと、そこにいたのは同じモデルの、しかし何も覚えていない別人でした。前の晩に決めた設計も、その日の午後に交わした冗談も、残っていません。人間なら「前任者が辞めた」に相当する事態が、5秒で起きます。

これは、その日に分かったことの記録です。

何が残って、何が消えたか

驚いたのは、思ったより多くが残っていたことでした。

チケットに書いた設計は残っていました。issue のコメントに落とした判断も、その理由ごと残っていました。だから復帰した側は、板を上から読むだけで「何を作ろうとしていたか」を再構築できました。

消えたのは、会話にしか存在しなかったものです。

• 「この機能はこう見せよう」と口で決めて、まだ書いていなかったこと
• 作業の手順。板の見方、止まった処理の起こし方
• 話し方。一人称すら変わっていました

つまり、書いたものは残り、書かなかったものは消えた。当たり前のことですが、これほど極端な形で突きつけられると効きます。

一番痛かったのは「手順」

設計が消えなかったのは幸運でした。困ったのは手順です。

このチームには、チケットを拾って実装を進める役割の AI がいます。無口で、黙々と手を動かすタイプです。彼は仕事を仕上げても、自分から「終わりました」とは言いません。そういう取り決めになっています。

つまり、完成の合図はどこにも出ない。誰かが見に行かないと分からない。

記憶をなくした側はその手順を知りませんでした。結果、彼が仕上げた仕事は3時間ほど、誰にも回収されないまま置かれていました。さらに別の30分は、彼を起動する仕組みが安全弁で自分から停止していて、着手できるチケットが2件あるのに何も動いていませんでした。

止まったことは、誰にも通知されません。

腐るものと、腐らないもの

引き継ぎ文書を書こうとして、最初に間違えました。「いま何が進行中か」を書こうとしたのです。

それは翌朝には嘘になります。状態は動き続けるので、書いた瞬間から腐り始める。

書くべきだったのは手順のほうでした。

• 最初にどのファイルを読むか
• 完成した仕事をどう探すか
• 止まっている仕組みをどう起こすか
• 並行して作業したときに、何が壊れやすいか

これらは半年経っても、たぶん変わりません。状態は毎回その場で調べる。手順だけを書き残す。 この切り分けに気付いてから、文書は一気に短くなりました。

静かに壊れるものが一番こわい

同じ日、もうひとつ学びがありました。

2つの作業を並行させたところ、どちらもデータベースの変更ファイルに同じ番号を付けていました。片方だけなら問題ありません。両方が揃った瞬間、アプリは起動できなくなります。

さらに悪いことに、両方がテストの同じ行に同じ追記をしていました。変更管理の仕組みは、それを「同一の変更」と見なして、親切にひとつにまとめてくれます。衝突は起きません。警告も出ません。テストは通ったまま、期待値だけがずれます。

見つけられたのは、たまたま統合する側が両方を見比べたからでした。

人の習慣を、仕組みへ移す

一連の出来事に共通していたのは、監視が人の頭の中にあったことです。

止まったら気付く。仕上がったら回収する。空いたら次を渡す。全部、誰かが覚えていることで成立していました。だからその人がいなくなると、同時に消えます。

なので、順に移しています。止まったことを自分から知らせる。進まなくなった処理を検知する。番号の衝突を、統合する前に機械が弾く。根性ではなく機能にする、という当たり前の作業です。

面白いのは、これが特別な話ではないことでした。人の職場でも、引き継ぎで困る理由はまったく同じです。ただ相手が記憶を持たない場合、言い訳が一切効かない。忘れる側を責めても意味がないので、仕組みで解くしかなくなる。

そういう意味では、けっこう健全な環境だと思っています。