OCR済みの実務書を工程スキルに落とし込む設計と、図解でレビューしやすくする工夫

本は棚にあっても、仕事の途中では出てこない。 OCRして蔵書データベースに入れても、そこは変わらなかった。 手を止めて検索するのは、自分が困っていると自覚したときだけである。

今日やりたかったのは、その1冊を、検索しなくても向こうから出てくる形に変えることだった。 つまり、工程のスキルにする。

そのリファレンス、私も読むのか

最初に作らせた計画には、本の内容を分野別に整理した読み物が8本入っていた。 きれいに章立てされていて、それらしく見えた。

念のため聞いた。 これはあなたも読むんですか、と。

返ってきた答えは「読む設計だが、読むのは事例と施策の中身だけで、分野別に章立てした解説部分は読み飛ばす」だった。 つまりあの8本は人が上から読むための整形であって、機械は使わない。 そして人が読むなら、原本がある。 私は本で読む。

どれくらいの量なのか測らせたら、43,000文字あった。 毎回それを全部読ませてから作業に入るのは無駄なので、8本とも落とした。 代わりに、必要なときに検索して該当箇所だけ引く形にした。

本から作るリファレンスは、「機械が引くためのもの」と「人が読むためのもの」が混ざりやすい。 後者は最初から作らなくていい。

母数を抽出プログラムに決めさせない

計画書を Codex にレビューさせたら、致命的な指摘が5点返ってきた。 いちばん重かったのは、母数の根拠が抽出プログラム自身になっているという点である。

抽出器が176件拾ったとして、それが全部かどうかを抽出器は知らない。 落としたものは、落としたことすら報告に出てこない。

幸い、原文の側に数えられる印があった。 項目の頭に付いている記号を数えて、抽出結果と突き合わせる。 この検算を全工程の完了条件にした。

出てきた不具合は4種類ある。

• 施策名が数字で始まる事例を、判定条件が丸ごと落としていた
• 分類の見出しを、事例本体と誤判定していた
• ページ上部の柱の文字列が、項目名に混入していた
• 別言語の文字が本文に紛れ込んでいた

最終的に、原文の193件が「176事例 + 3分類ラベル + 14表項目」に分解できた。 内訳が全部説明できた時点で、次の工程に進んだ。 プロトタイプの段階で落ちていた1件も、ここで復活している。

目次順ではなく、困りごとから引く

使う側は本の目次を覚えていない。 目の前の症状から引く。

そこで各事例に症状タグを付けさせた。 分野ごとに語彙を設計して、8分野に展開させた。

途中で、施策そのものと「提言の作法」が同じ一覧に混ざっているのに気づいて分離した。 ところが、分離したほうの中にも施策が混じっていた。 仕組みを作る話は、どう見ても作法ではなく施策である。 検索対象から外していたのが誤りだったので、設計を戻した。

このとき、特定の症状で引いても該当が出てこないケースが4件あった。 非該当だと決めて検算に組み込んでいたのだが、実データで裏を取ったら、4件のうち3件は本の中にちゃんと記述があった。 推測で作った「出ないはずのケース」が、検算の偽陽性を生んでいたことになる。

レビューを頼むなら、レビューできる形で出す

タグの粒度を確認してほしい、という報告がターミナルにテキストで出てきた。

これ、HTMLで見るんじゃないんですか、と返した。 33件のタグ付けが妥当かどうかは、ターミナルに流れる断片では見比べられない。

データから確認用ページを生成する形に変えさせた。 以後、分野を足すたびに同じページを開き直すだけで、全体を並べて見られるようになった。

崩れたテキストの図を、図に描き直す

昼は別系統の作業をした。 前日までに作ってあったスキル13本を、1枚のHTMLに結合してプレビューさせた。

使い方を説明する箇所に、矢印つきのテキストの図が入っていた。 等幅フォント前提の作りが崩れて、何が書いてあるのか読めない。

図に描き直させた。 13本を順に呼ぶこと、成果物が1案件につき1ファイルの自己完結したメモになること。 この骨格は、文字で並べると読み飛ばすが、図にすると一目で入る。

テキストで描いた図は、原本の中では意味を持つ。 別の場所に移した瞬間に崩れて、レビューの妨げになる。

ついでに、この工程そのものをスキルにした。 スキル群を1枚のHTMLに結合し、読みにくい図はSVGに描き直してから、Chromeで開く。 レビューのたびに同じことをやっていたので、手順として固定した。

前の晩のメモから入る

前夜、セッションを閉じる前に「次に開いたときに最初に読むもの」を書かせておいた。 経緯、結論、検討した内容、未了事項。

朝はそれを読ませてから続きに入った。 何をやっていたかを思い出す作業が、まるごと要らなかった。

昼過ぎに積み残しを一覧にさせた。 プロジェクトをまたいで並べると、最優先の2件がすぐ浮いた。 このとき「未了ってありましたっけ」と聞いたのだが、記憶で答えさせず、実際のファイルを見てから答えさせた。

手元のデータでできるところまで進める

夜は支援先の一次分析に入った。

足りない資料を先に依頼してから始める段取りにはしなかった。 手元にあるものだけで通せるところまで通し、足りないものは後からリストにする。 数期分の決算書を読ませ、検算を通させた。 月別売上の合計、貸借の一致、前期末と当期首の一致。 どれも合った。

ところが、途中で結論が反転した。 ある収入の性格が確定するかどうかで、本業の損益が黒にも赤にも振れる。 先に出させた結論をいったん撤回させて、成果物を作り直させた。

作業の終わりに、同じ趣旨のリストが前の晩に既に作られていたのを見つけた。 統合させて正本を1本に決め、旧版は消さずに残した。 先頭に警告と、正本へのポインタを置いてある。

手元のデータで進める狙いは、成果物を早く出すことだと思っていた。 実際にやってみると、足りないものを正確に知るための手段でもあった。 最初に依頼リストを作っていたら、依頼の粒度はもっと粗かったはずである。

学び

• 本から作るリファレンスは、「機械が引くためのもの」と「人が読むためのもの」が混ざる。後者は原本があるので作らなくていい。43,000文字を毎回読ませる設計になっていた
• 抽出した件数を母数にすると、落としたものは永久に見えない。原文側に数えられる印を探して、そちらを母数にする
• 検算の「出ないはずのケース」を推測で作ると、そこが偽陽性の温床になる。4件中3件が実際には本に書いてあった
• レビューを頼むなら、レビューできる形で出す。33件のタグ付けの妥当性は、ターミナルの断片では見比べられない
• テキストで描いた図は、別の場所に移すと崩れる。崩れた図は読まれないだけでなく、レビューを止める
• セッションの終わりに「次に読むもの」を1本残しておくと、翌朝の思い出す時間がゼロになる

明日やること

• 積み残し一覧の最優先2件のうち、先に着手するものを決める
• 一次分析で足りないと分かった資料を、依頼リストとして支援先に出す
• スキル群をHTMLに結合するスキルを、別のスキル群でも一度通してみる