@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
MVCはPMが知らなくても良い細かい技術ですか?
投票結果総投票数:201 | |||
---|---|---|---|
当然知ってる | 59票 | 29.35% | |
知ってた方が良い | 82票 | 40.80% | |
準備で調べてるはず | 5票 | 2.49% | |
PMは知らなくても良い | 38票 | 18.91% | |
お客さん次第 | 5票 | 2.49% | |
その他 | 12票 | 5.97% | |
|
投稿者 | 投稿内容 | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-03-17 14:58
因果関係で考えれば、何千、何万あるコンピューター用語のひとつである MVC を知っていたところで、プロジェクトマネージャーの仕事のメリットになるとは思えません。
しかし、良い仕事ができるプロジェクトマネージャーなら、著名なフレームワークである struts などでも登場する、(狭義の言葉としてだけの) MVC という言葉の存在を知っているはずなのではないでしょうか。もし、知らないとしたら MVC 以外のその他の技術的な知識も持っていない確率は高いでしょうし、そうだったら技術的な問題に対する意思決定は満足にできないので、ちゃんとした仕事はできないでしょう。 しかし、プロジェクトマネージャーに技術的な補佐役が別に付いているのならば、話は違います。技術的な役割と政治的な役割を分けているわけですから。タレント議員や知事のように。 -- unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86} | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-17 22:10
必須に投票しました。
PMの定義があいまいですが、MVCが細かい知識かどうか?でみると、 根本原理だとおもうので知っていて当然かと。 スタッフの勤怠とメンタルケアするだけのPMにはいりませんが。 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-17 23:11
久しぶりに投稿します。
知らなくていいに投票しました。 現在、自分が所属しているプロジェクトではPMはおそらく知らないし、 それでもプロジェクトは円滑に進行しています。 それに知っていないことで、問題がおきるのであれば 自分が知っていることで、そこを補うことが可能だと考えます。 プロジェクトの目的がMVCに基づいたシステムを作ることであれば知っていてほしい知識だとは思いますが、 プロジェクトの目的達成のために、必要な知識かどうかと考えると*必ずしも*知らなくていいかと。 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-17 23:22
すでにまいるどきゃっとさんが回答を出されてますが、 ただ単に俺が疑問に思ってた時の単語がMVCだったというだけなので MVCという単語自体には何も意味がありません。 まあ、正確に言えば私自身の基準ではMVCは技術というより概念という意識なので 細かい技術と組み合わせでMVCという単語が出てきたので疑問に思っただけですよ。 出てきた単語がもっと細かいプログラミングやインフラに特化した単語だったらスレを作らなかったと思います。 > 加納正和さん 私の返信の時にも書いてますが、 加納正和の意図とはまったく関係ありませんのでお気になさらずに。 まあ、ただのそういうタイミングだったというだけですから。 MVCなんて知らなくても良いプロジェクトがある事は理解しておりますし、 それはそれで全然問題ないと思います。 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-18 01:46
何でこんなにみんな違うポイントから意見を言うのかと思ったら、設問がいまいち曖昧だったんだ。
「MVCはPMが知らなくても良い細かい技術ですか?」 1)MVCは技術か否か 2)MVCは細かいのかそうでないのか 3)PMはMVCを知らなくてはならないかどうか さらに、 4)「プロジェクトマネージャ」はロールかタイトルか 蛇足で、 5)「プロジェクト」は情報システム構築プロジェクトに限るのか 最後に挙げた曖昧さは、ここが@ITだということで実質的な問題にはならんでしょうが。 [ メッセージ編集済み 編集者: カーニー 編集日時 2007-03-18 01:57 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-18 03:39
私は「当然知ってる」に投稿しました。 技術か否かということですが、技術としての側面もありますが、開発の技法としての 側面もあると思います。技術か否かと単純に割り切れないと思います。 細かいか細かくないのかというよりも、プロジェクトへの影響の度合いが大きいか どうかということを考えました。 その大きさの度合いからして、PMにとってもMVCは知るべき要素と判断しました。 MVCという、アルファベット3文字の、最近出てきた用語なのでわかりにくいと思いますが これを製造業における「カイゼン」に置きかえると理解しやすいと思います。 これをまともにやろうとすると非常に細かいです。しかし、工場長が「技術的な ことは技術の人間がやれば良いことだ。俺は管理だけしか知らん」といって カイゼンのカの字も知ろうとしないとしたらどうでしょう? もちろん、カイゼンを知らなくても工場は稼動します。納期が迫っているものに 関しては工場を24時間フル稼働させればなんとか間に合います。でも、ちょっと 頭を使って、工場内をぐちゃぐちゃにしないで整理できるものをあらかじめ整理 しておいたらどうでしょう? ではIT業界ではどうでしょう?たとえば担当者がいなくなったら、何がどこにあるか わからなくなってしまうというのが現状ではないでしょうか?見積を出すのに 平気でどんぶり勘定でやっているのではないでしょうか?コンピュータ自身の 難解さに加えて、複雑さを極める開発の現場において、少しでも余計な工数を 減らし、工夫できるものは工夫する時期がきているものと思います。 その工夫のうちのひとつがMVCであると考えます。じゃあPMは管理もやった上で そんな細かいことまでできなければならないのかという疑問ももちろんあると 思いますが、MVCを使ったプログラミングは出来なくても良いです。ただ、MVC のことを知っているのと知らないのとではプロジェクトの見積/進行に違いが 出てきます。たまに、自分の不勉強を棚に上げて「俺の判らないことをやるな」と 阻止するPMがいますけれど、これだけは勘弁してもらいたいですね。 | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-18 23:43
MVCってそんなに大事なんですか?さっと読んで階層化概念の1技法である事は理解しました。
私は階層化概念の話は出来ます。そこで技術として階層化概念の重要性を訴えつつも、人的組織の階層化概念を無視するような意見に理解が出来ず、前の投稿では揶揄した表現を用いました。しかし、その後も私には理解し難い意見がでていますので教えてください。 まず階層化概念を用いる場合は、適用組織に対し適正規模が求められます。これはMVCも例外ではないでしょう。殆どの階層化技術は小さいプログラムに適用すると、コストが増え、可読性が落ち、不具合率の増加などデメリットばかりが出てきます。 次にプロジェクトマネージャーという役割を個別に定義する必要性に迫られた組織規模とはどの程度を想定しているのでしょうか?話の内容からするとシステムエンジニアやITアーキテクチャーが話しにあがらず、プログラマーとプロジェクトマネージャーが客前で同席する話まであがっていますよね?他の役割を兼任しているPMを話に含めているのでしょうか? 確かにPM兼SEならばMVCは知っておいた方がいいと思いますが、それはSEとしての話になりますよね? MVCの話はシステムエンジニアやITアーキテクト等の設計担当者がすればいいし、それがプロジェクト運営に密接に繋がるならば、プロジェクトマネージャーにその必要性と組織運営への影響を技術表現を用いずにコミュニケーション能力を要求される設計担当者なら説明ができるはずです。 人的組織構造では階層化概念を否定し、ソフトウェア構造では階層化概念を肯定する、そこの差とは何でしょうか? 私は例えプロジェクトマネージャーであっても、プログラマーが判断すべき役割に対し口を出すべきではないと考えていますが、開発者の用語を理解して欲しいと望む理由は何でしょうか?私には内部変数名をグローバル変数化し参照・更新行為を推奨しているような話に聞き取れます。 [ メッセージ編集済み 編集者: はにまる 編集日時 2007-03-19 00:05 ] | ||||||||||||||||||||||||||||||||
|
投稿日時: 2007-03-19 00:13
webアプリにしろ、階層C/Sにしろ、 必要な概念でしょうね。 メンテナンスを容易にするものです。 PMの立場でプロジェクトを回す上で、 メンテナンスを考えていないって言われてるような気がしてます。
必要性を認識していない以上、議論しても無駄でしょう。 認識の問題です。 地球が温暖化してますが、二酸化炭素を抑えましょうって言われて、 いやなんで?って人と、 よし、やろうって人の違いでしょう。
Strutsを用いればフレームワークが強制的にMVCを要求するものです。 まぁ、そもそも、MVCやりやすいようにするためのフレームワークなワケですが。 誰でも用意に修正できるって言う目的があるからです。 作って作りっぱなしにするプロジェクトなら別に必要のないものです。
認識レベルで言葉が混同しているとスレの半ばで出ている以上 言葉の定義をしないで議論を進めるのはナンセンスだと思います。
メンテナンスを見込まないプロジェクトならばどうでもいいでしょう。 そのプロジェクトだけで終わりだって宣言なら別に何でもいいんじゃないですか? なぜMVCが必要か? そこが議論の出発点だと思います。
適用範囲が広すぎて、規約と同等なんですよ。 守られればメンテナンスしやすい。 でも、そうすると、無駄にコストがかかりやすい。 人も厳選して雇わなければいけない・・・等ね。 やりたくないなら、やりたくないって宣言しておくのもひとつの手でしょう。
人的組織構造では役割を振られた人が役割をこなしていないからです。 ソフトウェアは役割を与えれば役割をこなします。 そこに違いがあります。 能力がない人でも、役職って肩書きが有れば、組織なんですよ。 能力のない人を上に抱いて仕事することの苦痛をご存じないわけではありますまい。
誰が定義するのですか? 上位職種が下位職種を定義しいない・・・できない以上、 下位職種が現場を取り仕切るようになります。 それに対して、何でといわれても、会話すら成立しないと思いますがいかがでしょう? |