アカウント名:
パスワード:
10倍になったスライドの後に「めでたしめでたし ・・・・のはずもありませんよね」「見事なデスマーチの完成です。結構ありがちな風景ではないでしょうか」と続きます。
こちらが元です。
http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf [square-enix.com]
ありがとう、リンク先とても参考になりました。スクエニというだけで色眼鏡で見ながら読んでいたのですが、これPM駆け出しの人とかには相当に参考になる資料ですよ。アジャイルのエッセンスを取り入れつつ、いかに大規模プロジェクトをデスマーチ化させないかというところで、今までウォーターフォールしか経験が無いけどアジャイルが気になっている、というPMにも必読としてもいいんじゃないでしょうか。
個人的ツボだったのは、「PDCAがしっくりこない」のでPDCで説明されている点。確かにAは不要と考える人達がいて、その中でも「次のPになる」という人と「Cに含まれる」という人がいたり私自身も腑に落ちるまで時間がかかったところでした。
もともとPlan - Do - Seeだったのを日本でPDCAに改悪したので、単に原点のPlan - Do - Seeがやはりしっくりくるというだけの話でしょう。
興味深いのでこのリンクを追記しておきました。ありがとうございます。
参考になります
#これは確かに4GAMERの記事は誤解を招くであります……
いい資料だと思いました。ちょっと長いけど。
仕事を何度も最後までやり遂げたことがある人の資料でした。
スライドを読んでみたのですが、まだ足りないような気がします。・工程表を組むときは、最大見積もり?最小見積もり? どちらにせよ、頻繁に工程表を見直さないと 早く終わった分は生かされないし、遅れた分の挽回も出来なくなる。 しかも、リソースの競合を避けて見直すとしたら マネージャーは工程表の見直しで手一杯になる・優先順位が自然にわかる、とあるが本当? 納期とスコープは、大抵対立する。 どちらを優先するか決められるのか?
TOC/CCPMというマネージメント手法がありますがこの方法だと、・各タスクのバッファ(=最大見積もりー最小見積もり)は 全て集めて納期の直前におく・
凄いね。スライドを見ているだけで頭に入ってくる。資料と説明力自体が優秀だと思う。
仮にこの内容が正しくなかったとしても、これを基準に思考を巡らすだけでも価値がある。すばらしい。
スクウェア・エニックスの開発は裁量労働制の契約社員なので残業代は発生しませんよ。
いや、だからこれは、そういう失敗というか愚を犯さないためのプロジェクト管理って話です。労働時間を長くするとか、その辺のスライドは失敗の例として挙げられたもので別にスクエニが推奨してるわけでもなんでもないですよ。そして失敗を振り返らなければ正しい方向には改善できないわけですから、失敗の例を挙げるのはむしろ当然でよね。「何がいいたのでしょう」と書いてるところを見ると理解できないかもしれませんし、それなら仕方ないですが。
このオープンカンファレンスは私も出てましたけど、プロジェクト管理には100%の正解というのはないわけですし、ここで語られているようなのを参考にいろいろ工夫すればいいじゃないかと思いますよ。自分らが取り組んでいる手法を外部に公開してくれるというだけでも価値があるんじゃないかと思います。
その部分はよくある「無理矢理リソースを合わせました」の一例として出していて、ならどうすればいいか、を以降の部分で述べている、と読み取ったのですが、読み方間違えてます?
気になるのが、「クリエイティブをどう確保するのか」「開発者のモチベーションをどう確保するのか」が全く書かれてない事ですね。マネージメントは管理じゃなくて、環境づくりなんだけどな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
月労働時間 (スコア:1)
160時間を290時間にして1.8倍の効果などと書いてますけど、
8時間×20日で160時間なら残業扱い130時間ですよ。。。
(日曜休みなら一日平均12時間労働)
労働基準を無視しますと宣言しているようなものです。
# 人員の追加投入とか、品質の妥協とか、失敗のネタを並べて何が言いたいのでしょう?
notice : I ignore an anonymous contribution.
4gamer の記事は新聞並みの酷い改ざん (スコア:5, 参考になる)
10倍になったスライドの後に
「めでたしめでたし ・・・・のはずもありませんよね」
「見事なデスマーチの完成です。結構ありがちな風景ではないでしょうか」
と続きます。
こちらが元です。
http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf [square-enix.com]
マクロの基本は検索置換(by y.mikome)
Re:4gamer の記事は新聞並みの酷い改ざん (スコア:2)
ありがとう、リンク先とても参考になりました。
スクエニというだけで色眼鏡で見ながら読んでいたのですが、
これPM駆け出しの人とかには相当に参考になる資料ですよ。
アジャイルのエッセンスを取り入れつつ、いかに大規模プロジェクトをデスマーチ化させないか
というところで、今までウォーターフォールしか経験が無いけどアジャイルが気になっている、というPMにも
必読としてもいいんじゃないでしょうか。
個人的ツボだったのは、「PDCAがしっくりこない」のでPDCで説明されている点。
確かにAは不要と考える人達がいて、その中でも「次のPになる」という人と「Cに含まれる」という人がいたり
私自身も腑に落ちるまで時間がかかったところでした。
Re: (スコア:0)
もともとPlan - Do - Seeだったのを日本でPDCAに改悪したので、単に原点のPlan - Do - Seeがやはりしっくりくるというだけの話でしょう。
Re:4gamer の記事は新聞並みの酷い改ざん (スコア:1)
興味深いのでこのリンクを追記しておきました。ありがとうございます。
Re:4gamer の記事は新聞並みの酷い改ざん (スコア:1)
参考になります
#これは確かに4GAMERの記事は誤解を招くであります……
Re: (スコア:0)
いい資料だと思いました。ちょっと長いけど。
仕事を何度も最後までやり遂げたことがある人の資料でした。
TOC/CCPM(Re:4gamer の記事は新聞並みの酷い改ざん) (スコア:0)
スライドを読んでみたのですが、まだ足りないような気がします。
・工程表を組むときは、最大見積もり?最小見積もり?
どちらにせよ、頻繁に工程表を見直さないと
早く終わった分は生かされないし、遅れた分の挽回も出来なくなる。
しかも、リソースの競合を避けて見直すとしたら
マネージャーは工程表の見直しで手一杯になる
・優先順位が自然にわかる、とあるが本当?
納期とスコープは、大抵対立する。
どちらを優先するか決められるのか?
TOC/CCPMというマネージメント手法がありますが
この方法だと、
・各タスクのバッファ(=最大見積もりー最小見積もり)は
全て集めて納期の直前におく
・
Re: (スコア:0)
凄いね。スライドを見ているだけで頭に入ってくる。資料と説明力自体が優秀だと思う。
仮にこの内容が正しくなかったとしても、これを基準に思考を巡らすだけでも価値がある。すばらしい。
Re:月労働時間 (スコア:2)
スクウェア・エニックスの開発は裁量労働制の契約社員なので残業代は発生しませんよ。
Re:月労働時間 (スコア:1)
いや、だからこれは、
そういう失敗というか愚を犯さないためのプロジェクト管理って話です。
労働時間を長くするとか、その辺のスライドは失敗の例として挙げられたもので
別にスクエニが推奨してるわけでもなんでもないですよ。
そして失敗を振り返らなければ正しい方向には改善できないわけですから、
失敗の例を挙げるのはむしろ当然でよね。「何がいいたのでしょう」と書いてるところを
見ると理解できないかもしれませんし、それなら仕方ないですが。
このオープンカンファレンスは私も出てましたけど、プロジェクト管理には
100%の正解というのはないわけですし、ここで語られているようなのを
参考にいろいろ工夫すればいいじゃないかと思いますよ。自分らが取り組んでいる
手法を外部に公開してくれるというだけでも価値があるんじゃないかと思います。
Re: (スコア:0)
その部分はよくある「無理矢理リソースを合わせました」の一例として出していて、
ならどうすればいいか、を以降の部分で述べている、と読み取ったのですが、
読み方間違えてます?
Re: (スコア:0)
気になるのが、「クリエイティブをどう確保するのか」「開発者のモチベーションをどう確保するのか」が全く書かれてない事ですね。
マネージメントは管理じゃなくて、環境づくりなんだけどな。