同人ゲームサークルここだけはやめとけ！【55】

企画者ですから当然、企画を通さなければ仕事はできません。
適当なメモや、 熱弁で現場のラインを任せてもらうことはありません。
「俺はこんなにおもしろいと頭のなかでゲームを楽しんでいるのに、どうして作らせてくれないのだろうか」
……まあ、こんなアホなやつはプランナーとして採用されないと思いますが、
とにかく企画書を書いてプレゼンテーションをクリアしなければ、プランナーとしての明日はないのです。
しかし、この企画書を書くのがメチャメチャ難しいのです。
いや、むしろ、頭内構想を企画書というかたちに押さえるというのが難しいといえるのかもしれません。
企画書は端的な構成・記述が適当だからです。

企画書の一文一文はすべてストレートパンチであり、
一節一節がすべてフィニッシュブローでなくてはなりません。
それくらい明快に、ズバッと決まる文章と構成で、初めて他人にアピールができるのです。

分厚く微妙な表現を満載した企画書は、それがどんなにおもしろい内容を示していても、
お偉いさんが途中で読むのをやめてしまいます。ですから、
複雑な要素を何となく楽しむゲームなどは、
企画書にまとめるだけでも大変なのです（そういうのが売れるかどうかも微妙なところ）。

中には完成された企画書を諦めて、作文レベルの書類を作り、
メインを口述で行なおうという人もいます。プレゼンテーションの口述はアピールのためにある
といっても過言ではありません。口述による補足ですら好まれないというのに、口述でひたすら説明。

これは以前、Ｈ氏が書いたように、途中で退席を言い渡されるのが普通です。
五分喋らせてくれたらいい会社ではないでしょうか……
（そんなことをして、翌日会社に席があるかどうかは知りませんが）。
でも、大手だと提出した企画書の審査レベルで落ちますから、そんなの。
まずプレゼンテーションに出席させてもらえないでしょう（そしてクビでしょう）。

プレゼンテーションをクリアすれば、次に企画を実働させるための作業に入ります。
この段階でスタッフが合流するわけではありません。ときどき間違って呼び寄せて、
無駄に人件費を浪費したり、現場のスタッフを錯乱させたりする企画者がいますが、
とりあえず「まわりを見ろ！」といったところでしょうか。
なぜスタッフを集められないのかというと、ゲームの内容が決まっていないからです。
いや、ゲームの内容は決まっているのですが、その内容が明示されていないのです。
そのためにはゲームの内容を書類化した「仕様書」を書き上げなければなりません。

また書類か、いったいいつ語らせてくれるんだ！とご不満かもしれませんが、
現場のスタッフに対しては永遠に語る機会などありませんので、
そのへんの観葉植物相手に語ったり論じたりしてストレスを解消してください。

ちなみに、業界人も心得たもので、語るとハイハイと聞いてくれる人も少なくありません。
ただし、いわゆる「右から左」というやつで、実際に頭に入れているわけではありません。
また、そんなことで現場のスタッフの行動を束縛するのはラインにとって損失でしょう。

悪いことは言いません、観葉植物に語ってください。

仕様書にはゲームのすべての動作が記されます。このときもはっきりと明快な文章か、
はっきりと明快な図示で書き記していく必要があります。
プログラマにある程度の権限を振れば薄くても良いのですが、
「このゲームは俺のものっ！」という企画者の場合は、要求される仕様情報は
ゲームの動作全般にわたり、Ａ４にして数百枚に膨れ上がります。

そこまでやっても、現場からは「なんだこれ、使えねえ！」とボロクソに言われます、
というより、

プログラマやグラフィックデザイナーたちは使えないときには
「使えない」と言われ傷つきながらも成長をしてきたわけですから、
プランナーも同じです。

また、仕様書にすると自分が想像していたゲームの動作だけでは、
まとまりが付かなかったり、矛盾していたりすることがよくあります。
これゲームの制作を開始したあとでは、アイデアの追加も削除も変更も、
まず無理ですから（発売日を延ばしたり、そのぶんだけスタッフに給料を払えるなら別ですが）、
紙の上で矛盾点などすべて潰し、ゲームを作りこまなければなりません。

まだ正社員のラインなら多少並行作業も許されますが、
外部に委託する場合は最悪です。自分の指示欠陥を後から訂正しようにも
まず受け入れて貰えませんし
（というか、普通の人なら恥ずかしくて訂正指示なんか出せませんけどね）、
個の領域を越えて会社が恥をかきかねません。

