僕の仕事はSE（システムエンジニア）です。人に職業を聞かれたときにもこう答えますし、何かで職種を記述しなければいけないときも「SE」と書いています。
もともと、僕はプログラマを経てSEになりました（と言っても自分で申告しているだけですが）が、いくつかのプロジェクトで、上流工程（システムを作る前に構想策定を行う工程）で参加するコンサルタントという職種が大嫌いでした。理由は簡単、「考えるのはおまえらかもしれないが、その無理難題を実装するのは俺たちSEなんだよ。」と言う事です。
コンサルタントとは言え、色々なコンサルタントが存在します。僕の職種の場合、システムに関するコンサルタントですね。アクセンチュアとかアビームと言った名だたる会社が存在しますが、結構業界再編や合併なども厳しいようです。
今はやっているか分かりませんが、あるCMで素晴らしいアイデアを出しているコンサルタントに対して、「よし！その案乗った！」と握手しようとすると、顔がお餅になり、膨らんで消える。そして、「あぁ、このコンサルも絵に描いた餅だったかー！」というものがありました。僕がコンサルに対して感じているイメージは大体このようなものです。
我ながら、かなり偏見が入っていますね。
SEのお仕事と言えば顧客の要求に基づいてシステムを構築する作業になります。これを１から作り上げていく方式を「スクラッチ開発」と呼んだりします。基本的に顧客がよほど無茶な要求をしない限り、要求が実装できます。僕も会社に入って４年〜５年位はずっとこういう作業をしていました。
しかし、２０００年前後から、ERPなる方式が出て参りまして、「ERPパッケージ開発」なる方式の開発が始まります。会社の基幹システムは大きく、財務会計システム（会計システム）と、販売・生産システム（ロジスティクスシステム）に分かれますが、それらを全て一つにしたパッケージが発表されるのです。その当時のパッケージ会社は「このパッケージを入れれば会社の主要機能が全て網羅できます。あとは微調整するだけです。」と謳っていました。
僕は、１９９８年位から、SAPと言うパッケージ会社の「R/3」というパッケージを使って開発する仕事に従事しております。SAPと言うのはドイツの会社で、まだこの年代、日本では「ところで、このR/3ってのはどうやって使うのが一番正しいのだ？」と試行錯誤している黎明期でした。
SAPは安い買い物ではないので（元々システム開発には億単位のお金がかかったりします。）、導入できるのは大企業に限られていました。そして、大企業の既存システムというのは、非常に複雑なシステムだったのです。まさに、「スクラッチ開発」でやりたい放題作られたシステムです。それをパッケージに合わせる作業には困難を極めました。
海外では、トップダウン意識が強く、「明日からSAPのシステムを使え」とボスが言えば使わざるを得ない。いやなら辞めろ位の勢いで適用できたのでしょう。
ただ、日本ではなかなかそう行きません。「この仕組みがこの会社の肝なので、この仕組みは絶対に残して欲しい」という顧客の要求を聞いているとなかなかパッケージというのが適用できないのです。結局、パッケージの良いところを使わずに作り込みを多数発生させるケースが増えておりました。
例えばですが、生鮮食品を扱う仕事の場合、不定貫と言う単位で在庫管理します。魚一匹買うときに「１匹」買うと言う事はできるでしょう。魚屋さんに言って、「アジを二匹ちょうだい。」って言えば良いのですから。
しかし、それを原料にして料理するとき、その魚の単位は「ｋｇ（もしくはグラム）」になります。家庭で料理する時はそこまで重さを気にすることは無いと思いますが、工場で加工食品を作る際には原材料の容量は重要です。
それをパッケージで管理しようってのが無理な話です。
そこで、上流工程でコンサルタントが登場します。いかにシステムを作って行くか、そして、それをパッケージに適用するか？（どこまでが作り込みで、どこまでがパッケージか？）の構想策定を行うわけです。
当時は失われた１０年に突入しておりましたが、コンサル業界は深夜まで働いて毎日タクシーで帰るような生活でした。（僕たちは終電まで働いて電車で帰る。）
そして、コンサルが提示してきた結果の仕様は作り込みの塊となっておりました。せっかくパッケージを使っているのにそれを活用していない。それどころか、無理矢理結果をパッケージの標準業務部分に取り込む為、かなりの無理（無駄）な作業が増えている。と言う具合です。
当時、僕は、そのコンサルが作ってきた構想策定の結果をパッケージ（及び作り込み部分）に落とす仕事をしておりました。プログラムを作りながら、「なんでパッケージなのに、こんなに複雑なプログラムを作ってるんだろう？」なんて思っておりました。いやー、当時は本当に毎日忙しかったです。
そのうちに、今度はコンサルタントをいれずに、僕たちSEだけでシステムを導入する機会が出てきました。その場合、「さぁ、どう作りましょうか？」とは言えません。顧客の要件を極力残しながらパッケージに合わせるべく顧客を誘導し作り込みをいかに少なくするか、です。
つまり、顧客と話すためには、最低限、業務知識が無いとお話になりません。勿論、パッケージの知識も必要です。そのうちに、いつの間にやら、僕は「パッケージコンサル」と呼ばれるようになりました。当時僕は販売管理を担当していたので、「販売コンサルタント」と呼ばれるようになっていたのです。気がつけば、あれほど嫌だった”コンサルタント”に自分がなっていたのです。
会社に入ってもうすぐ２０年になろうとしています。一つの会社で２０年勤務するというのはけっこう凄い事になります。そのうちの半分以上、パッケージを扱っております。
気がつけばコンサルタント。（勿論、これも自称であり、あくまでも僕の職業はSEだと思っております。）あれほど嫌だったコンサルタントになっていたのです。
：
最近、よく思います。「あぁ、またスクラッチ開発したい。」と。スクラッチ開発をしているSEからしてみると、「パッケージ開発は作り込みが少なくていいよなぁ。」と思うかもしれませんが、顧客がやりたい要件をある意味強引な方法で実現している事もあります。本当に顧客が要求する要件を実装するにはスクラッチ開発の方が良いかも知れません。
ただ、スクラッチ開発はパッケージ開発より期間もお金もかかります。企業のシステム投資額が抑えられている昨今、スクラッチ開発はどんどん減っているようです。
僕は、スクラッチ開発をやりたいと思いながら、同時にいかにパッケージの機能を最大限発揮させて顧客要件を飲み込むかと言う点にも興味があります。その為には販売管理業務の知識だけではダメで、財務会計・管理会計、所謂「会計」の知識が必要になります。「このタイミングで、こういう仕訳が起きるので財務上、問題ありません。」そう胸を張って言えるようにならなくてはなりません。そうすると、行き着く先は、システム開発より上位の構想策定コンサルタントになってしまうのかもしれません。
あれほど嫌いだった、コンサルタント。
僕は、今、少し迷っているのです。あ、マネージャー（管理者）にはなりたくないです。僕は技術者ですので。そればかりは「生涯現役」で行きたいと思っているのです。
かしこ。
