ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

飛田ショウマの憂鬱 (7)

»

 システム開発の様々な工程で、最も知力と体力を投入すべきフェーズはどこか。スキルや立場によって千差万別の答えが得られるだろうが、飛田個人としてはテスト仕様を考える部分だと思っている。どんなに高性能なエンジンでも、エンジンオイルがなければ焼き付きを起こしてしまうように、プログラムを安心して動作させるためには、適切な量と質のテストが欠かせない。

 ただし、よくある「画面の項目数×項目数分の組み合わせチェック」といった類いのテストを飛田は心から軽蔑している。その手のテスト仕様書は、テスターが手動で実行し、結果を目視で確認し、マトリックス表に○を付ける、といった形式が多い。多数の項目をテストしたように見えるが、ほとんど意味のないチェックであることがほとんどだし、実際にテストをしたかどうかの真偽も定かではない。そんなテストに人的リソースを投入するぐらいなら、ユニットテストのコーディングに充てた方がずっと有意義だ、と考えている。

 前上司の有松課長も同じ意見だったので、システム開発課におけるテストとは、基本的にJUnit によるユニットテストを意味していた。インテグレーションテストはもちろん実施するが、ユニットテストでクラス単位の品質を担保した後になる。

 あるとき有松課長が、新人の書いたやたらに複雑なユニットテストを見て唸った。

 「ユニットテストはできるだけシンプルに書け。冗長だと思うぐらいでいい。たとえば通常のソースなら、1から10まで何かやるときは、for文で回すよな。だけどユニットテストの場合は、むしろ10行ずらずらと並べるぐらいでいいんだよ。ユニットテストを複雑にすると、ユニットテストのテストが必要になってくるからな」

 「でも」その新人は控えめに反論した。「これぐらい書かないと、このクラスのテストができないんです」

 「だとしたら、対象のクラスの構造が複雑すぎるということだな。現にこれなんか引数が21個もあるし、対象のテストを実行する前に実行しておかなければならない事前処理が多すぎる。もう少し分割しろ」

 「はあ......」

 「実際にやるかどうかはともかく、どんなクラスでも、少なくともpublic なメソッドについては、ユニットテストを行う前提で書くんだ。ユニットテストを書きやすいということは、クラスの責務が適度に分離されていて、疎結合になっているということだからな」

 営業課からは「納品物に含めるテスト結果のエビデンスが何もないでは格好がつかない」との声も聞かれ、顧客からも納品物の品質について不安が上がることもあったが、そのような場合、有松課長は自ら足を運んで、相手を納得させていた。

 首藤課長の考えは真逆だった。テストと言えばテスターが画面上で実際に操作することであり、エビデンスといえばスクリーンショットやマトリックス表だと考えていて、それらのドキュメントの作成を強く要求した。顧客担当者に、これだけ大量のテストを自分の指示の元で実施しました、と自慢したいんでしょうね、と野見山などはこっそり囁いたものだ。飛田はといえば、ユニットテストを禁止されたら一戦交えるつもりだったが、首藤課長はユニットテストの意味を理解していないのか何の言及もなかったので、表立っては何も反論しなかった。余計なドキュメントを作成することで工数を増加させたいのであれば、それは首藤課長の勝手というものだ。

 八十田建設見積書管理システム構築プロジェクトでも、テストに関しての方針は変わらなかった。一度だけ揉めたのは、飛田が結合テストのため、本番データをもらってきてくれ、と長谷部に要求したときだった。次の日、長谷部は申しわけなさそうに言った。

 「すまん。マスタ類も、過去の見積データも、個人情報流出防止のため出せないそうだ」

 「何のために機密情報保護契約を結んでるんだ」飛田は食い下がった。「何とかならんか。本番データを使って、初めて発覚する問題もある」

 「そうか。じゃあもう一度頼んで......」

 そのとき、いつものように首藤課長が介入した。

 「一度拒否されているのに、何度もずうずうしく頼んだら迷惑だろう」首藤課長は顔をしかめながら言った。「インポートするExcel ファイルは10 個以上もらっているし、マスタはフォーマットをもらっている。これでテストデータを作ればいいじゃないか」

 「それでどうだ?」長谷部が、飛田と首藤課長の両方を見ながら訊いた。「だいたい、本番データを使わないと発覚しない問題って何だ」

 「多くは仕様洩れだ」

 「つまり......要求分析の洩れということか?」

 「そうだ」

 飛田の答えに、首藤課長はバカバカしい、とでも言いたげに鼻を鳴らして薄笑いを浮かべたが、長谷部は戸惑いながら訊いた。

 「そんなことがあるのか? 要求分析書はうちと先方でチェックして、検印もらってる。見落としなんて」

 「要求分析であらゆるケースを拾い上げるのは難しい」飛田は首藤課長を無視して答えた。「前に、キュート社のEC サイトをやったとき、本番稼働してからエラーが発生したことがある。カードの有効期限がフォーマットでは4 桁なのに、特定の場合だけ6 桁で来ていた。オーソリかけた後、AMEXの場合だけ他とは別のチェックロジックを通していて、そこからの返値が6桁だったんだ」

 「結合テストで発覚しなかったのか?」

 「提示されたテストデータには、そのパターンが含まれてなかったから判明しなかった。結合テストでもVISA やJCB はテストしたが、AMEX はやらなかったしな。幸い、オーソリ関係はスタンドアロンだったから、修正したクラスを置き換えるだけで、再起動の必要もなく大事にはならなかったが」

 具体例での説明に、長谷部は感心したように頷き、珍しく首藤課長の顔色を窺うこともなく決断した。

 「わかった。もう一度頼んでみる」

 だが、実装フェーズと並行して結合テストが始まってからも、一向に本番データは提供されなかった。実装が一通り完了し、ほとんどのメンバーが結合テストのタスクを割り当てられても、やはり提供されなかった。当然、飛田は長谷部に催促したが、色よい返事は返ってこなかった。

 「例の個人情報関係で、八十田建設内部で稟議がもめてるみたいだ。担当の人は、たぶん大丈夫だと言っていたんだが、少し遅れるかもしれない」

 「急いでくれ」

 本番データ一式が届いたのは、1 月26 日の夜だった。しかし、指紋認証式のUSB メモリに入ったデータを、飛田が確認することはかなわなかった。ZIP で圧縮されたファイルにはパスワードが設定されていたのだが、長谷部が受け取ってきたメモの文字列を、何度入力しても解凍することができなかったのだ。すでに八十田建設の担当者は帰宅していて、翌日は有給休暇で休みだったため、せっかく届いたデータは飛田のPC の中で無為な時を過ごすことになった。

 「すまん」長谷部は謝った。「明日の朝、一番でパスワードを連絡するようにする」

 その約束は果たされなかった。八十田建設の担当者が午後出社で、出社後はずっと次年度予算編成会議に出席していたためだ。電話を取り次いでもらうこともできず、仕方なく長谷部は会議室の外で何時間も待ち続けた。休憩で出てきた担当者を捕まえて、パスワードを訊きだすことができたのが15 時過ぎだった。長谷部はすぐに飛田に電話をかけたが、あいにく飛田も、他のサブリーダーも席を外していた。3 人はリフレッシュルームで定例の「エルロンド会議」を開いていたのだが、各自のスマートフォンはデスクに残していたため、長谷部からの連絡を受け取ることができなかった。

 結局、飛田が正しいパスワードを知ったのは16 時近くになってからだった。圧縮ファイルは無事に解凍できたが、メンバーの一人のサポートの途中だったので、中身を確認したのは、さらに1 時間が経過した頃だった。データベースのダンプファイルと、各マスタ、データをExcel ファイルにエクスポートしたファイル群である。

 現在のテスト環境は、継続中のユニットテストと、飛田が時間をかけて考えた結合テストパターンに合わせてあるので、上書きすることはできない。飛田は、野見山、篠崎と相談し、本番データ用のテスト環境を作成することに決めたが、ここで邪魔が入った。首藤課長である。

 「そういう重大事項をサブリーダーだけで決めるんじゃない」首藤課長は不機嫌そうに言った。「チームリーダーの許可を得てからにしろ」

 無視して作ってしまうか、と飛田は考えたが、本番データでのテストを首藤課長の目から隠して実行することは難しい。仕方なく、飛田は長谷部の帰社を待つことにした。

 長谷部が帰社したのは、17 時30 分 過ぎ。長谷部への説明に1 分、了承が得られたのはその10 秒後だった。飛田はすぐにでも本番データ用テスト環境を作成したかったが、直後に首藤課長がリーダー会議を招集した。口の中で首藤課長を罵りつつ、飛田はメンバーの一人、岡崎を呼んで、手早く指示を与えた。岡崎は別の業務でデータベース構築を担当したことがあり、手順を熟知していたからだ。

 「ダンプファイルをインポートするだけでいいですか?」岡崎は訊いた。「それとも、マスタメンテ画面から、こっちのExcelファイルを投入していきますか?」

 「今の資材マスタの取り込み、どれぐらいかかった?」

 「1,000 件で90 秒ぐらいですね」

 「本番データは、48,000 件以上だ」飛田は添付されていた、各マスタの件数表を見ながら言った。「そんなには待てん。ダンプの方で頼む」

 このときマスタメンテ画面からの取り込みを指示していれば、もう少し早めに問題が発覚したかもしれない。常の飛田なら、マスタメンテ画面のテストを兼ねて取り込みを選択しただろうが、このときは結合テスト全体のスケジュールを考えて、スピードの方を優先してしまった。翌日が土曜日で出勤する人数が減るので、今日中にある程度の目処を付けておきたかったのだ。

 飛田にはムダな時間だとしか思えないが、長谷部の顔を立てるために出席していた進捗会議が終わった頃、新しいテスト環境の作成は終わっていた。飛田は急いで、投入されたデータを参照し、テストで使用するための見積書コードやユーザをピックアップしていった。

 ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

 土日の大部分は、UI を持つ機能のテストに費やされた。40 以上の要改修点と、30 近くの不具合が確認されたが、いずれも即座に修正することができた。安堵したサブリーダー3 人と長谷部は、日曜日の20 時でテストを切り上げて帰宅することにした。

 「後は帳票系だけか」飛田と駅まで歩きながら、長谷部は明るい顔で言った。「何とか予定通り、受入テストに渡せそうだな」

 「受入テストでも何か問題は出てくるだろうがな」

 「でも画面系がちゃんと動いていれば、何とかなるんだろう?」

 「だといいな」

 「いろいろ不快な思いもさせたと思うけど、とにかくお前のおかげだ。ありがとう」

 「まだ終わってない」

 そう言ったものの、飛田も大きな山場は越えたと考えていた。画面系機能は不具合があっても、対応版を反映することが難しい。ロジック部分の修正のためアプリケーションサーバの再起動が必要になっても、各地に散らばる全ての営業マンに連絡を取れるとは限らないからだ。その点、帳票系は、最悪でも翌日の朝までに出力できればいいことが多く、余裕を持って対応できる。

 次の日の午後、帳票系のテストをしていた石黒が、困惑した顔で立ち上がった。飛田のデスクに向かいかけたが、途中で首藤課長の視線に気付き、慌てて長谷部の方へ方向転換する。

 「すいません。これ2 行出てるんですけど、正しいですか?」

 長谷部は笑顔でプリントアウトを覗き込んだが、すぐにその顔が曇った。手元にあった仕様書ファイルをめくっていたが、やがて諦めたのか、席を立って飛田のデスクに早足で歩いて来た。

 「飛田。これ、月間資材別受注明細表なんだが、このコードが2 行出てるんだ」

 飛田は手を止めて差し出されたプリントアプトを覗いた。確かに、BBR0850177 という資材コードの行が2 行出力されている。

 「select 文投げた結果を、加工しながら出してるんだろう」飛田は仕様を思い出しながら訊いた。「JOIN のどっかがおかしいんじゃないのか」

 「一応調べたんですが」石黒は首を傾げながら答えた。「間違ってない気がするんです」

 「......」

 飛田は修正中だったソースを保存すると、月間資材別受注明細表のソースを開いた。select 文を発行しているメソッドを探し、対応するSQL 文を開いた。JOIN しているテーブルは4 つ。とりたてて難しいSQL 文ではない。こういう場合、複合キーを持つテーブルとの結合の際、結合するキーを書き忘れていることが多いが、どのテーブルも複合キーではない。

 「間違ってないな」飛田は、石黒に、というより自分に向かって呟いた。「データを見てみるか」

 飛田はTeraterm でデータベースサーバにログインすると、psql で本番用テストデータベースに接続した。BBR0850177 を条件に資材マスタを検索してみる。結果が表示された途端、飛田は息を止めた。

