コンサルとSEの違いって

今年から会社のコンサルティンググループに配属になりました。
それまでは、ユーザの業務要件に基づき、せっせと設計していたんですが、
コンサルということで業務の勉強をさせられています。
しかし、コンサルって言っても、自分自身よくわかりません。
上の人の仕事を見ていても、プリセールスばかりで肩書きだけが
コンサルって感じです。
ベンダーにおける、コンサルって何なのでしょうか？
何かご意見ください。

ベンダーのコンサルは名ばかり。
意味がないので、辞めなさい。

コンサルは戦略担当でSEは戦術担当です。

ま、これから俺らの命運を握るんだから頑張ってね。
業務分析手抜きしてデスマーチのお決まりのコースはもうやめてくれ〜。

コンサル：嘘つきボッタ栗
SE：プログラマー

>>3
とても「戦略」やってるって感じじゃないんですが。
ていうか、一緒に仕事をしていたSEのベテランの方の方が
業務に関しては良く知ってるんですけど。
「戦略」って、企業戦略とかそういうことでしょう。
私たちのグループは、とてもそんな風には思えません。
単に私の会社の問題かな？
お客様も、僕たちにそんなこと期待してるなんて思えないのですが

ベンダのコンサルっていうのは、俗に言う「ＩＴコンサル」ってやつでしょう？
純粋なコンサルとは意味が違うよ。ＳＥ部門よりもう少し上流からやるプレ部隊
という位置付けだと思うよ。うちはそうだよ。

>>6
その「ITコンサル」って、いわゆるシステム周りのコンサルティングということですか？
それとも、業務レベルも含んだ意味での「コンサル」なのでしょうか？

ＳＥもコンサルもやってることは基本的に同じだよ。

>>5
そのSEがよく知っているのは多分戦術レベルの"業務"だよ。
頼むから下士官レベルの人間になろうといしてる人が
「あの上等兵さんは大砲の打ち方を僕らよりよく知っているんですよ」
とか言わんでくれ〜。

あと、あの業務のシガラミを整理するだけで、この部分のシステム化って
実は凄く楽だったのに〜とか思ったこと開発してて思った無い？

そのような、クリティカルな部分を開発"開始"前に洗い出すのが
これからの貴方のお仕事なんじゃないですか？

他の人は知らんけどよ。

PG = 単価1とする。
SE = 1.5 〜 2.0
コンサル = 2.0 〜 4.0
でも、みんな能力同じ。金返せ！　って言いたいね。

>>9
ありがとうございます。
「大砲の打ち方」はともかく、「業務のシガラミを整理するだけで、楽だったのに」というところはなんとなく判ります。
確かに最初の要件分析がまずいせいで、すごく大変なプロジェクトになったことがあります。
ということは、細かい業務知識ということより、考え方が大切なんですね。

なんだか、荷が重いです

>>10
禿げ死苦土井

>>10
コンサル = 2.0 〜 4.0
そなの？10〜50位かと思っていたよ（藁）
給料じゃなくて単価ね。
>>11
周りから孤立しない程度に頑張ればよろしいと思いますよ。
1さんの境遇を羨んでしまう自分が悲しい（苦）

汎用機１０年・ＳＡＰ５年やってるけど、基本的なスタンスは同じ。
昔からある３５歳定年説も、好奇心・向上心があれば大丈夫さ。

この業界に適性の無い＝使えない奴は消えてくれ。

>>15
アンタ狭量すぎるよ

コンサル：理想論者
SE：現実論者
ってな構図が多すぎ。

ホントは理想の現実解を提示するのがコンサルじゃないのか！
解を示すことのできんコンサルはいらないなぁ。
かといって、「現実現実」って、ただ自分の視野の狭さを言い訳にする
SEも嫌だけど。

>>17
ほぼ同意。
加えて、コンサルって名前の知識オンリー野郎も
逝ってよし。

>>17
> ホントは理想の現実解を提示するのがコンサルじゃないのか！

理想って言うよりも「バクチ屋さん」って感じなんだけどね。
多少の理論と僅かな実態調査(市場調査含む)で大きなリスクを小さく見せかけ
勝負を行う賭博師と私の目には映ってしまう。

まあ、成功率低くても成功事例が蓄積出来ればやっていける職業だしね。

>>19
よーく、ご存知ですな。
もしかして、痛い目に遭った？

いくところ、コンサル屋って技術営業屋か商社マンじゃないの？（笑）
特に某外資系のところはそうみたいだけど。

>>20
いやー、私の商売仇なんですよ。（笑

