「goo」の広報ブログ「gooの音」

「goo」広報担当が、みなさんにとっておき情報をお伝えしていきます!

【エンジニアに訊く】Alexaスキルの審査を通すために抑えておくべきポイントは?社内勉強会「アサレン」でAlexaスキルを開発したエンジニアに訊いてみた。

2018-08-31 | ★もっと知りたい!NTTレゾナント

NTTレゾナントでは、社内のスペシャリストが講師となり、業務に必要なスキルを習得する場として勉強会を実施しています。その1つが「アサレン」です。「アサレン」は、朝の時間を活用し、UI/UX、 プログラミング等といった、技術力の向上を目的に開催している勉強会です。

今回は、「アサレン」で講師を務めた伊東さん、アサレンに参加した若手エンジニア久澤さん、岩田さんにインタビュー。3名とも今回の「アサレン」で、Alexaスキルを1ヶ月ほどで開発し、リリースしたとのこと。開発で苦労したポイントや、審査を通すために抑えておくべきポイントなどを訊きました。

※今回の記事はスマートスピーカーのスキル開発(主にAlexaスキル)を検討されている方向けのものです。

左)メディア事業部 ポータルサービス部門 技術開発チーム 岩田 紘成
2018年、NTTコミュニケーションズへ入社、同年にNTTレゾナントに配属。「gooニュースアプリ」のバックエンドの開発業務などに従事。

中央)スマートナビゲーション事業部 サービステクノロジー部門 AIチーム 伊東 久
2008年、NTTレゾナントに入社。「goo AI x DESIGN(エーアイクロスデザイン)」や「教えて!gooのAIオシエル」など、NTTレゾナントの主要なAI案件に従事。

右)ソリューション事業部 サービス基盤部門 課金/IDチーム 久澤 大輝
2016年、NTTコミュニケーションズへ入社、同年にNTTレゾナントに配属。「goo」のID・決済基盤の運用に加え、社内インフラ整備などの情報システム業務や、スマートフォンアプリの管理業務などに従事。

 

 

個人の作り手は「コンテンツ持っていない問題」にぶち当たる

 

――今回はAlexaスキルについてお話をお聞きします。皆さんは今回のアサレンで初めてAlexaスキルを開発したそうですが、どのようなスキルを開発したのでしょうか?

伊東
私は「アニメトークイベントお知らせ」というスキルを作りました。このスキルは都内で開催されているアニメ制作陣によるトークライブイベントのスケジュールをお知らせしてくれるスキルです。

久澤
私が作ったのは、食品名を言うとその食品の100グラムあたりの糖質とカロリーの量を教えてくれる「糖質チェッカー」というスキルです。文部科学省の『日本食品標準成分表2015年版(七訂)』のオープンデータをコンテンツとして利用しています。

岩田
私は「川崎のゴミ係」というスキルを作りました。捨てたいゴミを発話すると、そのゴミの川崎市での分別方法を教えてくれるものです。


――皆さん、ご自分でスキルを企画されたとのことですが、スキル設計で悩まれたところってありますか?

伊東
スキルを作るにあたって、どういったものにしようかいろいろと考えましたが、個人として発信するためのコンテンツを持っていないことが大きな課題でしたね。Alexaスキルでよく使われているのって、フラッシュブリーフィングスキルといわれているもので、これはニュースやメディアの情報を音声で聞けるスキル。簡単に言うと「アレクサ、今日のニュースを教えて」といったら、Alexaがニュースを読み上げてくれるものです。

このフラッシュブリーフィングスキルを作るには、まず自分が発信するためのコンテンツを用意しないといけません。みんなが知りたいと思う有用なコンテンツを持っていないとこういったものができないのです。「伊東久の今日のニュース」を流してもしょうがないので(笑)

なので、コンテンツを持っていない個人がAlexaスキルを作ろうと思ったときには、「コンテンツに頼らないもの」「オープンデータを活用してコンテンツとするもの」「なにかしらの手法で情報をキュレーションする」のどれかになるかと思います。私が開発した「アニメトークイベントお知らせ」は、3つ目ですね。Web上にあるイベントのタイムテーブルのデータを取得してきて、いつどこでアニメイベントが開催されているのかを教えてくれるようにしました。

