  |
はてなキーワード: 仕様書とは
そういう会社で○年目(5年以下とだけ)がそろそろ終わるのですが、正直転職ばかり考えている。
というのも、自ら設計した仕様書でプロジェクトに火がついたことはないが、下請け案件では殆ど火災だらけ。
国内王手のうちのある会社が主要取引先なのだが、はっきり言おう。
以下に私の食った仕様書をお教えしよう。
はい、メソッド？なにそれ？おいしいの？と言わんばかりの超大作。
上から下まで流すだけ。保守性皆無。
しかも無理やりループを一まとめにするから、もはや何処で何をしてるのか、、、、。
Basic/Cobol ならまだ分からんでもないが Java や C#
作ってないんですねきっと。何がしたいのかさっぱり分からない。
それで実装用の設計起こすんだから、そりゃぁ全体で動くわけねーわ。
(このときにクレーム付けられるのって下請けなんですが、でも下請けでは発言権無いですからね、、、|||orz)
いや本当に何がしたいのか、、、、どういう分岐条件かも分からない。
いやむしろ書いてない！？
DI, AOP, O/R Mapper いずれも基本となる技術なんですよね、でも。
「何でこんな意味の無いところに使うの？」という使い方で逆に労力を増やしてくれる。
例えば O/R Mapper はテーブルとマッピングを行い、プログラム側で処理しやすく、、、、
で、仕様書の指定「すべてのSQL結果に対して対応するO/Rを作成する」ってｗｗｗｗ
当然従えば大量にオブジェクトができて、SQL仕様が変わるたびに、、、、以下略。
「元のプロジェクトが○位の規模なのにどうしてその倍以上の規模なってんだｺﾞﾙｧ」
「すべてのオブジェクトはシングルトンで実装し、Interface用意してね、DIで使うから」
ってどれだけ無駄すれば気が済むのか、、、、。
(Test 時にMock入れるだけならここまでする意味って無いよな…)
そしてこんなことをして下請けをいじめた挙句「弊社には最新技術のノウハウがございます」とか言う。
素敵、、、、、。
こんな人海戦術しかないような仕様を書いてるようでは、そりゃ安価な海外に流れるなと、、、、。
本当に自分の技術を信じる人は、独立系、海外系、自社製品開発に行ってください。((もしくは王手企業でまともな仕様書書いてください))
509 ：名無しさん＠お金いっぱい。：2010/02/04(木) 22:55:23 ID:0hMHBPfc0
＞508
なんという厨二病
510 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:11:18 ID:ZmAlsQ0z0
＞508
これを30歳ちかい大人が書いたというのを想像すると、
なんだか愉快な気持ちになってきますね。
511 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:28:55 ID:LJK06wi+0
＞508
２ちゃんねるの最初の頃はこういうのを自作自演で盛り上げてってどんどん
虚名があがってくんだから世の中チョロイなーとか思ってたんだろうなー
まぁツケは後でくるんだけどね。今真顔で山本権兵衛の孫ですとかいったら
ぶん殴るわー
512 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:41:57 ID:UmutD1lF0
でもこういう情報が降りて来ない過疎板ではまだ切込ネタを信じてる連中がいるんだよな
183 名前：iPhone774G[sage] 投稿日：2010/02/04(木) 18:38:16 ID:fFGfwOFc0
4Gamer.net ― 【切込隊長】ゲーム業界，使えない人サバイバル（前編）
http://www.4gamer.net/games/000/G000000/20100202054/
＞プロジェクトがなくなって任地のなくなったプロデューサーやディレクターが解雇されず，
＞とはいえやることもないので，暇の延長線上でiPhone開発を社内で手がけるという
だから国内メーカーはロクなのが無いのか
その割に危機感が全然無さそうなのは何故だろう
184 名前：iPhone774G[sage] 投稿日：2010/02/04(木) 18:56:54 ID:xu93WEO00
まぁ今のゲーム業界は「ゲームが最近熱い！！」とか先人達のすごさに甘んじてブランドだけで入ったようなカスが多いから
時間がたてばこうなるのは必然 時代の変化を捉えられない人達の集まりだから
186 名前：iPhone774G[sage] 投稿日：2010/02/04(木) 19:50:32 ID:+HqaE6IV0
＞183
どこの会社も口だけのプロデューサー、古株なだけのディレクター、グラフィックデザイナー、プログラマーは腐るほどいるんだよ
遊びやアイデアを仕様書に落としこめる奴がいない会社はどうにもなんない
187 名前：iPhone774G[sage] 投稿日：2010/02/04(木) 20:04:59 ID:PoZZ4RBC0
＞183
513 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:45:52 ID:/0jjJRDN0
＞508
フカシ過ぎだろｗｗ
なんだこれ
514 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:55:05 ID:XWOww2nV0
＞512宣伝だとおもうけど。
アクセス数稼ぐための。
前に全文検索したけど、
なにかを書くたびに２ｃｈのあちこちにリンクが貼られるもん。
隊長がやってるとは言わないが。
515 ：名無しさん＠お金いっぱい。：2010/02/04(木) 23:58:35 ID:XWOww2nV0
２ｃｈのあちこちにリンク貼られて、（誰かが宣伝してまわって）、
それで隊長はアクセス数の稼げるブロガーとして、原稿を載せたサイト側に評価される。
516 ：名無しさん＠お金いっぱい。：2010/02/05(金) 00:22:29 ID:hYkXZDnc0
＞514
いや、リンクを貼る奴だけじゃなく
そのリンク先の切込の「業界裏ネタ」をスレ住人達がソースとして普通に語ってる所が・・・
517 ：名無しさん＠お金いっぱい。：2010/02/05(金) 00:57:26 ID:8bWyCKnD0
また注意を喚起しなきゃ不味くなってきたかもね。
518 ：名無しさん＠お金いっぱい。：2010/02/05(金) 01:52:52 ID:a69aWQwv0
常に注意は喚起しておいた方がいいよ。こういう奴はもうまともに仕事ができなくなってるから。
それで真面目な人も被害に遭ってしまう。気が弱い人は恫喝され洗脳されてしまう。
面白がって近づいた人ですら、いつしか詐欺被害や共犯などになってしまうから。
519 ：名無しさん＠お金いっぱい。：2010/02/05(金) 03:39:46 ID:ROTUttiN0
俺もたまに山さんに絡まれてキレてる有名人とかにあの人はおかしい人だから
相手しないでください、wiki参照、てゆってるよ。みんなもボランティアでやったら？
520 ：名無しさん＠お金いっぱい。：2010/02/05(金) 07:10:06 ID:hYkXZDnc0
最近はひろゆきに習って洋ゲー関連のコラムに出てくるようになった気がする
関係者風を装って「まあ、例の件がポシャった所為で続編はPが総入れ替えなんですけどね。実の話」みたいな
相変わらずのどうとでも取れるような言い回しで利鞘を稼ぐ感じ
＞4Gamer的にはご無沙汰しております，切込隊長こと山本一郎でございます。
＞年末商戦で据え置き機向けに企画協力したタイトルはほぼ全滅したということで，
＞葬式のような新年会や，針のむしろのような予算会議を経まして，ようやく記事執筆の気力が生まれてきたところであります。
＞まあ厳しいのは据え置き機向けだけで，プロジェクトの委託を請ける私の側はあんまり腹は痛まないんだけどね。
＞http://www.4gamer.net/games/000/G000000/20100202054/
かみさん食わせてかないとマズいのはわかるが、
こんな「どうも！ゲーム業界の重鎮こと切込です！」みたいな自己アピールじゃ
またネオ丸ごと事件の二の舞・三の舞だぞ
521 ：名無しさん＠お金いっぱい。：2010/02/05(金) 07:49:34 ID:WuMIDbZ90
＞kirik 利権そのものじゃないか（棒
＞ RT @tsuda 1回2時間くらい話してたかが2～3万円とかもらってるのを
＞「Twitter利権」とか言われてもなぁ……。キャバ嬢の方がよっぽど稼いでるよ。
津田さんに相手されるまでイヤミ言い続ける山さんカッコワロス。
522 ：名無しさん＠お金いっぱい。：2010/02/05(金) 08:08:25 ID:tb/trvKH0
津田はネットランナーなどでwinnyの使い方を書いてた元二流ライターだぞ。
MIAUという団体のトップをやってるけど、
その団体もきな臭い話がある。結成当初からもめてる。
金銭的利益を得ないボランティア団体ではなく、寄付金は給料として使ってる。
twitter利権って俺でも言いたくなるよ。津田にじゃなくてtwitterの普及伝道をやってる人、全てに対して。
もちろんソースのない怪しいtwitter調査データを出してみんなを吊り上げた山本にも同じように言いたい。
523 ：名無しさん＠お金いっぱい。：2010/02/05(金) 08:30:14 ID:WuMIDbZ90
＞522
津田さんが「元二流ライター」なら、
山さんは「現三流ライター」では？
524 ：名無しさん＠お金いっぱい。：2010/02/05(金) 08:49:32 ID:X/U26Qgv0
＞522
525 ：名無しさん＠お金いっぱい。：2010/02/05(金) 13:28:53 ID:a69aWQwv0
http://changi.2ch.net/test/read.cgi/market/1258002654/508-
記者「世論はマスコミによって操作されていると言うことですか？」
ttp://cherio199.blog120.fc2.com/blog-entry-2574.html
153 ：仕様書無しさん：2010/01/19(火) 01:10:54
記者「世論はマスコミによって操作されていると言うことですか？」
民主「その通り。報道によって本来の人格も無視されて悪役にされている。」
民主「操作された世論に、野党が乗じて国会を空転させるなど日本の未来のためになりません。」
民主「そのような事態を国民の皆さんが望んでいますか？国民は真実を理解して欲しい。」
記者「ありがとうございました。以上、麻生内閣についてお聞きしました。」
民主「ちょっとまて！」
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
仕様書を残さない理由が一切理解できないんだが。
例えば、詳細な仕様書を残す事で、他にもっと安い値段で出来る人材を探してくるのだろうか？
それなら最初から仕様書だけ書く奴を雇うか外注すれば良くないか？その方がよっぽどコストがかからないだろ。
と言う事を上司が理解できてないんじゃないか？
そもそも、親会社のSEが子会社のSEより無能だというのも考えられないんだが。
親会社なんだから、相対的に見て能力がある奴が入ってくるだろうし。
「仕様書が書けるのに時間が無くて他者に依頼する」という理屈も違う気がする。
仕様書なんかは能力・経験がある奴が書いた方がバグが少ないし、
開発する奴が書いた方が早く・正確な物が出来る。
だから、そのオチにはならないと思うんだけど。なるならよっぽどのブラックだなw
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。
適切の基準が曖昧でプロジェクトによってことなるのもその通りです。
エンジニア的には正しくても、会社的に正しくないことがあり元増田のおっしゃる通りだと思います。
王道が共通化というのは訂正します。
ただエンジニア的には共通化は正しく、
エンジニア上がり人は取り締まりに役になってもこんな事言ってたりします。
http://d.hatena.ne.jp/iad_otomamay/20090413/1239632703
内部設計の段階で、内部設計書書いて(or担当者に書かせて)してはどうでしょうか？
そして、そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間と
レビュー実施するようにすべきだと思います。
実装されているか(共通化を含む)項目つくるものだと思うのですが、
内部設計書は作ってないのですか？
担当者のせいばかりにしていても解決しない問題と思っています。
俺も似たような経験がある。
入社当時俺はミスをした。
で、なんでこんな簡単なミスをするの？
改善策とか考えている？
などなど似たような事聞かれて黙って聞いていたわけですよ。
で俺はそれを聞き返したんですよ。
これ作った人よんできてもらっていいですか？？
しかもこんな簡単なミスと言いましたがそもそもこんな簡単なオペミスを仕組化できてないのにシステムのリリースokだした馬鹿上司呼んできてください。
これそもそも、仕様に含まれていて、テスト仕様書に含まれていたんでしょうか？（ないことわかって聞いた）
でおたく重要なシステムといったけど、こういう状況を許している会社の体質そのものが問題ではないのか？
それをわたしが修正するのか？作った奴の技術力不足が起きた問題ですよね？
全てのわたしの問いに答えてもらっていいですか？
その回答でおそらくどこを直せばいいか会社組織の問題点がわかると思います。
あとはドリルダウンで問題点を洗い出せばいいのではないでしょうか？
こういうオペミスは絶えないので仕組化は必須で、重要なシステムならなおさらですと。
突き返した記憶あるな。
会社全体がそういう空気でそれなりに儲かっている会社でうまくいっていると経営者が勘違いすると社員が休職と退職の連鎖が起きるんだよ。
ウチのＨＰへＮ×Ｔ××がアクセスしてきて、何だろうと思ったらインストーラの記事を昔Blogで書いた事があって、それへのアクセスだった。
ちなみにウチのページはモロおたくな同人作家のページだが、１年に１度ぐらい、プログラマとしてのグチを書く。
VisualStudioについてるヤツとか、フリーソフトのとか、ああいうので日本企業が出すソフトのインストーラを何とかしようったって、無理なんだよ。うん。
PCが判らない人が仕様書作るんだから、PC判ってる方々が作ったインストーラと仕様が一致するはずがない。
日本のソフト上流工程の方は「途中で電源断」とか異常に拘る。インストールしなおしでいいだろ？でも連中は電源再び入れたら再びインストール再開とか仕様書に書く。
電源断した時と電源再開した時のユーザが違ったらどうなるか？当然そんなの「想定外」とか言って「あとまわし」とか言って、結局「ごめんなさいこの仕様マズかったね」となる。
日本でインストーラに拘る現場で必ず通るパターンだ。ざけんな糞。
インストーラ開発したいんだったら、雇ってくれりゃすぐ作ってあげられるよ。VC++スクラッチでね。ものすごい細かい挙動まで全部制御する。明らかにPCの中身を知らない人の仕様でも、ある程度までは実現してあげられる。
でもＮ×Ｔ××じゃ仕事したくない。実は昔揉めたから。72時間耐久デバッグに１人で挑まされた事は忘れない。マジで忘れない。
っていうかそもそもN×T系列って開発全部止めてるはずなのに、どうしてアクセスあったんだろう？
N×T、開発復活したのかなぁ。
仕事は開発だけどたぶん好きでも嫌いでもない仕事。プログラムが動けばうれしいけど、正直仕様書とか書いているのはかなりげんなりする。その横では後輩がプログラミングをやっているし、そういうとき、頭をよぎるのは「自分ってただの雑用係じゃねーの？」という想像というか妄想。
まあ、そんなこんなで仕事が続き、趣味は自分の健康のバランス（＝ストレスの解消）を取るためにやっている所もあるのだけれども、それをやろうという気力が萎えているのが怖い。死人のようにただただ眠っていたいだけ、という状態になっているから、余計にストレスが取れず。何か世の中に置いてけぼりにされているような気すらしてくる。
こういうのは年齢的なものなのか？それともデスクワークばっかりで体力がないから？
内蔵も調子が悪く、内科、心療内科に行って薬を処方してもらったりしたが、この気力のなさはなんというか半端なくて、特に改善されたとは思えない。
仕事は…頑張って当たり前、というのは勿論だけれども、ついていくだけで精一杯という気持ちを押し殺しながらやっている。こういうのが良くないのだろうか？
鬱の前触れだろうか？
・その人材を適所にあてはめる。
・人々の士気を保つ。
・チームの結束を強め、維持する。
・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。
・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。
・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。
・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。
・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。
・さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。
つまり……
心で指揮をとる。
組織に魂を吹き込む。
くだらないものを嗅ぎ分ける鼻を持つ。
・戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。
・採用には、管理に必要な身体の器官、心臓、魂、鼻、腹をすべて使う（しかし、腹が大部分だ）。
・一人でやろうとするな。二つの腹には、一つの腹の２倍以上の力がある。
・新しく採用した人材には、１回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。
・意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。
・話すより聞け。
・短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。
・短期的な効果を約束するものは、いんちきである可能性が高い。
・やる気のある態度を常に引き出そうとしない人物をリスク管理人に任命せよ。
・悪い話が上層部に伝わりやすい経路（匿名性など）を作っておくこと。
・無駄を減らす。
・成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。
・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。
・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する（本人たちにその意思があれば）。
・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす。
・プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。
・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。
・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。
・実際の結果と照らし合わせてモデルを調整する。
・病んだ政治はどこにでも、最も健全な組織にも出現する可能性がある。
・病んだ政治の決定的な特徴は、個人の権力と影響力の目標が、組織の自然な目標より優先されることである。これは、病んだ目標が組織の目標と相反する場合でも起こりうる。
・病んだ政治の副作用の一つは、少人数のプロジェクトを抱えることが危険になることである。
・単位を気にするな。客観的な尺度ができるまでの間は、主観的な単位を使えばよい。
・手に入るすべての基本要素（ソフトウェアの数量化可能な特徴）をもとに合成尺度を作成する。
・考古学的データを収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。
・合成尺度の公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。
・過去のデータベースをもとにトレンド・ラインを引き、予想される労力を、合成尺度の値の関数として示す。
・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンド・ラインから予想される労力を割り出す。
・生産性トレンドのノイズのレベルは、予測を立てるときの誤差の目安にする。
・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然な目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。
・形式的なプロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトでプロセス改良の為に費やされた時間を相殺できる可能性は低い。
・プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。
・プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数の技能改良プログラム（たとえば、全般的なＣＭＭ等級の引き上げ）は、プログラムを実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。
・標準的なプロセスの危険な点は、人々が賢明な省略を行う機会を失わせることである。特に、人員過剰のプロジェクトの場合、標準的なプロセスによって全員に行き渡るだけの仕事（役に立とうが立つまいが）が発生するなら、標準的なプロセスが厳密に守られてしまう。
・デバッグの時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。
・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
・相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
・一時的なプレッシャーや残業は、人々の商店を定め、その仕事が重要であるという認識を高めるには有効な方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。
・管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからないから、または、ほかの方法の難しさにひるんでいるからである。
・おそるべき推測：プレッシャーや残業を使うほんとうの理由は、プロジェクトが失敗したときにごまかすためかもしれない。
・管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる（虐待された子供が自分の子供を虐待するようになるのと同じ）
・管理者が部下を侮辱すると、それが刺激となって部下は自分の仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」である。しかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。使用を明確にする最初の一歩にもならない。
・仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである。
・開発に複数の当事者が関わっている限り、利害の対立は避けられない。
・対立は尊重すべきである。対立はプロらしくない行動のしるしではない。
・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベルで勝利条件を引き出すようにする。
・勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。
・触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても（通常はほかにもいろんなことをするが）、触媒の役割は重要で貴重である。
・仲裁は、触媒の役割の特殊なケースである。仲裁はわずかな投資で学習できる。
・「あなたたちの仲裁をさせてもらえますか」というささやかな儀式の開始が、対立解決の本質的な第一歩になることがある。
・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。
・初期に人数が多すぎると、プロジェクトは重要な設計作業を省略せざるをえない（全員に仕事を与えるため）。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。
・このため、相互依存性が高まり、会議が増え、やり直しが増え、フラストレーションがたまる。
・理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤（プロジェクト期間の最後の６分の１ぐらい）に人数を大幅に増やすというものである。
・おそるべき推察：無茶なスケジュールを達成するように決められたプロジェクトは、妥当なスケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。儀式は、小規模な会議や無欠点運動など、プロジェクトの目標と理想に目を向けるために使う。
・注意：怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである。
・考察：怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる（これは怒っている人の問題は解決できないが、ほかの人の悩みは軽減できるだろう）。
・病んだ政治を下から治療することはできない。むだな努力で時間を浪費したり、自分の立場を危険にさらす必要はない。
・問題が自然に解決するか、行動するチャンスが来るのを待つしかない場合もある。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。
・それは、組織の自然な目標である繁栄と福祉の精神とは正反対である。
・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。
もう契約満了から2年経過したし、そろそろ話してもいいかな、と思ったのでこちらに。
同人ゲームやらそうでないゲームやらお手伝いする中で、当然開発に至らなかったゲーム、というのも存在する訳です。
謝礼も振り込まずに素材だけ受け取って逃げた、とかなら別の話なんですが、素材開発も完了して、依頼料も受け取って、それでも開発完了と至らなかったケース。
これはこれで今考えるととても厄介だよなぁ。
謝礼を頂いてしまった手前、僕はあれこれ主張する立場にはないし、相手を避難する立場には無いので、どのような扱いを受けても文句を言ってはいけないのですが。
やっぱりお手伝いした立場としては、製作したデータが表に出ずにそのままお蔵入というのは悲しい。僕にとって最初の同人活動だと思うと尚更です。
あくまで僕はお手伝いをしただけであって、その素材がどのような扱いをうけたとしても、それは依頼主の裁量だと思っているのでなんとも言えないのです。
幸いなことにそのゲームの事前評価がよかった手前、それで次の依頼や後に繋げることができたので、ノウハウも勉強出来たぶん、全体的に見れば成功だったんだと思うのだけど。
どうしても心に蟠りとして残っているのがアレなんだろーと思います。
そりゃあ開発では自分も未熟（今もだけど）だったので色々と衝突したこともあったし、依頼主もプライドの高い方だったので喧嘩になったこともありました。
まぁ今になって考えれば、僕等の立場とすれば依頼主のイメージを形にするのが第一であって、あまり自身を主張してはいけない（担当部署としてもそうするべきだった）立場にあったので、依頼主にあれこれ文句（ex;マトモな仕様書を出せ）を言ったのは間違いだったと思います。
今はみんなでわいわい楽しく同人やろう、なんて気持ちはもう無くて、割り切って作業として考えるようにしたので精神的負担はかなり減ったのですが、当時はまだそんな気持ちも残ってたのでやっぱり精神的に負担になりすぎたってのはあります。どうしても言葉尻がきつくなってしまって、依頼主のプライドを傷つけてしまいがちになってしまいました。立場はわきまえるべきだと今では反省しております。
立場をわきまえた上での話ですが、それでも開発終了に至らなかったのはシナリオ担当兼リーダーの責任です。
自己評価が苦手なので自身についてはあれこれいうのは控えますが、あのプロジェクトに関わっていた自分以外のスタッフは極めて優秀だったと思います。どのスタッフもセミプロだったりプロだったりする方々で、少なくともヴィジュアル面においては、他の追随を許さない出来でした。結局完成しなかった今、何を言っても絵に描いた餅でしかないのですが、完成していれば、ヴィジュアル面だけでも相当の評価を得ていたのは間違い無いと思います。これだけ優秀なスタッフを抱えていて、それでも完成しないとすれば、それはやっぱりリーダーの責任としか言いようがありません。リーダーがあまりにも未熟過ぎたのが開発失敗の原因なんだと思います。
集団作業で製作される作品の失敗、成功はリーダーの能力に左右されます。今回の件ではまさにリーダーの能力が失敗の原因なんだと思います。
仕様書もまともに出さない、質問する度に説明が違う。曖昧な指示、一部スタッフとの過剰な癒着、リーダーのプライドの高さ。数々の問題があったと思います。
というかリーダーは某スレのやめとけ基準全てに当てはまるような地雷だったわけだし
その辺を見抜けなかった自分も未熟だったといえばそれまでの話なのだけれど。
まぁ二度と製作物が日の目に出ないのはあまりにも不憫だなぁー、と思う。僕だけの問題なら残念でもいいけど
他のスタッフ様にしてみても、貴重な時間の能力を費やして製作したデータが表に出ないのはつらいだろーなぁ。
その辺のことを他の方がどういう風に対処しているのかは知りたい所。
他にも色々と手伝わせて頂いているし、失敗した例にいつまでも取り憑かれているのはあれだから、どっかで毒を吐いて過去と決別しなければならない。それだけの話でした。
努力は無駄になるということはある程度覚悟して作業していくべきなのかもしれません。同人ゲーに関わらず、なんにせよそーなんだろーけど。
かと言って努力しない理由にはならないし。
まあ、あれだ。その、後輩がな、アニメ制作会社に受かって、んで、その様子を日々mixiに書き連ねているわけだ。
で、漏れはそれを見て「おー、がんばれよー！」と思っているんだが、同時に、こう、なんか言語化できない「もやもや」感をも感じるわけだ。
アニメ業界は薄給激務の場で、入ったからすぐにどうなる、というものではないが、彼女のその夢というか目標に向かって愚直なまでに突っ走る姿勢には考えさせられるんだよね。
翻って、おれなにやってんの？？？って。
地味なIT系会社に入社2年目。ハッキリ言ってスペックは低いし、1年目から出向させられたけど酷評。
テスト仕様書とかプログラミングとか意味不明なまま自分をすり減らして頑張ったつもりなんだが、世の中、なんらかの「成果」を出さないことにはそんなものはクソの役にもたたない無駄なんだよな。
で、まあ、仕事にモチベーションを感じられないんで、今こうやって増田ってるわけだが、こうやって大変な思いをして生きていくぐらいなら、人間やっぱり自分の好きなことやって大変な思いをしたほうがいいんじゃね？と思ったりもするわけだ。
が、自分の場合困った事に前述の彼女のような「アニメ会社に就職して○○を作りたい！！！」というような情熱がどういうわけか欠落している。別にアニメ会社に入りたい、というわけでもない。
だがこの「もやもや」感だけは残り続ける。これはなんだ？おれが、なんかを創りたいから？
けど、創ったところで、それが誰かに認められたり、何かを伝えるものじゃなければ意味もないと思っているんだよな。だから、自分で創作したものにも価値を感じられない。何かを伝えるほどの技巧がないから。
そういう発想こそが何か間違っているのに違いないのだが、どうやればこの「もやもや」感が消えるのか、皆目見当もつかない。
きっと、おそらく俺は「うらやましい」んだ。
今の自分の姿勢を疑わないような、自分の考え方と仕事の内容が一致するような仕事に就きたいと思っているんだ。
でもどうすればいいのかわからない＼(^o^)／ まさにこんな状態。
さてこんな「もやもや」を抱えた状態で明日（というかもう今日か）も仕事な訳だが、あれだ、生きるって、面倒くさい。今のおれにはそうとしか思えない。
http://anond.hatelabo.jp/20090519230327
とりあえずプロジェクトマネージャが作りたいシステムを語る。酒の席だったりする。
それを何となくSEに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「Amazonを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のシステム」を作る事になるとバグとか糞とか以前に完成しない。
そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。
決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の内容になる。（十字キーでリストが動くだけレベルとかシステムを一個だけそれっぽくしてるとか）
開発が始まると政治的なパワーバランスなどの都合により今まで作っていた何物かはゴミ箱に行くことに。でも「もう半分くらい作ったんだから簡単にできるハズ」等と言われる。ウィンドウズアプリだったハズが携帯のWEBアプリになったのに。（極端だけどハード変更はザラ。あまり大きな問題はない）
SEはまた初めと同じように内容を伺う。日を跨ぐと違うことを言うので出来るだけ素早く箇条書きにしてる。なかなかまとまらないがデザイナとプログラマはまた何かを作り出す。何を作るかは分からないが何となくキャラとか背景の枚数を妄想して分担表とかをつくる。プログラマも仮想工数表を作る。
放っておくと大量のデータ、大量の画面、大量の帳票、仕様のバグ、労力の割に効果があまりないような操作、壮大な計画がブチ上がってくるので必死で止める。
（仕様バグは仕様見ただけで分かるような無茶な物のこと。例えば100個のレコードから3つを合成してすべて違うテーブルが生成されて全部に名前と効果と属性が付くとか。16万通りもある事を理解できていない）
SEはこの段階で死にそうになっている。一応存在するSEの締め切りが迫ってくると当然毎日徹夜して仕様書を作成していくのだが、なんど書き直しても「つかえない」「ここはこういうつもりじゃなかった」「字にすると便利そうに見えないから名前を考えて」「（仮の）絵が気にくわないからインスピレーションが～」「やっぱこうの方がいい」「昨日いいこと思いついた」等の必殺技に返り討ちにされる。仮絵をデザイナに描いて貰っている場合はデザイナに頭を何度も下げに行く。SEの締め切りはもちろん守れられない。その分のしわ寄せはデザイナとプログラマがかぶることになる。毎日毎日両部門に目に隈を作ったSE勢が「間に合わなくて済みません」と謝っている。ただしデザイナもプログラマも怒らない。SEが遊んで遅れてる訳じゃないし。一緒に仕様固めを手伝う。
何となくあがってきたSEの仕様を眺めながら作る。ただし細かいことは何にも書いてない。オプション画面と一言だけ書かれているならましで、オプション画面の存在が伝えられていない事もザラ。その当りは必要そうな設定項目をプログラマが洗い出してデザイナが全体の空気を読んだ画面デザインを構築して己のインスピレーションを信じて勝手にプログラミングする。とりあえず作った物を見せると「俺の指示と違う」等と言われることが多い。指示なんかないのに。ただしこれがそのまま使われることも良くある。
開発が中盤に入る頃には仕様がしっかり上がって……いない。絶対。時間だけが無情にもすぎるが未だ路線が定まらない。分からないところは逐一聞きながら作る。聞かないでも作る。運が悪いと何故聞かなかったと言われる。デザイナはひたすらリテイクを食らう。コーポレートカラーと合わないとかこのボタンだけ浮いているとか。そもそもおれ孫請けだからリリースする会社がどこか知らないし。絵の枚数が気が付くと増えている。色数指定が破られている。容量が足りなくなる。プログラムで容量を何とかしろと言われる。もうたっぷり圧縮してる。
開発終盤。締め切りに間に合わない事が確定的になってから仕様をとりあえず削ってみる。最初からそれはいらないと言い続けた場所を削るがプロジェクトマネージャは不満顔。最初から入れなければもっと早かったのにと毎度毎度言い続けてるが変わらない。デバッグ期間は短くてもいいとか言い出す。それで前もバグを出しただろうに。やっぱりあそこが気に入らないから変えてとかこの期に及んで言う。デザイナは絵１枚当たり作業時間が割とはっきりしているのでギリギリまでリテイクされる。SEはテストデータを必死で打ち込む。「レスポンスが悪い。調整してないのか」とか言われる。その時間はお前が削ったんだ。プログラマは頻繁なデータの差し替えをしながらバグを潰していく。何度言ってもデータの差し替えはすぐ出来ると思われている。そろそろセレロンはやめて欲しい。デザイナもメモリが足りないので勝手に増やしている。バグは無理矢理潰す。みんな死にそうな顔をしているが激太りもしてる。
リリース前にプロジェクトマネージャが偉そうな顔して雑誌やブログにコメント。
リリースして失敗プロジェクトと言われる。世間一般的にバグれば販売元とプログラマのせいにされて（予算を出さなかったから、プログラマがミスをしたからと思われている）つかえなければディレクタやプロジェクトマネージャが批判される。（世間の（俺の）便利だと思っていることを理解できていない！とか）このために軸のぶれているプロジェクトマネージャやディレクタは上がってきた物が便利でないと感じると仕様変更をガンガン入れてくる。たとえバグっても内容が悪くなければ叩かれるのは自分じゃないもんね。時間と金をもって来ないのにこれをする人が時間を無駄遣いさせる。プログラマはバグを出したくないので仕様変更が出ないよう出ないよう事前に釘を刺しに行きたがる。
終わった頃には人数が減っている。そして募集が掛かっているｗ
とりあえずプロデューサが作りたいゲームを語る。酒の席だったりする。
それを何となくプランナに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「ポケモンを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のゲーム」を作る事になるとバグとか糞とか以前に完成しない。
そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。
決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の内容になる。（十字キーで絵が動くだけレベルとかシステムを一個だけそれっぽくしてるとか）
開発が始まると政治的なパワーバランスなどの都合により今まで作っていた何物かはゴミ箱に行くことに。でも「もう半分くらい作ったんだから簡単にできるハズ」等と言われる。DSのARPGだったハズがPSPのSRPGになったのに。（極端だけどハード変更はザラ。あまり大きな問題はない）
プランナはまた初めと同じように内容を伺う。日を跨ぐと違うことを言うので出来るだけ素早く箇条書きにしてる。なかなかまとまらないがデザイナとプログラマはまた何かを作り出す。何を作るかは分からないが何となくキャラとか背景の枚数を妄想して分担表とかをつくる。プログラマも仮想工数表を作る。
放っておくと大量のアイテム、大量のイベント、大量のモンスター、仕様のバグ、労力の割に効果があまりないような話、壮大な計画がブチ上がってくるので必死で止める。
（仕様バグは仕様見ただけで分かるような無茶な物のこと。例えば100個の素材アイテムから3つを合成してすべて違うアイテムが錬成されて全部に名前と効果と絵が付くとか。16万通りもある事を理解できていない）
プランナはこの段階で死にそうになっている。一応存在するプランナの締め切りが迫ってくると当然毎日徹夜して仕様書を作成していくのだが、なんど書き直しても「つまらない」「ここはこういうつもりじゃなかった」「字にすると面白そうに見えないから名前を考えて」「（仮の）絵が気にくわないからインスピレーションが～」「やっぱこうの方がいい」「昨日いいこと思いついた」等の必殺技に返り討ちにされる。仮絵をデザイナに描いて貰っている場合はデザイナに頭を何度も下げに行く。プランナの締め切りはもちろん守れられない。その分のしわ寄せはデザイナとプログラマがかぶることになる。毎日毎日両部門に目に隈を作ったプランナ勢が「間に合わなくて済みません」と謝っている。ただしデザイナもプログラマも怒らない。プランナが遊んで遅れてる訳じゃないし。一緒に仕様固めを手伝う。
何となくあがってきたプランナの仕様を眺めながら作る。ただし細かいことは何にも書いてない。オプション画面と一言だけ書かれているならましで、オプション画面の存在が伝えられていない事もザラ。その当りは必要そうな設定項目をプログラマが洗い出してデザイナが全体の空気を読んだ画面デザインを構築して己のインスピレーションを信じて勝手にプログラミングする。とりあえず作った物を見せると「俺の指示と違う」等と言われることが多い。指示なんかないのに。ただしこれがそのまま使われることも良くある。
開発が中盤に入る頃には仕様がしっかり上がって……いない。絶対。時間だけが無情にもすぎるが未だ路線が定まらない。分からないところは逐一聞きながら作る。聞かないでも作る。運が悪いと何故聞かなかったと言われる。デザイナはひたすらリテイクを食らう。世界観と合わないとかこのキャラだけ浮いているとか。世界観なんて説明書の2ページ辺りに描かれてる物語程度にしかなかったりするし。絵の枚数が気が付くと増えている。色数指定が破られている。容量が足りなくなる。プログラムで容量を何とかしろと言われる。もうたっぷり圧縮してる。
開発終盤。締め切りに間に合わない事が確定的になってから仕様をとりあえず削ってみる。最初からそれはいらないと言い続けた場所を削るがプロデューサは不満顔。最初から入れなければもっと早かったのにと毎度毎度言い続けてるが変わらない。デバッグ期間は短くてもいいとか言い出す。それで前もバグを出しただろうに。やっぱりあそこが気に入らないから変えてとかこの期に及んで言う。デザイナは絵１枚当たり作業時間が割とはっきりしているのでギリギリまでリテイクされる。プランナはデータを必死で打ち込む。「戦闘バランスが悪い。調整してないのか」とか言われる。その時間はお前が削ったんだ。プログラマは頻繁なデータの差し替えをしながらバグを潰していく。何度言ってもデータの差し替えはすぐ出来ると思われている。そろそろセレロンはやめて欲しい。デザイナもメモリが足りないので勝手に増やしている。バグは無理矢理潰す。みんな死にそうな顔をしているが激太りもしてる。
発売前にプロデューサが偉そうな顔して雑誌やブログにコメント。
発売して糞ゲーと言われる。世間一般的にバグれば販売元とプログラマのせいにされて（予算を出さなかったから、プログラマがミスをしたからと思われている）つまらなければディレクタやプロデューサが批判される。（世間の（俺の）面白いと思っていることを理解できていない！とか）このために軸のぶれているプロデューサやディレクタは上がってきた物が面白くないと感じると仕様変更をガンガン入れてくる。たとえバグっても内容が悪くなければ叩かれるのは自分じゃないもんね。時間と金をもって来ないのにこれをする人が時間を無駄遣いさせる。プログラマはバグを出したくないので仕様変更が出ないよう出ないよう事前に釘を刺しに行きたがる。
終わった頃には人数が減っている。そして募集が掛かっているｗ
たくさんのコメントありがとうございます。まさかこんなにと驚いています。某氏からの反応も合ってとても嬉しいです。せっかくなのでいくらか追記してみたいと思います。
仕様バグの話はネタではありません。頻繁にあることで実際に一度や二度ではなくそれがありました。私の経験では数億通りのパターンが生まれる仕様バグでした。なんでこんな事になるのかというと、仕様を考えている人が数学が不得意だから……ではなく数字を計算する癖がないからだと思われます。どんな仕様でも数字が出てくれば相応の計算を一応するといった癖がないので平然とこのような仕様が出てくるのです。
この日記は上が悪いように書いてます。私はお察しの方も多いようにプログラマです。プログラマの悪いところももちろんいっぱいあります。都合の悪いことは直接上に言わないでプランナに押しつける、データ入力時の細かい事項をプランナに教えない。遅れたのはプランナのせいだと後になって愚痴る。デザイナが指示したとおりの仕様でデータをくれない！……とプランナに愚痴る。基本プランナさんごめんなさいなのが多いですね。デザイナはデザイナで上のチェックをせずに提出したり仕事してる振りして同人描いてたりしてます。他にも色々あるそうですが細かいことは知らないです。プランナは上からの変更を周りに伝えない資料に必要事項を書かない等など。
＞これでも採算撮れるなら仕方ないなー。
細かいことは上の人間じゃないので知りませんが、赤いのは赤いです。根拠はいろいろですが、わかりやすいのは給料遅配とか。
良作はどうなるかというと本筋の流れは大して変わりません。先にお断りさせて頂きますと私は良作の制作にほとんど関われたことがありません。本当にちょっとちょっとちょっとちょびっとした良作程度の経験でお話しします。
予算や行程にゆとりがあってもより良い物をと仕様変更はガンガン入ります。むしろ入らない作品はつまらない物になります。（某氏らが言うように普通に作っていればだいたい糞ゲーです。）というのも一番最初に上がってきた構想がそのまま「誰が聞いてももの凄く面白い！ これは売れる！」なんて事はないと思うからです。（思うというのは知らないと言うことです。そういうすごい構想を語れる人もいるのかもしれませんが）なので仕様書を作るときも実際に制作を開始してても、例えバグフィクスをしながらでもいろいろな変更が入ります。「入ります」という言い方では語弊すらあります。入れるのです。現場から積極的に変更をかけていきます。自分の納期が迫る中でも良い物を作りたいのなら自分の担当分に変更を打診します。嫌な目で見られるかもしれなくても、その人の睡眠時間がなくなろうとも、より面白くなるアイデアがあるのなら他人の担当分に変更を促します。そのアイデアが入れてみたらつまらなくて元に戻して欲しい場合は、相手が死にそうな面をしていても戻そうと言います。最初から最高の物を構想できれば必要がないことなのですが、現場も上もそろって天才なんてことはないので、以上のようにするのです。そのようにして出来たゲームが余裕で糞だったりしますが。
糞ゲーは現場からの仕様変更がない、上の言うことを聞かない下が悪いのか、下にそっぽを向かれる上が悪いのかわかりませんが下が上に何も言わなくなってしまう状態だと非常に良く起こりえると言えます。何故こうなるのかというのは普通の会社と一緒です。評価してくれない。給料が上がらない。手柄を横取りされる。売れれば俺のおかげ売れなければお前らのせい。そんなことですね。「糞ゲーだろうとバグゲーだろうと俺の給料変わらないし」のようになるんですね。これを職務放棄だと言われる方がいると思いますが、まさにその通りです。ダメダメです。
ちなみに知らないですが、上から下に何も言わないような場所は最初からダメでしょうね。そんなにトップから末端まですべての人が自己管理完璧のスーパーマンなわけないですから。なので厳しいプロデューサやディレクタは絶対必要条件です。この日記のプロデューサやディレクタは気まぐれだったり本当に適当だったりもありますが良い物を作ろうと変更をしている……と思います。問題は厳しくても他でフォローできる、もしくはその役割を担当できる人がいること、もしくはそれに耐えうる強い精神力および目標とか夢がある事じゃないかなと思っています。徹夜してる人にコーヒー買ってくるくらいのなんでもない気遣いでもいいんですけどね。あんまりやるとつけ上がりますがｗ まぁ、どれもないから辞めるんですね。
最後に私も上からの視点で書いた記事を読んでみたいです。分かって欲しいとか言っても無駄とかそういう気持ちみたいなのはどうでも良くて、ただの事実として。
