1. 平成16年度 プロジェクトⅠ 春休みレポート
専修大学ネットワーク情報学部
NE14-0116B 荒浪一城
平成16年度 プロジェクトⅠ 「ERPシステムの開発」
・ERPとは何か？を理解する
特に、財務会計システムや販売管理システムとはどう違うのかを明確にしておく
・実装はクライアント・サーバー型かWeb型か？その利害得失を評価する
大学における開発環境の制約、参考事例の多さ、今後のシステム開発の動向などを
考慮して判断する仮に、Web型を採用した場合、.NETかJavaかを（その他の選択肢
を含めて）判断する
指導：本江 渉 先生
メンバー：源藤 司郎、本多 蔵人、平山 欣央、山本 瑛安、佐野 哲平、小嶋 聡
史、 黒田 充紀、寺地 亮人、荒浪 一城、丸 祥造、旭 俊治
1. ERPとは何か？を理解する
特に、財務会計システムや販売管理システムとはどう違うのかを明確にしておく
1.1 ERPとERPパッケージの違い
ERP（Enterprise Resource Planning）は、企業資源計画（管理）又は統合基幹業務と訳さ
れる。ERPは、生産や販売、物流、在庫、財務会計、人事といったあらゆる企業の中で

2. 共通した業務を一元的にリアルタイムで管理し、経営へ貢献していく概念のことを指す
。
ERPパッケージとは、会計データベースを中心に生産や販売、物流、在庫、財務会計、
人事などの企業の基幹業務を一つのシステムに統合し、ERPを実現するためのツールの
ことである。
1.2 ERPパッケージにおけるデータの流れ
財務会計とは、外部の株主や投資家向けの情報であり、管理会計は会社内部の資料とし
て用いるための会計である。ERPパッケージのシステムでは、ロジスティクス、財務会
計、管理会計、データウェアハウスという順にデータがおおまかに流れていく。下流行
程に位置する管理会計は、そのデータを財務会計システムより引き受けることとなる。
従って、管理会計システムは財務会計システムより作成された会計伝票情報が必要不可
欠な依存性の高い（密結合な）システムであり、管理会計システムを導入する場合には
両システムを同時に導入する必要が生ずる。
このことから会計システムに関するERPパッケージは、会計制度（財務諸表を作成）の
ためのシステムと管理（各種指標を作成）するためのシステム間が一体化したものが望
ましい。さらには、最終工程であるデータウェアハウスは、各種データのトレースを行
い経営戦略上重要な各種指標からエンドユーザーの各種分析用を作成提供する。これら
の機能を有することは、ERPパッケージの導入の大きな利点であることからも、データ
ウェアハウスは会計システムと連携していることが望ましい。
1.3 既存ERPパッケージのユーザインターフェース
それでは、既存のERPパッケージはどのようなユーザインターフェース（UI）を採用し
ているのか、代表的な製品について調べてみた。その結果、ERPパッケージは最も一般
的なクライアントアプリケーションがベースとなっており、その上でマルチデバイス対
応などのために、Web型にも対応していることがわかった。例えば、最大手のドイツ
SAP社の「SAP R/3」は1992年にリリースされているが、インターネットの普及して
いない当時では当然のことながら、クライアントアプリケーションである。インターネ
ットの普及した1999年にリリースされた「mySAP.com」ではWebブラウザ、Javaアプレ
ットなどのマルチデバイスに対応した様々なUIを提供している。しかし、最もベース
となるUIは現在でもクライアントアプリケーションである。

