上司の命令 |
作成日：2001-06-19 最終更新日： |
私はコンピュータとつきあっている職場にいながら、仕事の徹夜というものは２度しか経験がない （実験の徹夜は除く）。 それだけ自分かわいさが過ぎているのだろう。
さて、こんな話で始めたのも他でもない、私がした徹夜というのは上司の命令により 行なったものだが、徹夜しろ、といって行ったものではない。すべて身から出た錆である。
私が担当したあるソフトの部分が思った通りの動作をしなかった。上司は言った。 「おまえ、このソフトがどのように動くかわかっているんだろうな。」 私ははいという答えるしかない。実際、どのように動くべきかはわかっていた。 しかし、かなりの手抜きがあったので、 すべての組み合わせであるべき姿の動き方にはなっていなかった。それを上司が見破ったのだ。 「それならば、明日がプロジェクトの報告会だ。それまでに動くようにしておけ」 上司の口調は鋭かった。私は徹夜の覚悟を決めた。上司はテスト結果を確認するといって、 同じく徹夜したのだった。
上司はさらに付け加えた。「おまえのプログラムが論理的に確実に動くとわかっているなら、 テストをしなくてもいい。でも、本当に自信があるか？自信がなければテストをしろ。 最初から計画をたてて、テストの結果を予想して、その予想通りになることを確かめろ。いいな」
この上司から前にも「おまえは将棋が好きなんだろ。将棋で先が読めるのに、 なんでプロジェクトで（プログラムで）先が読めないんだ？」とも叱られた。 こちらにも堪えたが、予想をして、それから検証しろ、というのをこのときまさに身体で 知らされたのだった。
ワープロ打ちではない、手書きの A5 版のほご紙に、手順のフローを書いて分岐条件を 確かめた。分岐が細かく、条件が錯綜している個所は２次元または３次元の表にして、 正しく動作する条件と誤って作動してしまう条件、前の条件をそのまま使う条件などに分類した。
一応テストの計画を完成させた後では、上司とレビューをした。 OK のあと、プログラミングに入った。ある個所まで終わったらテストの結果を出し、 予想と突き合わせた。予想通りに行かない個所は、予想の前提条件やらプログラムのバグやら、 設計ミスやらで数多くあった。そのつど整合性を確かめ、直し壊し（エンバグ）がないよう、 繰り返しテスト（回帰テスト）も行った。
明るくなることにはメドが立った。上司は私を見て「最初からきちんとやっていれば、 ここまでやることにはならなかったんだ」と呟いた。
その後、私は異動になり、 ISO 9001 の推進事務局を担当することになった。 対象部署は、私がもといたソフト開発の現場であり、異動前の上司がマネージャーとなっていた。 ISO 9001 の審査に合格するためには、いろいろな文書や記録をそろえないといけない。 文書や記録といってもいろいろあるが、その中でテストの計画と実施記録は難関だった。 元上司に「テストは計画を立てて、その結果と突き合わせて下さい」と頼むと、 「おまえ、テストの計画を立てて、その結果を残しておくのはどれほど大変なのかわかってるだろう。 こっちは忙しくてそんなことをやる暇はないんだ」と嫌な顔をされるのだった。 むこうはどうだか知らないが、私は上の一件を覚えている。 だから、どんなに大変なことかはわかっている。そして、どんなに大事なことかもわかっている。 今となっては、マネージャーもきちんとテスト計画を作らせ、記録をとっている。
2001年6月、 いくつかの大学で採点のプログラムにミスがあることに気付かないまま、 不合格者を出してしまったという事件が相次いで発覚した。 私は気弱なものだから、当事者ではないにもかかわらず、 声高に事件を非難することができないでいる。
テストの計画というのは、けっこう大変なものである。 「正しく動く」ことを確かめるということは、 正しい範囲であれば予想された通り動く、というのと同時に、 正しくない範囲がくれば 予想された通り動かない、 あるいはエラーとなることを確かめないといけない。 それぞれを正論理、負論理という言い方を聞いた。 この負論理がなかなか出てこない。
エクストリーム・プログラミングといわれている手法も、 その名前の極端さに比べて、 中身はごく実直である。 その手法の一つに「テストケースを考えてからプログラミングをする」 というものがある。これなど、見習うべき手法の一つではないだろうか。 わたしは、テストケースの大事さについて、徹夜の事件と同時に、Ruby 256 本の RubyUnit の本も 思い浮かべている。
