ＭＶＣはＰＭが知らなくても良い細かい技術ですか？

投票結果総投票数：201
当然知ってる	59票	29.35%
知ってた方が良い	82票	40.80%
準備で調べてるはず	5票	2.49%
ＰＭは知らなくても良い	38票	18.91%
お客さん次第	5票	2.49%
その他	12票	5.97%
投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。

投稿者

投稿内容

rain: ぬし; 会議室デビュー日: 2006/10/19; 投稿数: 549

投稿日時: 2007-03-14 12:49

設問につけたタイトルの意図がわからなかったので、投票していません。
もしスレ主さんが「細かい技術なら知らなくてもいいけど、ＭＶＣは細かくない概念だよね？
だから、知らなくてもいいなんてことはないよね？」
という考えでつけたタイトルなのだとしたら、私はたぶん「スレ主の考えは間違っている」と言っちゃうと思います。
そんな意図でなかったらごめんなさい。
私が曲解していますので、もうちょっと詳しく目的を教えてください。

あと、「知っている」の中身にもよるのだとも思いました。
ただ用語を聞きかじっただけのＰＭさんよりは、まったく知らないＰＭさんのほうが私の中ではありがたいです。
ＭＶＣはすばらしい、ＭＶＣでなくちゃいかん、必ずＶとＣを分離しなきゃいかん、とかいうＰＭさんがいたら、
私の中では最悪に分類しちゃいます。
ＭＶＣの概念を知っていて、それを製造する人にも教えることができて、
でもそれをどう活用するかは製造する人たちに任せてくれる…
そんなＰＭさんがもしいたら、私の中では最高かもしれません。

でも私は、今までご一緒したＰＭさんにＭＶＣを知っているかどうかをわざわざ聞いたりしませんし、
これからもたぶんしないと思いますので、上に書いたようなＰＭさんは全て私の空想です。

さる: ぬし; 会議室デビュー日: 2005/07/14; 投稿数: 276; お住まい・勤務地: 実家戻ったｗ

投稿日時: 2007-03-14 13:35

引用:
未記入さんの書き込み (2007-03-14 12:49) より: 設問につけたタイトルの意図がわからなかったので、投票していません。

申し訳ありません、タイトルだけでは細かい意図は伝わりませんよね。
もう少し分かりやすいタイトルだとどういった形にすれば良かったと思いますか？

引用:

もしスレ主さんが「細かい技術なら知らなくてもいいけど、ＭＶＣは細かくない概念だよね？
だから、知らなくてもいいなんてことはないよね？」
という考えでつけたタイトルなのだとしたら、私はたぶん「スレ主の考えは間違っている」と言っちゃうと思います。
そんな意図でなかったらごめんなさい。
私が曲解していますので、もうちょっと詳しく目的を教えてください。

前半部分の
「細かい技術なら知らなくてもいいけど、ＭＶＣは細かくない概念だよね？」
は私の意図とは合っていますので問題ありません。

ただ、後半部分は
「だから、知らなくてもいいなんてことはないよね？」
は、私の考えとは違いますね。
知らなくて良い人は知らなくて良いと思いますよ。
ただし、
そのプロジェクトで必要なら知ってなきゃいけないんじゃないの？
必要なら準備段階で調べなきゃいけないんじゃないの？
というのが私の思ってる事ですから。

とりこん: 会議室デビュー日: 2007/03/13; 投稿数: 4

投稿日時: 2007-03-14 13:38

知ってた方が良いに１票

ＰＧ作業をしないのならＭＶＣ自体は知らなくてよいかもしれません。
でもＭＶＣを知らなくてよいかどうかは知らなければ解らないでしょう。

日々の作業をこなしながら新しい用語や技術を全部解れっても無理です。
でも常に解らないことを勉強することは立場に限らず必要ですよ。

ぶさいくろう: ぬし; 会議室デビュー日: 2005/11/22; 投稿数: 1232; お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）

投稿日時: 2007-03-14 13:44

知ってた方が良いとＰＭは知らなくても良いの選択肢が微妙。
知らなくても良いだと知ってても良いも含むんじゃない？
知ってた方が良いがあるなら知らない方が良いの方がいい。

それか知っててもいい。知らなくてもいい。かな。

Gio: ぬし; 会議室デビュー日: 2003/11/28; 投稿数: 350; お住まい・勤務地: 都内から横浜の間に少量発生中

投稿日時: 2007-03-14 14:30

