2024.07.23
税務調査の確率は低いから安心？油断禁物！知っておきたい調査...
税のこと
事務所のシステムとして書類の受け取りから仕訳データにするまでの前捌き、ここを仕組み化しようとしています。
プログラミングの知識はゼロです。
それでもClaudeと壁打ちしながら進めた結果、コードが2000行を超えました。
何が形になっているのか、現在地をそのままお伝えします。
システム設計で意識したポイントも書いているので、業種を問わず参考になれば嬉しいです。
Contents
現在構築中のシステムのコードを合計すると、2000行を超えています。
600〜900行規模のファイルが3つ4つ。まだ増える予定+既存のコードも随時更新予定。
プログラミングの知識がない状態から一人でやろうとしたら、5年以上かけてできるかどうか…いや、きっと完成すらしなかったと思います。
それが今、実際に動いています。
その中心にあるのがClaudeです。
Claude CodeやCoworkが話題ですが、私はシンプルにチャット機能メイン。
前回の記事で触れましたが、プロジェクト機能があるので「事務所のシステム作り」といった一つのテーマに向けていくつものチャットを並行できるのが強いです。
やることは単純で壁打ちしながら設計して、コードを書いてもらい、自分で確認しながら整えていく。
この繰り返しで少しずつ形になっています。
知識がなくてもコードを書くこと自体は苦痛ではありません。というよりも自分では書いていません。
自分が考えるのは設計・導線の部分で、それを形にしてもらえるのがClaudeとの壁打ちの強さだと感じています。
なお、この前身となる構想を組みだした時から含めるとそろそろ5か月くらい経ちます。
確定申告時期はストップしていたのでマイナス2か月程度したとしても、現時点は3か月くらい経った地点ですね。
インパクトのある成功体験は目を惹きますが、実際には業務や他の事をこなしながらとなると数か月～年単位かかると思います。
大きく分けて2つのシステムが動き始めています。
毎月の書類回収の案内を自動送信し、顧問先ごとの進捗をスプレッドシートで管理します。
ステータスが変わるとGoogle Tasksのタスクも自動で更新されます。
工夫したポイントはステータスに応じてタスク名が変わるところで、これまで様々なタスク管理ツールを使ってきましたが、これはなかなか実行が難しかったところだったので気に入っています。
Googleカレンダーでタイムブロッキングしながらタスクをこなしていくと、進捗管理表も連動して進んでいくイメージです。
個人的にはタスク管理にタイムブロッキングはマストなので、それを行える仕組みづくりというのが条件でした。
元々todoistを使っていましたが、仕組みとして組み込むのは難しいと考え、選択肢としてNotionカレンダーを想定して進めていましたがXでヒントを得て、イマイチと感じていたGoogle ToDoもGASで連携すれば仕組みに組み込めるのでは？と試してみたのが始まりです。
その他、判断を要する部分は残しつつ、リマインド送信などは半自動化していく予定です。
顧問先の共有フォルダを監視して、新着ファイルを自動で検知します。
作業フォルダへ移行し、進捗管理シートへの反映までを自動で処理します。
状況に応じてタスクを生成するケースもあり、①との重複が起きないように設計しています。
ここで工夫というか気を付けたポイントは、想定している通りに書類が入らない前提で考えるということでした。
通常は決められたフォルダにアップロードしてもらいますが、別の場所に入る可能性があります。
それを想定して、どの階層までなら移行するか、検知するか、検知するにしても通知程度にするのか要確認レベルで通知するのかという線を引いて、手動で確認する余地を残しています。
理想は全自動かもしれませんが、漏れないことを絶対条件とするために人の判断を介入させました。
この2つが連携して、書類の受領までの前捌きの工程を支えています。
次のフェーズとして証憑処理システムを構築しています。
書類を受領した後のフェーズですね。
具体的には顧問先から届いたファイルをGeminiでOCR処理し、書類の種別を判定してリネーム・フォルダ振り分けまで自動化することを考えています。
書類の種別によって処理ルートを分けていて、自動で処理できるものはそのまま、判断が必要なものだけ人が確認する設計にしています。
確認後はCSV出力まで対応する予定で、現在構築中です。
現時点はリネームの部分を手掛けています。アプリでの使用を想定しており、顧問先ごとの未処理ファイルのリネーム案が付されて手動での変更も可能な状態にしています。
理想はルールに従って自動でリネームですが、書類種別が様々ある中ですべて一発で決まるルールをまだ設定できていないというのが正直なところです。
ここは少しずつルールを追加して精度を上げていく運用になるのか、半自動で手動で直す余地を残すのかも含めてこれから考えていくところとなります。
システムを組む中で、技術というより考え方として工夫・意識してきたことがあります。
長期的な運用を考えると、全部を対象にしようとすると処理が重くなるのでプログラムが参照する範囲は常に区切ることを最初の時点で考えます。
長期的に耐えうる（破綻のない）仕組みかどうか。という点ですね。
良いものが出来たと思っても年が切り替わった時にコレどうするんだろう…ということもあります。2～3年なら問題なくても数年後同じ処理をすることが可能かどうかという視点も必要になります。
例えば、範囲を区切らずに全期間対象にした場合は最初の1年なら問題なくとも、年を重ねるごとに顧問先×年数だけ参照する範囲が積みあがっていきます。
ただ範囲の絞り方を誤ると、今度は抜けが出る恐れも。
どこまでどのように絞るかの判断は、フォルダ構成との兼ね合いも含めて決めることになると思いますが「絞ることと抜けを出さないことを両立させる」という視点が重要だと感じています。
全部自動にしようとすると、どこかで無理が出ます。
自動でいける部分と人が判断すべき部分を最初から設計で分けておく。
この線引きは実務を知っているからこそできる部分で、状況によって変わることもあります。
最終的にここの判断は自分しかできないと思っていて、その線引きをどこに引くかをClaudeと壁打ちしながら詰めていくのが今のやり方です。
ここの線引きは大変ですが、自作だからこそ自分に合うところで線を引くことができるのが醍醐味であり、同時に自作は１人や小規模向けな気がします。
処理済みのものを明確にしなければ、同じファイルを二重に処理してしまうリスクがあります。
後から気づいて修正するより、設計の段階で重複が起きうるかを先に考えておく方が結果的に楽になります。
そのためにどこかに重複防止のフラグを持たせる必要がありました。
顧問先×ファイル数で膨大になるので別で管理することは現実的ではなく、ファイルや置き場所で判断させたいと考えましたが、良い方法が見つからずにいました。
ファイル名に含めるのはできないこともなさそうだけどコード（条件）が複雑化しそう。
それならばとフォルダ構成で絞る案も考えましたが、それだと処理漏れのリスクが出てしまう。
半自動化することも視野に入れつつ、どれもピンとこないなか、Claudeが提案したのはGoogleドライブのファイルの説明欄に書き込む方法でした。
そもそも私はドライブのファイルに説明欄があること自体を知りませんでした。
これならファイル自体に情報を持たせることができ、なおかつフラグの内容次第では他の工程でも重複防止として使えるため、汎用性がありました。
知識がなければ絶対に辿り着けない手法でした。こういう発見が壁打ちの面白さだと思っています。
おわりに
システムはまだ構築途中です。そのうちまた次の工程の事などについても書いていきます。
前回の記事もあわせてご覧ください。 →Claudeが自動化するか、Claudeで自動化するか
