「全ファミ。」ブログ編

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

しょうゆさしからしょうゆが出なくする方法を5つ考えてください

ご意見をいただいたのと、単にツイッターをまとめるのも見づらく芸がないということで、ブログでまとめることにしました。原稿料が出ないとはいえ、21世紀ファミコンの連載移籍先ですしね、ちゃんとやらなければ。

---------------
ゲーム業界じゃないところで評価の取りまとめをしていたときの話です。製品評価とかデバッグというのは、新人さんに教えるのってけっこう難しいんですよ。感覚的なものといいますか、「ここらへんでバグが出るだろう」というのをつかんでもらいにくい。なので、わかりやすい例を挙げて説明したのがしょうゆさしの話なのでした。
ツイッターのほうでもいくつか方法が挙げられていましたが、ここで一覧を再掲。

1 しょうゆさしを水中/宇宙に持っていく
2 しょうゆを凍らせる
3 しょうゆをあらかじめ空にしておく
4 しょうゆを別の液体に変えておく
5 しょうゆさしの口をふさぐ
6 しょうゆさしに穴を開けておく
7 しょうゆさしの名前を変える

とまあ、こんな具合です。
これらの方法はいくつかのパターンに分かれます。

・環境を変える
・インプット(中身)を変える
・アウトプット(入れ物)を変える
・表現を変える

1番目は環境ですね。環境、つまりしょうゆさしを取り巻く環境を変えることで、しょうゆを出なくする。しょうゆさしを宇宙で使う人はそうそういないと思いますが、「しょうゆさしからしょうゆが出ない」というのは、製品評価の世界ではバグなんです。でも、そういう環境の変化を想定していないものは、仕様屋さんが仕様として「宇宙・水中では出ません」と決めてしまう
バグ出しの面白さってのは、プログラマーさんや仕様屋さんが考えていないところをつっつくところにあるんですね。そして、それを直させるところの楽しさ。しかし、せっかく出したバグに対して、「仕様を今から決めたので、それはバグじゃなくなりました。あしからず」と言われるのがいちばん面白くないんです。でも、「まあ仕様を付け加えさせたんだからいいじゃないか」と若い子には言うんですけどね。そして、こうも付け加えるんです。「宇宙・水中でしょうゆが出るシチュエーションを探そう」って。評価の世界はいたちごっこなのです。

2~4番目は中身の変更。しょうゆさしなんですから、中身がちゃんと出ないとしょうゆさしとしての存在が成り立ちませんからね。2番目の「しょうゆを凍らせる」のはけっこう大変そう。味噌も冷凍庫で凍らないですからねえ。まあそれはおいといて、もしかすると1の環境を変えるほうに含まれることも考えられます。環境での試験をやっているときに中身の試験も同時にやってしまうなんてのは、本当は駄目なんですよ。ま、試験の時間短縮になっていいってことでやらせちゃいますけど。
で、中身の変更で面白いのは4番目の「別の液体に変える」というやつ。確かにしょうゆが出てこないので不具合になりますわな。ただ、しょうゆさしでしたらフタをあけてしょうゆを入れ替えればいいんですけど、ソフトウェアの評価の場合は、「しょうゆ以外の液体がしょうゆさしに入ることはありえない。よって処置なしとする」という回答が普通にあるわけですよ。これは悔しい。なので、しょうゆ以外をいれる方法を見つけて、「こうすればしょうゆ以外が入りますよ。なので、ここにしょうゆが入らない対処をしてください」とやるわけです。ね、楽しげでしょ。やられるプログラマーさんや仕様屋さんはイライラするでしょうが、それがまたいいんです。
あと、面白いパターンとしては、ヤ○サしょうゆなら出てくるのにキッ○ーマンしょうゆだと出てこないというやつ。ソフトウェアの世界ではよくあります。しょうゆの構造がメーカーごとにちょっと違うんですね。その差異を考慮にいれていなかった故の不具合です。でも自家製しょうゆも出てこないんです! って訴えると、自家製しょうゆはユーザーの責任なので、そこまで面倒見ませんって言われてしまうんですよ。切ない話じゃないですか。

5、6番目はアウトプット(入れ物)に何かの変更を加える。しょうゆさしの口をふさぐってのは、使ってるユーザーが故意にやってるわけですよ。なので、仕様屋さんはそんなのしらねえよと言って終わりにしてしまうので、「こうすればユーザーが意図しないのに口がふさがれてしまいますよ」とやる。こういうのを、「不具合を寄せてくる」と私は呼んでました。不具合じゃないものを不具合にしてしまうテクニックですね。あんまりやりすぎると怒られます。でも、「しょうゆが出ないと困るのはユーザーで、最終的にはメーカーにその評判が跳ね返ってきますよ」と言うわけですよ。ソフトに言ってますけど、ようは脅しです。じゃあしょうがないっていうことで、仕様屋さんはプログラマーさんに「ユーザーが意図せずに口がふさがれる現象を対処するのに、どれだけの工数(直すための人数と時間)がかかるのか」とおもんばかる。で、工数が軽そうだから対処するか、っていう話になるわけです。
この工数ってのはお金も時間も人数もかかるってんで、大きな判断基準なんですね。不具合発見が後になればなるほど、この工数が大きくのしかかるんです。だから、バグ出しや評価では重そうな不具合から見つけるようにしていくのです。

7番目。例に挙げた「しょうゆさしの名前を変える」のだと屁理屈にしか見えませんが、しっかりと生かせるシチュエーションがあります。「ほかではしょうゆさしという表記なのに、ここだけιょうゆさし」になっている! というもの。ようするに誤記であり、表記の統一ですね。ソフトウェアの世界では、制作の過程で「同じような機能を違う人が別々に作る」こともあり、それが不統一の原因になったりするのです。あとマニュアルもそう。製品を直したのに、マニュアルが「しょうゆさι」じゃああかんと。注意力もそうですし、ものづくりの過程を理解した上のでチェックが必要となる項目なのです。
ちなみに、「統一」というところでチェックするのも面白いんですよ。前述した「キッ○ーマンしょうゆが出ない」不具合を直してもらったところ、確かに出るようにはなったんですが、「ヤ○サよりもキッ○ーマンのほうが出がよくなってしまった」なんてことがあるわけです。しょうゆの種類によらず、同じように出ないといけないわけですよ。だから、「ヤ○サしょうゆを出すときはいったい何をしていたんだ、プログラマー!」ってわけで、ちょっとした騒ぎになったりしてね。

このように、作り手側で散々波風を起こしておいて、お客さんには平穏無事に使ってもらう。デバッグとか評価とかはそういうお仕事なのです。


---------------
ゲームのバグ出しについて考える
RPGでバグを出す話

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://zenfami.blog91.fc2.com/tb.php/952-c5537c3d
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。