岩田
私も、コンテンツ持っていない問題に悩まされましたね。どうしようかと考えた結果、オープンデータを活用することにしました。神奈川県川崎市に住んでいるのですが、ゴミの分別方法がオープンデータとして公開されていて、それを利用しました。なぜ川崎市なのかというと、社会人一年目で川崎市に引っ越してきたばかりなのですが、ゴミの分別方法がよくわからなくなるからです(笑)。

 他の市町村で、すでにゴミ分別に関するスキルがあったけど、川崎市にはまだない!!
これは俺が作るしかねぇ!!と決めたとのこと。

 


Node.jsは非同期処理が辛い


――開発で苦労したことは?

久澤
Alexaスキルの多くがNode.jsかPython作られています。私は以前Pythonを使ったことがあったので、未経験だったNode.jsを選びました。初めて触る言語だったのですが、私が開発した「糖質チェッカー」ではスクレイピングはしないし、JavaScriptの経験はあったので、簡単だと思っていたのですが、実際は非同期処理という沼にハマりましたね。

伊東
私も、Node.jsを最初に選んだのですが、非同期処理で挫折しましたね(笑)。PythonはABCという処理を記述するとA、B、Cと順番通りに処理をするのですが、Node.jsはWebサーバーなどのサーバーサイドで動作させることを想定したJavaScript環境なので時間のかかる処理は処理が終わって値を返すことができる状態になったら返す(処理が速いものはすぐに返す)という動作になります。
例えば、ABCと記述しても、Bの処理が遅いと、A、C、Bとなり、Bの値が最後に返却されます。この非同期処理に慣れていない、私のようなプログラマーからすれば、かなりやっかいなんですよ。「Node.jsいけるっしょ!」っていうテンションで挑んだのですが、文字列を正規化するための関数を1つ書いただけなのに、「あれ?順番違うじゃん!やってられん!」となりましたね。結局、私は途中まで書いたNode.jsを全部捨てて、Pythonで書き直しました(笑)。

  

Node.jsでコールバック地獄に飲みこまれ、Pythonで息を吹き返したとのこと。

 


発話されやすいコンテンツを用意しよう


――みなさん、無事にリリースまでたどり着いたとのことですが、審査ではどういうポイントが指摘されましたか?

岩田
私は審査に何度も落とされました(笑)。スキルのエラーというよりも、ユーザーとの会話インターフェイスの部分で指摘を受けましたね。いかにユーザーが直感的に操作できるかが、重要視されているような気がします。
当初、オープンデータのテキストをそのまま使っていたんですが、それを人が発話するような書き方に直しました。例えば、元データでは「アイスクリームのふた(プラスチック製)」や「アイスクリームのふた(紙製)」という感じで分類されているんです。
ユーザはそんな聞き方をしないので「アイスクリームのふた」でまとめる、といった作業をひたすらやりましたね。ある程度は機械的にできますが、最終的には手作業で修正していく感じでした。これはスマートスピーカーのスキル開発ならではの作業かなと思います。

久澤
私もこの作業に結構時間がかかりましたね。日本食品標準成分表に記載されている食品名が「(えんどう類) さやえんどう 若ざや 生」みたいな絶対に人が発話しないような書き方なんですよ。

 

エクセルでゴリゴリ成形して、食品名のクリーニングを行ったとのこと。

 

あと、Alexaのシミュレーターは、実機と異なることを意識しておいたほうがいいですね。私の場合、シミュレーターではタイピングで文字を入力するのですが、発話だと音声で文字が入力されます。
具体例をあげると、シミュレーターで「はんぺん」と打つとちゃんと認識してくれるのですが、実機で試してみると「半片」と漢字に変換されてデータベースに飛んでいくんです。データベースには漢字の「半片」が登録されていないので、Alexaが「見つかりませんでした」と返答してしまうようになってしまって・・・。ですので、実機でも動作を確認しつつ、ひらがな、カタカナ、漢字でも対応できるデータベースにしないといけないんです。

また、審査を受けるときには、サンプルフレーズというものを用意しなくちゃいけないのですが、ここで指摘される人は多いのではと思います。私の「糖質チェッカー」というスキルの場合、自分でタイピングして打つときはシミュレーター上でAlexaがすでに起動しているので、「糖質チェッカーで唐揚げを調べて」で動作するのですが、実機の場合は、「アレクサ、○○して」というふうに、”アレクサ”をきちんとつけないといけないんです。ですので、ちゃんと”アレクサ”というウェイクワードをサンプルフレーズに入れなさいという指導が入りました。


――なるほど、シミュレーターと実機では動作が異なる場合があるのですね。

