AWS Route53の加重ルーティング機能で本番インフラを無停止・段階的にECS環境に移行する

弥生 Advent Calendar 2021 6日目の記事です。

システム開発部Misocaチームエンジニアの mizukmb です。

クラウド請求書作成ソフトであるMisocaのインフラはサービス稼動開始からつい最近までAWS EC2を使ってアプリケーションを運用していましたが、この度Dockerコンテナ管理サービスであるECSに移行し、この移行作業がほぼ完了致しました 🎉

ECS移行に際しては長い時間をかけて準備や検証を行っており、開発者ブログで紹介したいネタがいくつかあるのですが、今回は実際にEC2で稼動するappサーバを無停止且つ段階的にECSに移行した方法について紹介したいと思います。

ECS移行前の状態と作業の概要

移行前のMisocaアプリケーションのインフラは複数台のEC2インスタンス上で稼動しており、各EC2インスタンスへのリクエスト振り分けはALBを使って制御していました。ドメインとALBの紐付けはRoute53のエイリアスレコードを利用しています。

移行後はEC2インスタンスが複数のECSタスクに、ALBもEC2用からECS用の新規ALBリソースに置き換わります。この移行作業の準備としてMisocaアプリケーションのコンテナ化やECSサービス・タスク定義の作成、ECS用のALBの用意を事前に行いました。

移行作業は以下の点を重視し、これらが実現できる方法について調べました。

• サービスの停止時間を作らずに移行作業ができる
• 一気にECS環境に切り替えるのではなく、カナリアリリースのように段階的にECS環境を本番に投入して負荷状況等を監視したい
• 段階的に投入する事でECSもしっかり本番環境でサービスが提供できているという安心感を得たい ¹
• 万が一ECS起因の障害が発生したとしても影響を最小限にしつつ素早くロールバックできるようにしたい

こちらについてAWS Japan ソリューションアーキテクトの方に技術相談をしたところ、Route53の加重ルーティング (Weighted routing) 機能について教えていただきました。 ²

Route53加重ルーティング機能について

正確な機能紹介についてはAWSドキュメントを読む事が最も良いので、ここではざっくりとした紹介をします。

Route53の加重ルーティング機能は、同一レコード名で登録し、重み (Weight) を各レコードで設定する事でその重みに応じた割合でリクエストを振り分けることができます。振り分け方法はラウンドロビン方式です。また、片方の重みを0にする事で設定したレコードへリクエストが振り分けられなくなり、もう片方のレコードに全てのリクエストが振り分けられるようになります。

例えば、 hoge.example.com への振り分けを EC2:ECS=30:70 としたい場合は以下のように重みを設定しそれぞれレコード登録します。

レコード名	ルーティングポリシー	重み	ルーティング先
hoge.example.com	加重	30	EC2用のALBドメイン
hoge.example.com	加重	70	ECS用のALBドメイン

この重みを変更する事でリクエストの振り分ける割合を柔軟に設定が可能になります。

無停止・段階的に移行するための作戦

行う事はシンプルで、加重ルーティングで設定する各レコードの重みを編集して少しずつ EC2:ECS=100:0 な状態から EC2:ECS=0:100 にすれば作業は完了します。

MisocaチームではインフラをTerraformで管理しているので、Route53レコードの設定や重みの変更はTerraformコードを修正し、プルリクエストの作成とコードレビューを経て terraform apply を実行し適用するという流れでした。

重みの変更によるアプリケーションの停止時間は発生しないので、この値が間違っていないか十分注意していれば簡単に無停止・段階的な移行が可能になります。

実際の移行作業ですが、最初は EC2:ECS=95:5 の割合から始めて、1〜2日様子を見てECS側の重みを増やして EC2:ECS=70:30 にする。さらに様子を見てECS側の重みを増やして…といった作業を繰り返していき、約1週間程かけて EC2:ECS=0:100 な状態に移行し、サービスの稼動に影響が無い事を確認できました。

おわりに

MisocaのアプリケーションインフラのEC2からECSへの移行にRoute53の加重ルーティング機能を活用した話を書きました。

ECS移行に関する知見についてはまだまだあるので、できる限り開発者ブログで紹介したいと考えています。