この仕様書制作、企画書を上回る技能力が必要です。先程も書きましたが、
文章による明示、図や絵による明示。基本的にはこの２つしかありません。
この２つで他人に動作を説明する力がなければ、仕様書は作れないのです。

えーと………
業界の方？

どっかからのコピペじゃね？　基礎中の基礎の一般論だと思うが

要約すると作りたいゲームがある奴がゲームメーカーに入ると鬱になるって事だ。

ま、メーカーも慈善事業じゃないしな。

私は、以前、かなり大規模というか、プロジェクトが大規模かどうかは知りませんが、
グラフィックだけはやたらに使うプロジェクトに従事したことがあります。

これは当然、社内だけでは片付かないということで、かなり早い段階で下請けに出しました。
ところが、下請けがなかなか現物をあげてきません。

当時は、制作進行の人が直接下請けの現場へ行って、ＭＯディスク（今ならＣＤ−Ｒなんでしょうけど）
に記録して戻ってくるという作業体制で進めていたのですが、制作進行さんが戻ってきたら
ＭＯがなぜかフロッピーになっていて、中を見たら、お詫びのテキストファイルが入っていた、
なんてこともありました。

下請けの人は、ウィットに富んだジョークかなんかのつもりだったのかもしれませんが、
私たちは純粋にムカつきました。ええ。

そのうち制作進行さんも、電話してモノがあるのかどうか聞いてから外出するようになってしまいました。
また、あがってきたモノのクオリティも酷く、私はチェックは相当甘いほうなのですが、
それでも許しがたい、専門学生の落書きのようなデキに怒りが沸騰し、
リテイク率が１００％に達した週もありました（つまり、一週間何も進んでないのと同じ）。

ドット絵に至っては、ファミコンのような酷さで、ハイライト色が“まだら打ち”してあるなど、
もうメチャクチャでした。

スケジュールは遅れに遅れ、プログラムのα版があがったのに、
こちらの進捗状況は５０％未満という有様でした。今思い出しても胃が痛くなります……。

プログラムの仕事より、グラフィックの仕事が遅れてしまったことは、
過去３回あるのですが、このときが一番遅れがひどかったものです。

本社で雇ったバイトさんの一人には、期間中、プログラムで必要なサイズに合わせた
ダミーばかり作ってもらうという仕事を延々とやってもらっていました。彼にも酷い仕打ちをしてしまいました。

トイレでプログラマとばったり顔を合わせてしまった日には、おしっこしながら平謝りです。
チーフプログラマに至っては、

「辞表用意してるか」

って真顔で聞かれるほどでした。
用意してました。

結局どこが駄目なんだよ

外注先の選定を誤った自分じゃないか？

まだら打ちってなんだろ。

最後の一ヶ月半は恥ずかしくて会社に出れず、同僚二人と一緒に、
原因となっている下請けに詰めていました。

そして、大変なショックを受けたのです。
その会社、本職のＧデザイナーは５〜６人しかおらず、残りの戦力はすべてアルバイト！！

個人外注にまで手を出しているではありませんか。
こっちはプロがやるもんだと思って外注に出していましたから
（そりゃバイトも多少は使うとは思っていたが）、
一体、なんのために外注に出したのか分からなくなってしまいました。

結果として、うちが最初からアルバイトとフリーランスの戦略で仕事を進めたほうが、
安かったのです。やつらは、こちらの営業が計算したマージンの倍以上は取ったはずです。

しかも、アルバイトと本職の仕事のそれぞれの割り当てはテキトーだわ、
作業の組み立ては考えてないわ、アルバイトは無断で休んでるわ、個人外注は回収できてないわ……。
遅れた原因はこれだったのか！！

次からは、どんなに大きなプロジェクトでも、自社でやろうと思いました。
どうせ下請けに出しても、そこからバイトを使われるのなら、
直接バイトを使ったほうがコストも効率もいいに決まってます。

結局、首の皮一枚というやつで、私のクビは繋がりました。シャレじゃないですよ、まったく……。

そして、この事例のお陰で次の仕事からはバイトの導入や、
フリーランスの導入がずいぶん進めやすくなったのです。

それを考えると、このプロジェクトはありがたかったのでしょうか……？　
ちなみに、私はまだ二十代で、このプロジェクトのときは更に若かったのですが、
このときは白髪が出ました。

きちんと管理する

アルバイトをどう管理するかは会社の方針によって違うと思いますが、
私のところは私たちのセクションの中で管理することになっていたため、楽でもあり、また面倒でもありました。

