真面目で優しいシステムエンジニアは損をする⑧~障害~

2022-03-26

どうも!ヒグッティ(ヒグッティ@システムエンジニア)です!
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は崩壊しながらもギリギリのプロ ジェクト状況の話について書きました。

真面目で優しいシステムエンジニアは損をする⑦~崩壊~

今回はシステムテストで発生したエラーの話となります。ではお楽しみください。

障害

年が明け1月になりました。パーマさんとボウズさんの代わりの人が来ました。向井さん、ハムさんとします。理由はそれぞれ向井理に似ているから、ハムスターを飼っているからです。
システムテストは向井さんと私が担当になりました。それ以外のメンバ(茶髪さん、ヘビさん、マッチョさん、ハムさん)はplsqlの変換、テスト支援でした。

システムテストから人を入れるってあまりないですよね。普通は設計や開発をやって仕様がわかっている人がシステムテストやるんですけど、もはやいなくなってしまった…私が仕様をほとんど引き継いでいましたが、向井さんに引き継ぐ間もなく、システムテストが始まりました。贅沢を言えば1週間くらい仕様理解や調査に時間をあてたかったですが、お客さんに新しい人が来たので仕様理解のため1週間時間下さい!とも言えませんでした。以前、似たような話をお客さんにしたら、めちゃくちゃ怒られました(笑)「そんなことうちのしることか!そっちの都合で人を入れ替えたんだからスケジュールを変えるのはおかしいでしょ!」と。
なので引き継ぎもままならずシステムテストをせざる負えなかったです。
幸い向井さんは優秀でした。私が向井さんにシステムテストの内容とやることを伝えると、向井さんはすぐにテスト仕様書やテストデータを作成してくれました。向井さんはゲーマーでゲームのため、仕事は遅くても19時くらいには終わっていました。向井さんがいなかったらシステムテストは終わっていなかったです。そんなこんなで、システムテストに突入していきました。

PM∶明日から実際にシステムテスト始まりますけど、準備は大丈夫ですか?
ヒグ∶はい。他システムからファイルを取得してちゃんと取り込めるかのテストがメインとなります。
PM∶了解です。あとテスト状況を管理できるように何か管理表のようなものを作っておいて下さい。
ヒグ∶管理表ですか…?(明日からテスト始まるのにまだ何か作るのかよ…)
PM∶はい。日々、どんなテストをしたとか、どのテストが残っているかを管理したいので。以前、使っていたExcelのフォーマットがあるのでそれを使ってください。
ヒグ∶了解です。
PM∶あと、毎朝、その管理表を元に会議します。進捗報告をして下さい。
ヒグ∶了解です。(まじかー。毎朝会議は嫌だなー)

PMさんから管理表をもらい、今回のシステムテスト用に改良することになりました。この時、19時30分…いつものことながら残業確定…お客さんは定時頃に会議して、次の日までに資料作成を依頼してきます。わざとか?そんなことを考える暇もなく、管理表の使い方から調べることになりました。この管理表は他の会社の人が作ったものらしく、PMさんも使い方を知らないようでした。そんな管理表を俺に渡すなよ…と思いながらシステムテストの予定を記載していくことに。Excelに書かれた式を1つずつ調べながらどのセルに値を入れればよいのかを調べました。マジで面倒くさい。こーゆー作業に時間を取られていると作業が進んでいる気がしないんですよね。本当は他にもやらなければいけない事があるのに、お客さんの指示で横槍な作業が入ってきて…もちろん、この管理表が必要なのはわかるけど…まぁしょうがないかと自分に言い聞かせながらこの日も夜遅くまで作業をして帰りました。

システムテストの開始日になりました。他システムと連携しながらの作業なのでうちのタイミングでテストはできません。テストの実施時間にも制限がありました。16時〜18時までしか時間がありませんでした。当初はうちだけでシステムテストできるはずだったから特に制限もないはずだったのに…
あとあとPMさんに何でこんな事になっているのか確認しましたが、エンドユーザさんから「システムテストやるなら、ついでにシステム間でファイル送ったりしたほうがいいじゃん。4月からやる予定だったテストを前倒しにできて一石二鳥だね!」と言われたそうです。PMさんも快諾したとか。少しくらいうちにも相談してくれよ…その後、エンドユーザにシステムテストを実施する時の時間などを確認したところ、夕方しかテストできないと言われたりしたそう。
完全にエンドユーザに言いくるめられてるじゃん…しかも被害受けるのはうちのチームだし…