弥生 Advent Calendar 2021 では弥生のエンジニアが様々な内容で記事を公開しますのでぜひ他の記事もチェックしてみてください！

採用

積極採用活動中です!!

herp.careers

付録：最初に考えてた作戦内容と却下理由

ALBのリスナールールではリクエストを転送するターゲットグループの重み付けができるため、最初はALBのレイヤで無停止・段階的な移行を進めるつもりでいました。

しかしながら、ECS環境のデプロイはCodeDeployのBlue/Greenデプロイメント機能を使っている関係からこの案は技術的に不可能である事がわかりました。理由ですが、CodeDeploy Blue/Greenデプロイメント機能を実行するとCodeDeploy内部でリスナールールに紐付くターゲットグループをBlueからGreenに付け替えるといった事を行っており、実質リスナールールの転送先はECSに固定されてしまうためです。

CodeDeploy Blue/Greenデプロイメント機能を使わなければこの案で進められますが、これのためにBlue/Greenデプロイを止めるのは割に合わないと判断したため却下となりました。

---

1. もちろんステージング環境で検証していますが、やはり本番となると怖いものは怖いので安心感が欲しいのです↩

2. 弥生ではAWS Japan ソリューションアーキテクトの方と定例会を行っており、AWSに関する技術相談がカジュアルにできる場が設けられています↩

システム横断プロジェクトの品質計画

こんにちは、カトです。弥生でQAエンジニアをしています。この記事は弥生 Advent Calendar 2021の5日目エントリーです。

結論

弥生は、昨年2020年に記帳代行支援サービスを開始しました。
記帳代行支援サービスは、複数のシステム・複数のソフトウェアで構成されるサービスです。
弥生ではシステム横断プロジェクトと呼ぶことが多い、シームレスなサービスの裏側のおはなしです。

私は、QAエンジニアとして、記帳代行支援サービスに関わりました。 「かんたん、あんしん、たよれる。」の裏側では、複数のシステム・複数のソフトウェアから成り立つサービスの品質をどのように見ていくのか、何をやって何をやらないのかを決める必要がありました。

そこで、各テストフェーズでどのようなテストをすべきかをまとめました。それがこちらです。 改めてまとめたものをみると、難しいことは何も言っていないように思えます。
しかし、これを作成するまでに、いろんなことがありました。

本当に、いろんなことがありました……？

背景

U字プロセス

弥生の製品開発の多くは、開発プロセスとしてU字プロセスを取り入れています。
（参考：エンジニア採用｜採用情報｜弥生株式会社）
このU字プロセスは、弥生入社時に導入研修で学びます。日々の業務でもプロセスに準拠しているかどうかを判断基準としています。
弥生のエンジニアには浸透しているプロセスです。

「いつもの感じでよろしく」で、だいたい伝わる

システム横断プロジェクトで発生したこと

記帳代行支援サービスにおいても、「いつもの感じでよろしく」で済むものだと思っていました。
ところが、「そっちのシステムでテストしてると思ったからこっちでは見てないよ」「そっちでもやってるの？こっちのシステムでテスト終わってるよ」などなど、いろいろなトラブルが発生します。

特に、問題になったのが2点。

• システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまう
  結合テストでは、単一のサービスを対象にしたを実施するため、連結するサービスはダミーシステムを使ってテストしています。 このため、個別のシステムとしては動作していても、いざ連結してみると想定していた挙動にならないことが発生し、テストを中断せざるを得ないことがありました。

• 準備や設定が複雑なシステムを除外して、システムテストを実施してしまう
  システムテストは最終テストフェーズであり、リリース間近におこなうため、期日に追われています。 設定が複雑だったり、準備工数がかかったりする手順は、前フェーズでテストしているはずだから大丈夫だと思って省略させてしまいがちでした。 省略に根拠がないので、システムテストが貧弱になっていきました。

これらの問題を解決しなければいけません。

奮闘

文章にしてみた

どのフェーズのテストで何をしなければいけないのか、品質計画として文章化していきました。

一生懸命つくった品質計画書のイメージ

