挨拶
こんにちは、Nealle QAチームの船木です。 この1年をかけて10kg近いダイエットに成功しました。
この調子でいけば数年後には浮力を得られそうです。成功のポイントはやっぱり歩きめです、ってね（ドッ
自己紹介
さて、私はこれまでのQA記事にもたまに登場していた「1人目QA」です。
1人目QAが登場した記事：https://note.nealle.com/n/nff280a692aae
私は、QAエンジニアというキャリアを積んできたわけではなく、あくまで開発者でした。
Park Direct の QAとして何をしてきたかは前回以前の記事が詳しいかと思いますが、縁あってプロジェクトに参画することとなった後は、QAのようなSETのような開発者のような、3足のわらじを武器にする形で様々な角度から品質保証に携わる業務を行なっております。
これはどんな記事？何を得られる？
3足のわらじを武器にあらゆる手段を用いて様々なことをやってきました。一般的な話は他のQAの方の記事に任せるとして、この記事では私がこれまでにやってきた（やっている）ユニークそうな取り組みをご紹介します。
壊れるほど書いても3分の1も伝わらないかもしれませんが、「業務改善にそんな切り口が…!?」という、何らかの発見や参考になれば幸いです。
何がつらいの？
詳しくは割愛しますが、現在QAチームでは以下のような業務をしています。
- 開発案件への取り組み（インプロセスQA等）
- ビジネス側から上がってくるプロダクトに関する開発への質問・要望、または何か事が起きた時の調査の窓口
- E2Eテスト自動化を始めとしたテスト自動化への取り組み
QAチームとしては、これらを黙々と粛々とこなせたら最高なのですが、
現実は…！あらゆることに…！ 時間が足りない…っ！！！
複雑に要素が絡み合ったE2Eテスト用のデータ1つ作るのもひと仕事ですし、ビジネス側からのプロダクトに関する質問はほとんどの場合お客様からの問い合わせを発端とするケースバイケースな事案であり、状況整理とともに推理を重ねて真実に辿り着く様は脳汁が溢れこそすれ、同時にとんでもない時間泥棒です。
E2Eテスト用の複雑なテストデータは、そこに至るまでの過程や操作も多く、たった1つのデータを作るために何時間もかかったりしますし、問い合わせの調査は1日がかりになることも珍しくありません。
Park Direct が目下圧倒的なスピード感で開発に取り込み続けていることは、これまでの記事をご覧の皆さんならすでにご存知のことかと思います。
これらそれぞれのつらみについても、それぞれの事象について改善のための問題提起や課題提起はされ続けており、実際に改善されていることも多いですが、開発チームもすべての要望やつらみに応えるにはリソースにも時間にも限界があり、優先度によって切り分けられて泣く泣く積まれていくものが沢山あります。
大地に立つ
開発チームで手が回らないなら、自分で作ろう（名案）
別に誰かに頼まれたわけでもなく、本来の業務の片手間に、暗躍が始まりました。
結果として、なんかいろんなものを作ってしまいましたし、今なお作り続けています。
そして作ったものが、自分が楽するだけの枠を超えてQAチームに波及し、QAチームを超えて開発チームに波及し、部署の垣根を超えてビジネス側の人々にも波及してしまいました。
何を作ったの？
結論として、Park Directドメイン上でのみ動作する「Chrome拡張機能」を開発することにし、用途別に以下のツールを作成しました。
- Park Direct のE2Eテスト上で実行が大変なAPIを簡単に実行するツール
- Park Direct の各画面からその機能で出力されたログ検索を簡単に行うツール
- Park Direct 上で本来動線がないデータ間を連結する機能を追加するツール
まず前提として、なるべく、アプリケーション本来とは全く疎な状態で作りたい… すなわち既存のアプリケーションのソースコードを触ったりせず、欲しい機能だけいい感じに追加することを目標としました。
発想としては、アプリケーションが提供している API を活用して、3rd Party アプリを作ろう という感覚に近いです。
例えば、X（旧Twitter） のある部分がもうちょっとこうなったらいいのに…ということがあった時、X が提供する API を使って 3rd Party アプリ作ろう！などと思い立ちますよね？（※ 今は色んなしがらみがありますが…）
それを自社プロダクトでやってやろうという気概です。
3rd Partyとは言いつつも、実際はPark Direct 開発の中の人であるため、ソースコードは自由に見れるので、何をするためにどんな API を呼べばいいかは丸裸も同然です。
1. Park Direct のE2Eテスト上で実行が大変なAPIを簡単に実行するツール
Park Direct は、多くの登場人物が、多くの手続きの過程で、多くの操作をすることで初めて意味のあるデータが出来上がります。
その過程には、E2E操作ではとても実行できないものも多くあります。例えばわかりやすいところだと、Park Direct アプリケーションの外、保証会社に対してデータを送った・受け取ったという操作や、決済代行会社に対してデータを送った・受け取ったという操作です。
そのほとんどは、結局はシステム間のHTTPリクエストのやり取りで行われるわけですが、システム間連携のインタフェース、すなわちパラメータやレスポンスの内容に熟知した開発者ならいざ知らず、開発者ではない人がこれを行うのは至難でした。
とはいえそう泣き言も言ってられないので、これまではQAでも、HTTPリクエストを実行できる何らかのHTTPクライアントアプリを用意し、現在操作中のデータと辻褄が合うようにリクエストを調整して、欲しい結果となるように1個1個丁寧に実行していくということが必要でした。
たった一つのデータを作るために数十分もかかる不毛にも思える作業に疲弊する毎日… 😞
これが私作のツールにより、Chrome拡張機能上のボタンポチだけで、誰でも5秒で終われるようになりました。🎉
具体的には、ある画面またはあるデータを対象に操作したいということである限り、パラメータになり得るのはその対象データでしかないはずなので、画面上の表示や内部APIの呼び出しなど、Chrome拡張機能から取得可能なあらゆる値を使って、あらゆるAPIをチェーンして、ボタンひとつで目的の状態に至るまで完了できるようにしました。
同じChrome拡張機能ツールであらゆる環境（Dev、Staging、Feature、ローカル）で同様に動作するように作ったので、QAチーム内や開発チームでも概ね評判高く活用していただけているようです。
2. Park Direct の各画面からその機能で出力されたログ検索を簡単に行うツール
Park Direct では様々な場面で履歴データを作成したり、操作に関する履歴ログを出力しています。その先はシステム上のメインDBであったり、BigQueryであったり、Datadogであったり、CloudWatchであったり、用途毎に様々ですが、少なくとも我らが基盤チームの功績により過不足が無いように蓄積され続けており、これを検索できるような基盤が用意されています。
ビジネス側からの開発問い合わせでは、やはりお客様からの問い合わせが発端であることが多いので、あるデータについてこの操作ログはどうであったかとか、どういう経緯でこのような状態のデータになったのかなどといった調査の依頼が多いです。
そしてこれが非常に時間を食います。
何から検索することが適切か、なんの値をキーとして調べれば良いか、呼び出されたAPIが何であったか、欲しい情報に合致するログ仕様上の識別番号は何であったか… 毎回ほぼゼロベースで調査を開始することになります。
たった1つの調査チケットを解決するために、半日がかり、1日がかりの不毛にも思える作業に疲弊する毎日… 😞
これが私作のツールにより、Chrome拡張機能上のボタンポチだけで、誰でも5秒で終われるようになりました。🎊
具体的には、ある画面またはあるデータを対象にそのログや操作履歴を確認したい限り（例えばそれが駐車場に関するログなのか、顧客情報に関するログなのか、など）、見るべきログ仕様はほぼ決まっており、そのログを検索するためのパラメータになり得る値もほぼ決まっているので、これをツール内で定義化し、画面上の表示や内部APIの呼び出しなど、Chrome拡張機能から取得可能なあらゆる値を使って、Datadogのログ検索クエリ実行画面へのショートカットを一発で作成したり、関連するデータを取得するためのSQLを一発で提示したりできるようにしました。
これは主に本番環境での利用を想定していますが、あくまでデータを参照するためのリンクの提示、またはSELECT文クエリの提示に過ぎないので、本番環境でも臆することなく極めて安全に実行することができます。
QAチーム内では、いつの間にかさも当然のように使われています。
3. Park Direct 上で本来動線がないデータ間を連結する機能を追加するツール
Park Direct では様々なタイプのデータが複雑に絡み合っています。本当によく使うデータ間では、システム上で相互に確認できるような仕組みが作られていますが（例えば、駐車場の区画とその顧客情報といったような）、それ以外については基本的に機能として独立しており、各々の機能上で手動で値を指定して参照することが普通です。
これが私作のツールにより、Chrome拡張機能上のボタンポチだけで、本来アプリケーション上には存在しない、機能間の連結をできるようにしました。🥳
例えば Park Direct における請求情報や決済情報は機能として完全に独立しています。
ある顧客情報についてその請求情報等を参照するためには、その顧客情報が持つ何らかのキー情報を控えた上で、請求情報を管理する別機能にて改めて検索、参照等を行う必要がありました。
ある顧客情報から、その顧客情報に関連した請求情報等を直接参照する入口は公式では用意されてないのですが、欲しいと思って追加することにしました。（直情型）
具体的には、顧客情報画面上にてChrome拡張機能の実行ボタンを押すと、本来アプリケーションには存在しない、各機能に直接遷移するためのボタンやリンクを追加するようにしました。
ここから遷移することで、顧客情報が持つ必要なキーを自動的に取得し、遷移先の機能のクエリパラメータに反映させたり、画面上のinput項目に自動的に入力して検索を実行したり、関連データの取得結果をいい感じに子画面で表示したりするようにしました。
結果、非常に痒いところに手が届く機能だったらしく、開発チームという垣根を超え、主に支払い関係を担当している運用側のチームにまで波及し、非常に便利に使っているという有り難い評価をいただきました。
そんなところにまで及んでしまうのはある意味誤算でした。（責任が...😂）
まとめ
これらの活動により、本来は Park Direct には存在しなかった各種機能を、普段使っているブラウザ以外の何かを全く必要とすることなく、全く外側から注入することに成功しました。
結果、
- 「数時間かかりがちなテスト実施の準備が、秒で終わるようになった！」
- 「数時間かかりがちな開発調査依頼が、秒で終わるようになった！」
というような、手動で愚直に何とかするのが当たり前だった作業を駆逐するというパラダイムシフトを巻き起こし、
また、
- 「ちょっとした機能追加なら、工数をかけてアプリケーションそのものを改修するよりも、Chrome拡張機能で実現するので十分なんじゃ…？」
というような、アプリケーション自体の改修無くして機能追加は不可能だろうという固定観念を破壊するという、業務上のパラダイムシフトを巻き起こしました。（誇張）
残念ながら、実際の画面や作ったものについては企業秘密の塊すぎるため、何にも公開できないのですが...
これらの実現は私一人の力ではなく、前述までの記事の通りPark Direct を支える各チームたちの功績、堅牢しかし柔軟性の高いログ基盤やセキュリティ基盤や開発基盤、あらゆる無茶を通せるが崩壊しない拡張性を備えたアプリケーションだからこそです。
私はあくまで、配られたカードで勝負しただけで、配られたカードが強かっただけとも言えます。
しかしながら、Chrome拡張機能開発を通して「Chrome拡張機能って、意外と何でもできるな？」という知見を得られたのは習得でした。
業務でもプライベートでも、ちょっとした何かを実現したいとき、Chrome拡張機能は一つの可能性になり得るかもしれません😉
終わりに
結論としては Park Direct 専用の「Chrome拡張機能」を作ることで実現することにしましたが、これは今欲しい何かについて、最も早く最も手軽に実現できると思ったからです。
別方法としては、例えば Flutter 等で WebView を活用して Park Direct をラップしたネイティブアプリ（あるいはSPA）を作ろうかとか、Electron などを活用して Park Direct をラップしたデスクトップアプリを作ろうかとかなどが思いつきましたが、一旦オーバースペックだと思いやめました。
もしかしたら今後、SDKでしか提供されてない AWS API まで何とかしたいとか、PC自体やデバイスが持っている機能を使って何かを便利にしたいというような、ブラウザ上のJavaScriptでは実現不可能な無茶がしたくなってきたら… その時に考えます。
これらの活動のほかにも、AutifyでのE2Eテストシナリオにて、およそAutifyが対応していないような無茶の極みのE2Eテストを実現した話などもありますが… それはまた別の機会に😉
