アドオン
SAP標準に存在しない機能やそれを追加すること、またはSAPで提供されている拡張機能の実装を意味する。
標準機能をうまく利用しているプロジェクトは少なくないが、Add-onがないプロジェクトはない。
なお、開発そのものや考え方についても便宜上ここに含めた。
具体的な命令や用法については、ABAPの項を参照されたい。
概要 †
はじめに、まず、ERPパッケージたるSAPにおける開発は、それ以外の作りこみシステムetcとは大きく異なるということ。
何が違うかというと、まず主にはなり得ず従であるということ。
具体的には、入力系の話で言えば、標準にない標準同士の繋ぎであったり、取っつきにくい入力を補助したり、後続処理を担保するために細かいチェックを入れたりが該当する。
出力系の話で言えば、そもそも標準にないものを作ったり、標準のレポートや画面で取り扱っていない切り口でレポーティングしたり、標準では複数のレポートを併用しなければ見えないので単一機能にまとめたり・・・がこれにあたる。
という風に、如何にシステムにデータを入力し、如何に結果を照会するかという、あくまでSAPというシステムが主役であって、Add-Onは脇役であることを念頭に置くべきだと考える。
脇役に過ぎないAdd-Onが、分を弁えずに標準と同等かのような役割を与えてしまうと、当然SAPはそんな存在を考慮して作られていないので、それなりのしっぺ返しに見舞われることになる。
例えば、筆者は営業員単位で在庫を引き当てるというアドオンを見たことがある。
これは総数と引当済数量をアドオンテーブルに保持し、伝票を切るごとに取り崩していくという動きとなるが、こんなもの当然ながらまともに動くわけがない。
そもそも会計的な目線でなくロジ的な目線で言えば「組織別に在庫を持つべきではない」というBPRをするべきであるし、それでも顧客からの強い要望があれば従業員を保管場所として定義するなどSAPのデザイン或いはコンフィグレーションの範疇の中で吸収すべきであったが、調子に乗って標準と同等の振る舞いを与えてしまったせいでいつまでもバグが片付くことはなかった。
これが、主従関係を弁えるべきということである。
定義 †
SAPはコンフィグにより、諸々の業務ニーズに対応可能なシステムであり、標準機能の範囲内で使用している限り、導入工数も導入後のメンテ工数も減免することが可能である。
しかしながら、標準にない = 標準が想定しない業務要件に対応する為には、何らかの手を加える必要があり、標準設定にない機能、レポート、インタフェース、移行用プログラム、拡張機能の追加すべてをアドオンと呼ぶこととする。
性質ごとの分類 †
RICEFという括りである程度の区分けが可能である。（参照）
- Report
データをかき集めて表示する系。レポートの項参照。
- Interface
無理やり詰め込むことが必ずしも正しいとは思わないが、気安く繋いでいる事例が多すぎる。
また、誰も喜ばない割にアラばかり目立つため、個人的には一番嫌いなI/F。インタフェースの項参照。
- Conversion
Migrationと呼ぶのが一般的だが、いわゆる移行ツール。
移行の項参照。
- Form
いわゆる紙モノ。フォームの項参照。
要否の判定 †
大抵はFit&Gap分析でGapとなり、且つBPR対象とならないもの或いはBPRの結果「アドオン開発で実施すべきもの」となったものを対象とする。
が、期間も要員も限りあるため、通常どのプロジェクトでも総量規制を行う。
しかしながら、「これが無いと仕事にならない」etcの業務側ニーズとプロジェクト予算という制約とは、物凄いお金持ちかつ長期間でもない限り相反してしまうため、すべての吸収は難しい。
そこで重要なのは、採否判定（取捨選択）のプロセスである。
- 基準の明確化
プロジェクトが完了し、「このプロジェクトは成功した」と言えるかは、プロジェクト目標が達成されたか否か、あるいはどの程度達成されたかによって異なる。
つまり、「このプロジェクトは成功した」にビタ一文無関係なものはやらないという判定が可能である。
また、代替機能がないもの、膨大な伝票数をさばくために手順の簡素化が必須なものなども観点として挙げられる。
例えば、
- 現状業務に合わせてシステムを作るのではなく、SAP標準に合わせた業務の再設計（BPR）を優先
- 部署ニーズより会社ニーズ、会社ニーズよりグループニーズなど、個別最適よりも全体最適を優先
- 業務遂行上、著しい工数負荷が生じない場合は切り捨て
- 法制度要件、顧客からの要請、顧客へのサービスレベル低下は対応
など、平等かつ定量的な基準を設けることで私見のみでない判断ができ、これを継続して実行することが肝要かと思う。
- 手続き
数がある程度溜まってしまう前に、関係各位で適宜ミーティングを行う。
このミーティングは、背景の説明などの目的で当事者の参加が必要となるため、進捗確認とは別セッションで実施することが良いかと思う。
もし未判定案件が溜まってしまうと、手戻りを含め後続作業に及ぼすインパクトは大きくなるため、案件ベース或いは週次で行うこと、積み残しなく実施することが重要である。
開発プロセス †
品質管理について †
ひどいのになるとコンパイルが通れば・・・という人間もいるが、これに留まらず、作り手はもう少し品質に敏感であってもいいと思う。
「じゃあバグをゼロにしろっていうのか！」なんていうアメーバ未満のクリーチャーは置いといて、下記の観点で品質を担保し、メンテナンスを平易としていくべきと考える。
導入時の欠陥が少ないこと †
これは分かりやすい定義で、要はバグがないということ。
必要充分な試験が実施され、結果が開発物に反映されているということ。
エラー検知の仕組みが確立されていること †
上記のバグが少ないに留まらず、ショートダンプの回避や例外処理を含めエラーハンドリングが正しく設計/実装されている必要がある。
下手をすると、処理結果と出力メッセージが一致していなかったりすることもある。
顧客満足度が高いこと †
上記のふたつの指す品質と此処で意味する品質は毛色が違い、要は必要な機能を盛り込み、つかいやすいプログラム（機能）であるということ。
アドオン判定の中でテーマ別の採否判定のほか仕様レベルの簡素化をする場合があるが、満足度が低いケースは大抵これである。
悪戯にスコープを広げたりは当然できないし、期間も要員も有限であることを鑑みれば軽々に言えることではないが・・・
デグレが起こりづらいこと †
仕様変更の無いプログラムは無い。
つまり、修正を前提とした構造となっていなければならないのだが、そうでない場合にはデグレが非常に起こりやすく、こういった事態は設計段階で回避しなければならない。
迅速な修復できること †
上記のデグレが起こりづらいことにも関連するが、不具合の発生に如何に早く修正できるかということ。
おいしいスパゲッティが目の前にあれば、修正どころか原因の特定が難しくなってしまい、実際に修正するにしろ二次災害が起こりやすくなってしまう。
個別トピック †
ABAP、SAPのオブジェクト、SAPの拡張手段、オブジェクト命名規約の項もあわせて参照されたい。
考え方的なもの †
プログラムそのもの †
- その他
関連 †
コメントはありません。 Comments/アドオン?