nagiseさんの書き込みに尽くされてしまった気もしますが、プロジェクトの構成に依存するので「その他」に投票しました。

プロジェクトマネジャ、アナリスト、アーキテクトを完全に分離して別チーム（1チーム一人の場合もある）とできるならば、技術面はアーキテクトが率いるチームに任せ、アナリストは顧客要件の獲得（ただし技術的な実現難度はアーキテクト、実現コストはプロジェクトマネジャと相談）、プロジェクトマネジャは管理（難度と人員配置はアーキテクト、実現する顧客要件の絞込みと顧客提案はアナリストと相談）に専念すれば良いでしょう。
この場合、アーキテクトが「MVC に基づいて開発担当を分けると並行して作業を進めやすい」と言ってくるかもしれません。プロジェクトマネジャは「MVC というシステム構成方法の土台があって、それを使うと担当を分けやすい」くらいの認識で十分です。

けれども一部や全部を兼任しなければならない場合も多々あります。
プロジェクトマネジャがアーキテクトを兼務する場合は、技術面も知っていないとダメでしょう。

ognac: ベテラン; 会議室デビュー日: 2005/06/21; 投稿数: 65

投稿日時: 2007-03-14 14:33

投票:その他
OSI参照モデルの階層は,他の階層を情報をブラックボックスな物として対応しているので階層間の区切りは上下関係の役割分担です。
反対に,
ＭＶＣ(モデル,ビュー ,コントロール) や3階層アーキテクチャ (ユーザーサービス , ビジネスサービス ,ビジネスロジック)は (「いずれの切り口もデータの処理の役割を分離分割するもの.. という視点でおなじようなもの」と考えています。)
はインターフェースで結ばれる対等な役割分担です。
　PMの仕事はJOBの配分と管理でもあるので, 構成員のJOBの役割分担を適切に分割能力が必要と考えています。　構成員同士のインターフェースをPMがするのか,インターフェース要員を配置するのかは不問にします。
仕事の役割を分割するのと, データ処理をMVCに分割するか, 3階層に分けるかは,本質的に同じ能力だと考えています。
　その意味で, PMは MVCという文言は知らなくても, 能力として備わっているべき物でしょう(実態は願望ですが)
OSIモデルを初っ端に出したのは, 水平の役割分担を, 上下関係の役割分担だと勘違いしている、PMさんが散見するからです。
PL/SE/PG を上下関係で区分けし,下流に皺寄せを持っていくのが常態化してます。対等であり役割の差でしかありません。(この理解すら得られない時が有りますが)
その意味からも, PMは MVCの本質を認識すべきと考えます。
　業務分析段階では,この手の知識が無いほうが旨く分析できたりします。(前提条件:実装に口出ししない)

免許のない車のセールスマンや,甘いものが嫌いな和菓子屋さんは嫌です。

_________________
ognac＠わんくま同盟

よねＫＥＮ: ぬし; 会議室デビュー日: 2003/08/23; 投稿数: 472

投稿日時: 2007-03-14 15:34

引用:
Gioさんの書き込み (2007-03-14 14:30) より: けれども一部や全部を兼任しなければならない場合も多々あります。プロジェクトマネジャがアーキテクトを兼務する場合は、技術面も知っていないとダメでしょう。

こういう状況があることはよくわかります。
ただ、プロジェクトマネージャもアーキテクトも役割で、
「技術面も知っていないとダメ」なのはアーキテクトとして、ではないでしょうか。（つまり、プロジェクトマネージャは知らなくても良い、になるのかなと)

同じく”その他”にした私ですが、再度読み直してみて何故”その他”にしたかを考えると
PMは知らなくても良いよねと思いつつも、知っているにこしたことはないと思っているから、
「ＰＭは知らなくても良い」「知ってた方が良い」とでうまく選択肢を選べなかったということだと思いました。
＃ぶさいくろうさんの指摘の通りだと思います。

[ メッセージ編集済み編集者: よねＫＥＮ編集日時 2007-03-14 15:37 ]

Jitta: ぬし; 会議室デビュー日: 2002/07/05; 投稿数: 6267; お住まい・勤務地: 兵庫県・海手

投稿日時: 2007-03-14 15:49

PM ってなにさ？

プロジェクト・マネージャ
プロダクト・マネージャ
プログラム・マネージャ
プロジェクト・メンバー
ポール・マッカートニー（ぉぃ
_________________

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

ＭＶＣはＰＭが知らなくても良い細かい技術ですか？

スキルアップ／キャリアアップ（JOB@IT）