asoview! TECH BLOG

アソビュー株式会社のテックブログ

Autifyでリリースチェックを自動化した話

これはアソビュー Advent Calendar 2021の20日目の記事です。

「週末、なにする?そんな時は、アソビュー!」でお馴染みの遊び予約サイト「アソビュー!」のQAを担当している青柳です。

◆Autify導入の背景

私が担当しているWebチケットシステムは、日々機能追加・改修が行われています。昨年はコロナ禍を背景に、人数制限や日時指定など条件付きのチケットを開発しました。商品のバリエーションが増えてテストも膨大になったことで、品質を保ちながら効率良くテストするという課題に直面しました。

システムが複雑化していくことによって、テストの条件がどんどん増えていきますよね。たとえばマトリクスを組んだときに、数千/数万ケース数に膨れ上がっていく状況でした。
テストにかかる工数の割合がどうしても増えてしまうため、リリースサイクルも遅くなり、QAがボトルネックになってしまうこともありました。

◆自動化ツールの選定

上記背景から、品質を保ちながら効率良くテストするという課題を解決するために自動化ツールの導入を検討しました。

実は1〜2年ほど前、SeleniumができるQAエンジニアの方に来ていただいて、一部自動化を推進した時期がありました。ですが、メンテナンスのところでうまく機能しなかったため、作ったものの使われなくなったまま終わってしまいました。
原因としては、現在のQA体制では自動化のためのプログラミングができるメンバーがおらず、機能が改修・追加されていく中で、コードを修正する作業が追いつかなかった。それがメンテナンスにおける課題でした。

前回の反省も踏まえつつ、自動化ツールに関するディスカッションを行なっているとき、同じチームのメンバーからAutifyを紹介してもらいました。
使いやすそうと感じたので、トライアルから始めてみたところ、使いやすいプロダクトだったので本格導入を推進していくことになりました。

◆Autify導入〜

今回対象にしたプロダクトがWebチケットなので、まずは、チケット領域のリグレッションテストをAutifyで自動化に置き換えていこうと考えました。弊社はリリースチェックシートを用意しているので、まずはそのチェック項目に沿ってAutifyでテストシナリオを作っていきました。

・・・なぜ、リリースチェックから置き換えとしたのか
弊社では機能リリース時にリリースチェックをクリアする必要があるのですが、PC / SPで実施する必要があるため、1.5〜2時間程度の作業時間が発生していました。
多いときは週に何度もリリースチェックを行っていたため、工数削減効果が高い、既にテストケースが用意されている点を考慮し、リリースチェックから自動化に置き換えていくことにしました。

リリースチェックを置き換えるところまでは良かったのですが「誰がいつまでに」という具体的なところを決めきれていないままで進めたので作業が停滞してしまった時期がありましたが、仕切り直した上でテストケースを用意し、プランを明確にしました。
プランに対して実装する担当も決めて、そのメンバーと連携して、テストケースを上から順にAutifyで作っていってもらうようにしました。

テストケースが増えていくと、何がどういうケースなのか分からなくなってきてしまうという課題も発見できたので、命名規則を設けてパッと見てすぐに分かる形にしていきました。
リリースチェックを置き換えていく中で、せっかく作った自動テストを使わないのも勿体ないので、該当するAutifyのリンクを貼っていって、一部だけでも動かせるようにしました。グループ機能も活用しました。

◆Autify導入後〜運用フェーズ

現在は、デイリーで動かすシナリオを用意して、標準的な機能に異常が起こっていないかを毎朝確認しています。あとは、リリースのタイミングでテストプランとしてまとまっているものを実行しています。
Slackと連携して結果が全て通知されるようになっているので、確認も容易であり、エラーがあればすぐに拾える状態です。

以前は開発メンバーにもQAの作業を一部手伝ってもらったりしていましたが、手動で行っていたテストの一部がAutifyに置き換わってきているので、最近はほとんど起こらなくなっています。

◆今後の展望

リリースチェック以外にも自動化できるところを推進していく、他のチームのリグレッションテストもAutifyに置き換えていって、人の手で確認する作業を極力なくしていきたいです。
弊社の場合、サイトに掲載してチケットを販売するまでの大きなシナリオもあります。その部分もAutifyに置き換えて、品質を定常的にモニタリングできる仕組みの1つとしてもAutifyを活用していきたいとか考えています。

