「SEが業界に精通している」必要があるか？

投稿者

投稿内容

未記入: 大ベテラン; 会議室デビュー日: 2003/11/24; 投稿数: 121

投稿日時: 2004-09-08 22:49

引用:
業務知識がないとその人はSEやってはいけない

私の主張は「業務知識がないとSEをやってはいけない」ではありません。念のため。
私が言いたいのは「プログラマに要求を出す人間は業務を理解していないといけない」です。
業務を理解していない(かつ実装技術も持たない) SE が伝言ゲームでプログラマに指示を
出すことが問題であると私は考えています。この問題を回避するための方法は 3つあります。

(1) SE がプログラマに適切な要求・指示が出せるほどの
　業務知識を持っている。持っていなくてはならない。

(2) 業務を知らないのなら SE(実装技術を持たない人間) は存在しないほうが良い。
　業務を知っている顧客が、直接プログラマに要求を提示したほうがうまくいく。

(3) SE が実装技術を持ち、自らプログラマとして振舞えれば良い。

(2) と (3) は結果として SE = プログラマとなりますね。うちの会社がこのタイプです。
ほとんどの案件が 2,000万以下の小規模プロジェクトだからできるのかもしれませんが、
理想的なプロジェクト形態のひとつではないかと思います。

SE はプログラマではない(実装技術は不要である)とすると、方法は (1) しか
残りませんから「SE は業務を知っていなければならない」ということになります。

プログラマに「ここどうしたらいいですか？」と質問されて、「ユーザーに聞かないと
分からないから次回の打ち合わせで聞いておくよ」と答えている SE さんはいませんか？
以前いた会社には、このような SE がたくさんいました。

このようなことをしている SE には存在価値がありません。ただの連絡係です。

kaz: ぬし; 会議室デビュー日: 2003/11/06; 投稿数: 5403

投稿日時: 2004-09-09 00:17

こんばんわ．

自分がここの議論に参加するのは僭越ですが，
なんとなく気になったので書き込ませていただきます．

そもそも，SE は「役割」でしょうか？
それとも「職業」でしょうか？
自分は前者でしかないと認識しています．
つまり，場合によっては「専任の SE は必要ない Project」だったり，
広範囲にわたるためにまとめ役が必要で，それを「SE と定義づけ」したりするのかと．

自分は programmer や SE など遙に及ばない低級技術者ですが，
なので本気で programmer なる人々を尊敬してます
遍く「業務知識を持つ」のは不可能事ではないかと思いますし，
「知ってたほうが better」であるとも思っています．
ですが，そもそも programmer ほど SE が
「こういう人」という定義があるようには思えません．
なので，ある環境では「これが SE」と言う場合もあれば，
「そんなの SE とは言えない」な話も全然あるのではないかと．

自分個人の観念で言うなら，大昔の武士のようなものかと．
江戸時代とその前の戦国時代とでは，
「武士」という人々の観念は大きく違っていたようです．
武士だけでなく，全ての職業でそうだったかもしれません．
要するに，時代に求められていて醸造されたのではないかと推察いたします．

その意味で，現時点での SE は，多くの人に不満を抱かせることと思われますが，
「その程度でも居て欲しい」くらいの SE が多いのかと．
高級技術者から見たら「要らない」と思える人々すら
必要とされるほど業界が忙しいのか，
自分はそうは思いませんが．．．
そのような人たちが「SE です」と自称しているに過ぎないのではないかと思われます．
ですから，「業務知識が必要」というのが「絶対条件」となれば，
そのような「武装」を持つ人々が生き残り，そうでない人たちが淘汰されるのかな？
と，常々考えています．

ですから客観的に「必要か？」と問われれば「必要」ですが，
主体的に「自分はそうあろう」としている人は極めて少ないと思います．

このスレッドに書き込まれている方々には遠く及ばないことを自覚しつつ，
自分はこのように愚考します．

ラフィン: ぬし; 会議室デビュー日: 2002/05/23; 投稿数: 809; お住まい・勤務地: 外野

投稿日時: 2004-09-09 01:57

引用:
kazさんの書き込み (2004-09-09 00:17) より: そもそも，SE は「役割」でしょうか？それとも「職業」でしょうか？

　現実にはどちらの意味でも使われますね。

　SE、PE（プログラマ）の定義の一例ですが、

［PE］
・プログラムを作る人。
・責任範囲は自分の作成したプログラム。
・ただし、プロジェクトの一員としてプロジェクトが円滑に進むために協力する義務はある。
・例外として設計は他のメンバーが行うがプログラムを作るPLは全体の責任を負う。

［SE］
・データベース設計等も含めシステムを作る人。
　（ただし、システムを作ると言ってもSE複数のケースも当然ある）
・責任範囲にプログラミングも含む。
・作業としてのプログラミングを他のメンバーに委任することもある。
　（その場合、PEの高度な実装技術を設計に利用してよい）
・PEにスキルがあるならプログラムの設計から委任するのもあり。

　PEはプログラムエンジニア、SEはシステムエンジニアです。

Kensaku: 常連さん; 会議室デビュー日: 2003/02/16; 投稿数: 22

投稿日時: 2004-09-09 02:08

SEに○○は必要か？または、SEに○○は必要！という議論や記事はいろいろなところで見かけますが、何事もあればあったに越したことはないので必要になってしまうと思います。

SEが業務知識も持って交渉能力も持ってコスト管理能力も持って高度な実装能力も持って・・・、それで安月給で長時間労働も文句も言わずやってくれる人だけを経営者は雇いたいでしょうから。。。

夢物語ですね。

