R/3 コンサルに必要なABAPスキル

さてさて。
今度はつらつらと、コンサルタントに必要なABAPスキル、というお題目で書いてみたいと思う。


世の中には、アドオン悪玉論というものがる。
いわく、R/3をはじめとするERPパッケージにおいては、アドオン（追加のプログラム開発）はするべきではない。
理由は、以下2点。
・開発工数の増大により、ERPパッケージの短期導入というメリットが薄れる
・バージョンアップのときに、作成したアドオンが足かせになり、工数が増大する
どこそこの雑誌に書いてあることである。


まあ、基本的には間違っていないとは思うが、だからといって、開発がゼロで終わるなんてことはありえない。
ただ、「うまくやるか」どうかが問題なのである。
そして、コンサルがしっかりしていないから、とんでもなく開発工数が増える、なんてことは、世の中ザラにあるのである。


たとえば、である。
受注生産をしている会社にR/3を入れた。
この会社は、予算管理は既存のシステムを温存し、このシステムに、データをI/Fすることになった。
I/Fデータは、受注残ということだったので、R/3上の受注数量・出荷数量・その金額情報をI/Fすることになった・・・


ここまで書いて、「こりゃダメだ」と、思えるようでないと、開発工数を増やしてしまう。
つまり、予算管理システム、ということは、これから発生する見込みの収入と、これから発生する
見込みの支出（原価）が最低限ないと動かない、という常識があれば、上記の仕様は、
発生する見込み収入のみをI/Fしており、後者の考察がなく、どう考えてもおかしいわけである。
「レガシーのシステムのことはわからなくて・・・」
と、ほざくアホがいるが、んなもん「予算管理」というものが、どういうデータを使って行われるか、
その常識があれば、たちどころにわかる話である。
当然、このプログラムは、相次ぐ「仕様の追加」（該当受注に対する製造完了数、購買発注金額、
購買発注に対する入庫済み金額など、見込みの支出情報の項目追加）により、
予定より大幅な工数増加が発生する事態となり、開発担当の残業時間を大幅に増やすこととなった。


また、普通のアドオンテーブルのメンテナンス画面に、凝った画面レイアウトを書いてしまい、
払わなくてもいい金をエンドユーザに払わせる、ちょっと悪質な「無知」も散見される。


どう考えても不幸である。
そして、いわゆるコンサルと開発が別会社だと、さらに悲劇は加速する。
コンサルタントは自分の「無知」を棚に上げ、「開発が遅れて」と遅れた理由を語り、
開発側は、「仕様の変更が多発して」遅れた、という説明を繰り返す。
どちらの言っていることが正しいかわからないエンドユーザが、一番わりを食うわけである。
（あー、いかんいかん。個人的な感情たっぷりの文章になってしまっている・・・）


ということで、開発側が業務側に擦り寄れば、それは立派なコンサルタントであり、上記のような悲劇は、
主にコンサル側に原因がある、との認識に立ち、これから先は、開発されるアドオンの種別ごとに、
その気をつけるべき一般的なポイントを、コンサルタントの立場から書いていこうと思うのである。
題して、R/3 コンサルに必要なABAPスキル、である。


まずは、追加開発の種別を、以下のように大別したい。
・更新系
　標準機能の更新
　アドオンテーブル（トランザクション系）の更新
　アドオンテーブル（マスタ系）の更新
　I/F　Inbound
・出力系
　業務帳票出力
　管理帳票出力（マスタ照会・一覧を含む）
　I/F　Outbound
それぞれにおけるポイントを、さらっと話をしてみようと思う。