Autify社からの事例紹介のインタビューの記事はこちらからご覧ください。
https://autify.com/ja/stories/asoview?utm_campaign=weekly-letter&utm_medium=email&_hsmi=191725596&_hsenc=p2ANqtz-9fNT5uyn6zOLDibKu4E4sYPIyraYhx3XNgIwNmT-JezeTIPcTRHXLRLjBbx5of_Nvqy8YBOJE3KVNipCqqMf0REoQ0FvAW2l0ffus2lVH-i8lBonE&utm_content=191725596&utm_source=hs_email

「生きるに、遊びを。」をミッションに掲げる我らがアソビューでは一緒に事業をつくる仲間を絶賛募集中です。
興味がありましたらお気軽にご応募いただければと思います。
https://www.wantedly.com/companies/www-asoview-co/projects

TypeScriptのジェネリクスに入門してみた

 

こちらは、アソビュー! Advent Calendar 2021の18日目の記事です。

こんにちは、アソビュー!でエンジニアをしている島田です
そろそろクリスマスがやって来ますが、大切な人に渡すプレゼントはお決まりでしょうか!?私は、2歳になる子供に滑り台付きのジャングルジムを上げようと思い品切れになる前に購入したのですが、いざ届くと早く上げたくなり上げてしまいました😅

さて、今回はTypeScriptのジェネリクスについて学んだので備忘も兼ねて紹介できればと思います。
弊社では週に一度のペースでフロントエンドに関わる人が集まって勉強会のようなことを行なっています。そこでTypeScriptのジェネリクスの話題となったのですが、私自身よく分かっていないなと思ったので調べてみました。

はじめに

ジェネリクスはTypeScriptだけに限った機能ではありません。あらかじめ特定の型に定義せず、曖昧な状態のままで定義することができます。
そして利用時点で型指定を行い、特定の型に確定します。このように利用されるまでは型定義が曖昧で様々な型で利用されることから「総称型」とも呼ばれます。

ジェネリクスは利用法が色々あるみたいなので、学んでいきたいと思います。

メソッドでの利用

以下のコードは取得したデータをjson形式に変換してから返却するfetchAPIのラップ関数です。
getUserはfetcherを利用して取得したユーザー情報を利用元に返却します。

 

上記のコードだと返却値の型はPromise<any>という型になりTypeScriptの型チェックの恩恵を受けられません。

ここで、使用するのがジェネリクスです。

 

ジェネリクスを使用することでany型を返却しなくても良くなりました。
さらに、ジェネリクスを用いることでgetUserだけに依存することなく、その他のデータ取得関数からも利用可能な汎用的なfetchAPIのラップ関数として定義することができます。

上記の例は戻り値だけでしたが、引数にもジェネリクスを使用することができます。

複数の引数を持つ関数での利用

複数の引数を持つ関数に個別のジェネクスを定義することもできます。

インターフェースでの利用

インターフェースにもジェネリクスを利用できます。

インターフェースを継承したジェネリクスでの利用

ジェネリクスはどの型も使用することができますが、内部のプロパティまで理解してくれるわけではありません。例えば、以下のコードのようにarglengthを使いたいとした場合エラーとなります。

 

なぜなら、全ての型に特定のプロパティが存在するとは限らないためです。これを解決するためにTypeScript側に特定のプロパティが存在することを確定させる制約をかけることができます。

 

上記のように記述することでインターフェースのプロパティを持っているジェネリクスを定義することができます。ちなみに、インターフェースを継承しただけなので length というプロパティを持っていれば他のプロパティも渡すことができます。

まとめ

ジェネリクスを学んでみて以下のような場面で有効に使えるなと思いました。

  • コンパイル時型チェックの恩恵を捨てるようなコード(any型、あるいは型キャストの使用)
  • 型だけ違う実装の大量生産(再利用したい時)

ジェネリクスをこれから学ぼうとしている方に少しでも参考になれば幸いです。

最後に

アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています!ご興味がありましたらお気軽にご応募いただければと思います!

アソビュー株式会社の募集 採用・求人情報 - Wantedly

アソビュー株式会社の新卒・中途・インターンの募集が45件あります。気軽に面談して話を聞いてみよう。職種や採用形態からあなたにあった募集を見つけることができます。募集では「どんなことをやるのか」はもちろん、「なぜやるのか」「どうやるのか」や実…

www.wantedly.com

 
 

10年間のSEOの経験から考えるスペシャリストのキャリア

f:id:m_nishimoto:20220331184140j:plain

