「SAPの入れ替えが始まるらしい。情シスとベンダーがやってくれる」――経理がこの姿勢で移行を迎えると、稼働後にしっぺ返しが来る。月次の締めが以前より遅くなった、欲しい単位で損益が出ない、監査対応の手作業が増えた。稼働してから「そんなはずでは」と気づいても、作り込みはもう固まっている。移行の失敗の多くは、技術の失敗でなく、経理財務が要件を出すべき局面で沈黙していたことに起因する。 かといって、経理が設定作業まで抱え込むのも違う。丸投げと過干渉のあいだに、経理が握るべき意思決定の線が引ける。本稿は、その線を工程ごとに示す。
なぜIT主導だと経理の要件が抜けるのか
移行プロジェクトの体制図を見ると、たいていIT部門とベンダーが中心にいる。彼らは「動くシステムを期限内に作る」ことに責任を持つ。そして動くことと、経理が使いやすいことは別物だ。IT側から見れば、標準機能で伝票が起票でき残高が合えば、システムは「動いている」。だがその標準が、自社の締めの段取りや、見たい損益の切り口に合っているかは、経理でないと判断できない。
だから経理が黙っていると、要件は技術的に楽な場所に落ちる。締めのフローはSAP標準のまま、損益の粒度はデフォルトの科目単位、統制は「あとで規程で縛る」。個々は間違いではないが、積み重なると「動くが使えない」システムができあがる。ERPが会計システムと決定的に違うのは、業務プロセスそのものを規定する点にある（ERPとは何か｜会計システムとの違いと、経理・財務が知るべき選び方）。プロセスを決める場に経理がいなければ、経理の業務が他人の設計で固定されてしまう。
経理が握るべきは「作業」でなく「意思決定」
ここで関与の質を取り違えないことが肝心だ。経理が移行に関わるとは、設定画面を触ることでも、テストデータを黙々と流すことでもない。握るべきは、後戻りできない意思決定のほうだ。具体的には三つに集約される。
- 科目と粒度――どの単位で損益・残高を見たいか。これはCOA再設計の話に直結する（SAP移行を機にする勘定科目体系（COA）の再設計）。
- 統制――発注と支払、仕訳と承認をどこで分けるか。監査で問われる職務分掌を、規程でなく権限設計で担保する。
- 締め――いつ・どの順で締めるか。標準フローに合わせるのでなく、自社の締めをどう作り込むか。
この三つは、ベンダーが代わりに決められない。決めるのに会社の意思が要るからだ。逆に、この三つさえ経理が握れば、細かな設定はIT・ベンダーに任せてよい。丸投げすべきでないのは意思決定で、抱え込むべきでないのは作業――この切り分けが関与の軸になる。
いつ何を決めるか――工程ごとの決めどき
意思決定には、それぞれ決めどきがある。早すぎても情報が足りず、遅すぎると手戻りになる。工程の流れに沿って、経理が何を出すべきかを並べる。
とりわけ効くのが要件定義と**テスト（UAT）**だ。要件定義で出さなかった要望は、設計に載らない。設計に載らなければ、テストで検証する対象にすらならない。そしてテストは、IT部門が用意した理想データでなく、月末が集中する実データで、実際の締めを最初から最後まで通してみる必要がある。ここで初めて「この帳票が出ない」「この単位で集計できない」が露見する。稼働後に気づけば作り直しだが、テストで気づけば設計変更で済む。移行後にデータを見るだけの器で終わらせないためにも、テストは経理の主戦場だ（SAP移行後にデータを活かしきれない理由と、活用に踏み出す最初の一手）。
過干渉もまた失敗
最後に逆側の注意を。経理が心配のあまり設定の細部まで口を出し、あらゆる例外処理を作り込ませると、移行はアドオンの塊になり、保守費が膨らみ、次の移行がまた重くなる。標準に寄せるべきところは寄せ、譲れない要件だけを筋を通して守る。この線引きこそが経理の腕の見せどころだ。要件のオーナーであることと、何でも作り込ませることは違う。守るべき数本を決め、それ以外は手放す胆力が要る。
