マンガでよめる痔のこと・薬のこと

システムエンジニアとして仕事をするにあたり、
よく業務知識や業界知識を持つことがとても重要だと
耳にするとがあります。

顧客の業務知識を有することで、顧客のニーズがわかると
いったことがその意義でしょうが、それってそんなに重要ですか?

要件をきいて、業務的にわからないことがあれば、
顧客に質問し、イメージを明確にしていく。
そのうち経験によって、若干の業界知識も身につく。

これの繰り返しレベルでいいと思うのですよね。
これは、ユーザー系であっても若干の差こそあれ同じだと
思っています。
※ベンダー系の人がユーザー系に転職して成功するのは
 技術知識や管理能力、積極性が携わっているからであり、
 業務知識は、業務の中で都度覚えればよいかと思っています。


いやいや、何を言っているんだよ、といった意見。 または、
業界知識がとても重要になった。業務知識があったおかげで
プロジェクトが成功したといった体験談があれば教えてください。

このQ&Aに関連する最新のQ&A

A 回答 (8件)

実は、ほぼ同意ですが...



金融などは特にそうかもしれません。
「SEには業務知識や業界知識が無いし、
システム構築上の必要最低限しか知る気も無い。
必要になるまで聞いてもこない」
ということで顧客側が外注さんの使い方を心得ていて、
そのように対応してくれることがよくあります。
また2次請け以降であれば、その辺は元請がやってくれるので、
「システムのことだけ考えてやればいい」 という場面もあるでしょうね。

その前提でいけば、
「SEやPMのミッションは納期と予算どおりにシステムを完成させることでしょう?
業務知識は顧客と業務用語で会話が成立する程度の最低限の知識でいいよね?
最大のパフォーマンスを出すためのシステムアーキテクチャ設計には
業務は関係ないよね?
その都度要望を的確に聞きだせるコミュニケーション能力こそ大事でしょ」
人によっては、
「それが業務上どう運用されるとか、顧客にどう役立ったかも興味ない」
でもSEやPM,PLとしてやっていける世界です。

おそらく貴方は成功しているわけですし、
特に問題を感じない以上、現状そのままでよいと思いますよ。
おそらく必要最低限以上ものはクリアしているものと推測しますので、
そういう方に「必要ですか?」と聞かれれば、「貴方にはこれ以上不要でしょ」
と回答することになります。
でも、入門レベルの人が業務知識を覚えることを怠けたり拒否したりしてたら
「それは違うだろ?」と思うかもしれません。

まあ、コンサルの場合は、お金の出所になる人(経営者等)に対して、
業務改善を提言、提案することがあります。その場合はやはり、
業務自体や業界動向、その分野の成功例、ベストプラクティス等
を知っている必要が出てくる場合があります。

とはいっても、「名乗ったもの勝ち」で、
「ITコンサルタント」なんて肩書きの方は、(仕事内容は別だが)いくらでもいるのが現状です。
多くの場合、実情は単に上級SEもしくはセールスエンジニアでしょうね。
    • good
    • 0
この回答へのお礼

的確な回答ありがとうございます。私もそう思います。

コンサル(≒アナリスト)であれば、業務知識と技術的知識で
顧客の側に安心感を与えつつ仕事を受注したり、提案したり
しますよね。でも、その業務知識って業界の話をしたり
他社の実例を話してみたりするだけで、業務の知識というほど
ご大層なものではないと思います。

また、業務知識がセールスや客を安心させる為に必要というので
あれば、そんなに深い知識でなく経験で学べる程度の知識だと
思うのです。
 ※実際の業務知識なんて、顧客側で事務員(社員)として
  働かないと、せいぜい本や顧客とのコミニケーションからしか
  学べないと思いますし・・・

ITサイトやIT情報誌で、IT社会で生きていくには何の
スキルが必要か?といったアンケートを見たことがあると
思います。その中で、「(顧客の)業務知識」といった
回答が上位に挙げられることが多いですが、この業務知識が
上記に記載した業務知識だと考えると、甚だ疑問なんですよね。

ありがとうございました。

お礼日時:2008/04/19 10:08

・下流SE,プログラマの場合


 全く業務知識がない人向けの設計書を書く・説明するのは手間がかかるので、同じ値段なら業務知識のある人が喜ばれるでしょう。逆に言うと業務知識があると単価を上げてもらう理由になる

・上流SE、コンサルタントの場合
 言われたことをやるのであれば、お書きのように業務知識無し&必要な点について質問することでやっていけるでしょう。
 そうじゃなくて、システム化提案をする等であれば、顧客と同レベルの業務知識が必要です。
 つまり、上の場合と同じで、業務知識があるとよりたくさんのお金を取れます。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。また返事が遅れたことすみません。

システム化提案をするとき顧客と同レベルの知識を持つのは無理でしょう。業界ごと、会社ごと、プロジェクトごとに業務は全然違います。

生保、損保、共済、どれも経験しましたが
顧客の中に潜む業務のややこしさは、実際にプロジェクトに
参入しなければ結局わからないものだと思います。

提案時には、今まで培った経験則レベルの知識で提案しても
なんら問題ないと思いますが?

生保業界のD社に提案したいからといって、生保業界の
ことを、D社社員レベルになるまで、
事前に勉強しようとしても無理でしょう。

つまり、業務知識なんて自分の経験レベルの知識で
十分ではないでしょうか?



驚くような回答や、しっかりした経験談がでるのを待っていたのですが、
どうも表面上のありきたりの回答しかでなかったのが残念です。

お礼日時:2008/05/31 20:48

給与システムでの年末調整や自治体向けの業務システム