アソビュー! Advent Calendar 2021の17日目の記事です。

「週末、なにする?そんな時は、アソビュー!」でお馴染みの遊び予約サイト「アソビュー!」のSEOを担当している西本です。

アソビューは今年で創業10周年を迎え、現在お得なキャンペーンを開催しています。下記ページからご確認頂き、お得にお出かけを楽しんで頂けたらと思います。

www.asoview.com

実は偶然にも今年は僕がSEOに本格的に関わりだしてから10年の年でもあります。そこで今回はこの10年を振返って自分がどのような経験を積み、どう成長してきたのかをまとめたいと思います。SEO業界で無名な僕の自分語りに誰が興味があるのだろう、とは思いつつも、年末でもあるのでキャリアを考える誰かの参考になれば幸いです。

■はじめに

僕のキャリアに対する考え方は、尊敬するインサイトフォース山口さんの書籍「マーケティングの仕事と年収のリアル」を参考にしています。こちらの書籍はマーケターのキャリアについて書かれたものですが、ITエンジニアのキャリアを考える際にも参考になると思うのでお勧めです。詳しくはこちらの記事を参照ください

書籍の中で特定領域のスペシャリストに達した人のキャリアには次の3つの選択肢があると示されています。
・より高レベルのスペシャリストになる
・複数領域のスペシャリストになる
・マネジメントにキャリアをシフトする

ちなみに僕はマネジメントの適性が全く無いことを自覚しているので、スペシャリストとして生きて行こうと考えています。また、1つの領域を100点目指して深堀していくよりも、80点の強みを複数掛合せる方が性にあっているため、そのようなキャリアを志向しています。

この10年間一貫してSEOを自分の仕事にしてきましたが、適度に環境を変えることで、特異な強みが身についているのでは、と考えています。

■ITエンジニア→システムに強いSEOコンサル

元々僕は学生時代からプログラミングをしており、その流れで最初のキャリアはITエンジニアになりました。その後約10年ITエンジニアを経験しましたが、2社目の会社でどうやっても勝てる気がしない凄腕エンジニアの方々に圧倒され技術力で生きていくのを諦め、マネジメント側に方向転換したものの担当したプロジェクトを炎上させたりでうまくいかず、ITエンジニアとしての限界を感じていました。

そんな時に偶然SEOを知り、自分の仕事の成果が明確に数字として現れることに面白味を感じ、「なにこれ、スゲー面白い!」とのめり込んでいきました。ITエンジニアとしてのキャリアに頭打ちを感じていたこともあり、本格的にSEOを学ぶために転職しました。

転職したのはコンサルをメインにするSEO会社でした。ここで偉大な諸先輩方にSEOのイロハを教えて頂きました。元ITエンジニアでシステム開発の知見があるため、大規模サイトのSEO案件を多く担当させて頂きました。現在の僕の得意分野である、大規模サイトのテクニカルSEOのベースはここで作られました。

■システムに強いSEOコンサル→システムに強いインハウスSEO

SEOコンサルの仕事はとても楽しく業務は多忙だったものの充実していました。ただ、コンサルあるあるですが、自分が提案した施策を自分で推進してみたくなり、元々事業会社での仕事に興味があったこともあり、インハウスの立場でSEOを担当出来る事業会社に転職しました。

転職したのは大手人材系の事業会社でしたが、転職して3年ぐらいは辛い日々が続きました。コンサル→インハウスの転職で在りがちな悩みですが、大企業の事業会社でどうすれば組織を動かし自分の施策が推進出来るかが分からず苦しみました。また、それまでビジネススキルを意識したことが無く鍛えていなかったため、優秀な先輩方の仕事に全く付いていけませんでした。

ただ、システム開発の知見があるため、エンジニアの方とは会話がしやすかったように思います。起案した施策の実装が難しい場合は開発工数が抑えられるように要件を調整したりなど、施策が実現しやすいよう考慮していました。ここでも元ITエンジニアの経験が活きました。

■システムに強いインハウスSEO→データとシステムに強いインハウスSEO

3年ぐらい経ちようやく事業会社での仕事の進め方が多少理解でき、表彰されるぐらいの成果も出せるようになりました。

