アカウント名:
パスワード:
元記事カケラも見ずに言ってませんか? 例えばバッファを入れたスケジューリングに関しても、元記事から一部抜き出してもこの程度は書かれています。
あらためて荒木氏は，「ドラゴンクエストX」でのマネジメントの取り組みにおいて，2種類のリスクヘッジのためのバッファ管理を行ったと話す。すなわち，スタッフ作業のリスクヘッジとしてのイタレーションごとのバッファ管理と，プロジェクトのリスクヘッジのためのロードマップ上のバッファ管理である。とはいえ，バッファの過不足が生じないよう，予測と見積もりをしっかり行わなければならない。今回の件では，とくにロードマップ上のバッファの見積もりについて，経験則に頼らざるを得ず，どちらかというと不足気味だったとのことで，荒木氏は，より精度を高めることが今後の課題であると話していた。
あらためて荒木氏は，「ドラゴンクエストX」でのマネジメントの取り組みにおいて，2種類のリスクヘッジのためのバッファ管理を行ったと話す。すなわち，スタッフ作業のリスクヘッジとしてのイタレーションごとのバッファ管理と，プロジェクトのリスクヘッジのためのロードマップ上のバッファ管理である。
とはいえ，バッファの過不足が生じないよう，予測と見積もりをしっかり行わなければならない。今回の件では，とくにロードマップ上のバッファの見積もりについて，経験則に頼らざるを得ず，どちらかというと不足気味だったとのことで，荒木氏は，より精度を高めることが今後の課題であると話していた。
このような内容ですが、「まるで語られていない」は当てはまりますか?
前のコメント見ても元記事を見ていないのでしょうか。言っている内容についても元記事にあるように見えますが。
発表内容に本当に興味があるなら「ゲーム系サイトによるレポート」ではなく、現場で聞けというような話ではないでしょうか。 ゲーム系サイトという点を踏まえると割と突っ込んで書かれているように思えます。
また、糊代は基本的に強度確保の上で多少の余裕をもって用意するものです。 通常糊代部分に万遍なく糊を塗ること、糊代から糊がはみ出たりしない様、適切に糊を塗ることなどは想定されておらず、貼り付けた際に糊が広がることを想定して糊代部分は余裕をもった空間を用意することが基本です。 糊代は余るものであって、糊代余りませんでしたというのはぎりぎりの設計であり、余裕がなくよろしくない設計です。
そこから広がった言葉の意味としても、糊代は余裕を表すもので、糊代が余るのはダメ = 余裕があってはいけないという事となります。 余裕 (糊代) は不要というのは、リスク管理上致命的な問題がありませんか。
でもさ、糊代だってタダじゃないんだから、必要以上にでかい糊代でしたという状況が許容される現場ばかりじゃないでしょ。
糊代の最適化のポイントはなに？ってことかと。
＃何を捨て、何を死守したかの考え方は記事中に含まれてるけどね
「糊代を投入する」という表現は初めて見たな
プロジェクト目標や成果物を予め「緻密には」定義できない、というのはアジャイル開発の一つの出発点で、だからこそ小刻みに計画策定とチェックを繰り返すことで大幅な計画変更や手戻りを避けるわけですよね。
乱暴にいえば、「数年にわたるようなプロジェクトは管理しきれないけど、1週間くらいの計画なら目で見て管理しきれるし、それを繰り返していけば、結局トータルの成果は大きいよ」というのも一つの考え方です。
あなたのいう「プロジェクト管理」の定義がわからないと、なにが「素人」で「苦労がない」のかよくわかりません。
> プロジェクトの目標や成果物をあらかじめ決められない> 人にプロジェクトは任せられません。> 仕上がりは出来てからのお楽しみじゃ、話になりません。
これが大規模の業務用システムの開発ではなく、「ドラクエ」を冠した新規MMOの開発であるという点がポイントかもしれない。
これは、大規模でも事前に詳細に定められない、創意工夫をできる限り盛り込みたい、つまり「目標をあらかじめ決められない」プロジェクトかと。そのために、現物を触りながら改善を進めていきたかったり、職人が生み出す芸術的な成果を優先したい部分もあったりで。
そんな方針を実現する手法としてアジャイル開発を取り入れた、という話だと読めたんで、別にアジャイルの話を持ってくるのが方向違いだとは思わない。
基本的な内容が多いので元コメのような意見を持つのは分かる。ゲーム業界ならではの工夫がもっと分かるような内容だと面白く読めたと思う。
けれど、CEDECの記事とは言えゲーム専門サイトの4Gamer.netの記事なので、プロジェクト管理面で記事の内容が薄いと指摘するのはちょっと野暮かなと思うし、試行錯誤した大規模プロジェクトの成果の発表って、その中身のレベルが低かろうが高かろうが貴重なものだと思うから、頭ごなしに叩くのもどうかと思うわ。
ドラクエの場合、最終的な裁量の大半は堀井雄二氏が握ってますからね。開発途中で目標が別のものになったりするなんてこともしばしばあるはずです。
やって当然程度の事しか言ってないよなー。問題はそれらを如何に形骸化させずに効果を保ったまま続けるかってトコロ。# 線図がExcel方眼紙くさいのが気になる。ああいうバイナリファイルでゴニョゴニョするのは原理的に本当の意味では共有できないからダメダメなんだけどなー。
「やって当然」な内容はみんな知っているけど（だよね？）、それが出来れば苦労はしないですよねえ。
久々に、禿同。
ところでCCPMって知ってますぅ？
>プロジェクト目標、成果物と投入リソースの関係とかこれがプロジェクト管理の肝なんすか？持論聞きいてみたいっす、煽りとかじゃなくて純粋に。
あの本でTOCと一緒に語られてるから混同しやすいけどそれTOCじゃないよ。TOCとクリティカルパスは全然関係ない。TOCってのは「各々が勝手に考えた解決策を戦わせるんじゃなくて、各々が抱える条件をテーブルに乗せてジンテーゼを作ろう」って話。だからTOCは机上の空論にはなり得ない。# なんでゴールドラットはクリティカルパスの話を混ぜて書いたんだろうか...。
うーん。実際のプレゼンは面白かったんじゃないかと想像するんだけど、この記事からは魅力は伝わってこないねえ。実にレポートチック。パワポの資料ぐらいまるごと公開できれば良かったのにね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
記事書いた人 (スコア:3)
それとも発表でわざと論点をずらしたのか。
プロジェクト目標、成果物と投入リソースの関係とか
リスク管理とか、肝の部分がまるで語られていない。
＞毎日15分のミーティング、バッファを入れたスケジューリング、細かいロードマップ、スタッフ全員による定期的なレビュー
こんなのでプロジェクト管理ができるなら苦労はない。
本当なら、目標レベルが低すぎ。
Re:記事書いた人 (スコア:2)
元記事カケラも見ずに言ってませんか?
例えばバッファを入れたスケジューリングに関しても、元記事から一部抜き出してもこの程度は書かれています。
このような内容ですが、「まるで語られていない」は当てはまりますか?
Re:記事書いた人 (スコア:3)
糊代をどこに投入するか、いよいよ糊代がなくなったときにどういう基準で、
何を捨て、何を死守したかを語らなきゃ。
「糊代」余りましたというのは、それはそれでダメなんだわ。
Re:記事書いた人 (スコア:1)
前のコメント見ても元記事を見ていないのでしょうか。言っている内容についても元記事にあるように見えますが。
発表内容に本当に興味があるなら「ゲーム系サイトによるレポート」ではなく、現場で聞けというような話ではないでしょうか。
ゲーム系サイトという点を踏まえると割と突っ込んで書かれているように思えます。
また、糊代は基本的に強度確保の上で多少の余裕をもって用意するものです。
通常糊代部分に万遍なく糊を塗ること、糊代から糊がはみ出たりしない様、適切に糊を塗ることなどは想定されておらず、貼り付けた際に糊が広がることを想定して糊代部分は余裕をもった空間を用意することが基本です。
糊代は余るものであって、糊代余りませんでしたというのはぎりぎりの設計であり、余裕がなくよろしくない設計です。
そこから広がった言葉の意味としても、糊代は余裕を表すもので、糊代が余るのはダメ = 余裕があってはいけないという事となります。
余裕 (糊代) は不要というのは、リスク管理上致命的な問題がありませんか。
Re: (スコア:0)
でもさ、糊代だってタダじゃないんだから、必要以上にでかい糊代でしたという状況が許容される現場ばかりじゃないでしょ。
糊代の最適化のポイントはなに？ってことかと。
＃何を捨て、何を死守したかの考え方は記事中に含まれてるけどね
Re: (スコア:0)
「糊代を投入する」という表現は初めて見たな
Re: (スコア:0)
糊代
＋２
Re:記事書いた人 (スコア:1)
プロジェクト目標や成果物を予め「緻密には」定義できない、
というのはアジャイル開発の一つの出発点で、だからこそ小刻みに計画策定と
チェックを繰り返すことで大幅な計画変更や手戻りを避けるわけですよね。
乱暴にいえば、「数年にわたるようなプロジェクトは管理しきれないけど、
1週間くらいの計画なら目で見て管理しきれるし、それを繰り返していけば、
結局トータルの成果は大きいよ」というのも一つの考え方です。
あなたのいう「プロジェクト管理」の定義がわからないと、
なにが「素人」で「苦労がない」のかよくわかりません。
Re:記事書いた人 (スコア:2)
プロジェクトの目標や成果物をあらかじめ決められない
人にプロジェクトは任せられません。
仕上がりは出来てからのお楽しみじゃ、話になりません。
ここで、アジャイルの話を持ってくるのは方向違い。
プロジェクトを細分化してサブプロジェクトとして管理するのは
ごく当たり前の話。
＞数年にわたるようなプロジェクトは管理しきれないけど
あり得ません。
Re:記事書いた人 (スコア:1)
> プロジェクトの目標や成果物をあらかじめ決められない
> 人にプロジェクトは任せられません。
> 仕上がりは出来てからのお楽しみじゃ、話になりません。
これが大規模の業務用システムの開発ではなく、
「ドラクエ」を冠した新規MMOの開発であるという点がポイントかもしれない。
これは、大規模でも事前に詳細に定められない、創意工夫をできる限り盛り込みたい、
つまり「目標をあらかじめ決められない」プロジェクトかと。
そのために、現物を触りながら改善を進めていきたかったり、
職人が生み出す芸術的な成果を優先したい部分もあったりで。
そんな方針を実現する手法としてアジャイル開発を取り入れた、
という話だと読めたんで、別にアジャイルの話を持ってくるのが方向違いだとは思わない。
基本的な内容が多いので元コメのような意見を持つのは分かる。
ゲーム業界ならではの工夫がもっと分かるような内容だと面白く読めたと思う。
けれど、CEDECの記事とは言えゲーム専門サイトの4Gamer.netの記事なので、
プロジェクト管理面で記事の内容が薄いと指摘するのはちょっと野暮かなと思うし、
試行錯誤した大規模プロジェクトの成果の発表って、
その中身のレベルが低かろうが高かろうが貴重なものだと思うから、頭ごなしに叩くのもどうかと思うわ。
Re:記事書いた人 (スコア:2)
ドラクエの場合、最終的な裁量の大半は堀井雄二氏が握ってますからね。
開発途中で目標が別のものになったりするなんてこともしばしばあるはずです。
一人以外は全員敗者
それでもあきらめるより熱くなれ
Re:記事書いた人 (スコア:1)
やって当然程度の事しか言ってないよなー。
問題はそれらを如何に形骸化させずに効果を保ったまま続けるかってトコロ。
# 線図がExcel方眼紙くさいのが気になる。ああいうバイナリファイルでゴニョゴニョするのは原理的に本当の意味では共有できないからダメダメなんだけどなー。
Re: (スコア:0)
「やって当然」な内容はみんな知っているけど（だよね？）、それが出来れば苦労はしないですよねえ。
Re: (スコア:0)
久々に、禿同。
Re: (スコア:0)
ところでCCPMって知ってますぅ？
>プロジェクト目標、成果物と投入リソースの関係とか
これがプロジェクト管理の肝なんすか？
持論聞きいてみたいっす、煽りとかじゃなくて純粋に。
Re: (スコア:0)
Re:記事書いた人 (スコア:1)
あの本でTOCと一緒に語られてるから混同しやすいけどそれTOCじゃないよ。TOCとクリティカルパスは全然関係ない。
TOCってのは「各々が勝手に考えた解決策を戦わせるんじゃなくて、各々が抱える条件をテーブルに乗せてジンテーゼを作ろう」って話。
だからTOCは机上の空論にはなり得ない。
# なんでゴールドラットはクリティカルパスの話を混ぜて書いたんだろうか...。
Re: (スコア:0)
うーん。
実際のプレゼンは面白かったんじゃないかと想像するんだけど、この記事からは魅力は伝わってこないねえ。実にレポートチック。
パワポの資料ぐらいまるごと公開できれば良かったのにね。