等の税金計算や法律・条令にもとづく税額・補助金等を
扱う物等では、法改正に伴う制度の改変によるシステム
変更も良くあり、現在の制度の内容と変更される内容を
共に理解できていないとシステム全体の設計作業はまず
無理です。
#最近よく耳にする例では後期高齢者医療制度
#法律の施行寸前になって名称を変えようと言い出した
#人がいましたが、その一言で、それまでの数ヵ月間に
#及ぶ開発作業が配布寸前で手戻りさせられて苦労する
#人が大勢いる事をどう思っていたのでしょうか?
    • good
    • 0
この回答へのお礼

回答が遅れました。

あなたのその知識、今の(過去の)仕事で必要だから
今の仕事についてから勉強したのでは?

給与システムにおいて自治体向けや産別などで個々に計算が
違うのでしょうが、それってその仕事に従事したから
勉強したことですよね。

ベンダーさんで、技術知識があるけど業務知識がないから
業務知識を覚えたいとい人がいます。
業務知識なんて、業界や会社ごとに違うのだから
何を覚えたいといっているのか不思議でならないです。

お礼日時:2008/05/31 20:41

#1です。


金融に常駐するシステム開発の派遣でした。
確かに業界知識はいらないですね。
でも、業務知識は無いと仕事はなにもできませんでしたよ?
特に受け持ち担当もあり、まず業務の勉強をしました。
やっぱり、あなたの職場&あなたには必要ないって
いうだけじゃないですかね。
自分は人にそれが重要だなんてわざわざ
言ったりはしませんけどね。

こんなところで聞いてみるより、
自分で試してみれば良いんじゃないですか?
仕事のしかたが変わるかもしれませんよ。
もしやってみたけど必要ない気がした、というお話なら、
人になにかを聞く必要もありませんし。
    • good
    • 0
この回答へのお礼

回答が遅くなりました。

業務知識がまったく必要ないとは思っていませんが、
そのプロジェクトに参入してから、もしくは派遣先に行ってから
仕事に必要な業務知識を身につけることは当然として
例えば、次は生保会社に派遣するだろうから、
事前に生保業界のこと勉強したりしますか?

結局、そのプロジェクトに必要な分の業務知識しか
身につけてないのではないでしょうか?

聞きたかったのは、業務知識を重要視しているが
どの程度の業務知識を、プロジェクトに参入する前に
事前に習得しておくべきとみんな思っているのか?
ということであり、
仕事で業務知識が必要なんてのは、当たり前です。

お礼日時:2008/05/31 20:34

金融システムのPMを実施していると言う事であれば、かなりの経験をお持ちであると推察します。


PMの仕事って、プロジェクト(いわゆるコスト・品質・タイム・調達など)のバランスを保つ事ですよね。当然ステークホルダとの調整にも気を使わねばなりません。では、そんな役割の人に必要な知識ってなんでしょう?
私が思うに、最新の技術動向・業務知識・コミュニケーション力等はPM(SE)として必要ですが、深さはさほど求められていないと思います。逆に幅広さが求められていると思います。部下にスペシャリストが居れば済む話ですから。
ですので、最低限必要なのは幅広い知識(業務知識含む)で、その他に得意分野(深い基盤系知識・深い業務知識等)は1つの武器にはなりますが必須ではないと思います。

以上のことから、MOLUさんが上級SE・PMである前提で考えれば、経験で業務を覚えていく程度で良いと思います。

但し、上流工程でチーム内に業務知識がない人ばかりの場合、最良のシステムが提案・設計できない等のリスクは高くなると思われますので、チームとしては業務知識をサポートできる要員は必要と思います。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

実際の現場で、技術スキルでなく業務スキルがを所有する
部下はほとんどいないと思います。
なぜか?
部下も、日々ITを学びITのスキルを身につけているのであり、
業務知識を学んではいないからです。

顧客の業務知識を学ぶというのは、IT系列のベンダーからしてみれば
業界の本を読んでみる、顧客とコミニケーションをとるくらいからしか
学ぶことはできないです。それ以外の方法ってあるでしょうか?
また、上記レベルであれば経験で培うことができると思うのです。

少なくとも私も部下だった(今も場合により部下になることも
あります)時期がありますが、そのとき業務知識を覚えることより
もう1つ言語を覚えたり、DBの知識を覚えたり、最新の技術の
動向を覚えたり、最新の業界のニュースを読んだりする程度でした。
 ※今も、やっていることは変わらないですけど…

あとは、No5さんの回答のとおりです。


最初、質問したとき、なかなか意味を理解してくれる回答がなく
困っていましたが、幾人かの回答で多少救われました。
ありがとうございます。

お礼日時:2008/04/19 10:22

ぬるい仕事してる場合、部下がついて来ないと思います。


特定さんやフリーのエンジニアさんはシビアだから、即座に抜けちゃうでしょうし。
ただ、社員さんのレベルによっては、かばい合いもあるでしょうから、ぬるい会社に就職すれば、それなりに幸せなんじゃないかと思います。
    • good
    • 1

顧客がメインとしている業務内容を知ることにより、何を必要としているのかが分かります。



実際にSEやPMとして顧客と接するようになると分かりますが、お客さんは「最初は全ての事に対してうそをつく」
という傾向があります。
何も顧客が意図的にいじわるして嘘をついているわけではなく、
顧客自身のニーズが自分でも分かってない っということが多々あります。

顧客に「こういうシステムを作ってくれ」と言われて、そのとおりのシステムを作ることは確かに可能です。
しかし、顧客が勝手に思い込んで提案したシステムが必ずしも顧客のニーズにマッチしているものとは限らないのです。
そこらへんをもっと掘り下げてゆくと、顧客の業務内容に対するニーズをかなえるためのシステムが別に有る というのは多々あります。
その深くうずもれたニーズや本当に適したシステムを提案するためにも顧客の業務知識は少なからず必要となってきます。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

