＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-08 14:58
元ネタは、「＠IT会議室 > ＠IT情報マネジメント 会議室 >
プロジェクトの納期遅延について」になります。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=14494&forum=15&start=0 ちっと興味もあり、且つ上記のスレッドから少し外れた話題に なっているので、別スレッドを、僭越ながら足せさせていただいた って感じです。 で、本題。 皆さんは、「「SEが業界に精通している」必要があるか？」という 問いに対してどのように考えてらっしゃるでしょうか？ 基本的に、ここでは「結論を出す」というよりも、「お互いの意見を ぶつけてそれぞれの考えを知りつつ、各個、自分のスタンスを確立する」 ことが主眼にできれば、と考えております。 で、私は「必要ない」派です。 ちっと、前述のスレッドの発言への返答、という形から議論を発展 させていきたいと思います。 あと、先に議題定義しておきたいのが「SEってなに？」っていう 部分ですね。 SEという単語をひらいた時に、英単語ですら色々出揃う上に、 そこに意図される意味合いはかなり各人開きがあるように思われる です。 ので、私は、今回の議論に関しては、意図的に「設計をする人」を SEと呼称します。設計するので、無論「設計のためにヒアリング」とか 「設計の過程/結果、逆提案をかける」ってあたりも全部含めます。 というわけで、ちっと返信をかねて、私の意見を。
このケースで逆に痛い目に会っているのも、私は多々見ております。 takuさんの
という発言がそういう意味では私の知っている現場に非常に近いのですが。 つまり、 ・その会社で「その業界の一般常識」が通用しない ・その会社で「同業種の別の会社の一般常識」が通用しない ことから、「暗黙の了解」の齟齬が起きて…というケースです。 あと、もうちょい泥臭い話だと、他社の話を引き合いにだして「御社は変わった 業務運用をされて いますね。他社さんでは○○をしていることが多いですよ。」 と発言すると、相手の逆鱗に触れるケースっていうのもあります 
実際、私も「まったく知らない異業種」に出向いての仕事、っていうのは 多々あります。それと同じくらい「以前に複数回やったことのある、それなりに 把握している業種」に出向いての仕事っていうのもあります。 ここで重要なのは「その業種を知っていること」ではなくて、「相手がなにを したいのか、という要求を正しく把握する能力」です。 で、そのために私は、知っている業種ですら、わざと「知らないフリをして相手に その業種での常識を語ってもらう」ってことを良くやります。 それによって「相手がイメージしている自業種の内容」が的確に把握でき、 場合によっては「相手が自分で自分の業種への再認識」を促すこともできます。 「知彼知己、百戦不殆」彼を知り己を知らば百戦危うからず とりあえず「システムを作る」というヘビーな戦のために、顧客にもきちんと 「己を知る」ことをやってもらうと、後々でメリットが大きいんですね。 私がSE、特に「顧客にインタビューをかけて設計をする人間」にとって 重要なのは「その業種を知っている」ことではなくて「相手から必要なことを ヒアリングする」能力と「新しいことを速やかに学び取る」能力だと思います。 っていうか正直なところ「新しい業種相手だと慎重にならざるを得ない」 状況では、私みたいな零細はあっというまに潰れますので
それよりは、方円の器に従う水のように柔軟に、ってのをモットーに してるのがまぁ私のスタンスです。 もっとも、方円の器に従えるだけの「柔軟な基礎知識」ってのが重要で、 それが結構ヘビーだったりはするのですが
皆さんからの色々な意見を楽しみにしております m(_ _)m | ||||||||
|
投稿日時: 2004-09-08 16:04
話題の未記入です。
がるがるさんの言ってることは大筋で何も間違ってないですね。 がるがるさんの主張の多くには同意できます。 それでもあえて「SE不要論過激派」としてコメントさせていただきます。 「暗黙の了解の齟齬が起きて」というのは、ややこじつけのように感じますね。 「精通」しているから「確認しない」という時点で SE 失格でしょう？ 知っていたって相手の話を聞くし、確認だってします。
「わざと知らないフリをする」というのは知っていないとできないテクニックです。 知っていて聞くのと、知らないで聞くのではまったく違いますからね。知らないで 聞く場合、相手の使う用語が分からないことも多々あるでしょう。都度、用語について 説明を求めるようでは、相手の話の腰を折ることになりかねません。 「相手に良い気分で上手に語らせる」のはとても大事なことですが、それができるのは ある程度の知識を持った者です。知識を持たない者が相手に語らせるのは非常に難しい。 知らないと、質問だって上手にするのは困難でしょう。 ※たとえば、営業がある技術者をおだててもあまり詳細な説明が返ってこないかもしれない。 技術知識のない営業の場合、「すごいですね」程度の相槌しか挟めないから。ところが、 ある程度、同種の知識を持っている技術者が相槌程度に「○○が××となるわけですね」と 相手の言っていることを良く理解しているという態度を示すと、相手はより気分良く 話をしてくれたりするわけです。 「相手に聞く」ことは大事ですが「知らないと聞けない」ということもあるわけです。
確かにその通りです。ところが、上記の能力(ヒアリング・理解・分解・再構築)は プログラマにとっても必須のスキルであり、多くのプログラマが備えています。 プログラマの場合は、ヒアリング部分が、「ドキュメント等の読解」で磨かれている、 というウェイトの違いはありますが、他人の説明・意図を読み取るという点では 同質といえるでしょう。 SE には業務知識が不要で、設計能力(ヒアリング・理解・分解・再構築)が重要だ、 という意見を認めても構いませんが、それを認めてしまうと、SE という存在は そのうち プログラマに駆逐される結果になると思いますよ。 本当に SE は業務知識不要・実装技術不要でいいんですか？ 設計技術(ヒアリング・理解・分解・再構築)だけで存在価値があると思いますか？ また、プログラマには、設計技術(ヒアリング・理解・分解・再構築)がないとでも たかをくくっているのでしょうか？ | ||||||||
|
投稿日時: 2004-09-08 16:16
ん〜ケースバイケースという感じもあるのですが．．．
「ＳＥ＝設計する人」というのをもう少し絞りませんか？ 例えば、 対象としては、業務アプリケーション開発 規模から見た場合、 大規模：業務設計や基本設計の機能設計等を受け持つ人 （ＵＭＬならユースケース図を書く人） 中小規模：ヒアリング〜設計まで受け持つ人 というぐらいではないかと思うのです。ＳＥと言ってもインフラを専門に担当する ＳＥやら、制御系ばかりのＳＥも居るので．．． この前提で言いますと、 「必ずしも必要では無いが、有るに越したことは無い」 という感じです。 ただし、 >もっとも、方円の器に従えるだけの「柔軟な基礎知識」ってのが重要で、 >それが結構ヘビーだったりはするのですが これが大事で、ある業界の新入社員が自分の会社の業務を覚えるよりも短時間で 吸収できる能力が必要で、標準業務というか基本業務については、少なくともヒ アリングや開発する段階では「精通」とまでは行かなくても「知っている」レベ ルまでになっている必要があると思います。 つまり、「突然呼ばれた」とかでは無い限り、 「ヒアリングや開発に携わるならそれまでに基本業務知識ぐらいは、勉強して来てね」 ということですよ。 業界内の会社ごとの固有差とか業界動向に関しては、まぁ有れば有るにこしたことは ないのですが、経験とかも必要になりますから、業界固定でプロジェクトを担当しな い限り難しいでしょうね。中には特殊な業界というのもありまして、業務知識があっ ても初めてじゃなかなかうまく行かないこともあるようですが。 | ||||||||
|
投稿日時: 2004-09-08 16:16
はにまるです。
御指定のスレッドは、議論に入るタイミングを見失いました．．． がるがるさんの問に対しての直接返答は「必須では無い」です。 「必要では無い」との違いは、知識を持っている方が良いと言う事です。 業種知識に限らず、仕事を依頼する際に依頼先（相手）に依頼に関する知識が あると思うと前提条件や用語の定義を飛ばし、自分の知識と同じ意味合いで 相手も理解している又は、理解してくれるであろうと暗黙的に想定するのが 人の性質と思います。 これはシステム開発や＠ＩＴ会議室でも多々見受けられますね。 ですから、がるがるさんの仰る事は賛同出来ますが、 しかしここで問題なのは、ある仕様について一切説明が無い時です。 依頼主が説明という行為を行っていただければ、各用語や話から想定する 流れにより、確認や質問が出来ますが、もし説明が無くまた自分に知識が 無い場合、完全に問題がスルーしてしまいます。 それをフォローするには、「業種知識」が必要ですが、 それにも関わらず業種知識が「必須では無い」としない理由は、 そのフォローを「業務知識」で賄える事が多いからです。 今日では「業務知識」の基礎を取得する際に事欠くことがありませんし、 又「業種知識」は「業務知識」の発展系である事が多く「業務知識」抜きで 「業種知識」の取得は困難だと思います。 で、がるがるさんの問に対する返答をちょびっと変えてもう一回すると、 「業種知識は必須では無いが、業務知識は必須」となります。 しかし、話としては根本に「仕事の仕方」についての理解不足が問題だと思います。 今の所、理解不足が悪いのでは無く、理解している人は少ないからこそ、 どう対処するのか？と言う認識がシステム開発ではより一層必要であり重要だと 考えます。 システム開発する際に、「仕事の仕方」をどうするのか議論出来ぬ風潮の組織は 全てに関して程度が低いと感じます。きっとこれはＩＴ業界のみの話では 無いと想定しています。 もし、業種知識も業務知識も無いのであれば、 「仕事の仕方」が一級品でなければなりません。 もし仕事の仕方も程度が低いのであれば、そこを退けというのが私の本音です。 以上、実体験からでした。 # 編集しました。 読み直すと不細工でしたので整形手術を施し、ちょっと不細工にレベルアップしました。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-09-08 16:31 ] | ||||||||
|
投稿日時: 2004-09-08 16:44
もうひとつ、プログラマSE論。
業務システム開発のスタイル自体が、かなり変化してきていますね。ウォーターフォール なんて紀元前までしか使っていなかったんじゃないかと思うくらい過去の遺物となっています。 オフコン時代と異なりユーザーも個人PCでワードやエクセル、ネットサーフをしたりと PC に 慣れていることもあり、最近はユーザーインターフェイスへの要求が高くなっていますね。 昔は伝票さえ出れば操作体系は二の次だったのに…。 で、このような要求レベルの上昇に対応するために、アジャイル, プロトタイピング, リテイク といった開発が要求されるようになってきているわけです。打ち合わせの都度、 プロトタイピングを持ち込んだりということも増えてきていますよね。 (昔は画面レイアウトだけで打ち合わせしてたりもしたけど…。) このような早さを求められると、SE - プログラマの情報伝達レイテンシが大きく影響 してしまうので、プログラマ同行という方法が出てきます。あと、技術面での要求も 高くなってきているので、「実現可能性」を即答するためにも、プログラマ同行の 必要性は増えてきています。 それで、プログラマ同行で打ち合わせを行うと、お客さんがなぜか SE よりもプログラマに 話かけてくるようになります。ちゃんと返事が返ってくるから。SE に聞いても、聞かれた SE は横にいるプログラマに「どう？」と振るだけだったりするので、お客さんもそれを 察知してプログラマに話を振るようになってくるのです。どうせ、業務のことはイチから 説明しなきゃならないんだから、コンピュータのことを知っているプログラマ君に話した方が 早そうだ、と。これ実際にあった話です。 まあ、うちの会社は SE = プログラマ なのでこんなことにはなりませんけどね。 SE と プログラマが完全に分離しているとアジャイル開発できないような気が するんですけど、そこんところどうなっているんでしょう？ どのように解決しているんでしょう？ | ||||||||
|
投稿日時: 2004-09-08 16:45
お疲れ様です。
CHN＠またさぼりに来たです。 おれは大概、未記入さんのどうでもいいことを言っているときのことば使い 態度が気に入らないですが、なぜか、まともに話をするときはほとんど ご意見に同意できます。 SEってやはり業務知識が必須だと私目も思います。 それがないSEなら存在価値がわかりません。 話するなり営業なりよりのことだけなら、業務知識ゼロの 私目もできますぜ！(いやだれでもできる) 未記入さんという名前の方が多すぎますので、 だれのことを指してるのか紛らわしいです。 適当にでも名前付けてちょーよ。 _________________ 世界平和を願う！ http://park8.wakwak.com/~chin/ [ メッセージ編集済み 編集者: CHN 編集日時 2004-09-08 16:47 ] | ||||||||
|
投稿日時: 2004-09-08 18:13
精通する必要はないし、あったほうが良いくらいかな。
一を聞いて十を知ることができるよう人なら不要だとも思います。 顧客が長年培って来た業務のなかで顧客の問題解決に必要な 情報を早く聞き出し、早く理解する能力や顧客との齟齬を最小に する姿勢の方が業務知識より大切でしょう。 ヒアリング〜実装まで、一人でできたらいいけど、現実では 物量が多くてできないので、多人数で分担してやりましょうって ことからＰＭ，ＳＥ、プログラマなどが分かれてるだけで、 求められる能力はそれほど変わらないと考えています。 コンサルタント、ＰＭ、ＳＥ、プログラマなどの呼称がきちんと 定義されていて、それぞれがちゃんと役割をこないしてるような 環境で仕事をしているひとは羨ましい限りです。 私の勤めている会社は人数が少ないのでそういった区別自体が希薄です。 | ||||||||
|
投稿日時: 2004-09-08 20:55
業務知識はある方がベター派です。
ただ、システムに関連する業務はある程度以上に理解できずに設計を完了するようではマズいのではないかと思います。 SEの定義は、「SE = プログラマ」な会社の人が「SE不要論過激派」と自ら名乗るように、 ・個人につく肩書きのようなもの ・単なるプロジェクトでの役割 の２種類で使われているようですね。 私にとってのSEは後者です。 ですので、「業務知識がないとその人はSEやってはいけない」ということは言い換えると「業務知識があるSEをアサインできないのならその会社はその案件を受注してはいけない」ということになります。 ただ、私は「プロジェクト開始時の業務知識は必須でない」派ですので受注しますけど。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.