確認が必要なときには、集まってミーティングをしました。
フェーズごとに実施するテスト内容を品質計画で明示する前と明示した後で比較すると、各段に認識齟齬がなくなりました。
しかし、品質計画として書いてあるから全員が熟読している、というわけではありません。途中参加で読めていない人もいるし、読んだけれど忘れてしまったという人もいます。
そのつど確認をしていましたが、もう少しよりどころになるようなものが必要だと思うようになりました。

図にしてみた

「よりどころになり、これを見れば責任者に細かく確認をとらなくても安心して確認できるようなものがほしい」と思ってつくったのが冒頭の図です。
もう一度貼っておきます。
この図をつくって共有したところ、記帳代行支援サービスに関係するメンバーそれぞれがこの図を見ながら会話ができるようになりました。

問題になっていた2点に対しては、このような変化がありました。

• システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまっていた
  Aさん：「統合テストの前に連携テストする必要がある。いつ頃テストできそう？」
  Bさん：「〇月×日にテストアップ可能になる予定。」
  Aさん：「両システムがテストアップして、連携テスト後に、統合テスト開始ですね。」
  ⇒システム間のインターフェースに着目した連携テストを実施することで、統合テスト開始直後の中断がなくなりました。

• 準備や設定が複雑なシステムを除外して、システムテストを実施してしまっていた
  Aさん：「心配だから統合テストで2つ先のシステムまで確認しておく？」
  Bさん：「対象のシステムと直接連携していないシステムは、統合テストの確認対象じゃないよ。」
  Cさん：「システムテストで確実に実施するよう申し伝えておこう。」
  ⇒システムテスト内容が明確になり、最終フェーズとして有効なテストができるようになりました。

結果

「記帳代行支援サービスのテスト、どう考えればよいの？」というときに、よりどころになる図ができました。
そして、この品質計画の図は、記帳代行支援サービス以外でも複数のシステム・複数のソフトウェアから成り立つサービスでのテストを考えるときに使える内容になっています。

私は、2019年から記帳代行支援サービスに関わり、2020年にサービスの開始、2021年には記帳代行支援サービスのバージョンアップに立ち会いました。
まだまだ記帳代行支援サービスは進化していきます。しかし、私がQAエンジニアとして記帳代行支援サービスに関わるのはここまで。

私は、QAエンジニアとして別のサービスに参画し始めました。記帳代行支援サービスでつくった品質計画の図をさらに進化させ、今以上に弥生の資産となる品質計画をつくっていきます。

お知らせ

弥生では「弥生会計」に限らず、さまざまな製品・サービスに関わることができます。
一緒に、弥生の製品・サービスの品質を追求してみませんか？

herp.careers

テクニカルリーダーになってシステムの解像度が上がった話

この記事は弥生 Advent Calendar 2021の2日目の記事です

自己紹介

弥生の白井と申します。SMARTの推論という機械学習機能のテクニカルリーダーを担当しています。

家では1歳の息子を溺愛しています！！

テクニカルリーダーについて

入社してから今までエンジニアとして働いていたのですが、今年10月から初めてテクニカルリーダーをやることになりました。

弥生のテクニカルリーダーの役割には、開発計画の立案と実行、プログラム品質の管理（レビュー）、エンジニアのチーミング、適用技術の決定などがあります。

役割に伴う責任が大きくなる分、必要な権限も与えられます。今回はその与えられた権限によって見える世界が広がったという話です

広がる・・・世界が・・・

与えられた権限について

前提として、SMARTはAzureのApp ServiceというWebアプリ用のPaaSで動いています。App ServiceはOSをLinuxに指定することもでき、推論エンジンはLinuxのApp Serviceで動いています。

（ちなみに弥生の他のサービスではAWSを使用しているものもあります）

AzureはAzureポータルという管理画面（AWSだとAWSマネジメントコンソール）があるのですが、開発環境であっても一般のエンジニアにはAzureポータルへのアクセス権がありませんでした（ここはチームによって運用は異なるかもしれません）

テクニカルリーダーになることでAzureポータルへのアクセス権が与えられ、他にも監視系サービスのアクセス権など様々な権限が与えられます。