hida-sql.png

 「え」石黒も息を呑んだ。「に、2 行あります」

 「見ればわかる」飛田は長谷部に顔を向けた。「どういうことだ?」

 「え?」長谷部は明らかに意味を理解していない表情を浮かべた。「何が2 行?」

 「資材マスタの資材コードだ」飛田はマウスカーソルでコード部分を指した。「これはユニークじゃなかったのか」

 「そう聞いてるが......違うのか?」

 「現に違ってる」

 長谷部が画面の表示を見つめている間に、野見山と篠崎が近寄ってきた。飛田の声が聞こえたらしい。

 「資材コード、ユニークじゃないんですか?」野見山が画面に顔を寄せた。

 「少なくともこのコードはそうだ」

 「それだけですか?」篠崎が訊いた。「それとも......」

 飛田はすでにキーを叩いていた。資材コードでGroup by をかけ、件数が2 件以上のレコードを検索する。結果は3 秒後に出た。

 「うーん」野見山が呻いた。「211 件ですか」

 「これは1 レコードだけのコード間違いというレベルじゃないですね」篠崎は長谷部を見た。「要件定義段階ではどういう話だったんですか」

 長谷部はファイルキャビネットに走り、要件定義書の成果物が綴じられたファイルを持ってきた。焦った顔でページをめくり、該当部分で手を止めた。

 「資材マスタ......資材コード......ユニークとは書かれていない。重複があるとも書かれていないな」

 「それにしたって」野見山が険のある声を上げた。「要件定義や仕様の打ち合わせ段階でわかりそうなもんでしょう」

 成り行きを見守っていた首藤課長が立ち上がった。

 「おい君たち。優先順位を違えてないか。今は犯人捜しより、対策を考える方が先じゃないのか」

 それが自分と長谷部の保身から出たセリフだとしても、言っていること自体は間違っていなかったから、サブリーダーたちは頭を切り換えた。

 「この最後のbranchkey と資材コードでユニークになるようだ」飛田は素早くselect 文を書き、自分の言葉の真偽を確かめた。「間違いない。最後にあるところを見ると、後から追加したんだろうな」

 「枝番ってことですね」

 「影響範囲はどれぐらいでしょう」

 「かなり広いな。資材コードがユニークだという前提のロジックは、ちょっとすぐには思い出せないぐらい沢山ある」

 「おい、それはどういうことだ」長谷部がおそるおそる訊いた。「この帳票だけの問題じゃないのか?」

 「違う」飛田はにべもなく答えた。「資材マスタを使っている画面のほとんどに影響する」

 長谷部は絶句した。見積書管理システムは、資材マスタを使っていない機能の方が少ない。

 「どうやって回避しますかね」長谷部には構わず野見山が言った。

 「設計からやり直すのが一番確実だろうな」飛田は答えた。「もっとも、確実に受入テストには間に合わなくなる」

 「それはダメだ」長谷部が焦燥感を露わにした。「1日に納品と先方に伝えてあるし、遅延はないと何度も言ってあるんだ。今さら、延期をお願いすることはできないよ」

 「延期など論外だ」首藤課長も喚いた。「いかん。絶対にいかん」

 3 人のサブリーダーは、うんざりした顔を見合わせた。

 「どうします?」

 「インターセプターを追加して」飛田は頭の中でロジックを組み立てながら、まとまった部分を口にした。「資材マスタを資材コードでチェックして、複数存在していたら警告を返す。警告が来たら、資材コードの選択ダイアログを表示する......でどうだ」

 野見山と篠崎は、それぞれ手近にあった裏紙を手に取ると、ペンを走らせて飛田の提案を検討し始めた。飛田自身も、もう一度、ロジックを再検討する。さすがの首藤課長も「チームリーダーに相談しろ」とは言わず、無言でロジックをチェックする3 人を固唾を呑んで見守っていた。

 「よさそうです」数分後、篠崎が顔を上げた。

 「OK です」野見山もペンを置いた。「いけると思います」

 ホッと安堵の表情を見せた長谷部と首藤課長に、再チェックを終えた飛田は釘を刺した。

 「これはあくまでも臨時の処理、受入テストに間に合わせるためだけの対応だ。受入テスト後に、改めて影響範囲をチェックし、根本的な対応策を反映させる。本来ならこの段階で受入テスト実施日を延期してもらい、本格的に調査をしたいところだぞ」

 「わかった。ありがとう。助かる。とても助かる」

 「それから」飛田は思いついて付け加えた。「受入テストで、重複している資材コードを使うとダイアログが表示されるが、いずれ反映させる修正版では出なくなる。そのことを指摘されたら、何とか誤魔化してくれ。いいか」

 「わかった。そこは何とかする」

 「野見山、インターセプターを作れ。篠崎さん、インターセプターを突っ込むロジックをピックアップして、マッチングする正規表現を作ってください」

 野見山と篠崎は頷いて、それぞれの席に戻っていった。飛田は突っ立ったままの石黒にテストに戻るように言ってから、長谷部と首藤課長に目をやった。

 「俺はテストパターンを作り直す。言っておくが、この件をうやむやにするなよ。こんな重大な問題が要件定義のどこの段階で洩れたのか、いずれしっかり説明をしてもらうからな」

 その言葉に青くなったのは、長谷部ではなく、首藤課長だった。