その頃所属していたSEOチーム内にデータサイエンティストの方がいて、一緒に仕事をする機会がありました。その方からBigQueryとRedashの存在を教えてもらい衝撃を受けました。これを使えば、それまでExcelで管理をして更新に毎回時間がかかっていたモニタリングを、全て自動化し数値もグラフで可視化出来ると思い付きました。それからプライベートの時間を全て使いGCPでのデータ分析基盤の構築を学んでいきました。「なにこれ、スゲー面白い!」とデータエンジニアリングにのめり込んでいきました。

それから2年ほど経ち、自分が目指していたモニタリングの仕組みがある程度形になってきました。大手事業会社での仕事も5年が経ち、次はスタートアップで仕事がしてみたいと現職であるアソビューに転職しました。

■データとシステムに強いインハウスSEO→???

アソビューでインハウスSEO担当として仕事をする今の僕には以下3点の強みがあります。
・戦略策定、分析、課題特定、実装、効果検証までの一連のSEO業務遂行
・要件定義、設計、実装、テスト、運用までの一連のシステム開発経験
・データ分析基盤(GCP)×モニタリングダッシュボード(Redash)の構築

SEOという柱となる明確な強みがあり、それを補強する形でシステム開発とデータ分析のスキルが掛け合わされ、それなりの希少性が作れているのでは、と思います。前述した通り、僕は複数の専門領域を掛合せるキャリアを志向しているため、これからも未経験の領域に手を出し、その中から「なにこれ、スゲー面白い!」と思える何かを見つけのめり込み、また新たな自分の強みとして加えていければと考えています。

■さいごに

「生きるに、遊びを。」をミッションに掲げる我らがアソビューでは一緒に事業をつくる仲間を絶賛募集中です。

www.wantedly.com

とにかくエンジニアのリソースが足りずとても困っています。助けてください。

スパゲッティ化して改修困難になったプロダクトをフルスクラッチでリニューアルした話


これはアソビュー Advent Calendar 2021の16日目の記事です。

アソビューCPOの横峯です。

弊社アソビューではアソビュー!そとあそびアソビュー!ギフトというC向けのサービスの他にB向けのサービスもいくつか展開しております。

その一つラフティングやダイビング、陶芸教室などの体験アクティビティと呼ばれる事業者様に使って頂いてるウラカタというプロダクトがあります。

既存のコードをすべて捨てて今年の11月にリニューアルした話です。

📕歴史と経緯

初期のウラカタは株式会社そとあそびで僕が一人で開発してたプロダクトでした。2014年から開始して2年ほど僕以外コミットしてる人がいません。マンションベンチャーで新規プロジェクトだったので最初はもちろんPMFできるかわからない状態です。

という言い訳を元にとてもコードの品質が高いものとは言えない状態でした。とにかく使っていただきたい、使えるものを出したいという思いのもと短期的なスピードを圧倒的に優先し開発していたためテストコードも少なくレビュー体制もありませんでした(一人なのでそりゃそうなのですが...)

その状態で進めていたおかげか多くの方に使っていただけるサービスに成長していき、2016年に会社が株式会社アカツキとMAをすることになりました。※当時の記事プレス

このあと一気に事業を成長させるべく、開発にも大幅に投資します。

多くのエンジニアの方に参画頂いたのですが、コードは読みづらく機能も複雑だったため、改修の難易度がどんどんあがっていきます。

徐々に細かいバグが増え、そのバグを修正してもどこか違う箇所でバグが起きるような状態。この頃には様々なアクティビティ業界の方と話をできる状態になっていたので、市場のニーズは多く理解できてきているが、運用のためのタスクが積み上がってるため、描いたようなプロダクトの成長ができない状態になっていました

開発してる側もつらく、その原因を作った自覚のある僕もつらい状態が続きましたが、それでもその後2年ほど改善を続けプロダクトは成長していきました。が、今度は事業観点で縮小が決定。開発も最小限にしてしばらくバグの改修のみを細く続ける状態でした。

🔨作り直し決定

2018年頃、僕が事業責任者をやることになったタイミングでプロダクトのロードマップを描きなおし、前回の反省を踏まえた上で0から作り直すことを決定しました。

同時にビジネスモデルも変更し、継続的に成長しながらプロダクトをあるべき姿に変えていく構想をスタートしました。

といっても開発体制はほぼなかったので、まずはその構築から。

以前関わってくれていた方を中心にチームを再結成し、前回の反省を踏まえ品質にはこだわりをもってやろうと再スタート。

まず機能の整理からはじめました。

ユーザーストーリーマッピングを全員必読にし、実際に全員ですり合わせました。※これを実施したのはコロナ前なのでリアルボード

