アカウント名:
パスワード:
プロジェクトマネージメント手法は勉強すればある程度身に付きます。そういう知識は無いよりあったほうが良いですから、知らない人はPMBOKを勉強すればスキルはアップすると思います。 #各自の経験から暗黙知の形で取得している場合もおおいでしょうが。
ただ、PMBOKは所詮プロジェクトマネージメントの一般論。現実の所謂「ITシステム」のプロジェクトマネージメントの難しさは、正確な見積もりの難しさ、進捗が見えにくいこと、タスクとリソースの相関が強い上に分散が大きい(途中で担当者を変えることの影響が大きい。そもそも、仕事と人間の組み合わせによって、かかる時間や出来たものの品質が大きく異なる)ことなどがあると思います。
結局プロジェクトマネージメントって、最初に目的をはっきりさせて、その実現のために必要なリソースを見積もって集め、あとはそれらを納期を見据えながら成果物に置き換えていく、という作業だと思っています。ところがこの業界、「必要なリソース」「納期を見据えながら成果物」の両方ともに誤差が大きいのですから、単純にPMBOKを知っているだけのレベルではどうにもならないでしょう。
加えて、現実問題としては、肝心の「目的」があいまいだったり、無茶苦茶な納期とリソースの組み合わせをごり押しする「ステークホルダー」の存在が困難に拍車をかけたりする場合も少なくないようですが、これは業界固有の問題かどうかわかりませんね。
結局、「PMBOKもいいけど人月の神話 [amazon.co.jp]もね」って感じ。 #一応PMP資格保持者としてID
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
CMMIとPMBK (スコア:3, 興味深い)
学生は,システム構築に必要な知識を大学でほとんど学んでいない。
中国の学生にはCMMIやPMBOKが半ば常識なのに,日本の学生の多くは名前さえ知らない。"
これは、学生に留まらず、業界の実態でもあると思います。
その結果、IT業界内でも、プロジェクト運営に対する理解が、
単なる経験則や、駄本由来の偏った知識だけになりがちで、
意志疎通や、全体計
Re:CMMIとPMBK (スコア:0)
ただ、知っているだけの知識は知らないより性質が悪いと思うけどね。
特にPMBOKは今までのプロジェクトマネジメントの集大成に過ぎないから、
追加して覚える必要がない人には本当に要らない知識だし、
結局思想として周りに広めることが出来なければ単に現場を混乱させるだけの存在だし。
必要な知識を持っていること、
そしてそれを効率的
Re:CMMIとPMBK (スコア:1)
プロジェクトマネージメント手法は勉強すればある程度身に付きます。そういう知識は無いよりあったほうが良いですから、知らない人はPMBOKを勉強すればスキルはアップすると思います。 #各自の経験から暗黙知の形で取得している場合もおおいでしょうが。
ただ、PMBOKは所詮プロジェクトマネージメントの一般論。現実の所謂「ITシステム」のプロジェクトマネージメントの難しさは、正確な見積もりの難しさ、進捗が見えにくいこと、タスクとリソースの相関が強い上に分散が大きい(途中で担当者を変えることの影響が大きい。そもそも、仕事と人間の組み合わせによって、かかる時間や出来たものの品質が大きく異なる)ことなどがあると思います。
結局プロジェクトマネージメントって、最初に目的をはっきりさせて、その実現のために必要なリソースを見積もって集め、あとはそれらを納期を見据えながら成果物に置き換えていく、という作業だと思っています。ところがこの業界、「必要なリソース」「納期を見据えながら成果物」の両方ともに誤差が大きいのですから、単純にPMBOKを知っているだけのレベルではどうにもならないでしょう。
加えて、現実問題としては、肝心の「目的」があいまいだったり、無茶苦茶な納期とリソースの組み合わせをごり押しする「ステークホルダー」の存在が困難に拍車をかけたりする場合も少なくないようですが、これは業界固有の問題かどうかわかりませんね。
結局、「PMBOKもいいけど人月の神話 [amazon.co.jp]もね」って感じ。
#一応PMP資格保持者としてID
Re:CMMIとPMBK (スコア:1)
#こちらにぶら下がるのが健康的かな
さっきOn Lisp邦訳 [u-tokyo.ac.jp]なるものが有るのに気付いて見始めたんですが、
これの冒頭に、こんな一文がありました。
「ボトムアップ・デザインは,ソフトウェアがどんどん複雑化していく中で一層重要になってきている.現代のプログラム
は,とてつもなく複雑だったり,ときには解釈が定まらないような仕様を満たさなければならない.そのような状況では伝統
的なトップダウン方式が破綻してしまうことがある.そこで,現在のほとんどのコンピュータ科学講座で教えられているの
とは大変異なったプログラミング手法が発達した:ボトムアップ・スタイルだ.」
これを見て思い出したのが今回のスレッド。
PMBOKの中身を全く知らないんでアレですが、もしかしてこれは(も)、
トップダウン方式の一種、だったりはしないのかな?と、ふと思ったです。
#というわけで、以下、矛先はPMBOKではなくトップダウンです(^^;
「ほとんどのコンピュータ科学講座で教えられている」という部分に引っかかったんです。
つまり、ボトムアップとかアジャイル(^^;とかについては、もしかして
「あっちの国でも、まだロクに教えられてなかったり」するのかな?と思いまして。
PMBOKのことは判りませんが、トップダウン一般について自分の印象を言わせて貰うなら、
「ちょっと間違えば、建前論のインチキをごり押しするだけになってしまう。
しかも、この間違いを回避するのは、なかなか困難である」という感じなもんで、
もし「学生さんに、本当に役立つプログラムの作り方」を教えたいというなら、
トップダウンの暗部についても正しく教えて欲しいなー、そうでないならイカサマだなー、
「役に立たない」なー、と思ったんです。
#トップダウン神話に汚染された上司にゴマするための役には、たつかも知れませんが(笑)>トップダウンのみ習得
アジャイルとかでも正に、「事前見積もりの困難さ」を打破(回避?)するために、
事前見積もりにあんまり依存しないようにする、というヤリカタを薦めているわけです。
アジャイルがどこまで素晴らしいかはさておき、少なくとも「事前見積もりは困難だ」
という感覚は、もうビンビン実感してます。たぶん皆さんが実感してるんじゃないかな。
つまりそれはきっと「事実」なんだろうなと。
そんなヤリカタも有るんだ、と感心していた矢先(^^;に、
今回のトピで参照されてるページのように「契約や仕様書作成の大切さが身にしみた」
なんていう呑気なことを学生さんに言われたのでは、
それじゃあっちの国々の数年前までの状況の後追いに過ぎないよ、と不安になってしまったのです。
せっかく下地が無い(笑)んですから、悪い部分(笑)は一気に飛び越えて、
最新のヤリカタに飛びついてみる、ってのはどうだろう?と思いました。
無保証ですが(笑)、ああいう学生さんたちに俺がお勧めしたいなあと思う学習内容は、
アジャイルつーか「本音」ベースの開発、だったりします。
建前で押し潰されそうになること「を」教えるのって、現実という意味では意味が有るにしても、
あまりにも悪現実すぎて、なんか教えるのも忍びないというか馬鹿馬鹿しいというか。
#開発部屋が「静か」だったら、その職場は警戒(成果物の品質に対して疑う)に値する、と何処かで聞いた記憶があるのでG7
#むしろワイワイやってるほうが、「仕事についてワイワイ」やってるわけだから、彼らの脳が仕事にきちんと向きあってることや
#少なくとも脳が活性状態にあることが、保証されるんだよね。
#お行儀の良さが優れたコードを産むわけじゃないんだよな。
#俺の身近では、行儀に五月蝿い奴ほど設計や実装が糞です(藁
相手は(恐らくまだ若くて色々なものを「素直に」吸収してしまう)学生さんなのですから、
何を教えても「納得」してしまうんじゃないでしょうか。
つまり極端な話、間違ったことでも納得してしまいかねん。
教えるときには、いかに「正しい」ことを教えるか?は、重要だと思います。
教えればなんでもいいってわけじゃない。