PM∶ではシステムテスト初日ですし、簡単に朝の会議を始めましょうか。
ヒグ∶はい。
PM∶今日から私の上司の仲間さんもこの会議に参加してもらいます。
仲間∶よろしくお願いします。
ヒグ∶早速ですが、今日のテスト予定はこちらになります。・・・(色々説明)
PM∶わかりました。システムテストで実施する総テスト件数は何件ですか?
ヒグ∶25件です。
PM∶了解です。管理表のこのシートに総テスト件数とか書いてあるんですけど、エラーになってますね。
ヒグ∶本当ですね。すみません。修正します。
PM∶あとこの総件数のあるシートとか他のシートもそうなんですけど、見づらいですね。もっとわかりやすくしてください。この項目をここの列に追加して、あと新しくこの項目も追加して・・・
(30分くらい管理表についての指摘をもらう)
PM∶って感じで、あとはさっき言ったことを修正してわかりやすくいい感じにしておいてください。
ヒグ∶はい…(めちゃくちゃ多いな…メモを取るだけで精一杯だったぞ…)
仲間∶ちょっといいですか?
PM∶さっきPMさんが言ってたところだけど、その書き方だと誤解するかもしれないからもっとこうやって・・・
(30分くらい議論が交わされて…)
仲間∶こうしたほうがわかりやすいよね!
PM∶ですね!じゃあ、ヒグさん今のも修正しておいてください!
ヒグ∶り、了解です、、、
仲間∶あと総テスト件数だけど、このテストは1件として数えてるけど、ちがうよね?
ヒグ∶と言いますと…
仲間∶テストは1件に見えるけど、この中に何件か複数テストをやるように見えるんだけど違う?
ヒグ∶たしかに、1件のテストの中に複数の操作が入っているので、複数のテストと言えばそうかもしれないですね。
仲間∶でしょー!この書き方だとテストをまとめちゃってるからぱっと見、分かりづらいな。テストは最小のタスクにまで落として記載しておいてね!
ヒグ∶そうですね!わかりました。

朝の会議は無事?終了しました。朝の会議だけで1時間30分かかりました。午前中はほぼ会議だけで終わりました。仲間さんはお客さんの中でも珍しく開発を経験している人でした。なので現場の作業の進め方もわかっている人でした。その分、突っ込みも鋭いですが…
この後、管理表を修正しました。午後は管理表の修正とシステムテストの準備、実施であっという間に終わりました。
システムテストは16時から19時頃まででした。この日は他システムが作るファイルの中身が空だったため、ファイルの取り込み結果としては、確認できませんした。ファイルの中身が空であることは想定通りだったらしい。最初は取り込み処理を実施したらテーブルにデータが何も入ってなかったので、バグか!?と思いましたが、ファイルの中身がなかっただけでした。
次の日も同じように朝から会議をし、夕方からシステムテストでした。しかし、この日、システムテストで初めての障害が発生しました。
障害の現象はファイルを取り込む際、エラーが発生することでした。何回やってもエラーでした。

ヒグ:なんで、エラーになるんだ…
茶髪:わからないなー
向井:謎ですね…
ヒグ:今日は3ファイルの取り込みテストだけど、このファイルだけ取り込みエラーになるんだよなー。他のファイルは正常に取り込めてるよね?
向井:はい。問題無いです。
ヒグ:どうやってテスト実行してる?
向井:ヒグさんに言われた通りですよ。バッチを実行するために、このバッチ実行ソフトの画面からジョブ実行ボタンを押してるだけですよ。
ヒグ:そうだよね…
茶髪:原因はファイルの内容を取得した後、特定のバイト数以上にアクセスすると、アウトバーンエラー※になります。
※アウトバーンエラーはファイルや配列にアクセスした時、指定したバイトにアクセスしたが、指定したバイトが存在しないこと。
ヒグ:そうか…ファイル見ると指定したバイトには文字が入ってるから問題ないんだけどなー
茶髪:そうですね…ファイルは問題ない。単体テストでこのエラーになったファイルを取り込んだけど、エラー出なかったよ。
ヒグ:マジすか…サーバで手動でバッチのコマンド実行したらどう?
茶髪:やってみますね!
ヒグ:おねがいします。