現行バージョンは細かい機能がかなり多かったため、すべての機能の使用率を調査し、ミニマムのスコープを定義しました。

今回のリニューアルは今後の中長期的な成長を支える基盤になるもののため品質をとにかく優先しよう。その認識をチームで共通のものにするためインセプションデッキを行い明文化しました。

期日、機能より品質、セキュリティが大事であることを明確に定義。

これがあったことで、そのあと議論になったときに立ち返る場所になったと思います。ユーザーストーリーマッピングもインセプションデッキもよく使われてるツールだと思いますが、改めてその価値を実感しました。

実際、開発を開始してからしばらくするとコロナが本格化して事業としては大打撃を受けたり、会社もMAを実施することになり親会社が変わったりと環境は目まぐるしく変わっていましたが、ウラカタの開発だけはスタンスを変更せず最初に誓った志を保って開発を続けていました。

その結果開発を開始してから2年以上たつ今でも細かいバグもほとんどなく、新しい価値を提供するために多くのリソースを避けていると思いますし、以前のように既存のコードを読み続けてよくわからなくなってるところをドキドキしながら改修するようなことはなく、開発に関わってくれる方のストレスも少ない状態が保てているのではと思ってます。そのため結果的には今後の事業成長のスピードを最大化できる状態が作れていると思っています。

🌈今後

ウラカタは体験アクティビティ事業者の方々の業務を効率化し、集客に貢献できるプロダクトだと思っています。

僕自身、この業界に関わりはじめて知りましたが、体験アクティビティ事業者の方々はほんとにたくさんの業務を少人数でやられています。

朝、新しい予約の確認をして予約申し込み頂いてる方とメールでやりとりをしたあと、ツアーのための準備、実際にツアーを催行してお客様を見送ったあと、翌日の準備、その間も予約申込は続くためその対応を一件一件行っていく。繁忙期は早朝から深夜までは当たり前。多くの事業者様がこれを毎日行っていることを知りました。

ほんとはやりたいけど、できてないこともたくさんあると聞きます。少しでも業務を効率化し、予約を増やすことができれば、お客様との時間や、ツアー自体をどう良くしていくかに時間を使っていただけるのではないか。そんな思いを持って日々開発を続けています。

弊社はミッションとして「生きるに、遊びを。」を掲げています。身をおいてるからこそ、日々遊びが進化し多様化してることを実感をもって感じています。どれだけ多様化してもそれぞれの良さや楽しさがあります。その中で選択され続けるためにも業界全体がサステナブルでより良い状態へ向かっていけるようにしていく必要があると思っています。

僕自身、たくさんの体験アクティビティ事業者の方々とお会いしましたが、みなさん強い思いを持たれていたり、そのアクティビティが大好きだったり目を輝かせて自身の仕事や体験について語ってくれることがとても印象的です。

僕個人のミッションとして「楽しく生きる人を増やす」を掲げています。今ウラカタを通してたくさんの事業者の方々をサポートすることはまさに楽しく仕事する方を増やすことに直結してると感じてますし、多くの方の楽しい体験の時間を下支えしている実感があります。

この波はまだまだ大きくできるし、もっともっと大きくなって世の中の楽しい時間が増えればいいなと思ってます!


そんなミッションに興味もってくれた方も、遊びのSaaSに興味もってくれた方も全方位で仲間を大募集しております!楽しく質にこだわりをもって一緒に開発しましょう!

 

PostgreSQLのスロークエリログを出してみた話

f:id:h_miz3754:20220406182532j:plain

これはアソビュー !Advent Calendar 2021の15日目の記事です🎄

こんにちは、アソビュー!SREチームの三森です。
寒い日が続きますが、皆さんいかがお過ごしでしょうか?

先月受診した健康診断で肥満気味だと発覚したため、食生活の改善を行なっています。3食バランスのとれた食事と適度な運動を実践するのは、なかなか容易ではありません。とりあえず、間食を食べることからやめてみようと思います。

 

Aurora PostgreSQLではデフォルトでクエリの失敗、ログインエラー、致命的なサーバーエラー、デッドロックが出力されています。

今回はAurora PostgreSQLでスロークエリを出力する設定について話します。

内容

Aurora PostgreSQLのパラメータグループで特定のパラメータを変更します。なお、パラメータグループはDBクラスターパラメータグループとDBパラメータグループの2種類がありますが、今回はDBクラスターパラメータグループに変更を加えています。

