方式（技術）よりのSEの仕事内容について

質問

私はプログラマになりたてのものなのですが方式（技術）系のSEの仕事内容に
ついて質問があります。
方式系のSEはお客さんのところへ行ってどんなシステムが作りたい等の要望を
ヒアリングする機会は少ないのでしょうか。
設計書等は業務系のSEがお客さんからヒアリングしてきたものを元に設計を進めていくのでしょうか。
業務系SE、方式系SEはどのような役割分担でシステムを構築していくのでしょうか。
また方式系SEは簿記等の業務知識は必要ないのでしょうか

回答No.2

sinjou

先日まで勤務してが現場は・・・部下達が致命的バグを発見すると、
リーダーが「もう、触らないで！バグを出さないで！」
と、アホの子みたいな指示を、出しておりました・・・

向上心のない社風の場合、記述漏れのまま、客先に上げちゃうみたいです。流石に、客が騒いだら、追加するんでしょうけんど。
ヒアリング可能な現場は、大手SEだと思います。
中小SEは一生、お客にヒアリングする機会のないまま、失職するんじゃないかなあ・・・そういう人も、珍しくないと思います。
３０代中盤になっても、セールストークが出来ない場合、そんな人、どっこの会社も要らないもん・・・
日商２級＋ヒアリング力がないと、会社が買収された際に、新しい組織で使ってもらえんと思います。あと、愛情ある設計記述がないと、成果物はボロボロです。出来れば、ユーザーに近いブレインを作って、実務を頭に叩き込んでおいたほうが無難です。
とにかく、人望第一のお仕事に思いますので。参考まで。

回答No.1

STICKY2006

こんちは。

ＰＧ３年目です。

分かる限りの部分で回答を。。。

>>お客さんのところへ行ってどんなシステムが作りたい等の要望をヒアリングする機会は少ないのでしょうか。
その会社の開発手法次第で違うかと。。。

そもそも、どういう仕事をしているのかで変わってくる部分でしょうねぇ。

昔から（？）あるような、「在庫管理のシステムが欲しいな～。オーダーメイドで○○社に作ってもらうか。」というものだったら、ヒアリングなしじゃ作れもしませんよね。
他にも、部分的に請け負ったり、最初から設計やらなにやら既に済んでいて、後は開発だけ～の物を投げられたり。。。

それは、自分の会社がどういう開発しているのか次第で変わるかと思います。

うちの会社の場合は。。。
６：４～７：３ぐらいで、客と直接、システム開発に取り組んでいくようなのは。。。少ないと思ってます。
そういう、客向け～の開発している部隊と、そういう風ではないお仕事している部隊があるので。

>>設計書等は業務系のSE
というか、自分は、「業務」も「技術」もカバーしていて、ＳＥ。だと思っていますが。。。

業務の流れだけ理解していればできる～なら、「その客先の会社の人」の方がよっぽど、自分の会社の業務の流れなんか理解しているんですし、その会社の、ちょっと企画力が優れている人～に
設計させた方が、よっぽどよいものができると思います。

業務も知っていて、その業務をサポートするシステムをどういう技術で実現するかを提案できる力があるのがＳＥかなと思ってます。

>>方式系SEは簿記等の業務知識は必要ないのでしょうか
ＳＥに対しての、自分の考えは、上までに述べさせてもらったので、それを踏まえて。。。。
知っていた方がよいものです。

業務～の理解をある程度できていない方式系のＳＥさんって。。。
正直、年数の経ったＰＧ。と変わらなくないですかね。。。？と個人的には思うのですが。。。

お礼

ご回答ありがとうございました。STICKY2006さんのおかけでSE象というのがなんとなく伝わりました。私もやはり業務の知識、方式の知識、両方を身につけてSEかなと思います。たくさん知識を吸収して早くSEになれたらと思っています。ありがとうございました。