ERPのアーキテクチャを比較する 会計システムに用いるソリューションは、メーカーによって開発思想が異なる。 当然だが、開発思想の違いはデータ構造やアプリケーション構成に大きな影響を与える。 そのためソリューションの選定に当たり、開発思想を深く理解することは重要な意味を持つ。 本稿では、会計ソリューションとして多くの企業が採用している独ＳＡＰと米オラクルのＥＲＰパッケージを 帳簿会計や伝票会計といった会計の基礎理論や情報構造など複数の観点から考察する。 ※本稿は日本ユニシス発行の「技報 通巻１０１号」（２００９年8月発行）の記事に加筆・編集して掲載しています。
従来の会計業務は伝票を起こして財務諸表を作成する、というシンプルな構造であり、システム化しやすい分野だった。しかし1990年代後半に入ってからは急激な環境変化、企業個別の管理会計、会計基準の国際化など、多くのニーズへの対応が求められており、会計システムの構造は年々複雑化している。利用するソリューションも独SAPのSAP ERPや米オラクルのE-Business Suite（Oracle EBS）など、大規模かつ広範囲なものとなっている。
ERPパッケージはそのアーキテクチャ、すなわちデータ構造やアプリケーション構成を変えて導入することは推奨されない。このため、表面に現れる機能や利用方法に着目して導入可否の検討を行い、通常はアーキテクチャ面からの分析はなされない。
しかし、ユーザ企業の導入目的、業務方針、文化、システム環境の違いから、選択したソリューションのベースとなる考え方が馴染まないケースも散見される。よって、当該ソリューションのアーキテクチャとそのベースとなる考え方を充分に理解しなければ、データ連携や情報活用、システムの全体最適はもとより、業務の全体最適も実現できない。
本稿では、会計理論の違いがソリューションのアーキテクチャに与える影響やアーキテクチャ検討の重要性を説くと共に、情報システム構築時に検討すべきポイントの具体例を提示する。そのためにまず、伝票会計・帳簿会計の理論、本支店会計、管理会計をその構造面から考察する。続いて、これら会計理論の背景にある考え方の違いがデータ構造やアプリケーション構成に及ぼす影響をSAP ERPとOracle EBSの比較分析を通じて明らかにする。そして最後に、期間損益計算と取引別損益計算の理論を構造面から考察し、データ構造やアプリケーション構成への影響を示す。
財務会計における主要情報の構造を論じる場合、まず着目したいのが帳簿会計か、それとも伝票会計かという点である。帳簿会計とは、すべての取引を都度仕訳帳に記入し、総勘定元帳に転記する帳簿ベースの会計処理をいう。また、帳簿会計の帳簿とは「仕訳帳」と「総勘定元帳」からなる主要簿と、「仕入先元帳」や「得意先元帳」といった補助簿の2つの帳簿組織で構成する（図1）。
こうした帳簿会計をベースにしているソリューションの1つがOracle EBSである。図2のように、仕訳を中心に転記処理を行う帳簿体系を採用しており、仕訳データと残高データを会計帳簿と呼ぶ。
一方の伝票会計は、会計取引を伝票によって記録し、伝票を集計することで総勘定元帳や補助簿を作成する仕組みである。伝票会計により伝票を様々な現場で起票することが可能になるだけでなく、日計表からの合計転記により記帳や集計を迅速に行うことができる（図3）。
こちらはSAP ERPが採用している方式で、図4のような仕組みになっている。SAP ERPでは取引別に起票した伝票明細がすべての帳簿・処理の基礎データとなる（大福帳システム）。
ところが、伝票会計と帳簿会計との間にある考え方の違いは、会計システムでのデータの持ち方や更新順序の違いを生み、会計業務に大きな影響を与える。当然、伝票会計に立脚するか、それとも帳簿会計に立脚するかが会計システムのアーキテクチャに与える影響は大きい。それだけに、採用するソリューションのテーブルや更新タイミングなどまで深く把握して、いずれの方法を採択しているかを判断することの重要性は高い。
具体的には、仕訳が取引ベースなのかサマリーかなのか。取引別損益管理やリアルタイム管理が可能かどうか、補助簿の単位と管理、データ連携方式がどうなっているか。これらに加えて周辺システムでの承認や締めのタイミングなどを踏まえて全体方針を策定することが大切である。
もっとも最近は、本支店勘定は会計単位間で貸借対照表のバランスを保つためだけのもの、という意味合いが強い。帳簿を分けなくても仕訳明細データに多彩な切り口を持たせることで、迅速に集計できるようになったからだ。本支店会計の役割は採算・評価目的より、勘定管理・決済・決算などの会計業務としての便宜に重心を移している。
70ページの図5はSAP ERPによる組織別情報の管理体系を示している。財務会計モジュールは主に会社単位のB/S、P/Lを出力するというシンプルな機能であり、管理会計モジュールによりP/Lをベースとした損益計算書を重視する。また管理会計では組織としての切り口・事業としての切り口などの多様な観点からのフレキシブルな比較を重視している。
一方、Oracle EBSは帳簿の運用がSAP ERPより柔軟であり、1つの帳簿内に会計単位の情報を持ち、会計単位ごとに貸借一致を保証する。管理会計のP/Lにおいて片仕訳※2も許容するSAP ERPに比べると、本支店会計のベースは整っていると思われる（図6）。ただし、厳密に本支店会計を行う場合、振替先での承認や締めの制御、勘定相殺などの機能の追加開発が必要である。
なお、近年の国際会計基準へのコンバージェンスの一環で、貸借対照表の重要度が増してきている。これに伴い、財務会計の機能の中で会社内部の組織で貸借対照表を作成する機能が重視されつつある。SAP ERPにおいても、近年のバージョンでは、会社内部の組織単位での貸借対照表機能が拡充されており、Oracle EBSとの差異は小さくなっている。
SAP ERPの管理会計機能モジュールはコスト管理用、利益管理用といった「利用目的別」に分かれ豊富に存在する（図7）。管理会計のデータは財務会計とは別に独立して存在し、管理会計独自のデータの投入や、シミュレーションが可能になり、簡便かつ柔軟に集計・分析ができるようになっている。
SAP ERPは「利用目的別」にDBを分割することで取り扱う項目・データ構造を個別に定義する。そして専用機能の装備を充実することで、それぞれの分野に特化した細かな業務サポートを可能にしている。
これに対し、Oracle EBSには管理会計モジュールというものが存在しない（図8）。会計データは「財管一致」の前提があるからだ。つまり管理会計のデータとして特に独立を要さず、管理会計における集計項目は、すべて財務会計の仕訳に管理項目として持つ。
Oracle EBSの仕訳明細の項目はSAP ERPのように項目が固定ではなく、会計フレックスフィールド（AFF：Accounting Flex Field）というユーザー定義が可能な領域に自由に定義して利用する。この方法は非常に柔軟かつ簡易で分かりやすく、Oracle EBSの最大の利点といえよう。
その反面、管理会計で利用する情報を財務会計の仕訳明細のどの項目に格納するかについても、原則としてユーザー企業ごとに決定する必要がある。そのため「管理会計の利用目的（何を何の目的でどう管理するのか）」から定義しなければならない。このため、目的を固定した各種の専用機能の提供が難しい。
とはいえ、Oracle EBSはデータ構造をシンプルにして、仕訳を通した情報の統合・格納・活用を支援する各種機能を提供している。SAP ERPのように、データ連携時に仕訳を管理会計と財務会計に振り分けたり、複雑なロジックや目的別DB、専用マスターを管理したりする必要がなくなり、データ連携や活用は比較的容易である。
管理会計システムを構築する際は、これらの特性を考慮することが重要である。業務支援に重点を置く（利用目的別）か、あるいはデータ活用・連携に主眼を置く（財管一致）か、管理会計の「利用目的」や情報系システム（シミュレーション、ダッシュボード）をどのように活用するのかを十分に検討する必要がある。
会計の仕組みは、清算を前提にするか、今後の事業継続を前提にするかによって異なってくる。事業継続を前提とした現代の企業では事業を一定の期間に便宜的に区切って収支を算出することが求められる。この仕組みのことを期間損益計算という（図9）。
期間損益計算の実現だけであれば、会計システムは期次または月次のバッチ処理で足りる。しかし、環境変化の激しい昨今においては、日次での利益管理を行いたいというニーズは多い。また、業種によっては取引ごとに利益を把握したいというニーズもある。
こうしたニーズを取り入れてリアルタイム損益管理を実施するには、取引ごとの損益把握が欠かせない。そこで多くの企業は業務プロセスの見直しやインタフェースのタイミング、コンピュータの処理速度の向上などの対策を施すが、実はそれだけでは実現できない。制度会計そのものが、期次・月次ベースの期間損益計算を前提に作られているからである。リアルタイムで業績を把握するには、売上原価対立法による勘定記入が必須になる。
売上原価対立法とは、商品の入庫の都度、商品/買掛金の仕訳を起こす方法だ。売上時に売掛金/売上という仕訳のほかに、売上原価/商品という仕訳を起こす。売上と原価がタイムリーに仕訳され、相互に関連付けておくことで取引別の損益が都度把握できる。ただし、この方法を採択するには、商品を入出庫するたびに記帳・把握（継続記録法による在庫管理）し、商品払出単価を決定する必要がある。
商品売買の記帳方法として多くの企業が用いている方法に三分割法がある。商品売買を繰越商品、仕入、売上の3つの勘定で記帳するもので、繰越商品は前期末の在庫額が記載され、期末に当月末の期末在庫額が仕訳されるまで更新されない。簡便な方法だが、バッチベースでの運用になる。
具体的には、在庫管理システムで在庫払出単価を決定できるようにする。取引単位の利益を把握するために、販売管理システムで販売伝票と出庫伝票を関連付けて管理できるよう基本構造を変えなければならないケースもある。
ユーザー企業が独自開発したシステムを含め、幅広い選択肢を想定しているOracle EBSは、モジュール間の疎結合を重視している。言い換えれば、それぞれ独立したモジュールをインタフェーステーブルを介してデータ連携させて、最終的に仕訳で管理するというバッチベースの考え方に立脚している。そのためインタフェースの間隔を短くすることで「擬似リアルタイム」の仕組みを実現することはできるが、厳密な意味でのリアルタイム損益把握の実現は難しい。
他方、SAP ERPは業務統合を目指した密結合のパッケージである。在庫元帳と会計がリアルタイム統合されており、移動平均原価を含め取引別リアルタイム損益把握が可能である。しかし、単価の後決めや一括請求などの商慣行を反映したリアルタイム業績把握を実現するには、他システムの改良や業務改善が必要になってくる。
会計以外のアプリケーションのアーキテクチャが業績把握のタイミングの制約になり、会計システムのアーキテクチャ決定に影響を及ぼすことは珍しくない。このため会計のリアルタイム性を高めるには会計以外のシステムのアーキテクチャについても幅広く分析対象を広げなければならない。
当然だが、密結合のシステムから疎結合のシステムへの変換は負荷が高い。このため今後はアプリケーション連携をはじめとするインフラ面でのアーキテクチャの検討も避けて通れない。
繰り返しになるが、SAP ERPとOracle EBSとの間には会計の基礎理論と開発思想に大きな違いがある。自社の会計により適したシステムを構築するには、アーキテクチャをしっかりと分析して、ソリューション全体の開発思想を推察・類推することが必要である。
ERPパッケージはそのアーキテクチャ、すなわちデータ構造やアプリケーション構成を変えて導入することは推奨されない。このため、表面に現れる機能や利用方法に着目して導入可否の検討を行い、通常はアーキテクチャ面からの分析はなされない。
しかし、ユーザ企業の導入目的、業務方針、文化、システム環境の違いから、選択したソリューションのベースとなる考え方が馴染まないケースも散見される。よって、当該ソリューションのアーキテクチャとそのベースとなる考え方を充分に理解しなければ、データ連携や情報活用、システムの全体最適はもとより、業務の全体最適も実現できない。
本稿では、会計理論の違いがソリューションのアーキテクチャに与える影響やアーキテクチャ検討の重要性を説くと共に、情報システム構築時に検討すべきポイントの具体例を提示する。そのためにまず、伝票会計・帳簿会計の理論、本支店会計、管理会計をその構造面から考察する。続いて、これら会計理論の背景にある考え方の違いがデータ構造やアプリケーション構成に及ぼす影響をSAP ERPとOracle EBSの比較分析を通じて明らかにする。そして最後に、期間損益計算と取引別損益計算の理論を構造面から考察し、データ構造やアプリケーション構成への影響を示す。
会計の基礎理論からみたSAP ERPとOracle EBS
財務会計でしばしば論点となるテーマのうち会計システムの構造に大きな影響を与えるものに、帳簿会計と伝票会計、本支店会計という3つがある。最初にこれらの考え方を整理しながら、SAP ERPとOracle EBSとの違いをみていく。財務会計における主要情報の構造を論じる場合、まず着目したいのが帳簿会計か、それとも伝票会計かという点である。帳簿会計とは、すべての取引を都度仕訳帳に記入し、総勘定元帳に転記する帳簿ベースの会計処理をいう。また、帳簿会計の帳簿とは「仕訳帳」と「総勘定元帳」からなる主要簿と、「仕入先元帳」や「得意先元帳」といった補助簿の2つの帳簿組織で構成する（図1）。
図1 帳簿会計の体系（画像をクリックで拡大）
図2 Oracle EBSの会計帳簿（画像をクリックで拡大）
図3 伝票会計の体系（画像をクリックで拡大）
図4 SAP ERPの会計伝票と帳簿（画像をクリックで拡大）
テーブル更新タイミングに加え仕訳や連携方式も把握する
伝票会計は取引単位に起票するものだが、仕訳に関しては必ずしも取引単位である必要はない。他方、帳簿会計は転記前に承認や変更をするなど、帳簿を独立させて柔軟に運用できる。いずれも手作業による記帳をベースとした考え方である。システム化が進んでいる現代は、どちらの方式であっても帳簿や伝票を情報システム上で共有することで、記帳の分業や集計の省力化を図ることができる。ところが、伝票会計と帳簿会計との間にある考え方の違いは、会計システムでのデータの持ち方や更新順序の違いを生み、会計業務に大きな影響を与える。当然、伝票会計に立脚するか、それとも帳簿会計に立脚するかが会計システムのアーキテクチャに与える影響は大きい。それだけに、採用するソリューションのテーブルや更新タイミングなどまで深く把握して、いずれの方法を採択しているかを判断することの重要性は高い。
具体的には、仕訳が取引ベースなのかサマリーかなのか。取引別損益管理やリアルタイム管理が可能かどうか、補助簿の単位と管理、データ連携方式がどうなっているか。これらに加えて周辺システムでの承認や締めのタイミングなどを踏まえて全体方針を策定することが大切である。
支店ごとの評価を実現する本支店会計の考え方と情報構造
財務会計における主要情報の構造を規定する方法に本支店会計がある。本支店会計とは、支店が独自の帳簿に取引の内容を記帳し、支店ごとに決算する会計の仕組みだ。支店を独立して評価する目的で古くから多くの企業が採用してきた。本支店会計は以下の順番で処理する。- 支店内取引は当該支店の帳簿のみに記帳
- 本支店間取引は振替先・振替元双方に伝票起票、双方で承認後それぞれの帳簿に記載
- 決算時は、本店・支店勘定を照合し、現物や通知が未到達の取引の処理を実施
- 全社合算後、支店の本店勘定と本店の支店勘定を相殺
- 社内仕入・社内売上を照合・相殺
もっとも最近は、本支店勘定は会計単位間で貸借対照表のバランスを保つためだけのもの、という意味合いが強い。帳簿を分けなくても仕訳明細データに多彩な切り口を持たせることで、迅速に集計できるようになったからだ。本支店会計の役割は採算・評価目的より、勘定管理・決済・決算などの会計業務としての便宜に重心を移している。
「ワンファクト」重視のSAPと帳簿の運用が柔軟なOracle
本支店会計は財務会計と管理会計の機能分割はもとより、会計システムによるデータの持ち方にも影響を与える。このためビジネスとしての貸借対照表の重要度、ワンファクト・ワンプレース※1やリアルタイム性の重要度を確認したうえで、支店ごとのアプリケーションの配置や本支店取引のボリュームとパターン、支店内の会計と業務システムの関連性などを把握することが必須となる。では、本支店会計の視点でSAP ERPとOracle EBSをみてみよう。
※1 事実（Fact）が1カ所だけに記録されているという意味。1つのデータは1つしか存在させないという考え方。
SAP ERPは、「事実は1カ所にしかない」というワンファクト・ワンプレースを重視しており、本支店間取引を2つの取引に分けて伝票起票する考え方は馴染まない。本支店双方での伝票の承認は、SAP ERPのリアルタイム処理の考え方にも相容れない。70ページの図5はSAP ERPによる組織別情報の管理体系を示している。財務会計モジュールは主に会社単位のB/S、P/Lを出力するというシンプルな機能であり、管理会計モジュールによりP/Lをベースとした損益計算書を重視する。また管理会計では組織としての切り口・事業としての切り口などの多様な観点からのフレキシブルな比較を重視している。
図5 SAP ERPによる組織別情報の管理体系（画像をクリックで拡大）
※2 貸借バランスしない仕訳。通常はシステム内で入力できないように制限がかけられている。
図6 Oracle EBSにおける組織別情報の管理体系（画像をクリックで拡大）
業務支援か、財管一致か管理会計機能に見る違い
会社内部の業績評価・業績管理、いわゆる管理会計のデータをどのように管理するかという問題も、会計システムの構造を論じる上で大きな課題だ。管理会計とは、経営者のための企業内部の管理を目的とする会計である。管理会計には様々な手法・分野があり、近年ではバランス・スコアカード（BSC）や活動基準原価計算など多彩な管理の仕組みが開発されてきた。なお、本支店会計も管理会計の一部ではあるが、決算の便宜という観点から財務会計の部分で検討した。SAP ERPの管理会計機能モジュールはコスト管理用、利益管理用といった「利用目的別」に分かれ豊富に存在する（図7）。管理会計のデータは財務会計とは別に独立して存在し、管理会計独自のデータの投入や、シミュレーションが可能になり、簡便かつ柔軟に集計・分析ができるようになっている。
図7 SAP ERPのモジュール構成とデータ構造（画像をクリックで拡大）
これに対し、Oracle EBSには管理会計モジュールというものが存在しない（図8）。会計データは「財管一致」の前提があるからだ。つまり管理会計のデータとして特に独立を要さず、管理会計における集計項目は、すべて財務会計の仕訳に管理項目として持つ。
図8 Oracle EBSのモジュール構成とデータ構造（画像をクリックで拡大）
その反面、管理会計で利用する情報を財務会計の仕訳明細のどの項目に格納するかについても、原則としてユーザー企業ごとに決定する必要がある。そのため「管理会計の利用目的（何を何の目的でどう管理するのか）」から定義しなければならない。このため、目的を固定した各種の専用機能の提供が難しい。
とはいえ、Oracle EBSはデータ構造をシンプルにして、仕訳を通した情報の統合・格納・活用を支援する各種機能を提供している。SAP ERPのように、データ連携時に仕訳を管理会計と財務会計に振り分けたり、複雑なロジックや目的別DB、専用マスターを管理したりする必要がなくなり、データ連携や活用は比較的容易である。
管理会計システムを構築する際は、これらの特性を考慮することが重要である。業務支援に重点を置く（利用目的別）か、あるいはデータ活用・連携に主眼を置く（財管一致）か、管理会計の「利用目的」や情報系システム（シミュレーション、ダッシュボード）をどのように活用するのかを十分に検討する必要がある。
即時性や取引先別損益計算に不可欠な売上原価対立法
続いて、リアルタイム性の重要度と情報システムのアーキテクチャに及ぼす影響を考える。まずはリアルタイム会計と会計情報の更新について整理する意味で、「期間損益計算」という会計の前提を解説する。そのうえで取引別損益計算の必要性や、商品売買の勘定記入の方法である三分割法、各種在庫評価方法の特徴を説明し、リアルタイム損益管理の観点からSAP ERPとOracle EBSを比較する。会計の仕組みは、清算を前提にするか、今後の事業継続を前提にするかによって異なってくる。事業継続を前提とした現代の企業では事業を一定の期間に便宜的に区切って収支を算出することが求められる。この仕組みのことを期間損益計算という（図9）。
図9 期間損益計算と取引別損益計算（画像をクリックで拡大）
こうしたニーズを取り入れてリアルタイム損益管理を実施するには、取引ごとの損益把握が欠かせない。そこで多くの企業は業務プロセスの見直しやインタフェースのタイミング、コンピュータの処理速度の向上などの対策を施すが、実はそれだけでは実現できない。制度会計そのものが、期次・月次ベースの期間損益計算を前提に作られているからである。リアルタイムで業績を把握するには、売上原価対立法による勘定記入が必須になる。
売上原価対立法とは、商品の入庫の都度、商品/買掛金の仕訳を起こす方法だ。売上時に売掛金/売上という仕訳のほかに、売上原価/商品という仕訳を起こす。売上と原価がタイムリーに仕訳され、相互に関連付けておくことで取引別の損益が都度把握できる。ただし、この方法を採択するには、商品を入出庫するたびに記帳・把握（継続記録法による在庫管理）し、商品払出単価を決定する必要がある。
商品売買の記帳方法として多くの企業が用いている方法に三分割法がある。商品売買を繰越商品、仕入、売上の3つの勘定で記帳するもので、繰越商品は前期末の在庫額が記載され、期末に当月末の期末在庫額が仕訳されるまで更新されない。簡便な方法だが、バッチベースでの運用になる。
疎結合と密結合の違いでリアルタイム性に特徴
最後に会計システムをバッチベースから真の意味でのリアルタイムに移行する視点で、Oracle EBSとSAP ERPの特徴をみていこう。言うまでもないが、バッチからリアルタイムへのシステム移行は業務的にも技術的にも難易度が高い。改修対象となるシステムが勘定を記入する会計システムの周囲に及ぶからだ。具体的には、在庫管理システムで在庫払出単価を決定できるようにする。取引単位の利益を把握するために、販売管理システムで販売伝票と出庫伝票を関連付けて管理できるよう基本構造を変えなければならないケースもある。
ユーザー企業が独自開発したシステムを含め、幅広い選択肢を想定しているOracle EBSは、モジュール間の疎結合を重視している。言い換えれば、それぞれ独立したモジュールをインタフェーステーブルを介してデータ連携させて、最終的に仕訳で管理するというバッチベースの考え方に立脚している。そのためインタフェースの間隔を短くすることで「擬似リアルタイム」の仕組みを実現することはできるが、厳密な意味でのリアルタイム損益把握の実現は難しい。
他方、SAP ERPは業務統合を目指した密結合のパッケージである。在庫元帳と会計がリアルタイム統合されており、移動平均原価を含め取引別リアルタイム損益把握が可能である。しかし、単価の後決めや一括請求などの商慣行を反映したリアルタイム業績把握を実現するには、他システムの改良や業務改善が必要になってくる。
会計以外のアプリケーションのアーキテクチャが業績把握のタイミングの制約になり、会計システムのアーキテクチャ決定に影響を及ぼすことは珍しくない。このため会計のリアルタイム性を高めるには会計以外のシステムのアーキテクチャについても幅広く分析対象を広げなければならない。
当然だが、密結合のシステムから疎結合のシステムへの変換は負荷が高い。このため今後はアプリケーション連携をはじめとするインフラ面でのアーキテクチャの検討も避けて通れない。
機能面の比較だけに終始せず理論や思想にも視野を広げる
とかく機能を比較されるSAP ERPとOracle EBS。もちろんソリューションごとに異なる機能の特徴を知ることは重要だが、表面的な違いばかりに目が向いてしまうことは避けたい。結果として、導入目的に合致しないソリューションを採択することになりかねないからだ。とりあえず稼働させることはできたとしても、稼働後の変化への対応やデータ活用、システム拡張の局面で思わぬ壁にぶつかることは十分に考えられる。繰り返しになるが、SAP ERPとOracle EBSとの間には会計の基礎理論と開発思想に大きな違いがある。自社の会計により適したシステムを構築するには、アーキテクチャをしっかりと分析して、ソリューション全体の開発思想を推察・類推することが必要である。