テクニカルリーダーの権限で見えた世界

テクニカルリーダーの権限でシステムの裏側を見ることで、システムのアーキテクチャをより深く理解できるようになりました。

例えばアプリケーションログを確認することによって、Webアプリがデプロイ後にどのように動いているかを知ることができました。

デプロイ直後のアプリケーションログを確認すると、LinuxのApp Serviceでは裏側でLinuxのDockerコンテナを作成し、そこにデプロイされたWebアプリをのせて動かしていることがわかりました。

他にもLogic Appsで定期実行スケジューラを組んで運用していたり、アプリケーションログをログ可視化用のElasticsearchに転送するために、一時的にBlobストレージに保存している処理などを目で見て確認することができました。

システムへの解像度が上がることでレベルが上がった気がする

システムのアーキテクチャの理解が深まったことで、システムへの解像度が一段と上がったような気もします。

例えば本番環境で謎の事象が発生した時でも、どこを調べればいいのかある程度検討がつくようになり、調査の目処が立てやすくなりました。 以前は闇雲にありとあらゆるログを確認してエラーが出ていないか調査していましたが、全体像を理解して調査ポイントを絞り込むことで、不必要な調査に時間をかけてしまうことが減りました。

他にも少し難しい事象を再現したり新しい機能を試すときに、モックを作ってささっと検証する、といったことがスムーズにできるようになりしました。

作業がうまくいったとき、自分のエンジニアとしてのレベルが上がった気がする！なんて思ったりしました。

レベルアップ！！！

エンジニアがシステムのアーキテクチャを理解できるようになるために

私は権限を手に入れたことでシステムのアーキテクチャをより理解できましたが、本来これはエンジニアだった時に理解したかったな～とも思いました。

よくよく設計書を見ると書いてあることだったりするのですが、目で見て確認できるかできないかは理解度に大きく影響すると感じました。セキュリティの都合上全てのエンジニアがAzureポータルを見れるようにすることは難しいのですが、なんとかならないものかと悩んでいます。

今後は他のエンジニアにもうまく伝えられる方法がないか考えていきたいと思います！

宣伝！！来年2月に推論チームでもくテクやります！！

mokuteku.connpass.com

弥生は月に1度、木曜日に技術イベント「もくテク」を開催しています （現在はリモートイベントで開催しています）

イベントページはまだ出来ていませんが、来年2月に推論（機械学習）がテーマの会を企画しています！

機械学習のサービス運用に興味のある方、弥生の研究開発に興味のある方など、誰でも大歓迎です！ぜひお気軽にお越しください！！！

弥生では一緒に働く仲間を募集しています。

herp.careers

QuickSightでかんたんに視覚化

この記事は 弥生 Advent Calendar 2021 の1日目の記事です。

よくできてる

こんにちは、3年間育てていた観葉植物のうち、ひとつがフェイクだと分かったgarusanです。
質感が違うなぁって思っていたら、素材も違っていたんですよね。でもよくできてます。

そんなショックを悟られないようにデータ分析について考えていたところ、 エクセルで行っていた集計をQuickSightに置き換えてみたら、結構かんたんにできることが分かりました。 本日はそんなQuickSightについて紹介します。こちらもよくできてます。

QuickSightって？

AWSが提供しているBIサービスです。 S3に配置したデータ、AthenaやRDSで抽出したデータを読み込んで、かんたんに視覚化できます。

視覚化してみよう

今回は、とあるcsvファイルのデータをQuickSightで視覚化してみます。

使用するデータ

日付型や数値が含まれるデータを用意しました。
へッダーあり、カンマ区切りのデータでUTF-8でエンコードしています。

植物	日付	葉っぱの枚数	お世話	観察結果
植物A	2018/03/31	10	購入	ふわふわしてる
植物B	2018/03/31	10	購入	ふわふわしてる
植物C	2018/03/31	10	購入	ふわふわしてる
植物D	2018/03/31	10	購入	ふわふわしてる
植物E	2018/03/31	10	購入	ふわふわしてる
植物F	2018/03/31	10	購入	つるつるしてる
...	...	...	...	...

データセット作成