久澤
他にも注意しておきたい点がありまして、それがサンプル発話の準備ですね。アレクサがユーザーの発話を正確に認識できるように学習するための辞書のようなものです。サンプル発話には、「〇〇の糖質を調べて」「〇〇の糖質を知りたい」「〇〇の糖質を教えて」などユーザーのさまざまな発話に対して対応できるように辞書を用意する必要がありまして、これの数が10個以下だとおそらく審査で指摘されますね。

岩田
私はまさに、それを審査で指摘されました。Amazonのウェブサイトにサンプルはあるものの、スキルによってユーザーの発話方法がそれぞれ異なるので、そのまま転用することはほとんどできません。初めて申請される方の多くがここで指摘をされるのではと思っています。

伊東
私の場合は、Alexaスキルの説明欄に書く文章について指摘を受けました。申請時にこのスキルはこういうことができるという説明を書いたドキュメントを提出するのですが、その体裁について指摘を受けています。Alexaの標準機能と誤解させてしまうので、これがスキルであることを明示的に書いてくださいという指摘を受けました。最終的には説明文に”Alexa”という表現をしていたところをすべて”スキル”に直しました。

 

 

Alexaスキルをリリースするなら今がチャンス


――Alexaスキルって今が審査に通りやすいとの噂を聞くのですが、実際に体験してみていかがでしょうか。

岩田
私は何度も審査されましたが、実際はそれほど厳しいものではないと思います。指摘ポイントはある程度限定されていて、スキルの実装で指摘をされることはないですし。また、
Alexaはスキル数の拡大に力を入れているときで、キャンペーンなども積極的に実施しているので、それもあって今はスキル審査が通りやすい時期なのかなと思います。

久澤
岩田さんと同じく、それほど厳しくはないという印象ですね。Amazonが求めるユーザーエクスペリエンスに関する資料や審査のチェック項目があるので、それをきちんと見ていれば、大丈夫だと思います。

今がチャンスというのは、審査のスピード感からも伝わってきますね。私の場合は、日曜日の夜に出して、月曜日の昼に返ってきたのでかなりスピーディーだと思います。営業日的には半日くらいですね。次の日の昼に指摘されたポイントを改善して出したら、その日の夕方に審査通りました。

伊東
スキル開発に関する情報もネット上では充実しつつありますね。AmazonのAlexaスキル開発トレーニング、Qiitaの記事か、GitHubのサンプルコードなどが参考になるので、それらの情報をみれば簡単なものであればすぐに作れると思います。逆に書籍はいろいろと見ましたが、参考になるものはなかった(アサレン開始時 2018年6月の段階)ので、情報収集は基本的にウェブサイトで良いと思いますね。

今後は、各社がスマートスピーカーにディスプレイを備えたものを市場に提供してきますので、機能もよりリッチなスキルが作れるんじゃないかと思います。そういった意味でも、スキル開発の可能性が広がっている段階なので、今スキル開発を経験しておくことをおすすめします。 


――ありがとうございました!

NTTレゾナントでは、「goo」を一緒に作るエンジニアを募集中です!採用ページでは、実際のエンジニア社員へのインタビューや社内カルチャーを紹介していますので、ご興味があればぜひご覧ください。


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

プロアクティブチャットサポートで攻めのCSを実現 UX向上にも繋げているgooのチャットサポートとは

2018-08-21 | ★もっと知りたい!NTTレゾナント

企業がサービス・製品を提供する上で、ユーザーの窓口として欠かすことができない職種、カスタマーサービス(以下、CS)。ポータルサイトとして、メール、ポイント、ブログ、Q&Aなどさまざまなサービスを展開するgooにとっては、とても重要な要素です。

CSでは、近年のコミュニケーションツールの発展に伴いユーザーとのやりとりも多様になっています。特に、リアルタイムでのチャットサポートでの相談件数はこの1年で大きく伸びました。その中でチャットサポートでの知見を築き、88%の応対満足度を得ることができたのが、gooのCSです。今回は、チャットサポートを問題解決だけではなく、UX向上にも繋げたCS担当の町田さんに話を伺いました。

 

メディア事業部 ポータルサービス部門 CSチーム 町田 孝一郎

平成29年にNTTレゾナントに入社。
メディア事業部ソーシャルサービス部門CS担当に配属となり、お客さまの満足度向上を目的としたサポート業務やソーシャルメディアの運営業務を担当。



チャットサポートには向き不向きがある

 

