課題
月次の管理会計資料は、表計算ソフトのアドイン関数で基幹データを引き当て、足りない部分を手計算で埋める形で作られていました。計算が資料そのものに埋め込まれているため、数字の正しさは「作った人が確かめた」という記憶に依存します。担当が替われば、なぜその数字になるのかを辿れる人がいなくなる構造です（数値はいずれも概数です）。
拠点によって集計の定義も報告通貨も異なり、横に並べるには通貨換算と定義の読み替えが要りました。毎月これをやり切ること自体が、管理会計で本来やるべき分析の時間を奪っていました。
やったこと
1. アドイン関数が何を計算しているかを、全セル突合で解く
置き換えの前に、現行資料のアドイン関数が何をしているかを式のレベルまで解きました。会社・年月・勘定科目コードによる絞り込みと合計であることを特定し、元データから同じ値を再計算して現行資料と突き合わせています。対象の関数セルは約1,150、すべて一致しました。
ここが合わないまま自動化に進むと、出来上がるのは「違う数字を速く作る仕組み」です。
2. 資料ごとに独立したエンジンとして作る
共通の読み取り層や統合ランナーは作りませんでした。資料は目的も様式も、扱える月の範囲も違います。共通化すると1本の都合が残り3本に伝染し、どこかを直すたびに全部を検証し直すことになります。
代わりに、資料ごとに独立したプログラムを持たせ、対応できない月は正直に断って止まる設計にしました。「今はできないことがある」を隠さないほうが、運用に載ります。
3. 検算を通ったファイルだけが、正式な名前で確定する
エンジンはまず仮の名前でファイルを書き出します。それを一度閉じ、開き直して、元データを別の経路から足し直した値と突き合わせます。この検算を通ったものだけを正式な資料名へ置き換え、通らなかったものは仮ファイルごと削除して異常終了します。
結果として、正式な名前の資料が存在すること自体が、検算に合格した証明になります。「検算しましたが結果は不一致でした」と書かれた資料が手元に届くことはありません。この保証を、人の読解にも、報告の書きぶりにも依存させたくなかったためです。
4. ゲートが本当に止まるかを、障害を注入して確かめる
品質ゲートは、作った本人が「入れました」と言えば入ったことになってしまいます。そこで、正しいデータにわざと壊れた値を混ぜ、資料が生成されずに止まることを確認する試験を用意しました。約40ケース・約320項目の検査で違反ゼロです。あわせて、ゲート側のコードを1箇所ずつ書き換えて試験が確かに落ちること、つまり試験自体が空振りしていないことも確かめています。
同じ入力から必ず同じ出力が出ること（実行のたびに数字が揺れないこと）は、生成ファイルのハッシュ値が一致することで確認しました。
納品物
毎月使う資料4本の生成エンジンと、検証用の1本。データの置き場所・実行の入口・パラメータ・作成履歴をまとめたNotion上の運用ページ一式。担当者向けのご利用手順。加えて、品質ゲートが何を検査し、何を検査していないか（この仕組みでは捕まえられない異常の種類）を書き切った仕様書を残しています。
結果
アドイン関数の再現は約1,150セルで100%一致、現行資料との様式一致は99.8%、売掛金明細は約49,000セルで完全一致しました。
そして、初めて新しい月の実データを通したとき、資料が1本だけ生成されずに止まりました。原因は、資料の元データにだけ後から計上された1行が入っており、会計側の残高と金額が合わなかったことです。金額としてはごく小さな1行でしたが、合わない以上、ゲートは資料を出しませんでした。
自動化の価値がいちばん出たのはここだと考えています。人が作っていれば、この程度の差は気づかれないまま資料になり、そのまま配られていたはずです。速く作れることより、間違ったまま出ないことのほうが、管理会計では効きます。
その後
担当部門向けのご利用手順の提供まで完了しました。運用の初月は、当方が並走して数字を照合する体制を置いています。ここで使った品質保証の型（検算を通ったものだけが確定する構造、障害注入による試験、埋まらない限界の明示）は、Excelの計算をエンジンへ移すときの品質保証に一般化して整理しています。