R/3連携におけるアドオン開発のメリット／デメリット：パッケージ活用とシステム連携のススメ（2）

ERPパッケージ導入では通常、カスタマイズやシステム連携のための開発が行われる。その手段として、アドオンは便利な半面、リスクもある。

[名倉 愛美，＠IT]

　前回は事例紹介を中心にR/3導入プロジェクトでのシステム連携の課題をご紹介しました。

　今回は、特にこれからR/3を導入しようと検討されている方々に、アドオン開発のリスクを認知していただきたいと考え、R/3へのアドオンによるシステム連携とツール連携の比較をしながらの情報提供をしていきます。

　事前にお断りしておきますが、パッケージにアドオンするなということではありません。アドオンすることによるメリットとデメリットを理解したうえで、どうしても自社業務に合わない、あるいは使いにくい部分の開発を決定してください。

そのアドオンは必要ですか？

　アドオン開発を実施する際、表の理由のほかに裏の理由が存在します。

表の理由	裏の理由
標準では機能が足りない	別の方法を調べるより開発した方が楽
標準では使いにくい	エンドユーザーを説得するより開発した方が早い
標準は分かりにくい	機能を勉強していると間に合わない
業務が特殊	BPRは面倒

　ほかにも、SIベンダの事情で自社で抱えるABAP開発者の仕事を作り出さなければならない場合や、自社システム部門でABAP開発者を養成しているユーザーが社内でアドオン開発した方が経費削減になると考える場合などがあります。

　確かにエンドユーザーにとって、「使いにくい」というのは大問題です。だからといって、短絡的にアドオン開発に走る前に、きちんとそのリスクを認識しておく必要があります。

　R/3の導入作業を外部に委託している場合、その委託先のベンダ技術者は本稼働後にいなくなります。運用責任を持つユーザー企業のシステム担当者は、本稼働後に自分たちで管理できる範囲のアドオン開発に収まるよう、事前に運用を想定して設計段階からプロジェクトに参画することをお勧めします。

　R/3などのパッケージアプリケーションは、自社業務用に開発されていた専用システムに比べて自社に関係ない項目がいっぱい入っているのですから、使いにくい面があるのは確かです。

　例えばR/3の伝票登録が大変なのは、世界中のユーザーからの機能追加要求を反映して、かなり欲張ったシステムになっていることが第1の原因です。全体として巨大なパッケージで、各アプリケーション機能がリアルタイムに統合するために複雑に連動し、内部のデータの持ち方も難解です。

　標準トランザクションの動きと、ほかのモジュールに与える影響をしっかり解析した後にアドオン設計しなければならないのはいうまでもありませんが、同時に現行バージョンでは問題ない設計でも、次のR/3バージョンアップ版では関連する標準機能が別の動きをするものに置き換わってしまう可能性が小さくはないことも認識しておく必要があります。

R/3の特徴を知ったうえで、導入を進める

　SAPのドイツ開発センターには、2000人前後の開発者がドアの閉まる個室（2人部屋）でR/3の開発をしています。私も何カ月かそこで開発者の席をもらっていましたので、当時（1993年ごろ）のR/3開発事情を少しご紹介します。

R/3は生きている

　開発者の下には、世界中のユーザーからの開発要求が集まってきます。いまはリリース間隔が長くなりましたが、R/3 4.0ぐらいまでは3カ月周期ぐらいでのリビジョンアップをしていました。その大量の開発要求の中から、標準に取り込むことが決定された機能の開発期間は本当に短いものでした。

　ドイツの開発者はプロ意識を持ち職人的な人が多いので、非常に真面目に仕事に取り組んでいましたが、常にリリーススケジュールに追われているため、テストが不十分なモジュールもあったようです。そのため、出荷と同時にバグレポートがいっぱい上がってきます。1つのリリースでもバグフィックスのためのパッチが大量にあるので、一定期間ごとにサービスパック（パッチの集合）が出てきます。

　プログラムにはバグは付きものですし、R/3ほどの巨大システムにバグが多いのも致し方ないところでしょう。もっとも、SAPのノート検索システム（障害別対応方法の解説ノート）ほど、ユーザーに対してしっかりとバグ対応できているベンダもなかなかないかもしれません。

　R/3は、コアのシステムアーキテクチャがしっかりしており、優れたコンセプトの製品です。そのため、各アプリケーションパーツがバラバラに開発され増殖しても、何とかなってしまうという側面があります。そして、非常にレベルの高い技術者がハイスピードで開発を継続していますから、日々生き物のように変化しているパッケージという認識を持った方がいいでしょう。