実は、SE(兼PM)暦10年です。
金融を中心に通信も流通も含めて、
数々のプロジェクトも手がけてきました。
要件定義も何度か実施しました。
ユーザー会社からPMとして表彰を受けたこともあります。

しかし、詳しい業務知識が際立って役立ったということは
残念ながらないです。
金融システムの流れも基盤もアプリ(汎用系が主)もイメージと
して持っています。そこそこの業務知識もあります。

でも、行員さんや保険やさんに比べれば少ないと思っています。

ただ、困ったことはないです。
融資業務、証券代行業務、その都度話をしながらやればできました。
1つ1つ行員さんのイメージとこちらのイメージを
絵を書いて刷り合わせて、要件定義を形つけていけば、
できあがってきました。

できれば実体験を元に回答して頂けると具体的なイメージが
もてるのですが、どうでしょうか?
よろしくお願いします。

お礼日時:2008/04/17 13:46

やってみればわかりますよ。



重要じゃなければ誰も言いませんし、
逆に業務知識は後からついてくるから
知らなくてもぜんぜん平気、
というハナシになっているはずです。

ただ、あなたが重要でないと考えているなら
今のあなたにとっては重要じゃないんでしょうね。
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q業務知識をどうやってみにつければいいですか

新卒で入社してレンタルシステムをプログラミングするのですが
業務知識がなく仕事ができません

業務知識をみにつけるいい方法を教えてください
ちなみに仕様書とかは忙しくてないらしいです。

簿記とかの勉強ってレンタルシステムに必要ですか?

参考になる書籍やサイトもあれば教えてください

Aベストアンサー

最初に業務知識は勉強しないと身につきません。
次に業種知識は業界独特の言葉表現の勉強と後の答えは現場にあります。
(新人のうちは最低でも1週間位かけて客先で朝一番から最終まで現場にいて何をしているか見ないと)
掃除や荷物運びも手伝わせます。見込みの有る新人にはこれをやらせます。答えは常に現場にあります。

さて
新卒で入社してレンタルシステムをプログラミングするのですが
業務知識がなく仕事ができません
と有りますが、
新卒でもう実践ですか?OJD(On the Job Development)でもやっているのでしょうか?
どの程度の規模で開発手法は何で開発言語は何であなたのそのプロジェクトの位置付けは?
それによって回答は変わります。
今は、仕様書が無いとの事アジャイルででもやっているのでしょうか?

業務知識が無いと仕事が出来ないとありますが、業種の知識ではなく業務の知識なのですね。

分からない事が多いので、
簿記とかの勉強ってレンタルシステムに必要ですか?
にだけ答えたいのですが
レンタルの場合システムにもよりますが、物をレンタルした場合は当然償却期間の圧縮が行われます。
それに、簿記には、商業・工業・銀行等の簿記がありまた、連結決算・本支店会計等の問題も絡んできますし財務会計と管理会計があり要求によりそのシステム内容がかわってきます。

また、会社規模によってまたレンタルシステムといっても単なる請求管理なのか、原価管理及び償却を含むのかによって何を勉強したらよいか、貴方の担当する業務・工程で有った方が便利な知識は変わってきます。
・レンタル→扱い商品
・業務(販売・購買・予約・請求・原価・財務・給与・人事等)
・利用ユーザー(Web等の利用 BtoB BtoC は有りか?)
・開発手法(アジャイル・ウォータフォール等)
・プロジェクト体制
・開発OS
・開発期間
・開発総工数
・言語
・DB

 分かる範囲で良いですので教えてください。

いくらネット上であっても、納得の行く回答がしたいのです。

最初に業務知識は勉強しないと身につきません。
次に業種知識は業界独特の言葉表現の勉強と後の答えは現場にあります。
(新人のうちは最低でも1週間位かけて客先で朝一番から最終まで現場にいて何をしているか見ないと)
掃除や荷物運びも手伝わせます。見込みの有る新人にはこれをやらせます。答えは常に現場にあります。

さて
新卒で入社してレンタルシステムをプログラミングするのですが
業務知識がなく仕事ができません
と有りますが、
新卒でもう実践ですか?OJD(On the Job Development)でもやってい...続きを読む

Q30歳SE,技術がありません・・・

30歳になった8年目のSEです。独身女です。
技術がありません。
これからの仕事についてどうしたらいいかわからず、途方に暮れています。

私の会社は二次請けの仕事がほとんどです。
文系大学卒業後入社して以来、長期間のプロジェクトに関わる事が多くずっと客先にいたのですが、最近自社に戻りました。
主に現行仕様調査、詳細設計~結合テストの経験しかなく、ほとんどがバッチでプログラミングスキルは新人に毛がはえたレベルだと思います。(PL/SQL,COBOL,少しJava)
仕様を固める為にユーザ企業のシステム課の方と打ち合わせをしたような経験はありますが、リーダー経験もありません。
マスタ管理のようなチームがほとんどだった為、業界のどの企業でも通用するような業務知識もありません。
資格は情報処理試験(基本情報、ソフトウェア開発技術者)だけです
SEというと激務な方が多いですが、私はぬるい環境で仕事をしてきました(残業は多くても月70hくらい)


自社に戻り、上司は新たな職場に派遣しようとしていますが、
年をとり、おまけに主任になった為単価が高く、技術がない私はなかなか仕事が決まりません。
会社で他部署の手伝いなどをしています。

社外にいる間は一次請けベンダーのリーダーさんを目標としていたのですが、
自分の会社では無理な事をいまさら思い知りました。
昔から自分の技術がしょぼい事を感じつつ、現状に甘えてきた結果です。
努力しなければいけない事がたくさんありすぎて、まず何から始めたらいいかわからなくなってしまっています。
年齢が年齢なので、あせるばかりです。

