中堅開発会社でSEを務める上村裕二さんは、間もなく始まる新販売管理システムの開発プロジェクトで、テスト工程のリーダーを任された。テストでバグを発見するのが得意な入社4年目の上村さんに、リーダー役として白羽の矢が立ったのである。

　「これまでの実績が評価された。このチャンスをうまく生かしてやろう」。初めてのリーダー役に上村さんは意欲を燃やした。

　プロジェクトが始まり、上村さんはプロジェクトマネジャーで上司の田中部長に呼び出された。「上村、そろそろテスト計画書を作ってくれないか」。上村さんはテスト計画書を見たことはあるが、自分で作ったことがない。「わ、分かりました」。そう返事だけして、過去のテスト計画書やテストに関する本を参考にしながら、見よう見まねで今回のテスト計画書を作ることにした。

　テスト計画書は、テストの目的や方針、スケジュールや工数、体制、テスト環境などを記載したもの。テスト担当者はこの計画書に従って、テストを実施する。テスト工程全体の計画を「全体テスト計画」、単体テストや結合テストなどフェーズ別に分けた計画を「詳細テスト計画」と呼ぶ。「ふむふむ」。本に書かれたこうした説明を読みながら、計画書を作成していった。

　ところが、スケジュールを計画する段階で壁にぶつかった。プロジェクトの期間は6カ月あまり。このうちテストに割り当てられた時間は1カ月しかなかったのだ。システムの規模から見て、明らかに時間が足りない。「さすがにこれは無理だろう」。そう思った上村さんは、田中部長のもとを訪れた。

「時間がないのは当たり前だろ」

　「もう少し期間を長くできませんか」。上村さんがそう訴えると「時間がないのは当たり前だろ。設計も実装もみんな同じだ。時間がない中でどうするか考えるのがリーダーのお前の仕事だぞ」。あっさりと突き返された。

　苦労の末に、何とかギリギリのスケジュールを引いてみた。だが、今度は人が足りない。そこで上村さんも、いくつかのテストを担当することにした。さらに自動テストツールを導入し、一部のテストを効率化しようとも考えた。ただ、今回のテストには新人が2人参加する。「操作を教える時間もないし、予算もないしな」。過去のプロジェクトで使い慣れたツールの導入も、今回は見送らざるを得なかった。

　次の日、上村さんはテスト設計と呼ぶ作業に取り掛かった。テスト設計とは、テストの目的に沿って、テスト対象やテストケース、テストデータなどを検討する作業だ。テストケースは抜けや漏れがないように洗い出し、時間の効率を考えて効果の高いテストケースに絞り込む必要がある。ここでも上村さんの手が止まった。

　「このシステムにはなんでこんなに外部システムがあるんだ。どこまでをテスト範囲にしたらいいのか分からない」。考え込んでいると、見かねた田中部長がやって来た。「この設計書から関数の呼び出しを漏れなく調べ上げ、テスト範囲としてみてくれ」。机の上にドサッと置かれた分厚いバインダーを見て、上村さんはため息をついた。

　それでも何とかテスト計画書を作り上げた。これだけ悪条件がそろったテストもないと思ったが、田中部長に言わせれば「今回はまだましな方」だそうだ。納得とはいかない上村さんも、いよいよ今日から始まるテストの実施に気を引き締め直した。テストチームは上村さんを含めて6人である。「時間はあまりないが、みんなで協力して乗り切ろう」。上村さんはメンバーを前に、こうはっぱをかけた。

　テストの実施については、上村さんの得意分野である。自分の担当分をテキパキとこなし、新人の2人の支援も怠らなかった。計画したテストケースの件数も順調に消化。そこに田中部長がやって来た。「順調に進んでいるみたいじゃないか。明日の会議でバグと進捗の報告をよろしくな」。

　「あっ、そうでした…」。テストの実施に集中していた上村さんは、管理資料の取りまとめを忘れていた。「おいおい、あ、じゃないぞ。明日は利用部門の方も参加するので不備がないようにしとけよ」。上村さんはあわてて各メンバーから状況を聞き出し、表計算ソフトで報告書を作成した。帰宅はまた深夜だ。

　次の朝、上村さんは会議室で、プロジェクトの関係者の前で報告した。「テストは現在、結合テストまで進んでいます。テストケースの消化率もバグの件数も予定通りです」。上村さんは落ち着いた表情でこう伝えた。

　上村さんが報告を終えると、利用部門の関課長から質問が挙がった。「上村さん、バグの原因の傾向と、具体的な対応策を教えてください。それと、バグの修正がどの程度進んでいるのかも報告していただけませんか」。

　「それは…え、えーと…」。上村さんは言葉に詰まった。質問に答えるだけの情報がない。それでも何とか答えようと「お手元にバグ管理表があるかと思います。バグの内容はそこに書いていますので、そこから傾向をつかむと…」と続けた。とはいえ、バグ管理表には数百件のバグが羅列してあるだけ。その内容から対応策や原因をつかむのは困難だった。「もういいですよ」。イライラした関課長はそう言って「バグの修正はきちんと進めてくださいね」と吐き捨てた。「はい、たぶん大丈夫だと…」。上村さんが自信なさそうに答えたところで、上司の田中部長が助け舟を出した。「後日、詳しい状況を取りまとめて報告させていただきます」。田中部長もその場を収束させようと必死だった。

　上村さんは、会議が終わると田中部長に呼び止められた。「ギリギリの中でテストを進めているのでみんな心配なんだ。できるだけ細かい現場の情報を収集し、会議で答えられるようにしてくれないと困るぞ」。「すみません」。準備不足を痛感した。

テストが全くできない状態に

　上村さんがテスト現場に戻ると、メンバーの様子がいつもと違っていた。立ち話をしていたり、マンガを読んでいたりするメンバーもいた。「どうしたんだ。サボっている時間はないぞ」。上村さんがそう言うと、あるメンバーがこう答えた。「先輩、一部のモジュールの修正が3日たっても終わらず、残りの結合テストができないんです」。聞けば、ほかにできるテストはなく、朝から全員が待ち状態という。

　「修正を依頼した開発メンバーは何をしているんだ」。上村さんはあわてて開発チームのところに走った。「早く修正してくれないとテストが進みませんよ」。上村さんが声を荒らげると、修正担当者はこう答えた。「すまん。設計ミスだ。いろいろ修正が必要なので、もう少し時間がかかる。このモジュールを使ったテストは、もう一度やり直してくれないか」。上村さんは言葉を失った。「もっと早くこのモジュールをテストしていれば…」。手戻りの大きさに、悔やんでも悔やみ切れなかった。

　修正が上がってきたのはその2日後。進捗は遅れに遅れ、“八方ふさがり”に。上村さんは結局リーダーを外され、テスト計画も見直されることになった。