一番気をつけなければいけないのは、学生のバイトには無断欠勤が非常に多いということです。
割ときれいなフローを作っておいても、無断欠勤をされると、一気に流れがおかしくなってしまいます。

前項の下請け会社など、めちゃくちゃで、
無断欠勤しているにも関わらず、会社側がそれを把握してないなど、
まさにバイトさんのやりたい放題でした。

ということで、まず無断欠勤をなくすための管理を徹底します。

しかし、無断欠勤をなくすと、今度は電話一本で休みたいとかぬかしやがります。
これにしても、私たちにとっては予定外欠勤ということで、業務上は無断欠勤と変わるところがありません。

とはいえ、バイトさんにそのへんを徹底するのも難しいでしょう。
扱いがバイトなのに、仕事に執心しろとは言えません。

対策として、規模に応じて一日数人の欠勤をあらかじめ見こんでおき、
どの作業にも対応できる万能のスタッフを（正社から）その人数分割り当てて、
日ごろから浮かせておくと、欠勤で作業が滞ることがなくなります。

この対策は正解です。人手を浮かすなんてとんでもないと思われるかもしれませんが、
コンスタントに欠勤があるために（悲しいことですが）、
結果的にはほとんど人手を浮かすことなく、作業を進めていくことができました。

人間関係の衝突に気をつける

バイトを入れるということは、衝突しつつも出来あがってきたチーム（人間関係）に、
新しい空気を入れるということでもあります。

この場合、正社スタッフ同士の衝突や、正社とバイトさんの間の衝突は心配する
必要はありませんが、バイトさん同士の衝突に気をつける必要があります。

バイトとはいえ、技術能力職業ですし、バイトに来るのは学生さんが多く、
技術に自尊心を乗せているところがあり、普通の仕事より人間関係が摩擦を起こしやすいようです。

衝突を防ぐためのコツは色々あると思うのですが、
システムとしてとれる対策として、まず「私語禁止」があげられます。

それと、バイトが増えてくるとバイト同士で班を組ませて班長を決め、
その班長を管理することで管理効率を上げることになってくると思うのですが、
中途半端にこれをやると、かえって危険です。

私たちは、割とバイトに気を払わないため、すぐに衝突を起こさせてしまいます。
その結果学んだことは、この仕事に関しては、
バイトの間で優劣をつけると衝突の原因になるということです。

徹底してバイトの面倒を見るか、班を組ませたとき、
正社を班長に割り当てるかのどちらかがよいでしょう。
私たちは主に後者の方法をとっています。

バイトの間で色恋沙汰のトラブルがあったときは、正直参りました……。
ちなみに、新卒の正社員とバイトを接触させても危険です（ハア……胃が……）。

小説を書かない人も、趣味で小説を読むし、絵を描かない人も絵画鑑賞を趣味にできる。
だが、プログラマでもないのに、コードを読むことを趣味にする人はいないだろう。

大工の工事だって工事中の状態を見れば、目で分かるものだが、
プログラムの場合はそうはいかない。極端な話、プログラムの知識がない場合、プログラマに対して、

「働いているのかサボっているのか分からない」

という気持ちを抱くことさえあるという。ちなみにこの言葉は、
週１００時間労働をこなすプログラマに対して、実際に吐かれた暴言だ。

このような無知から、プログラマを他の職業と同様に扱って仕事の指示を振ったりする人もいれば、
逆に徹底的に敬遠する人もいる。

それで済む場合もあるが、済まない場合のほうが多い。
プログラマとうまく付き合うためには、プログラムを知る必要がある。

グラフィッカーやシナリオライター、営業やＳＥと付き合うのとは訳が違うのだ。
義務教育の経験だけでは心情に足を踏み入れることは出来ない。

プログラマはプログラムという仕事の特性に振りまわされる人種で、
考えられない時期に不機嫌だったり、思いもかけぬときに快調だったりする。

プログラムを知らない人は、プログラマを一瞬でムカつかせる能力に秀でている。
そして、自分がなぜ相手をムカつかせたのか理解できない。
プログラマに人生最高クラスの屈辱を与えても、
なぜ相手が怒っているのかすら理解できない人もいる。

アメリカ人に、意味も分からず中指を立ててファックユーと叫び、

「なんであのアメリカ人怒ってるの？　普通じゃないよ、あの人」

と言うようなもので、自分の感覚と文化が万人に通じると思っている類の人間だ。
こういう人は、若い人に多い。

