約800本のアドオンを抱えた、会計基盤刷新と経営判断

日本郵船株式会社は、海運を中核に物流・不動産・航空貨物などを展開する総合物流企業だ。同社は、グループ約350社が利用していた会計基幹システムを「SAP S/4HANA Cloud Public Edition」へ移行し、2025年7月に本格稼働を開始した。従来のSAP ECCには約800本のアドオンが存在し、それらを整理しながら標準化を進める大規模な刷新となったが、これは単なるシステム更改ではなく、経営判断につなげる基盤再構築でもあった。

SAP ECCは長年安定稼働しており、業務が止まっていたわけではない。しかし、部門ごとの個別最適が積み重なり、標準からの乖離が進行。将来的なアップデートや新技術への対応が難しい状態にあった。NYK Business Systems（NBS）の取締役・常務執行役員の照木氏は、当時をこう振り返る。

「業務面で致命的な問題があったわけではありません。約800本のアドオンで要望に対応していたため、日常業務は回っていました。ただ、将来的な技術進化への対応やSAP ECCのサポート終了を見据えると、このままでは十分とは言えない。業務が動いているうちに手を打つべきだと判断しました」。

海運業は為替や燃料価格、市況変動の影響を強く受ける。決算に必要なデータは取得できていたが、経営判断に資するリアルタイム活用には限界があった。市況データと自社オペレーションデータを組み合わせ、迅速に分析・シミュレーションできる基盤が求められていた。

こうして同社は、単なるシステム更改ではなく、AI活用やデータドリブン経営を見据えた業務プロセスの再設計へと舵を切った。プロジェクトは日本郵船本店が業務変革のオーナーシップを担い、NBSがテクニカル面を統括する体制で進められた。そしてSAP S/4HANA本体の導入および業務変革、プロジェクト全体設計と推進はシグマクシスが担当し、標準外として切り出したSAP BTP領域および周辺システムとのインターフェース構築を伊藤忠テクノソリューションズ（CTC）が担う。SAPジャパンも調整を支援し、全体で約400名規模が並行して開発を進めた。

Fit to Standardを掲げた理由と“ミニマムライン”の設定

今回のシステム刷新はFit to Standardが軸に据えられている。SAPの標準機能を前提に業務プロセスを見直し、過度な作り込みを避ける。標準で補えない領域は基幹の外に切り出し、周辺アプリケーションとの連携で補完する。短期的な最適化よりも、将来のアップデートや拡張への追随性を優先する方針である。

SAP S/4HANA Cloud Public Editionを選択したのも、その方針を徹底するためだ。自由度の高い環境では再び作り込みが進む可能性がある。あえて制約の明確な環境を選ぶことで、標準に寄せる意思を組織として示した。もっとも、実践は容易ではない。標準に合わせる過程では一時的に業務効率が落ちる局面もある。会計基幹として守るべき最低ラインを担保しながら、段階的に整えていく必要があった。NBSの会計・財務システム部副部長の小池氏は、当時について「Fit to Standardを掲げましたが、最も重要なのは決算を確実に締められることです。出納業務を止めないこと、上流からのデータを正しく取り込めることが前提になります。そのため、データ連携の仕様はできる限り変えないという判断もありました。まずはミニマムラインを明確にし、その上で改善していく進め方を取りました」と振り返る。

本プロジェクトでは、SAP S/4HANA本体を極力クリーンに保つ方針が徹底された。標準で対応できない業務や外部連携はSAP BTPへ切り出す構成である。

制約は二つあった。海運特有のトン税や船舶関連処理など、SAP S/4HANA標準機能ではカバーできない業務が存在すること。加えて、上流の既存システムを大きく変更できない一方で、SAP S/4HANA Cloud Public Editionの制約によりSAP S/4HANA側で取得できないデータがあることだ。これらを両立させるため、拡張はSAP BTP上で実装する方針が採られた。

