Jargon, Java, Jargon, Java, ....

今度の会社では,なぜか,システムの提案を受ける側で仕事をしている.そこでいろいろな提案書をよんだり,プレゼンテーションを受ける立場にいる.笑ってしまうが,どれもこれも,酷い.もう,業界のトップ3社がものすごい体制を組んで作っているのに,そんな状態だ.
提案書は,初めの数ページを除いて,システムをどう作るかという側面に割かれている部分がとても多くて,この業界関係者でなければ,到底意味が理解できない.いや,ある程度知っているはずの私ですらすぐには理解不可能な内容だ.ましてや,ユーザー部門の人には・・・.ほんとに,こんな発表しかできないのか?こうやって煙をまいて受注を取ることしか,私たちの業界はできないのだろうか?
実現手段のところはすべて似ている.以下のようなことが誇らしげにちりばめられ,ありがたいお言葉のようだ.

しかも,これらのメリットといえば,すべてほとんどが,システム変更に対する柔軟性なのだ.
とうぜん,私たちからはどれだけコストが下がるのかが知りたい.しかし,それを聞いてもいい返事がない.ということは,私たちにとってはそれらのありがたいジャーゴンは何の意味もない.
そんなものは提案書になくていいくらいだ.どういう技術を使うなど,どうでもいい.だから,この200ページ近い提案書のほとんどに意味がない.
SOAだろうが,Webサービスだろうが,そんなことはどうだったいいのだ.ただ,コストがどう下がるのか,とくにどういう変更に関しては,現行のシステムよりも対応しやすくなるのか.どの程度の概算額で変更できるのか?ということがわかればいい.Javaでなくたって,そういうことが実現できるなら,それでいい.何かベンダーは全体的に勘違いをしているとしか思えない.
確かに,こちら側にも情報システム部門があり,それなりに知っている人たちがいる.そういう人たちは上記のようなジャーゴンに飛びついてくれるかもしれない.大多数の情報システムなんて知らないユーザー部門の人たちは,そういう人たちがいうことだから間違いないのだろうということで,ついてくるのかもしれない.
しかし,本当にそれでいいのだろうか?いや,それしか方法はないのだろうか.

念のためにいうと,今回のシステムはすでに機能的な要件は詰まっている.だからワークフローが変化するとか,そういうことはない.重要なことは制度の変更などで,コストがかからないか?ということだ.そこに焦点を当てることは決して間違ってはいない.しかし,それを技術用語のオンパレードでしか説明できない,ということにむなしさを感じた.

*1:EJB使っているのに,JDBCSQLを飛ばすっていう図をみたことがあるのだけど,EJBってこういうもの?SQLを自動生成して,それを投げているっていう意味なのかなぁ?あと,EJB使っているのにストアードプロシージャ使うのって,反則じゃないの?