アカウント名:
パスワード:
プロジェクトマネージメント手法は勉強すればある程度身に付きます。そういう知識は無いよりあったほうが良いですから、知らない人はPMBOKを勉強すればスキルはアップすると思います。 ＃各自の経験から暗黙知の形で取得している場合もおおいでしょうが。
ただ、PMBOKは所詮プロジェクトマネージメントの一般論。現実の所謂「ITシステム」のプロジェクトマネージメントの難しさは、正確な見積もりの難しさ、進捗が見えにくいこと、タスクとリソースの相関が強い上に分散が大きい(途中で担当者を変えることの影響が大きい。そもそも、仕事と人間の組み合わせによって、かかる時間や出来たものの品質が大きく異なる)ことなどがあると思います。
結局プロジェクトマネージメントって、最初に目的をはっきりさせて、その実現のために必要なリソースを見積もって集め、あとはそれらを納期を見据えながら成果物に置き換えていく、という作業だと思っています。ところがこの業界、「必要なリソース」「納期を見据えながら成果物」の両方ともに誤差が大きいのですから、単純にPMBOKを知っているだけのレベルではどうにもならないでしょう。
加えて、現実問題としては、肝心の「目的」があいまいだったり、無茶苦茶な納期とリソースの組み合わせをごり押しする「ステークホルダー」の存在が困難に拍車をかけたりする場合も少なくないようですが、これは業界固有の問題かどうかわかりませんね。
結局、「PMBOKもいいけど人月の神話 [amazon.co.jp]もね」って感じ。 ＃一応PMP資格保持者としてID
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
CMMIとPMBK (スコア:3, 興味深い)
学生は，システム構築に必要な知識を大学でほとんど学んでいない。
中国の学生にはCMMIやPMBOKが半ば常識なのに，日本の学生の多くは名前さえ知らない。"
これは、学生に留まらず、業界の実態でもあると思います。
その結果、IT業界内でも、プロジェクト運営に対する理解が、
単なる経験則や、駄本由来の偏った知識だけになりがちで、
意志疎通や、全体計画の立案や改善の際にも、大きな妨げになっています。
第一、生産性も顧客満足度も向上しないし。
ほんと、コンピュータの技術知識だけあってもダメなんですよぉー。
その技術知識を"社会化"するための普遍的なモデルやメソッドを
身に付けていてこそ、技術者として一人前だと私は思っています。
Re:CMMIとPMBK (スコア:2, おもしろおかしい)
「configure ; make ; make install」
の略かと思いました。
#あほ杉なので、AC
Re:CMMIとPMBK (スコア:1)
Re:CMMIとPMBK (スコア:1)
勉強になりました。
ありがとう！
Re:CMMIとPMBK (スコア:0)
大丈夫です。
大きなコンサル会社やソフトハウスでも、外資じゃなければ知らない場合は多いですわ。
CMMは少しは知っていても、まずPMBOKやP2Mはほとんど知られてませんな。
学生のころからそちらの知識をつけておけば、応用は広いと思います。
ちなみに、そういうことを知っているのはなるべく隠さ
Re:CMMIとPMBK (スコア:1)
とか言っておけばハッタリが効くという事でよろしいか。
# 実戦は未経験の気楽な学生なのでID
Re:CMMIとPMBK (スコア:0)
>とか言っておけばハッタリが効くという事でよろしいか。
銀行への就職試験で面接かなんかにこぎつけたら、そういう事を言って、面接官の乱暴な発言を誘えたならば就職できますよ
# ちなみに後半は実話^^;;
# 銀行の悪口を言われないためだそうで…
Re:CMMIとPMBK (スコア:0)
そんな連中の反対につぶされる程度の説得力しかないヤツには
導入そのものが無理(w
Re:CMMIとPMBK (スコア:0)
・・・いつの間に、こんな大げさなお題目が付くようになったんだ(w
確かにメソッド化すればバカでも使えるような幻想を持たせられるけど・・・。
Re:CMMIとPMBK (スコア:0)
エンジニアとして大事なのは、自分の仕事に必要になったときに、
それにすぐに対応できるかどうかだよな。
「トレンドをいち早くつかんで」なんてやってるようでは、
正直仕事なんてできません。
Re:CMMIとPMBK (スコア:0)
どっちかに偏った主張は建設的じゃないよな。
Re:CMMIとPMBK (スコア:0)
ただ、知っているだけの知識は知らないより性質が悪いと思うけどね。
特にPMBOKは今までのプロジェクトマネジメントの集大成に過ぎないから、
追加して覚える必要がない人には本当に要らない知識だし、
結局思想として周りに広めることが出来なければ単に現場を混乱させるだけの存在だし。
必要な知識を持っていること、
そしてそれを効率的
Re:CMMIとPMBK (スコア:1)
>追加して覚える必要がない人には本当に要らない知識だし、
うーん。たぶんこれはデザインパターンと同じようなものなんじゃないかと。
つまり過去の知識の集大成なりなんなりに「名前を付ける」ことで
知識を運搬し易くする効果を狙う、っていうあれ。
PMBOKについては知らないので、(Globalな)名前をつけてまで
広めるに値するものなのか、それとも一部企業の煽り文句(笑)に過ぎないのかは、
俺は知りませんが。
>結局思想として周りに広めることが出来なければ単に現場を混乱させるだけの存在だし。
まあ、それ言ったら、なんだってそうなんですよね。
「K&R読めよ。ANSI Cの基本くらい覚えとけよ。」と言っても
「そんなこと、ワタシタチのレベルじゃ、ついてけません。無理です。」と答える奴もいる。
＃じゃあC使うなよと小一時間思うのだが、Systemが要求する開発言語がCなんだよね。
＃というか、そもそもそんな奴らProjectに入れるなよなと小一時間思うんだが、
＃べつに俺に人事権が有るわけでもないんで。こんな奴らの「ほうが多く」ても俺には手の出しようがない。
＃おかげで、似非ANSI Cなコードが数十万行蓄積しちまってる…(T_T)
＃え？数十万は多いって？そうでもないよ。数千行の関数が百本あれば到達するっしょ(T_T)
「必要なもの」や「良いもの」については、
「俺^Hソレに付いて来い！来れない奴ぁ首だ！」とか言う、という手もアリなんだとは思います。
シゴトなのならば、足切りラインが存在してもおかしくないはず。
ただ、本当にそう言うに値するほどの「もの」なのかどうかが
なかなか見極められないことは、多いですけど…
＃銀だなんて贅沢は言わない。普通の鉛の弾丸でもいいから欲しいのでG7
＃だって、それすら不足してるんだもん(T_T)
>＃その本質を理解せず運用しようとするPMP資格保持者のなんと多いことか…。
間違った意味の安心感 [bluegate.org]という言葉が有るようです。
これ、その「資格」の問題と似てますね。
資格を取れば最終的な実務に役立つ、という間違った安心感を抱いている人が、きっと多いんだろうなあ…
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
＃むしろワイワイやってるほうが、「仕事についてワイワイ」やってるわけだから、彼らの脳が仕事にきちんと向きあってることや
＃少なくとも脳が活性状態にあることが、保証されるんだよね。
＃お行儀の良さが優れたコードを産むわけじゃないんだよな。
＃俺の身近では、行儀に五月蝿い奴ほど設計や実装が糞です(藁
相手は(恐らくまだ若くて色々なものを「素直に」吸収してしまう)学生さんなのですから、
何を教えても「納得」してしまうんじゃないでしょうか。
つまり極端な話、間違ったことでも納得してしまいかねん。
教えるときには、いかに「正しい」ことを教えるか？は、重要だと思います。
教えればなんでもいいってわけじゃない。