一時、ゲーム業界でその日の気分で仕様変更を言い渡すゲームデザイナーの存在が問題になった。
彼らは「プロの領域」という言葉を駆使してプログラムを理解する努力を怠ったが、
我が国の法体系がハムラビ法典であったなら、
八つ裂きにされても文句は言えない所業であったことは言うまでもない。

463は読んだ事あるな。

これコピペじゃなくてこのスレ用に書いてんのかな
なかなか面白いテキストだけど

プログラムを理解していない人間が、しばしばプログラマに怒りを注ぐのが、成果物への認識だ。
最近はいなくなったが、ちょっと前までは、プログラムの成果物を、絵やシナリオと同様の
進捗性で求める人がいて、現場の火種になっていた。

プログラムはある程度仕事を進めると、急速に成果物が出来上がるが、
進捗度や開発方法によっては、なかなか成果物と呼べる状態まで仕上がらない特性のものだ。

彼らの中で、基礎設計や骨組み・棟上げといった、段階的な作業は進められるが、
プログラマ以外には、「裸の王様」の洋服のようにそれは見えない。

しかし彼らは物語に出てくるような詐欺師ではなく、立派な仕立屋だ。
それがプログラムなのだ。

また、プログラムの部分修正というのは、絵やシナリオの部分修正とは、
同音異義であるということを強く知っておかなくてはいけない。

プログラムの部分修正とはソース（過程）の部分修正であって、結果を部分修正するためには、
必ずしも作業が“部分”修正で済むとは限らないのだ。

先ほども書いたが、プログラマはコンピュータを制御し、
制御されたコンピュータが“仕事”をするという仕組みになっている。

「画面」と向かい合う人たちが、消しゴムで消して書き足すくらいのノリであっても、
実際の作業が同じようにクイックに済む保証はない。

プログラマは成果物以上に、その過程に美的感覚を注ぐ。
これはプログラムとプログラマの独特の感覚であり、よい例えが見つからない。

プログラマはそれを、

「美しい設計」
「美しい仕様」
そして、
「美しいコード」

と例える。これらの美しさは、どんな芸術品より彼らの心を強く引き付ける。
しかし、困っちゃうのが、プログラマ以外にはこの感覚がサッパリ分からないことだろう。

美しい設計と仕様くらいなら、ＳＥクラスならまだ理解できるが、美しいコードなんか本気で分からない。
機会があれば、プログラマに美しいコードと汚いコードを見せて貰うといい。
理解できないどころか、

「こんなので汚いだ美しいだ……こいつら頭おかしいんじゃないのか！？」

と思うことだろう。
美しいプログラムは、変更に強く、バグも少なく、スピードも速いという。
しかし、これも周りの人間には、どうでもいい話だったりする。
実際にどうでもよいはずがないのだが、繰り返すようにプログラマが
向かい合っているのは「コード」。それを見る人は、コードが制御する「結果」を見ている。

コンピュータが処理速度ぎりぎりの戦いを挑まれない限り、「コード」を美しく改良しても、
「結果」が美しくなるわけではない。

仕様変更はプログラマをもっとも苦しめる指令だ。
仕様変更にも大小があり、プログラマにとってダメージが大きいものと小さいものがあるが、
その大小はプログラムを知らないと分からない。

仕様書の１ページを書き換えただけで、プログラムの大半がご破算になることもあれば、
１０ページ書き換えても、

「いいっすよ」

と返されることもある。
ゲームや組込系は、微妙な変更で大ダメージをもたらしやすい。

ＳＥはともかく、ゲームデザイナー系の一部の人は、
「この仕様変更が、どんなに素晴らしい結果をもたらすか」
ということを熱っぽく説こうとするが、プログラマの心にはまったく響いていないことを知るべきだ。

優れたデザイナーやディレクターなら、プロデューサーに掛け合って日程と予算を確保し、段取りを用意する。
それがあって初めてプログラマを納得させられるのである。

また、ＳＥの場合は、営業に間を取り持って貰うと上手くいくことがある。
（会社によるが）営業の方が、仕様変更で苦渋を飲むプログラマの心情を、理解している場合が多いのだ。
しばしば営業のリップサービスが仕様変更の元凶になっているにも関わらず、である。

プログラムを知らず、プログラマを知らない場合は、彼らに親しい営業に相談してみよう。

プログラマほど出世が割に合わない仕事はない。
プログラマとうまく付き合うためにも、相手の肩書きや担当に気をつけたい。
プログラマは、全体の指揮を執るＳＥやディレクター、
プロダクトマネージャーといった人の下にチーフプログラマという役職が置かれる。