その日、色々と調査しましたが、エラーになる理由がわかりませんでした。
次の日の朝、お客さんに報告しました。

ヒグ:というわけで昨日のテストで、エラーが発生しました。
PM:そうですか。原因はわかっているんですか?
ヒグ:いえ、まだ調査中です。単体テストや手動でコマンドを実施すると問題なく処理が終了してファイルの内容が取り込めるのですが…アプリは問題無いと思うんですよね。
PM:すみません。ヒグさんの言っていることが全くわかりません。手動でコマンドを実施するとか、アプリに問題がないってどういうことですか?
仲間:PMさん、それはバッチを手動で実行したら処理がうまくいって、バッチ実行ソフトからバッチを実行したら処理がエラーになるってことですよ。ヒグさん合ってますか?
ヒグ:はい。認識の通りです。
PM:なるほど…対策の目処は立っていますか?いつまでに解決できますか?
ヒグ:まだ目処は立っていませんが、バッチ実行ソフトをインストールした人に話を聞かないと何とも…もしかしたらインストールの方法が悪かったかもしれません。
PM:そうなんだ…でもバッチ実行ソフトからでも成功してる処理はあるんでしょ?
ヒグ∶はい。あります。
PM:じゃあやっぱりアプリが悪いんじゃないの?他を疑う前に自分のところを疑ってください。それで、問題ないと証明できたら、私がバッチ実行ソフトをインストールしたチームに問い合わせをします。
ヒグ:証明ですか…難しいですね…どうすればよいか…
PM:とりあえず引き続き調査をお願いしますね。他のシステムテストについては順調ですか?
ヒグ:はい。問題ありません。調査しますね。分かり次第報告します。

やはり、お客さんに悪い報告をするのは何度やっても慣れません
実際、チームメンバに聞いてみましたが、調査結果は変わらず。完全に行き詰まってしまいました。そんな時、バッチ実行ソフトをインストールした人(正確にはインストールの指示をした人)と話をすることができました。この人は別のチームの人でお客さんの会社の人です。この人を以降、猪鼻さんとします。

ヒグ:猪鼻さん、バッチ実行ソフト経由でバッチを実行するとうまくいかないんですよ…インストールした時のことなどを聞かせてくれませんか?
猪鼻:そ~ですか。わかりました。私がインストールしたわけじゃないので、実際にインストールした人に聞いてみますね。
ヒグ:お願いします。
猪鼻:インストールした時のエビデンスやログをもらいました。中身は詳しく見てませんが、問題無さそうですよ。
ヒグ:そうですか。確かに問題なさそうですね。ありがとうございます。

次はインフラチームのノッポさんにも話を聞いてみました。

ヒグ:今、こんなエラーが出ていて…
ノッポ:わからないな。うちはサーバをAWSに構築しただけだからなー
ヒグ:そうですよねー。今、システムテストをやってる環境ってどうやって作ったんですか?
ノッポ:えーっと、ヒグさんチームで作った開発環境をサーバごとコピーしてテスト環境として作りました。
ヒグ:そうですか…特に問題なさそうですね…

色々な人に話を聞きましたが、ヒントは得られずでした。開発がある程度、大きいプロジェクトになると、タスクによってチームを細く分けたりするんですよね。それはそれでメリットもあるんですけど、今みたいにエラー原因を突き止めようとすると、色々チームに話を聞かないとわからないというデメリットもあります。
そんな中、ある共通点がわかってきました。失敗する処理は取り込むファイルに日本語が含まれていたのです。