データはS3に配置することが多いのですが、今回はcsvファイルをそのままアップロードしてみます。
一般的な形式の日付データは、フォーマットの指定不要で自動変換して読み込みます。よくできてます。

アップロードデータ

データ加工

もし、自動変換できなかった場合は文字列型として読み込まれます。

自動変換できない日付データ

そんなデータも西暦の日付形式であれば、フォーマットを指定することで変換できます。わざわざラムダを作成してデータ変換しなくても変換できることは大きなメリットです。

フォーマットを設定

変換完了

ちなみに和暦や和風月名は対応していません。弥生晦日→03/31の変換はさすがにダメでしたね。

対応は西暦のみです

視覚化

最後に視覚化です。今回は折れ線グラフを選択し、X軸、値、色に各項目をドラッグ＆ドロップします。

折れ線グラフを選択し、X軸を日付に設定

データセットとグラフの関連付けが終わりました。ここまでくればほぼ完成です。

設定完了

後は細かい体裁を整えます。デフォルトで設定されるグラフタイトルがちょっとアレなのでそれらしく変更し、日付の表示形式も変更します。

タイトルと日付の表示形式を変更

よくできてる

ビジネスデータを分析する場合、各サービスから取得するデータは日付フォーマットやエンコードも様々です。クセの強いデータは加工処理が必要になりますが、よくある日付フォーマット指定や数値の集計程度の加工であれば、ラムダやETLツールによる変換処理を作成せずにQuickSightだけでかんたんに視覚化が可能です。よくできてます。

弥生では一緒に働く仲間を募集しています。

herp.careers

もくテク「2021年秋のLT大会」を開催しました！

こんにちは、カトです。

11月の第3木曜日といえば、何の日でしょうか？
そうです、ボージョレ・ヌーヴォーの解禁日です。11月18日（木）、弊社オフィスではこんなイベントを開催していました。

そして、同日。11月18日（木）は、もくテクの開催日でもありました。

イベント盛りだくさんの1日です。

ボージョレ・ヌーヴォーに、もくテクを添えて

今回のもくテクのテーマ

2021年秋のLT大会

今回のもくテクは、日々の業務で得られた知見についてのLT！
弥生では10以上のチームに分かれて新卒～ベテランが一緒になり、開発を行っています。
今年もそれぞれのチームで新しい技術や施策の導入が進みました。

各発表者の開発で得られた生の声をお楽しみいただこうということで、21卒の新卒3人から、勤続20年を超えるベテランまで、新しい技術や施策の導入のLTをしました。

発表者と発表内容はこちらをご覧ください。


10月のもくテク開催報告ブログ、9月のもくテク開催報告ブログでは、セッションの内容をご紹介しています。今回11月の開催報告は、セッションの内容ではなく、舞台の裏側のお話しです。
LTの時間では話しきれなかったこと、じっくりみなさんに読んでほしいことは、個々にブログを書いてもらうことにします。
指針No.25：社会人の勉強は、アウトプットがゴールなのです。
もくテクに参加されたみなさんは覚えていますか？入社1年目の王さん＆竹内さんの発表『目指せ、精明強幹！！ ～社会人の心得～』で紹介していた書籍、入社１年目の教科書 | 書籍 | ダイヤモンド社 の指針の1つです。
何度でもゴールを決めちゃいましょう。

ちょっと違う気がしますが、細かいことは気にしない、気にしない。

発表者の裏話

早々に資料作成に着手する人、アイディアが降ってくるのを待つかのように直前まで資料作成には着手しない人、準備の仕方にも個性が現れていました。
準備を見ていて、面白いなと思った内容をご紹介します。

開催がオンラインならリハーサルもオンラインで

今まで、発表のリハーサルは、対面やZoomミーティングで実施していました。
対面やZoomミーティングで実施することで、その場ですぐに改善点を修正できるというメリットがある一方、発表者とレビューアーのスケジュールを合わせなければいけない、発表者自身が確認することができないというデメリットがありました。
そんなデメリットを解消すべく、Zoom録画機能を使って発表を録画してレビュー依頼をする発表者がいました。

