SIerは本当は必要な職業SIerは本当は必要な職業言語
アセンブラは速いが 開発効率が超・悪いC/C++は準じて速いが、開発効率が悪い
Javaはそこそこ速くて、そこそこ開発効率がよいが、そこそこでしかない
Perl/PHP/Pyton/Ruby は 開発効率は劇的によいが、重い
他にもJavascriptだったり、FlexだったりActionScriptだったりListだったりetc,etc
あぁ、Mathamaticaも忘れちゃいけない。
さて、ここで出てくるのが、何でもかんでもアセンブラ・なんでもかんでもRubyではなく。適材適所・バランスの問題
どういう比率でそれらを混ぜるかが重要。
昔で言えばフレームはCで チューニングが必要な関数はアセンブラでみたいなもの
料理と同じで、素材にはクセがある。問題は分量と配合
サーバー・クライアント
クライアントを高機能にすると、サクサク動くが、単価が高くなるしアップデートが大変。サーバーを高機能にすると、集中管理できるが、ネットワークでのロスが心配
これも、上と同じで、なんでもかんでも、クライアント重視じゃないし、なんでもかんでもサーバー重視でもない。配合と比率の問題。
OS他
もう、いうまでもないが、なんでもかんでもWindowsじゃないし、Macでもないし、Linuxでもないし、UNIXでもない。まぁ、BSDとかSystemV(Solaris)とかとかとかそれぞれに一長一短ある
Windows サーバーだって最近はケースによってはLinuxに勝つし、LinuxだってデスクトップでWindowsに勝ることもあるだろう。
ようするに、案件毎に適切な配分というのが重要
SIerとは
本質的に言えば、案件毎に、これらの配分を決め、適切な会社を選び出し、それぞれにオーダーをだし、その進捗を管理する者である。とうぜん、そういう配合を決めるからには、すべての言語・すべてのサーバー・クライアント構成・すべてのOSに精通していて、特徴を肌身に感じていなければならない。
まちがって、案件ほしさに、都合の良いデータを出してくるベンダーの言う事なんて聞いてはいけない。それらベンダーからのデータを実際にテストし、試験し、検証し、生でリアルなデータとして保有してなければならない。
その上で、日々変わる最新技術のトレンドに追従し、温故知新で古い技術を組み合わせ、設計書を書き、発注するのだ。
本質的には、外注会社への発注というのは、アートなのだ。だからこそ中間で発注するだけの会社というのが成り立つ。
しかし、何も考えずに発注してもそこそこの物はできあがる。そして、楽ができる。そして、楽をした。その結果、ボロボロになった。
こういう、すべてに精通した人間がいることで、巨大なメガシステムが動き出す。
はっきりいって、巨大な案件になればなるほどSIerなくしてはシステムは作れない。
本質的なSIerの仕事とは
それぞれの外注が自分の仕事に専念できるように適切なパスを張ることにつきる。クライアントで起きたバグだがサーバーで治すべき物（仕様誤り）やその逆が発生したときに適切に処理したり。
うちのバグじゃありません、XX社のバグですとかゴネる外注の会社に乗り込んでいって、ほーらほーらほーら。と指摘し、指導してきちんとバグを治させる事なのだ。
間違っても、全社を呼んで、だれのせいか会議を開いたりする物ではない。そういう会議をひらくなら、SIerなしでも動くだろう?
今のSIerの問題
SIerの会社に入っただけの、スキルも何もない、新人がSIerを名乗っていること。昔は、アセンブラでドライバをゴリゴリっと書ける管理職がいた。今はほとんどいない。利益至上主義で営業畑が管理職になりすぎた。
技術がわからないので、とにかく、会議会議、で外注を呼び出す。外注は会議対策で制作時間が削られる。
今後の課題
若い人がチープ革命に走る余り、重い構成が作れない人が増える事。銀行システムや株式取引システムの期間などちょっとまえにヘビーな事態だった。もしかすると、冗長化システムを本来の意味で用いた落ちないシステムを作れる人は次の世代にはいなくなるのかもしれない本当の意味でのSIerを育てられなかったSIerの会社の淘汰。これが起きるのは良いとしても途中過程として、IT産業の外注化。国外への発注。その過程でのIT技術の国内蓄積の消失。
いつのまにか、技術大国日本は、技術小国日本になるのかもしれない。
良くなる方法はないのか？
昔、マリーアントワネットはいったそうだ。『パンがなければお菓子をたべればいいじゃない』現代ではSIer会社の偉い人がこういう『残業したくなければ、帰ればいいじゃない。（残業しているヤツは帰りたくないだけ）』
ようするに同じ。
