＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「SEが業界に精通している」必要があるか？
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-09 11:55
未記入さんが私の好きな所を突いて来たので、すんませんがスレッド議題から外れます。
MechanicalLifeさんの発言を含め、省略する意図があれば問題は無いとは考えます。 で！わくわくタイムですが 
仰る通り、私が業務知識で上げたリスト中、販売管理（売上管理）と生産管理は、 業種（っていうより最近はユーザ単位）によってガラッと変わりますね。 その反対で財務管理は、かなり流用が可能で楽チンですが。 で未記入さんの仰る内容は、私の中では「委託販売」と言う考えです。 委託販売は原価が非常に高い高級品販売業でもありますし、 受託側になりますが最近ではフリーマーケットの発展系である レンタルボックスたる商売も在るようですね。 で昔、私が「委託販売」のシステムに携わった時の話ですが、 「売上管理」システム自体を変更して「委託販売」管理に変更してしまいました。 でも最近では業種によって販売方式が一通りで無い事が多くなり、 直接変更した事は、失敗だなと思っています。 例えば、今、存在するかどうか知りませんが出版業界で委託販売では無く 通常販売を行う企業がニュースになりましたよね。これは一部の流れであり、 委託販売が基本の業界でも直売や通常販売する事もこれか十分にありえる訳です。 # 電子出版がまさしくそれかな？ とすると、「委託契約システム」→「売上管理システム」→．．． という構成の方が柔軟性があるよな〜と今は考えています。 # 勿論ですが、通常の売上管理システムと在庫システムとの連携制御が変わります。 ちょっと難しい言葉になりますが、 業務知識は、各ユーザ業務（勿論私たちの現場も）の抽象的で概念的な知識だと思います。 そして業務知識は、法律や外部サービス（金融機関のサービス等）に強く影響を受けている為、 どの業界でも似た概念になると思います。 では「業界知識」は？と問われると、 ここまで熱く議論すると、つたないシステム構成理論を出しますが、 業界知識は不要です。不要と言うのは、前回の不要とは異なり、 業界という括りで考える時代じゃない！って事です。 今では、小売の中小企業でも海外と直接取引をしたり、 小売業でない企業でもＷＥＢを含む通信販売を用いて直接販売をしたり、 既存概念の業種知識だけでは、意味合いが薄くなる所か柔軟性に欠ける システム構成になると思うのです。 ですからその代わりにサービス形態という概念で括った物の考えが 重要であり、考えを転換する必要があると思っています。 | ||||||||||||
|
投稿日時: 2004-09-09 12:43
本論からずれてますが、
曖昧な書き込みをしてしまってすいません。 私の書いた「不要な機能」は、どちらかというと、 まだ要求として挙げられていない細かい部分についてです。 ある特殊なケースに対応するには、付加的な機能を追加しなければならない。 でもそれを追加することによるデメリットもある。むしろデメリットの方が多そう。 そんな感じです。 私はデメリット（操作性の悪化、設計の悪化、他）をSEにちゃんと説明します。 しかし一週間後、場合によっては２〜３週間後に、ほぼ必ず「やって」といわれるのです。 どうも、お客さんの「全部やって」という言葉を聞きに行ってるだけにしか思えなかったりします。 まあ、根本的な問題はアジャイルじゃないことだと思いますけどね。。 未だにウォーターフォールモデルで仕事をしているからだと。 で、そのアジャイルにSEは要るのかというと… というわけで、スレ汚しスミマセンでした。 | ||||||||||||
|
投稿日時: 2004-09-09 12:45
まあ、販売に着目するとそうなんだけど、出版は仕入(?)も特殊ですね。 ライターさんへの原稿料支払があるので、一般の販売管理で 仕入先 = ライター として代用することはできません。源泉徴収をするとか、支払調書を出さないと いけないとか…。なので、うちでは、業務でまとめるのではなく業種でまとめて 「出版社システム」としてテンプレート化しています。 これが私の SE だったら業種知識を知っていないといけない、 という主張のひとつに繋がっているのかもしれません。
不要というか…。変化が大きい、各社が特色を出しているから、 ヒアリングでゼロから組み上げていくようなシステムが増えているんですよね。 で、このタイプの場合は、実装技術を持ったプログラマがヒアリングしたほうが 良いと思っています。 最近は、キャンペーンなんかもシステム化しますからね…。昔は、別品番で 単価下げた商品マスタを登録したりとか業務運用で対応していたことを、 システム化するようになってきたり。さらに基幹業務だけでなく情報系との 繋がりもシームレスになっていますね。販売管理から発展して、売上推移表を ○○別にも出したいとか、営業員に自分で分析させたいだとか、経営判断に 使えそうだとか。うちでは、基幹業務リプレースの際には、基幹業務で蓄えた データの分析システムを中心として情報系も一緒にプッシュしてたりします。
括り方はともかく、このように多様化していく中では、 実装技術 + 基本業務知識 という話のできるプログラマタイプが、 もっとも適応し生き残っていくのではないかと思います。 | ||||||||||||
|
投稿日時: 2004-09-09 12:59
それぞれの知識レベル（業務知識、実装技術）が同じならどちらがやっても同じです。 ＃ 現実的には５０人のプログラマーが全員ヒアリングを受けるってなことはできない のでプログラマーのリーダーなり代表がやることになるのでしょう。でも役割とし て考えるとこれはＳＥと見ることもできます。 職業としてのＳＥとプログラマーの違いというのは（能力の優劣では無いですよ） 私は、「問題解決方法の指向性」だと勝手に思っています。 例えば、ＳＥとプログラマーが同時にヒアリングを受けたとします。 次に何をするか。 まず、現状業務をドキュメントなりにまとめたとして、新規業務を考えます。 その際にＳＥというのは、業務改善する内容を、他業務も含めて幅広い視点で、業務方法 改善側に指向して欲しいと考えます。（もちろん実装に関しての裏付けは必要ですが） ・このシステムが会社としてどういう位置付けか（もっと拡張される代物か） ・将来的にどういう業務に拡張していくのか ・システム導入によってもたらす効果は（もっと効果を出すには） というような事を常に意識して欲しい（いや自然とできて欲しい）ということです。 一方プログラマーはその業務をどういう実装方法 ・どんな言語を使うのがベストか ・どういうシステムを作ればうまく行くのか ・この業務で実装上困難な場所はどこか ・それを回避する実装手段は というような方向に目を向けていくのであろうということで、この違いというのが業務 知識が有る無いとかという次元じゃ無いと思っているわけです。 もちろｎ、プログラマーがこれを出来ないとか言っているのでは無く、プログラマーと しての役割・職業、ＳＥとしての役割・職業であれば常にそれを意識して、よりbetter な解答ができる能力が必要ではないかと思っています。その中に業務知識というものも 含まれますが、どこまで必要かというのは「あればあるほど有利」としか言い様が無い わけです。 現実の作業では、上記のプログラマーの指向というのがＳＥがやっているわけですが、 作業そのものはできる人がやれば良いというものでしょうかね。
業界というか在庫を抱える「商社」ですね。（商品によっても違いますが） って同時に立たないほうが普通だと思うのですが．．． | ||||||||||||
|
投稿日時: 2004-09-09 13:05
はにまるです。
なるほど出版業界は知らなかったので触り程度でしょうが、勉強になります。 私の「業種知識」「業務知識」の別け方は一辺倒の考えで 議論的に別け方が良くないと理解いたしました。自分の中にしまって置きます。 皆さんが使われている「基本的〜」とかの方がよさそうですね。 これは、皆さんに対する要望では無く、私が発言する際の注意点ですので、あしからず。 | ||||||||||||
|
投稿日時: 2004-09-09 13:27
基本設計確認の段階で、ちゃんと業務のシステム化範囲を明確にしていれば、(契約上の)不要な機能を削除すると言う判断は SE が行うことができますね。 …というのは理想論なんですが(言ってみただけ)。実際には、基本設計での未定義部分も多々あり、結局、設計・開発段階でユーザー確認を都度行うことになります。で、この未定義・矛盾部分というのがプログラマが実装設計・実装着手してから表面化することが多いんです。設計レビューでは見抜けない未定義や矛盾ってたくさんあるんです。これが、ウォーターフォール開発が適さない理由のひとつです。基本設計・詳細設計・設計レビューまで済んだのに、実装をはじめたプログラマに矛盾や未定義を見つけられちゃったら、どうするの？ これに対して、動くものを重視して(試行錯誤はするけど)システムを進めていくのが、アジャイル開発手法です。プロトタイピングを包括しているとも言えます。 ・契約交渉よりもユーザとの協調を重視する ・計画に従うよりも変化への対応を重視する ・包括的なドキュメントよりも動作するソフトウェアを重視する このようなアジャイル開発の要素は、完全にウォーターフォール開発の対極と言えるのではないでしょうか？ そして、連絡係としての役割しか果たすことのできない SE は、アジャイル開発の妨げにしかならないのです。 | ||||||||||||
|
投稿日時: 2004-09-09 13:35
# 脱線です。ごめんなさい。。
業務知識については言葉の定義が一致していないようですので控えます。 ただ、SEとプログラマの定義は、 プログラマ：技術力が高い・ヒアリングしない・立場（単価）が低い SE：技術力が低い・ヒアリングする・立場（単価）が高い というような@ITの？業界の？共通認識があるようで興味深いです。 自分的には、 プログラマ：（高度に訓練された）技術者。 SE：システム会社の会社員。入社したその日から。 という感じなのですが。 誰がどんなヒアリングをするか（必要か）はケースバイケースだと思います。 | ||||||||||||
|
投稿日時: 2004-09-09 14:01
いや、前提として SE は実装技術を持たないことになっていますから。 以下の「指向性」や「50人規模プロジェクト」の話は「役割としての SE」に 集約されると思いますので、もうコメントするのはやめておきます。
普通は同時だと思うのですが？ 「自分の売りと相手の買い」もしくは「相手の売りと自分の買い」の話ですよね？ 「自分の買い(仕入)と自分の売り(売上)」が同時でない、なんてのは良くあること、というか当たり前のことですよね。オークションでは何が違うのでしょうか？ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.