宿題の答え合わせをしたら、直っていたのは「機械で直せるところ」だけだった話

困ったこと

6週間前に「直すべき所が10個ある」と書き残した大きな道具箱の点検を、答え合わせとしてやり直した。あいだに改良は44回も積まれていた。ところが同じ物差しで数えてみると、絡まった配線（お互いを呼び合って抜け出せない設計）も、数字が古いままの説明書も、まったく動いていない。宿題の半分以上が、ずっと凍ったままだった。

どう解決したか

原因はやる気ではなく、仕事の種類だった。動いていたのは「道具に任せられる作業」——部品の規格チェックを通す、要らない物を箱の外へ出す。止まっていたのは「考えないと直せない作業」——設計の見直しや説明書の書き直し。判断が要る物は、9個の隣に並べてあるだけで埋もれてしまう。そこで方針を変えた。機械で直せるところを先に全部片付け、考えどころは単独の宿題カードとして別に置く。さらに「見ない場所」を決めていなかったせいで棚の裏に隠れていた、外部製の部品の山（44万行ぶん・箱の中身の約7割）も発見した。

何が変わったか

点検が「感想」から「答え合わせ」になった。前回指摘した所を同じ物差しで再測定するので、「直したつもり」が数字で割り切れる。改良を重ねた直後に測り直したことで、「前回の点検が書いた強み」にも条件が付いたと分かった——全体を見ているつもりが、直前の変更だけしか見ていなかった。点検は一度やったら終わりではなく、前回の結論ごと疑って測り直すのが正解だと学んだ。

<details> <summary>▶ 技術的にどう作ったか</summary>

• 対象: Python製エージェントフレームワーク（NexusCore）の差分レビュー。前回（2026-08-12）の包括レビュー10件の消化状況を、44コミット後に同一メトリクスで再計測した
• 手法: git追跡ファイルのみを分母に除外確認（4,658→1,383ファイル）→ 自作AST走査で循環依存・循環的複雑度・docstring率を計測 → ruff/mypy/pytest/pip-audit を実走し生exit codeで記録（計測前にexit codeの校正を実施し、偽0を排除）
• 結果: 機械的是正（CIへの静的解析配線・生成物の追跡解除・層違反import 20→0）は進行。一方で構造系（循環依存5組・層逆流28エッジ・README乖離の拡大）は数値が完全に同値。新規に、依存ライブラリ442,980行がgit追跡下・既知脆弱性4件・CI対象外のコードにlint違反1,160件を発見
• 学び: 差分レビューでは「前回の強み」も検証対象に含めるべき（秘密情報スキャンがpush差分の2コミットしか見ていなかった実測例）。起点になったのはレビュー用スキルの「既存レビュー検出」フェーズで、過去レビューの存在に気付いて差分方式へ切り替えられたこと
• 記録: 詳細な作業記録は個人ナレッジベースのNexusCoreプロジェクト配下（2026-08-29差分レビュー）に保存

</details>