業界へ就職した
いあなたへ
現在 運用テスト中です。文中のバックナンバーへのアンカーなどは機能しません。
プログラマと付き合う
WRITTEN BY ソリッドウェブ
2003/01/19 rewrite
お業界で、もっとも厳しいのはアニメ制作進行だ……。
しかし、純粋な労働内容で比較すれば、プログラマも負けてはいない……。
プログラマ……。
パソコンが普及する時代の前からパソコンをいじって変態呼ばわりされ、
時代が来ればＩＴ時代の騎手とか言われて、特攻を繰り返させられる……。
その就労条件は、業界や会社の体質によって大きく異なるが、基本的にはひどい。
いや、ひどいというのも視点次第かもしれない。
プログラマは時給換算すれば、少し低賃金の印象があるが、他の仕事に比べれば稼いでいるというのが正直なところだ。
「生活は何の心配もしなくていいから、安心して死になさい」
というのがプログラマの典型的な環境だろう。
そして実際、プログラマの損壊率・死亡率は非常に高い。
一時、デスクワーク業最高の死亡率と言われていたほどだ。
アニメーター以上の職人意識を持つといわれ、なにより仕事の特殊性から、理解されがたいプログラマ……。
しかし、ソフトウェア産業ではプログラマの性質を理解せずして、共同戦線は築けない。
■無縁の心理
人は人生の中で一回は絵を描いたり、作文を書くので、グラフィッカーやシナリオライターの仕事と心情を察することは不可能ではない。
しかし、プログラムは違う。やらない人は永遠にやらないし、義務教育でやらされる内容も、絵や作文に比べてグッとレベルが低い。
また、文章やグラフィックに比べて、入力と出力の直結性が、知識のない人には理解しがたいところもある。プログラマは、コンピュータを制御・操作し、コンピュータがプログラマの書いた指示書ともいえるプログラムを読む取って彼らの意図すること（また意図しないこと）を表現させる仕事だ。
誤解を恐れずに言えば、プログラマは直接的にはコードと向かい合っている。絵描きや物書きは、紙の上で作ったものをそのまま他の職業の人に見せることも出来るが、プログラマがエディタ上で打ち込んだコードは、プログラマでなければ理解はできない。
小説を書かない人も、趣味で小説を読むし、絵を描かない人も絵画鑑賞を趣味にできる。
だが、プログラマでもないのに、コードを読むことを趣味にする人はいないだろう。
大工の工事だって工事中の状態を見れば、目で分かるものだが、プログラムの場合はそうはいかない。極端な話、プログラムの知識がない場合、プログラマに対して、
「働いているのかサボっているのか分からない」
という気持ちを抱くことさえあるという。ちなみにこの言葉は、週１００時間労働をこなすプログラマに対して、実際に吐かれた暴言だ。
このような無知から、プログラマを他の職業と同様に扱って仕事の指示を振ったりする人もいれば、逆に徹底的に敬遠する人もいる。
それで済む場合もあるが、済まない場合のほうが多い。
プログラマとうまく付き合うためには、プログラムを知る必要がある。
グラフィッカーやシナリオライター、営業やＳＥと付き合うのとは訳が違うのだ。義務教育の経験だけでは心情に足を踏み入れることは出来ない。
プログラマはプログラムという仕事の特性に振りまわされる人種で、考えられない時期に不機嫌だったり、思いもかけぬときに快調だったりする。
プログラムを知らない人は、プログラマを一瞬でムカつかせる能力に秀でている。
そして、自分がなぜ相手をムカつかせたのか理解できない。
プログラマに人生最高クラスの屈辱を与えても、なぜ相手が怒っているのかすら理解できない人もいる。
アメリカ人に、意味も分からず中指を立ててファックユーと叫び、
「なんであのアメリカ人怒ってるの？ 普通じゃないよ、あの人」
と言うようなもので、自分の感覚と文化が万人に通じると思っている類の人間だ。
こういう人は、若い人に多い。
一時、ゲーム業界でその日の気分で仕様変更を言い渡すゲームデザイナーの存在が問題になった。
彼らは「プロの領域」という言葉を駆使してプログラムを理解する努力を怠ったが、
我が国の法体系がハムラビ法典であったなら、八つ裂きにされても文句は言えない所業であったことは言うまでもない。
■プログラ・ム＆マー、理解へのポイント
先ほども書いたとおり、まずプログラムというものが特殊で、それを１００％引き受けるプログラマというものがまた特殊だ。
プログラマはプログラムの快楽を独占する代わりに、プログラムの猛毒を引き受ける。
つまり、プログラムの楽しみはプログラマにしか味わえないが、プログラムの苦しみもプログラマにしか味わえないわけだ。ときどき独自の結束感を持ったプログラマチームを目にすることがあると思う。たとえ同じチームにグラフィッカーがいたとしても、同じ楽しみや苦しみを共有することはできない。
それが独特の結束感を生むのかもしれない。
そんな羨ましく／かつ気の毒なプログラマを理解してやろう。
成果物
プログラムを理解していない人間が、しばしばプログラマに怒りを注ぐのが、成果物への認識だ。
最近はいなくなったが、ちょっと前までは、プログラムの成果物を、絵やシナリオと同様の進捗性で求める人がいて、現場の火種になっていた。
プログラムはある程度仕事を進めると、急速に成果物が出来上がるが、進捗度や開発方法によっては、なかなか成果物と呼べる状態まで仕上がらない特性のものだ。
彼らの中で、基礎設計や骨組み・棟上げといった、段階的な作業は進められるが、プログラマ以外には、「裸の王様」の洋服のようにそれは見えない。
しかし彼らは物語に出てくるような詐欺師ではなく、立派な仕立屋だ。
それがプログラムなのだ。
また、プログラムの部分修正というのは、絵やシナリオの部分修正とは、同音異義であるということを強く知っておかなくてはいけない。
プログラムの部分修正とはソース（過程）の部分修正であって、結果を部分修正するためには、必ずしも作業が“部分”修正で済むとは限らないのだ。
先ほども書いたが、プログラマはコンピュータを制御し、制御されたコンピュータが“仕事”をするという仕組みになっている。
「画面」と向かい合う人たちが、消しゴムで消して書き足すくらいのノリであっても、実際の作業が同じようにクイックに済む保証はない。
プログラマの美意識
プログラマは成果物以上に、その過程に美的感覚を注ぐ。
これはプログラムとプログラマの独特の感覚であり、よい例えが見つからない。
プログラマはそれを、
「美しい設計」
「美しい仕様」
そして、
「美しいコード」
と例える。これらの美しさは、どんな芸術品より彼らの心を強く引き付ける。
しかし、困っちゃうのが、プログラマ以外にはこの感覚がサッパリ分からないことだろう。
美しい設計と仕様くらいなら、ＳＥクラスならまだ理解できるが、美しいコードなんか本気で分からない。
機会があれば、プログラマに美しいコードと汚いコードを見せて貰うといい。
理解できないどころか、
「こんなので汚いだ美しいだ……こいつら頭おかしいんじゃないのか！？」
と思うことだろう。
美しいプログラムは、変更に強く、バグも少なく、スピードも速いという。
しかし、これも周りの人間には、どうでもいい話だったりする。
実際にどうでもよいはずがないのだが、繰り返すようにプログラマが向かい合っているのは「コード」。それを見る人は、コードが制御する「結果」を見ている。コンピュータが処理速度ぎりぎりの戦いを挑まれない限り、「コード」を美しく改良しても、「結果」が美しくなるわけではない。
ほとんどの人が「どうでもいい」「それより進行優先」と思っても仕方のないことなのかもしれない。
アニメーターの人には、「完全にフレーム外の作画」といえばピンとくるだろうか？ ＰＡＮしない限り、「フレーム外」に時間を割いても、「結果」が美しくなるわけではない。しかし、フレーム外をきちんと描くことで、その先の作業（動画など）は効率よくやれるかもしれない。
ともかく、このプログラマの美意識を乱す者をプログラマは許さない。
結果を仕様によって縛られている彼らの楽しみは、過程で快感を得ることなのだから……。
想定外仕様などは、彼らが作り上げた繊細なガラス細工を一発で打ち壊してしまう。
その手の話をするときは、女を口説くときより気を遣う必要がある。
そして、明らかに簡単な変更であっても、彼らの美術精神を破壊したことに一定の理解を示さなければならない。
「すぐできるだろ？」
「簡単だろ？」
といった問いかけは、人間関係の破綻の元だ。
また、変更に強いプログラムを書くプログラマ自身は変更に弱い[1]、という一般人には謎の法則も、よく知っておくべきだろう。
[1]彼らの多くは変更に強くすることを目的に、美しいコードを書いているわけではないということだ。
仕様変更
仕様変更はプログラマをもっとも苦しめる指令だ。
仕様変更にも大小があり、プログラマにとってダメージが大きいものと小さいものがあるが、その大小はプログラムを知らないと分からない。
仕様書の１ページを書き換えただけで、プログラムの大半がご破算になることもあれば、１０ページ書き換えても、
「いいっすよ」
と返されることもある。
ゲームや組込系は、微妙な変更で大ダメージをもたらしやすい。
ＳＥはともかく、ゲームデザイナー系の一部の人は、
「この仕様変更が、どんなに素晴らしい結果をもたらすか」
ということを熱っぽく説こうとするが、プログラマの心にはまったく響いていないことを知るべきだ。
優れたデザイナーやディレクターなら、プロデューサーに掛け合って日程と予算を確保し、段取りを用意する。
それがあって初めてプログラマを納得させられるのである。
また、ＳＥの場合は、営業に間を取り持って貰うと上手くいくことがある。
（会社によるが）営業の方が、仕様変更で苦渋を飲むプログラマの心情を、理解している場合が多いのだ。
しばしば営業のリップサービスが仕様変更の元凶になっているにも関わらず、である。
プログラムを知らず、プログラマを知らない場合は、彼らに親しい営業に相談してみよう。
出世と負担
プログラマほど出世が割に合わない仕事はない。
プログラマとうまく付き合うためにも、相手の肩書きや担当に気をつけたい。
プログラマは、全体の指揮を執るＳＥやディレクター、プロダクトマネージャーといった人の下にチーフプログラマという役職が置かれる。
チーフの下にメインが付き、メインの下にサブが付くのが“たぶん”体系だ。
これは会社によって大きく違うので本当のところは分からない。
また、実際にはＳＥなどに仕切る力がなく、事実上、チーフが仕切りをやったり、チーフという肩書がなく、メインがそれをやったりすることが少なくない。
プログラマは、最高の肩書であるチーフプログラマに近づけば近づくほど、労働条件が急激に悪化する仕組みになっている。
特にチーフプログラマは開発主任というだけでなく、なぜかプロダクト全体に対する責任を問われ易い仕事だ。
「ゲームデザイナーが失敗すればチーフプログラマが懲罰される」
という言葉があったほど、そのポジションは理不尽だ。上の言葉、デザイナーをＳＥに置き換えてもかまわない。
プログラマは全フェーズのしわ寄せの終着点にあるため、ついでに責任問題もしわ寄せされるということがあるのだ。
ゲームデザイナーが、チーフプログラマに責任をなすりつけるのをテクニック化していた時期もある。ロンゲのアイツがたぎってた時代の話だ……。今でもまったく無いとは言い切れない。
チーフプログラマは純粋な仕事量も多い。給料も多いが、負担が大きすぎて、
「損しているのか得しているのか分からない」
という状態に追い込まれてしまう。
純粋に管理だけやっていれば楽なはずだが、実際にはメインプログラマも兼ねるし、コードの修正もしなければならない。
しかし、コードの修正は絵の修正や文章の修正とは違って作業量がメチャクチャ多い。それがプログラムなのだ。
どんなに元のプログラマの個性や主張を重視しようとしても、プログラムというのは一部変えようとするだけで、ザクっと一気にコードが持っていかれてしまう。本当にこれは作業していても、「あれれ？」という感じなのだ。
「ここまでやるつもりではなかったのに……」
スタッフの構成次第では、チーフプログラマはマジ死に確定である。
このへんの事情を知っている人だと、
「チーフをやってみないかね」
と声がかかっても断るという。
しかし、断っても上にプログラマを置かれなければ、事実上、もっとも仕事ができるメインがチーフになる。
（ちなみに、ヒラのプログラマが楽な会社であればあるほど、チーフクラスのプログラマはキツイ場合が多い。入社１〜２年の頃に、「プログラマって意外と楽っすね」などと口走ろうものなら、主任に刺されるかもしれない）
デバッグ
バグ取りはプログラマにとって修行……いや、死業と言ったほうがいいかもしれない。
デバッグ期間中のプログラマは、生理中の女性より神経質で怒りっぽいので、取り扱いには注意したい。
デバッグと聞いて、デバッガ（ソフト）やモニタを用いたバグ取りを想像する人がいるだろう。
最近は組込系でも、監視デバッグが可能になる場合があり、確かに楽にはなった。
しかし、ゲームなどでは未だにデバッガ（ソフト）が使えない環境がほとんどなのである。
大学で培ったテキトーな知識で、
「必要な情報を printf すりゃいいじゃねーっスかー」
などとヘラヘラ言おうものなら、転蓮華で首をヘシ折られてしまうだろう。
ちなみに上記のせりふ、あるコンシューマ・ゲーム開発現場で実際に吐かれたものだ。
もうひとつプログラマを常に苛立たせるのが、デバッガの仕事だろう。
ここでいうデバッガとは、バグ出しを専門とするスタッフのことである。
たとえば、あるソフトのデバッグで３０日の間に１２０個のバグが出たとしよう。
報告書だけ読めば、「なるほど、１日に４個ずつバグが見つかったのだな」と思うかもしれない。
しかし、実際には、最後の５日で１２０個出る……といったようなケースがほとんどだ。
要するにデバッガというのはギリギリまで仕事をしないのである（断定）。
真面目なデバッガさんには申し訳ないが、プログラマのデバッガに対するイメージはそんなものだ。
プログラマにしてみれば、順次アップデートしていく過程のなかで、
「ああ、あの部分は複雑だったが、バグが出なかったんだなあ」
と思っていたところに、成果物提出、もしくはマスターアップ期に、いきなり初期のバグを報告されることになる。
とっくに無事が確認されていたはずのコードだ。
そのときのプログラマの怒りを想像できないようでは、彼らとは付き合えない。
しかし、プログラマはなかなか表だって恨めないところもある。
そもそもバグというのは直近ではプログラマの責任だから（大元ではＰとかＤの責任だけどな！）、逆上するわけにもいかない。だが、プログラムにはバグは必ず含まれるのだ！ バグのないプログラムとは、バグがまだ出ていないプログラムに他ならない。
（もし、バグがまったくないプログラムを書いて渡してしまったら、プログラマはどうなるか想像してほしい。喜ぶだろうか？ いや、恐ろしくて不安で夜も眠れなくなるだろう。）
それに、終盤期は他の仕事をアップしたスタッフがデバッグにあたることもある。
のんびりやられても文句は言いにくい……。それまでに地獄を見た連中なのだから……。
じゃあ、バイトのデバッガなら文句が言えるのかというと、それも、
「素人だしなあ……」
と思うと、言いにくい。それに、事態が進行した今、文句を言う暇があったらバグを突き止めなくてはならない。
それゆえに、デバッグ期のプログラマは不安定で、付き合いづらいのだ。
ちなみに言い訳ではないが、デバッグは作った本人以外の人間がやったほうが効率がよい。これは教本にはよく載っている原則論のひとつだ。
社外デバッグ
最近は（……いや、昔からですね……）社内デバッグを使わず外注の専業デバッグ会社を使うようになってきた。
この専業デバッグ会社は素晴らしい。こっちが指定した期限で最大の仕事をするし、報告書が抜群に読みやすく、ソース上のエンバグポイントが想像できる。
思ったより安いのもウリだ。上司にかけあったとき話が通りやすい。
デバッグに関しては、バイトを雇って仕切るよりは、アウトソーシングしたほうが安くて結果もいいと思う……。
ビジネス・アプリケーション系では（性質上、）あまり使えないけど……。
マスターアップ
ソフトウェア業界において、「マスターアップ」は、神聖で畏怖を感じさせる言葉だ。ＨＴＭＬで表現するとこんな感じだ、↓↓
マスターアップ
冗談抜きで、この世の中に「マスターアップ」よりキツイものはないと思う。
神を信じない者も、このときばかりは神に祈る。
その負担が最もデカイのがプログラマだ。
マスターアップの驚異を感じられない者は、せめて「マスターアップと〆切は意味が違う」、ということだけは知っておきたい。
プログラマは「マスターアップ」という言葉に、複雑で巨大な感情を抱く。
これまで以上に積み重なる判断と調査とコーディングと焦燥感。体力以上に精神力を消耗することになる。
あるプログラマは言う。
「３倍界王拳っっ！！」
意味は分からないが気持ちは分かる。
ビジネス系ソフトなら、難無くマスターアップに漕ぎ着けることもあるが、普通は荒れる。
ビジネスソフトにはゲームにはない「合法な」仕様変更[2]が異常に多く、マスターアップ時に大変な問題を引き起こすのだ。
下請け孫請けもゲームよりよほど複雑なので、分離開発したものが、
「実機に乗せたら動きませんでした」
ということもよく起こる。まあ、これはゲームでもよくあるけど……。
ゲームはゲームで、会社によっては本当にメチャクチャだったりする。
出前途中のそばを全部ひっくり返してしまったが、それをまたかき集めて、体裁をとりつくろってお客様にお届けする……。
そんな例えがピッタリくる。
また、マスターアップには、これまでのツケが必ず噴出するという凄まじい特性を持っている。例の美しいプログラムの真価が（プログラマに対してだけ）発揮されるのもここだ！
プログラマを中心に人間関係は大荒れする。
ここで、ＳＥとかゲームデザイナーの類が、
「こんなときだからこそ、力を合わせてがんばろう！」
などと言った日には、殺人キャメルクラッチで二ツ折りにされてしまうので注意が必要だ。
……マスターアップについて語ると、本が一冊書けてしまうので、ここまでにしておく。
だが、このマスターアップという独特の儀式があるからこそ、プログラマの損壊率が一層高まっているのは間違いない。
[2]合法仕様変更とは造語。上層部や営業が、今後の契約や展開を考えて仕様変更の要求を受け入れ、正式に「長期的視野からみて利益あり。やってよし」と判断すること（その長期的視野のなかに、短期的に地獄を見るプログラマは入っていない）。ゲーム業界では一部の密室会議で決められた「仕様変更」に対し、コストやスケジュールを盾にとり、公的問題にブチ上げて抵抗するのがひとつの手段だが、その盾を会社に奪われた形になってしまう。こうなったらもうやるしかない。
■よい付き合いを
プログラマが背負っている負担というものを想像せずに、ずけずけモノを言う人がいる。一種のハラスメントだ。
かといって、常にハレモノ扱いするのも考え物だ。要はハレモノになる時期を押さえればよい……。
繰り返すが、人は絵を描いたり、作文を書くことは、義務教育だけで見ても何度もある。
だから、絵描きや物書きの仕事は想像できるし、いつハレモノになっているのか、どんなふうに組み立てられるのか……ということも想像できる。
絵を描く過程を、「色を塗ってから線を引くんだ」と思っている人はいないだろう。
しかし、プログラマに対しては違うわけだ。付き合ううえで、必要な情報が、たいていの人に不足している。
今回の記事を読んで、
「プログラマを特別扱いしろというのか」
と思ってしまった人は、この点を理解してほしい。
我々は、義務教育のお陰で、グラフィッカーや物書きとは最低限のポイントを押さえた付き合いはできる。
しかし、プログラマとは最低限のポイントを押さえた付き合いができない。
だから、最低限のポイントを軽く紹介した次第だ。
考えてみて欲しい。プログラマは絵描きや物書きを（少なくとも学校で）やったことがあり、あなたの仕事を理解しようと試みている。
それに対して、プログラマに対しても理解をしようと努力することが、人間同士の正しい付き合いに繋がるのではないだろうか。