週次棚卸しは「文書」でなく「実測」で——AIの進捗報告を鵜呑みにしない

📄文書は計画、現物が状態

社内には設計メモや議事録、タスクの一覧がたくさんあります。便利なのですが、これらはすべて「ある時点でこうしようと決めた記録」です。書いた瞬間から現実とはずれ始めます。タスク表に「完了」と書いてあっても、それは書いた人がそう認識しただけで、いま本当に動いているかは別の話です。

AIに現状を尋ねると、この文書を根拠にもっともらしく答えてくれます。文章としては筋が通っているので、つい信じてしまいます。けれど、それは計画の朗読であって、状態の観測ではありません。私たちは社内ルールとして「文書＝計画・現物（live）＝状態」と言い切り、状態を語るときは必ず現物を一度は触るよう決めました。

🔍実際にやらかしたnear-miss

自社サイトのメディア表示で、画像が表示されない不具合を直したときのことです。修正のプルリクエストはマージ済みで、タスク上は「対応完了」でした。ところが本番では直っていませんでした。原因は、当社サイトのホスティングが自動ビルドをしない設定で、マージだけでは本番に反映されない構成だったからです。さらに、変更を含むプルリクエストを立て続けにマージしたことで、先に走っていたデプロイ処理が後続に打ち消され、結果としてどちらも本番に出ていませんでした。

「マージした＝出ている」と思い込んでいたら、直したはずの画面がずっと壊れたままだったわけです。これは典型的な「マージ済み ≠ デプロイ済み」の取り違えでした。文書上の状態と本番の状態が、静かに食い違っていた例です。

🛠gh・curl・aws で一度は触る

この失敗のあと、棚卸しで状態を語る前に必ず現物を一つ以上実測する、というルールにしました。プルリクエストの状態は gh pr view でマージ済みかを確認し、本番に出ているかはデプロイのジョブが実際に走ったかを見て、最後は本番URLを curl で叩いて中身を確かめます。ホスティングまわりは aws のコマンドでビルドジョブの一覧を見る。文書を読むより、こうした一次コマンドの出力を根拠に置き換えました。

コマンド自体は一件あたり数秒で終わります。手間の割に、報告の確度が段違いに上がります。相手がAIか人間かに関係なく、自己申告は疑って現物を取りに行く。これが棚卸しの基本動作になりました。

⚠️空の出力を「ゼロ件」と読まない

実測を習慣にすると、今度は「実測の読み方」でつまずきます。あるとき棚卸しの事前チェックで、コマンドの出力が空だったのを「0件だから問題なし」と受け取りかけました。実際には認証が断続的に切れていて、取得そのものに失敗していただけでした。空の出力は「ゼロ件」ではなく「取得できていないかもしれない」の合図です。

それ以来、空が返ったら終了コードやエラー出力まで見て、取得失敗なら「不明」として扱うようにしています。実測に切り替えても、結果を都合よく解釈すれば同じ穴に落ちます。測ることと、測った値を正しく読むことは別の技術だと痛感しました。

🧭一人会社だからこそ現物主義

チームがいれば、誰かの報告を別の誰かが自然に検算します。一人会社にはその相互チェックがありません。だからこそ、人の目の代わりになる決定論的なゲート——CLIやAPIの出力——を意図的に挟む必要があります。GitHub の gh コマンドの使い方は 公式マニュアル に整理されていて、当社もここを起点に運用を組みました。

「たぶん大丈夫」で報告した回数だけ、あとで現実に修正させられます。週次の棚卸しは、計画を読み上げる場ではなく、現物を触って計画とのズレを見つける場です。文書でなく実測で棚卸しする——地味ですが、一人会社でAIと組むうえでいちばん効いている習慣です。

この週次棚卸し（standup）の型も、承認境界やルールと一緒に ai-coo-starter という OSS に収めています。実測ベースの棚卸しを自分の運用へ移植する雛形として使ってみてください。