移行プロジェクトの序盤で必ず作られる資料がある。現行帳票の一覧だ。各部門に照会をかけると、数百本の行が並んだ表が返ってくる。全部は作れないことは、その場の全員が分かっている。それでも一本も削れないまま要件定義が終わり、アドオンの見積りが跳ね上がる。原因は現場のわがままではない。削る根拠を「使っていますか」というアンケートで取りにいったことのほうにある。 その質問には、誰も「使っていません」とは答えられない。
「使っていますか」と聞くと、全部が「使っています」になる
帳票の棚卸しが失敗する原因は、質問設計にある。「この帳票は必要ですか」と聞かれて、不要と答える担当者はいない。答えた瞬間に、自分の業務が不要だと言ったように聞こえるからだ。仮に本人が不要だと思っていても、「昔、部長が見ていた気がする」という理由で残す。こうして棚卸表は、全行が「必要」で埋まる。
質問を変える。帳票ごとに、次の列を埋めさせる。
- ① 出力の受け手：部署名でなく役職名。「経理部」で止めず「経理部長」「工場の原価担当」まで書かせる
- ② その人が下す判断：この数字を見て何を決めるか。決めることが無いなら、それは参考資料である
- ③ 見るタイミング：月次締め後、週次、随時。締めのクリティカルパス上にあるかどうかが分かる
- ④ 廃止したら止まるもの：具体的な業務名。「困る」で止めず「何が止まるか」を書かせる
- ⑤ 同じ数字を出している他の帳票：重複の発見はここでしか起きない
- ⑥ 現行での加工の有無：出力後にExcelで加工しているなら、その加工こそが本当の要件
②が書けない帳票は、判断に使われていない。③が「随時」ばかりなら、定型帳票にする必要はない。照会機能で足りる。そして⑥が最も効く。出力後の加工手順は、現行帳票が満たせていなかった要件の告白だ。 現行帳票をそのまま移植すれば、その加工も一緒に移植される。
分類は「効き」と「標準で出せるか」の二軸で切る
棚卸しの結果を、二軸で置き直す。縦軸は意思決定への効き、横軸は標準機能で出せる度合いだ。
この図で本当に難しいのは左下の判定だ。効きが低く標準でも出ない帳票は、論理的には全部廃止でいい。だが現場は「二十年出し続けてきた」という事実だけを根拠に残そうとする。ここで効くのが棚卸表の②と④になる。判断が書けず、止まる業務も書けなければ、廃止の合意は取れる。書けるなら、効きが低いという判定のほうが間違っていた。
左上に落ちたものだけが、開発の候補になる。ここまで絞り込めば、数百本が二桁になることは珍しくない。
帳票が多いのではなく、判断が重複している
数百本という規模そのものを疑ったほうがいい。中身を並べると、同じ勘定残高を部門別・製品別・地域別に切っただけの帳票が何十本も並んでいることがある。作った当時は、切り口ごとに別のプログラムを組むしかなかったからだ。
S/4HANAでは、その前提が消えている。切り口を会計明細の属性として持てる以上、帳票を切り口の数だけ用意する理由はなくなった（SAPの組織構造設計（会社コード・管理領域・利益センタ）｜アドオンで直せない唯一の領域）。一本の照会に分析軸を持たせ、利用者に切り替えさせればいい。
問題は、重複を機械的に見つける手順が用意されていないことだ。棚卸表の⑤を担当者の記憶に頼って埋めさせても、精度は出ない。実務では、帳票ごとに四つの属性をコード化して並べる。使っている勘定科目の範囲、集計の単位（会社・利益センタ・製品・得意先など）、期間の切り方、そして金額の種類（実績・予算・差異）。この四つのうち集計の単位だけが違う帳票群は、同じ判断のための同じ数字を、別の切り口で出しているにすぎない。並べれば、数十本が数本に畳める。
ここで効いてくるのが分析軸そのものの設計になる。明細に持っていない軸は、後からどう頑張っても分解できない。帳票要件の議論に見えて、実際には分析軸の設計を議論していることが多い（管理会計の分析軸（ディメンション）設計｜あとから分解できない粒度を先に決める）。軸が正しく設計できていれば、統合は自然に進む。
「作る」と決めたものを、さらに三段で削る
左上に残った帳票も、そのままアドオンにはしない。開発量を決めるのは、この三段階を通す規律のほうだ。
第一段。標準のアプリや標準の照会で、レイアウトを変えれば足りないか。「様式が現行と違う」は作る理由にならない。 現行の様式は、現行システムの制約が二十年かけて固まったものだ。ここを認めると、移行プロジェクトは旧システムの再現工事になる。
第二段。標準の照会にフィルタと集計を足すか、CDSビューを追加して標準のUIから見る形にできないか。この層で作ったものは標準の画面と権限の枠組みに乗るため、アップグレード時の回帰テストが軽い。
第三段。それでも足りないものを、分析基盤側に置けないか。定型帳票としてSAPの中に持つ必要が本当にあるのか、分析用途なら計画と実績を扱う分析側に寄せるほうが自然か（SAP Analytics Cloud（SAC）で計画と実績を一つにつなぐ）。
三段を通過してもなお残るものだけが、開発の対象になる。ここまで来た帳票は、たいてい法定様式か、業界固有の取引先提出資料か、他社にない独自の原価計算のいずれかだ。数はごく少ない。そして少ないからこそ、クリーンコアの考え方に沿って標準の外側へ逃がす設計が成立する（クリーンコア戦略とは｜S/4HANAのアドオンをBTPに逃がす考え方）。
作る判断のコストは、開発費より稼働後に効く
帳票を一本作る判断を、開発工数の見積りだけで議論すると必ず誤る。作った帳票には、稼働後もコストが付いてくる。仕様変更のたびの改修、アップグレードのたびの回帰テスト、権限設計の維持、そして作った人がいなくなった後の仕様の再解読。
この永続コストは、要件定義の会議では見えない。見えないから、判断が「作る」に倒れる。効くのは、承認の場に稼働後の負担を数字で持ち込むことだ。一本あたりの年間保守工数を仮置きし、要求本数を掛けて年額として示す。金額の精度は問わない。毎年出ていく費用として承認の場に並ぶこと自体が効く（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
廃止は情シスでは決められない。オーナーを置く
分類が正しくても、廃止の合意は自動的には取れない。廃止を決められるのは情報システム部門ではなく、その帳票で判断していた人だ。だから棚卸表の①で役職名を書かせている。名前が付いた帳票は、その人と一対一で廃止を協議できる。「経理部」宛の帳票は、誰とも協議できない。
そのうえで、期限を設計に組み込む。稼働時にすべてを廃止し切ろうとすると抵抗が強くなるので、暫定的に残す帳票にはサンセット条項を付ける。稼働後の一定期間だけ残し、その間の出力ログを取る。期間内に一度も出力されなければ、協議なしで廃止する。逆に出力されていれば、その時点で改めて用途を書かせる。この運用を最初に合意しておくと、稼働直後の「念のため残してほしい」という要望を、対立せずに受けられる。
稼働後に帳票が使われなくなる原因は、たいてい様式にはない。その人の仕事の順序に合っていないからだ。出力ログは、その事実を議論を経ずにデータで出してくれる（SAP稼働後にユーザーが使わなくなる理由｜定着を決めるのは操作研修ではない）。
廃止した本数を、プロジェクトの成果に書く
移行プロジェクトの帳票スコープは、放っておけば必ず膨らむ。要望を集める仕組みはあるのに、落とす仕組みがないからだ。三分類は、その落とす仕組みを会議体に埋め込む道具にすぎない。用途を書かせ、二軸に置き、作ると決めたものも三段で削る。手順はこれだけで、目新しさもない。
それでも多くのプロジェクトが数百本の一覧を抱えたまま設計に入っていく。削れないのは根拠が無いからではなく、削る役割を誰も引き受けていないからだ。 その役割は経理財務側から出すのがいちばん機能する。その数字で判断しているのが、経理財務だからだ（SAP移行プロジェクトに経理財務はどう関わるべきか｜丸投げで失敗しない）。