3. 2 実装はクライアント・サーバー型かWeb型か？その利害得失を評価する
大学における開発環境の制約、参考事例の多さ、今後のシステム開発の動向などを
考慮して判断する仮に、Web型を採用した場合、 .NETかJavaかを（その他の選択
肢を含めて）判断する
例： Apache + Tomcat + JavaServlet、IIS + ASP.NET + VisualStudio.NET etc...
2.1 システム構成の変遷
ERPパッケージの作成というプロジェクトを推進していく上で、システムのアーキテク
チャについて考えてみたい。まずは、これまでの業務システムの変遷を振り返り、そこ
から学べることをまとめてみる。また、現在の問題点と最近の傾向についてもまとめる
。
対象となる業務システムのアーキテクチャを決定する際の参考とするために、システム
構築の歴史を振り返ってみたい。システム構築の歴史を紐解いてみると、面白いことに
集中と分散を交互に繰り返している。現在のIT業界での主な案件は、レガシーシステム
と呼ばれるメインフレームとクライアント・サーバーから構成されるシステムのWeb型
への移行である。そもそもメインフレームが終焉を迎えた理由は、一人一台のコンピュ
ータを利用するという形が定着し、クライアントの数が急速に増加、個々の処理するデ
ータ量も増え続けたことによって、メインフレームによる集中的な処理の限界が露呈さ
れることとなったからである。
そこで負荷分散が可能な、クライアント・サーバー型が広く普及し、現在では運用面に
大きな問題が生じている。大量のクライアントを一元的に管理する作業が必要となり、
管理ツールなどの導入コストも発生している。これらの経緯から、運用面の問題を回避
するためWeb型への移行がなされてきている。次にそれぞれのシステム構成について詳
しく見ていきたい。
2.2 クライアント・サーバー型の発展経緯と現状課題
クライアント・サーバー型について詳しく見ていく。クライアントマシンの価格低下と
性能向上とが重なり、データをメインフレームへの送信する前に、一定の処理行うこと
で負荷分散が可能となった。これにより、メインフレームの抱えていた問題を回避する
ことができたが、運用面で限界が露呈することとなった。個々のクライアントマシンへ
のインストール作業や設定、バージョンアップによる更新作業に非常に多くの労力とコ

4. ストを割かれることとなったからである。また、クライアントマシンにインストールさ
れているDLL（Dynamic Link Library）のバージョンが異なることによって生じる、いわ
ゆる「DLL地獄」という問題も管理者を悩ませている。特定のバージョンへの依存によ
って、セキュリティーパッチを適用することができないという問題も発生している。マ
イクロソフトの.NET Frameworkでは、Side-by-side 実行により同一のファイル名であっ
ても異なったバージョンを共存させ、バージョン依存問題を回避することができる。
2.3 Web型の発展経緯と現状課題
このような運用面の負荷という問題を解消する手法として注目されているのが、Web型
への移行である。Web型には、アプリケーションの配布やインストール作業の必要がな
いといった運用上の大きなメリットがある。インターネットの急速な普及とブロードバ
ンド環境の整備により、OSに標準的に組み込まれているブラウザに対する抵抗感もな
く、ブロードバンド環境により表示やダウンロードもスムーズに行うことが可能となっ
ている。このようなことから、Webアプリケーションは様々な分野で幅広く使用されて
来ている。
もちろん、Web型にも問題はある。それはクライアント・サーバー型に比べ、本来は情
報を表示することを目的としたブラウザを用いるため、操作性やスループット（レスポ
ンス）などの点で専門的用途に開発されたクライアントアプリケーションに比べ劣り、
エンドユーザーからの評判が悪い。つまり、保守性・拡張性で開発者や運用担当者がメ
リットを享受する分、エンドユーザーが操作性やスループットの面でそのデメリットを
受けるという構図になっている。従来のクライアントアプリケーションは、ユーザーの
細かな使い勝手に関する要望を反映することができたが、そうしたことも機能的制約か
らできなくなる可能性がある。また、当然の事ながらサーバーへの負荷は高まる。業務
システムをWebアプリケーションで構築したとすれば、サーバーが停止すれば業務も停
止することになり、装置の二重化など障害対策が必須となる。耐障害性は、その度合い
により指数関数的にコストが膨らむことから、留意する必要がある。
2.4 リッチクライアントの発展経緯と現状課題
近年ではそれらの諸問題を解決するために、クライアント・サーバー型とWeb型の両方
のメリットを取る形で、リッチクライアントが注目を集めている。豊富なロカールリソ
ースを利用可能で機能とGUIが充実した「ファットクライアント」、サーバサイドによ
る貧弱な機能とGUIによる「シンクライアント」、インストールが不要またはオートア
ップデートによる管理の容易さを持つ中間的な存在であるリッチクライアントをマイク
ロソフトでは「スマートクライアント」と呼んでる。

