企画レビューで前提が2つ崩れた — レシートOCRのシリーズ案をシーケンス図に描き直す
自分の企画書を画面でスクロールしていて、最初に赤を入れたのは記事の並び順ではなかった。「写真1枚に複数のレシートが写り込んでいる場合は、まず画像を1枚ずつに切り分ける」という一行だ。
ここが違う。
レビューの場は、ローカルに立てた決裁フォーム
note第1弾のシリーズ企画は、マークダウンで書いた計画書をHTMLに変換し、ローカルサーバーで立てて読んでいる。判断が必要な項目には3択ボタンが埋まっていて、読んだ流れでそのまま答えられる。今日はそのHTMLを上から読みながら、気づいた点を口で伝えて、計画書のほうを直させていった。
途中で手が止まった。27項目ある企画書を、上下に往復しながら読んでいる。目次が欲しい。
ただ、計画書のプレビューに使っている共通CSSは他の計画書も全部読んでいるファイルなので、ここを書き換えられると過去の計画書の見た目まで動く。既存には触らせず、目次用のCSSを新規で1枚足させた。右側に27項目が並んで、本文と重なっていないことを画面で確かめてから続きに戻った。
指摘1 — 手順ではなく、前提が古かった
企画書のOCRの節には「複数枚が写り込んだ写真は、分割してから読ませる」と書いてあった。分割が難しいケースの回避策で記事を1本立てる構成にもなっていた。
自分が試した範囲では、この前処理は要らない。最近のマルチモーダルのモデルは、レシートの境界がはっきりしていれば、1枚の写真に4枚写っていても4件として読み分ける。切り分けの工程を挟む理由がない。
これは実装の細部ではなく前提なので、直る範囲が広い。該当箇所を4か所書き直させた。「分割してから読む」という手順が消え、「分割が難しいときの回避策」だった記事の枠が、「いろいろな写り方の写真をどう読ませるか」という別の記事に変わった。
企画書の誤りは、たいてい手順ではなく前提のほうに居る。手順の誤りは文を直せば済むが、前提の誤りは記事の本数を変えてしまう。
ネタ元を実務から引く前に、禁止事項を先に決めた
記事候補が机上の想像に寄っていたので、実務処理を置いてあるリポジトリを読ませることにした。どの帳票をどの道具でどう通しているかは、そこに全部ある。いちいち口で説明するより読ませたほうが早い。
ただしそこは、顧客の実名がディレクトリ名になっている場所だ。読ませる前に前提を1つ立てた。記事には実名も金額も一切使わない。抜き出すのは処理の型だけ。 「どの種類の帳票を、どの道具で、どの順に通したか」だけが記事に出ればいい。実務の中身は記事に持ち出さない。
読ませてみて、いちばん効いたのは新しい発見ではなかった。数か月前に自分で作ったAI活用事例の棚卸し資料が、そのまま記事候補の母集団になっていた。用途欄には「ブログ連載の記事お題候補」と自分の字で書いてある。仕込んだことを忘れていた。
抜き出した処理の型を、部品のカタログとして計画書の §9 に書き込ませた。20本強ある。ここで企画の性格が変わった。読ませる前の候補は「たぶん誰かが困っているはず」で立てた想像だったが、書き込まれたのは自分が毎月すでに動かしているものだけになった。動かしているものは、詰まる箇所も回避のしかたも手が覚えている。想像で立てた記事は、書き始めてから中身が無いことに気づく。
指摘2 — ゴールが手前で止まっていた
今日いちばん大きい軌道修正がこれだった。
企画書のゴールは「提出用の様式に流し込んだExcelができたところ」になっていた。写真を撮り、読み取り、様式に落ちる。そこで記事が終わる構成だ。
実務ではそこで終わらない。CSVにして会計ソフトDに取り込み、画面に出た件数と金額が手元の集計と合っているところまでが1本の作業だ。取り込みで弾かれる、件数が1件足りない、金額が丸めでずれる。詰まるのはたいていこの区間で、Excelができた時点はまだ折り返しにすぎない。
だから終点を「ソフトの画面で件数と金額が合うところ」まで伸ばさせた。そのうえで、撮影から表示までを1本の記事に載せると長い。フェーズに割って、記事のほうを分ければいい。
シーケンス図にして、フェーズで囲む
レシートを題材に、撮ってから取り込んで表示されるまでを1本のシーケンス図にまとめさせた。フェーズは図の外の注記ではなく、図の中でまとまりを囲む形にした。読んだ人が「今日の記事はこの区間」と指で押さえられるほうがいい。
第1版はすぐ出てきた。lintも描画も確認済み。ただ、図の中身が実態と合っているかは別問題で、確認すべき範囲が広い。取り込み用CSVの仕様のリバースエンジニアリングと、スプレッドシート台帳への集約の仕組みを、サブエージェント2本に分けて並列で調べさせた。
1本目が引っかかるものを返してきた。集計フォームと取り込み用CSVのパイプラインが、ドキュメント上つながっていない。実ファイルで接続を確認させたら、つながっていないのが事実だった。
図に描こうとしていた終点は、実務でもまだ通していない区間だった。
これは図の描き直しになるが、悪い発見ではない。書くべき記事が1本増えた、という意味にもなる。台帳のスプレッドシートが全体の中心に居ると分かったので、第2版は6フェーズに割り直させた。6フェーズ＝6記事。目次の深さも1段上げて、シーズン構成まで右側に出るようにした。
なお、HTMLを作り直しても画面が古いままだったことが今日2回あった。サーバーが前のHTMLを掴んだままなので、再生成のあとは立て直しまでやらないと自分が古い版をレビューしてしまう。
帰り際に、明日の自分へ渡す
帰る時間になった。ここで止めると、明日の自分は「計画書のどこが最新か」から探し始めることになる。
計画書に現在地と残タスクを追記させ、引き継ぎを §12 として本文の中に残させた。図の版、フェーズの本数、まだ通っていない区間。この3つは計画書側に文字で置いておかないと、明日の判断がやり直しになる。決裁フォームも最新のHTMLで立て直してある。
学び
- 企画書のレビューは、手順より前提を疑う。前提が誤っていると記事の本数まで変わる
- 「モデルが苦手だから前処理を足す」という設計は、モデルの世代が変わると丸ごと不要になる。前処理の必要性は都度自分で試して確かめる
- 成果物の終点を「ファイルができたところ」に置くと、実務では折り返しで止まる。「画面で数字が合うところ」まで伸ばす
- 実務のリポジトリをネタ元にするなら、読ませる前に「実名・金額は使わない、型だけ抜く」を宣言してから読ませる
- 共通CSSに手を入れさせず、用途別のCSSを足す。過去の計画書の見た目を巻き込まない
- 過去の自分の棚卸し資料は、そのまま企画の母集団になる
明日やること
- まだ通っていない区間（集計フォーム → 取り込み用CSV）を実際に通し、ソフトの画面で件数と金額が合うところまで確認する
- 6フェーズの記事割りを、1本ずつの見出しレベルまで落とす
- 決裁フォームに残っている判断項目に答えて、シリーズの本数を確定させる