＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-09 10:28
それは単に時代の移り変わりに対応できていないＳＥなんでしょう。 多分、数年か数十年後になれば同じように、「・・・・JAVA上がりのやつは．．．」 なんて言われているかもしれません。 業務知識、実装知識（技術）が必要なのはＳＥであれプログラマーであれ同じですよ。 程度とバランスの問題だけで。 ＳＥ（職業、役割問わず）と言われる人は、実装よりも業務のほうにウエイトを置いて プロジェクト内でも普段でも考え、プログラマーは実装の方にウエイトを置くだけです。 他方の知識が全く無いというのは、ＳＥであれプログラマーであれ現場では役に立ちま せん。 かといって、現実のプロジェクトではＳＥ＝プログラマーかというとこれは規模が大き くなると鮮明に役割として区別されてきます。（そうしないと回らない。） そこに能力の劣るＳＥが居たからといって、ＳＥ不要論にはなりません。個人差です。 もし、「プログラマーがやればよい」からＳＥ不要論になるなら、「実装技術を持った ＳＥが設計書なんて作る暇が合ったら自分でコーディングすりゃいいじゃん」という プログラマー不要論にもなってしまいます。こういう議論は不毛だと思いますよ。 で、私は「業務知識」として話をしていましたが、 ここで論議されているのは、「業務知識」で良いのですか？「業界知識」ですか？ | ||||||||
|
投稿日時: 2004-09-09 10:29
私の場合、「業務知識＝業界知識を含む業務遂行に必要な知識」という意味で 業務知識とい言葉を使用しました。 はにまるさんの業務知識（業種知識）・業務知識の定義が私より厳密な定義であるのは 感じていましたが、私の意見としてはどちらでも変わらないので業務知識と書きました。 あと、話がＳＥ論に流れていくのは当然の流れに思いますが、スレッドは 新しくしちゃえば って思います。 | ||||||||
|
投稿日時: 2004-09-09 11:02
業種知識 = 業種特有の高度な業務知識(精通) ※これを現在の流れでは、精通とか長々と書くのが面倒だから「業務知識」と省略していて、 かわりに、プログラマにも必要とされるような知識を「一般的な業務知識」「基本業務知識」 と表現しているんじゃないかな？ 業種によっては、基本業務に大きな変化を与えることがあります。 SE はプログラマの持つ基本業務知識以上のものが求められると私が考えている例。 一般的な販売管理であれば、納品した段階で(当月)売上になりますが、出版業の 販売管理システムの場合、納品では売上が立ちません。これは雑誌など 3ヵ月間の 返本が可能で 3ヵ月間返本推移を追います。そして、納品数 - 返本数 ではじめて売上が 立ちます。(実際には掛売りだから請求はさらに翌月か翌々月です。)さらに楽器店などへの 納品は(返本できない)売り切りが可能で、当月売上・翌月請求になるなどの例外もあり。 このような業種特有の業務(基本業務との差異)を知っていないと、 実装技術を持たない SE は生き残れないんじゃないかと思います。 | ||||||||
|
投稿日時: 2004-09-09 11:21
最初の >一般的な販売管理であれば、納品した段階で(当月)売上になります っていうのがＳＥのデフォルト業務知識として必要な部分であって、例外があるって 事を把握していれば良いのではないでしょうか？あとはプロジェクトでの業務ヒアリ ングでしっかりと吸収できればＯＫと思いますけどね。 でないと、世の中のすべての例外を把握していなければならないことになりますよ。 そりゃ無理でしょう。 「俺は「販売管理」専門のＳＥだ！」というように専門化するならある程度は可能で しょうけど、生産管理も、販売管理も、会計もというような状態では．．． 野暮なつっこみ： 流通業界（とくにオークション系）等は「売り」と「買い」が同時に立つというような こともあるので．．． [ メッセージ編集済み 編集者: Beatle 編集日時 2004-09-09 11:26 ] | ||||||||
|
投稿日時: 2004-09-09 11:24
議論が熱いですね。どうも、Wataです。
うちの会社の場合、「SE」と呼ばれる人が作ってくれるのは 「要求仕様書」と呼ばれる要求機能の概要が書かれたドキュメントだけです。 対する私は「開発担当」と呼ばれます。（PGとは呼ばれない） でその開発担当がやるのが、 基本設計、詳細設計、実装、単体テスト、結合テスト、 システムテスト、ユーザーズマニュアル作成、etc etc 
ちなみに、明らかに不要（余分）な機能についてSEに 「これ要らないですよね〜」と尋ねると、「お客さんに聞いてみないと…」と答えられ、 一週間後に「やっぱり、あれはやる方向で…」といわれます。 
というわけで、私もSE不要論者かな。 いや、環境が悪いだけかも知れない。うーん。 | ||||||||
|
投稿日時: 2004-09-09 11:37
いや全然不毛じゃないです。SE不要論とプログラマ不要論は対立しません。「プログラマが ユーザーヒアリングをする SE 不要論」も「SE がコーディングをするプログラマ不要論」も SE = プログラマという同質のことを主張しているわけですから、論を戦わせる必要なんて ありません。 これに対立する主張は、SE はプログラマと異なるスキルを持つとする、 SE/プログラマ分離論でしょう。ここでいう分離は、役割としてではなく、 保有スキルつまり職業としての分離・区別です。 SE には実装技術は必要ないといって分離するのであれば、プログラマ側からは 「じゃあ業務知識(精通)を持っているんだよね？」と言いたくなるんですが、 「業務知識(精通)も必要ない」と言い出し「SE に必要なのは設計能力だ」と言う。 で「業務を切り離した設計能力(論理的思考)ならプログラマも十分に備えている」と 反論しても答えは返ってきません。 業務知識を持たない SE が、プログラマより優れている点ってなんですか？ | ||||||||
|
投稿日時: 2004-09-09 11:39
「不要な機能」というのがどういうものを差すのかわかりませんが、これはやっぱり そうならざるを得ない部分があるのではないでしょうか。 開発業務の受け方や契約にも寄るのですが、ＳＥと言えども「要求仕様に上げら れた内容を勝手に削除する権限」は無いのですよ。必ず「お客さん」との合意の元 で削除しないと。（内部検討で発案されたブラックボックス部分（トレースや内部ログ他） なら良いのですがね。） まぁ、この場合レビューの時にその機能の目的や、必要性等をしっかりと把握しておけ！ っていう激なのですね。 | ||||||||
|
投稿日時: 2004-09-09 11:48
販売管理システムを組んでいるプログラマも「一般的な販売管理」は知っているわけです。 例外部分を「あとは業務ヒアリングで吸収」としてしまうのであれば、実装技術を持つ プログラマが直接ヒアリングしたほうがいいんじゃないでしょうか？ 特有業務をヒアリングで済まそうとして、基本業務知識しか持たない、 実装技術を持たない SE がヒアリングをすることにどのようなメリットがあるのでしょう？ 完全にプログラマに劣っているように見えるのですが…。
「売り」と「買い」が同時に立たない業界ってなんですか？ [ メッセージ編集済み 編集者: 未記入 編集日時 2004-09-09 11:54 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.