自分ではこんな事を考えているのですが・・・

(1)プログラミング言語の勉強をし、たくさん資格でもとるか?
 今の会社ではこれを求められている気がしますが、実務経験がなく資格だけとって、役に立つのかは不明です。
 ベンダー系資格は受験料が高いので、それに見合う効果があるのかも・・・

(2)管理するポジションを目指す為、転職するか?
 今の技術力まま転職活動をしても望みが薄い気もしますが、勉強してから・・・というのでは年ばかりとってしまいそうで怖いです。
 反面、リクナビNEXTに登録しており、いくつかプライベートオファーも頂いたのですが、面接でアピールできる事が思いつかず、応募を躊躇してしまいます。

(3)他業界をめざすか?
 絶対SEがいいという希望はありませんが、この年齢で他業種で通用するのか?
 ぬるま湯育ちの私が通用するのか?

一番の目標は、ユーザ企業にしばられない業務知識を持ち、管理できる人間になることなのですが、夢のまた夢のまた夢のような気がして・・・

学生時代は定年まで仕事人間でいたいと思っていたのに、今の自分が情けないです。
これからの人生、食べていけるのかも不安になってきました。


あいまいな質問で申し訳ないのですが、私はまずどんな努力をすべきでしょうか・・・
お恥ずかしながら給料が安く、貯金も少ない為お金がかかる事は不可能です。

30歳になった8年目のSEです。独身女です。
技術がありません。
これからの仕事についてどうしたらいいかわからず、途方に暮れています。

私の会社は二次請けの仕事がほとんどです。
文系大学卒業後入社して以来、長期間のプロジェクトに関わる事が多くずっと客先にいたのですが、最近自社に戻りました。
主に現行仕様調査、詳細設計~結合テストの経験しかなく、ほとんどがバッチでプログラミングスキルは新人に毛がはえたレベルだと思います。(PL/SQL,COBOL,少しJava)
仕様を固める為にユーザ企業のシステ...続きを読む

Aベストアンサー

まあ、人生において正解の行動というのは無いわけですが、私だったら転職を志しますね。実際、携帯電話のSEから別業種に転職したことがあります。その後もう1回転職していますが、少しづつ他業種にチャレンジしていたら、今ではSEとは全く違う職種(アプリケーションエンジニア)で生きるようになってしまいました。

色々言いたい事はありますが、とりあえず3つだけ。

>反面、リクナビNEXTに登録しており、いくつかプライベートオファーも
>頂いたのですが、

できれば転職エージェントが対応してくれるサービスを利用した方が良いと思います。紹介される企業の質がそもそも違いますからね。亜リクルートNEXTだけでなく、ありとあらゆる転職サービスに応募するんです。時には門前払いを食う事も有るでしょうが、そんな事を恐れていたら前には進めません。

>面接でアピールできる事が思いつかず

アピール出来る事が無いなんて甘いですよ。それは死ぬ程考えて捻り出す者です。とりあえず、いままであなたがやってきた仕事/期間/使用ツール/開発人数を細かい所まで全部書き出してみましょう。職務経歴書を書いたかもしれませんが、それをもっと細かく書く様なイメージです。その中で、少しでも他者よりも誇れそうな者を抜き出し、10倍程度膨らましてアピール出来る様に文章を作ってみましょう。まずはそれからです。

>絶対SEがいいという希望はありませんが、この年齢で他業種で通用するのか?

通用するのか? じゃなくて通用する様に死ぬ程努力するんです。転職は、そのくらいの気合いが無いと絶対に成功しませんよ。

情けないと思う暇があったら、まずは出来る限りの行動をするべきです。それでも効果がなかったらそのとき初めて嘆きましょう。やるべきことをやっていたら、嘆く暇なんてないはずですよ。

まあ、人生において正解の行動というのは無いわけですが、私だったら転職を志しますね。実際、携帯電話のSEから別業種に転職したことがあります。その後もう1回転職していますが、少しづつ他業種にチャレンジしていたら、今ではSEとは全く違う職種(アプリケーションエンジニア)で生きるようになってしまいました。

色々言いたい事はありますが、とりあえず3つだけ。

>反面、リクナビNEXTに登録しており、いくつかプライベートオファーも
>頂いたのですが、

できれば転職エージェントが対応してくれるサービ...続きを読む

Q「以降」ってその日も含めますか

10以上だったら10も含める。10未満だったら10は含めない。では10以降は10を含めるのでしょうか?含めないのでしょうか?例えば10日以降にお越しくださいという文があるとします。これは10日も含めるのか、もしくは11日目からのどちらをさしているんでしょうか?自分は10日も含めると思い、今までずっとそのような意味で使ってきましたが実際はどうなんでしょうか?辞書を引いてものってないので疑問に思ってしまいました。

Aベストアンサー

「以」がつけば、以上でも以降でもその時も含みます。

しかし!間違えている人もいるので、きちんと確認したほうがいいです。これって小学校の時に習い以後の教育で多々使われているんすが、小学校以後の勉強をちゃんとしていない人がそのまま勘違いしている場合があります。あ、今の「以後」も当然小学校の時のことも含まれています。

私もにた様な経験があります。美容師さんに「木曜以降でしたらいつでも」といわれたので、じゃあ木曜に。といったら「だから、木曜以降って!聞いてました?木曜は駄目なんですよぉ(怒)。と言われたことがあります。しつこく言いますが、念のため、確認したほうがいいですよ。

「以上以下」と「以外」の説明について他の方が質問していたので、ご覧ください。
http://oshiete1.goo.ne.jp/kotaeru.php3?qid=643134

Q仕事についていけない(システムエンジニアです)

社会人5年目のシステムエンジニア(女性)です。
プログラミングやプログラム設計を中心に、仕事をしていますが
新入社員や後輩にどんどん抜かれている気がします。