チーフの下にメインが付き、メインの下にサブが付くのが“たぶん”体系だ。
これは会社によって大きく違うので本当のところは分からない。

また、実際にはＳＥなどに仕切る力がなく、事実上、チーフが仕切りをやったり、
チーフという肩書がなく、メインがそれをやったりすることが少なくない。
プログラマは、最高の肩書であるチーフプログラマに近づけば近づくほど、
労働条件が急激に悪化する仕組みになっている。

特にチーフプログラマは開発主任というだけでなく、
なぜかプロダクト全体に対する責任を問われ易い仕事だ。

「ゲームデザイナーが失敗すればチーフプログラマが懲罰される」

という言葉があったほど、そのポジションは理不尽だ。上の言葉、
デザイナーをＳＥに置き換えてもかまわない。
プログラマは全フェーズのしわ寄せの終着点にあるため、
ついでに責任問題もしわ寄せされるということがあるのだ。

ゲームデザイナーが、チーフプログラマに責任をなすりつけるのを
テクニック化していた時期もある。ロンゲのアイツがたぎってた時代の話だ……。
今でもまったく無いとは言い切れない。

チーフプログラマは純粋な仕事量も多い。給料も多いが、負担が大きすぎて、
「損しているのか得しているのか分からない」
という状態に追い込まれてしまう。

純粋に管理だけやっていれば楽なはずだが、実際にはメインプログラマも兼ねるし、
コードの修正もしなければならない。
しかし、コードの修正は絵の修正や文章の修正とは違って作業量がメチャクチャ多い。
それがプログラムなのだ。

どんなに元のプログラマの個性や主張を重視しようとしても、
プログラムというのは一部変えようとするだけで、ザクっと一気にコードが持っていかれてしまう。
本当にこれは作業していても、「あれれ？」という感じなのだ。
「ここまでやるつもりではなかったのに……」
スタッフの構成次第では、チーフプログラマはマジ死に確定である。
このへんの事情を知っている人だと、
「チーフをやってみないかね」
と声がかかっても断るという。
しかし、断っても上にプログラマを置かれなければ、事実上、もっとも仕事ができるメインがチーフになる。

（ちなみに、ヒラのプログラマが楽な会社であればあるほど、
チーフクラスのプログラマはキツイ場合が多い。入社１〜２年の頃に、
「プログラマって意外と楽っすね」などと口走ろうものなら、主任に刺されるかもしれない）

バグ取りはプログラマにとって修行……いや、死業と言ったほうがいいかもしれない。
デバッグ期間中のプログラマは、生理中の女性より神経質で怒りっぽいので、取り扱いには注意したい。

デバッグと聞いて、デバッガ（ソフト）やモニタを用いたバグ取りを想像する人がいるだろう。
最近は組込系でも、監視デバッグが可能になる場合があり、確かに楽にはなった。

しかし、ゲームなどでは未だにデバッガ（ソフト）が使えない環境がほとんどなのである。
大学で培ったテキトーな知識で、

「必要な情報を printf すりゃいいじゃねーっスかー」

などとヘラヘラ言おうものなら、転蓮華で首をヘシ折られてしまうだろう。
ちなみに上記のせりふ、あるコンシューマ・ゲーム開発現場で実際に吐かれたものだ。
もうひとつプログラマを常に苛立たせるのが、デバッガの仕事だろう。

ここでいうデバッガとは、バグ出しを専門とするスタッフのことである。
たとえば、あるソフトのデバッグで３０日の間に１２０個のバグが出たとしよう。
報告書だけ読めば、「なるほど、１日に４個ずつバグが見つかったのだな」と思うかもしれない。

しかし、実際には、最後の５日で１２０個出る……といったようなケースがほとんどだ。
要するにデバッガというのはギリギリまで仕事をしないのである（断定）。
真面目なデバッガさんには申し訳ないが、プログラマのデバッガに対するイメージはそんなものだ。

プログラマにしてみれば、順次アップデートしていく過程のなかで、
「ああ、あの部分は複雑だったが、バグが出なかったんだなあ」
と思っていたところに、成果物提出、もしくはマスターアップ期に、
いきなり初期のバグを報告されることになる。

とっくに無事が確認されていたはずのコードだ。
そのときのプログラマの怒りを想像できないようでは、彼らとは付き合えない。

しかし、プログラマはなかなか表だって恨めないところもある。
そもそもバグというのは直近ではプログラマの責任だから（大元ではＰとかＤの責任だけどな！）、
逆上するわけにもいかない。だが、プログラムにはバグは必ず含まれるのだ！　
バグのないプログラムとは、バグがまだ出ていないプログラムに他ならない。

