記事・コラムColumn

こんにちは、Kakitsuです。「BLoQ管理会計」開発日誌の第12回です。前回は、業種によって採算表の形を変えた話をしました。今回は表に出ない裏方の話で、システムが数字をしまっているデータベースそのものを引っ越しました。得点板にたとえるなら、床下の配線を全部入れ替える工事です。工事のあいだも、表に出る得点は1円たりとも変わってはいけません。

なぜ引っ越すことにしたか

開発中は、ファイル1つで完結する手軽なデータベースを使っていました。一人で作っている間はこれがいちばん速い。ただ、部門数が百を超え、年間の仕訳が十数万件という規模のお客様を扱うようになり、しかも本番はクラウド上のPostgreSQLで動かす予定でした。開発と本番で違うデータベースを使い続けると、開発環境では出ない不具合が本番でだけ出ます。そこで、手元の環境もPostgreSQLにそろえることにしました。

細かいところでは、データベースの置き場所をクラウド同期フォルダの外にしています。同期対象のフォルダに実体を置くと、書き込みの最中に同期が走ってファイルが壊れかねないためです。

引っ越しで大事なのは、荷物が減っていないこと

移行用のスクリプトを書いて、27個のテーブル・18万行あまりを新しいデータベースへ移しました。外部キーの依存関係を壊さない順番でコピーし、IDはそのまま保持。部門どうしの親子関係は自分自身を参照するので2回に分けて流し込み、連番の採番位置も最大値に合わせ直します。最後に、テーブルごとの件数を突き合わせました。

とはいえ、件数が合っていることは「正しく移った」ことの証明にはなりません。そこで、あるお客様の前年度について、全12か月の売上高がfreeeの数字と1円まで一致することを、引っ越し先のデータベース側でも確認しました。ここまでやって、ようやく引っ越し完了です。

計算結果を1円も変えずに、速くする

続いて性能です。それまでは、日次の明細を全部アプリ側に読み込んで、JavaScriptで月ごとに集計していました。手元で動かす分には問題ありませんが、本番ではアプリとデータベースがネットワークを挟んで別の場所にあります。何万行も転送してから足し算をするのは、いかにも重い。そこで、日付の畳み込みをデータベース側の集計に移しました。

ここで自分に課した条件は、計算結果を一切変えないことです。勘定科目の割り当てを解決する部分のロジックには手を触れず、日付をまとめる部分だけを移しました。そのうえで、旧方式と新方式の集計結果を実データで突き合わせ、不一致ゼロを確認してから差し替えています。あわせて部門と期間で絞り込むための索引を追加し、実行計画を見て意図どおりに索引が使われていることも確かめました。結果は、大きなお客様のダッシュボードで1秒を切る表示、ドリルダウンは0.15秒ほど。性能の目標にしていた3秒は余裕をもってクリアできました。

途中で止まっても、続きから

もう一つ、本番を見据えた作り替えをしました。クラウドでは、一回の処理に使える時間に上限があります。通年のデータ取り込みを1回のリクエストで終わらせるのは、大きなお客様では現実的ではありません。
そこで、取り込みを「1回＝1か月」に刻み、どこまで進んだかを記録して、中断しても続きから再開できるようにしました。15分以上動きのない処理は自動で拾い直します。このとき、取り直しても行が積み増さないよう、月ごとにいったん消してから入れ直す方式に変えています。おかげで、以前の方式で溜まっていた残高ゼロの残骸が一掃され、行数が正味の姿に落ち着きました。もちろん、金額は一致したままです。

「売上が消えた」——間違っていたのは検算のほうだった

この時期、あるお客様の前年度データを取り込んだ直後に、検算で売上だけが大幅に少なく見える、という事件がありました。費用はおおむね見えているのに、売上がごっそり足りない。
徹底的に調べた結論は、取り込んだデータは最初から完全で、間違っていたのは検算に使ったほうだった、というものでした。日付を文字列として「月末日以下」で比べていたため、時刻つきで保存されている月末日のデータが丸ごと条件から外れていたのです。そのお客様は店舗の売上を月末日に一括で計上していました。だから売上だけが消えて見え、月の途中に散らばっている費用は残って見えた。画面の集計は日付型で比較していたので、そもそも表示は正しかったわけです。

検算の道具も、検算しなければならない。冷や汗をかきながら得た教訓でした。なお、この調査の過程で本物の不具合も一つ見つかり（大量データでデータ生成が待ち時間を超える）、あわせて直しています。ダウンロードが途中で切れていないかを確かめる処理も足しました。

残った宿題

本番のクラウドへは接続先の設定を差し替えれば移れる見込みですが、同時接続数の扱いなど、本番だけに出てくる設定はこれからです。また、全部門をまとめて月次集計する経路は、いまのところ表全体を走査しています。お客様が増えてデータが分散してくると索引が効きはじめるはずで、そのときに測り直す予定です。

次回予告
第13回では、このシステムをどこで動かすか——本番インフラとホスティングの選定についてお話しします。
（次回に続く）

――――――――――
#管理会計システム #DX #経営効率化＃個人開発＃アメーバ管理会計
――――――――――

本連載はKakitsu株式会社（Kakitsu）が開発・運営しています。
Kakitsu株式会社 公式サイト： https://kakitsu.co.jp/