S/4HANAへの移行を、CIOとSIベンダーに任せた瞬間に、CFOは次の10年を失う。強い言い方だが、これは現場で繰り返し起きていることだ。
多くの移行は「2027年（延長して2030年）の保守期限に間に合わせる」という締め切り対応として始まる。期限から逆算し、リスクを最小化し、いま動いている業務を“そのまま”新基盤に載せる。IT部門にとっては、これは正しい。だが、その「そのまま」の中に、勘定科目体系・利益センタ・採算の見方・管理会計と財務会計の関係——経理財務の数字の構造そのものが、丸ごと含まれている。そして移行が終われば、それは次の更改まで事実上10年、凍結される。
だから本質はこうだ。移行は「いつやるか」の問題ではない。**「何を作り変え、何を10年固定するか」**の問題だ。そしてこれを意思決定できるのは、IT部門ではない。CFOだ。
「そのまま載せ替える」が、なぜ高くつくのか
移行後に勘定科目体系を組み替える、利益センタの切り方を変える、採算分析の軸を入れ替える——これらは本番稼働後にやると、ほぼ再構築（リプレイス級）の費用とリスクになる。逆に移行のプロジェクトの中でなら、追加の設計工数で済む。作り変えのコストが何十分の一かで済む窓は、移行のときだけ開く。
ところが現実の意思決定は逆を向く。締め切りが先にあり、リスクを嫌い、「現行どおり」が安全に見える。こうして、本来は10年に一度の設計機会が、「無事に載せ替えること」を目的にした保守作業に縮んでいく。失うのは、その10年に効いたはずの資本効率の可視化だ。
「管理会計と財務会計が合わない」は、もう設計で消せる問題
ここが、CFOが必ず押さえるべき一点だ。
S/4HANAは、すべての仕訳を**Universal Journal（単一テーブル ACDOCA）**に統合する。財務会計（FI）と管理会計（CO）が、別々の世界として存在することをやめる。これが意味するのは、技術の話ではない。経営会議で使う数字と、決算で出す数字が、原理的に一致する設計が、初めて手に入るということだ。
具体的には、採算分析（旧 CO-PA）を account-based の Margin Analysis に寄せると、製品別・顧客別の利益が Universal Journal の中に直接記録される。SAPの表現を借りれば “reconciled by design” ——照合しなくても、最初から合っている。あなたのチームが毎月の締めで費やしている「管理の利益と決算の利益が合わない、その差はどこか」という消耗が、構造ごと消える。
逆を見落としてはいけない。旧来の costing-based CO-PA をそのまま引き継ぐと（＝「今までこれだったから」というブラウンフィールドの既定値）、その採算データは Universal Journal の外に置かれる。SAP自身が「財務会計との照合は大きな課題になる」と認める構造を、わざわざ10年、抱え直すことになる。
つまり、毎月あなたを苦しめている照合作業は、本当は移行時の一度きりの設計判断だ。多くのCFOは、自分がその判断を——たいてい既定値のまま——下していることに気づいていない。
「見たい数字」は変わり続ける──今の前提で固めたシステムは、明日の足かせになる
経営管理の要件を「いま見たい数字を出せること」と書いた瞬間に、設計を一度間違えている。事業は変わり続ける。今期の主力は来期には縮み、新規事業が立ち上がり、見るべき切り口（セグメント・チャネル・顧客軸）は入れ替わっていく。いま見たい数字“だけ”が出せるシステムは、事業が動いた瞬間に「見たい数字が出せないシステム」に変わる。
だから本当の要件はこうだ。「見たい数字を、いつでも出せる」。ただしこの“いつでも”には、今の事業の前提が変わっても成り立つ、が含まれていなければならない。勘定科目体系の定義もシステム構成も、変化を前提にした柔軟な思想で組んでおく。そうしないと、事業を変えたいのにシステムが追従できない——自社の競争力を、自分の手で落とすことになる。器が硬いせいで、事業がそこから動けなくなる。
そしてここは、現場やITだけでは設計できない。どの数字を見たいかは、会社がどこへ向かうか——戦略そのものと結びつく。次にどの軸で事業を見るようになるかを知っているのは経営だ。CxOレイヤーが関与しなければ、この設計はほぼ必ず外す。「今の業務で必要な項目」を積み上げただけの、変化に弱い器ができあがる。
Greenfield か Brownfield か──IT判断に見えて、経営管理の意思決定だ
移行の方式は3つに整理される。Greenfield（新規構築）、Brownfield（システム変換）、Selective Data Transition（選択的移行＝両者の折衷）。一般にはIT部門が、コスト・期間・リスクで選ぶ「技術の選択」とされる。だが採算と数字の構造から見ると、これは経営管理の意思決定だ。
正直に言えば、Brownfield が選ばれる理由（期間・リスク・コスト）はしばしば妥当だ。問題は、正しい理由で、間違った人が決めていることにある。IT部門が「ITにとって最適」を最適化し、経営管理の要件が机に載る前に方式が確定する。CFOの仕事は、方式が固まる前に、経営管理の要求仕様を先に置くことだ。
「作り変えるCFO」が、スコープに必ず乗せる5つ
移行スコープを議論するとき、CFOが「これは今しか触れない」と釘を刺すべき項目は、おおむね次の5つに絞られる。
- 勘定科目体系の整理——10年使う器。事業や組織の変化で歪んだ科目を、ここで合理化しないと10年引きずる。
- 利益センタ・セグメントの次元設計——「どの軸で儲けを見るか」。事業別・地域別・チャネル別、後から増やせない軸をいま決める。
- 採算分析を account-based の Margin Analysis にするか——前述の「照合を設計で消す」判断。最大の論点。
- 配賦と責任の設計——部門別損益・ROICツリーの土台。誰の数字に何を載せるかは、組織の意思決定構造そのもの。
- 法定と管理の関係——Universal Journal で一本化し切るのか、別建てを残すのか。締めの速さと統制に直結する。
この5つは、いずれも「IT的にはどちらでも動く」。だからこそIT観点では既定値に流れる。経営に効くかどうかで線を引けるのはCFOだけだ。
延命が正解のときもある──だから“意識して”決める
念のため逆も書く。勘定科目体系がすでに整い、管理レポートが機能していて、期限とリスクが支配的なら、Brownfield 寄りの軽い移行が合理的なこともある。本稿は「常にGreenfield」と言っているのではない。
主張は一点だけだ。作り変えるか・固定するかを、CFOが意識して決めているか。既定値のまま、IT観点だけで10年が決まっているなら、それはCFOが意思決定を手放している。延命を選ぶなら、「いま整っているから固定でよい」と能動的に選ぶ。それが手放しとの違いだ。
監修者の視点（現場から）
私が移行の現場で繰り返し見てきたのは、技術ではなく人の問題だ。標準を入れる本来の発想は fit to standard——標準のやり方に業務を寄せ、無駄な作り込みを足さない。ところが移行が始まると、現場はほぼ必ず fit & gap に引き戻す。「うちはここが特殊だ」「今までこうしてきた」。差分を一つずつ拾い、アドオンが膨らみ、標準のはずが現行の焼き直しになる。これが、移行を“載せ替え”に縮める最大の現場メカニズムだ。
そして押し戻すのは、たいてい中間管理職だ。経営（トップ）は標準化のメリットを理解している。現場の若い層（ボトム）も、むしろ新しいやり方に頭が切り替わっている。なのにミドルが、これまでの経験と自分の作ってきたやり方への愛着を盾に、標準への移行を邪魔する。そこで改革は止まる。頭を切り替えていたボトムはやる気をそがれ、トップは「なんで改革がうまくいかないんだ」と吠える。失敗するプロジェクトは、だいたいこの構図にはまっている。
だからCFOとCxOの仕事は、スコープを引くだけでは終わらない。fit to standard を組織の意思として掲げ、ミドルの「特殊だ」を経営の数字で一つずつ問い直すところまでが、作り変えの実装だ。標準から外す例外には、経営の言葉で説明できる理由を求める。ここを現場の力学に委ねた瞬間、どれだけ良いスコープも、なし崩しに延命へ流れていく。
移行の意思決定の場で、CFOが投げるべき問いはひとつに尽きる。「この移行で、勘定科目体系と採算の見方を作り変えるのか、今のまま10年載せ替えるのか」。その答えが、いつの間にかIT観点だけで決まっているなら——そこが、次の10年の資本効率が静かに失われる地点だ。CxOが入らないかぎり、この問いは正しく決まらない。