＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-11 11:01
「SE不要論は」とは言ってないですが、「スレッドを新しくすれば？」って言ったのは もともとが「SEが業界に精通している」必要があるか？という がるがるさんの問いで、 がるがるさんの言うＳＥはそこで説明されているので、もっと広範なＳＥ論は 別にスレッドを立ててそこで大いに意見を出し合えば良いと思ったしだいです。 ちょっと思ったことを書くと 業務知識と実装技術を持たないで・・・ ってのを考えると トヨタ生産方式なんかを開発してきた様な方たちなのかなとイメージします。 業務の標準化・省力化を担いますが、コンピュータの導入が必須ではないないですよね。 ＯＪＴでいこう！という本に、 流通業の改善をに挑戦した話があるのですが、こういうの見ると電算化で なくても、各々の業界に括られない分析・設計能力があるんだなと感じます。 [追記] 本の内容はトヨタの工場出身の指導員が製造業の工場をメインに現場と一緒に 実際に作業しつつ業務改善を指導していき、その結果どのような改善結果が 表れたかを紹介います。 [ メッセージ編集済み 編集者: MechanicalLife 編集日時 2004-09-11 22:11 ] | ||||||||||||||||
|
投稿日時: 2004-09-11 11:48
私も賛成です。 「SEが業界に精通していなとできない業務」として挙げられている金融の銀行系をやって来ました。3年目の頃、定期預金の自動継続のプログラムを作成して、利率を100％にしてお客さんに叱られたことがあります。元加（元金+利息）で計算が楽だったもので (^^; お客さんの話では「そういうレートにすると行員は検証できない」との話でした。 定期預金の自動継続は複利計算になるため、「Ｘ年後で凡そいくら」というイメージを持ってるとわかって、それから銀行業務を覚えるように努力しました。 それからだんだん分かるようになりました。そうすると、お客様の言っているのが見えるようになりました。 | ||||||||||||||||
|
投稿日時: 2004-09-11 14:26
こんにちは。
Beatleさんは、まずは「SEに業務知識は必須でない」から始まって、「この時点ではこの程度は必要」「こういう例外では必要どころのレベルではない」ということをきっちり述べられていると思います。 何が何でも一つの命題に一つの答えだけを求めるのでなく、Beatleさんのようにまとめ上げられることが実装技術や業務知識以前にSEに求められるスキルではないのでしょうか？ また、（本来仲間であるべき）社内の人と仲良くできない人が（プロジェクトでは同じ方向を向いていたとしても）社外の人とは仲良くできるというのは、ひょっとしたら勘違いであるかもしれないので要注意。 | ||||||||||||||||
|
投稿日時: 2004-09-11 16:39
そうでしょうか？ Beatle さんの話は、ケースバイケースであることを述べているようにみえて、実際のところ話が発散しているだけのようにも思えます。たとえば、前回のコメントではフェーズによって業務知識の必要性が異なるということについて述べているようですが…。 「これからＳＥを志す。 → 業務知識全般としては特に無くても良い。」という意見などは、ビギナーについて述べているのであって話を発散させているだけでしょう。ビギナーという例外的なケースを持ち出すことにどのような意味があるのか私には理解できませんでした。ビギナーの話をするのであれば「(ビギナー)プログラマは実装技術に精通していなくても良い」と言うこともできるわけです。極端に言えば「人間は法を(知り)守らねばならないか？」という議題に対して「赤ちゃんは法律を知らなくても構わない」と口を挟むようなものです。 2「ＳＥとして案件を待っている。 → 基本業務知識は習得する努力はしておく必要がある。」 3「開発案件にアサインされた。 → 着手までに業界基本業務知識習得必須」 4「開発作業中。 → 業務知識詳細まで必須」 通常、2→3→4 というフェーズは非常に短い時間で進行していきますね。(長くても半年くらいかな？) 2 では業務知識は必須ではないとされていますが 4 では業務知識は必須である、となっています。これは何を意味しているのでしょうか。これは、プロジェクトが始まってからでも(短い時間で)「業務に精通できる」ということを意味していませんか？ 「業務に精通していなくてもプロジェクトがはじまってヒアリングをしながら覚えていけばよい。よって、SE に業務知識は不要であり、ヒアリングで吸収していく能力・設計能力が必要なのである」という主張でしょうか？ これは、当初からの がるがるさんの主張に似ています。何度も何度もしつこく言っていますが「それならプログラマでもできます。 SE とはなんですか？」
私は「一つの命題に一つの答えだけを求める」ようなことはしていません。実際に、私は「SEが業界に精通している必要があるか？」という命題に対して「必要ある」「必要ない」両方の答えを出していますよ。 「必要ない」という視点で、プロジェクト単位で覚えていける、SE とは役割である、という主張には同意しています。ただし、この場合は別の疑問として「SE と プログラマのスキルは何が違うのか？」という疑問が出てきます。 「必要ある」というのは上記の疑問に対する答えとして、「プログラミングできないんだから、業務知識は持ってるはずだよね？」という逆説的に導いた答えです。この逆説的に導いた答えが誤りだとすると、「SE はスキル面で完全にプログラマに劣り存在価値がない」ということになります。
失礼ながら、Beatle さんが ご自分の意見をまとめきれているようには私には見えませんでした。Beatle さん自身まだ整理中なのではないでしょうか。それで自分の考えを整理するために前回のコメントを書いたのではなかと理解しています。このスレッドで私の書き込み数はかなり多いので「反論することを目的としている」と思っている方も多いかもしれませんが、決してそうではありません。同意できる意見は素通りしていたりしますし。ただ、Beatle さんの「まとめ」は「難度の高い部分を前提からはずす」「ビギナーの話を主論に混ぜる」などのちぐはぐしている部分があったのでコメントしたまでです。
ラフィンさんのこのコメントは何を言おうとしているのかまったく理解できませんでした。 何を言いたいのでしょう？ もう少し「まとめる」ことはできませんか？ | ||||||||||||||||
|
投稿日時: 2004-09-11 17:07
＞未記入さん
SEとプログラマの定義が未記入さんが書かれた通りで、加えて業務知識を吸収する能力にも差がないとしたら、業務知識のないSEに価値はないですね。 そもそも、人に聞かなくても明確なのではないでしょうか。 Beatleの話が完成されたものでないのはその通りですが、ああいう風に組み立てていかないと結論を出すのが難しいだけではないんですかね。 いやこれは「こういうスレッドってまとまらないよねー」と言いたいだけなんですが(^^;; 例えば、がるがるさんをエンドユーザーとしましょう。『「SEが業界に精通している」必要があるか？ 』というのがユーザーさんから問いかけられたとしましょう。で、このスレッドが要件定義の場としましょう。そうしたら少し展開変わりますかね？ ま、とりあえずSEとプログラマの定義はがるがるさんの定義が正ですね。
やめておきます。 | ||||||||||||||||
|
投稿日時: 2004-09-11 17:58
そろそろ、がるがるさんにも出てきて欲しいと思っていたりするんですが…。
がるがるさんの書き込みでは「プログラマ」については定義されていないのです。私は、プログラマにも(業務に依存しない)論理的思考に基づく設計能力があると考えていますが、がるがるさんのコメントでは、設計能力が SE の特徴であるかのように書かれていることから「プログラマには設計能力(吸収能力)がない」という意図が感じられるわけです(推測)。
全然、明確ではありません。大丈夫ですか？ 私の主張を受け入れろとは言いませんが、私の主張(言っていること)を理解しないと反論・コメントするのは難しいと思いますよ。 まず、プログラマについて定義されていない以上、私の言っている「プログラマ像」は定義ではなく主張でしかありません。「吸収する能力に差がない」というのは定義ではなく私の主張ですから「SEに価値がないのは明確」とは言えませんね。実際に私は「プログラマに設計能力がないと思っているのですか？」と聞いていますが、答えは返ってきていません。 また「吸収する能力に差がない」としても、SE がプログラマの持たない他のスキルを保有している場合も「SEに価値がないのは明確」とはなりませんよね。これについても私は想定していて、「プログラマになくて SE にある能力とはなんですか？」と聞いているわけです。同じく、答えは返ってきていませんが…。
結論を出す(合意する)必要はないと思いますが？ | ||||||||||||||||
|
投稿日時: 2004-09-11 18:45
に対してでした。 ちなみに私の主張？ ・SEとPEは役割として分けることはできるがそれは人を分ける意味ではない。 ・また職業としてはSEとPEは分けない方がよい。 ・それをSEと呼ぼうがプログラマと呼ぼうがお好きなように。 ・業務知識はシステム周辺に必要なものはSEの役割として把握する必要がある。 ・業務知識はプログラム周辺に必要なものはPEの役割として把握する必要がある。 ・ただし最初から必要なわけではない。 | ||||||||||||||||
|
投稿日時: 2004-09-12 00:29
そう言っております。 というのは、業務知識そのものが問題ではなく得られた業務知識をどうシステムで 実現するかを考える能力こそが大事であると思うからです。 「それならプログラマーにもある」と反論されるかもしれません。それについては 「ＳＥに業務知識が必要か」ということとは切り離して考えるほうが自然ではない でしょうか？ 実際に例外として上げた業界以外は対象ユーザーのシステム化に必要な業務は比較 的短時間で覚えられます。ただ、除外した業界の業務は膨大で、複雑な為、経験し ていないとヒアリングすらまともにできないことがある為、一般論としては除外し ました。 未記入さんが主張されるＳＥ＝プログラマーというのは一般論としての主張ではな いのですか？
職業としてのプログラマーにもその知識や能力さえあればできます。実際に役割と してのＳＥにアサインする際、別プロジェクトではプログラマーの役割をしていた 人が当てられることも有りです。知識や技術等、能力の幅や深さが同じであれば、 ＳＥとしての役割をプログラマーがやろうと、プログラマーとしての役割をＳＥが やろうと一向に構いません。 ただ、ここで言っている「知識」というものと「技術」や「能力」というものを同 じ土俵で語ることはできないと思います。その意味で別スレッドではいかがでしょ う？と言っているわけです。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.