業界話の番外編。
20年たった話、ともいえるし、長い時間の話なので、最後のほうは20年たってないように思うのだけど、いい機会なので書いてしまおう。
Twitter の TL で、「デバッグの天才っているよね」という話題が盛り上がっていた。
ここでいうデバッグとは、厳密にいえば「バグ出し」のことね。バグを出現させる仕事。
念のために書けば、バグとはプログラムの動作の誤りのこと。
デバッグとは本来「バグを無くす」、つまり正しい動作にする作業の意味で、バグを出すことではない。
でも、存在するかどうかもわからないバグを無くすことは出来ない。
「バグを出す」ことこそが、デバッグの上で一番重要な作業だ。
そのことから、バグ出しのことを「デバッグ」と言ってしまう場合も多い。
デバッグプレイ、というとき、それはゲームのバグを出す目的で遊ぶことだ。
ゲームバランスなどを確認する「テストプレイ」とは異なる。
そして、デバッグの天才は天性の勘で、または執念によって、次々と誰も気づかなかったバグをあぶり出し、さらには「確実にバグを再現する」方法まで編み出してくれるのだ。
会社で働いていた時も、バグ出しの天才がいた。
完成間近で部内に置かれているゲームをプレイして、難易度が高いゲームであるにも関わらず、ノーコンティニューで２周したりする。
また別のゲームでは、ノーミス全面クリアを誰よりも早く達成する。
まず、そこまでゲームをやり込む、ということが「前提条件」となる。
そして、そこまでやり込んだ腕前を持って、あえておかしな武器ですべてのボスに挑んでみたり、弾を撃たずに逃げ回ってみたり、画面端を狙って撃ち続けてみたり、面クリアと同時にゲームオーバーになってみたりする。
とにかく、プログラマーが想定もしていないような条件を引き起こしてみる。
これが「バグ出し」で一番重要なことだ。
プログラマーはごく普通の状況を想定してプログラムを作っているから、あえて意地悪をしなくてはならない。
極端な状況でのテストというのはバグが出やすい。
チェック方法はエスカレートして、全く同時に複数のキーを押してみたり、コインが入ると全く同時にスタートボタンを押してみたり、普通のレバーではありえないが、上と下、右と左を同時入力してみたりする。
これらは、普通の方法ではなかなか難しい。
彼は、このためにワニ口クリップを結線したボタンを用意していて、コンパネを開けて、各種ボタン結線の間をショートさせてチェックを行っていた。
彼は僕と同期の企画で、新人の時からデバッグプレイで才能を見せていた。
多数のゲームのチェックをやっていたのだけど、過去にバグを見つけた部分に関しては、別のゲームでも必ず同じような状況を試すようにしていた。
それを繰り返すうちに、「いろいろなゲームに共通してバグが出やすいポイント」に気付き、チェック項目リストを作り始める。
項目が80を超えたころに、「108項目チェックリスト、って名前にしたらカッコイイと思ってるんだけど、なんか他にバグ出そうなポイントあるかな」って、明らかに目的と手段が入れ替わり始めた。
とはいえ、最終的に本当に 108項目のリストを作り上げ、その内容は実際にバグが出やすい、プログラマーが気付きにくい状況で埋まっていた。
＃一部の項目は、基板ごとに分かれていた。ST-V 用チェック項目のグループとか、MODEL2用のチェック項目のグループとかあったのね。
さらに、２人同時プレイの時の項目とか、エンディングの有無でも項目が異なったりした。
だから、すべてのゲームで 108項目をチェックする必要がある、というわけではなかった。
この 108項目でどれほどのバグが出るかで、プログラムの品質をある程度推し量ることができた。
あまりバグが出なければ、そのプログラムを作った人は、「想定外」のことまでかなり考えて、きっちりしたプログラムを作っている、と言える。高品質なプログラムだ。
逆にバグが多ければ、そのプログラムは低品質だ。見た目は動いていても、他にもバグが多数あることが予期される。
そういうプログラムは、ゲーム中にも徹底しておかしな操作をして、バグを洗い出す必要があった。
ところがだ。
ある時、ゲームを作成している下請け会社から、「リスト項目の意味が分からないところがある」という問い合わせの電話がかかってきた。
最初は何の話か分からない。詳しく聞くと、彼の作った 108項目チェックリストだった。
個人的にまとめていたものだったのに、いつの間にか流出していた。
サポートに電話がかかってくるということは、公式なものだと思われている。
そして、この項目が全部 OK になればそのまま発売できる、というものだと思われていた。
とんでもない。
これらは「最低限のテスト」であって、それが OK だったら発売できる、などというものではない。
これらはプログラムの品質を推定し、どの程度デバッグを本気でやるべきかを事前検査する意味合いを持っていた。
あくまでも極秘のテスト項目であり、このテストにだけ OK を取れるように事前チェックをされてしまうと、プログラムの品質が推定できなくなってしまう。
バグを無くすには、とにかくバグを見つけ出すしかない。
しかし、バグを見つけ出す、単純で広く適用可能な方法なんてない。
そんなものがあれば、それこそプログラマが待ち望む「銀の弾丸」だろう。
だけど、少なくともバグが多そうかどうかを知るための指標を、彼は数年の苦労で作り上げた。
それがいつの間にか流出することで、指標は指標として役に立たなくなってしまった。
それどころか、下請け会社に「このチェックさえ通ればいい」と誤解させてしまった。
それはつまり、バグを一生懸命探そうという気を失わせ、プログラムの品質を下げてしまうことを意味する。
彼が作ったものは、確かに役に立っていた。
しかし、誰かが意図を理解しないままに流出させてしまった。
それによって起こったことは、彼の意図とは正反対の、品質を下げてしまう効果だった。
最初から、こんなもの作り上げないほうがよかったのかもしれない。
彼が、そう言って後悔していたのを覚えている。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |