＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-09 14:11
業務知識（業種知識でも、商品知識）は受注した作業工程によってすぐ必要か少し待てるか
じゃないでしょうか。それと規模にもよるでしょうけど。 すぐ必要なのは、作り込み作業以降で受注した場合と思います。 但し、作りこんで逃げれる（？）計画で受注した場合は不要でしょうが。 (^^ 設計作業からだったら、設計しながら覚えても間に合うような気がします。 但し、それもそのプロジェクトに参加している人の自覚で行うものなので 学校みたいに「覚えました？」「はい、分かりました」ってことではないと思います。 従って、ＰＧ、ＳＥ，ＰＭを問わずじゃないでしょうか。 特に、ＳＥは業務知識を知ってること（知ろうとすることも含んで）は当たり前じゃないでしょうか？ 業務知識が無かった場合、テストなんかどう行えるのでしょうか？ そうしたことは、すべてお客さんがやるものだと思ってるんでしょうか？ [ メッセージ編集済み 編集者: いつも新米 編集日時 2004-09-09 14:13 ] | ||||||||||||||||
|
投稿日時: 2004-09-09 14:16
あっ。言葉が足りなかったですね。売り（売上）、買い（仕入）です。 すべてのオークションがその形態ではないですが、出品者から開催会社が落札と同時に 買い取り、落札者に対して売るという売買を成立させることがあります。（一応古物商 なので） その際、出品者から商品を買い上げるのが仕入れで、落札者に売るのが売上。これが オークションでの落札と同時に発生します。（もちろん商品そのものの金額とは別に 両者からの手数料のみを扱う場合もありますが、仕入に対する手数料発生と売りに対 する手数料発生が「落札」という同じタイミングで起こります。） ってこういうような誤解が基本より上の個別知識ではないのでしょうかねぇ。 [ メッセージ編集済み 編集者: Beatle 編集日時 2004-09-09 14:17 ] [ メッセージ編集済み 編集者: Beatle 編集日時 2004-09-09 14:22 ] | ||||||||||||||||
|
投稿日時: 2004-09-09 15:07
なるほど納得いたしました。仲介料(サービスチャージ)ではなく 仕入 + 売上 で構成されているわけですね。 | ||||||||||||||||
|
投稿日時: 2004-09-10 06:32
私が前にいた会社では、「技術営業」とか、「ビフォアSE」とか呼んでいた「技術部」がいました。この後ろに設計をする「SE」がいました。なので、ビフォアSEは客先業務に精通している必要はありましたが、アフタSEには、そう必要はありませんでした。
が、ビフォアは「技術部」のはずなのに「技術」に疎すぎ、いや、ハードウェアには強かったんだけどソフトウェアには弱かったので、後ろにいる人間としては冷や冷やしていました・・・ | ||||||||||||||||
|
投稿日時: 2004-09-10 16:08
とりあえず私なりに（勝手に(^^ゞ）整理してみました。
前提： ・業務アプリケーション開発を担当するＳＥ ・固定業界というわけではなく、いろいろな業界の開発案件を受ける ・開発作業は要件定義からリリースまで ・金融、原子力、医療等特殊な業界は除きます（これは常日頃から詳細まで理解していない と難しいので） とします。 状態としては、 １．これからＳＥを志す。なろうとしている。 ２．ＳＥとして案件を待っている。（案件の谷間） ３．開発案件にアサインされた。（開始は１〜２週間後） ４．開発作業中。 というように考えた場合、 １．業務知識全般としては特に無くても良い。（必須ではない） ２．基本業務知識は習得する努力はしておく必要がある。 ３．案件対象のユーザー企業の業界基本業務知識：着手までに習得必須 ４．ユーザー企業の業務知識詳細まで必須 （ウォータフォール型では、基本設計完までにはこのレベルになる必要あり） という感じでしょうか。 案件をこなしていく内に詳細業務知識レベルまでのバリエーションが増えるはずなので、 ２．の基本業務知識の勉強というのは、未経験、新しい業界等に限られてきます。 ※ 基本業務知識というか業界標準業務知識というようなものは、本当は会社で、 １〜２週間ぐらいでマスターできるような教育カリキュラムが用意されていて もいいと思うのですが．．． アジャイル開発においても、やはりユーザーへのプロトタイプレビューをする前に 内部レビューにて、ユーザーと同レベル（が望ましい）の業務知識を持った人（ＳＥ かプログラマーかは別として）が、業務的観点から見た出来栄えとか、方向性等を 見る必要があるので、この段階で業務知識詳細は必須でしょうね。 | ||||||||||||||||
|
投稿日時: 2004-09-10 17:26
前提から、これらの業界を除いてしまうのは少々作為的じゃないでしょうか？ こういった業種でこそ、詳細な業務知識を持った SE が求められるわけで。逆に、販売管理などの一般業務だけで構成可能な業種は、SE 不要の声が多くあるのではないかと思います。販売管理などの部分業務でシステムを受注する場合、規模が小さく 2〜3人のチームであることも多いと思います。このような少数開発場面では、全員が実装技術保有者である必要性が相対的に高くなるのではないでしょうか。 また、このような小規模システム受注の場合は、業種特有の要素が少ないため業種知識が不要であることも多いです。これらの多くは、基本業務知識 + ユーザー固有運用 で構成されており、ユーザー固有運用に関する情報ヒアリングで済み、詳細な業務知識は不要と言えるかもしれません。(業種特有の要素が少々あったとしても、ユーザー固有運用のヒアリングと一緒に吸収できますし。)
これはもったいないからやめましょう。ユーザーにしてもらえること(業務観点での評価)は、ユーザーにしてもらえば良いのです。ユーザー提出前に社内で確認(ブラッシュアップ)しなくてはならない、という発想自体が アジャイルを阻害しています。もっと、ユーザーと協調してシステムを構築していきましょう！ [ メッセージ編集済み 編集者: 未記入 編集日時 2004-09-10 17:28 ] | ||||||||||||||||
|
投稿日時: 2004-09-10 18:10
作為的です。 というのはこの業界の場合、専門特化した知識が必要になります。そのような知識とい うのは「勉強しろ」とかで済まない部分が多く、会社としてもこの業界からの受注を 何度も繰り返すようなことをしない限りなかなか成功しません。 ですから、大手金融機関が自分のところのシステム開発専用の情報システム会社を作り そこで特化された人材を作るような形態になるので、なかなか一般のＩＴ関連業界ＳＥ が飛び込む機会というのは少ないでしょう。そういう意味で除きました。
私はＳＥに実装技術が不要とは全く思っていません。（念のため） 前の投稿では実装技術に関して触れていないだけなのですが．．．
それはよくわかります。と言う意味ではＳＥ＝プログラマーも理想論としては納得できます。 ただ、ＳＥもプログラマーもそれほどスキルフル（業務、実装の両方）なメンバーばかり とは限らないので、この局面では「ＳＥ：業務を熟知している」「プログラマー：実装技 術を熟知している」という観点から、業務・実装の両観点からのすり合わせというフェーズ と考えています。 変な話、業務的な事を全く考えずに作りやすい、作るのが楽という観点のみで作成された プロト（ユーザーに見せた途端３０秒でダメ出し）というのもあるので．．． とりあえず、ここでは「ＳＥ（プログラマーとしても良い）には業務知識が必要か？」と いう観点なので、「一般業務アプリ開発にＳＥは不要か？（ＳＥ不要論）」ということは 別スレッドか何かにしませんか？ | ||||||||||||||||
|
投稿日時: 2004-09-11 01:18
これらの表現は、まさに (SEに)詳細な業務知識が必要である、ということをあらわしていると思います。「SE に詳細な業務知識が必要となるようなケース(特殊業種)を除く」という前提では、何も論じる必要は無く「SE には詳細な業務知識は必要ない」という結論になりませんか？ 「SEが業界に精通している必要があるか？」という題目に対して、「SEが業界に精通していなとできない業界は除く」という前提を付けるのは、あまりにも馬鹿げていると思うのですが、私が何か読み違えているのでしょうか…。
いえ、理想論ではありません。うちのように 2,000万以下の案件を 2〜3人でこなす現場においては現実解です。
あれ？ あなたは「SEが業界に精通している必要がある」肯定派でしたっけ？ 私も肯定派なんですが、あれ？ なんの話でどのように意見が喰い違っていたのでしたっけ？
前にも SE不要論は他スレで、と仰っている人がいましたが残念ながら分離することはできません。なぜなら「業務知識の有無」と「SE の要・不要」は密接な繋がりを持っているからです。「SEに業務知識は必要ない」という主張に対して、私は「業務知識を持たない SE とは何なのか？」と問いました。この問いに対して大きく 3つの回答があったと思います。 (回答1) SE も十分な実装スキルを持っておりプログラマとしても振舞える。SE とはプロジェクトにおける役割に過ぎない。(私のいう SE = プログラマだと思いますので、この回答には同意します。) (回答2) その他のシステム要素、ネットワーク, データベース, 運用知識, トラブル対応など SE の担当分野が存在する。(この意見には同意できません。実装技術を持たない SE よりもプログラマの方が、ネットワーク, データベース, トラブル(プログラム不具合)対応に強いと思っています。) (回答3) SE は設計能力を持っている。 で、回答3 に対して、私は「プログラマも設計能力を持っています。プログラマになくて、SEにある能力とは何ですか？」と質問しましたが、これには誰も回答されていないと思います。 (なぜか、この質問のあとは SE は役割であるという主張が多かったような気がします。) 今のところ、私には SE が プログラマより優れている点が分からない(誰も教えてくれない)ので、「それなら SE なんて不要なんじゃないですか？」ということになるのです。 最後にもう一度聞きましょう。業務知識と実装技術を持たない SE とは何ですか？ 明確にプログラマと差別化できるスキルが何かありますか？ | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.