私は、録画でのリハ―サルにレビューアーとして参加しました。
自分の都合のよいタイミングで動画を確認できました。「メモを取っている間に聞き逃したかもしれない」「何か違和感があるけれどなぜだろう」といった時に、一時停止や戻って聞き直すことができました。録画でのリハ―サルは、参加しやすいと感じました。
対話をしながら構想を練る場合は時間を共有して進めた方がメリットが大きくなります。発表練習の場合は、録画機能での確認が発表者・レビューアーともに非常に有効です。
発表者それぞれが、場面に合わせて工夫しながら準備を進めていました。

リハーサル動画のイメージ（※画像はイメージです。）

運営の裏話

オンサイト開催の時には、「開始時間に間に合わず遅れて参加する人にも本編をしっかり聞いてほしい」「場をあたためる意味合い」といったアイスブレイクの位置づけで会社紹介をしていました。
このため、オープニングの資料作成にあまり時間をかけていませんでした。
しかし、オンラインになってからのもくテクは、一味違います。

「いつもどおり」ではない会社紹介

弥生という組織やその中の人たちに興味を持っていただけるよう、運営メンバーはオープニングやクロージングにも力を入れています。
前回10月のオープニングでは、AWARD受賞をご紹介。今回11月のオープニングでは、弥生 22 シリーズの発売や、最新のユーザー数をご紹介。
10月・11月ともにクロージングでは採用イベントのご紹介をしています。
もくテクは、弥生の開発メンバーによる発表だけではなく、弥生の「今」を共有するイベントになっています。
ぜひ、オープニング・クロージングも楽しみに参加していただければと思います。


それでは、ここまで読んでいただいたあなたに。

3つのご案内

ご案内1：次回もくテクのご案内

次回の開催は2021年12月16日（木）です。
テーマは「AWS学習イベント DevAxのご紹介」！

弥生が2021年6月～9月に実施したAWS学習イベント「DevAx::Academy Monoliths To Microservices」についてご紹介します。
弥生のエンジニア向けに100人規模で実施した大型の技術研修イベントの概要と、学んだことの具体例の発表です。
ぜひ、各発表者が研修で得た知見についての生の声をお楽しみください！

詳細のご確認や、参加お申込みはこちらのイベントページから、よろしくお願いします。
mokuteku.connpass.com

ご案内2：アドベントカレンダーのご案内

今年もやります、弥生 Advent Calendar 2021！ 弥生グループで働くエンジニアが業務に関係あること・ないこと、色々書いていきます。 12月1日（水）から始まります。ぜひご覧ください。

qiita.com

ご案内3：採用に関するご案内

弥生では、いっしょに働く仲間を募集しています！ herp.careers https://herp.careers/v1/yayoi/QNC85w1I4sZeherp.careers

ここまで読んでいただきありがとうございました。
それでは、また次のブログでお会いしましょう！

もくテク「弥生で未経験の分野に挑戦したエンジニアたち」を開催しました！

こんにちは。たけです。2021年10月14日（木）にもくテク「弥生で未経験の分野に挑戦したエンジニアたち」をオンラインで開催しました。 今月も開催報告をしたいと思います！

イベントページはこちらです。（※開催は終了） mokuteku.connpass.com

今回のテーマ

弥生で未経験の分野に挑戦したエンジニアたち

エンジニアとしてのキャリアは多岐にわたっており、弥生でも様々な選択肢が用意されています。
しかし、キャリアチェンジには不安がつきもので、興味はあってもなかなか踏み切れないという方も多いのではないでしょうか。
そこで今回のもくテクでは、弥生で実際にキャリアチェンジをして新たな分野に挑戦したメンバーに自身の経験を語ってもらいました！

セッションの内容

今回は弥生の開発本部でAIの開発やインフラに携わるメンバーが、それぞれのキャリアチェンジストーリーを発表しました。

1.未経験から始めてハマったAIの世界 / 牛尾

新サービスのために自動仕訳の正解率を上げるというミッションを託され、AI開発に携わるようになった牛尾さん。
未経験の状態からプロジェクトをどのように進めていったか、AIをどのように独学していったかについてお話ししました。
AI未経験の方々に向けてのQ & Aもあり、最後は「興味があれば、是非AIにチャレンジしてみてください」とのメッセージで締めくくりました。

