第4回目：『ITコンサルタント』と付き合う その2
■初めに
こんにちわ、憲正です。みなさまＩＴエンジニアライフをいかがお過ごしでしょうか？
一応コラムの主題は『わが身は自分で守れ！』ですので、僕のささやかな経験を踏まえて、徒然なるままに皆様にささやかながら情報共有をさせて頂ければと考えております。
今回は第4回目ということで、若干酸っぱいお話をしようと思います。
前回に引き続いて「コンサルタント」について取り上げたいと思います。一体、コンサルタントという職種は本来何をするべき人達なのでしょうか？
■コンサルタントという肩書きに気を付けろ！for 就職活動中の学生さん
そもそもコンサルタントというくらいなので、何かの相談に乗ってくれる職種のことです。
業務コンサルタントからデータベースのチューニングを行うＩＴテクニカルコンサルタントまで幅広くいます。コンサルタント企業を志望の学生さんは、自分が何のコンサルタントを目指しているのか明確にしておいた方が良いでしょう。
逆に、理系だからコンサルティングができないというわけでもないので、その辺は就職活動を通じて十分にサーベイした方が良いでしょう。
需要が多いERPコンサルタントという肩書きに要注意！
ERP業務コンサルタントだからといって、必ずしも業務コンサルタントではありません。
悪く言えばシステムエンジニアの出来損ないの方も少なくありません。もちろん全部が全部そういうわけでもないのですが、大方の人間がパッケージの表面を弄っているだけなので、非常に残念です。
前回話した高い単金を支払うには値しないと僕は思います。
実際、彼らよりメインフレームで業務アプリケーションを設計・製造している年季に入ったシステムエンジニアの方々の方が、遙かに業務に詳しいのです。
コンサルタントという名前に騙されて入社したらABAPのコーディングをしているとか、笑うに笑えません。もっとも本人が納得していればそれはそれで良いのですが。
■コンサルタントという肩書きに気を付けろ！for システム運用部門・業務部門
ＩＴを理解していない業務コンサルタントに要注意！
彼らはＩＴシステムを理解していないため、作成する業務フローは得てして複雑怪奇です。
それをシステムに落とし込むのは至難の業です。
システム構築は目先のコスト改善を目標とせずに大きな視点でERPを目的とする必要があると思います。コレができない自称コンサルタントが非常に多いのが実情です。特に、大きな会社の肩書きを背負っているとそれらしく聞こえてしまうから要注意です。
もちろん全ての業務コンサルタントがそうだとは言いませんが、業務コンサルタントの方々は「システム化するのはシステムエンジニアの責任だ！」というのです。
そんなわけで、システムに落とし込む事を前提に作成されていない業務フローをシステムエンジニアは頑張って仕様書（機能設計書相当）にします。プログラマはそれを受け取ります。プログラマは渋々その意味不明な仕様書を元にコード化します。当然でき上がるものは悲惨なモノになります。はい、失敗システムのできあがりです。
もし業務コンサルタントがテーブル設計まで中途半端に担当していた日には悲惨です。もうプログラムでどうにかなる代物ではありません。そして製造工程に入ったときにはそれを担当したコンサルタントは既にいなくなっていることが少なくありません（大概いません）。
お客様のいうとおりに業務フローを作れば、システムとしてまともなモノにはなりません。
なぜならお客様は自分達のシステムに夢を見るからです。現実をどうやってお客様に理解してもらうか、そしてお客様にとって最適なシステムのベースを作る事こそ業務コンサルタントの重要な役割だと僕は考えます。
■よく考えよう、お金は大事ですよ！
おや？ しかし、よくよく考えてみるとコンサルタントという肩書きの人に頼まなくても、それなりのシステムエンジニアにコンサルタントを頼めば安くて済むのではないでしょうか？
グッとお安く費用を抑える事が出来ます。システムエンジニアもピンキリなので一概には良いと言えないのですが、少なくともERPパッケージの導入についてはＩＴベンダに頼んだ方がお安く済みそうです。
なぜならERPパッケージの導入はどこに頼んでも出来上がるモノに大きな違いはありません。大きなカスタマイズがなければできあがるシステムに大差はないのです。
僕としてはお金は一生懸命に働いている人に回るような仕組みができることを望むばかりです（涙）。
■終わりに
ERPパッケージをうまく導入することができればBPRを実現できます。これは非常に大きなメリットがあるとは思いますが、費用対効果を踏まえて導入を再検討して見ることをお奨めします。今回はしょっぱい話で申し訳ありませんでした。