Togatterでこんなの見つけました
Togetter - まとめ「ゲーム制作にまつわる問題点」
結構似たような事や関係してそうな事ががあるんですね。以下同じだと思った内容を抜粋
金出してる奴は金出してる以上のリターンを求める。全部いう事聞いてたら赤字になる。
これはどこでも同じだと思う。
昔は全部紙書けばどうにかなるだろうと思ってた。無理だった。だって、紙読まないんだぜ。かなりの開発者が。
これは現在の悩み。全く読まないような酷い人はなかなかいませんが、自分がコーディングする部分だけの資料で理解出来てると思っている人は多い(参照しろと書いても読まない人が多い)、若しくは割り切って知らないものは知らんと言った態度の人もいる。時間とコストが少ないせいでもある。
ちゃんと仕様書を読むプログラマはものすごく重宝する。
SEが設計書まで書いてプログラマに渡す場合で仕様書に書かれているルールはわざわざ設計書までに同じことを書かない事もある。その期待に外れて仕様書を無視して設計書に書いている事だけを見てコーディングして後は知らん。というのは経験した。あと仕様が複雑になってくるとデバッグする目の数が必要になってきてそういうときに仕様書をしっかり読んでくれるプログラマは仕様に潜むレアなバグの発見に繋がったりして重宝します。
最近のプログラマは、高速化や圧縮の小技を知らない人も多い。
確かに、こういうプログラマは任せられる範囲が限定されるのでやりにくい。でも教えてあげて次回は出来るようになってもらうしかない。
ちなみに最近の絵描きは、プログラム的知識に乏しいので、パレット（クラット）や、ファイル、ディレクトリ、なんやらかんやらの知識をぶっこむのが超大変。３Ｄツールの操作に長けるが絵が下手とか、絵は上手いけど３Ｄ苦手とか、特化してて面倒な人も多い。
ウェブデザイナーでもRGBが理解できないとか透過GIFの原理を全く知らないとか、ウェブ上のデザインなのにメートル法で表現しピクセル単位で要望すると逆切れしたりとか。アバターの着せ替えとか2Dのゲームではドット絵師としてのセンスと合わせて必須事項だと思うのに。特化してて面倒なのはバッチ屋になってしまってる私も反省。
日本のゲームの特徴として、毎回エンジン新造したり、ルールを根底から創造したりするところがあるので、これはなかなかツール化が大変だ。（時間とハードスペックが解決するとは思うが）
ゲームはともかくシステム開発でも同じような状況。業務の多様性は否定しないが毎回、創造して作らせていたらコスト削減がうまくいかない事にいい加減気付くべき。まぁ気付かれてどの会社も一斉にパッケージを使い始めて業務をパッケージに合わせるようになったら、コストメリットの無い独自開発が減るが同時に沢山のプログラマが職を失うかもねｗｗｗ
細深化もしているので、各開発者は自己パートのエキスパートにはなるんだけど、全体を見る能力が磨かれていかない。
人数の多いプロジェクトや役割分担をローテーションせずに長期でやってると陥る罠。全体を見れる人が育たないのも問題だが欠員が出たときのリスクがヤバい。何とかしないと。
ゲーム業界が煮え詰まってエライコトになってるところに、「一方webと携帯屋はソーシャルゲームを作った」という状況
いきなりweb屋がゲーム作れるわけでもないのでゲーム業界の方々と協力が必要ですが、大きなゲームを一本作るというのは無くて小粒にタイトル量産、権利を受けて移植量産って感じでした。こっちは素人なんで企画さんとゲーム屋さんにお任せではあります。
ソーシャルゲーって簡単そうだけど、あれはコストかかるんだぜとか。アジアプログラムの流出とか
その割りに単価が安いですよね。昔はFlash制作に夢見てましたが今のFlash受注単価見てるとアニメ制作と同じ道に進んでいるような気がするのです。
テストについてはこちらの日記を見つけました
2010-06-12 - 未来のいつか/hyoshiokの日記
全く同感。
テスト書くこととテストをすることの違い
みんなテストはしますが、テストを書くというのは本当に少ないですね。
私は同じ作業をしたくないのでテストを書きますが、そのコードをプロジェクトごとに使い捨てにしてたのは反省。
テストプログラムを作ると言うことは、エクセルのシートにテストケースを書くことではない。
手作業テストだと実行可能なケース数が限られますからね。エクセルシートだけで全機能テストはコスト上不可能なのでどこか発生しにくいパターンを端折って想定外で済ますという隠蔽工作を・・・
コンパイラだってソースコードの文法テストツールとして考えることもできますからね。だからコンパイラを通さないスクリプト言語だとツマラナイ構文エラーで無駄な作業が発生するし。