パッケージのメリットを享受するには

　長々とシステム連携とは関係ないようなR/3開発の話をしたのは、アプリケーションアドオンへの考え方はインターフェイスにも影響するからです。

　R/3は生き物です。最小単位の細胞がアメーバのようにそれぞれ勝手に成長しています。いままでの汎用機ベースのオーダーメイドシステムと同じ感覚で、そのうえに独自開発を行っていくと、将来的に必ず痛い目に遭います。

　SAPは優れた開発環境をR/3アプリケーションとともに提供していますので、ユーザープログラムを作るのはレガシーシステム時代より簡単かもしれませんが、アドオンはパッケージ本体のアップグレード時に、その本数分相当の作業をユーザーに残します。

　開発を外部委託している場合、本稼働後も常駐してもらう契約でなければ開発者はいなくなってしまいます。後で同じベンダにサポートを依頼しても、当時の開発者を集めることは不可能です。そこで、R/3本体をアップグレードした際、テストで引っ掛かったアドオンプログラムはソースコードを追いかけなければならない羽目に陥ります。

　現在、R/3の最新リリースは4.7Enterpriseです。SAPの正式サポートは通常2リリース前まで──つまり4.5までなのですが、実際には3.x台を大量のアドオンとともに本稼働させ、システムのアップグレードもできずにいるユーザーが少なくないので、サポート期間の特別延長や追加サービス料金で旧バージョンのサポートをするというような対策が行われています。そのため、ユーザーの中にはアップグレードをあきらめて、新バージョンでシステムを一から作り直すところもあるようです。

　システムインターフェイスでも同様です。何億円も掛けてアドオン開発した受発注インターフェイスも本体のアップグレードで使えなくなり、作り直しにまた何億円もの見積もりが出てきて驚いたという話もあります。

　基幹業務にパッケージを導入するということは、常に最新のIT技術基盤を手に入れるというメリットがあります。しかし、それはスムーズな本体アップグレードが可能な状態であってこそだということを忘れないでください。

アドオン開発とツール連携

　R/3システムと帳票システムを連動させる場合を例に、アドオン連携の問題点をもう少し具体的に説明していきましょう。

アドオン開発の問題点

　R/3の標準帳票では対外伝票用の柔軟なフォームオーバーレイ印刷ができないので、帳票ツールにデータを渡して印刷するという方法がごく一般的に行われています。その際、多くの場合、R/3から帳票ツールへのデータ連携はR/3側にABAPでアドオン開発してファイル出力し、帳票サーバへ転送するという方法が取られています。

図1　ABAPアドオンによる出力ファイルを帳票サーバに転送

の部分がR/3へのアドオンプログラムですが、このコーディングで特定条件によるプリンタ振り分けや、フォーム決定、オーバーレイの構造を意識した項目編集をしていると、帳票の種類数分のプログラム開発が必要になります。例えば100社の得意先がそれぞれ別レイアウトの指定納品書を要求していれば、相応の編集ロジックとフォーム・プリンタ決定ロジック＋それらの定義テーブルの開発が必要なのです。もちろん本稼働後に新規帳票、または項目の追加やプリンタ機種、用紙などの仕様変更が発生すると、R/3上のプログラムを修正しなければなりません。

　また、OS上にファイルを置くということは、R/3のアプリケーションサーバ追加やハードウェアアップグレードにも影響を受けるという認識も必要です。

　R/3にはファイル名決定用テーブルが標準で用意されていますので、どうしてもアドオンプログラムでファイル出力する場合は、当該テーブルエントリを設定してそちらを使用されることをお勧めします。ファイルを書くディレクトリ名称をプログラムハードコードする人はいないと思いますが、念のため。

　ファイル転送部分をOSコマンドによるFTP処理などで実現している場合はさらに注意が必要ですから、これらの開発を外部に委託している場合は本稼働前に十分な引き継ぎを受けてください。

標準インターフェイスを利用した開発

　R /3へのアドオンではなく、可能な限り標準インターフェイスを利用したツール連携で実現しておけば、開発工数削減だけでなく運用工数を抑えることが可能になります。

図2　標準インターフェイスから連携ツールに向けてデータ出力

　R/3のトランザクションデータとマスタデータにはほとんどすべてシステム間転送用のメッセージが用意されています。１〜３はすべてGUIによる設定で解決できます。