(続)

Comment(13)

コメント

匿名

最初の予告では短編でしたが、ぼちぼち中編くらいの規模に?
毎月曜朝を楽しみにしてます!
#今年はクリスマススピンオフなしで続きそうですね

匿名

>画面系機能は不具合があても

匿名

飛田がデータを確認したのが16時の2時間後で18時以降、
本番データ用テスト環境の許可で待った長谷部の帰社が17時は辻褄合わないような
午後7時で19時?

匿名

最後に首藤課長が青くなった理由が自省によるものであれば痛快なのですが、多分この流れだと見当違いのコメントが飛んでくるんでしょうね。
この手の人種の想像の斜め上の思考回路にワクワクしてしまいます。

匿名

お客様を責めるなとかいいそうですねw

ななし

経歴的に、飛田バッドエンドになる前提で読んでるのですがどうなるか

リーベルG

匿名さん、ご指摘ありがとうございました。

匿名

長谷部に責任押し付けてトンズラでしょうね

匿名

すみません、つかぬ質問なのですが、
飛田 の読み方は
ひだ
とびた
のどちらでしょうか?
隣席の同僚と議論になりまして、回答を知りたい次第です。

リーベルG

匿名さん、こんにちは。
ひだ、です。

匿名

教えて頂きありがとうございます。
了解しました。
同僚の方が正解でした、、、

Edosson

さて、飛田さんも課長さんもぶれないとして、
長谷部君はどうするんでしょうね。
一番情けないのは、課長について飛田さんに責任転嫁かな。

別業界の人間

匿名さん、私も「とびた」だと思っていました。

コメントを投稿する