@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
SEが設計に関わってくれない
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-02-02 12:31
M所K技師の釣りですか?
| ||||||||||||
|
投稿日時: 2007-02-02 12:58
あれ、KNさんプログラマじゃないの?
SEが仕事してくれないからプログラマの俺が大変だ、って話かと思ってた。 | ||||||||||||
|
投稿日時: 2007-02-02 13:13
さっきいったん投稿したんだけど、KNさんって、もしかしてPGなのかしら、
と気がついたので削除したのです。 その心配もなくなったので、再掲しますね。
そんなに単純じゃないと思うんですけどね。 交渉ったって、首を縦に振って、右から左に移しているだけかもしれないし。 容易だって断言するのなら、一度、ご自身でやってみてはいかがですか? この上なくクソマジメではあるが、融通というものが一切利かないモノを 相手にするのも、結構大変ですよ。
この話し相手って誰なの? SEさんが相手にならないんでPGさん・・・ではなさそうですね。
PGさん、こんな切り捨てられ方されてるし。 KNさんが尊重していないだけなんじゃないの? | ||||||||||||
|
投稿日時: 2007-02-03 01:39
設計がどうなるかを踏まえて初めて判断できる利害というのもあるのですけどね。
プログラムの分からん人間にどうして工数が見積もれるのか不思議でなりませんが。 実際のモノを作るプログラマの質を評価しない →出来上がるモノの品質も高が知れている →長期視点で顧客に評価されない →短期視点で顧客をとっかえひっかえして金を絞って使い捨てという戦略 →落ちる評判は看板のはったりでカバー といった戦略で売り上げが上がるうちは続けるでしょうね。 経営側は利益が上がるなら今の図式でいいんじゃないの?という意見なのかも。 だとすればトップダウン式の改革も絶望的ということになりますね。 私はそういう仕事は相手にしない主義ですが…。 相手にしないという戦略が取れない事情もいろいろありそうですし。 | ||||||||||||
|
投稿日時: 2007-02-03 02:22
H製作所の技師さんだと早合点して茶化してゴメン。
この手の話はゴマンとあるんですが。SE/PGの仲たがいは内輪揉めなんでよね。 顧客から見たら, PM/SE/PGの区別はどうでもいいわけで、関係者の意識としては,顧客が満足するものを納品するという視点に立てば仕事の進め方がはっきりすると考えるのですが如何でしょうか。 上流工程のSEが職務をまっとうできないと判断すれば下克上もありだと考えますが過激ですかね? | ||||||||||||
|
投稿日時: 2007-02-22 17:54
SEに必要なスキルは、設計力ではなくて、交渉力ではないかと思います。
本来PGに必要とされるスキルが設計力だと思います。 どちらが偉いとかそういうのではなくて コミュニケーション力が大切になってくるのではと思います。 | ||||||||||||
|
投稿日時: 2007-02-22 19:50
・SEの最重要スキル 要求定義から外部設計、結合テスト設計 ・PGの最重要スキル 内部設計からコーディング、単体テスト設計 設計は外部と内部を分けて考えるべきだと思います。 で、外部設計まで出来た成果物が「システム仕様」ですね ・SEが責任を持つ成果物がシステム仕様 ・PGが責任を持つ成果物がプログラム で、最終的にエンドユーザーに届けるまでがPMの責任。 顧客エンドユーザーから見ると、PM以下全て「製造元」。 経験上、システム設計を外部・内部をいっしょに考えている企業には 不安を感じます。 | ||||||||||||
|
投稿日時: 2007-02-22 22:57
SEが〜、PGが〜という話をするときは、「SE」「PG」という
定義のあやふやな語の定義を決めてからしましょう。 前提をあわせずに話をしても無駄です。 ひとつの重要なポイントは「役職がSE」なのか「役割がSE」なのかですね。 役職SEなんて会社個別の定義なんでこういったパブリックな場で議論する意義はないですね。 役割としてのSEの内訳も万人に同意を得られる線引きができないのですが、 仕様策定・交渉などがSEの仕事とされるケースが多いのかな? 経験上、SEが外部設計をするのにプログラミングの知識が不要だと 考えている企業には不安を感じます。 |