「プレス屋さんの付加価値はプレスした瞬間に発生する！、
ですから重い鉄板を幾ら移動しても付加価値は生まないのです。
このことを知らずして云々．．．．」
って感じだしな！ (笑

>>21
技術営業屋ではないな、少なくとも俺のところは。
商社ってのは、当ってるな。輸入屋って意味では。

>>22
ハハハハハ。大受け。
一緒に仕事したいですな。
俺の会社、もう終わってるから。

>>24
まあ、この時期コンサルは厳しいでしょうな。
動かせる資金すらない相手をバクチに誘っても虚しいからね。

# 堅実にやるしかないでしょうな。（まあ廃業を進めて歩くが吉がもね。

あら、出張３２さんにレスされちゃった。
いろいろ叩かれてますけど、なかなか面白いですよ。
それはおいといて…。

最近思うのは、コンサル、ＳＥ、ＰＧの対立が激しい
プロジェクトって絶対うまくいかないなーってこと。

特に上位（別にコンサル＞ＳＥ＞ＰＧって思ってないけど、
とりあえず便宜的にコンサルが上位ってことで）がマズいと
ほんとひどいことになります。

1さんは違いがどうのってことに気をとらわれず、
「プロジェクトを成功させるためには何が良いことか」って
ことを常に考え、ＳＥ、ＰＧと仲良くやってくださいな。
ＰＧの提案で生産性が１０倍伸びた例もあります。
柔軟な考えを心がけましょー。

>>26
Thx♪

対立が激しくても問題無いよ。
ってか、激しいほうが良かったりするケースも多々あります。

一番不味いのは、相互否定の構図なんだよね。
こりゃもう如何にもならんでしょうな。

# 「分業するならコミュニケーションは活発に！」

>>26
一般論としては、まあ同意。
でも、PGレベルで生産性が10倍伸びるなんてホントにあるかあ？

>>27
>一番不味いのは、相互否定の構図なんだよね。

あ、それだ、俺の言いたかったことって（ｗ。
確かに良い意見を戦わせるって感じのプロジェクトはいいもんです。

お互いに「あいつはバカだ」って無闇に片付けてはいかんっつーことですな。

>>29
そう言うこってす。
バクチは嫌いって騒いでたら魅力に乏しい戦略の乏しいものになるしね。
かといってバクチはリスクが絡んで当然だし、結局落としどころなんだよね。
ＰＧに付いても同様だしね。
創造物という物はどの工程も大事なんですよ。
どっかの工程に手抜かりがあれば良い創造物などできませんって！

>>28
ああ、それはですねぇ、
ＳＥが作ったマズい処理フローがありまして、
それを２０人分業で作らせようとしちゃってたのを、
「ここと、ここと、これって同じでしょう？それにあのクラス使えばいいでしょ？」
ってな感じでプログラムレベルでの提案があったときのことですー。

>>28
>でも、PGレベルで生産性が10倍伸びるなんてホントにあるかあ？
>>31
だよね。PGで的確なクラス、ライブラリ、手法を使えば、生産性なんて
個人単位で１０倍、グループになると１００倍ぐらい違う。
だけど、それを生産性って言う風にSEやコンサルはあんま見ないんだよね。
その辺。

>>32
なるほど、わかった。
でも、喧嘩売るわけじゃねーけどよ、コンサルの仕事って、もっと、こう、
実装に落とし込む以前の段階のハナシで、ユーザの漠とした要求を聞いて、それを分析、整理してあげるっつうところが
仕事の土俵なんじゃねえの？
簡単に言うと、もっと業務よりってことだ。
もちろん、実装のことをまるっきり考えねえって訳じゃないが、
そこはHOWの部分で、コンサルはどちらかというと、WHATのところだぜ。

>>33
同意。
もっとも、漏れんとこ小さいから今猿（うわ、凄い変換）・営業・SEまで漏れ。
ＰＧだけいつも使っている協力会社さん。
狭い業界で業務知識もたこつぼで構わないから出来るけれど、あんまりよくない
と思うのは常々。コンサルとしては「…ここ省けば（変えれば）、ずっと良くなる」
と思っても、ＳＥとして「工程が延びるな」と考えてしまって、業務の改革が
うまくできない。
もちろん、言い訳に過ぎなくて、自分の能力がないせいなのはわかってはいるけど。

&hearts

♥

&hearts

仕事の分担はこんな感じのでは？だから、誰がえらいというわけではのない。
それぞれの役割に徹すればうまくいくのだ。

計画...要件定義...設計...開発...テスト...運用...
<--コンサル-->
<-アーキテクト->
<------------SE-------------->
<---- PG ---->
<-運用担当->
<------------PM-------------->

あ、ずれちゃった…

>>34
同意＆同情
もっとも、俺も人に同情してる身分じゃないけどね。

コンサルについて教えて下さい。age
長く勤められるんでしょうか？
残業時間は多いのでしょうか？

コンサルと一言で言ってもね、色々と持ってる武器が違うんです。
情報処理系のコンサルの場合、武器として情報処理が使われる訳なんで
あまり大した業務・業界知識がある訳じゃありません。

その為、多くのコンサルはＳＥ経験が結構あり折衝能力もそこそこで
設計者としては及第程度の人が、ある程度高齢になり技術の進歩に付いて行くのが
辛くなった方がなるようです。(上から強制的に配置転換されることが多い)

>>42
そんなもんですか。楽そうですね。
ITコンサル会社は安泰ですか？

コンサルに期待しているのは、やはり上位職との折衝能力ではないでしょうか？
最初の方にもあったように、業務はＳＥにまかしてでも経営的な観点からの
アプローチのできるひと。
だから、ＩＴコンサルは、まず相手の業務を把握して、こういったＩＴ技術で
こんだけの効果がでるはずですよっていう、本当は、ユーザー側で検討すべきことを
やってもらえるところっていう認識があるんで、いまのところは仕事としては、
ＳＥへの売上まで考えなければ安定していくんじゃないかな？

>>43
> そんなもんですか。楽そうですね。
> ITコンサル会社は安泰ですか？

まあ、中小企業診断士の免許持っていても現実は大したこと無いからね。
ほんとに優秀なコンサルは極一部ってところですね。
まあ、情報処理系だと強力な武器を必然に持つ訳だから誤魔化しは効きますね。

>>44
> コンサルに期待しているのは、やはり上位職との折衝能力ではないでしょうか？
> 最初の方にもあったように、業務はＳＥにまかしてでも経営的な観点からの
> アプローチのできるひと。

その通りなんだけどね。
所詮会社員たるコンサルの「経営的な視点」に多くを期待するほうが野暮だと思う。
理屈だけで通じるならばどの会社も超優良企業になってしまうからね。

>>44
> だから、ＩＴコンサルは、まず相手の業務を把握して、こういったＩＴ技術で
> こんだけの効果がでるはずですよっていう、本当は、ユーザー側で検討すべきことを
> やってもらえるところっていう認識があるんで、いまのところは仕事としては、
> ＳＥへの売上まで考えなければ安定していくんじゃないかな？

極々常識的な範囲での経営的視野と情報処理と言う武器によって、相手を本気にさすところが
最大の売りでしょうね。

だからこと、情報系コンサルが魅力を持ち大きな市場も抱えていると言えますよね。
だけど、もう５年もしたらコンサル能力について選別される時代が来ると思うよ。
所詮はマヤカシである部分が多過ぎるからね。

出張32さん、煽りは嫌われてるけど業界には詳しいですね。

情報関係の仕事のSEみたいな部分て、見た目が一見綺麗なだけで、実態は人海戦術、また、これから先細りじゃないですかね？
特殊な分野のプログラマや回路設計の方が今後良くないですかね？

上で、人海戦術と書きましたが、
SEやコンサルの一人が何件もの仕事を同時にする、ってのも、
末期的な人海戦術ですよね？

>>46,47
> 情報関係の仕事のSEみたいな部分て、見た目が一見綺麗なだけで、実態は人海戦術、また、これから先細りじゃないですかね？

SEと言うのはある意味、ＴＶのドラマに出てくる刑事みたいなものなんですよ。
結局、ユーザーの要求に対しての裏付けを如何に多く取るかってとこが最大のお仕事なんだわさ
その部分がなくならない限り先細りはないと思うよ。
今のコンサルは、開発責任を放棄している人が多いから上記の裏付けもそのほとんどが
単純な理屈と貧弱な業界知識で見かけ上補っているだけの人が多いからね。
結局、荒すぎるんだよね。
あまりにも大雑把なものだから抜けも多くて、本筋すら見誤ってるケースも
多いですね。

> 特殊な分野のプログラマや回路設計の方が今後良くないですかね？
特殊分野は所詮隙間産業だよ。
隙間だからこそ少数であることに意味がある。
だから多人数で競う合うもんじゃないよ。

> SEやコンサルの一人が何件もの仕事を同時にする、ってのも、
> 末期的な人海戦術ですよね？

うんとね。
同時に複数案件を抱えるのには、訳があります。
基本的に、顧客と歩調を合わせる必要があるから時間が余ってしまうんですよ。
勿論、時間の足りないＳＥさんも多くいるけどね。(整理不足・準備不足が原因)

ソフト開発はいわゆる製造業ですよ
海外に生産拠点が移るのがトレンドですから
コンサルのような上流工程をつかむことが
大事かもしれませんね

>48
汎用機、UNIX、COBOLマンセーな時代には裏付けが重要だったと思いますが、
Win、Linux、オープンソースアプリ時代だと、
設定は雑誌で見るだけで事足りる時期が時期がきたりしませんかね？

>>48
出張32殿、お願いがあります。

私のお願いを聞いていただけませんでしょうか。

>>49
> ソフト開発はいわゆる製造業ですよ
> 海外に生産拠点が移るのがトレンドですから
> コンサルのような上流工程をつかむことが
> 大事かもしれませんね

まあ、そうなんだけどね。
唯、ソフト産業が他の製造業と一番大きく異なるのは
「常に異なるものを作っている」ってことなんですよ。
まったく同じ物を大量に作る(コピーで終わり)のは他の産業と違って非常に簡単であって商売にすらならない。
常に異なるもの短期間で作る為に精密なる仕様を作成する予算も時間も無いってことが
他製造業と大きく異なるわけです。
つまり、はじめから曖昧なんですよ。
この曖昧さを無くせば良いのだけど、現実的には非効率過ぎるので
ある程度の曖昧さを持ったままの開発になるんですよ。
その為、個人の技量によって曖昧箇所の押さえ込みが大きく異なり
結果として品質・コストパフォーマンス・開発期間に大きな差を生んでいるんです。

>>50
> 設定は雑誌で見るだけで事足りる時期が時期がきたりしませんかね？

如何でしょうね？
自動作成ツールが如何に発展したところで、曖昧さを残した設計をするのだし
状況はあんまし変わらんと思うよ。

>>51
まずは、お願いを書き込んで下され！
返事はそれからです。

>>52
プログラムの自動作成ツール OR マクロ言語は役に立たないと思うけど、
アプリケーションは一杯になるんじゃない？

今だと、MS-Accessは高価で難しいけど使っている人が居るよね。
フリーな業務ソフトや簡易WebDBとか出てくるんでは。

>>53
> アプリケーションは一杯になるんじゃない？

現状でも可也充実して来てるよね。
使える完成品もそこそこ出揃って来ているね。
唯、完成品販売分野には飽和点があって全市場の20%前後だと思います。(基幹分野)
で、現在ではパーケージの一部カスタマイズ分野が急成長してますね。

> 今だと、MS-Accessは高価で難しいけど使っている人が居るよね。
> フリーな業務ソフトや簡易WebDBとか出てくるんでは。

Accessは、一般の企業で半素人さん達が多く手がけてますね。
勿論、プロの分野でも主力ツールと使われていて適用範囲の大きさを窺い知ることが出来ます。
このようなツールをユーザーが直接開発に使うメリットとしては
十分な試行錯誤が可能であるってことでしょうね。

# 試行錯誤は必要不可欠な工程なんだけど、日本では見積に入らないケースが
# 殆どなので余暇を利用したり、思考だけでのシュミレートになったりしますよね。

>>で、現在ではパーケージの一部カスタマイズ分野が急成長してますね。

コンサルってパッケージの設定だけで膨大な金取るんですよね？
レベルの低い仕事だから高級貰わんとやってられないかな。

でも、将来的にヤヴァくないですかね。

　ここまではＳＥさんはじめ業界内からの
「コンサル」さんに対する希望というところですか？
　でもう一方、顧客からの要望というのもあるのよね。
俺的にはこっちも色々あると思うんだが？
＊・・・と無責任に逃げる俺

>>52
うーん、なんといいますか、
いい意味で
いい加減な気持ちでなく、
筋違いかもしれませんが、

出張32殿！

ＰＧ板（マ板というのか？）の日○部殿をとっちめてきて下さい。

罪状としては、
良スレもなんもかんも彼が登場すると糞スレになってしまうという事です。
良スレが荒れて行くのは見るに耐えられません。

>>57
見てきたけど、ありゃ〜会話さえまともに出来ないお人だわさ。
放置するしかないんじゃないの？
基本的に会話をする意思が無いようにお見受け致しました。

>>56
> でもう一方、顧客からの要望というのもあるのよね。
> 俺的にはこっちも色々あると思うんだが？

一般的に顧客の要望は整理されていないケースが多いよね。
「整理は君達のお仕事ですよ」って考えてる顧客さまは多く居ます。
ある意味、我々にとってそのことが仕事上有利なことが多いんだけどさぁ
もう少し考えて自身の損失にならないように努力しないと泣きを見ると思うよ。
ってか、泣き続けてる企業も多くあるでしょう？

# 最低限度の整理は自身の保全であることを知ってほしい > 顧客様
# 運が悪いのは貴方様自身に半分原因があるのですよ。

>>57
でもさ、くさか○の本って結構、本屋で見かけるよね。
読んだことないけど。平積みとまでは行かないけど
けっこう目立つようにおいてあったよ。
その気になれば人に読ませる文章は書ける人らしい。

「つくってわかるＣ言語」とかいうやつ。
Ｃプログラミングだったかもしれない・・・
誰か読んだことある人、中立的な意見をキボンヌ

>>59
リアルは全く関係ないと思うよ。
本人であるかどうかも実際に判らんし、もし本人であったとしても
２CHでの会話が全てだからね。
会話する意思があるのならもう少し噛み合う発言をすると思うしね。

まあ、あれが彼のキャラスタイルなんじゃないの？
そのつもりで対処してれば済むと思うしね。

>>58
了解。

>>58
　問題の発生に対し、冷静な分析・対応が
できる企業・組織なら、基本的にコンサル
はいらないのでは？（藁）
　乗り込む側の心得としては
「なんだか解らないけど、
とにかく何とかしてくれ」からはじまる
と考えてるし。

　もっとも、二度と付き合いたくない
という顧客なら、それなりの対応があろうけど

>>62
> 問題の発生に対し、冷静な分析・対応が
> できる企業・組織なら、基本的にコンサル
> はいらないのでは？（藁）

紐付きのコンサルは要らないでしょうね。(って言うか邪魔でしょうね)
彼ら(できる企業・組織)の必要としているのは外部からの多角的な視点とアドバイスだけなんです。
ですから、必要としても所詮はオブザーバーとしてであってそれ以上じゃないんですよ。
それと多角的視野が重要なので多様な分野の複数者と言う事になり、その方達には自社の選任担当を
付けてアドバイスが的確になるように支援するでしょうね。

# コンサルは本来、上記が本職なんですよ。(それ以上でも以下でもありません)
# まあ、現在は持て囃されてるから勘違い君も多いけどね。

では、次にＳＥという分野はどうなんでしょう？

昔のＯＳやアプリのインストールなんかは客がやってしまいます。
また、ユーザ用プログラムなんて相当単価下がってるんじゃないでしょうか。

>>64
> では、次にＳＥという分野はどうなんでしょう？

顧客がどれだけ適正な要求仕様を作成するかよって大きく変化する分野と言えます。
つまり自社の現状と新たな情報システムを構築した場合の効果及び導入予算を的確に把握し
直ぐに詳細設計が適切に書き下ろせる程度までの要求仕様を顧客自身が行う場合はＳＥ不要
となるでしょうね。(正確には顧客内ＳＥが代行するって意味ね)

唯、上記までの作業を顧客が行った場合は、当然ながら仕様書作成代金はお手伝い代金程度に
減額され、プログラミング費用も余裕のない厳しいものになるでしょうね。
どちらにせよ、リスク分担は顧客に集中することになりその分だけ単価は安くなりますね。

>>65
つまり、ＳＥって本当の意味でアウトソーシングなんだ。
最近までエンジニアと勘違いしてたＹＯ！

>>66
> つまり、ＳＥって本当の意味でアウトソーシングなんだ。

ほい、そうですよ。(社内ＳＥ除く)
お抱えでない限り、ＳＥも一級建築士も公認会計士も弁護士もアウトソーシングだよ。

> 最近までエンジニアと勘違いしてたＹＯ！

？？
君、アウトソーシングの意味判ってます？

>>67

アウトソーシングと関係なかったですね。

仕様書作成=庶務的な人材派遣、て意味でエンジニアじゃないって書いちゃった。

>>68
仕様書作成＝庶務
って、勘違いがすぎるYO！

>>58
>>63
>>65
>>67
　言ってることは至極もっともだけど、
その手の事を一席ぶつ時には、
それが理想論であることも、念を押しといて・・お願い

・・・いや、いるのよ、顧客との打ち合わせの席で
その手の話いいだして、担当者激怒させたのが
＊「58」あたりの話を言い出した時は
＊「コイツ首しめたろか」とおもた

　泥臭い現実を見据えてない理想論は
ひたすら迷惑だってことは、おわかりでしょ？

>>70
理想論として受け取り現実逃避を計るのは良くないですよ。
私の書いたことは「お仕事の基本」であって、そこから商売が見えてくるものばかり
ですからね。

まず、基本をしっかりと見据えた上で「お客様の我が侭」を商売として捉える。
その上で解決策をじっくりと考え、必要なだけの確証を得た上で提供する。
これが私達ＳＥの仕事であり、「お客様の我が侭」は商売のタネですよ。

>>71
　何か、うけこたえがちょっとずれてない？
基本だろうが理想論だろうが、それを言ってはいけない
場がある・・という話なんだが？

>>72
> 基本だろうが理想論だろうが、それを言ってはいけない
> 場がある・・という話なんだが？

うん、全てを理解した上で間接的に賛同した投稿をしたつもりなんだけど．．．
読み取れませんでしたか？

商売としての押さえが甘いと70番のような場面に遭遇することとなりまする。

>>73
いや・・・
>>71
の後段に対しては、そう受け取れたんだが
その分前段が？？？だったの

補足
> 理想論として受け取り現実逃避を計るのは良くないですよ。

上記は、70番さんのお話に出てくるバカもののことです。

> 70番のような場面

勿論、バカものが遭遇した場面の意です。

# プロとしての自覚が乏しいと自ら商売のタネを放棄することとなる訳ですね。

>>75
補足　サンクス

ちなみに他業種の「70｣の類似例

建設コンサル某氏が住民説明会にて
「私たちは此処を良い街にするために開発するのです。
それに賛同しない人は街を悪いままで良いというわけで
言ってみれば犯罪者です。」

・・・これも実話・・・

>>76
その手合いの人って結構いるよね。
まあ、焦る気持ちや熱心さは判らないでもないのだけど．．．
暴走すると真の目的を見失うので困ったものです。

私達の仕事もお客さんからの依頼に基いて行うのが筋なんだけど．．．
技術屋としての鬱憤も溜まるらしくて結構多くの方が「自由な設計をしたい」
との理由で職場を転々とされてるようです。
結局、自身の構想を一システムで具現化することが不可能なのは明白なのにね。

まあ、技術屋の技術屋たる所以なんだろうけど、見てて寂しくなります。

>>77
最近気付いたんですけど、コンピュータ業界は実はそういう人間関係の
泥臭いところなんですね。
日本だとプログラミング中心のところはお金が入って来ないため、ダメ市場って感じ。

>>78
でも、理想・信念もなくすんじゃないぞー
＞＞ＳＥ・ＰＧ及び各業種技術者諸氏

　そりゃ、理想論だけでは周りが迷惑とは書いたさ
けど、それ無くしたら、今度は自分がつらいぞー

「へー、いいねえ、好きなことやって
お金もらえる御身分は（皮肉笑）

「おーおー知ったようなこと、
　現場もしらねーでよ」
この手の商売やってると
必ずこういうこと言ってくる奴らがいる。
で、若い内は真に受けて結構悩む人いるんだよね。
（特に勉強熱心な人）そのとき理想・信念が立ち直るきっかけ
・・・ってこと多い、それだけじゃ無いけどね
・・・というわけで、がんばっていきましょう＞＞ＡＬＬ

>>78
> 最近気付いたんですけど、コンピュータ業界は実はそういう人間関係の
> 泥臭いところなんですね。

うん、結構泥臭いし予算や開発期間も厳しいから大変ですよ。
だけど、その大変さがあるからバランスの取れた(予算配分・業務及び機能配分)システムを
カットオーバーすると喜びもひとしおなんです。

# 自分なりに努力しその過程での障害を知恵と経験で克服するのは楽しいです。

>>80
オープンソフトに囲まれて（日本では少ないが）開発予算はこれから厳しくなりませんかね。

>>77
自由な設計でイパーイ売れるものを作りたいということでは。
でも日本ではそういう場自体無いですね。

age

>>81
> オープンソフトに囲まれて（日本では少ないが）開発予算はこれから厳しくなりませんかね。

Web系の開発は学生アルバイト＆単価激安外国人達によって開発予算は激減してますね。
まあ、XML等で開発自体が単純になり元々複雑な構造は苦手な分野だけに
仕方ないといえますね。

> 自由な設計でイパーイ売れるものを作りたいということでは。
> でも日本ではそういう場自体無いですね。

如何なんだろう？
不特定多数者を相手の開発となると分野が違うと思われます。
主要ユーティリティ関係ならば巨大資本が抑えているので、
結局隙間分野になり、ユニークな発想が勝負所だと考えます。
「ユニークな発想」こそが最大の分野と考えますので職種も異なるとの認識なんですよ。

>>83
開発予算が激減したらSEヤヴァくない？

コンサルも将来コンサルする対象が少なくなってコンサルが食い合いするという話があるね。

>>84
> 開発予算が激減したらSEヤヴァくない？
> コンサルも将来コンサルする対象が少なくなってコンサルが食い合いするという話があるね。

まあ、業界の技術者は大ピンチに陥るでしょうね。
但し、需要が減らなければ作り手が居なくなってしまうので結果として激減することはありえないでしょうね。
勿論、需要が減らなければのお話です。

で、もし需要が激減したらほんとに開発効率の高い人達だけが生き残るでしょう。
他の分野と違って、開発効率の幅が非常に大きい業界だからね。(2-10倍)
そうなると、現在の情報系コンサルの殆どは撤退でしょうね。
開発効率を高めるだけのスキルを有した人は非常に少ないからね。

ちょっと85の内容は余り賛成でないですね。

需要が激減することは無いんじゃないでしょうかね。
需要をあえて作り出すように大きなフレームワークがイパーイでっちあげられてるので。
過去のソフトハウスが潰れてた時期というのは、仕事は一杯あるのに採算が取れない、という状況だったらしいですが。

>>86
> 需要が激減することは無いんじゃないでしょうかね。

うん、今のところ激減する要素は無いですね。

> 需要をあえて作り出すように大きなフレームワークがイパーイでっちあげられてるので。
> 過去のソフトハウスが潰れてた時期というのは、仕事は一杯あるのに採算が取れない、という状況だったらしいですが。

その事例は85の内容と事象が全くことなります。
業界組織構造がもたらす不況＆過渡競争が原因だと認識しています。
ご存知のように、この業界はビックネームによって色分け＆組織化されています。
この状況で、ほんの少し不景気に振れると当然ながら上位から順番に仕事量を確保する
圧力が高まりますのでその反動として不況＆過渡競争へと進み弱小ソフトハウスが打撃を被ることとなります。
更に、資産が人材と言える業界なので資産に乏しく、人材の放出＝信用の失墜なので経費削減も難しい。

ビッグネームが仕事が取れて弱小ソフトハウスが仕事取れないのね。
確かにそういうこと書いてあった。
http://www.atmarkit.co.jp/fengineer/rensai/jobtrend/jobtrend01.html
連載：ITエンジニア最新求人レポート No.1＜2001年12月版＞
■案件自体が減っている？ 派遣エンジニア動向

>>88
そうです。
それとビックネームはチョット景気が良くなったり大きなプロジェクト(第ＸＸオンライン開発等)が発生すると
直ぐに人集めに走る傾向があって弱小ソフトハウスの乱立に一役買っております。
そんなわけで、地道に商売をしているソフトハウスよりも人買いに近い商売をしているソフトハウスの方が多く
存在するという特殊な環境でもあるんですよ。
近頃では、「派遣業」に変身して暴利を貪っておりますね。
どちらにせよ、業界としては好ましくない環境に向かってるのは確かなことです。

そうすると、納期の速さを売りにしたり、開発費用の安さを売りに
するのは、ある意味自分の首を絞める行為なわけですね。

こういうことは「ある程度のレベル」をクリアしておいて、
もっと付加価値的なものを売りにしたほうが、業界全体と
してはいい方向に向かうのかなと。

>>90
> そうすると、納期の速さを売りにしたり、開発費用の安さを売りに
> するのは、ある意味自分の首を絞める行為なわけですね。

はい、私もそう考えてます。
戦略と技術の裏付けがある安売りならばそれなりに差別化戦略として使えると思うけど
単に安さだけを強調した販売は自身の首を締めてるに等しいと考えます。
合理化は至上命題なんだけど、研究開発費は残して置きたいしユーザーに対しても一歩踏み込んだ
サービスを提供したいものです。
そんな時、予算が少な過ぎると満足な支援は出来ないので結局、安かろう悪かろうの道へと進んでしまう。

> こういうことは「ある程度のレベル」をクリアしておいて、
> もっと付加価値的なものを売りにしたほうが、業界全体と
> してはいい方向に向かうのかなと。

うん、やはり一歩踏み込んだサービスを心掛けるってことが業界としても良い方向への
指針となり得る概念じゃないかなぁ。
「顧客の満足を得る為に何をすべきか？」が業界として問われているのだと思います。

ビッグネームもＳヨを大規模に募集かけて首を締めてたりしないかな。
報道ではサービスへのシフトとか言ってるが。

研究開発してビッグネームが暴利を貪る大型プラットフォームに対抗する小型ソフトを作りたいよね。
でも、コンサルやＳヨじゃ無理。やっぱりＰＧじゃないか？

>>92
??
君の言ってること良く判らんわ。
ＳＥとＰＧを区別することに何の合理性があるのかすら理解出来ない。
要は、技量の乏しい人を大量雇用して自身の首を締めてるって言うのならそのとおりだけどね。
でも、そんなことは判りきったことなので承知でやってるんだわ。
で、厳しくなったら営業職へ配置転換し自主退社に追い込むのが基本だろう？
所詮、巨大組織で質が高い訳ないさ。(下の下ってことね)

だって、ここはSoftware Engineerをコンサル、Ｓヨ、ＰＧと細分化して比較するスレでは？

俺的にはプロジェクトマネージャ＋SE＋営業＝コンサルであって欲しいが

ナゼそうあって欲しいのか分からん>>95

暴利を貪るコンサルなんて消えてくれれば良いじゃん。

ちょっと横道それちゃうけどさぁ。
私としては、使用する言語やＤＢに精通していないとＳＥとは呼べないと考えてます。
オープン化の波が押し寄せて使用言語が手続き型からイベントドリブン型へと移行しています。
その中で、手続き型は精通しているけどもイベントドリブン型は弱い設計者が多く出てきています。
で、その人達の多くが今尚コンサルであったりＳＥであったりするのだけども、
実際に彼らの設計は陳腐で且つオープン系の特性を反映したものに成っていないのが現状だと思うんですよ。
結局、精通していない分だけ設計が曖昧になったり特性が引き出せない設計になってる訳ね。
そんなことで、情報系コンサルは役に立たない人が多いんですよ。

イベントドリブン型って結局は手続き型じゃないのか？

ＣＯＢＯＬ、ＶＢ、ＪＡＶＡ、どれも手続き型なんですけど・・・
ただそこに構造化設計やオブジェクト指向設計、あるいは
コンポーネント志向設計（っていう言い方があるかどうかは”？”）
って要素が絡むだけ。
出張３２が言いたいのはそっちの違いじゃないのか？

手続き型言語じゃないものって言ったら、対比する対象は
関数型言語とかだろ、普通。

>>98
ノイマン型のコンピュータで処理するものは、設計理念が
どうであれ手続き型にならざるを得ないよね。

出張32のいうイベントドリブンというのは、フレームワークを除外して
その上で動く部分だけを指しているのではないでしょうか。

>>99
同意。
もうずいぶん下がっちゃって、見つかるかどうかわかんないけど
前に「オブジェクト指向」ってスレがこの板にあって、
そこでも彼は「オブジェクト志向」とイベントドリブンを
混同したような発言をしてたよ。まあ証拠が示してないから
「いつ、どこでそんなこと言った？読解力のないキミが単に
そういう勘違いしただけだろ？」って本人に言われそうだけど（ｗ

単なる"業務フローソフト"じゃなくて、
"検討に使えるブレインソフト"って意味でしょう。

業務フローソフトならJCLとCOBOLがバッチ処理やってれば良いが、
ブレインソフトだとGUIGUIしてないとダメ。

バッチ処理ってのはＳヨがワープロで仕様書を書いたり出来るが、GUIはワープロで書けないね。

で、バッチ処理＝手続き、GUI＝イベントドリブン、てことじゃないのかい？

>>98,99
つまらん煽りは止めなよ。(意味があるなら別だけどね)

元の話に戻ると、Ｓヨと呼ばれる人達は皆 >>97 で言ってる内容を
出来ない人ばかりじゃない。
だったら、逆に出張32のＳヨの定義が現状と合ってなくて、
ＳヨとＰＧを別けるのは正しいとなるよ。

>>104
そりゃ君の属する会社がツマランだけだわ。
精通しているＳＥなど沢山居るよ。

反発だけで煽ってないでもっと視野広げろ。

Ｓヨってのを無くせば良いのさ。

視野を広くすれば、Software Engineer（プログラマと同義）だけで良いことになる。

>>103
煽ったわけではないですよ。

イベントドリブンという「仕組み」を実装するためには、
結局手続き型を組み合わせることで実現されている、
ということを言いたかっただけです。

アプリケーションを開発する側から見た、イベントドリブンや
オブジェクト指向といった発想自体はいいですし、熟練した
開発者であれば生産性向上に一役買ってくれると思いますよ。

>>102
え？するとオンライントランザクションを処理する
ビジネスロジックの部分は？
あきらかにここで言われている手続き型（要は上から下まで
一直線に流れるロジック）だよ。しかしこれを果たしてバッチと
呼ぶかな？
例えば銀行のＡＴＭで入金をした時のバックエンドの部分とか。
誰もこれをバッチとは呼ばないだろ？でもそこにはＧＵＩは
ないよ。ＧＵＩがあるのはＡＴＭの画面制御部分だけ。

>>108
102 で言ってる「＝」は、同等という意味じゃなく、
出張32が >>97 で言ってる内容を >>101-102 で解説しただけだよ。
その解説があってるかどうかは分からんが。

>>107
> イベントドリブンという「仕組み」を実装するためには、
> 結局手続き型を組み合わせることで実現されている、
> ということを言いたかっただけです。

そんなことは初めから判ってる。
そんなつまらんことで煽ってたら会話自体成り立たんよ。

>>106
そりゃ無理な相談だな。
システムエンジニア＝システム設計者だからな。
肩書きが複数在っても良いが、
設計者でないＰＧはＳＥとは言わないし、
プログラム出来ない物をＰＧとも言わんよ。

君はどうも、ＳＥに対して愚かな偏見をお持ちのようだね。

怒るな>>110
見方は幾つもあるんだから片方から片方を見れば偏見になるだけだろ。

で、イベントハンドラの解説は >>101-102 で言ってる意味であってんの？

>>111
> 怒っちゃないさ、呆れてるだけ。

> で、イベントハンドラの解説は >>101-102 で言ってる意味であってんの？

私に聞いて如何する？
お前が答えたらどうだい。（笑

>>112

煽る & 責任回避 山師の常套手段。

USELESS & UZEEEEEEEEE!!!!!!!

>>113
山師かい！

>>114
自分の能力を隠し、能力について「マイナス」を
想像させる可能性がある行動は避け、安全な能力を
示せる話にだけ参加し、もって他者の自分の能力について
判断可能な部分を常に自分の支配下におこうとする。

自分が外に出した部分については常に支配している
認識があるから、彼の提示した部分に対する異議への
拒否反応は凄まじい。

本当に才能のある人間からは隠そうとしても溢れ出てしまう
才気があり、見えているもの以上のものを想像したくなる。しかし
山師は我々に見えているものしか想像させてくれない。

山師と呼ばれたくなかったら、
もっと自分の生の姿を曝け出しなさい >出張32

現実世界ならまだ分るが、もっと自由な世界で山師スタイルを
貫く出張32。2ch に現実世界を求めるのなら次は
本名でも出したらいかがですか？

ありゃりゃ。
何時の間にか粘着軍団さんに囲まれちゃったわ。（嬉しい
元気よくバカ曝け出して無意味なレスで満たして下され。

>>116
こいつフリーかな、勤め人かな？
みんなどうよ？

>>117
なんでもいいけどすごく寂しい人間だよな。
こういう人にかぎって長生きするんだけど。

>>117
他人に絡まなきゃいい人なんだけれど、やっぱ日常生活が寂しいだろうな。
つーことでフリーかフリーに近い派遣に一票。

どうやらまともお方達らしい．．． > 114-119
取り合えず、116の投稿は取り下げさして下され。

すまん >> 114-119

>>115
っていうか、山師って言う言葉は、はずれてるんじゃない？

ああだこうだ言う前に日本語勉強しろ。

出来れば、スレッドの趣旨に沿った会話に戻したいのだが．． >> ALL

よろしく頼みまする。 m(_ _)m

とりあえずそれらしい御託を並べたドキュメントさえ作れば
それで格好はつく。
ドキュメントが動いて出力するわけじゃないもん。
問題は先送り、しわ寄せは後工程に。
成功すれば自分の手柄、失敗すれば人のせい。

はじめまして、山田（仮名）です。プログラマ経験者です。

>>27

># 「分業するならコミュニケーションは活発に！」

コンサル、SE、PG間のやり取りをまともなものにするために、
具体的にこう取り組んでます、みたいな話が聞きたいです。

私は、「コミュニケーション？そんなもんは知らん。やれ！」
というようなプロジェクトマネージャのいるデスマーチProjの経験も
あるし、みんながそのことをわかってるから特に対策を取らなくても
大丈夫だったProjの経験もあります。

でも、「コミュニケーションこうあるべき」という信念に基づいた方法を
取っていたProjに参加したことがなかったもので・・・。

以下愚痴モード。

#Projに参加した当日に、変数の命名規則表と、プログラム仕様書
（これをみてプログラムを書く）をポンと渡されて、Startというのが
少なくない。

たとえば、Web系の開発とかだと特にそうですが、命名規則とか
プログラム仕様書とかをWebで参照できるようにしておくように、

・「このプロジェクトは誰の為の製品を作るのか」
・「そのお客さんは、なんでこの製品を必要としているのか」
・「この製品で何がどう改善されるのか」

のような内容も掲示されていると、私のような馬鹿なプログラマでも
もっと仕事やりやすいのになー、と。

コンサルと客の会談の議事録を見せてもらっても、（もちろんこれを
見せてもらえないのも困るけど）、時系列なので
「で、最終的にどうしたいのよ？」って所をつかむのに時間がかかったり。

「そんなことはPGはわかってなくてもいいの」って言うのなら、曖昧個所の
皆無な仕様書もらわんとやってられん、と思う。

ええと、完全に内向きな話ですいません。

コンサル=業務を”コンサル”と銘打ってる会社に勤めてる人
SE=業務を”システムエンジニアリング”と銘打ってる会社に勤めてる人
PG=業務を（以下略

…などというような非常に後ろ向きな状況が現状なのでは？
ここはそんなことは百も承知の上で「あるべき姿」を討論するスレッドなんでしょうが…

なんというか言葉に踊らされつつあるような気がしないでも無い

>>124

そういう不特定多数が該当しそうなハンドルはやめて頂けませんか？
ハンドルを変更していただくことを希望します。

>>124
「知らしむべからず、もって寄らしむべし」
を地でいってますな（藁）

「ちゃんと理解しろよおおーー」
「もっと解りやすく説明しろよおおーー」

という不毛な打ち合わせという例とか

>>124
コミュニケーション以前にソレゾレの立場に付いての認識が重要だと思います。
支援者、設計者、開発者それぞれに置いてスペシャリストであるという前提が必要です。
自分の持ち場に付いての責任を負い関連知識も豊富に持つことが重要ですよね。
そのような人達の集まりであればコミュニケーションは意識しなくても活発且つ正常に
為されることと考えます。
で、上記の前提を満たさないのであれば、何処に問題があるのか・どのようにして補えば良いのか
を先に議論し明確にすべきです。
ここで重要なことは「どのようにして補えば良いのか」に付いての考察と協力する姿勢です。

age

>>1
話を最初に戻すけど、コンサルの実情は「営業マン」ってことで良いですか？

営業マンに失礼かと思われ

>>130
実情的には「現場部隊の露払い」程度かと

　・・本来「こんな局面でウチの商品導入なんて
馬鹿なことやめたほうがいいですよ」
的発言が許されるべきだと思う。
　けど、現場の仕事を潰すようなコンサルって
今のところアフォ扱いが常識だから・・・

>>132
まあ、確かに使えない高齢ＳＥを退職へ追い込む為に「コンサル」＝「営業補佐」への
配置転換をしている企業が大半だよね。
そりゃ良く判るんだけどさぁ。

でも、少数ではあるがまともなコンサルが居るのも事実なんだし、ＳＥとの作業分担を
考えれば「営業」ってことにならんかなぁ？

# ちょっと強引？

そんなに無理して世の中をSEと営業に二極化しなくても(;´Д`)

>>134
そうなんだけどね。
でもさぁ、コンサルは本来お客様の業務に付いてのコンサルテーションをして
その作業に見合った代償を頂くのがお仕事だよね。
だけど、情報系の紐付きコンサルはその代償を明示しないので分類が難しい。
そりゃ、ある程度の要件分析や概略分析・整理をされるので技術職なのかもだけど．．．
結局、ＳＥが再度調査するから重複しちゃうのよね。

>>135
ちょっとお邪魔します
大手電機のＳＥ（Ｓヨ？）からコンサルに転職したけど、
自分の技術力の無さに落胆したね。
ＤＢの再勉強（特訓）してます。
コンサルはＳＥ以上にお客さんに対して助言（言いなりではない）しなきゃ
ならんからはったりだけじゃダメなんだね。
みんなも勉強してる？（失礼か・・・）

>132
今度営業にくっついて行きます。
とんでもない案件持ってこられると困るから。

>>136
コンサルにじょよるんじゃないの？
システムコンサルならある程度の技術ないとダメかもね。
でも、経営コンサルとかITコンサルとかなら経営、業務よりに
コンサルしていけばいいんじゃないの？

>>136
> コンサルはＳＥ以上にお客さんに対して助言（言いなりではない）しなきゃ
> ならんからはったりだけじゃダメなんだね。

提案型のＳＥは幾らでも居るよね。
コンサルを経営面から眺めた企業戦略のコメンテータと位置付けるのか？
もしそうならば、戦略面に特化した報告書こそがコンサルの付加価値と言える。
勿論、報告書に付加価値が認められるかは依頼者であるユーザーの判断となるよね。
このように整理するとＳＥとコンサルは全く別の職業と言えるのではないでしょうか？
ＳＥは、設計書の良し悪しではなく実現されたシステムの評価そのものがＳＥの評価で
あると言える。
で、このように整理してみるとコンピュータ業界の紐付きコンサルの実態は本来のコンサル
と大きく異なり営業支援者であるように思うのですよ。

>>138
>このように整理してみるとコンピュータ業界の紐付きコンサルの実態は本来のコンサル
>と大きく異なり営業支援者であるように思うのですよ。

より対人折衝に重きが置かれると考えていいですか？
早く認められるようになりたいもんだ。

>137
さんきゅー

>>139
え？そうなの？
俺は紐付だから本来の中立的な助言ができず
自社のSEのための仕事を作る仕事しか
していないっていう嫌味に聞こえたけど。

？コンサルって？分類された職種なの？
ユーザーの立場から見たらメーカー（ベンダー）の人ってだけなんだけど。
我々がお金を払ってシステム構築契約を取り交わす以上お金を払うに値する
提案でなければならないわけ。
その提案を納得させてくれるためにも、提案側はユーザの業務にいかにインパクトの
あるプランかを技術的なバックボーンをまじえてプレゼンする必要がある。
で、営業とＳＥ（システム構築のスキルを持った人）が共同で取り組んで
いるんだと思ってた。
もっとも、最近の提案は技術的な話ばかり先行して、ユーザーメリットをちっとも
アピールできてないものが多いんだけど。
ベンダーの内部事情もどろどろしてそうだけど結局は契約とらないと話にならないんじゃないの？
要するにベンダーのコンサルって手持ちの資源を総動員して契約をとることなんだと思うけど。

>>141
ユーザーメリットはユーザー自身が考えるのは基本中の基本です。
ユーザーの考え出したメリットを吸い上げたりエンリッチするのがベンダーのお仕事です。

# 後で騙された！って泣きをみない為です。

>>142
凄い当たり前な事を言っているんだけど、でもエンドユーザーって
そう思ってない人多いよね…
丸投げすると自動的に（自分たちに都合が）良いものが出来上がると
思っている人って、どういう頭の構造してるんだろうと思う。

>>143
いや、丸投げすればオッケーとはだれも
考えてはいないと思うよ。
　ただ、問題を抱えている組織、
とりわけ、情報関連の問題を
抱えている組織というのは往々にして
組織のあり方のコンセンサス的なものも含めて
混乱している事が多いわけで・・・

　んー、例えれば、自分の体の状態を
冷静に把握・説明できる患者さん
というのは医者の理想であっても
現実には居るわけないじゃん・・・ということ

>>144
しかし、当事者にもよく分からない組織を外部から最適化するって、
機械相手じゃないんだから、と思うぞ…

実は医者も患者の症状を掴むのに、いろいろと試行錯誤する場合が多い・・・

>>145
必要な情報と綿密な調査にて、助言等を行うことは出来ます。
ですが、最終的にメリットを考え決定を下すのは結局ユーザー様自身なんですよ。
何方もそれについて責任を取ることは出来ませんからね。

勿論、情報は多ければ多いほど良いでしょう。
ですから、現状調査費用等を予算に盛り込んで頂いて導入前に調査を依頼するのが
最善ではないでしょうか？

ごもっとも。結局採用の可否を判断するのはユーザーだと認識している。
情報は多いにこしたことはないと思うけど、昨今の経済状態から現状調査費という、
言わば怪しげな費用がなかなか認められない。
出てきた報告書の内容が／そんなことわかってるわい！／という結果が多いので。
で結局、お金を出す側の理論として、いい提案を出してください。
（そちらが必要な情報は提供しますから（費用は払いませんよ！））いい提案だったら
契約しましょう。となるわけです。
契約を取るための事前調査は営業費でしょうという理論はベンダーにとっては非常に理不尽
と感じるかもしれませんが、これがビジネスの現実です。

>>149
> 契約を取るための事前調査は営業費でしょうという理論はベンダーにとっては非常に理不尽
> と感じるかもしれませんが、これがビジネスの現実です。

つまりは現状調査費をサービスしろってことですね。
そんなの全然理不尽じゃないですよ。
理不尽なのは、確固たる導入意思も無いのに賑やかしで「良い提案出せ！」って
要求するユーザー様です。
まあ、導入意思があるのか無いのかは打ち合わせ姿勢を見れば明らかなのでそんなに
困りませんけどね。
どちらにせよ時間を割こうとしないユーザーさんは導入意思が無いと見てよさそうです。

ベンダーのコンサルとは、コンサルティング営業のことだよ。
まあ、ていのいい営業と思っていた方がいいと思うよ！
客先に出かけて、客の要望を聞き、提案書を作成し、プレゼンし、案件受注
できれば、それをSEにトスするといった具合に。。。

営業と技術を両極端に置いて考えた時、SEは技術より、コンサルタントは
営業よりということになると思うよ！

外資系コンサルタントのつぶやき　第10回　会社に自分の席がない
http://www.atmarkit.co.jp/fengineer/rensai/consult/consult010.html

席有る仕事の方が良いな。ハケンSヨやハケンPGやだった。
コンサルの良さって何？

↑これ読んだことある。
>>1に参考になるね、特に５回目ぐらいまで。

定義はきわめて簡単。

企画室や経理部から仕事をもらうのがコンサル。
ＩＳ部門またはＩＴ子会社からだったらＳＥ。

見かけの仕事の内容はほぼ同じでも、
ミッションの相違の源泉はココヨ！

＞１５３
ずいぶんひどい話だな。

株主や経営者にとってみれば、
正社員もコンサルも等しくコストのはず。
実績をあげた対価を支払うだけ。
所詮は同じ雇われ人だろ。

第一秘書と政策秘書の違いかな？
同じ番犬同士でも金時計組がいるってことか。
いや、牢名主様気取りか。
正室と側室かも？

ソドミー日本企業には吐き気を催す。
行き着くところまで行けばよい。
いや、そうすべきだ！

>>153
あく煎茶か？
あく煎茶はかなり多めの帰社席が用意してあって、
帰社しても居場所に困らないそうなんだけど...

どっちも虚業

ＳＥじゃなくコンサルって看板だと単価は倍以上するから
給料変わんなくても自社でワガママ言えるYO!
ＳＥって肩書きだと月３００万とか取るの難しいから年取っただけでクビだけど
コンサルなら文句言われないYO!。
コンサルって肩書きはようはＳＥの生き残る術かもね。
さぁ君も明日から早速名刺にコンサルと刷ろうぜ！
３０過ぎたら君もコ・ン・サ・ル！
いやっほ〜いっ！

Futureは？
SE？コンサル？
自称ITコンサルだって聞いたけど．

>>160
そのスレはあるよ（てか、知っててやってるね）

今月のCIOマガジンにファミリーマートのCIOがコンサルに対しての苦言を書いているよ

↓こんな方もいらっしゃるようです。
コンサルで独立なんてのもいい目標ですね。

経営コンサルだけど
http://natto.2ch.net/manage/kako/1001/10018/1001855044.html

>>163
ふぅ〜ん

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜ここまで読んだ〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

あぼーん

>>163
ＩＴ業界のコンサルでそんな人は希だって。
自称コンサルばっかだし、客の商売理解して経営コンサルできる奴なら、
逆に独立しなきゃ、やってられんでしょ。

本物のコンサルがでたら、スレが止まったな（激ｗ

>>167
それって163を指してるのかなぁ？
彼らならちゃんと「第三者であり限界がある」って述べてるのだから自覚されててまともだと
思いましたよ。

だれか、168の解説してくれ。

コンサル＝聞かれたことに答える仕事。顧客に知的優位であることが条件。
　　　　　顧客とのコミュニケーション能力が無ければ落第。
ＳＥ＝言われたことをやる仕事。実行に関して専門的効率性があることが条件。
　　　実行に関するリスクマネジメント能力が無ければ落第。

まあ、二元論じゃないから反論もあるだろうが。

ＰＧのコンサルもコンサルだったりする

コンサルは概念のレベルから実装の入り口まで。

コンサルは、
顧客の中でシステム部門が次につくるシステムの
企画支援・概念定義をする。（定義した振りをする）

SEは実装レベルから。

昔、SEってコンサルっぽいところも含んでたけど、
今SEっていったら。。。。。。。
執行部隊だ。

>>172
ネタか？それとも本当のヴァカか？

>>173
出張32と同じヴァカ！

>>174
納得

(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)ｳﾞｫｹ!!
　　
イーベンチャーサポート
http://science.2ch.net/test/read.cgi/infosys/1018064816/l50
偉そうなこと書いてるけど、所詮は派遣業免許なしの、タダの違法派遣屋

(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)(　ﾟДﾟ)ｳﾞｫｹ!!

>>173,174
実務経験の乏しい青尻さんは黙ってて下され！
コンサルなんてもんは所詮隙間産業であることを自覚してから投稿されたし。
競争原理を少し掘り下げて考えれば判ることだしね♪

ど素人の質問させてください。
SAP R/3 の会計上流コンサルって何をしているのでしょう?
当方、ITほぼ初心者なのですが、経理畑でずーっとやってきて、業務経験だけは
あるんですが、それだけでお声がかかったもんで。
とんでもありませんが、SEなどなれませんし、こんな自分に何を求めているのかと思って
不安なんです。どなたか、お助けを。

>>177
普段誰からも相手にされなくて２ちゃんで能書きたれるしかない奴が
偉そうな事言っても説得力無し！

>>179
別に偉そうなこと言った覚えは無いんだけど．．．

コンサルは基本的に顧客を正論で説得せんとダメだしね♪
顧客毎の分析って言っても．．．
日本じゃ方法論は限られるし、客受けを考えれば「楽」がキーワードになってしまよ。

>>180
う！！！
抜けてしまった．．．．（汗

# 洒落でなく（笑

>>180
正論言ってるつもりらしいけど、同意する人がいないのは何故？
所詮は自覚の無いひとりよがりということの証拠だね。

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
イー便茶役員一覧

社長池上（テンプスタッフを追い出された、人材派遣業ヒューマンアイも経営し、私腹をこやしている）
菅原（住商情シスで仕事をしたと威張ってる、偽EVS Framework開発者として、JavaONEで演説予定）
山本（リクルートをDrop outして人材派遣業という、いわゆる使えない社員の王道、ヒューマン偽アイコンサルタント）
児玉（なんだかんだで、結局辞めた）　

こんなやつらは、ゴミ以下のイーベンチャー　ゴミサポート会社！！
（ついでにゴミSE巡回サービスもよろしく！！）
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

単純かもしれないが、ＩＴの場合は、
コンサル　　→　　スポンサー ＝ ユーザー部門
ＳＥ　　　　　→　　スポンサー ＝ システム部門
のような気がする。煎じ詰めれば。

あと、もう十分言い古された事なんだけど、
日本の場合、実体の無いものにはお金を払わない慣行にあるよね。
どの分野のコンサルも、実体のあるプロジェクトにくっ付いて、
風呂敷を拡げるしかないみたい。

この点でコンサルは、化粧品販売と良く似ているよね。
例えば、対面販売で１０,０００万円で売っている化粧品があるとする。
これ分けて、商品を平台で５,０００円で売り、お化粧コンサルを５,０００円で
売ったとしても、誰もコンサル代を払おうとしないよね。
これと同じような気がする。

訂正
×：１０,０００万円　→　○：１０,０００円
ｽﾏｿ

コンサル：こんなこと出来ますよ〜
SE：こんな風になりますよ〜

端的にいえばこうじゃないか？

　　　　　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
Λ＿Λ　　|　君さぁ　こんなスレッド立てるから　　　　　　　　 　|
（　´∀｀）＜　厨房って言われちゃうんだよ　　　　　　　　　 　 　|
（ ΛΛ つ ＞―――――――――――――――――――‐＜
　( ﾟДﾟ) ＜　おまえのことを必要としてる奴なんて　　 　　　　　 |
　/つつ　　|　いないんだからさっさと回線切って首吊れ　　　 　|
　　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_／

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

（＾＾）

（＾＾）

（＾＾）

ん〜なんかおにぎりとおむすびぐらいの違いなんだなきっと。

出張32さん曰く
>私としては、使用する言語やＤＢに精通していないとＳＥとは呼べないと考えてます。

その通り。だけど、俺は使用する言語すら精通していないな、SEとは呼べないな。
でも、DBで言えば、例えばOracleをチューニング、運用できる仕組みができれば（これが大変なんだが）、
それはそれで立派なSEと呼びたい。
俺は CとPerl、Javaくらいしかコーディングできんけど。Javaは半端オブジェクト指向言語で気持ち悪い。
ちょっとしたツールにはPerl、システム開発だと分析／設計してJavaというパターンだな。
DBは使わないこともある。

でだ、情報系のコンサルというのは何をするのだろう。
・システム化を検討してる会社に行って、ビジネスプロセスを分析して、顧客の要求を仕様書にまとめる。
上記だと、SEの仕事と何らかわらんな。
あとは、特化した技術を持っていて、そのトランスファー、とか。

>>1は コンサルということで業務の勉強をさせられています。
というが、当然ではないのか？勉強して提案するのが最終的な仕事（SIに繋げられれば最高）だと思うのだが。

情報系のコンサルって、いろんなパターンがあると思うのだけど、ユーザが「コンサルに来てもらえるんだから」
なんとかなるだろ、って意識があるのではないか。まぁ、ユーザが何のためにコンサルに入ってもらってるのか
を理解できてれば（コンサルがそれを理解させていれば）、「コンサルはアフォ、コン猿」なんて言われないと
思うのだが。なんで猿呼ばわりされているのかわからない。それって、コンサルやってる人間が猿なのか？

>>192
> それはそれで立派なSEと呼びたい。
責任の範疇において正解かと．．．

> でだ、情報系のコンサルというのは何をするのだろう。

実情だけを書きますと、「顧客から受注を貰う為の要件定義」を行う人です。
勿論、「受注を貰う」わけですから「経済用語」をちりばめた(ホートフォリオは必須？）定義書に
なることでしょうね。

勿論、その定義書がそのまま使えればありがたいのだけどね（笑

# まあ、目的や目標を決定する為の参考程度と考えとけば安全でしょうね。

>>192
＞情報系のコンサルって、いろんなパターンがあると思うのだけど
コンサルって、契約書に業務内容を規定して渡しておいて、月いくらかもらうっていう仕事です。
関西では中小は口約束もおおい。　だからパターンというか、契約次第ですね。
（通常収入が決まっているので、極力余計な仕事はしたくないし、客と契約によっては儲からない）

＞なんで猿呼ばわりされているのかわからない。それって、コンサルやってる人間が猿なのか？
多少2chでは誇張される傾向がありますが、実態はお金をもらっている相手の仕事の一部を
負担するというものですから、払ってないところに文句言われてもなぁってとこでしょう。
大きな仕事をするに当たって、コンサルは顧客のリソースを圧迫したがりません。
それは仕事を任されているという考えだからです。　それが結局、船頭が二人いるような状態を作って
問題を起こしているんじゃないでしょうか。　SEから見ると、居なければ混乱を防げる存在に見えます。

コンサル＝馬鹿
ＳＥ＝アフォ
ＰＧ＝天才

>>195
正解！

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

age

触手としてＰＧとＳＥ
業務内容としてＳＩとかコン猿
って思ってたけど違うのか？

ＳＩとコン猿のどっちがＥＲＰ作るの？
あとＳＥってＰＧに毛が生えた程度だと思うんだけど違うの？

>>199
なんかいろいろな要素がごった煮状態で記憶されているようだが大丈夫か？

あぼーん

あぼーん

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

違いなんかあってないようなもんだよ。

肩書きは、会社の戦略の問題。

実質は、本人の意識の問題。

おいらが知っているほんの一握りの優れた連中は、
・PGとして一流の腕と知識を持ち、
・SEとして卓越したリスクと組織のマネジメント力を持ち、
・Consとして、柔軟で計算高いコミュニケーション能力と問題分析力を持つ

って感じだよ。常に、次のステージを見越してすごしてるから、
経験もやり方も、無駄がないんだよね。

ただ、卓越した経営センスを持つ奴は、ほんとに少ない。
おれは経営者が目標だから、そう意識してコンサル時代を過ごすしたよ。

本人が何を見てる(目指してる)かによって、受けられるコンサルサービスの
質や方向性って、かなり変わってくるよ。
実装段階になると、選択肢が少ないから逆に収束するけど(ｗ

あぼーん

某Ｈ系自称開発力Ｎｏ．１と言っている会社はコンサル事業に力を入れ出した。

そこのコンサル研修のひとコマ。
１．コンサルタントは口先だけです。クライアント（顧客）が動くように仕向けるのが仕事です。
２．クライアント内のステークホルダーは幹部です。ヒラ社員はこの際無視。
３．クライアントが自主的に動くようにしなければなりません。コンサルが主導権持つと
　　もしもの際に責任取らされます。
４．コンサルはボロイ仕事です。口先だけで金が稼げます。






　　　　　　　　　　　　　　　　　　アフォらしくなって、漏れはこの会社を辞めた。

悪銭、ベア（KPMG)、PwCについて語ってくれよ。

>>207
>某Ｈ系自称開発力Ｎｏ．１
　○立ソフトウ○アエン○ニアリ○グのことですね？

age

今日戸塚に用事があったのだけど、
○立ソフ○の戸塚支社、夜なのに明かりがざぁーとついてますた。
いつもあんななのかな、、、

>>205
コンサルをConsと約す香具師は始めて見た。
わざわざ分かり難く省略せんでも良いと思われ。

>>211
事業多角化で電照菊を栽培してるんだよ。知らなかった？
あれ、ひよこだったかな。

読者の中には、メインフレームからオープンシステム、そしてウェブアプリ
ケーションと情報技術（IT）におけるキャリアを重ねてきた方もおられると
察する。今、もしこの文章をお読みのあなたがそれに該当するならば、あなた
の年齢層はおそらく30代半ば前後、もしくはそれ以上だろう。あなたがエンジ
ニアならば、冒頭のようなキャリアを経てきたことについて、そのときどきの
ITトレンドに順応してこられたことを誇りに感じておられるに違いない。

過去において、システムエンジニア（SE）あるいはプログラマといった
業務は、顧客の要望の詳細なヒアリングに始まり、それを要件定義と
してまとめた分厚いシステム仕様書を作成し、顧客の承認を得た後は、
全体設計、基本設計、詳細設計、プログラミング、単体／結合／総合
テスト、カットオーバー、運用と、順に各フェーズをこなしていった。
そうした作業工程の中で、システム構築に関わる者たちは皆、ある種の
連帯感を伴った共同作業への参画意識が高かった。構築したシステムの
カットオーバーを果たした後の、開発チームの打ち上げのビールの味は
格別だった。

SEとしての誇りは、いくつかのプロジェクトをフィニッシュに導くこと
のみならず、顧客の要望のヒアリングの時点で、自らが将来完成させる
であろうシステムの構成を、ハードウェアからソフトウェア、あるいは
サポート・運用形態に至るまでくまなくイメージできることだった。
そうした能力を持ち、顧客と直接折衝できるSEは、システムインテグ
レータ（SI）職場の花形でもあった。

だが、現在のIT業界において、そうした花形SEの地位を奪う層が登場
してきた。それが、プログラミングなどを経験したこともない「コンサル
タント」という職種の人たちである。コンサルタントは、経営効率化が
進んだ国内外の先進企業例との比較によって危機感を抱く経営者の心理
に取り入り、プレゼンテーション・ツールを駆使して、ITを介した「夢
の企業経営」を提示する。これは、SEには到底持ち得ないスキルである。
いやむしろ、プログラマからキャリアを重ねてきたSEは、情報システム
の構築・導入あるいは維持管理がけして楽なものでなく、また、相応の
コストも掛かるものであることも経験上熟知しているため、ITが夢を
実現するなどという大層なセリフは倫理にもとると考えるであろう。

しかし、コンサルタントはそうした負の部分をひたすら隠匿し、ことさら
よい部分だけを強調する。彼／彼女らに言わせればそれが「お客様主体」
なのである。そして、いつの間にかコンサルタントが「上流」、エンジ
ニアが「下流」という二重構造をIT業界の中に作り上げてしまった。
できるだけ多くの夢を語り、そしてそれに惹き付けられる「クライアント」
を獲得できるのが優秀なITコンサルタントと見なされ、その夢の実現の
ために地味な作業も厭わないエンジニアは、ホワイトカラーの中でもブルー
ゾーンの人間と化している。このような状況下では、昔日にあったSIと
しての連帯感は生まれようがない。

人件費の安い地域への技術移転の問題がIT業界においてもかまびすしい
が、昨今とくに顕著になっている上記のような二重構造も、IT業界に
おける国内のエンジニアの能力の伸長の機会を妨げ、職業としての魅力
を低下させていると筆者は考えるのだが、いかがだろうか。

ソースは何でつか？

ソースは、ここ
　http://www.ikari-s.co.jp/

＞219

わたしゃSEからよろずコンサルもどきに強引にスキルチェンジしたよ。
案件がでかくなった。でもリスクもでかくなった（笑）。

>>214-219
若干文章のこなれないところもあるけど、まあいい内容だな。

提案力のある優秀なＳＥが少ないっての問題なんだと思う。

優秀なSEが育たなくなったのはコンサルの台頭のため、ってのが
>>214-219の主旨だろう。
その実どっちもどっち、もたれ合いの構図なんだが、上流下流という
区分に抵抗があるのは俺も同意。

優秀なSEが育たなくなったのは214のような過去のSEが提案力なかったから。

まあたしかに、出来合いのプラットフォームとアプリケーションじゃ
提案のしようもない罠。
つーか、それは今のERPとかCRMとかの３文字システム導入プロジェクトでも
基本的に変わってないな。

提案力のあるSEはたしかにいた。でも、今よりももっと情報リテラシの
低い顧客の前では「提案」というコトバは使えなかった。
提案なんて言おうものなら「生意気言うな！」と逆切れされるのが
関の山という時代だったから。
で、そうした逆切れ顧客しか相手にできなかった不幸なSEが、今では
逆切れコンサルの下で使われてさらに不幸になってる罠。

http://itpro.nikkeibp.co.jp/free/NC/yajima/20030710/1/

コンサルタントもどきや偽SEを送り込んでくる企業があるのは事実である。
コンサルタントやSEを出入り業者と見なして苦行を課す日本の商慣習は、
半人前を鍛える効果があるかもしれない。しかしそんなことを続けると、
優秀な人材は寄りつかなくなる。旧態依然の外注管理をしている企業は、
「イコールパートナー」という言葉を再考するときではなかろうか。


コンサルもどきを駆除しようキャンペーンが始まりますた！
同時にSEもどきも駆除されます！

あぼーん

あぼーん

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

紺猿：口だけ番長
SE：土方

何となく状況に合わせて、いろんな役割はたしてるんじゃない？

　営業≒コンサル≒ＳＥ≒ＰＧ

丸投げする方　コンサル
丸投げされる方　SE

クライアント 「できますか？」
コンサル 　　「できます」
ＳＥ 　　　　「できません」

大した仕事をせずに高給＝紺猿
残業しまくりでやっと高給＝ＳＥ

口先重視＝紺猿
理論重視＝SE

test

うそつき　　紺猿
半病人　　SE

>>分かる奴
PG = 単価1とする。
SE = 1.5 〜 2.0
コンサル = 2.0 〜 4.0
だとして、給料も、単価に比例するわけ？

PGとSEは同一給与カーブの勤務年数が違うだけ。
コンサルは住む世界が違うのでSEの3倍くらいだな。

>>243
どうも。
PG→SEと進化するってこと？
SE→コンサルと進化することはないのか？
3倍てのは、SEが低いのか？コンサルが高いのか？
平均的な30歳でコンサルの給与は、どれくらい？

PGのままだと単価が安いから、肩書きはSEにしとく。
30歳で1000万超えてなければ負け組みだろうな。

この業界、ウマいな。

>>246
黙れ！＞厨房

コンサルは理想ばっかだから
対応が大変。

>>245
年収が？
そんなに行く物なの？

やめて

↑あげ厨氏ね

コンサル=>トップダウン
ＳＥ=>ボトムアップ

クライアントが自主的に動くようにしなければなりません。
コンサルが主導権持つともしもの際に責任取らされます。

warata