積み残しの一覧化から始めて、粒度を分けたコミットで締める一日

この日は、同じ支援先向けのプロジェクトで7回セッションを開いた。 そのうち3回、最初に打ち込んだのは作業指示ではなく「積み残しを列挙してください」だった。

自分の頭のなかにも残件のリストはある。 ただ、それが当てにならないことを、この日のうちに確かめることになった。

積み残しは、記憶ではなく進捗ドキュメントから出させる

積み残しの正本は、日付ディレクトリの下に置いた進捗ドキュメント1本にしてある。 新しいセッションを開いたら、まずそれを読ませてから一覧を出させる。

返ってきた一覧にこちらから訂正を入れた。 「資料の受領待ち」として残っていた工程は、実際にはもう受け取り終わり、スキルに落とすところまで済んでいた。 ディレクトリを見ればわかるはずだと伝えて、実態に合わせてドキュメントを直させた。

この直しが入って初めて、その日の最優先が次のフェーズの実地検証だと確定する。 一覧を出させる目的は、思い出すことではない。 記憶と記録がどこでずれたかを見つけることにある。

資料は丸ごと落とし、地図を作り、原本は動かさない

クラウドの共有フォルダに置かれた資料一式を、ローカルの作業ディレクトリへ落とさせた。

量が多いので、画像しか入っていなければ文字起こしが要ると身構えていた。 落ちてきたものはどれもテキスト層を持っていて、抽出は数秒で終わった。

そのぶん、手元のディレクトリは増えた。 どこに何があるかを自分でも言えなくなったので、ローカル全体の内訳を1枚の地図に書き出させた。

整理を頼むときには、条件を1つ付けた。 削除はしない。 アーカイブ用のディレクトリを作って、そこへ移すかコピーするだけにする。 中身を確かめて捨てるのは自分の手でやる。 結果として履歴の上でも削除は1件も出ず、すべて移動として記録された。

計画書はパスで渡さず、画面に出す

計画書ができたと報告されたとき、こちらは手元でファイルを開ける状態になかった。 ブラウザで立ち上げておいてほしいと頼んで、前面のタブに出させた。

読める状態になって、ようやく判断が進む。 成果物の置き場、資料をどこまで読み解くか、フェーズをいくつに割るか、裏取りをいつやるか。 その場で4件決めた。

続けて、今回のゴールを口で伝えた。 面談の内容を音声で記録し、それを文字にして渡すところが入口になる。 そこから業務システム側の記録を更新するのが出口になる。

出口の話をした時点で、資料の読み解き方が変わった。 入力する項目だけを拾えばいいと思っていたが、取り出せるデータの範囲も同時に調べる必要が出てきた。 計画書は書き直しになった。

計画書を清書だと思っていると、この書き直しは手戻りに見える。 合意の記録だと思えば、ゴールが言葉になった時点で更新が入るのはむしろ正常な動きになる。

開きにくい形式は、閲覧用に変換して逃がす

受け取った資料の一部は、いま使っている Mac では開くのに手間がかかる形式だった。 中身が読めればいいだけなので、一時的なビューアを作らせてブラウザに出させた。

最初に出てきたものは使えなかった。 ページを画像に変換して並べる作りになっていて、その変換の途中で日本語のフォントが当たらず、記号と数字しか残っていない。 これはこちらが指摘する前に、Claude Code の側から気づいて報告が来た。 画像をやめさせて、文書から起こしたテキストのほうを本体に据え直させた。

同じ日の夜、この経験がそのまま別の工程につながった。 提出物の形式は変えられないので、いつかはその形式に戻さないといけない。 そこで、文書を HTML に変換して、以後は HTML の側を更新の本体にする形を試させた。 提出用のファイルは、必要になった時点でそこから生成し直す。

分かったことは2つある。 埋め込まれた画像14点のうち2点は変換の通らない形式で、注記に置き換わった。 そして、参照用の文書を渡さずに生成すると、日本語のフォント指定が丸ごと落ちる。 この2点を含めて、手順をスキルに固定した。

止まった処理は、続きから動かす

夜にセッションを開いたら、前の作業が途中で止まっていた。 続けてほしいと一言だけ送って再開させた。

もう1件、長いレビューを任せていたサブエージェントが接続のエラーで途中終了した。 このときはやり直させず、まず成果物の現状を確認させた。 出力は 53KB まで書けていたので、残りの項目だけを指示して続きから走らせ、最終的に 126KB まで伸びた。

中断が起きること自体は避けられない。 途中経過がディスクに残る形にしておけば、中断は事故ではなく一時停止で済む。

下書きを作る前に、項目と出どころを対応させる

素材から下書きを生成する工程に手を付けた。 いきなり生成させず、手前に2段はさんだ。

まず、完成物に必要な項目を全部洗い出させる。 次に、その項目がどの書類に載っているかを1件ずつ対応させた表を作らせる。

作らせてみると、2つの項目が対象の文書に入っていなかった。 どこにあるかをサブエージェントに探させたところ、提出物一式のうち別のファイルに含まれていた。 表を直させた。

こちらから落とした行も1つある。 ある項目は手元の別の書類を見れば足りるので、わざわざ証明書を取り寄せる必要はない。 対応表が埋まった時点で、下書きの生成は判断ではなく作業に変わる。

音声からの更新は、渡し方を先に決める

音声から記録を更新する工程の想定が、計画書と食い違っていた。

音声ファイルをそのまま渡す前提で書かれていたので、そこを直させた。 実際に流すのは、音声を文字にしてから渡す形にする。 文字を受け取った側が議事録と記録の下書きを作り、その内容はその場にいた人が確認してコメントを返す。

この訂正は1か所では終わらなかった。 図と段取りと決定事項の3か所に同じ話が書いてあり、うち1か所は逆の意味になっていた。 直させたあと、同じ意味の表現が他に残っていないかを検索させて潰した。

一日の終わりは、粒度を分けてコミットする

締めの指示はいつも同じにしている。

コミットだけはやっといてください。適切な粒度で全部。

未コミットが16件あった。 テーマ別に振り分けさせて、6つのコミットに分けて記録させた。 push はしない。

最後に、翌日やることを3本立てで書き残させた。 どれも、どこから再開するかまで書いてある。

今日固まった進め方

• 着手前に積み残しを列挙させる。狙いは思い出すことではなく、記憶と記録のずれを見つけること
• 計画書はパスで渡さず、画面に出してから判断する
• 原本は消さない。移動とコピーだけにして、捨てるのは自分の手でやる
• 中断は前提にする。途中経過が残っていれば、続きから走らせられる
• 一日の終わりに粒度を分けてコミットし、翌日の再開地点まで書いておく

翌日の3本立ては、翌朝の自分ではなく、翌朝のセッションが読む。 書いた本人が説明しなくても動き出せる書き方になっているかどうかは、明日の朝に一覧を出させたときにわかる。