――今回は、gooのCSで取り入れているチャットサポートについてのお話を聞きたいと思います。電話にはない「気軽さ」、メールにはない「即時性」の両方を兼ね備えているというイメージなのですが、実際はいかがでしょうか?

町田:はい、そのメリットは確かにチャットサポート特有のものですね。ユーザーもそのメリットを感じているようで、チャットサポートを始めてからメールのお問合せ件数は30%ほど減りました。

やはり、チャットサポートのほうがユーザーの課題を速く解決できるので、チャットサポートを使ったことのあるユーザーはまたチャットサポートでの問い合わせをしてくれるというデータもあります。

 

――チャットサポートの効果が数字として出ているのですね。その一方で、チャットサポートで対応する場合、向き不向きはありますか?

町田:チャットサポートに向いているのは、How toの部分。例えば「gooブログの新規開設の方法がわからないから教えて」などの質問はチャットサポートが向いています。一方でチャットサポートに向いていないものもあります。たとえば、ユーザーと同じ環境で検証が必要になるもの。そういったものはどうしてもリアルタイムでの回答が難しいので、メールで対応をしています。このメリットデメリットを踏まえて、チャットサポートを提供しています。

 


問い合わせする前に、サービスの利用をあきらめて、
離脱していたユーザーユーザーを救う


――チャットサポートはどういったタイミングで使われているのでしょうか?

町田:gooのチャットサポートはプロアクティブなものです。ユーザーの各ページにおける滞在時間などを見て、どこかで手詰まりになっていると判断した場合に、ポップアップを出して、こちらからチャットサポートを促します。

 

――チャットサポートといえば、ウェブページの端に常設しているイメージなのですが、なぜプロアクティブな仕様にしたのでしょうか?

町田:常設のものだと、ウェブページのデザインによっては、邪魔になってしまうこともあると考えています。例えば、ヘビーユーザーやリテラシーの高いユーザーからすればチャットサポートは必要とされていません。常設のものだと、それらのユーザーのユーザー体験を阻害させてしまうことにも繋がるのです。

本当に必要としている人に対してのみ、チャットサポートを提供したいと思い、プロアクティブな仕様を採用しました。

 

――プロアクティブなチャットサポートを導入して、その効果はいかがしょうか?

町田:応対満足度の数字は上がっています。それ以外のところでいうと、今まで問い合わせしないで離脱していたユーザーの問題を解決できているという実感があります。

チャットサポートの後でアンケートをとっているのですが、「なぜチャットを利用したのか」の回答では、「チャットに関するポップアップが出てきたので、聞くつもりはなかったが聞いてみた」の声があります。

こういったユーザーは今まで問い合わせする前に、サービスの利用をあきらめて、離脱していたユーザーです。このようなユーザーをプロアクティブなチャットサポートを導入したことで救うことができるようになりました。

gooブログで出てくるポップアップ。チャットサポートのポップアップが文字だけだと、
無機質なものに見えてしまうので、gooユーザーから親しまれているメグたんのイラストも出すようにしたのとのこと。


――チャットサポートでユーザーの離脱を救う。デジタルマーケティングのような側面も持ち合わせていますね。 

町田:そういってもらえると嬉しいですね。CSってどうしてもユーザーの問い合わせを待っている受け身なものに見られがちですが、gooのCSは能動的に動くことをスタンスとしています。ユーザーの潜在的な悩みを引き出し、それを解決することで、サービスのユーザー体験を向上させていく、ユーザーの伴走者としてgooを100%楽しんでもらうことがCSとしての目標ですね。

 


問題解決までのプロセスはメールと大きく異なる


――次はチャットサポートの課題について聞いてみたいと思います。チャットサポートならではの難しさってありますか?

町田:やはりスピードを求められてしまうことですね。チャットだと、何も応答が無い状態で30秒ほど待たされるだけで、ユーザーが「待たされている感覚」になってしまいます。問題解決をいち早くしたいユーザーからすれば、この「待たされている感覚」が不満に直結します。

 

――では、ユーザーを待たせないように工夫していることって何かありますか?

町田:回答スピードを上げることにはどうしても限界があるので、ユーザーの「待たされている感覚」を無くすことに注力しています。例えば、こちらがタイピングしている間にはユーザーのチャット画面には「回答入力中」と出るようになっていたり、長文になる場合は文章を細かく区切って送るようにしています。こうすることで、全ての回答を返すまでのスピードは変わらないですが、「いま対応しています」ということをユーザーに知らせることができるようになり、ユーザーの「待たされている感覚」を無くすようにしています。

 

