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