牛尾さんのWantedlyの記事もどうぞご覧ください。 www.wantedly.com

2.プログラミングテスト0点!?それならインフラだ! / 峯岸

学生時代にプログラミングテストで0点を取り、インフラエンジニアを志望していたものの、就職先で任されたのは開発の仕事だった峯岸さん。
めげずにインフラの仕事ができる環境を探し続けた結果、知り合いのいる弥生でインフラエンジニアとしてキャリアをスタートすることができました。
自宅ラボ（※業務用のサーバーやネットワーク機器を活用する自宅の環境）の写真も公開し、インフラ愛をアピールしました。

峯岸さんのWantedlyの記事もどうぞご覧ください。 www.wantedly.com

3.チャレンジするきっかけは何処にあるかわからない / 辻野

新卒で弥生に入社し、開発系チームへの所属を経て、インフラエンジニアへとキャリアチェンジした辻野さん。
技術カンファレンスへの参加をきっかけにバックエンド系の技術に興味を持ち、キャリアパス面談を通じてインフラ系チームに入ることとなりました。
キャリアチェンジに不安を抱えながらも、先輩方に相談しながら自分の道を決めていったことをお話ししました。

4.ベンダーから事業会社の情シスへ。何が変わった、変わらなかった！？ / 石田

トリを飾るのは、峯岸さんと辻野さんの所属しているチームでリーダーをしている石田さん。
ハードウェアベンダーのサポートエンジニア、バックオフィス職を経験した後、「もう一度コマンドを打ってみたい」という気持ちもあり弥生に転職してインフラエンジニアになりました。
転職後、初めて聞く専門用語に戸惑いながらも、弥生の本社オフィス移転という大仕事をやり遂げました。

次回のご案内

次回の開催は2021年11月18日（木）です。
テーマは「2021年秋のLT大会」！

弥生の開発本部のメンバーが、日々の業務で得た知見についてのLTを行います！
弥生では10以上のチームに分かれて新卒～ベテランが一緒になり、開発を行っています。
今年もそれぞれのチームで新しい技術や施策の導入が進みました。
色とりどりの"実り"を共有しますので、ぜひご参加ください。

mokuteku.connpass.com

採用について

弥生では、幅広いポジションでいっしょに働く仲間を募集しています！
ポジション等の詳細については以下のサイトをご覧ください。

herp.careers

GooglePlayストアの評価を改善しよう！

弥生モバイルチームのtijinsです。

今日はGooglePlayストアでの評価を改善する取り組みについて紹介します。

まず結果からですが、今回の取り組みによりMisocaアプリの評価が、半年間で3.2→3.7と改善しています。

以前の評価

この取り組みを開始する前、Misocaアプリのレビューには、ネガティブなものが多く並んでいました。

使えないのでアンインストールしました。☆1

ログインできません。☆1

などが多かったです。

ネガティブなレビューが多くなる理由の考察

低評価のレビューを確認すると、トラブルに遭遇したユーザーが問い合わせ窓口としてレビューを利用し、その際に低評価を付けている事が分かりました。

バグや障害があればバグの解消が評価改善の正攻法ですが、稼働率やリテンション率を見る限り、すぐに直せる箇所は無く、もう少し高めの評価になってもよさそうでした。

高評価のレビューを増やすには

レビューへの導線を作る

気に入ったらレビューをお願いしますのような、レビューを促すダイアログを導入しているアプリをよく見かけます。 この方法だと親切なユーザーだけがレビューしてくれるので、高評価が集まりやすくなります。

レビューを促すタイミング

高評価のレビューをしてもらう為には、レビューをお願いするタイミングも重要です。
例えば、クラッシュやエラーの発生に合わせてレビューを促すと、低評価のレビューが集まってしまいます。

Misocaアプリでは、請求書のステータスを入金済みにしたタイミングでレビューを促すダイアログを表示する事にしました。 入金されたタイミングであれば、感情的にも嬉しく、またログインできないや請求書を作成できないという事もないはずです。

アプリ内レビュー (In-app review)