チャットサポート時は、窓口の対応者がどのようなアクションをしているのか把握できるようになっている

 

ここはメールとは大きく異なるポイントですね。限られた時間の中だと、応対満足度向上のためには、メールはやり取りの数を減らすことが基本ですが、チャットサポートはその逆。やり取りの数を増やすことが応対満足度向上に繋がりやすいのです。

また、チャットサポートはログが残るので、アンケートで不満があったに回答したチャット対応などは、CSチームで見返すようにしています。「文章をここで区切って送ったほうがよかったね」や「これはチャットだと対応が難しいので、メールでの対応に切り替えたほうがいいね」などを話し合っています。リアルタイムでのコミュニケーションを振り返ることができるのは大きなメリットだと思っています。

 

――チャットサポートのログを見返すこともあるのですね。 

町田:量としてはかなり見返していると思います。チャットサポートのログは、ユーザーがサイトのどの操作がわからなくなったのかを可視化するものです。ですので、サービス改善にも繋がる大きな資産だと考えています。

チャットサポートのログを活用して、サービスのFAQページや、ユーザーに配信するメールをサービス担当者と一緒に設計しています。そうすることで、ユーザーが問い合わせをしなくてもよい環境づくりも進めています。

私としては、チャットサポートなどの問い合わせ窓口は最終的に存在しない方がいいと思っています。ユーザーが問い合わせする必要のないUI/UXやFAQページをサービス内で実現できていれば問い合わせ自体が必要ないからです。ユーザーにとってはそれが一番幸せな状況だと思います。gooのCSとして、問い合わせ情報をもとにサービス開発にも携わっていくことで、問い合わせ0件の実現を目指しています。


――ありがとうございました。


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アプリ開発のプロ集団!10ヶ月で11本のアプリをリリースしたNTTレゾナントのアジャイルデザインチームの開発手法に迫る

2018-08-09 | ★もっと知りたい!NTTレゾナント

アジャイル開発に積極的に取り組み、10ヶ月という期間で11本のアプリを内製で開発したチームがNTTレゾナントにはあります。彼らは開発スピードを上げるために、どのような開発プロセスを進めているのでしょうか。今回はアジャイル開発チームのデザイナー呉さんにインタビューを行い、その開発プロセスに迫りました。

 

 スマートナビゲーション事業部
サービスデザイン部門 アジャイルデザインチーム
呉 宗翰 (ご ぞんはん)

2017年にNTTレゾナントに入社。アプリ開発をスピーディに行うアジャイルデザインチームでデザイナーを務める。人間中心設計の資格を持ち、UIデザインだけでなく、ユーザー調査を通じたUXデザインも担当している。

 

新規アプリを立て続けに開発するにはアジャイル開発がベストだった。

 

――呉さんのチームでは、アジャイル開発を取り入れているとのことですが、そもそもなぜアジャイル開発を採用しているのでしょうか?

呉:既存の開発手法であるウォーターフォール開発では、あらかじめ全体の機能設計を定義して、機能を実装します。仕様が決まっている分、進捗を管理しやすい利点があります。ただ、新しいアプリを開発するときは、開発段階の途中で仕様の変更や、コンセプトの再設計をするというのはよくある話です。リリースの日付が決まっている以上、スピーディかつ柔軟に対応する必要があるのですが、ウォーターフォール開発は手戻りすることを想定していない手法ですので、スケジュール通り進めることが難しくなります。

私達のチームのミッションはアプリを出し続けることで、市場のニーズを探り、市場に価値あるアプリを創出することです。ユーザーの反応を見てグロースできそうであれば、gooのサービスとしてリデザインして、将来的にはgooの接点を拡大していこうと考えています。そのためには、新規アプリを立て続けにリリースしていく必要があります。それを実現するために、既存のウォーターフォール開発ではなく、仕様変更に対してもスピーディかつ柔軟に対応できるアジャイル開発を採用しました。

 

――具体的にどういうプロセスでアジャイル開発を進めたのでしょうか?

呉:私達が採用しているのはアジャイル開発の中でも最もメジャーなスクラムという手法です。スクラムでは、長期間の緻密な計画を立て開発していく従来の手法に対して、短期間の開発サイクルを反復していきます。この1回のサイクルをスプリントと呼んでいて、私達のチームでは1回のスプリントの期間は1週間もしくは2週間と決めています。1つのアプリをリリースするまでに6回のスプリントを繰り返しています。