DBクラスターパラメータとDBパラメータについては以下を引用させてもらいます。

 

DB パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。(略)

DB クラスターパラメータグループは、Aurora DB クラスター内のすべての DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。

 

docs.aws.amazon.com

スロークエリログを出力するためのパラメータは下記です。

なお、下記は全て動的パラメータなので変更後のクラスター再起動は発生しません。

 

log_min_duration_statement=1000(ms)

スロークエリとみなす閾値。0に設定すれば、すべてのクエリの実行時間と実行されたクエリが出力され、 -1(デフォルト)は、実行時間の記録を無効にします。例えば、1000msに設定すると、実行に1000msもしくはそれ以上かかったクエリをログに出力します。

上記のパラメータの設定により、閾値を超えたクエリがログが出力されるようになるので、基本的な運用は問題ないと思います。

もしくは下記2つの設定を変更することで、同様の状態にすることができます。

 

log_statement

どの種類(データ定義文、データ変更文など)のSQL文をログに吐き出すかを設定します。有効な値は、none、ddl、mod、およびallです。デフォルトはnoneです。

 

log_duration

これをonにすることで、実行された全てのSQLの経過時間を出力します。 デフォルトはoffです。

 

さらにエラーログを充実させたい場合は、下記のパラメータを設定することもオススメです。

 

log_error_verbosity=verbose

ログ取得されるそれぞれのメッセージに対し、サーバログに書き込まれる詳細の量を制御します。有効な値は、TERSE、DEFAULT、およびVERBOSEで、それぞれ表示するメッセージのフィールドが追加されていきます。

また、log_destinationをcsvlogとしている且つ、このパラメータをverboseの場合はログにPostgreSQLソースコード上のエラー発生場所が記録されます。

 

log_min_error_statement=error

単純な構文エラーをログに出力させます。

より詳細な情報については下記が参考になるかと思います。

www.postgresql.jp

まとめ

これでスロークエリログは出るようになります。調査などにお役になれば嬉しいです。

 

さいごに

アソビュー!では一緒に働くメンバーを募集しています。
興味がありましたら、まずはざっくばらんにお話しだけでも聞きに来て頂けたら嬉しいです。ご応募をお待ちしております。

www.wantedly.com

 

負荷テストを進めるためのワタシ的重要なポイント

 

こちらは、アソビュー! Advent Calendar 2021の14日目の記事です。

お久しぶりです、アソビュー!でエンジニアをしている山内です。
皆様、12月いかがお過ごしでしょうか?
最近はグッと冷え込むようになったので、鍋をよく食べています。マイブームは、牡蠣チゲ鍋です。🤤

さて、今回は社内のアプリケーションの負荷テストを行う際に、Gatlingというツールを用いて行いました。
その際に、ポイントとなる観点や、学びがありましたので紹介できればと思います。

Gatlingとは?

Gatlingとは、JVM上で起動するオープンソースの負荷テストツールです。
テストのシナリオケースを作る際に、GUI上で作成できたり、テスト後のレポートを自動的にhtmlで出力してくれるといった特徴があります。

また、Scalaベースで書かれているため、独自にテストシナリオケースを記述することができます。

負荷テストの進め方とポイント

実際に負荷テストを行う際のポイントとなる部分を、負荷テストの進め方を通して紹介していきます。

1.目標値を設定
2.テストシナリオを作成
3.テストを実行

1. 目標値を設定

まずは目標値を設定します。今回の負荷テストの目的は何なのか、何を持って判定基準にするのかを明確にします。

一般的に、負荷テストを行うの目的は「想定されるユーザー分のアクセスに耐えうることの確認」になるかと思います。
想定されるユーザー分の負荷テストをして、システムが稼働し続けていれば問題はないはずですが、本当にそれだけで大丈夫でしょうか?

もしも、想定の2倍のアクセスが来たらどうなるのだろうか…
もしも、1分間だけ想定の3倍のアクセスが来たときには耐えられるのだろうか…

想定されるアクセスに耐えることを検証していても、実際のシステムの限界点を様々な視点から定量的に分析できていなければ、意味のないテストになっている可能性があります。

そのため、負荷テストの目標は、想定されるアクセスに耐えうることはもちろん、現在のシステムの危険領域・限界値の数値化をすることが重要になっていきます。

2. テストシナリオを作成

続いて、テストシナリオの作成を行います。

