本件に入る前に、
松下電器：３万人対象に在宅勤務制度導入 国内最大規模
（MSN毎日 より）
何か、すげー悔しいんだけど。。。
まぁ、仮に1年前にこの話が出てても、やっぱり辞めてたかな。
というわけで、
これも伝説の1つかもなぁと思いつつ月影です。
こんばんは。
Tech総研のこの記事ですが、
読みながら「ねーよっ」と思うやつばかりだったので放置だったんだけど、
スラドで取り上げられてたので、
都市伝説オレオレ版というのを思い出してみるのも一興かもな、
ということで、ちょっと書いてみるです。
オレオレ7不思議ならぬ、7伝説。
その1. 不具合は帰り際に報告される。
定時まではそこそこ平和なのに、
定時過ぎてから、なぜかいろいろ問題が報告されてくる。
というか、問題なさそうだ、よかったよかったと
安心して帰り支度を始めると、何かしら「待った」がかかる。
これの拡大版としては、
納期間際に要望や仕様変更が殺到するとか。。。
その2. 通らないと思ったものは通る。通ると思ったものは通らない。
企画とか、仕様とか、コンパイルとか。
こんな無茶な仕様ありえねぇ！と思ってたら、
お客さん「それでOK！」、当方「うそぉぉーん！？」みたいな。
大体のお客さんで技術部と現場の意思疎通がうまくいってなくて、
そういう仕様は後から「やっぱりこうしたい」といってくることが、
まぁ8割以上だったわけですがね。
プログラムでも、この法則が発動することがある。
1Kステップくらい一気に書いて、
とりあえずコンパイルかけて出たエラーを潰していこうと思ったら、
一発で通っちゃったり。。
逆に、10行くらいちょちょっと書いて、
絶対通ると確信してたコードが通らなかったり。。。
この場合、大体スペルミスとか型が違ったりみたいな、
とても些細なミスなんだけど、
なぜかそのミスの部分をなかなか見つけられない。
最初に絶対の自信を持っちゃってるから、
どこか間違っているはずがないという先入観が強いのですな。
その3. テストケースバグよりもモンキーテストバグの方が深刻
テストというのは、
大抵どのシステムでもテストケースというのを洗い出して、
そのパターンを全ルート試すというシナリオを書いてやるんだけど、
そこで上がってくるバグというのは、
概ね大して重いものがないのです。
まぁ、テストケースのつくりが甘いという考え方もあるけど、
そもそもテストケースというのは、
開発者としても想定しているルートを通しているわけで、
上がってくる不具合も大体予想通りだったりするのですな。
しかし、ケース外のテスト、
これを業界ではモンキーテストという（らしい）のですが、
（私自身、フリーになってからこの言葉を知った）
テスタが思いつきで「こんなことしちゃったらどうなるんだろ？」
みたいな、いわば興味本位みたいな操作を試すことがあって、
そういうところで見つかったバグは、なかなか難物が多い。。
100%再現すれば良いのだけど、たまーに再現する、とか、
超神がかったタイミングで入力してみたりとか、
いろんな（まず運用ではあり得ない）条件が揃ったときに再現するとか、
よーく見ないと判別できないようなビジュアルの違和感とか。。。
こういうのが徹夜のタネになったりすることも多々でした。
その4. 不安に感じた部分は十中八九問題になる。
その3にも関連するけど、
かなりレアケースでまず実運用ではあり得ないから、
不具合の可能性もあるけど放置でいいや、と思ってるような箇所は、
ほぼ必ず、後で「あり得る」ようになって問題になる。
あと、ちょっとコードの意味に不安があるけど、
動くからいいや、と思ったような箇所は、ほぼ100%バグになる。
だから、（今は大丈夫そうだけど）少しでも不安のあるという箇所は、
必ずテストまでには、最低でも納品までには解明しておくべしです。
その5. 仕様書が厚いほど問題も多い。
シンプル・イズ・ベスト、ってことです。
仕様書がないシステムは問題だけど、
仕様書が異様に厚いようなシステムも要注意で、
大体その内容は関係者に読まれてません。
（品管も形式のみで細部までチェックできない。）
全部が全部というわけでもないけど、
特に「顧客に納品するだけの目的でつくられた仕様書」というのは、
開発、保守の参考にならないこと多々です。。。
その6. 「こんな会社辞めてやる！」と声高にいってるヤツほど辞めない。
いや、そういう人を知ってるだけなんですが。。。
んじゃ、はやく辞めろよ！と。
その7. プロジェクト最盛時に面白いゲームが発売される。
いや、そういうことが結構あったというだけなんですが。。。
DQ8とかFF12とかは、かなり絶妙なタイミングでした。
なんか、ずっといわゆるデスマーチだったってことなのか…。
