2026年8月5日の開発日記

この日は「持っているつもりのものを、実際に数える」作業が二つ重なった。ひとつは蔵書データベースで、ある分野の専門書がどこまで入っているのかを数え直した。もうひとつは支援先の業務システムで、画面を眺めて仕様を書くのをやめ、内部のやりとりを直接見に行った。

どちらも、思っていたより入っていない・思っていたより単純だった、という結果になった。数えるまで分からないことは案外多い。

今日のタイムライン

今日やったこと

1. 蔵書データベースを棚卸しして、工程スキルの実装に入った

ある分野の専門書がデータベースにどこまで取り込まれているかを確かめた。取り込み済みと未取り込みが両方あり、どちらがどれなのかを突き合わせて抜けを出した。

抜けが見えたところで、その分野の知識を手順として使える形に落とすスキルの実装へ進んだ。設計自体はこの日の別セッションで固めてあり、そのまま実装に入れた。

主な成果:

• 取り込み済みと未取り込みの冊数を突き合わせ、抜けを一覧にした
• 分野知識を工程として使えるスキルの実装を進めた
• できたスキルを、手元にある実データで一度通した

詳細: 蔵書DBを棚卸しして専門書の抜けを洗い出し、簡易デューデリジェンス支援スキルを実装した

2. 業務システムの内部APIから仕様を起こした

支援先の入力効率化を進めるにあたって、画面を一周テストした。ブラウザの開発者ツールで通信を見ると、画面の裏で何をやりとりしているかがそのまま読める。

そこから内部APIの形を洗い出し、機械が読める形式へ移した。画面の見た目から仕様を推測するより、はるかに確度が高い。

主な成果:

• 開発者ツール越しに画面と通信を一周たどった
• 内部APIの入出力を洗い出し、スキーマとして書き起こした
• 計画書について、外部AIのレビュー版と自前の観点を重ねた版を比べた

詳細: 業務システムの内部APIを開発者ツールで洗い出し、JSON Schemaに移す

今日の試行錯誤

今日の学び

• 「だいたい入っている」は数えていないことの言い換えだった。棚卸しは、抜けを責める作業ではなく、次に何を足すかを決めるための作業になる
• 画面から仕様を起こすと、こちらの解釈が混ざる。通信をそのまま読むと解釈が減る
• レビューは一種類だと観点が偏る。外部の目と手元の事情を知っている目は、役割が違う

明日やること

• 未取り込みの専門書を順に取り込む
• 書き起こしたスキーマを、実際の入力処理に当てて検証する

関連記事

• 蔵書DBを棚卸しして専門書の抜けを洗い出し、簡易デューデリジェンス支援スキルを実装した
• 業務システムの内部APIを開発者ツールで洗い出し、JSON Schemaに移す