こんにちは、Kakitsuです。「BLoQ管理会計」開発日誌の第2回です。前回は、なぜ公認会計士・税理士事務所が自分たちで管理会計システムを開発することにしたのか、その経緯をお話ししました。今回は、開発初日に固めた技術の土台と、実際にfreee会計APIと接続してみて最初にぶつかった壁についてお話しします。
なぜこの技術構成を選んだか
開発工程書を作成した段階で、技術選定として、Next.js・TypeScript・Prismaを軸に、開発中は手元で扱いやすいSQLite、本番移行を見据えてPostgreSQLにも切り替えられる設計を選びました。会計・税務の専門知識はこちらが持っていても、インフラの知見は限られています。そこで、情報が豊富で生成AIとの相性が良いこと、型があることで会計計算のミスを防ぎやすいこと、小さく始めて本番規模まで無理なく育てられること、の3点を基準にしました。
freee会計APIとの疎通確認
設計と並行して、freee会計APIとのOAuth2.0連携を実装し、初日のうちに実際のお客様データでの疎通確認まで進めました。認可コードとstate検証によるOAuth認証、取得したアクセストークンはAES-256-GCMで暗号化して保存し、有効期限が切れれば自動でリフレッシュする仕組みにしました。また、APIには呼び出し回数の制限があるため、リクエストを直列のキューで処理し、レート制限や一時的なエラーが返ってきた場合は自動でリトライする作りにしています。
部門が多いお客様で起きた最初のエラー
疎通確認は、ご協力いただいているお客様（複数の店舗・部門を運営されているお客様）の環境で行いました。ところが、部門別の試算表を同期しようとしたところ、エラーが返ってきて止まってしまいました。原因を調べると、freee会計の部門比較APIには「1回のリクエストで指定できる部門は最大5件まで」という制限があり、このお客様は20を超える部門をお持ちだったため、一度に全部門を指定するリクエストが上限に引っかかっていたのです。
対応として、指定する部門IDを5件ずつのまとまり（チャンク）に分割し、複数回に分けて取得してから結果を統合する処理に修正しました。あわせてテストケースを追加し、実際のお客様データ（複数期分の試算表）を取り込んで、事前にfreee会計側で確認していた数値と一致することも確認しました。地味な修正ですが、「freee会計側の細かい制限は、実データを流してみ
て初めてわかる」ということを、開発初日から実感した出来事でした。
次回予告
第3回では、部門マスタや勘定科目マスタの取込みと、それらをどうデータベース設計に落とし込んだかについてお話しします。特に「親部門と子部門の階層をどう扱うか」で、実データを使った検証の中で最初の判断を修正することになった経緯を紹介する予定です。
（次回に続く）
――――――――――
#freee会計 #LaQ #BLoQ管理会計 #全員参加経営 #アメーバ会計システム #決算早期化 #売上最大・経費最小 #管理会計システム #DX #経営効率化 #中小企業 #ニューブロック #Yondemy #ゲーミフィケーション #遊びと教育 #遊びと仕事
――――――――――
本連載は嘉橘株式会社（Kakitsu）が開発・運営しています。
嘉橘株式会社 公式サイト： https://kakitsu.co.jp/