　標準のデータ出力と転送機能を利用すれば、パッケージのアップグレードだけでなく、ハードウェアなどを含めたシステム環境のアップグレードにも影響を受けにくくすることができます。運用フェイズに入ってからの仕様変更への対応は、GUIによる設定変更で対応可能なので、ソースコードの変更やそれに伴うテスト負荷が大幅に軽減できます。

　帳票ツールの連携でアドオン開発をしてしまう最大の理由は、１の設定が難解で標準メッセージの柔軟性がないという点でしょう。といっても、R/3の設定が難解なのは何もインターフェイスに限った話ではなく、すべてのモジュールが同等に複雑さを持っているのですが、アプリケーションのエンジニアがインターフェイス部分になじみがないので敬遠しているといったところでしょう。

　アプリケーショントランザクション機能と同様、標準メッセージでは対応できない部分も確かにあります。私の経験則では、5種類のデータで連携を取りたかったら、1種類は何らかの機能拡張が必要になります。この部分の対策をきれいに設計するためには、１の設定方法のみならず標準ミドルウェアの動きを理解する必要があり、さらにハードルが高くなってしまうので、柔軟性がないということで片付けられてしまうのでしょう。

ABAPの利点と弱点を知る

　確かにパッケージの特定機能を勉強するより、単価の安い開発者を投入した方が早いというのも、1つの解決策ではあります。ABAPの開発者は一時期、汎用機ベースのCOBOL開発請負の仕事が減少する中で、「ABAPはもうかる」といううわさが業界に広がり、大量に養成されました。そのため、レガシー同様の感覚でR/3ベースの開発を外部委託で行うという流れができてしまった感がありました。ただ、そこで大量養成されたABAP開発者は、技術レベルに大きな個人差があり、アドオン機能の出来栄えや開発工数は、機能設計書からは予測不能な場合がある状態です。

　また実際、大型コンピュータでのプログラム開発に比べて、SAP R/3の開発環境は格段に便利になっていますが、プログラミングのために理解しなければならないRDBベースのクライアント／サーバ・アーキテクチャはそんなに簡単ではありません。

　プログラム単体テストは問題なく終了したけれど、本稼働に入ったら何時間たっても処理終了しないアドオンがあるという話をたまに耳にします。「DBアクセスを意識していない開発をしてしまい、テスト機のデータ量ではプログラムロジックミスに気が付かなかった」「本稼働の環境では複数のアプリケーションサーバが稼働することを認識できていなかった（プロセスデッドロック、テーブルデットロック）」などなど……。さらに、パフォーマンス・チューニング系の話はまた別なのです。

　こうしたトラブルを抱えてアドオン開発が何億円にも膨らみ、プロジェクトが途中で凍結ということにならないためにも、ユーザー側が「パッケージを導入する」という意識、長期的に見たコストパフォーマンスの視点を持つ必要があります。

　R/3をベースにした開発は、ABAPの文法と開発ツールの使い方さえ覚えれば、パッケージ本体の勉強なしで開発に入れるので確かに作業着手までは早いといえますが、全工程を考えるとコーディング・単体テストが不要で、安定した機能ブロックの連結であるツール連携の方が導入時のみならず、運用に入ってからも有利なのは確実といえるでしょう。

この記事に対するご意見をお寄せください　[e-mail]

Profile

名倉 愛美（なぐら まなみ）

株式会社エス・アイ・サービス　コンサルティンググループ マネージャー

名倉 愛美（なぐら まなみ）

株式会社エス・アイ・サービス　コンサルティンググループ マネージャー

国内ITベンダでネットワーク系SEを経験後、1992年からドイツSAP社の日本市場を狙ったシステムR/3ダブルバイト化プロジェクトチームに参加。1993年に日本法人 SAPジャパン設立により、本社から移籍。引き続き、R/3日本語化とSAPジャパントレーニングセンター開設作業を行う。1995年には日本での外部システム連携認定センターの設立作業および各種インターフェイスの認定を実施。1999年、SAP社退社後、SAP R/3のインターフェイスコンサルティング専門会社を設立。SAPのパートナーとしてR/3導入EDI、EAIを中心に事業展開している。

「パッケージ活用とシステム連携のススメ」バックナンバー

• システム連携ツールの選び方
• R/3連携におけるアドオン開発のメリット／デメリット
• なぜ、R/3と外部システムの接続は失敗するのか