集中力があまり無いことが災いしているのかもしれませんが
とにかくプログラミングがぜんぜんわかりません。もう、わけがわかりません。
プログラミングがわからないので、その設計も当然できません。
元々集中力が無く、楽器や勉強もそこそこで
何かひとつのことを成し遂げた経験がありません。
そういった中途半端で飽きっぽい性格のせいかもしれません。
読書も苦手なので、読解力もまったくありません。

これまで何とか5年も続けてこれたのは、周りの人たちが優しくて
毎回助けてもらってきたからに相違ありません。
でも、もう5年目なので、あまり堂々と質問したりできませんし
つまらないことを他の人に質問している姿を見た上司は
あきれた顔をしています。

でも、プログラミングの考え方がまったくわからないのです。
努力して自習するのも、もう疲れてしまいました。
来期から、同じ会社内の別の仕事(事務職など)に
配置換えをお願いしようと思っています。

このままエンジニアで居ても、なかなか成長しないし
何より、仕事についていけないという理由で
会社に行くのがとても辛いです。
辛いあまり、周りに泣き言を言いそうになってしまいます。
泣き言を言われる側も迷惑だと思います。
私なんかいない方がいいと思います。

私はもう少し粘ってシステムエンジニアを続けるべきでしょうか?
それとも、一度休職などしてリセットするべきでしょうか?
また、今考えているように配置換えをお願いするのがいいでしょうか。

今後に自分の身の振り方を考えています。
色々ご意見をください。よろしくお願いします。

社会人5年目のシステムエンジニア(女性)です。
プログラミングやプログラム設計を中心に、仕事をしていますが
新入社員や後輩にどんどん抜かれている気がします。

集中力があまり無いことが災いしているのかもしれませんが
とにかくプログラミングがぜんぜんわかりません。もう、わけがわかりません。
プログラミングがわからないので、その設計も当然できません。
元々集中力が無く、楽器や勉強もそこそこで
何かひとつのことを成し遂げた経験がありません。
そういった中途半端で飽きっぽい性格のせいかもし...続きを読む

Aベストアンサー

私は、まだまだくじけずに頑張って欲しい、と思います。

あなたの文章を読む限り、プログラムでつまずいているものの、
SEとしての適性は十分あり、頑張り次第ではこれから十分に活躍できると思えるからです。

以下その理由を述べていきます。

SEにとって必要な能力はいろいろあり、
プログラミングというのはそのうちの一つに過ぎません。
コミュニケーション力、柔軟性、設計力、イマジネーション、組織マネジメント力など色んな能力が必要ですが、
・このシステムは何のために必要なものか
・どうあればもっと良いものになるか
・良いものにするための工夫
・みんながもっとうまく仕事をすすめられるための工夫
というようなことを考えて、自発的に課題を発見し、対処していく、
そんなことを頑張ってくれる人であれば、プログラミングが少々苦手であっても、
素晴らしいSEといえるでしょう。

私は大手SIerでSEをやっていますが、周りにはプログラムが不得意だけど優れたSEもたくさんいますので、
得意なことをもっと頑張っていけば、組織に必要な人材に十分なれるのではないでしょうか?

また、プログラミング・設計能力はもちろん重要で、あると活躍の機会は増えますが、
それはいわゆる「システムに強いSE」のタイプです。
もうひとつは「業務に強いSE」のタイプで、システムと業務の得意な割合が9:1であればプログラマー寄りですし、1:9であればコンサルタント寄りといえます。5:5はバランスの良いSEですね。
いずれも組織に必要なタイプですので、得意なことを頑張って強みを発揮できるようになれば、苦手も気にならなくなるかもです。

あとは、プロジェクトマネージャーを目指すという考えもあります。
組織をまとめて人を動かす、ということに特化したタイプですが、大きめなプロジェクトとなれば、こういった能力を持った人が重要となります。プログラマータイプには、マネジメントが苦手なタイプが多いです。(コンピュータとは何時間向かい合っていてもいいけど、人間は苦手、な~んてね)

いろいろと可能性はありますので、もっと視野を広げて勉強して、
自分の得意なこと、興味のあることを頑張ってみると良いのではないでしょうか。
もちろん、プログラミングも、もう一回初歩の初歩まで戻って勉強しなおして、
ある程度苦手は払拭しておきたいところだな~、とは思いますが。

私は、まだまだくじけずに頑張って欲しい、と思います。

あなたの文章を読む限り、プログラムでつまずいているものの、
SEとしての適性は十分あり、頑張り次第ではこれから十分に活躍できると思えるからです。

以下その理由を述べていきます。

SEにとって必要な能力はいろいろあり、
プログラミングというのはそのうちの一つに過ぎません。
コミュニケーション力、柔軟性、設計力、イマジネーション、組織マネジメント力など色んな能力が必要ですが、
・このシステムは何のために必要なものか
・どうあればもっ...続きを読む

Qメーカー系、ユーザー系、独立系のメリットデメリット

誰かメーカー系、ユーザー系、独立系の会社のメリットデメリットを教えてくれませんか?
わかるかたいらっしゃったらお願いします。

Aベストアンサー

こんにちは
某所からのテンプレートですが、、、
-------------
■メーカー系
ハードウェアメーカーのソフトウェア開発部門が子会社として独立した企業やその傘下にある企業。
親会社のハードウェア販売支援業務に近い。 
 Ex. NECソフト、富士通ビジネスシステム、日立情報システムズ
 長所:遠隔医療のようなハードウェアに依存するようなシステムに強い。
    メーカーの営業を経由して、仕事が入ってくる。
 短所:原則として、親会社のメーカー製のハードウェアを使う。