供給が満たされる範囲で考えるとSEが業務知識も持つことには無理があると私は思います。

kaz: ぬし; 会議室デビュー日: 2003/11/06; 投稿数: 5403

投稿日時: 2004-09-09 07:34

おはようございます．

昨日書き忘れたのですが，goo の国語辞典で検索させると

システムエンジニア【systems engineer】
コンピューター-システムの分析と設計に携わる人。情報処理技術者。SE。

なのだそうで，「作る人」に対する「作るための準備をする人」なのですかね？
さらには "systems" なんですよね，昔から気になってましたけど．．．

未記入: 大ベテラン; 会議室デビュー日: 2003/11/24; 投稿数: 121

投稿日時: 2004-09-09 09:46

「SE」の定義が揺らいでいますね。SE とは役割にすぎないという意見には
おおいに同意できますが、このスレッドでは「職業としての SE」について
議論しているのだと思っています。違うのでしょうか？

・SE はプログラマとは明確に区別される
・SE は実装技術(プログラミング能力)を持っている必要はない

前スレの流れで SE がこのように定義されています。なので、私が何度か述べた
SE = プログラマという人間は、ここで議論される SE には含まれないと思います。
ここで議論される SE はあくまでも「職業としての SE」でしょう。

私は「職業としての SE」の一例として次のような人物像を思い描いています。
若い頃はCOBOLプログラマとして腕を振るった。しかし今は言語も大きく変化し
新しい言語など習得できない。もう歳も 40 をずいぶん過ぎた。
プログラマとしての手腕はもうないから「じゃあ、俺は SE ということで。」

といった感じで、プログラマから「プログラミング能力をマイナスして」経験相応の
「十分な業務知識をプラスした」のが現実的に大多数を占める職業 SE だと思います。

職業 SE = プログラマ - プログラミング能力 + 業務知識

上記のように考えていたわけですが、「業務知識」は持っていなくても良い、
という意見が非常に多いので戸惑っているわけです。「+ 業務知識」の部分を
とったら、SE なんて完全にプログラマに劣る存在になってしまうと思うのです。

引用:
SE、PE（プログラマ）の定義の一例ですが、［SE］・データベース設計等も含めシステムを作る人。

プログラマではない SE が設計したデータベースはひどいものが多いです。
私はデータベースはプログラマが設計すべきものと考えています。

上記であげたCOBOLプログラマあがりの職業 SE はデータベースの設計が
できない人が多いです。型を知らず、numeric と char だけで設計するとか。
日付型を覚えたと思ったら「スラッシュ区切りで格納」とか「和暦で格納」とか
トンチンカンなことを平気で言っていたり、ロックに関する知識がなかったり、
自動連番を使えばいいのに常に自前の採番テーブルを定義したり、機械的な
第三正規系への正規化しかできなかったり、プログラマの冗長化手法(正規化崩し)を
闇雲に批判したり…。プログラムを組めない、つまり、プログラムからクエリを
発行しない人間に、まともなデータベース設計ができるとは思えません。

引用:
・PEにスキルがあるならプログラムの設計から委任するのもあり。

最近、増えてますね。「設計」さえもプログラマに押し付けてしまう SE 。
いったい SE とはなんなのか、ますます悩んでしまいます。

引用:
SEが業務知識も持つことには無理があると私は思います。

なぜ無理があるのでしょう？プログラマは言語スキルや設計を磨いているし、
業務系プログラマであれば、さらに基本業務知識を学んでいます。

SE は何を学んでいるのですか？

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-09-09 10:06

うんんん．．．業界知識（業種知識）と業務知識がごっちゃになっていると思うのですが

・業務知識
　
　１．受注管理、売上管理、請求管理、入金管理、在庫管理、発注管理、仕入管理、支払管理
　２．生産管理
　３．財務管理、給与管理
　
　等などの概念で、主に

　１番は小売業、流通業での概念が一般的とされ、
　２番は工業製品での概念が一般的とされ、
　３番は法律の概念が一般的とされる。

・業界知識（私の用いる「業種知識」と同意義）
　
　市販の販売管理パッケージでは、『受注管理→売上管理→請求管理→入金管理』の流れとなるが、
　小売業（通販対象外）では店頭での現金販売が基本である為、
　『売上管理＋入金管理』の構成で受注管理、請求管理が無い。
　
　海外と取引をしている場合、金額欄は日本円以外の現地金額も必要。
　またはレート管理、通貨単位設定など考慮が必要。
　
　ＩＴ業界では販売管理は契約管理システムになる。

　とか、とか、そう言う事でしょ？

#因みに上記は例題なので、小売業に受注管理、請求管理が本当に不要と思わないで下さい。

で！当スレッドでは、業界知識（業種知識）について
問うているのでは無いでしょうか？

# 追記
あ！ＳＥ論は面白いので続けて下さい。（スレ主じゃないけど）

[ メッセージ編集済み編集者: はにまる編集日時 2004-09-09 10:21 ]

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2004-09-09 10:24

引用:
SE は何を学んでいるのですか？

コンピュータシステムはプログラムだけで動いているわけではないと思います。
ネットワーク、データベース　それらの運用知識、トラブル対応いろいろあります。

あとデータベース設計に関しては、ＳＥ、ＰＧに関係なくデータモデリング能力の有り，なし
の問題です。ＰＧ側でもデータベース設計はできると思いますが、必要とされるエンティティ
やドメインを理解してないとできないですよね！

[ メッセージ編集済み編集者: 七味唐辛子編集日時 2004-09-09 10:36 ]

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

「SEが業界に精通している」必要があるか？

スキルアップ／キャリアアップ（JOB@IT）