5. 具体的なものとしては、次のような製品が挙げられる。アクシスソフト社のブラウザソ
フトウェア「Biz/Browser」、カール社のWebプログラミング言語「Curl」、マクロメデ
ィア社の代表的なアプリケーション「Flash」、マイクロソフト社の.NET Frameworkで
採用されているノータッチデプロイメントをさらに強化した「ClickOnce」などである
。ノータッチデプロイメントとは、クライアントアプリケーションを自動更新するなど
、Webアプリケーションの利点をクライアント環境に持ち込むための仕組みである。最
も有名な製品は「Flash」であるが、業務向けのシステムに特化しているわけではない
。とりわけ、「Biz/Browser」と「Curl」はリッチクライアントに特化した製品であり、
現在注目を集めているところである。これらの商用製品の採用は価格的に難しい面があ
るものの、「Flash」については学校のコンピュータに既に導入されているので採用可
能ではないかと思われる。マイクロソフト社の「ClickOnce」は、次世代OS Longhorn
（ロングホーン）に組み込まれる予定のものであり現在開発途中である。
2.5 フレームワーク .NET & Java
これらのことから、Webアプリケーションの採用による操作性やレスポンス低下を最小
限に抑えることを優先すれば、リッチクライアントである「Biz/Browser」や「Curl」を
採用検討するところではあるが、今回の制約を考慮すれば、Web型でもリッチクライア
ントではなく、.NETかJ2EE（Java）のいずれかのフレームワークを採用することが現
実解となるであろう。

6. .NETとJavaのWebアプリケーションアーキテクチャ比較図
どちらのフレームワークを採用すべきかを考えた場合、フレームワークの優劣を考慮す
べきだが、どちらのフレームワークも優れており、その点で議論を重ねてもあまり意味
があることではない。実際の現場でも、どちらも多く採用され使われているからである
。実績では、小規模システム.NETが多く、大規模システムではJavaとなる。
2.6 開発作業フェーズへの移行準備
.NETかJ2EE（Java）かを考える上で、どちらにも共通することがある。開発環境を構
築、設定し、HelloWorldプログラムから簡単なサンプルアプリケーションへ、そして
ERPパッケージのプログラミングを行うという一連の作業過程である。開発言語として
、JavaまたはC#を採用すれば、それらの過程をスムーズに通過できると考えられる。し
かし、それぞれのフレームワークを利用すること自体はほとんどの場合初めてである。
.NETを採用した場合には、IISを搭載しているWindows上にMSDNAA（MSDNアカデミ
ックアライアンス）を利用しVisualStudio.NET 2003などをインストールすることで、
MSDNライブラリを用いて即座に開発フェーズに移行することができる。しかし、Java
を採用した場合には様々なオープンソースソフトウェアの利用が考えられてくる。
Javaを採用した場合に考えられる開発環境の例には、Jakarta（ジャカルタ）プロジェク
トにより開発されているWebサーバー「Apache」、アプリケーションサーバー「Tomcat

7. 」、Webアプリケーションフレームワーク「Struts（ストラッツ）」が考えられる。ま
たIDE（統合開発環境）としてはEclipseが挙げられる。その他に、「PHP」、「MySQL
」、「Ant」などのツールを導入し、それぞれが利用可能かつ連携をはかるように設定
する必要がある。実際にそれらを使えるように準備をし、開発環境を整備することに非
常に多くの時間が割かれる。このことから、.NET Frameworkを採用することで生産性
の高い開発が実現する
ことができるとわかる。
2.7 まとめ
開発環境整備の中でも学べることが多く、オープンソースソフトウェアを利用したWeb
アプリケーションのおもしろみを感じたのは「Java」である。仮に顧客に対する提案や
短期開発などの効率性を重視する開発であれば.NET Frameworkを採用すべきであろう
。仮に技術的を身につける目的であれば、Javaを採用すべきだと感じた。また、時間的
猶予があるならば、両者のフレームワークを利用しプロトタイプ開発を行い、メンバー
の実感により最終決定するのも良いと考える。