■ユーザー系
システムのユーザー企業のソフトウェア開発部門が子会社として独立した企業。
親会社が勝ち組であればあるほど、ノウハウ・実績が高く、システムの得意分野がはっきり定まっている場合が多い。
基本は親会社グループのシステム支援業務。 
 Ex. 住商情報システム株式会社、新日鉄ソリューションズ株式会社、伊勢丹データーセンター
 長所:親会社やそのグループ企業での、ノウハウ・実績を利用できる。
 短所:遠隔医療のようなハードウェアに依存するようなシステムに弱い。
    グループ外企業に対しては独自の営業力が必要。
■独立系
親会社を持たず、独自に設立し経営している企業。ソフトウェア業界の過半数を占める。
独自の技術力を蓄積している場合がある。 
 Ex. CSK、インテック富士ソフトABC
 長所:親会社に縛られないことから、どこのメーカーのハードでも調達できる。
 短所:経営基盤が弱い。親頼みの受注は一切ないため、独自の営業力が必要。
■コンサル系
経営コンサルティングを行い、その方法論としてIT化を支援する企業。 
 Ex. 野村総合研究所、日本総合研究所、アクセンチュア
 長所:経営コンサルからシステム開発・メンテナンスに至るまでの一社での完全なソリューション提供の実現。
    パイオニア的な方法論の実現が可能。
 短所:システム開発面での実績の弱さ(予算・納期・品質)。
    業務のIT化に実験的な部分が含まれる可能性があり、全体的にコストが高い。

こんにちは
某所からのテンプレートですが、、、
-------------
■メーカー系
ハードウェアメーカーのソフトウェア開発部門が子会社として独立した企業やその傘下にある企業。
親会社のハードウェア販売支援業務に近い。 
 Ex. NECソフト、富士通ビジネスシステム、日立情報システムズ
 長所:遠隔医療のようなハードウェアに依存するようなシステムに強い。
    メーカーの営業を経由して、仕事が入ってくる。
 短所:原則として、親会社のメーカー製のハードウェアを使う。
■ユーザー系...続きを読む

Qミドルウエアの具体例を教えてください。

初級シスアドで、OSとアプリケーションソフトの中間に位置するものとしてミドルウエアがあり
 ・データベース管理システム(DBMS)
 ・通信管理システム(LAN制御を含む)
 ・ソフトウエア開発支援ツール
 ・EUCツール
 ・運用管理ツール
説明されています。なんとなく具体例が推測できるものもありますし、ぜんぜんイメージできないものもあります。
そこで、推測が間違っていないか確認したいのと、イメージできないものの場合具体例をあげていただければ助かります。

(1) データベース管理システム(DBMS)
多分、OracleやSQL-SeaverやMySQLのようなものだと思うのですが。
この推測はあってますか?

(2) 通信管理システム(LAN制御を含む)
プラットホームや使用アプリが違う場合のデータのやり取りを行うようなもの・・・というイメージがあります。使用アプリの場合はODBCドライバみたいなものの様な(全然自信ない)、プラットホームとなると実例が浮かんできません。

(3) ソフトウエア開発支援ツール
なんでしょう?プログラミングジェネレータのことでしょうか。
EXCELマクロの自動記録機能なんてのもこれに入るのでしょうか。ひょっとするとEXCELマクロは、次のEUCツールでしょうか?

(4) EUCツール
AccessとかEXCELとかでしょうか。イメージ沸きません。

(5) 運用管理ツール
う~ん・・・なんでしょう?

補足:IMEとかもミドルウエアと考えてよいのだろうか? WEBで調べるとワープロや表計算もミドルウエアと定義しているものもあります。それは少し拡張解釈なような気がします。

いずれにせよ、すっきりした定義と具体例を書いてあるものを見つけられないのです。

宜しくお願いします。

初級シスアドで、OSとアプリケーションソフトの中間に位置するものとしてミドルウエアがあり
 ・データベース管理システム(DBMS)
 ・通信管理システム(LAN制御を含む)
 ・ソフトウエア開発支援ツール
 ・EUCツール
 ・運用管理ツール
説明されています。なんとなく具体例が推測できるものもありますし、ぜんぜんイメージできないものもあります。
そこで、推測が間違っていないか確認したいのと、イメージできないものの場合具体例をあげていただければ助かります。

(1) データベース管理システ...続きを読む

Aベストアンサー