テストシナリオの作成方法は、実際のユーザーの行動に近いシナリオを作成していきます。

例えばアソビュー!であれば、TOPページを閲覧しているユーザー、検索をしているユーザー、予約をしているユーザー等々が想定できます。
それらのユーザー行動を列挙し、システム内の機能を網羅するように整理していきます。

ここでのポイントは実際のユーザーに近いシナリオの作成をすることです。

3. テスト実行

実際にシナリオからテストを作って、実行します。

私は、実行結果をスプレッドシートで管理しました。
シナリオごとの実行日時と、インフラ情報、実行の結果をまとめていきます。

※ 数値は仮に当てています

このように実行の結果をすべて残すことで、前後の比較や限界値の可視化と、ログを見ることができます。

実行したあとに、分析 → 原因調査 → 修正 → 再度テスト実行を繰り返し行います。その際にも、すべてのログが1つの場所に正確に残っていることで、比較検討が容易になります。
実行時間も正確に残すことでアプリケーションログもわかりやすくなります。

テスト実行後のログの整理・管理も大事なポイントです。

おわりに

今回は、Gatlingで行った負荷テストを行う上でワタシ的に重要であった部分の紹介を行いました。

・ 目標は、現在のシステムの危険領域・限界値の数値化を定める。
・ シナリオは、実際のユーザーに近いシナリオの作成する。
・ テスト後のログの整理・管理を正確に残す。

負荷テストの手法によって重要になってくる点は異なるかと思いますが、今回のようなシステムの限界値等を明確にする耐久テストでは全て重要になってくるポイントだと思います。
これから負荷テストを行う方の参考になれば幸いです。

最後に

アソビューでは、エンジニアを大募集しております!
やりがいしか無いサービスの開発の興味がある方いればぜひ一度ご応募ください!

www.wantedly.com

タスク依頼時に「Background(背景・経緯)」を伝えるとチームの生産性が上がった話


アソビュー Advent Calendar 2021の13日目です🎄

こんにちは。アソビューでバックエンドエンジニア兼スクラムマスターをしている頭島です。

今回はタスク依頼時に「Background(背景・経緯)」を伝えると、チームの生産性が上がった話をしたいと思います。


課題

今年の7月に所属チームが変更になり、新チームのスクラムマスターをすることになりました。チーム立ち上げ時に下記の課題がありました。

  • 依頼した設計タスクのアウトプットが想定とずれてしまう
  • タスクに関する指摘や改善案が少ない

伝えたつもりが伝わっていない場面が多く、伝達情報の不足を感じていました。

タスク依頼する時に何を伝える?

最低限下記が伝われば問題ないと思っています!

  • Why:なぜやるか
  • What:なにをやるか
  • When:いつまでにやるか
  • How:どうやってやるか ※必要に応じて

実施したこと

上記に加えて、「Background(背景・経緯)」を追加して運用してみました。BackgroundはWhyが持つ要素の1つですが、あえて分けることで意識しました。

誰が、どのようなシチュエーションや目的で利用するか、どのようなことに困っているか

上記のようにタスク化に至った背景などをBackgroundとして必ず伝えるようにしました。特に小さいタスクになればなるほど忘れがちです😲

タスクフォーマットは下記で進めてました。


結果

ハイコンテクストなコミュニケーションができるようになりました 😃

例えば画面項目を検討する場合、Background(背景・経緯)をもとに設計や議論するため、表示すべき項目の解像度が上がりますね。また想定していた仕様に加えて、よりよいエクスペリエンスを提供できるような提案が出るようになりました。Background(背景・経緯)を共通認識にできたためだと考えます。

結果として、認識齟齬が減ってアウトプットの品質が向上し、生産性が向上しました!


まとめ

タスク内容にBackground(背景・経緯)を追加することは大した作業ではないですが、想像以上に効果がありました!

リモートワークが浸透してテキストコミュニケーションが大部分を占めるようになりました。この環境下におけるハイコンテクストは誤解や認識齟齬の原因になります。一方ですべてローコンテクストにするとコミュニケーションコストが上がります。

使い所が肝心で、チーム内・プロジェクト内におけるハイコンテクストは、仕事を進める上で重要だと再認識しました。今後チーム立ち上げや、オンボーディングの際に活かしていきたいです。


さいごに

「生きるに、遊びを。」をミッションに掲げる我らがアソビューではアソビューではエンジニアを募集しています。
ご興味ある方はぜひ応募ください!