CTCは導入支援サービス「Figues（フィグ）」で蓄積したPublic Cloud環境での実装経験を踏まえ、SAP BTP上での拡張設計を具体化した。実装言語としてはABAP Cloudも選択肢にあったが、最終的にJavaを採用。背景には運用体制と人材戦略があった。

「比較的早い段階でJavaベースにする方向性は決めていました。Steampunk（現在のABAP Cloud）という選択肢もありましたが、保守を統括する立場としては市場での人材調達のしやすさを重視しました。Javaであれば扱えるエンジニアも多いため、状況に合わせた人員調整が行いやすい。もともと内製運用を前提としていましたので、長期的に持続可能な基盤を選ぶ必要がありました」（小池氏）

CTCの田中氏も、Java採用の意義について「Public Cloudでは、従来のABAPだけでなくSAP BTP上でJavaによる開発が可能になります。ABAP技術者は単価も高く、確保が難しい状況ですが、Javaであれば会計知識を持つオープン系エンジニアがSAP S/4HANA開発に関われる。弊社としても数年前から取り組んでいましたが、日本郵船様のような大規模案件で本格的に適用するのは初の挑戦でした」と語る。

こうして、上流システムを大きく変更せず、SAP S/4HANA本体への改修も最小限に抑える構成が確立された。SAP BTPへと接続するインターフェースは約50本。複数の業務システムから流入するデータの整合性を保ったまま会計へ接続する必要がある。さらに、他領域の改修の影響もSAP BTP側で吸収する構造となった。

難易度を高めたのは性能要件だ。会計伝票明細は月次約130万件。開発当初はバッチ処理に7時間近くを要した。

「Java環境では実行特性が異なります。当初は約7時間かかりましたが、本来は2時間以内に収める必要がありました。新環境で性能を落とすことは許されない。並列度や構成を見直し、チューニングを重ねた結果、既存環境と同等まで改善できました」（田中氏）

Public Cloudを前提とした継続変革の基盤構築

2025年7月、グループ約350社を対象とした会計基盤移行は本番稼働を迎えた。

「通常は稼働後数カ月で何らかの課題が顕在化します。特に月次決算で問題が表面化しやすいのですが、今回は重大な障害は発生しませんでした。最初の月次決算も予定通り完了しました」（照木氏）

SAP S/4HANA Cloud Public Editionでは年2回のメジャーアップグレードが適用される。稼働直後および翌2月のアップグレードも大きな影響なく通過した。本番環境での安定稼働とアップグレード耐性は、クリーンコア設計の有効性を示す結果となった。

冒頭にも強調したが、日本郵船におけるSAP S/4HANA Cloud Public Edition導入は、単なるシステム刷新ではない。照木氏は今回のプロジェクトについて「大規模プロジェクトは導入完了で一区切りという空気が生まれがちです。しかし今回は、これがスタートだというメッセージを共有してきました。導入して終わりではなく、ここから継続的に改善していくという認識が根づきつつあります」と語った。

SAP S/4HANA Cloud Public Editionを選択したことで、年2回のアップデートに向き合い続けることは必然となる。つまり、機能追加や仕様変更を受け入れながら業務を更新していく。変化を前提とした基盤への転換は、IT戦略上の大きな決断だった。

最後に照木氏は、CTCとのパートナーシップについて次のように述べる。

「CTCには当社の業務や体制を深く理解していただきました。今後も技術だけでなく、組織や人材も含めて伴走していただきたい。状況を踏まえた具体的な提案を期待しています」。

今後はSAP BTP基盤を活用した高度化やAI活用も視野に入る。クリーンコアを維持した構造であるからこそ、新技術を取り込みやすい。会計基盤の刷新は完了したが、真価が問われるのはこれからだ。変化を前提とした環境のもと、標準化と高度化をどう積み重ねるか。NBSとCTCの協業は、運用フェーズで次の段階へ進んでいる。