139
49

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

本番環境でやらかしちゃった人Advent Calendar 2021

Day 18

アンケートサイトを作ったら一部の回答が漏れてた話

Last updated at Posted at 2021-12-17

三行

  • アンケートサイトの回答データを見てたら一部設問の回答データが全くないことに気づいた
  • 原因は前提条件の確認不足とテストが不十分だったこと
  • 例え当然の帰結に思えても憶測で判断してはいけない。

デブ、やらかしたってよ

おはようございます。
いつもこの時期になったらクソアプリ見てケラケラ笑って、やらかした話見てチビってるデブです。
ふと見たらカレンダーに空きを見つけ、折角なのでと突っ込んでみました。

ちょっと長いですがあと愚痴が見え隠れしてますがお付き合いいただければと思います。

ことのあらまし

初っ端から脱線しますけどあらましって元々「願いごと」とか「将来の展望」とかって意味があったそうです。
なお以降はフェイク入れたり誇張表現モリモリです。
大筋は変えてませんので所謂「事実を元にしたフィクション」というやつですね。

これは、私が実際に体験した話です。
1、2年ほどの前のこと、それまで私は.NetやC++使った業務系や制御系を主にやってたんですけど、(実務では)未経験のweb系業務を中心としたグループに異動となりました。
何故か上司が技術を教える気配がなかったので仕方なく独学で知識を吸収しながら改修や調査等の業務をこなしていて一か月くらい経った頃でした。
「デブ君、これやって。仕様これね」
と渡された資料を見てみてみると、アンケートサイトを作ること、その目的が書かれた箇条書きのメモと、サイトの挙動指定、紙にすること前提の質問項目がびっちり書かれたwardwordドキュメントしかなかったのです。
(2021/12/20 修正)

そう、今にして思えばそこには仕様ではなく、要件まで落とし込み切れていない要求しか書かれてなかったのです。
しかし当時の私は「まあ今までの研究開発もこんなんだったしとりあえずやるか」と作業に取り掛かったのです。

それが地獄への招待状だとも知らずに。

今までのグループでやってきたものを参考に、と言われてサンプルを渡されましたが到底人に見せられるような代物ではなく、仕方なくフルスクラッチで開発することとしました。
将来的にバックエンドが変わることも見据え、

  • 基本的な挙動は全てフロント任せ
  • サーバー(php)はリクエストに応じて回答データを受け取る、あるいは返すだけ
    • 再回答機能があり、再回答時には現在の回答データを復元して予め入力されていて欲しい、という要求があったため

と言う感じでサーバーとクライアントをrest APIで繋ぐ形式にしました。
上司にもこの仕様でOKを貰ったので、とりあえずHTMLのガワだけ作って元請けさんに見てもらっている間にAPIとそのI/Fを作ってました。
(言い忘れてましたが弊社は二次請けでした。ユーザー=>元請け=>弊社 という感じで。実作業はほぼ弊社がやってました)

元請けさんからもOKを貰い、それから数営業日で大体実装が終わりました。
私と上司の方で動作確認も取れたのでまた元請けさんに見てもらい、そのままユーザーさんの確認を取ってもらうこととしました。

それからおよそ一週間後、ユーザーさんからこんなご指摘、を頂きました。

なんか表示が崩れてるし、うまく選択出来ないんだけど

冷や汗をかきながらそんなはずは、と思いよく見てみると、血の気が引きました。
そこには第一の地獄があったのです。その地獄の名は、かつての覇王、Internet Explorer。
そう、ユーザーさんはIEを使っていました。

要求の中にスマホ対応もあったので、CSSではGridを用いて画面幅に合わせて選択肢が適切に並ぶようにしたのが仇となりました。
IEはこれに対応していなかったのです。(厳密にはベンダープレフィックスを付ければある程度は対応可能。しかし使い方が、当時調べた限りではIEでは非対応だった)

急いでIE用にCSSを調整し、最低限見れるようにしたのですが、ここでまた問題が浮上します。
IEから送信した回答データが全て空だったのです。
超特急で原因を調査したところ、jsでリクエストを作る際にformElement.elementName.Valueで回答データを収集していたのが原因でした。
IEではformのデータをこのような構文では回収することが出来なかったのです。
これもまた超特急でIE対応にjsを書き直しました。
(余談ですが当時は書いたjsをそのままhtmlで読み込んでました。仕事の合間に基礎から勉強していたのでbabelやwebpackを実務で導入出来るほどの技術力や自信が当時の私にはありませんでした。因みに上司は今でもnodeを使ったことがなく、恐らくbabelやwebpackの存在は知りません)

そしてギリギリでしたが何とか実装を終え、元請けさんに確認を取っている最中に試験を終え、元請けさんのOKも出てあとはユーザーさんに確認してもらうだけ、までこぎつけたところでユーザーさんの確認結果が来ました。

送信ボタン押しても何も動かんのやけど?

私は「は?」しか言えず、上司も「え?」という感じで、弊社としては「いやいや。chrome、ff、IEは勿論ipadのsafariやadnroidのchromeでも動作確認取りましたよ」としか言えずに確認を取ると、二つ目の地獄へと誘う返答が来ました。

地獄の名はjavascript無効環境

いつから私たちは2000年代に来たのか。chromeやhtml5、es2017は泡沫の夢かそれとも渇望が見せた幻影か。まだ日曜にデジモンが見れるのか。川上とも子さんや松来未祐さん、水谷優子さん、大塚周夫さんの声はまだ聴けるのか。ああ納屋さんや永井さんの声も聞きたい。
そんな現実逃避をしたくなるのも当然でした。
その日は稼働日の二日前だったのです。

前述したとおり、フロントの挙動はjs頼み。js無効はちゃぶ台返しと言っても過言ではない状況でした。
そういうわけなので上司も「jsは有効前提で作成しました」と送ったところ、

出来ればjs無効環境でも動作するようにしていただきたいです

絶望、あるいは崖から突き落されたような気がしました。

ところで、皆さんご存知かとは思いますが、ここは「本番環境でやらかしちゃった人」のアドベントカレンダーです。
元々ある程度柔軟に流用出来るように作っておいたので、ある程度I/Fが変わっても何とかなるようには作っていたおかげで一日でどうにかこうにか対応できました。
ある程度の動作確認も取って上司の方からもOKが出て、無事予定日に稼働出来ました。

しかし、地獄はその真の姿を遅れて見せてきました

これまでのことは長い長い前置き。
「本番環境でやらかしちゃった人」の本編はここからです。

稼働から一か月後。
最初こそちょくちょく問い合わせがあったものの、比較的無事にクローズ出来ました。
アンケートの集計も弊社の業務だったのですが、それは私ではなく上司が対応していました。
作業中、「ん?」という上司の声が聞こえました。それはいつものことなのですが、少しずつ不穏な空気が漂い始めます。

「ん?」
「あれ?」
「集計ミスった?」
「んー?おかしいな」

私が手の汗を意識しはじめたところで、

「デブ君、設問Xの回答データが1件もないんだけど……」

背中や太もも、体の裏側のいたるところから脂汗が噴き出ました。
マッハで確認すると、あることに気が付きました。

問Xのinput要素にdisabled属性が付いていたのです。

この問X、詳細は省きますがちょっと特殊な回答方法を指定されていたので、元々はそれに合わせて回答データをjsで加工してデータを生成していました。
他のデータは自動で収集していたのでノイズにならないように見分け方としてhtml側でdisabledを付けていたのがことの経緯です。

それが前述の「js無効環境対応」の際に抜け落ちた結果、当該の設問では回答データが送信されていなかったのです。

その後

先方も無茶を言っていた自覚があったのか現実的だったのか、執拗に追求されることはなく補完として追加で当該設問のみを答えるアンケートサイトを作ることとなりました。
とは言え回答者は準匿名だったので紐づけるための基本情報ももう一度答えていただく形式になりました。

回収率はそこそこ良かったそうで、抜けもその設問だけだったので最悪の事態は免れたと思っています。
ただ、追加アンケートのお願いや説明を弊社のオフィスでやっていたのですが、私のミスでお姉さま方が頭を下げるように電話をしていたのが聞こえていたのでその間は精神的にとてもきつかったです。

原因と教訓

このようになった原因は色々ありますが主な原因は以下の二つ。

  • 仕様の確認不足
  • テスト不足

事前に私が対応ブラウザ、及びjavascriptの扱いを確認しておけばこんなことは起きませんでした。
(地獄は地獄ですが)
また、しっかり正式な試験手順を踏んでいれば、時間さえあれば対応できていたことでもあります。

では原因の原因というのは以下の通り。

  • 私がwebに不慣れで対応ブラウザのことを考慮していなかった
    • 当時既にedgeもchromium化しており、旧edgeもIEも無理に使おうとしなければ使えない状況だったので両者は完全に度外視していた
    • お上がここまでIEに妄執しているとは知らなかった
    • それまでは固定環境での業務が多かった
  • 「この設問でこの回答の場合はあの設問は回答不能に」「普通のhtmlだけでは出来ない回答方法の指定」等の要求があり、javascriptが有効前提だと決めつけていなかった
  • 正式な試験をする時間がなかったとは言え、「とりあえずパッと見はOK」で進めてしまった
    • もっと言えばそれまでの疲労等で「上司がOK出したし大丈夫だろ」と思っていました。(この頃は上司をまだある程度信頼していた)

はい。偏に経験値不足でした。

ゆえに以降、私は以下のことを気にして業務を行っています。

  • 対応環境があやふやな場合は確認を取る
  • javascript等無効になる可能性があるものの扱いは必ず確認する
  • 少しの変更でも、時間が迫っていても試験は正式なものをやる
    • 可能ならば自動化し、手間や時間を削減する
  • しっかり自分が納得できるものを出す

無論、これはweb系だけでなく全ての業務に通じていると思います。

また、「上司のOK出たし多分大丈夫」や「上司のOK言質取ったし、あとの責任は上司にある」という意識があったのも事実です。
要するに下っ端という立場に甘えており、プロ意識が低かったのも原因の一つだと思っていますし、大いに反省しています。
~~まあ実際その分の職位で、相応のお給金しかもらっていないので、会社と私の間でのギブアンドテイクは成立していると今でも思っていますけど。それとこれとは別の話で、~~以降は責任をもって成果物出す、逆に言えば責任が持てない状態では成果物として出していません。

終わりに

当たり前ですが、お互いの共通認識の確認は大事です。
横文字使うとコンセンサス取るのはマストです。
要件定義や設計がどれだけ大事か改めて身に染みた事件でした。

正直に言えば、下っ端で逐一上司のOKも取っていたので特にお咎めもなかったので、勉強代としてはかなり安く、このタイミングで身をもって経験出来たのは良かったです。
(会社としてはあまり良くないでしょうけど)

そして古いスマホやタブレットにも対応したアプリをリリースしている各企業さんの大変さが分かったとともに、もう足を向けて寝れません。(ipad Air使用者の感想。いやゲームとかで第7世代も使ってますけどね?)

読者の方々、とくに新人の方やこれからIT系で働く、働こうと思っている方は私や他の方の経験をもとに同じ轍を踏まないことを心の底から願っています。
いやホント、マジでお願いします。トラブル起きて幸せになる人はいないので。

まあそれはそれとして私にも落ち度があったのも事実ですし反省もしてますけど、私とユーザーの間には元請けと上司が入っていたはずなのに、**経験十数年、数十年の人材が何人も居てまともに要件定義が出来ていないのも問題では?とも思うんです。
因みに以降も似たような案件が何件か来たんですが
上司は一度も対応ブラウザやjavascriptの扱いを先方に確認していません。毎回私が指摘してから確認しています。**頼むよ上司ちゃん……

139
49
4

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
139
49

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?