【受入テスト】リーダー「終わらないけど終わらせるんだよ。」
2016/03/20
受発注管理システムにアサインされた新人の僕は、せっせとマスタメンテナンス系の詳細設計書を作成していました。
詳細設計書の作成も1ヶ月位経過して慣れてきた頃、外部ベンダーに発注していたプログラムが遂に納品されてきます。
このプロジェクトは設計フェーズがだいぶ遅延していた為、完成した詳細設計書から開発依頼を五月雨式に出していました。
その為、この納品は第一版としての納品でした。
スポンサーリンク
受入テストが始まる
プログラムが納品されたので、それらが仕様通りに正しく動くかどうかを確認しなければなりません。
この確認のことを受入テストと呼び、受入テストをパスしないと開発ベンダーにはお金の支払い出来ないということになっています。
ですので、契約時に受入テストの期間というのは決まっていて、その期間内に発注側でテストをしてバグを出し、バグを開発ベンダーに修正して貰うということをする必要があります。
テストはリーダー(大手SIer社員37歳)と僕（外注の新人20歳）で行うことになりました。
このチームにはあと2人ベテランSEがいるのですが、その頃バッチ処理系の設計が全く手付かずで残っていたので、2人はそちらの設計と開発作業に入っていました。
リーダー「受入テストのテストケースは俺が全部作ったから、2人で手分けしてやっていこう。」
僕「はい。分かりました！」
リーダー「テスト期間は1ヶ月間しかないから頑張ろうね。」
僕「はい！」
受入テストケース
テスト環境の構築や納品物のデプロイは先輩がやってくれて僕はいよいよ受入テストの消化に入りました。
僕（よし、やるぞー！）
僕（どれどれ・・・。）
”シナリオ：受注入力画面を開き受注データを登録する。”
”結果：正しく登録出来ることを確認する。”
僕（えーと、”受注入力画面を開き”までは分かるんだけど、受注データを登録するってどうやるの？）
僕（つーか、正しく登録出来ることってどういうこと？）
僕（ヤベ。サッパリ分かんねーぞ。）
と、やる気まんまんで受入テストのケースを見たのですが、具体的に何をすれば良いのかサッパリ分かりませんでした。
僕「すいません。受入テストのケースについて教えて下さい。」
リーダー「ん？」
僕「受注データを登録するってどうやるんですか？」
リーダー「受注データを入力して、登録ボタンを押せば良いんだよ。」
僕「内容は何でも良いんですか？」
リーダー「テストだから何でも良くはないよ。設計書に書かれているフル桁で入れたりしてみて。」
僕「フル桁入れて登録ボタンを押せば良いんですか？」
リーダー「いやいや、他にも全角半角、数字英語とか。あとは一通りの受注区分で登録してみて。」
僕「あっ。はい、分かりました。」
僕「あと、正しく登録されることってどういうことですか？」
リーダー「詳細設計書にデータベースにどう書き込むかが書いてあるでしょ？」
僕「はい。」
リーダー「その通りに書き込まれるか確認してってこと。テスト環境のデータベースの中身は見れるんだっけ？」
僕「いえ、見たこと無いです。」
リーダー「じゃあ、それは先輩に確認して。」
僕「はい、分かりました。」
僕（SQLってやつを使うのかな？学校の授業でやってたような・・・。ちゃんと授業聞いとけばよかったorz）
当時は新人ですからこういうもんかと思っていましたが、今考えると酷いですねｗ
なんですかｗこのテストケースと無茶振りｗ
“受注データを登録する。”この一文からフル桁、文字種、区分毎の登録、といったテスト観点を自分で考えてテストする必要があり、
“正しく登録出来ること。”の一文から設計書に書かれている通りにDB登録がされるかを確認する必要があるのです。
もちろん、Aの場合は1、Bの場合はNULL等、登録仕様に分岐がある場合は、ある程度※そのパターンを網羅するようにテストしろというのです。
※全パターンやると単体テストレベルになるのである程度やれってことでした。でも新人にその匙加減が分かると思うか？ｗ
まあ、設計作業が遅延していた為、受入テストのケースを作成する期間が殆ど取れなかったのが原因です。
その為、いざ納品物が来たというタイミングで、リーダーが大急ぎで作成したテストケースだったのです。
終わらない＆帰れない
受入テストのケースはこんなアバウトな感じですので、一つのケースを消化するだけでも、「仕様を把握する」、「必要なテストを考える」、「消化する」という3行程必要になるのです。
しかも、テストの最中に、そもそも仕様が間違ってる。なんて問題が発覚したりもしますし、全部で50画面位あるにも関わらず期間は1ヶ月、作業者は僕とリーダーの2人だけでした。
当然、毎日フル残業になるし、土日も出勤になるわけです。
多分当時の僕の勤務表には、9:00-23:30がずらーっと1ヶ月並んでいたと思いますｗ
そしてある日僕は勇気を出してリーダーにあることを言ってみました
僕「すいません。」
リーダー「ん？どうしたの？」
僕「このペースでテストしてても1ヶ月以内に終わらないと思うんですけど・・・。」
リーダー「・・・。」
リーダー「そうだね。それで？」
僕「それでって言われましても・・・。何とかならないですかね？」
リーダー「タカ君。言いたいことは分かるよ。でもね。」
リーダー「終わらないけど、終わらせるんだよ。」
僕（なっ！！！）
僕はとんでもない名言を聞きましたｗ
「終わらないけど、終わらせるんだよ。」
当時新人の僕でさえ、頭の半分では何をバカなことを言ってるんだと思いました。でも残りの半分はこう思ったのです。
「終わらないかも。って心配している暇があったら終わらせる方法を考えなきゃ。」と。
初めての提案
結局リーダーに相談しても何も状況は変わりませんでしたが僕の意識は少し変化しました。
テストを消化している最中でも、何とか効率良く出来ないものか？と常に考えるようになったのです。
そして、
僕（つーか、作業の割り振りが良くねーよな。）
僕（僕が必至で仕様を把握してからテストするよりも、元から仕様を知ってるリーダーがテストした方が圧倒的に速いよな・・・。）
僕（仕様を知らないと出来ないテストはリーダーがやって、僕は単純なテストに専念した方が良いんじゃないか？）
と、いうことを考えたのです。
そして、
僕「すいません。」
リーダー「どうしたの？」
僕「作業の割り振りが良くないと思うんですけど。」
リーダー「どういうこと？」
僕「今は画面毎に担当を分けていますけど、仕様を知らないと出来ないテストはリーダーがやって、僕は単純なテストに専念した方が良いんじゃないかと思うんです。」
僕「僕はテストに時間が掛かるというよりは、仕様を把握してやるべきテストを考えるのに時間が掛かっているので、僕は全画面の入力チェックや、エラー時の動作とか、仕様を知らなくても出来るところからやって、リーダーは・・・（省略）と思うんです。」
と、新人のクソガキが偉そうに派遣先のSIerのリーダーに物申し始めたのですｗ
提案の結果
リーダー「なるほどね。」
リーダー「確かにそうだね。そうしよっか。」
と、なんと僕の提案が採用されて、作業分担が変わったのです。
その結果、作業効率が激的に向上して何とか期間内に受入テストを完了させることが出来たのです。はい、メデタシ、メデタシ。
・・・なんてことになる訳ないですねｗ
確かに作業効率は上がりました、しかし圧倒的な作業量の前には焼け石に水です。
結局毎日フル残業＋休日出勤で頑張ったのですが、期間内に終わらせることは出来ませんでした。
そして受入テスト最終週の進捗会議で、
リーダー「受入テストの完全な完了は無理そうだから、結合テストでキャッチアップしよう。」
リーダー「一応、主要な画面は一通り確認したから。」
と、前工程のツケを次工程で払うというシステム開発の悪しき習慣を踏襲することを決定するのですｗ
今思うこと
今までのSE生活の中で、この1ヶ月間が最も長時間働きました。
さて、今回は名言が飛び出しましたｗ
「終わらないけど、終わらせるんだよ。」
バカバカしいけど、個人的には嫌いじゃないです。
「終わらないかも。って心配している暇があったら終わらせる方法を考えなきゃ。」
と僕に気付かせてくれたので。
でも、IT業界ではこんな精神論しか手段しか残っていないプロジェクトなんて沢山あります。
もうね、見積の時点でプロジェクトの行く末なんてほぼ決まってるんですよｗ
見積もりで失敗したらデスマーチは必至です。
見積もりでコケるインパクトに比べたらSEの努力なんてクソみたいなもんです。
このプロジェクト（というかこの会社は）は営業がかなり安い金額で受注したものでしたので、作業ボリュームに対して圧倒的に人員が足りていませんでした。
多分これまでのプロジェクトも営業が安い金額で受注した案件を、SE全員で必死でこなしてきたんだと思います。
なので、リーダーもいつものパターンだと半分匙を投げていたんだと思います。
じゃあ、どうすりゃいいのか？
発注側がコンペを取る時に、特別なコネがなくて同等条件の提案なら安いベンダーに発注すると思います。
でも、何故安いのか理由を考えましょう。
その安い理由が見積もりの甘さ、だとしたら必ず品質に跳ね返ってきて発注側も痛い目を見ます。
僕は今、とある金融機関の社内SEなのですが、このグループ会社からご提案を頂いたことがあります。
確かに安かったですし、金額面で他社に負けているならもっと勉強します。と営業からの電話攻勢も結構ありました。
でもね、安い理由が見積もりの甘さだと分かっちゃっていたので、少し高かったですけど精緻に見積もれていた他のベンダーさんに発注しました。
少しづつでもこういう風にしていったらIT業界もっと働きやすくなりませんかね？
レベルアップ
- テストの経験値が増えた。
- 受注管理システムの全体的な仕様が何となく分かった。
- 目的の為にどうするべきか？を考える意識が芽生えた。