（もし、バグがまったくないプログラムを書いて渡してしまったら、
プログラマはどうなるか想像してほしい。喜ぶだろうか？　いや、恐ろしくて不安で夜も眠れなくなるだろう。）

それに、終盤期は他の仕事をアップしたスタッフがデバッグにあたることもある。
のんびりやられても文句は言いにくい……。それまでに地獄を見た連中なのだから……。
じゃあ、バイトのデバッガなら文句が言えるのかというと、それも、

「素人だしなあ……」

と思うと、言いにくい。それに、事態が進行した今、文句を言う暇があったらバグを突き止めなくてはならない。
それゆえに、デバッグ期のプログラマは不安定で、付き合いづらいのだ。

ちなみに言い訳ではないが、デバッグは作った本人以外の人間がやったほうが効率がよい。
これは教本にはよく載っている原則論のひとつだ。

ソフトウェア業界において、「マスターアップ」は、神聖で畏怖を感じさせる言葉だ。
冗談抜きで、この世の中に「マスターアップ」よりキツイものはないと思う。

神を信じない者も、このときばかりは神に祈る。
その負担が最もデカイのがプログラマだ。

マスターアップの驚異を感じられない者は、せめて「マスターアップと〆切は意味が違う」、
ということだけは知っておきたい。
プログラマは「マスターアップ」という言葉に、複雑で巨大な感情を抱く。

これまで以上に積み重なる判断と調査とコーディングと焦燥感。
体力以上に精神力を消耗することになる。
あるプログラマは言う。

「３倍界王拳っっ！！」

意味は分からないが気持ちは分かる。
ビジネス系ソフトなら、難無くマスターアップに漕ぎ着けることもあるが、普通は荒れる。

ビジネスソフトにはゲームにはない「合法な」仕様変更が異常に多く、
マスターアップ時に大変な問題を引き起こすのだ。
下請け孫請けもゲームよりよほど複雑なので、分離開発したものが、

「実機に乗せたら動きませんでした」

ということもよく起こる。まあ、これはゲームでもよくあるけど……。
ゲームはゲームで、会社によっては本当にメチャクチャだったりする。

出前途中のそばを全部ひっくり返してしまったが、それをまたかき集めて、
体裁をとりつくろってお客様にお届けする……。
そんな例えがピッタリくる。

また、マスターアップには、これまでのツケが必ず噴出するという凄まじい特性を持っている。
例の美しいプログラムの真価が（プログラマに対してだけ）発揮されるのもここだ！

プログラマを中心に人間関係は大荒れする。
ここで、ＳＥとかゲームデザイナーの類が、

「こんなときだからこそ、力を合わせてがんばろう！」

などと言った日には、殺人キャメルクラッチで二ツ折りにされてしまうので注意が必要だ。
……マスターアップについて語ると、本が一冊書けてしまうので、ここまでにしておく。

だが、このマスターアップという独特の儀式があるからこそ、
プログラマの損壊率が一層高まっているのは間違いない。

終わった？
面白かったよ。
自分もプログラマだが、いろんな人に読んでもらいたい文章だ。

プログラム知らない人は、気楽に「バグはないだろうね？」とか、
「バグだけは止めてね」とか言うけど、ありえないよな。

何がありえないって、「バグが無いこと」を保証するのは、プログラマの役割ではないから。
上位階層の人が、「動作（仕様）」を決定して、品質保証部門辺りが「検査要領」を決定。

プログラマは「仕様」通りにプログラムを組む。
「検査要領書」には、プログラムの動作をチェックする要領（方法）が記されていて、
そして検査に合格すれば、そこでプログラマの仕事は完了だよ。

検査に合格した後、コードの修正が言い渡されたら、プログラマは「メンテナンス作業」として、
改めて費用を請求することになる。
検査に合格した時点で、プログラマは仕事を果たしてるからね。

ダメな仕事環境だと、「仕様書」「検査要領書」の両方をプログラマが書いてる。
プログラマが自分に「ＯＫか？」と聞いて自分で「ＯＫだ！」と答えてる状況。

プログラマのモラルに全てが依存しているわけだけど、同人では「品質保証部門」なんて不可能だよね。

そしてネット上において、プログラマは「最大限の譲歩」として今日も「仕様書は何処ですか？」と
尋ねて回るのであったとさ・・・

長文、駄文スマソ