[[開発者>プロジェクト/開発者]]の対義語で、満点の仕様で[[設計>アドオン/設計]]されても赤点の[[実装>アドオン/実装]]と[[試験>アドオン/試験]]しかできないコーダーに対する蔑称として用いられる。
詳細設計書を元に組むだけの人、と言えば平易か。
詳細設計書を元にコーディングするだけの人、と言えば平易か。
* どうしてこうなった [#rf5260d8]
日本のSAPの世界には、役割自体が全く異なるにもかかわらず、[[プログラマ>プロジェクト/プログラマ]]→[[システムエンジニア>プロジェクト/システムエンジニア]]→[[コンサルタント>プロジェクト/コンサルタント]]というよくわからない階級制＆キャリアパスがある。
ここに「システムの細胞たる実装とその工程から、システムのコンセプトや機能要求、その充足の仕方を学んでいく」という哲学があればよかったのだが、実情を見ていると、給与や経験年数ありきで決められたり定着してしまったと思われる。
ここに「システムの細胞たる実装とその工程から、システムのコンセプトや機能要求、その充足の仕方を学んでいく」という哲学があればよかったのだが、実情を見ていると、給与や経験年数ありきで決められたり定着してしまったと思われる。
自然、上の階級の人間がデザインしたものを下の階級の人間が詳細化していくことになるが、''上の階級のデザインが大きく後続を左右する→責任は上流のデザインした人間に帰属する''と都合良く解釈する下流工程の人間が現れ、更に''「下流工程を担当する人間の持つ責任は低い」と曲解されていったのではないか''と推測する。
そうなってしまえば、担当する実装という工程にも責任を持たないと話を飛躍させるのは、簡単だ。
そうなってしまえば、担当する実装という工程にも責任を持たないと話を飛躍させるのは、簡単だ。
* 一番まずいこと [#z8bd5dca]
何が一番まずいって、''考えなくなる''ことが最もまずい。
業務プロセスやコンフィグでどう表現するかを求められているわけでもないのに、マッピング元の[[テーブル>SAPのオブジェクト/テーブル]]や項目・使用する[[汎用モジュール>SAPのオブジェクト/汎用モジュール]]を明示されなかったり、直接帰属しないトピックを振られると、''それ、コンサルの仕事でしょ？''という思考回路となるABAPerが、如何に多いことか。
そして、こういう人間の意識を変えようとしても、自分の仕事を増やす気だな！とか押しつけられた！的な感想しか持ちえず、また それらの人間たちは「動くものが組める」程度のレベルにも関わらず、''「Add-Onなんかもういい。コンサルやりたい」''的な台詞を吐く。
もちろん、考えることをしない人が「考える人」というロールを割り当てられても、末路は知れている。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