ユーザーにレビューを促すダイアログを表示しても
ダイアログを見る → レビューするをクリック → GooglePlayに遷移 → レビューする

と、かなりの手順が必要なので、本当に親切なユーザー以外はレビューしてくれません。

Misocaアプリでは、より効果的にレビューを収集する為、GooglePlayコアライブラリのIn-App reviw API (アプリ内レビュー)を使用する事にしました。

アプリ内レビューを使用すると、レビュー投稿フォームをアプリ内に設置でき、GooglePlayに遷移せず投稿可能です。

アプリ内レビューの動作イメージ Google Developersから引用

In-App review APIの導入

アプリ内レビュー単独のライブラリはなく、GooglePlay Core SDKを導入します

app/build.gradle

dependencies {
    implementation 'com.google.android.play:core:1.10.2'
    // Kotlinの場合 以下も導入する
    implementation 'com.google.android.play:core-ktx:1.8.1'
}

レビューダイアログの表示

レビュー投稿フォーム（レビューダイアログ）はライブラリから表示され、GooglePlayとの通信もライブラリが行うので、アプリとしてはAPIを呼び出すだけです。
ただし、設計のガイドラインには、以下の注意点があげられています。

• レビューダイアログを改変しないこと（意図的にしない限り改変できません）
• レビューダイアログの上にレイヤーを重ねて表示しないこと（クリックジャッキングしないこと）
• レビューダイアログの表示後、コードから制御しないこと（ユーザーの操作で投稿、またはキャンセルされるのを待つこと）

以下のコードを実行する事でレビューダイアログが表示されます。（表示されない場合もある）

fun requestReview(context: Context){
    val reviewManager = ReviewManagerFactory.create(context)
    reviewManager.requestReviewFlow().addOnSuccessListener { reviewInfo ->
        reviewManager.launchReviewFlow(context, reviewInfo). addOnCompleteListener {
            // APIへのリクエスト完了
            //  投稿 or キャンセル を検出する事はできない。レビューダイアログが表示されない場合もある
        }
    }

}

アプリ内レビュー利用時の注意点

ReviewManager.launchReviewFlow()を実行しても、レビューダイアログが表示されない場合があります。
また、ユーザーがレビューを投稿したのかキャンセルしたのかも取得できない為、未レビューのユーザーに絞ってレビューを促すという制御もできません。
とりあえずレビューが完了しているかを気にせずAPIを実行しても、未レビューのユーザーに限定してダイアログを表示してくれるようです。

もっと改善する

☆4や☆5のレビューが増えても、☆1のレビューが有ると平均はあまり上がりません。
しかし、偶発的なトラブルでも☆1は付いてしまう為、☆1を無くす事は不可能です。

☆1のレビューは全くダメ、使えない！のような短文が多いのですが、使い方が分からなくて困っています。教えてください。のような問い合わせも含まれています。

Misocaには電話・メール・チャットを利用できる問い合わせ窓口があり、GooglePlayのレビューはユーザーからのご意見・ご感想を頂戴する所という位置づけであった為、レビュー上で問い合わせがあっても回答していませんでした。

レビューでも双方向のサポートを提供しトラブルを解消できれば、☆1が付いた後でも評価を改めてもらえる余地がありそうです。

終わりに

ストアの評価が4.0未満だと、検索から入ってきたユーザーはあまりインストールしてくれないようです。
実際、MisocaアプリはiOS版もAndroid版もストアの訪問者数は同じくらいなのに、評価の低いAndroid版のインストール率が低くなっています。
ユーザーを逃してしまうのはもったいないですね。

モバイルチームの求人

弥生のモバイルチームでは、Android、iOSのエンジニアを募集中です！！

www.wantedly.com

www.wantedly.com

もくテクの紹介

弥生では毎月技術イベント「もくテク」を開催しています。11月も開催するので、ぜひご参加ください！

• 日時：11/18(木) 19:00 〜 20:30
• 内容：今回のもくテクでは、日々の業務で得られた知見についてのLTを行います。
• 形式：Zoomミーティング
• 詳細・参加方法：以下のリンクから参加登録をお願いします！ mokuteku.connpass.com