＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-12 03:27
いいえ。金融業界も含めて一般論と思っています。ただし、これらの業界ではプロジェクトが開始されてから業務に精通していくことは困難であり、はじめから業務知識を持っていなくては務まらないと思います。さらに「業務知識が必要」だからといって「実装技術を持たなくても良い」とはなりません。つまり、これらの業務知識が求められる業界では SE はスキルフルな人材である必要があります。 (ヒアリングで十分補える業界) SE(実装技術) = プログラマ(実装技術) (詳細な業務知識が必要となる業界) SE(業務知識 + 実装技術) >= プログラマ(実装技術)
ここで言っている「知識」「能力」とはなんでしょうか？ 話の流れからすると業務知識に依存しない知識・能力を指すことになりそうですから…。モデリングに関する知識や能力のようなものを指していると理解して良いですか。仮にモデリング技能だとした場合、これもプログラマ(実装技術保有者)のほうが適性があると思います(実装技術がないと務まらないという意味)。 モデリングは 事象の抽象化(概念化)と、実装に合わせた具象化(書き下し)という相反するふたつの側面を持っています。抽象化に関しては実装技術は必要ありませんが、具象化には実装技術が不可欠です。たとえば、UML はプログラミング言語(実装)に依存しないもの、ということになっていますが、これは記述方法が実装(特定の言語)に依存していないというだけのこと。実際には Java や C++ のようなオブジェクト指向言語のクラス設計に精通している必要があるのです。 モデリングとは、実装(システム化)の礎を目的として行うのものです。実装技術を持たない SE が概念面だけで組み上げたモデルは、逆に実装の障害になったり、最悪、実装不可能であったりします。というか、実装技術を持たない SE のモデル化の多くは単なる業務フローになってしまっていることが多いですね。(ヒアリングした内容をまとめるのが最終目的になってしまっていて、実装の礎となるようなモデルになっていないことがほとんどです。) おっと。また話がそれてしまいましたね。スレ違いという意見が多いので、これで終わりにします。言いたいことのほとんどは言いましたし。お疲れ様でした。 | ||||||||
|
投稿日時: 2004-09-12 05:11
ん？ ひょっとして一般論で語りたいのは "SEに実装技術は必要か？" っちゅうことですか？ そもそも、一般論（例外なし）で「○○は必要（必ずなくてはならない）」は、そう言えたもんじゃないと思いますが。 | ||||||||
|
投稿日時: 2004-09-12 12:28
但し、最近業務知識もない自称ＳＥが金融系にも増えていると思います。 金融本来必要とする知識もなく、ＳＥと名乗ってるのが多い。 ここの討議では、基礎知識という部類に入るものでも、それも知らないＳＥが。 ＳＥは実装技術の必要性（当たり前ですが）がわからない（又は、知らなくて良いと思ってる輩）は、ＳＥなんて名乗って欲しくない。 | ||||||||
|
投稿日時: 2004-09-12 16:06
たとえば、１つのプロジェクトを発生から次のように「工程」分けした場合、どこからどこまでを「ＳＥ」、どこからどこまでを「プログラマ」としますか？
１：営業活動 「当社にはこういう商品があるが、御社のこれこれの業務を置き換えれば、 これだけの改善が見込める」 ２：営業支援 営業さんに商品の内容を教え、お客からのツッコミに答える ３：受注支援 「こういうことをしたいのだが、お宅の会社にできるかね？」と聞かれ、 規模と、金額的な見積もりを返す。また、プレゼンテーション用資料を作る。 ４：現状分析 現在の業務内容を分析し、改善点と新しいシステムとの融合点を見つける。 ５：要件定義 顧客のニーズを聞き出し、金額的、期間的に可否を判断する。 ６：システム設計 要件定義で決定した事項を受け、システム全体がどのように配置され、 どのように使われるか、定義する。UMLでは配置図など。 ７：機能設計 システム設計を受け、機能的なまとまりに分割する。また、共通部分の 切り出し、ライブラリ、パッケージの使用を決定する。パッケージ定義。 ８：詳細設計 機能設計を受け、各々の機能の担当範囲と、ユーザインタフェースを 決定する。クラス図、コラボレーション図など。 ９：プログラム設計 シーケンス図、ステートチャートなど。 １０：プログラミング １１：個別テスト １２：機能テスト １３：システムテスト １４：全体テスト １５：納品、客先教育 １６：保守、バグ対応 前にいた会社では５までと、５以降を「ビフォアＳＥ」、「アフタＳＥ」と呼んでいました。なので、単に「ＳＥ」というと全部が入り、「詳細な業務知識が必要」となりますねぇ。 | ||||||||
|
投稿日時: 2004-09-12 16:52
CHN＠業務知識セロです。
かっ〜〜！ な〜んもしらんから、参戦したくも参戦できないのが悔しい〜 
以上、嫌がらせでした〜。 _________________ | ||||||||
|
投稿日時: 2004-09-12 17:24
こんにちわ．
激しく同意いたします． 自分は「特定分野」での仕事が少なく， さらには SE ですらないのですが， 前にも書いたとおり「個人の観念」でしかない気がしてます． 「必要か否か？」という疑問には「あったほうが良い」と答えざるを得ませんが， では「そうではない人たちを切り捨てて成り立つか？」となると「無理」でしょうし． 結局，「現役の人たち，頑張ってね」と申し上げるしかなかったりします． かく言う自分は，そもそも「この人たちは SE なんかぢゃない」と切り捨てて， 自分で学んで自社の仕組みを作った口ですが．．． ただ，Jitta 様のところのように「仕組みで分ける」という仕組みを 今の会社では試行錯誤で取り入れていますが， 「ここまではうちの部署だからそこから先は知らない」みたいな 観念をぶつけ合うだけで，離合集散の繰り返しになると感じてます． ※弊社だけかもしれませんが．．． なので，役割であれ職種であれ， 努力目標として「業務知識を加える」のは必要かと考えます． また，「実装技術も身に付ける」のも必要と考えます， そうなると，やはり徒弟制度的な「師匠」にあたる人が SE なのかな？ とも思ったりしてます． 愚考ですね．．．相変わらず． | ||||||||
|
投稿日時: 2004-09-12 17:39
るぱんです。
独り言です。 自分の範囲じゃないから手伝いたくないって言う態度がいかんのでは？ 一つのお客さんを受け持つんだからチームであたればよいものを・・・。 と考えてしまいました。 でも、部署があって、縦割りに近くて横で連携が取れないって言うのは 非常にストレス溜まりますね。 | ||||||||
|
投稿日時: 2004-09-12 20:59
とりあえず呟いておきます． かなり暴挙なので，ことある毎に進言しても， そもそも上にいる人たちが過去の現在も「SE に非ず」なので， 言っても「わかんな〜い」な会話なわけで．．． チームにしたらしたで，「できる人よろしく」な雰囲気が濃密な．．． これで「人が育つ」としたら， みんな一人前になったら出て行ってしまうの当然なんだけどな．．． | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.