前半のスプリントでは、ユーザー調査やアプリのコンセプトの設計、モックアップの作成。後半でアプリの実装やブラッシュアップ、脆弱性の対策などを行います。スプリントごとにレビュー、振り返りを行い、状況によっては次回のスプリントでの開発内容を変更します。

 

――アジャイル開発ならではの苦労ってありますか?

呉:計画段階で厳密な仕様を決めていないため、開発の方向性が途中で変更することが多いことですね。

「結婚活動ノート」という婚活中やマッチングアプリを使っているユーザーが彼氏(彼女)候補とのやり取りを記録していくことができるアプリを7月にリリースしました。このアプリの主な機能は、婚活中に複数の候補者とデートしたときの印象やエピソードを記録していくことで、相性を視覚的に表示してくれることです。

実は、この機能は当初から考えていたわけではありません。実際にユーザーインタビューやコンセプトの見直しを並行して行ったのですが、1回目のスプリントでのUIと最後のアプリのUIでは大きく異なります。アジャイル開発では、良くしようと改善を繰り返し、仕様を追加していくことで、当初の計画からずれてしまうことがあるのです。

スプリント1回目のUI


リリース時のUI

 

当初は複数の候補者を比較する機能が特徴だったが、ユーザーインタビューの結果、比較することで候補者の悪いところに目がいきがちになることがわかり、機能を変更した。

 

――仕様が変わっていく中で、プロダクトのコンセプトやタスクに対する認識を合わせていくことが難しそうですが、何か工夫されていることはありますか?

呉:各スプリントの開始前に、そのスプリントではどういうタスクを処理すべきか、チーム共通のダンボールのボードに付箋を貼りながら決めています。そうすることで、お互いコミュニケーションを取りながらタスクを決められるので、「なぜこのタスクをするのか」がチームの共通認識になるのです。 

また、部屋の片隅にダンボールのボードをいつも置いているので、どういうタスクがあるのかもすぐ目に入ります。デジタルなタスク管理ツールもいろいろと試してみましたが、このダンボールのボードが私達には一番あっていますね。  

 

青線でタスクの優先度を区切りスプリントごとのアクションを決めている。

 

――アジャイル開発によって、短期間でのアプリリリースを続けられていますが、今、振り返ってみて、いかがでしょうか?

呉:アジャイル開発の書籍や、そのノウハウが書いてあるWeb記事などをいろいろと読んできたのですが、それがそのまま今の私達のかたちになっているわけではないと思います。アプリのリリースを続けるなかで、とにかく動いてみるという姿勢で試行錯誤しながらチームの文化にあったアジャイル開発を見つけることができたのだと思います。アプリの作り手として、作ったアプリだけを見直すのではなく、その作る過程についても考察を続けることで、ユーザーに良いアプリを届けられるようになりたいですね。

 

――ありがとうございました。

 

呉さんがデザインを担当した「結婚活動ノート」はこちらよりDLできます。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【開発者必見】Remote TestKitのAppium自動テストクラウドがMagic Podと連携可能に!~テストシナリオ作成から自動テスト実施までをフルカバー~

2018-08-08 | ★もっと知りたい!NTTレゾナント

こんにちは!広報担当の佐藤です!

今日は、NTTレゾナントが運営するクラウド型検証サービス「Remote TestKit(リモートテストキット)」の新情報のお知らせです。

 

【Remote TestKitとは?】

「Remote TestKit」は、スマホアプリやスマホ用Webサイトをクラウド上でスマートフォン実機を使ってテストすることができるサービスです。利用者は実機を購入する必要がなく、クラウド上にある約500機種以上のスマホ・タブレットを使ったテストを実施することができます。また、Appium(アピウム)を使った自動テストクラウドや複数端末の同時操作など、開発者を支援するさまざまな機能があり、検証における負担を軽減します。

 

6月にリリースした新機能「Appium自動テストクラウド」が更に便利になり、Magic Pod(トライデント社)で作成したテストシナリオをそのまま利用できるようになりました

 

 

テスト自動化導入を検討する際、「自動テスト環境を構築するのが大変」「シナリオを作るのが難しい」などの課題が挙がることが多いかと思いますが、自動テスト環境構築不要のRemote TestKitとテストシナリオ作成をAIが補助してくれるMagic Podを使うことで、簡単に自動テストを導入することができます。

 

モバイルアプリやサイトのテスト自動化を検討されている方は、ぜひこの機会にお問い合せください!


お問い合わせはこちら→https://appkitbox.com/testkit/test-consulting/


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする