この記事は ex-crowdworks Advent Calendar 2024の24日目の記事です。

はじめに

今年、株式会社クラウドワークスを退職した@nisyuuです。来年はサイフォン式コーヒーに挑戦します。
エンジニアとしてクラウドワークステック（旧クラウドテック）というフリーランスと企業をマッチングするエージェントサービスを開発していました。

2023年7月1日、クラウドワークステック（旧クラウドテック）であるお知らせが投稿されました。

作業報告書というワーカーが作業の時間を記録して提出するための機能があるのですが、ある時、突然提出ができなくなるということがありました。
提出ができなくなると、作業時間の確認が出来ずワーカーに報酬をお支払いできなくなる可能性もあるため事業にも大きく影響があります。

直近で影響のあるリリースはなく、チーム総出で調査をしたのですが原因特定は難航を極めました。
さらに、作業報告書は月末締めなのですが、問題の発生がちょうど月末と早急に解決しなければならないタイミングでした。

時間が経つにつれてチームの雰囲気が悪くなり、ちょっとした争いにも発展するほどでした。
ピンチや困難な状況では、真価が問われるからこそ、より冷静でいましょう。

なんとかこの状況を打破したかった当時まだ若造の下っ端エンジニアである私は、手がかりを見つけるためにログ調査を地道に進めました。
ログ調査の内容を共有しながら対応していたところ、なぜかダメ出しのようなものが飛んできたりもしましたが、持ち前の気合いとド根性で自分を信じて黙々と調査をしました。
土壇場では自分を信じる気持ちが案外成功につながるものです。
この地道な調査の甲斐があってか、早急に原因を特定でき、翌営業日には問題なく機能を回復させることができました。

このときの障害は、個人的に衝撃かつ強烈な体験であり、大きな教訓が得られたため将来有望な未来ある優秀なみなさまの血となり肉となることを願って、記事にすることとしました。

具体的な事象

発生していた問題は、作業報告書のボタンを押すと404ページに遷移してしまうというもので、正しい挙動は遷移せずにPOSTリクエストをするというものでした。

ボタンはaタグになっており、rails-ujsを使っていたため、リンクが押されると本来はGETリクエストでなくPOSTリクエストに変換するというような処理になっていました。

問題の原因はなんだったのか

結論を先に出すと、原因はGoogle Tag Managerの設定でした。(以下GTMに省略)

指定のクラス名を含むリンクが押されたときにGTMのトリガーを発動する設定ができるのですが、発動場所のリンクにrails-ujsが使われており、GTMと干渉し合っていたことが問題の起因になっていました。

原因特定までの道のり

原因は、主にこのような道のりで特定しました。

問題を再現する
何が原因となり得るか絞り込みする
本番環境とステージング環境の差分を確認
Chromeの検証ツールで通信制御してみる

問題が再現する

問題が再現するか実際に挙動を確認します。
再現させることで、手元でエラーの調査がしやすくなります。

何が原因となり得るか絞り込みする

フロントエンドで起きていたことと、GETリクエストからPOSTリクエストに変換している処理はJavaScriptで実行していたため、読み込んで実行しているJavaScriptのソースコードに問題があると推測しました。

本番環境とステージング環境の差分を確認

本番環境とステージング環境で読み込んでいるJavaScriptコードは違うため、原因特定の手がかりとして2つの環境を比較しました。
比較してみると、ステージング環境では作業報告書のボタンを押しても正しい挙動になることがわかりました。

本番環境で読み込んでいて、ステージング環境では読み込んでいないJavaScriptコードは何かを調べると、マーケティング用に入れているコードがHTMLのscriptタグを使って入れられていることが分かりました。

Chromeの検証ツールで通信制御してみる

Chromeの検証ツールを使うと、特定のscript読み込みを止めることができます。
試しに、マーケティング用に入れているscriptの読み込みを制限してみました。

導入しているマーケティングツールはいくつかあったため、手探りで調査を進めたところGTMの読み込みを制限することで正常に動作しました。

Stackoveflowにも同様な事象が報告されていたため、GTMが原因であると推測できます。

GTMの設定を確認してみると、問題が起きていたリンクが押された時にトリガーを発動するような条件が含まれており、試しに該当のトリガーが設定されているタグを停止してみると問題が起きなくなりました。

これで原因がGTMであると確定できました。

再発防止策

原因が究明でき解決できた後に、再発防止策を考えました。
これまで、GTMの設定はマーケティングチームで設定し本番反映まで行っていたのですが、GTMの設定は柔軟性が高く予期せぬ箇所へ影響が出ることもあるため、ステージングでチェックしてもらうようにしました。
さらに、本番反映前は設定に問題がないかをエンジニアチームでチェックをする体制を強く意志を持って提案し導入しました。

これ以降は同じ問題が起きていないので、チェック体制が上手く機能しているのではないでしょうか。

事実から推測せよ

ここで紹介した問題と解決までの道のりを通して、大きな学びが一つあります。
それは、事実から推測するということです。

この世の全ては、事実から成り立っています。
当たり前のことですが、明確に認知しているのとそうでないのとでは天と地、いや、スーパーカブとスカイラインほどの差があります。

何かを推測するときに、仮定から入ってしまうと推測が大きく外れてしまうことにもなります。
そのため、まずは観測を元に事実を認識し、事実に紐づくであろう推測をしていくことが問題解決の正しい在り方です。
太陽系を知らなかった人類も、天体観測から分かった事実によって地動説を導きました。
一方、天動説はどうだったか。地球を中心として太陽が回っているという仮定のもと、何百年も事実である観測結果に反する論調がまかり通っていました。
仮定から話を進めてしまうということは、過ちの始まりにもなり得るのです。

おわりに

開発現場では、大きな問題に直面した時ほどチームの実力と真価が問われます。そして、実力と真価は常にアップデートされ継承されていくべきものです。
今回の問題解決方法は、1人で調査して解決してしまったという属人化観点での反省点があり、これは継承していくべきものであるため、将来有望な未来ある優秀な若手に継承しました。
クラウドワークスは新しい風を取り入れられる土壌があり、若手が活躍できる貴重な会社の一つなのではないでしょうか。
そのためにも、若手にチャンスや技術力、仕事術を積極的に継承していくべきなのだと思います。

誰もが実績を作って認められたいと思うのは、当然のことかもしれません。しかし、時には席を譲ることで、将来有望な未来ある優秀な若手の活躍の場を広げられ今後の発展にも繋がります。
退職という判断をできれば控えたかった私も席を譲った立場であり、席を譲ったことで活躍の場が広がった優秀な若手もいます。
そのため、雑用ばかりを若手に押し付けるのではなく、時にはしっかりと活躍のできる席を譲ることも、あって良い選択肢なのではないでしょうか？