ヒグ:ファイルに日本語が入ってる処理はエラーか…文字コードはUTF8ですよね?
茶髪:はい。でもソースを見てもUTF8で取り込むように指定しているんですけどねー。手動で実行した時は問題ないし…
ヒグ:ですよねー。ってことはバッチ実行ソフトに問題があるとしか考えられないなー
茶髪:そうだね。でもバッチ実行ソフトは他のチームがサーバにインストールして、問題なかったんでしょ?
ヒグ:うん…
茶髪:バッチ実行ソフトの事はよくわからないしなー
ヒグ:とりあえず私はバッチ実行ソフトについて調べてみますね。茶髪さんは引き続き、plsqlの変換をお願いしますね。
茶髪:了解ですー。

こうしてバッチ実行ソフトについて調査することにしました。まずはバッチ実行ソフトの会社が出しているマニュアルを読んで…ってこのマニュアルが100ページを超える量のマニュアルでした。全部は読んでられないので文字コードに関する設定のページだけを読んでいくことに。するとインストール時、バッチ実行ソフトはサーバのデフォルトの文字コードを参照して、インストールされることがわかりました。早速、サーバの文字コードの設定を確認。すると、英語のSJISと設定されていました。なんで~!?本来なら日本語のUTF8なのに!!さらにバッチ実行ソフトの設定ファイルを見ると処理するときの文字コードが英語のSJISになっていました。これが原因でした。バッチ実行ソフトで処理を実行すると全てのファイルをSJISとして読み込んでしまうのでした。すぐに設定ファイルを修正し、バッチ実行ソフトから処理を実施。すると処理は見事に正常終了しました!!長かった…この問題を解決するのに3日かかりました。
この事をお客さんに報告しました。

ヒグ:こういう理由で無事問題は解決しました。
PM:解決したんですね!!良かった!ちなみに原因の説明をしてもらったんですけど、何を言っているか全くわかりません。そもそも何でそのようなことが起きたんですか?
ヒグ:おそらくサーバを作る時に文字コードの指定を誤ってしまったと思います。それに気づかないままバッチ実行ソフトをインストールしてしまったので今回のエラーが発生したと思います。
PM:まぁいいや。この問題を横展開しておいて下さい。ノッポさんや猪鼻さんにも説明してくださいね。そもそもサーバの設定を変更したりバッチ実行ソフトの設定を変更してしまったら今までのテストはやり直しになりませんか?
ヒグ:はい。やり直したほうがいいと思います。なので、システムテストで実施したこの1週間分のテストは再テストしたほうがいいですね。
PM:えー、それは困るよ…エンドユーザともスケジュールは決めちゃってるし、なんとかならない?
ヒグ:こればかりは何とも…

この会話の後、PMさんがノッポさんと猪鼻さんと話して再テストはしなくて良いことになりました。何故かはわかりませんが、不思議な力が働いたようです。横展開についても、しなくて良いことになりました。何故か不明です。
その後、猪鼻さんに修正したバッチ実行ソフトの設定ファイルと修正箇所を展開しました。猪鼻さんもこの設定ファイルについては何も知らないようで、展開した意味があったかどうか疑問ですが。そしてこの問題はその後、触れられることもなく、闇に葬られることになりました。ノッポさん、猪鼻さんもお客さん先の社員なので、客先の社員のミスはできるだけ無かったことにしたかったのかな?と今になって思います。
システムテストはその後もエラーが発生したり、修正したりと色々ありましたが、無事完了の目処が立ってきました。相変わらず、エビデンスを用意したり、報告資料を準備したりと遅くまで作業していましたが、作成したアプリが正しく動いていることに達成感がありました。
今日も帰って東海オンエアを見て元気をもらいながら就寝しました。東海オンエアって子供の時やりたかったことや想像もしえなかったことを大人がやってくれるから面白いんだよなー!明日からも頑張ろう!!

まとめ

人を入れ替えても引き継ぎや仕様理解のスケジュールは予定に組まれない。
相談もなしに勝手にシステムテストの時間や方法が決められていく。(しわ寄せは末端にくる)
1つのエラーの解決に一日以上かかることも珍しくない。
お客さんに良くないことを報告する時は覚悟が必要。
日本語や文字コードはエラーの原因になりがち。

スポンサーリンク