(1) データベース管理システム(DBMS):お書きになられた通りです。
(2) 通信管理システム(LAN制御を含む:TCP/IPドライバー等通信制御を行うアプリケーションです。ファームウェアも該当するでしょう。通常ユーザが操作する類のアプリケーションではありません。
(3) ソフトウエア開発支援ツール:VisualBASIC、C言語、Perl等、亜ぷロケーションを開発するツール、プログラミング言語と言えば分かり易いでしょうか。
(4)EUCツール:エンドユーザが使用するアプリケーションです。
(5)運用管理ツール:クライアントPCの管理ツール、DBシステムの管理ツール、WEB/メールのサーバ管理等、運用機器を管理するツールです。最近では情報漏えいを防止する目的のツールが多数出ています。

Qベンダー、SIer、システム開発会社、ソフトハウスの違いを教えて!

ベンダー、システムインテグレータ(SIer)、システム開発会社、ソフトハウスの違いがよく分かりません。教えてください!

たとえばマイクロソフトはどれに当たるのかなど、
有名企業を例に挙げていただくとイメージしやすいかと思います。

Aベストアンサー

# 有名大手は規模が大きすぎて部門/グループ会社ごとに別の側面を持ってます。
# 質問者さんがその会社のどの情報を持っているか(いないか)で
# 例に挙げた企業のイメージがまったく異なりますので、
# かえって誤解させる可能性が高いと思います。
#
# 一般には単にIT企業として有名だが、SIer部門も業界では有名で、
# ソフトウェアベンダ部門も一部に有名で、ハード部門からサービス部門からいろいろ持ってて、
# ソフトハウスなグループ会社もあり、違う会社もあり…。


(ソフトウェア)ベンダー≒ソフトハウス
システムインテグレータ(SIer)≒システム開発会社

ソフトハウスってのは一般にソフトウェア開発専門/メイン(自社製品/受託)の会社。

「○○ベンダ」は○○の提供元のことで、多くのソフトウェアベンダは
自社開発したソフトウェア製品を販売してる(この場合、見方を変えればソフトハウスの一種ともいえる)
まぁ他社製品の販売だけの販売代理店もベンダの一種ですが。

システム開発会社はシステムインテグレータ(SIer)と同義かと。
「お客様のシステム」を設計して開発して支援するのがお仕事。
ソフトウェアは本来そのための部品であって、通常は
ハードウェアやサポート等を含めたソリューションを提供する。

# 有名大手は規模が大きすぎて部門/グループ会社ごとに別の側面を持ってます。
# 質問者さんがその会社のどの情報を持っているか(いないか)で
# 例に挙げた企業のイメージがまったく異なりますので、
# かえって誤解させる可能性が高いと思います。
#
# 一般には単にIT企業として有名だが、SIer部門も業界では有名で、
# ソフトウェアベンダ部門も一部に有名で、ハード部門からサービス部門からいろいろ持ってて、
# ソフトハウスなグループ会社もあり、違う会社もあり…。


(ソフトウェア)ベンダー≒ソ...続きを読む

Qシステム運用。この考え方は駄目?転職すべき?

客先常駐メインのIT企業に勤めています
11年度卒の専門学生(20歳)で8月から早期出社をしています。

開発職希望で入社したら運用系で採用されました。
職種はシステム運用のオペレーター
勤務時間は2交代勤務で1日12時間勤務。夜勤明けの休日を入れると月の半分は休みです。
仕事内容は障害が発生したらアラート音が鳴るので鳴れば手順書を見て作業をするか、運用SEに連絡。
定期的にバックアップを取ったり、機器の点検をしたり・・。
linuxでpingで応答確認程度。

上司も同じ仕事内容です。
リーダーだけシフト作成+SEへ渡す報告書等の作成をしています。
上司も仰ってるのですが正直な所、スキルは一切つかない仕事内容です。
運用SEは1次受け企業のため2次受けである今の会社にいるとステップアップは不可。
上司の話を聞いてると30歳になると異動で運用とは全く関係ない仕事をさせられるそうです。
それでも40になるまでにほとんどの人がクビになるか自分で退社するようです。
開発職に異動のチャンスは?と思ったのですが過去のケースからしてなさそうです。
やはりスキルが身につかない、交替制ということで出入りが多い職場です。
年功序列のためリーダーになる頃には28、29歳。
リーダーになっても30過ぎれば上記に記載されてる通り関係職種に異動。

個人的に運用SEとステップアップできるのであれば働き続けたいのですが、スキルが身につかないオペレーターで30を迎え、関係ない職へ飛ばされ解雇と思うと憂鬱になります。

最近考えてるのは3年間働いたら転職しようかなと思ってます。
運用SEは大変な仕事だとオペレータの仕事をしてわかってるのですが、SEの仕事がやってみたい気持ちがあります。

転職資格は無意味と聞いたのですが・・
とりあえず、月半分休みで時間があるため3年間で基本情報取得してから応用情報取得。
ping、TELNETコマンドしか使わないのですがlinuxに触ってるのでLPICのレベル1辺りを勉強して取得しようかなと思ってます。

人生の先輩である皆さんに聞きたいのですが

1:皆さんが私の立場だったら転職しますか?
2:3年で転職という考え方は辞めるべきですか?転職した方がいいですか?
3:その他アドバイス的なことがありましたら宜しくお願いします

客先常駐メインのIT企業に勤めています
11年度卒の専門学生(20歳)で8月から早期出社をしています。

開発職希望で入社したら運用系で採用されました。
職種はシステム運用のオペレーター
勤務時間は2交代勤務で1日12時間勤務。夜勤明けの休日を入れると月の半分は休みです。
仕事内容は障害が発生したらアラート音が鳴るので鳴れば手順書を見て作業をするか、運用SEに連絡。
定期的にバックアップを取ったり、機器の点検をしたり・・。
linuxでpingで応答確認程度。

上司も同じ仕事内容です。
リ...続きを読む

Aベストアンサー

こんにちは

2007年からIT業界でSEをしている者です。

1:転職します。
2:3年と言わず1年ぐらいで(もっと早くても)転職してもOKだと思います。
3:以下記載。

□はじめに
あなたの経済状況がわからないので、ご自身の経済状況を考慮のうえ検討していただきたいのですが、
一般論としてそういう会社で、SEとしてやっていくのは難しいと思いますし
やりがいも無いかと思います。

まず、考えるべきなのは、将来(5年後、10年後ぐらい)に何をやっていたいか、を考えることです。
記述を見ていますと、開発系か、運用系かで悩んでいらっしゃるようなので
どちらかに決めましょう。

□転職先があると思う理由
その上で、ある程度やりたい仕事が未経験でも、受け入れてくれる会社はIT業界にはあると思います。
なぜかというと、
・年齢が若い
・情報系の専門学校を卒業していること
の2点があるからです。

IT業界の現状として、情報系の教育を受けていない人間を採用して
(教育せずに)仕事をさせている現場が多いのが現状です。

その現状から、きちんと教育を受けていて、かつ、自学自習の意思のある人間は
採用される可能性が高いです。

また、賃金の関係から、年齢が若いというだけで、採用の幅は広がります。

□資格について
資格は、未経験かつ年齢が若いあなたのケースですと、少しは意味があるかと思います。
また、資格を取得するための勉強をすることによって、
自分がその分野に向いているか、いないか、を自分で判断する材料にもなるかと思います。


□転職先について
これだけでも、かなり長くなってしまうので簡単に。
身近な先輩等に相談して、ちゃんと給料がでて、経験を積むことができる会社を選んでください。

こんにちは

2007年からIT業界でSEをしている者です。

1:転職します。
2:3年と言わず1年ぐらいで(もっと早くても)転職してもOKだと思います。
3:以下記載。

□はじめに
あなたの経済状況がわからないので、ご自身の経済状況を考慮のうえ検討していただきたいのですが、
一般論としてそういう会社で、SEとしてやっていくのは難しいと思いますし
やりがいも無いかと思います。

まず、考えるべきなのは、将来(5年後、10年後ぐらい)に何をやっていたいか、を考えることです。
記述を見ていますと、開発系か、...続きを読む

Q基本情報技術者が受からない

社会人二年目のものです。
大学では、情報科学を勉強していました。
ですが、基本情報技術者の午後問題の選択問題と言語が全く解けません。
毎回、選択問題は割りと取れると噂のストラテジー・マネジメント系の問題ですが、
読んでみても結局間違っていることが多く、自信がもてません。
だからといって他の問題もピンキリです。
言語もC言語を大学時代にやっていたくせに、読み込むのに時間がかかり過ぎて、
いつも適当にマークしてしまいます。
※必須問題は安定して取れていますし、午前は八割とれます。
大学で真面目にやってきたはずなのに、どうしてこんな悲惨な状況になるのでしょうか?
親に学費を払ってもらっただけに、恥ずかしすぎてしんどいです。
これで、二回目なんですが以前ほど悔しいと思う気持ちが薄れており、
最初落ちたときは、辞表をだすまでいったのに
いまは諦める気持ちが大きいせいか、あっけらかんとしています。
あっけらかんとしていることに、腹がたっている自分もいます。
心の中がめちゃくちゃです

Aベストアンサー

 あなたは真面目すぎます。
 情報処理の資格試験は合格しなくても仕事ができます。合格しないとできない医師などとは違います。

 ちなみに私が働いていたソフト会社は千人規模でしたが有資格者は1割もいませんでした。何回受けても合格しない人はザラで、資格を取るための勉強をする暇があるなら少しでも仕事をしろという会社でしたから当然です。
 さすがにこの状況がまずいと思ったのか現状を打破するために社内教育をいろいろする事になりましたが、私はリストラされましたので成果は不明です。
 私が働いていたのはダメ会社ですから参考にならないかもしれませんが、取得率が高い会社ばかりではないと思います。
 精神的に自分を追い詰める必要は無いでしょう。

 私は第二種情報処理技術者を2回目で合格しましたが、1回目の失敗を冷静に分析し対策を万全にしました。大切なのは同じ失敗を繰り返さない事です。自信を持って解答できない現状では難しいと思います。なぜこうなるのかを理解しましょう。

Qシステムエンジニアとして知っておくべき業務知識

システムエンジニアとして仕事しています。

自分は、下請け常駐して仕事をするなど、いくつもの現場で経験を積んできました。

しかし、主に開発フェーズ寄りになってしまうため、いまいち業務に関して知識が養えていません。

珍しく、直請けで入った現場でも、やはり業務知識を身につけないといけないなと思う日々です。

見本となる先輩はいるのですが、経験してきた道はやはり違いがあるのでどうしても経験論が多いのが実状です。先輩も何か具体的な方法を教えてあげたいと思ってくれているようですが(^^;)

何か良い業務知識の本などありますか?

よろしくお願いします。

Aベストアンサー

SEというのはその意味するところの範囲が広すぎて一般的には理解されていません。業務設計をするのはSEなのか、要件定義からなのか、あるいは開発に入ってからか?
通常業務設計をするのはビジネス側の人間。でもその人間でもある程度システムに詳しくないとできません。これはコンサルの仕事になります。
要件定義の基本はヒアリング、つまり業務に係る人から話を聞いてシステムに仕上げる仕事。通常の日本のSEはここからですね。ただここも業務側に人間がする事もあります。
つまりここからやる場合でも業務に精通している必要があるわけでそれは業種によってさまざまです。
上流になればなるほどシステムから離れていくというのは今までの手法。でも最近はクラウドの登場で、どこまでを社内で処理し、どこからを外で処理させるかなど、システムを業務に取り込むことが勝つ為の条件になっています。
業務を知るには直接その業界の知識を身に着けるしかありません。それは金融であったり製造業であったりその道のトレンドを把握します。
つまりこれが出来る人はコンサルとして独立出来るわけでコンサル系の勉強の仕方をするしかありません。
でも日本ではこの分野は非常に遅れてます。こういうのが得意なのは欧米です。つまり訴訟が多い国ではプロセスの作成が第一だから。
一番いい例がSAPの導入コンサル。導入コンサルだけで食って行けるのです。システムは一から作らない。既に確実に動くものを間違いなく導入し余計な感情を入れない。
試しにSAPの導入コンサルのやり方を勉強してみたらどうでしょう。
http://www.sap.com/japan/index.epx

SEというのはその意味するところの範囲が広すぎて一般的には理解されていません。業務設計をするのはSEなのか、要件定義からなのか、あるいは開発に入ってからか?
通常業務設計をするのはビジネス側の人間。でもその人間でもある程度システムに詳しくないとできません。これはコンサルの仕事になります。
要件定義の基本はヒアリング、つまり業務に係る人から話を聞いてシステムに仕上げる仕事。通常の日本のSEはここからですね。ただここも業務側に人間がする事もあります。
つまりここからやる場合でも業...続きを読む


人気Q&Aランキング