4gamerの記事の補足というか、話がややこしくなるから避けた箇所について。
要するに、開発チームに実力が足りなかった場合どうするか。
「早めに損きりしてプロジェクトを諦める」
これが正解だと思ってる。他の手はそうは無いよ。
自分は発注側、受託側の両方の立場に立ったことがあるんだけど。
作りかけのゲームを挟んでこっち側に座るか、あっち側に座るかで、ものの見方が１８０度変わるわけで胃に来る。嫌な汗が出る。
ダメ出しをするのはツライ。
発注の仕方をマズってて混沌になってるプロジェクトを「これは微妙なんじゃね？」とか言うのは苦虫モグモグだ。（発注には噛んでないが、開発がわかる人的な扱いで場に呼ばれたりする）
知っている失敗例を数えていくと、やはり大抵の場合は座組に問題がある。
例えば発注側の知識不足とか、受託側の能力不足とか。
こういう状況を回避するには、偉い人が舵を切るしかない。偉い人程取り得る選択肢が多いのだから。
偉い人程権限があるから、失敗を回避する事は出来るハズなのだけど、知識が無いと間違った舵を切ってしまう。
現場はこりゃ駄目だと思っても、指示が出てれば従う事が仕事だ。そりゃこりゃダメっしょー。みたいな話はちゃんと上げるけどね。
逆に自分が発注側のときは「なんかやばいとこある？」みたいなのは日常会話でやたら聞くし、まぁ見た目で判断できる。
海原雄山は、てんぷら職人を見て、揚げるてんぷらの旨さがわかるが、ゲーム開発者は、ゲーム開発者をみて、どれぐらいのことが出来るかがわかるから。
話が意図的にずれた。
失敗するプロジェクトは、だいたいが座組の段階で失敗しているという話。
そんなもん、簡単には対処できないから、とっとと損切というのは、あながち間違いでは無いと思う。
もしくは、事態を打開できる人材を投入するかだ。
失敗しているという事は、今の座組では事態を打開できないということで、その状態で進めることはいたずらに傷口を広げていく。
現在開発が失敗中なのか、例の外部から見た際の開発の一時的な遅れかを見分けるのは、それなりのスキルが要る。どうしても現場に詳しい人の意見というのは重要だ。
全員がガリガリに詳しい必要は無いが、詳しい人を混ぜるとか。（自分は別プロジェクトのプログラマとかにも聞く）
そもそも話をする。
だいたい座組的には、委託側は1円でも安く高いクオリティのものが欲しいし、開発側は妥当な工数で物を作りたい。
これは最悪相手に損をさせる事が利益になる。
だから座組は、レベニューシェアとか、報奨金とか、開発が頑張れば頑張るほどいい事があるような座組にしておいたほうが良いと思うんだ。
遅延罰則とかで縛ると、モチベーション下がってデキる奴から逃げていくから。
時々、一定以上の売り上げを超えてから一定額までレベニューシェア、ソコまで行かないとモトが取れない低価格、みたいな契約があって。
これはほんとヒドイなと感じる。足元を見過ぎだ。
超えないとジリ貧、超えても天井が低い。開発側のリスクがやたら高い癖にメリットが薄い。
しかも企画は発注側がやるのかよ。みたいな契約ね。
こういうのは、どっち側のイスに座っていても胃にきたりする。
これも程度問題だけど、相手に利益を渡さない取引は、結局長期的にはいい結果を生まないわけで。
失敗の例は大抵座組の段階で失敗が予定されているという話をしたけど、成功した例はどうか。
俺の知る限り、成功例は運が良かったか、知識のある奴が権限を持ってたか、知識の有る奴が越権行為でブン回したか、スキルのある奴が耐えてどうにかした、というのが多い。結局、開発は場数だよアニキ。
んで、発注側が出来るのは「予算ブっ込む」「諦める」の２択。
（さっき書いた、適切な人材を投入するは、予算をブッ込むと同じ方向性になる）
これに、「タダでクオリティを上げさせる」という選択肢を入れると、結果的に、開発会社ツブしたり、主力開発者が逃げたり、関係者がプロジェクトへの愛を失って明日を見失ったりする。
「＊＊を改善すれば良くなる」
て所まで青写真があるなら、それは指示を出す。期間と予算は考慮する。
よくならなかった場合の責任は持つ。
この辺が限界ラインか。
ゲーム開発はどうしてもトライ＆エラーになるから。
開発経験があると、わかりきってる失敗のトライアルを減らす事ができる。
予算内で収めるにはそういった経験がどうしても必要だ。
これは発注側にも、受注側にも重要なポイント。
そもそもね。完成したゲームみてこりゃダメだ。せめて俺ならこうするってのは誰でも思い浮かぶ。
その案を実現するスキルがあるか。そもそもその案は正しいのか。
そういうアレコレをちゃんと乗り越えるから、バクチに勝つこともあるんでしょ。的な。
ついでに述べておくと。
開発中に、ヤベコレ手思ったときに出るアイデアに関しては以下の感じじゃないかな、
誰にも負荷をかけずに解決するのが「素晴らしいアイデア」
誰かに負荷をかけて解決するのは「だたのクソな思いつき」
誰かに負荷をかけても解決せず、あらたな問題を引き起こすのが「のクソ以下の思いつき」
誰かに負荷をかけて解決するが、ソコにかかった予算は自分が責任を持つ「采配として正しい」
みたいな感じ。
偉い人にはこれぐらいの選択肢はある。
ヒアリングすることで、それぞれのリスクリターンが見えてくる。
とにかくヤレで好転する事態というのはそうはない。
今日は酒が入ってるので、いつもに増して、アレな感じの文章だが。
朝起きて微妙だったら、誤字脱字は治すつもりで。（直した。まだあったらごめん。おせーて。）
んじゃま。あでゅー。
あー。あと座組をちょっと可視化したxlsかパワポでも合ったほうが話が早いな。
気が向いたら来週ぐらいになんか書く。
要するに、開発チームに実力が足りなかった場合どうするか。
「早めに損きりしてプロジェクトを諦める」
これが正解だと思ってる。他の手はそうは無いよ。
自分は発注側、受託側の両方の立場に立ったことがあるんだけど。
作りかけのゲームを挟んでこっち側に座るか、あっち側に座るかで、ものの見方が１８０度変わるわけで胃に来る。嫌な汗が出る。
ダメ出しをするのはツライ。
発注の仕方をマズってて混沌になってるプロジェクトを「これは微妙なんじゃね？」とか言うのは苦虫モグモグだ。（発注には噛んでないが、開発がわかる人的な扱いで場に呼ばれたりする）
知っている失敗例を数えていくと、やはり大抵の場合は座組に問題がある。
例えば発注側の知識不足とか、受託側の能力不足とか。
こういう状況を回避するには、偉い人が舵を切るしかない。偉い人程取り得る選択肢が多いのだから。
偉い人程権限があるから、失敗を回避する事は出来るハズなのだけど、知識が無いと間違った舵を切ってしまう。
現場はこりゃ駄目だと思っても、指示が出てれば従う事が仕事だ。そりゃこりゃダメっしょー。みたいな話はちゃんと上げるけどね。
逆に自分が発注側のときは「なんかやばいとこある？」みたいなのは日常会話でやたら聞くし、まぁ見た目で判断できる。
海原雄山は、てんぷら職人を見て、揚げるてんぷらの旨さがわかるが、ゲーム開発者は、ゲーム開発者をみて、どれぐらいのことが出来るかがわかるから。
話が意図的にずれた。
失敗するプロジェクトは、だいたいが座組の段階で失敗しているという話。
そんなもん、簡単には対処できないから、とっとと損切というのは、あながち間違いでは無いと思う。
もしくは、事態を打開できる人材を投入するかだ。
失敗しているという事は、今の座組では事態を打開できないということで、その状態で進めることはいたずらに傷口を広げていく。
現在開発が失敗中なのか、例の外部から見た際の開発の一時的な遅れかを見分けるのは、それなりのスキルが要る。どうしても現場に詳しい人の意見というのは重要だ。
全員がガリガリに詳しい必要は無いが、詳しい人を混ぜるとか。（自分は別プロジェクトのプログラマとかにも聞く）
そもそも話をする。
だいたい座組的には、委託側は1円でも安く高いクオリティのものが欲しいし、開発側は妥当な工数で物を作りたい。
これは最悪相手に損をさせる事が利益になる。
だから座組は、レベニューシェアとか、報奨金とか、開発が頑張れば頑張るほどいい事があるような座組にしておいたほうが良いと思うんだ。
遅延罰則とかで縛ると、モチベーション下がってデキる奴から逃げていくから。
時々、一定以上の売り上げを超えてから一定額までレベニューシェア、ソコまで行かないとモトが取れない低価格、みたいな契約があって。
これはほんとヒドイなと感じる。足元を見過ぎだ。
超えないとジリ貧、超えても天井が低い。開発側のリスクがやたら高い癖にメリットが薄い。
しかも企画は発注側がやるのかよ。みたいな契約ね。
こういうのは、どっち側のイスに座っていても胃にきたりする。
これも程度問題だけど、相手に利益を渡さない取引は、結局長期的にはいい結果を生まないわけで。
失敗の例は大抵座組の段階で失敗が予定されているという話をしたけど、成功した例はどうか。
俺の知る限り、成功例は運が良かったか、知識のある奴が権限を持ってたか、知識の有る奴が越権行為でブン回したか、スキルのある奴が耐えてどうにかした、というのが多い。結局、開発は場数だよアニキ。
んで、発注側が出来るのは「予算ブっ込む」「諦める」の２択。
（さっき書いた、適切な人材を投入するは、予算をブッ込むと同じ方向性になる）
これに、「タダでクオリティを上げさせる」という選択肢を入れると、結果的に、開発会社ツブしたり、主力開発者が逃げたり、関係者がプロジェクトへの愛を失って明日を見失ったりする。
「＊＊を改善すれば良くなる」
て所まで青写真があるなら、それは指示を出す。期間と予算は考慮する。
よくならなかった場合の責任は持つ。
この辺が限界ラインか。
ゲーム開発はどうしてもトライ＆エラーになるから。
開発経験があると、わかりきってる失敗のトライアルを減らす事ができる。
予算内で収めるにはそういった経験がどうしても必要だ。
これは発注側にも、受注側にも重要なポイント。
そもそもね。完成したゲームみてこりゃダメだ。せめて俺ならこうするってのは誰でも思い浮かぶ。
その案を実現するスキルがあるか。そもそもその案は正しいのか。
そういうアレコレをちゃんと乗り越えるから、バクチに勝つこともあるんでしょ。的な。
ついでに述べておくと。
開発中に、ヤベコレ手思ったときに出るアイデアに関しては以下の感じじゃないかな、
誰にも負荷をかけずに解決するのが「素晴らしいアイデア」
誰かに負荷をかけて解決するのは「だたのクソな思いつき」
誰かに負荷をかけても解決せず、あらたな問題を引き起こすのが「のクソ以下の思いつき」
誰かに負荷をかけて解決するが、ソコにかかった予算は自分が責任を持つ「采配として正しい」
みたいな感じ。
偉い人にはこれぐらいの選択肢はある。
ヒアリングすることで、それぞれのリスクリターンが見えてくる。
とにかくヤレで好転する事態というのはそうはない。
今日は酒が入ってるので、いつもに増して、アレな感じの文章だが。
朝起きて微妙だったら、誤字脱字は治すつもりで。（直した。まだあったらごめん。おせーて。）
んじゃま。あでゅー。
あー。あと座組をちょっと可視化したxlsかパワポでも合ったほうが話が早いな。
気が向いたら来週ぐらいになんか書く。
| ホーム |
COPYRIGHT © 2004 POWERED BY FC2 ALL RIGHTS RESERVED.
