情報システム部門から、次のリリースへの更新を来月末の週末に実施しますという連絡が来る。経理には、影響が無いことを確認してほしいという依頼が付いている。前回のテストで何を確認したかを知っている人間は、部内に一人しかいない。 その一人が当時作ったExcelを探し出し、日付とバージョンを書き換え、担当を割り振り直す。二週間の残業と、決算の準備を止めた分の遅れを払って、結果は「問題なし」で終わる。そして次の更新のときに、同じことをもう一度やる。
更新の頻度は、導入形態で二倍違う
議論の前提として、自社がどの周期に置かれているかを確認しておく必要がある。ここを取り違えたまま計画を立てている会社が、実際にある。
SAP S/4HANA Cloud Public Editionは、2月と8月の年2回の主要リリースで更新される。リリース名は年と月を並べた形式で、2508なら2025年8月のリリースを指す。更新は所定のスケジュールに従って適用され、主要リリースの間にはおおむね2週間ごとの修正の適用がある。更新の日程を会社が選べる幅は狭い。 決算の繁忙期と重なったから今回は見送る、という選択肢が事実上ない。
一方、SAP S/4HANA Cloud Private Editionとオンプレミスは、年1回の主要リリースである。SAP S/4HANA 2025は2025年10月8日にリリースされており、そこに複数のFeature Package Stackが後続する。主要リリースには数年間のメインストリーム保守が設定されるため、毎年上げるかどうかは会社の判断で決められる。
この違いが、テスト資産の切実さを分ける。Public Editionでは、年2回の更新が止まらずに来るため、資産化しなければ経理の工数が構造的に足りなくなる。Private Editionとオンプレミスでは見送りが可能だが、見送りは消滅ではない。三年分をまとめて上げるとき、テストの範囲は三倍ではなく、それ以上に膨らむ。 差分が積み重なるうえ、当時の判断を知る人が社内に残っていないためである（SAPの年間保守料に見合う価値を出す｜標準機能の更新に追従する会社としない会社）。
テストケースを、画面ではなく締めの成果物から書き直す
資産にならないテストケースには、共通の書き方がある。主語が操作になっている。
「FB60で仕入先請求書を登録する」「F-28で入金消込を行う」。この書き方の問題は、確認していることが「その画面が動くこと」に閉じている点にある。標準の更新で画面が動かなくなることは、そもそも稀である。経理が本当に心配しているのは、画面ではなく、その先で作られる数字のほうである。
書き直すときの起点は、締めのアウトプットに置く。月次の試算表、勘定明細、固定資産の償却計算、税区分別の集計、支払データ、そして開示に使う集計表。これらが前月と同じ論理で作られるかどうかが、経理にとっての合否である。
具体的には、ケースを次の形で書く。まず前提として、どのマスタとどの伝票が存在している状態か。次に、何を実行するか。そして期待値として、どの帳票のどの行が、いくらになるか。 最後に、その期待値がどこから導かれるかの根拠。ここが最も重要で、根拠が「前回もこの値だったから」になっているケースは、資産ではなく単なる記録である。
期待値の根拠は、たいてい三つのどれかになる。計算式で導けるもの（償却額、税額、為替換算額）、業務ルールで決まるもの（消込の充当順序、値引きの計上先）、そして設定値で決まるもの（勘定決定、期間管理、番号範囲）。根拠を三つに分類しておくと、次の更新で影響分析が来たときに、どのケースを実行すべきかが機械的に選べる。 設定に関わる変更なら三つ目の分類だけを回せばよい、という判断ができるようになる（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。
範囲は「勘定の金額」と「自動仕訳の経路」で切る
全部テストするという方針は、実行されない方針である。絞り方を先に決めておかないと、絞れなかった年は結局やらないことになる。
絞る軸は二つでよい。一つ目が、金額の大きい勘定である。 試算表を金額順に並べ、上位で全体の大半を占める勘定を特定する。売上、売上原価、仕入債務、売上債権、棚卸資産、固定資産、人件費。ここに誤りが出れば、決算が出せない。
二つ目が、自動で仕訳が作られる経路である。 手で起票する仕訳は、間違えば人が気づく。気づかないのは、設定に従って裏で作られる仕訳のほうである。出荷に伴う売上原価の計上、入庫に伴う仕入計上と検収差額、償却実行、為替評価、消費税の税区分の決定、原価差異の振替。これらは、設定が一箇所変わるだけで、誰にも気づかれずに別の勘定へ流れ込む。
二軸を掛け合わせると、金額が大きく、かつ自動で仕訳が作られる経路が浮かぶ。ここが最優先である。 逆に、金額が小さく手起票の領域は、更新のたびに全件を確認する必要がない。年に一度、まとめて見れば足りる。
この絞り込みには副産物がある。同じ二軸は、日々の月次締めのチェック項目とほぼ一致する。 つまり、回帰テストのために作った一覧が、そのまま決算チェックリストの骨格として使える。逆も成り立つ。すでに実効性のある決算チェックリストを持っている会社は、回帰テストの資産を半分すでに持っている。
追加開発の量ではなく、追加開発の「置き場所」が工数を決める
更新のたびに経理が動員される会社と、そうでない会社の差は、追加開発の本数だけでは説明できない。同じ本数でも、置き場所が違えば工数が違う。
標準の拡張ポイントを使って作られた追加開発は、更新時の影響を受けにくい。標準のテーブルやプログラムに直接手を入れたものは、更新のたびに衝突する。そしてもう一段深刻なのが、標準の中間テーブルを前提にした帳票やインタフェースである。 標準機能自体は動き続けていても、内部の持ち方が変われば、そこを直接読んでいた仕組みが静かに壊れる。壊れ方が「エラーが出る」ではなく「値が変わる」であるため、テストしていなければ気づかない。
したがって、経理の回帰テストの範囲を決めるときには、情報システム部門から**「どの追加開発が、どの標準の内部構造に依存しているか」**の一覧をもらう必要がある。この一覧は、多くの場合そもそも存在しない。存在しないなら、作る対象を絞ってでも作る。この一覧が無い状態で「影響は無いはずです」と言われても、経理は検証できない。
クリーンコアの議論は、この文脈で読むと意味が変わる。標準に手を入れない設計にするという方針は、開発の思想の話に見えて、実際には更新のたびに経理が払う工数を前払いで削る意思決定である。 追加開発を外に逃がす投資の効果は、機能ではなく、毎回の回帰テストの縮小として現れる（クリーンコア戦略とは｜S/4HANAのアドオンをBTPに逃がす考え方）。
自動化は、資産ができた後に効く
テスト自動化の道具は、すでに手の届く場所にある。SAP S/4HANA Cloud Public Editionには、Fiori アプリから使う組み込みのテスト自動化ツールがあり、標準のプロセスを対象にテストを自動化できる。より広い範囲、とくに複数システムをまたぐ統合テストについては、SAPとTricentisの提携によるTricentis Test Automation for SAPがあり、SAP Enterprise Supportの契約者はこれを利用できる。実行結果はSAP Cloud ALM側で集約して確認できる。
ただし、順序を間違えないほうがよい。 自動化は、何をどう判定するかが決まっていて初めて効く。判定基準が人の記憶にある状態で自動化に着手すると、記憶を持っている人が自動化の作業に張り付き、しかも出来上がったスクリプトは操作をなぞるだけのものになる。操作をなぞるスクリプトは、画面が変わった瞬間に全部作り直しになる。 これは、Excelのテストケースが陳腐化するのと同じ理由である。
現実的な順序は三段である。一年目は、期待値と根拠を書いた資産を作る。実行は手作業でよい。二年目は、その資産のうち、実行頻度が高く判定が機械的なものだけを自動化する。三年目以降で、範囲を広げる。一年目を飛ばして二年目から始めた会社が、最も高くつく。
そして忘れられがちなのが、テストデータである。前提となるマスタと伝票が検証環境に無ければ、テストは実行できない。環境をリフレッシュするたびに前提が消えるなら、資産は毎回使えない。テストデータの用意を手順として固定するところまでが、資産化の範囲である（SAPの検証環境に本番データをそのまま入れない｜給与と取引先情報のマスキング設計）。
決めるのは三つ
第一に、期待値を締めの成果物の側に置き、根拠を三分類で記録する。 操作手順で書かれたテストケースは、画面が変われば全滅し、書いた本人の記憶が無ければ再現できない。月次試算表、償却明細、税区分別集計、支払データといった成果物の行と金額で期待値を書き、その期待値が計算式・業務ルール・設定値のどれから導かれるかを分類しておく。この分類があるから、次の更新で影響分析を受け取ったときに、実行すべきケースを機械的に選べる。
第二に、範囲を金額の大きい勘定と自動仕訳の経路の二軸で切る。 全部テストするという方針は実行されない。手で起票する仕訳は間違えば人が気づくが、設定に従って裏で作られる仕訳は誰も気づかない。しかもこの二軸で絞った一覧は、月次締めのチェック項目とほぼ一致するため、決算の統制としても二重に効く。 併せて、追加開発のうちどれが標準の内部構造に依存しているかの一覧を情報システム部門に作らせる。壊れ方が「値が変わる」である以上、テストしなければ気づかない。
第三に、自動化は資産ができた後に着手する。 SAP S/4HANA Cloud Public Editionには組み込みのテスト自動化ツールがあり、統合テストにはSAP Enterprise Supportの契約者が利用できるTricentis Test Automation for SAPがあって、結果はSAP Cloud ALMで集約できる。道具は揃っている。しかし判定基準が人の記憶にある状態で自動化すると、操作をなぞるスクリプトができ、画面が変わった時点で作り直しになる。 一年目は手作業でよいから資産を作り、二年目に判定が機械的なものだけを自動化する。テストデータの用意を手順として固定するところまでが、資産化の範囲である。
