VPN製品の社内PoCを通して考えたことなど

お疲れさまです。インフラチームの山口です。

新型コロナウィルスの影響下でのリモートワークに伴い最近社内でいくつかのVPNアプライアンスのPoCを実施したのでその際に考えたことや振り返ってこうしておくべきだったという内容を戒めとして各フェーズに沿ってエッセイとして記載します。 なお、現在進行系で数種の製品のPoC中のため、「何か特定の製品を使ってうまくいった」や「弊社はこうしている」などの情報は何もない、私が感じたチラシの裏的なレポートになります。

要は、技術的に新規性のあることはない内容ですが、同じような問題意識を持ってる人間に届けばいいなといった感じの文章になります(文章でもなんでも刺さる人にだけ刺さればいいというポリシーなので、そういった感じです)。

本稿の構成を以下に記載します。

まず、筆者の経歴および、前提条件を説明します。 次に、製品選定や実際のPoC準備から実施までに考えたことを記載します。 そして、最後に感想をまとめます。

筆者の経歴

前職は以下の感じの業務に従事しており、お客様のネットワーク構築やビデオ会議の導入などをしていました。

  • 顧客のNW(主にWAN)構築・運用(所謂ネットワークエンジニア)
  • ビデオ会議の端末やサーバの導入・運用など(これは何エンジニアなのか適切な表現は思いつかない)

その後弊社に転職して今に至ります。

要は、法人のお客様にベンダーのアプライアンス製品を導入したりする仕事をしている人の気持や挙動は薄々イメージつくといった感じになります。 前職では、企業の情シスの方が主に対面となる顧客の形でした。

が、今回のPoCでは、どちらかというと企業の情シスに近い動きをしており、立場変わると見え方変わるなというのを感じています。 その一方で、再販のベンダーさんが英語の資料ベースにパワーポイントなどでまとめられた日本語の手順書などいただくと、「こういう類作るの面倒だよね(困ったら英語の一次資料頑張って読むけど、利用者としては日本語でアウトラインまとめられているのはありがたい)」という気持ちもあったりして日々勉強させて頂いています。

前提条件

本稿全体の前提にかかる弊社の現状について開示可能な範囲で簡単に箇条書きで記載します。 今回のPoCについては基本的に情シスと協力して進めるという形を取っています。

  • 社員数
    • 150人強(業務委託の方なども含む)
  • 人員の構成
    • 情シス: 2名
      • 社内NWや社内のPC/社内で利用する外部サービスの管理など
    • インフラ: 7名
      • 自社サービスのインフラ部分を担当
      • 当初は情シスワークもインフラで実施していたが、専任の情シス担当者着任に伴い移管したという経緯がある
      • 情シス・インフラは部署としては別ライン(会社でよくある構成だと思いますが、情シスは人事総務系の所属・インフラはエンジニア部門の所属)
  • NW構成と運用
    • オンプレミスからAWSへの移行中のためデータセンタ・AWS側それぞれへのIP到達性が必要
    • リモートアクセスVPNはルータではなくLinuxサーバで終端(PC側は各OSに組み込みのクライアントを利用)
    • VPN関連はインフラの管轄(ただし、社員からのVPN関連の問い合わせやサポートは情シスでも一部対応してい頂いているケースもある)
  • 問題意識
    • リモートワークに伴い以下の工数が増えている点を改善したい
      • VPNの初期設定時のサポート
      • VPNがつながらないなどのサポート

製品の選定

製品の選定の際に考えたことを記載します。

まず、選択肢として、ベンダーの提供している製品を使うか、自分たちでOSSをベースに構築するかがあると思います。

弊社の状況としては、OSSなどを組み合わせて自分たちで独自に構築して運用する工数を取ることは避けたかったため、ベンダーの製品を選択する形を取りました。 また、ベンダーという単語は本稿では、サービスや製品を提供している企業と、その製品の代理店をなんとなく指す意味合いで使います。

  • OSSを組み合わせて構築する
  • ベンダーの製品を使用する

次に、製品を選ぶ際に考えた点を以下に記載します。 以下に明示的に記載はしていませんが、コストも気にはします。

  • 利用者の観点で設定が簡単か
    • VPNの設定のサポートが辛いという問題を解消したいのでこれは重要。
  • 端末のアップリンクでのポートの遮断などに対応可能か
    • 要は、リモートワーク時のご自宅のNWなどでポートが遮断されている場合はTCP:443などにフォールバックしてつながってくれるような製品かどうか。
    • リモートワークの際に、社内のメンバーのご自宅のNW機器の設定起因と思われるトラブルに対して、会社としてどこまで手を出すかは悩ましいところなので極力robustに動いてくれる製品が良い。
    • 前職なら「お客様責任のお客様機器」なので設定変更はご法度的な箇所を、製品の型番教えてもらいマニュアル読みつつ影響なく問題を回避する方法を調べ対応するのは面白くもあるが、しくじったときにお互いに辛い。
    • が、まあ最近の製品は、おおよそフォールバックして通信してくれるのでそこまで気にする必要は実際無い印象。
  • PoCや導入に際し既存への通信影響がなく、可能であればNW構成も変更せず利用可能なこと
    • 要は、PoCや検証のために既存の通信経路などの変更はしたくない。
    • 最近の流行りだと大概はデータセンタやVPCに配置するVPNサーバに相当するアプライアンス側でも、アウトバウンドでクラウド側と接続するデザインが大半の印象なのでこれもそこまで気にする必要はなかった。
    • また、オンプレミス側に配置する仮想アプライアンスのためには、ESXiがあれば良い
      • Dockerのイメージが提供されている製品もあるようであったが一部機能に制限などがあるため基本はESXiかHyper-V仮想マシンをデプロイする。
      • 余力があればEKSなりECSで動かしてみるかといった気持ちを当初抱いていたが実際はそんな余力はなかった。
  • サポート体制
    • 英語での問い合わせでも良いですが、辛いので可能であれば日本語でサポートが受けられるのが望ましい。
  • 息が長い製品であるかどうか
    • 要は、ベンダー都合でEOS(End of Support もしくは End of Service)にすぐならなさそうか。
    • これは前職でベンダーの日本法人がなくなったり、EoSに伴う後継の製品への置き換えが辛かったりというケースがあったので少し気にしました。
      • が、根本的に利用者側としては回避する方法はないので頭に留めておく程度。

PoC準備

次に社内PoCの準備に際して考えたことを記載します。

  • 事前に製品の検証をしておく
    • 社内でPoCの依頼をする前に、事前に製品の挙動などの検証をしておきます。
    • 社内のメンバーに使ってもらう状態になると気軽に設定変えて試験といった形が難しくなるため事前に気になる点は検証をしておくのが望ましい。
  • 協力を依頼する部署に事前にお願いしておく
    • 会社の規模にもよるとは思いますが、流石に昨日の今日で社内の各部署に「明日から社内PoCやるんで協力よろしく」は避けたいので、事前に協力を依頼したいメンバーをリストアップし、上長含めて事前にご協力のお願いを出すという形にしました。
    • 各部門で数人ずつ協力していただき、概ね漏れがないような人選としました。
  • 各種手順の準備
    • インストール/アンイストール/トラブルシュートの手順は事前に準備しておきます。
    • 準備しておけばおくだけ、後が楽になるため注力しておいた方が良いと思いますが、後から漏れなどが出てくるので実際社内PoCの間にも追加で準備したりしていました。
  • ローカル開発環境でも影響が無いか
    • PCから各リソースにIP到達性さえあればよしとしてしまっていて盲点的な箇所ではあったのですが、弊社サービスのローカル開発環境がリモートのDBなどと通信している箇所があり、PoCを行う製品でも既存のVPNと比較して、ローカル開発環境が極端に遅かったり不安定にならないかを確認します。
    • たまに遅いなどの問題をうまく検知するために、事前に負荷試験ツールの類でローカル開発環境に対して数時間試験をしてレスポンスタイムを記録し定量的に比較できるようにしておきます。

PoC実施&評価

PoC実施中から評価の際に考えた内容を列挙します。 実施する状態になったらやりきるしかなくて、どれだけ事前に準備して問題潰しておくかだなと言うのが正直な印象です。

  • PoC中はPoCに対する問い合わせ対応を最優先にする
    • 社内PoC中はPoCに関連する問い合わせの対応を最優先にするよう事前に自分の持っているタスクの段取りなどを調整していました。
  • PoC実施中にうまくいかないケースがあったら問題判別を強行しない
    • PoCしてもらっているメンバーからうまく動かないなどの問い合わせがあった場合、長時間に渡る可能性がある問題判別は極力避けるようにしました。
    • これは、社内PoCに協力いただいていること起因で、既存の業務に影響が出てしまうのは本意ではないため、うまくいかない点の解消がすぐできなそうなら、既存のVPNに切り戻して業務継続していただくような形です。
  • 評価方法
    • 複数製品を評価する場合何らかの形で数字に落として比較できると嬉しいので、PoCに協力していただいたメンバーにアンケート取る形にした。

まとめ(というか感想)

まとめというか感想なのですが、社内の利用者・情シス・インフラ・再販事業者・製品ベンダーなど立場が変わると見え方も変わると思いますが、それぞれの立場でみんな幸せになる形で、構成を改善していけるといいなという気持ちです。

エッジコンピューティングでアクセス集中、パーソナライズ、プライバシー保護の課題を解決

エンジニアの木村です。最近は負荷対策のためのリファクタリングやリアーキテクティングのリードや、データ基盤・ML・検索基盤を担当するチームのマネージャーとしてデータ関連の案件に携わっております。

先週、webinar 形式で行われた Akamai TechWeek 2021 Japan にて、6/16 に「EdgeWorkersの導入について」というテーマで、昨年末にバイマに導入したEdgeWorkersというAkamaiのサービスについて講演しました。本ブログでもその内容を共有したいと思います。

スライドはこちらになります。

エッジコンピューティング導入の背景

導入背景としては、アクセス集中下でもサービス自身のドメインを通じて自らユーザーを追跡し、ファーストパーティデータを収集する必要性という事業課題がありました。

アクセス集中を伴うマーケティング施策への対応

事業課題の1つとして、モバイルへのプッシュ通知と、フラッシュセール施策という、いずれもアクセスの集中を引き起こすマーケティング施策へサービスとして対応していく必要がありました。

まず、モバイルへのプッシュ通知が増加しているのですが、その背景には時代やサービスの成長フェーズの移り変わりがあります。マスマーケティングからOne to Oneマーケティングへと、我々の注力ポイントが変わってきているからです。実際、以前は認知を広げて新規顧客を獲得するためにTVCMによるマスキャンペーンを展開し、当時はアクセス集中といえばTVCMの放映起因がほとんどでした。最近は既存顧客一人一人に対してパーソナライズ した通知を送ってリテンションを図る施策が増えています。モバイルアプリをインストールしているユーザーやLINEのバイマ公式アカウントと連携しているユーザーはサービスへのロイヤリティが高く、通知の開封率も高いので特に一斉に送信するような通知ではTVCM放映以上のアクセス集中が生まれています。

フラッシュセールとは、ブラックフライデーサイバーマンデーなどのセール施策のことです。期間や商品の在庫も限定した形で行われ、また先程のプッシュ通知により開始が通知されるのでアクセスの集中が発生します。毎年性能改善を重ねてはいたのですが、スケールが難しいオンプレのインフラを使っているサービスのところでは対策に限界があったのと、年々増加していくユーザー数に追いつかない状況で、毎年このセールの開始直後はサイトのパフォーマンスが不安定になっていました。

パーソナライズとプライバシー保護の両立

直面していた事業課題の2つ目は、プライバシー保護とパーソナライズの両立です。

パーソナライズ についてですが、最近はレコメンドなどに代表されるパーソナライズ されたUXへの期待が高まっています。北米やイギリスの消費者を対象にした2019年の調査*1では、63%の消費者がサービスの標準としてパーソナライズ を期待しているそうです。また、自分だけの特別なオファーが送られてきたり、サービスとの各接点で一人の同一の顧客として認識されることで一人の個人として扱われていると感じるそうです。したがって、サイトのUXだけでなく、マーケティング施策にもパーソナライズ が求められています。さらに、そういったUX改善やマーケティング施策の効果測定でも、施策による単純なKPIの動きだけでなく、ユーザーを一人一人区別して分析し、どのような属性の顧客に効いているのかといった高い解像度での分析が求められています。

また、ユーザーはパーソナライズ を期待している一方で、プライバシーの保護についての意識も高まっていて、個人データの収集に関して透明性が求められています。それに答えるように、SafariChromeといったメジャーなブラウザでブラウザフィンガープリントやサードパーティクッキー、クライアントサイドクッキーは何らかの制限や規制、あるいは廃止される予定になっています。これにより、ユーザーを追跡する手段としては、サービス自身のドメインを使ってのファーストパーティクッキーだけが残され、そのクッキーを通じて収集されるファーストパーティデータの重要性が増してきています*2

エッジコンピューティングの導入理由

そういった背景から、なぜエッジコンピューティングの導入に至ったのかをお話しします。

CDN導入のための必須要件

背景にあったアクセスの集中に対応するために、それまで画像・js・cssといった静的コンテンツのみで多なっていたCDNでの配信を、Webアプリから返しているHTMLやAPIという動的コンテンツの配信にも導入することになりました。また、これも背景で説明したパーソナライズ やデータ収集の必要性から、CDNを選定するにあたり以下の3つの必須要件を定めました。

  • レスポンスをパーソナライズ可能
  • エッジアクセスデータと自社DWHの連携が可能
  • ファーストパーティCookie操作をエッジへ移行可能

1つ目はレスポンスをパーソナライズ可能性、つまりキャッシュするコンテンツをユーザーによって分けたりが可能かどうかです。2つ目はエッジアクセスデータと自社DWHの連携が可能かという点です。それまではオリジンのWebサーバーのログをDWHへ連携することでユーザーのサイト内の行動を分析していたのですが、キャッシュされるコンテンツに関してはオリジン側へログが残らなくなるため、分析のためにエッジのアクセスデータを自社DWHへ連携する必要があります。3つ目ですが、バイマでは未ログインでセッションを張っていないユーザーも追跡可能にするためにファーストパーティcookieを利用していて、これによりUXのパーソナライズやマーケティング施策の効果計測を実現しています。そのCookieの操作処理をエッジへ移行する必要がありました。

ITP2.1 への対応

Cookie操作処理のエッジへ移行する必要性の経緯としては、ITP 2.1 への対応というのがあります。

f:id:enigmo7:20210617143016p:plainf:id:enigmo7:20210617143020p:plainf:id:enigmo7:20210617143027p:plain
Cookieの操作処理の変遷
バイマでは当初、そのCookieの操作をJavaScriptAPIであるDocument.cookieで行っていたのですが、2019年にApple によってブラウザのJavascriptで作成するCookieの有効期限は最大7日に制限するというITP 2.1のSafariへの導入 がアナウンスされました。バイマではiOSSafariのユーザーが大半を占めるので、我々はそれまでブラウザのJavascriptで行っていたCookieの操作をオリジンのアプリケーションサーバー側へ移行し、Set-Cookieヘッダーによりcookieを操作するように修正を行いました。今回のCDNの導入の際は、キャッシュヒット時にもSet-Cookieヘッダを返すことでCookieを操作する必要性がでてきます。したがって、ファーストパーティCookieの操作処理をエッジサーバー側へ移行する必要性がありました。

Akamai EdgeWorkers を採用

いくつかのCDNサービスからAkamaiを選んだ理由としては、上述の必須要件を満たしていたという点がありました。プロパティだけでもかなり柔軟なルール設定が可能で、それだけでもある程度パーソナライズは実現可能でした。また、DataStream 2 というサービスにいよりエッジのアクセスデータをリアルタイムに近い形で、GoogleのBigQuery上で構築している自社のDWHへデータ連携が可能でした。さらに、EdgeWorkersによりCookie操作をエッジサーバー上への移行が可能という点で必須要件を全て満たすことができました。

また、すでにスタティックコンテンツの配信では既に導入実績があったという点も採用への後押しになりました。実は、この3つの必須要件のパーソナライズ、データ連携、エッジコンピューティングの機能については、他の競合CDNサービスも提供されています。ただ我々としては利用に慣れていて信頼のあるAkamaiを使いたかったので、逆にこちらからエッジコンピューティングの機能について問い合わせたところ、EdgeWorkersを提案いただき採用に至りました。

EdgeWorkers の開発・運用

EdgeWorkersでどのように開発をすすめたのかや、実際の運用状況について紹介します。

利用開始は簡単

最初のEdgeWorkersへのとっかかりは簡単でした。すでにAkamaiをお使いの方にはお馴染みのWebコンソール「Control Center」から利用可能です。実装も簡単で、開発者はイベントハンドラのファンクションを実装するだけになります。今回クライアントへのレスポンスするタイミングで呼ばれる onClientResponse を実装しました。Web UI上でコーディング、アクティベートも可能だったので、チュートリアルとしてのHello Worldを動かすところまでは1日で到達できました。

ライブラリも利用可能

利用できるライブラリについてですが、cookie操作やURLのパースなどは標準で組み込まれいているモジュールで十分可能でした。また、rollup.jsというJavaScriptのモジュールバンドラーにより標準組み込みでない、npmリポジトリで公開されているサードパーティ製モジュールもbundle可能でした。1点だけ注意というか、当然ではあるのですが、ブラウザJavaScriptのコードをそのまま移植しようとしても動かなかったです。元々はブラウザJavaScriptCookieを操作していたロジックはあったのですが、書き換える必要はありました。さらに細かいところで言うと、ブラウザだとwindowのオブジェクトにatobやbtoaというbase64エンコーディング・デコーディングをしてくれるfunctionが付いてるんですが、それは使えず、代わりにrollup.jsでbase64エンコーディングを行う3rdパーティモジュールをbundleして呼び出して使っています。

開発時のデバッグ方法

開発時のデバッグ方法ですが、ログ出力をレスポンスヘッダに埋め込んで確認できるenhancend debug headerを利用し、ステージングへアップロード&アクティベートを繰り返しながらのプリントデバッグで切り抜けました。本当はakamaiCLIでローカルにSandboxを構築して利用する方法もあるのですが、その構築が手順通りにやってもうまくいかず、ブラックフライデーが差し迫っていたこともあり、問い合わせる余裕すらなかったので、実環境のステージングでの開発となりました。ただステージングへのアクティベートは毎回許容範囲内の時間で終わってくれるので、このやり方でも開発は可能でした。手順通りにやってうまくいかないという点なのですが、ある程度経験のあるメンバーが二人がトライして、二人ともSandbox構築にハマっていたので、ドキュメントに関しては何らかの改善の余地はありそうです。昨年末の話なので、既に改善されているかもしれないですが、期待とフィードバックの意味も込めて、ここで苦労したエピソードとして紹介させていただきます。

開発時の参考リソース

開発時に参考にしたリソースとしては、ユーザーガイドもあるのですが、他にもGitHubのリポジトリにexampleが公開されていて、先行事例があまりない段階での利用だったので、開発時にはそれが大変助かりました。ブログにも参考になりそうな記事があります。ユースケースの紹介もありますし、Github ActionsでCICDを実現するような事例も載っていて、デベロッパーフレンドリーにできてるなと思いました。

本番運用してみて

実際に本番運用してみている状況についてですが、実行時間的なパフォーマンスは非常に良いです。エッジでなにか処理を行っていてもUX上はなにもレイテンシを感じないレベルを維持できています。

f:id:enigmo7:20210617153422p:plain
EdgeWorkersの実行時間の推移

ただし、本番環境でのトラブルシューティング時のログ調査に課題があるなと感じました。原因調査のため、ログ出力の解析をするためにログ取得をしようとすると、Log Delivery Serviceを使うのですが、実際に手元にログが届くのが次の日になるので、トラブルシューティングのサイクルを回すのが非常に時間を要する状態でした。EdgeWorkersをFaaS (Function As A Service) として見たときに、競合としてはAWSのLambdaやGCPのCloud Functionがそれに当たると思うのですが、これらの場合はリアルタイムに近い形でWebUI上で本番のログをtailしたり、検索、分析できたりします。当然Akamaiそういった機能はあるのだろうと、期待していたところもありましたが、そういた機能は未提供となっているところは残念なポイントでした。今後提供されることを期待したいと思います。

EdgeWorkersの今後の活用と期待

私たちのEdgeWorkersの今後の活用案や、EdgeWorkers自体に対してどのような進化を期待しているかというお話しをしたいと思います。

EdgeWorkersの今後の活用案

今後の活用案としては、これまではキャッシュすることでオリジン側の負荷をオフロードするだけでしたが、EdgeWorkersによりオリジンのロジック自体をエッジへマイグレーションしてよりアグレッシブなオフロードが可能となったと思うので、今回はCookie操作の処理だけでしたが、分散処理可能なものはEdgeWorkersへ移行してよりオリジン側の負荷を減らすことが考えられます。また、これまでオリジン側の負荷の制約で諦めていたサイトUXのパーソナライズ施策がたくさんあります。工夫次第ではEdgeWorkersを使うことで実現できそうなものもありそうです。

EdgeWorkersへの今後の期待

最後に、EdgeWorkersへの今後の期待としては、運用のところでも述べた競合並みの監視・ログ管理ツールの提供です。また、監視として使えるものとしてEdgeWorkers Report APIが提供されていて、各種メトリクスを取得できるのですが、自社の監視ツールに手動で設定する必要があります。最近は我々も導入しているDataDogやNew Relicといった3rd パーティの監視SaaSがあるので、SaaS側にEdgeWorkersのインテグレーションを用意してもらって簡単にメトリクスやログを収集し、常時監視できたらありがたいと思いました。率直に言って、現状のレポーティングの機能だけですと、Cookieの操作のようなライトな使い方が限界かなという印象です。これら監視・ログのサポートが揃えば、ある程度複雑な処理を書いても本番運用に耐えると思うので、今後の活用案のところで書いたような、マイクロサービス をエッジ上で構築するぐらいのヘビーな活用も目指せると思いました。

また、データ連携の強化も期待したいです。EdgeKVという、Key Valueストアとして使えるストレージの機能があるのですが、そこのデータがエッジ上にあるままでは活用は限定的なものになってしまうと思いました。そこのデータも自社のDWHなどに取り込み、他のデータと紐づけての活用が可能になれば理想的です。

まとめ

私たちは、アクセス集中による負荷の軽減・パーソナライズ・プライバシーの保護というお互いにトレードオフの関係にある課題を解決する必要がありました。エッジコンピューティングの導入により、それらをどれも犠牲にすることなくクリアすることができました。EdgeWorkersには、ドキュメントの整備や運用面ではまだ課題はあるもの、それらが改善されれば開発者体験としてはさらに向上し、よりディープな活用へと踏み出すことができると期待しています。

最後に、私たちは今回紹介したようなUXの向上やプライバシー保護についての課題など、純粋にユーザー目線でサービスの課題解決に日々取り組んでおります。CDNを始めクラウドサービスや、最新テクノロジーを駆使して世界を変える流れを作るサービスを提供する仕事に興味のある方は、下のリンクからご応募お待ちしております。

株式会社エニグモ 正社員の求人一覧

hrmos.co

enigmoデザイナーの「最近気になるデザイントピック」- アプリUI編

こんにちは。デザイナーの別所です。
本日はenigmoデザイナーの、最近気になっているデザインに関するトピックをご紹介したいと思います。

今回のテーマは「アプリUI編」です!

心地よい使い勝手!映画レビューアプリ「Must」

「Must」は映画/TVファンのためのSNSアプリです。
作品のレビューを投稿したり、見たい映画や番組をコレクションとして保存できたり、友達と繋がって他の人がコレクションしている作品を見たりすることができます。
おすすめ作品をデイリーでレコメンドしてもらえたりもします。
2016年にリリースされたアメリカ生まれのアプリです。

f:id:enigmo7:20210603171725p:plain
引用:https://mustapp.com/

デザイナーのこだわりを感じるUI/UX

f:id:enigmo7:20210603171820p:plain Mustの一番の特徴は、画面の下半分の操作で完結するように設計されているUI/UXではないでしょうか。
レビューの入力や「観たい」「鑑賞済み」を選択するボタンなど、このアプリのメインアクションは全て画面の下部で操作できるため、「指が届かない」「両手に持ち替える」などのストレスがなくスムーズに操作できます。
昨今のスマホの様々な端末サイズに左右されないような設計がされているんですね!
ストアのレビューでも優れたUI/UXに対してのコメントが多く見られます。 (レビューでUIについて言及されるアプリって珍しい気がします!)

心地良いUIモーション

Mustは見た目の美しさだけでなく、モーションにもこだわりを感じます。
作品のサムネイルをタップすると、本棚から選んで取り出すような雰囲気のモーションがついてます。タップした時にサムネが少し小さくなるところも、ユーザーが押したことを認知させる表現で、細かい技が効いてます。
作品情報のモーダルは作品サムネイルにかぶさる様に画面下から表示されレイヤー感があるので、作品サムネイルと作品情報との優先順位を感じさせる見た目になっています。

テキスト要素をギリギリまで排除したシンプルさ

f:id:enigmo7:20210603173215p:plain
引用:https://mustapp.com/
海外アプリっぽいな〜と感じるのがテキスト要素の圧倒的少なさ。
基本的には作品名はテキストで表示させず作品画像のみとなっています。 このシンプルさが美しい作品画像をより際立たせてる気がします。 視認性担保のため小さい画像も無いところが、作品情報を認識しやすく操作しやすいです。

楽しい絵文字遣い

f:id:enigmo7:20210603173326p:plain

絵文字の使い方にシャレが効いていてオシャレです。
レビューを10段階で入力するときは、数字によって表情が変わります。 こういう小技で入力を楽しめる体験って良いですね。

海外のアプリなので日本語のレビューや、邦題作品はまだ少ないようです。
日本でももっと広まって欲しいです!

株式会社エニグモ 正社員の求人一覧

hrmos.co

コロナウィルスがやって来た!情シス奮闘記

こんにちは、Corporate IT/Business ITを担当している足立 です。

この記事は Enigmo Advent Calendar 2020 の 24日目の記事です。

エニグモでは1人目のコーポレートIT担当として未着手な社内IT環境をコツコツ整備してます。 世間的には1人情シスと呼ばれるポジションです。

今回は2020年に取り組んだ事を書きたいと思います。

2020年は何と言ってもコロナウィルス

1月後半から徐々に猛威が迫ってきて弊社も2月17日に対応・方針についてのMTGが予定されてました。
また、偶然にも同タイミングでSlackの全社チャンネルに 会社に対し何らかの方針、対応があるのかと言う内容の投稿がありました。
今思うと見えない恐怖・不安が爆発した日だと思います。

f:id:enigmo7:20201211162325p:plain
コロナウィルス

2月17日 緊急招集 MTG

2月17日 夕方 経営陣、監査役、部署長、情シスが招集されました。
そこで決まった方針は下記内容になります。

方針の大概要

①「在宅勤務」の推奨
②出社勤務の場合は「時差通勤」推奨と「社内感染防止ルール」の厳守
③本方針は翌営業日からのスタート
コロナウィルスの影響により、急遽全社的にリモートワークを一斉にスタートする事になりました。

情シスとしてのMISSIONは リモートワーク環境の構築

リモートワーク環境・・・

実はリモートワークを本導入してませんでした。
当初の予定だとオフィスが元々国立競技場が近いと言うこともありオリンピックに向けて
リモートワークを段階的に試験導入する予定でした。
また、コロナ禍前は情シスとしてリモートワーク開始について反対の立場をとっていました。

反対した理由

当時でもリモートワークで業務出来る環境でありましたが
いくつか課題があり中々、賛成する事は出来ませんでした。
代表的な理由としては・・・

  • 運用、緊急時のフローが無い
    リモートワークの運用フロー・ルールが構築されていない
    重大インシデント発生した際の緊急連絡フローが確立出来てない
  • ウィルス対策が脆弱
    コンシュマー版のウィルス対策ソフトを利用してましたが、リモートワークを実施するには強化すべき部分でした。 やはり管理コンソールが無い為、管理者として各端末の状況が把握しにくい部分が課題でした。
  • MDM(Mobile Device Management)導入して無い
    ウィルス対策の話と同様に端末の状況を一括で集中管理出来るソリューションが未導入

運用・緊急時のフロー等は社内で方針を決めるだけなので、直ぐに対応が出来る内容ですが
正直、セキュリティ周りをもう少し強化な環境に整えてから実施したいと言う思いでした。

真っ先にやった事 デスクトップ パソコンのリプレイス

緊急事態に付き兎に角、業務が出来る環境にすべくデスクトップPCのリプレイスに着手しました。 当然、パソコン無ければ仕事が出来ません。
当時、アルバイト・派遣社員が使用していた約20台程のWindowsデスクトップPCが
稼働中な為、直ぐにメーカーに連絡し、12~13台ずつ購入し3~4週間程で入れ替え完了させました。
キッティングに関し初めはイメージを作成しクローニングで対応も考えたのですが
作成・検証する時間も無かったのと、エニグモでは予めインストールするソフトも少ないので
人力による力技で対応しました。
2019年より少しずつノートPC化をしていたので、何とかなった感じです。

f:id:enigmo7:20201211170328p:plain
デスクトップPC リプレイス

WEB会議・問い合わせ対応

Zoomを導入しました。
実は運良くコロナ禍前から導入に向けて動いていました。
導入した理由としてはGoogle Workspace(旧称 G Suite)があるので
Google Meet利用出来ましたが、やはり大人数でのWEB会議はZoomの方が安定していたからです。
特にエニグモでは4Mと呼ばれる全体集会が月1回あるので、そこは重視しました。
また、仮想背景機能もあるので従業員のプライバシー保護の観点や
リモートコントロール機能もあるのが決定打でした。

Zoom導入前にトラブルサポート対応で解決までに3時間かかった事例があったので
この機能にはだいぶ助けられました。

Zoom対応ハードウェア DTEN導入

元々社長室・会議室にAppleTVが設置されておりプロジェクターを使用して
会議資料を投影してました。
MacはAirPlayを使用して安定的に投影出来ますが、Windowsの場合はAirParrot3と言う
シェアウェアを利用してましたが非常に動作が不安定と言う課題がありました。

プロジェクターを利用する際に部屋を暗くする不便さ、動作が不安定な課題を解決する為
Zoom対応ハードウェア DTENを1番大きい会議室と社長室に導入しました。 導入後はWindowsでも安定した投影が可能になりZoomRoomsアカウントで 無償アカウントユーザーでも時間無制限でWEB会議を利用出来るようになりました。
デメリットな部分としてはお値段が高いところでしょうか
個人的には気に入っているハードです。
当初は全会議室に導入しようとしていたので2台で止めといて良かったです。

f:id:enigmo7:20201211173357p:plainf:id:enigmo7:20201211173336p:plain
社長室と会議室

電話対応 fondesk モバイルチョイス050導入

コロナ禍と言えども会社へ電話が鳴る日々でした。
その殆どは業務と関係の無い営業電話や人材紹介の電話で月間300件程着信があり
主にバックオフィス部門にて全ての電話を受電し業務負荷が増え
電話対応する度に集中力が途切れて業務がままならない状況でした。
また、お客様の問い合わせについても迅速に対応出来ない事例も発生し
折返し対応するにも会社支給の携帯電話が無いので個人の携帯電話を利用する人も居ました。

そこで電話受付代行サービス fondeskを導入
導入後は会社代表電話番号をfondeskの番号へ転送し 転送先のオペレーターの人が一時対応し全て折返し対応となります。 対応内容はSlackにて投稿されるので、総務が内容毎に関係部署や個人へ共有する運用になりました。
導入後はオフィスが非常に静かになり、こんなにも効果があるものかと感心しました。

また、個人の電話対応として楽天コミュニケーションズのモバイルチョイス050を導入しました。
導入後は個人スマホに050番号を付与する事が出来るので、折返し対応時にプライベートの番号が伝わる事が無い様になりました。 メリットとしては簡単にBYODを導入出来る、データ通信ではなく音声回線を利用しているので音質が安定しているのが良い部分だと思います。

FAX対応 メール送信&Slack連携

電話の次に対応したのでFAXです。 レガシーなシステムと言えども銀行やカード会社のやり取りで使用する為、 何かしら対応が必要になりました。

弊社のFAXは複合機で送受信を行っているのですが 仕様を確認したところ受信したFAXをメール送信出来る機能があり直ぐに設定 メール送信されたものはzapierを経由しGoogleドライブ(共有ドライブ)へ保存され受信した際にSlackへ通知されるようにしました。

ただ、この構成で欠点があります。 複合機のFAXメール送信機能は用紙切れになるとメールが送信出来ない仕様でした。 ここは盲点でした。

f:id:enigmo7:20201211181155p:plain
FAXの構成

冒頭でも触れたウィルス対策

リモートワークを始めるにあたり絶対にウィルス対策(エンドポイントセキュリティ)の強化は最低限譲れないと思ってました。 そもそもWindowsNortonMacはESETとOS毎に違っている。 しかも、コンシュマー版を利用している状況 Excelでシリアル番号とインストール端末を管理すると言う運用

この状況を打破する為、CrowdStrikeを導入 念願のEDRを導入する事が出来ました。 展開が終わった時は達成感が凄かった・・・・ 何と言っても管理コンソールの存在に感動、アラートが飛んでくる頼もしさ、勝手にアンインストールされない安心感はプライスレス。

ちなみに導入直後に管理コンソールにログイン出来ない事象がありました。 原因はセカンダリ環境にCrowdStrikeが構築されログインURLが通常と違っていたのが原因でした。
(後日談としてESETのアンインストールを社内にアナウンスしたら、みんな光の速さで削除してました・・・)

まとめ 2021年へ

その他にも実施した事もまだあるのですが、今回書くことが出来ないのでいつかタイミングあれば書いてみたいと思います。 情シス視点での福利厚生制度を作ったり社内イベントをやったりしました。

今後リモートワークを核としたワークスタイルへの移行にむけてオフィスをリニューアルする予定で、 そこに向けて色々と動いています

  • サーバールーム移設対応
  • 社内ネットワーク対応(有線・無線)
  • 電話回線周り(光収容化・Dialpad導入)
  • インターネットFAX導入
  • 受付システム導入
  • 入退出システム導入
  • 座席予約システム導入
  • AV機器周り対応

また、4月にokta導入が決定しました! 出来たら来年こそはMDMを構築したいと思ってます。

では、以上になります。 ありがとうございました。

明日の記事の担当は 出品審査担当 の 杉山 さんです。お楽しみに。


株式会社エニグモ 正社員の求人一覧

hrmos.co

リモートワーク文脈で超低コスト擬似DNSを社内で提供しました。

こんにちは、インフラチームの加藤です。

この記事は Enigmo Advent Calendar 2020の23日目の記事となります。
本記事では、リモートワーク環境のため、擬似DNSを社内提供したお話をします。

エニグモでは、今年の2月頃から全社的にリモートワークを開始しました。
それに伴いインフラチームでは、リモートワークのネットワーク周りの対応を行いました。


エニグモが運用しているサーバ群

エニグモの運用するサーバは、データセンター内に構築したものとAWSのものがあります。
情シスの足立さんが、SaaS導入を進めて下さったためオフィス内にサーバはほぼありません。

サーバへの疎通経路

オフィス・リモート環境共にVPN経由(+ファイアウォール)で、サーバ群へアクセス可能です。

f:id:enigmo7:20201221131920p:plain


リモートワーク開始後のサーバアクセスの問題

リモートワーク開始直後から、ネットワーク設定に関するお問い合わせと、インフラチームの対応が発生しました。VPNWifiの設定など、個々人のネットワーク設定の問題は、一度解決すれば再発することは滅多にありませんでしたが、名前解決は、何度もお問い合わせが頻発する厄介な課題でした。

なぜ、名前解決がリモートワークの課題だったのか

コロナ禍以前
エニグモでは、オフィス環境からサーバへのアクセスを楽にするため、ファイアウォールでオフィスのグローバルIPを許可し、非エンジニアスタッフの使用するサーバへはサーバのグローバルIPを指定してアクセス可能にしていました。

f:id:enigmo7:20201221132000p:plain

名前解決がリモートワークの課題となった原因
リモート環境からサーバへは、VPN経由でサーバのローカルIPを指定してアクセスする形でした。そのためオフィスとリモート環境では、サーバのアクセス情報が異なりました。

整理すると、以下の形になります。

職場 アクセス元のIP アクセス先のIP
リモート環境 スタッフのお家 サーバのローカルIPを指定
オフィス オフィスのGIP サーバのグローバルIPを指定

リモートワーク開始直後は、採用や営業活動、検品作業のため出社が必要なスタッフも居て、シフトで出社日を回していました。出社したスタッフは、Hostsを社内用に修正せねばならず、名前解決関係のお問い合わせが継続していました。DNSを導入すべきでしたが、工数がかかり難しいところでした。

f:id:enigmo7:20201221132042p:plain

名前解決の課題を解決

Hostsを一元管理できないかと思案していたところ、SwitchHosts!を発見し利用することにしました。

f:id:enigmo7:20201221132126p:plain

SwitchHosts!とは

Hostsファイルのサーバ管理が可能になる、端末のアプリです。
開発者は、サーバからHostsファイルをダウンロードして端末で使用する形となります。

f:id:enigmo7:20201221132146p:plain

SwitchHosts!のよかったところ

  • 無料公開されているアプリケーションだったこと。
  • 配布元にリモートサーバが使えて、Hostsファイルを集中管理できたこと。
  • Mac/Windowsでも、同じUIで使えてサポートし易かったこと。
  • HostsのパーツごとのON/OFFができ、localでHostsを修正できて組み合わせられること。
  • 端末のHostsのバックアップが取れること。 f:id:enigmo7:20201221132237p:plain

SwitchHosts!を使用した、擬似DNSの運用

ユースケースに合わせたHostsファイルを作成し、データセンターにNginxコンテナを立てて配布できるようにしました。 これにより、オフィスでもリモート環境でも、簡単にDNSの機能を提供できるようになりました。

f:id:enigmo7:20201221132221p:plain

SwitchHosts!導入後の課題と解決方法

SwitchHosts!の導入後、名前解決が原因となる問題はさっぱりとなくなりました。
しかし「AWS環境における開発に伴い、Hostsの修正が都度必要になる」という課題が残りました。

  • 原因は、以下2つでした。
    • スポットインスタンスのマシンが再作成された際、Hostsの修正が必要だった。
    • AWS環境に、日々サーバが増設されるため、Hostsに追記が必要だった。

一時は、ダウンロード元のHostsファイルを手動で修正していましたが、無駄な作業でした。
そこで、Hosts情報の更新スクリプトを作成し、Hostsファイルの自動更新を実現しました。


#AWSのマシンには、${Prefix}タグと${Name}タグに、
#マシンのAZやサイト環境を命名規則として持たせています。
#!/usr/bin/env ruby

require 'aws-sdk-ec2'

ec2_client = Aws::EC2::Client.new()

#ARGVに、${Prefix}タグの値(マシンのAZやサイト環境を命名規則としたもの)を持たせています。
Prefix_list = ARGV

f = { filters:[{ name: "tag:Prefix", values: Prefix_list }]}
reservations = ec2_client.describe_instances(f).inject([]) do |s,list|
  s += list.reservations
end
instances = reservations.each.inject([]) do |s,list|
  s += list.instances
end

instance_list = []
instances.each do |e|
  instance_list << {
    :instance_id => e.instance_id,
    :vpc_id => e.vpc_id,
    :public_ip => e.public_ip_address,
    :private_ip => e.private_ip_address,
    :name_tag => e.tags.find{|t| t.key == "Name"}.value,
    :prefix_tag => e.tags.find{|t| t.key == "Prefix"}.value.downcase,
  }
end

instance_list.each do |e|
  hostname = e[:name_tag].downcase

  #あとは、環境に合わせてよしなに加工してHostsファイルに出力します。

end

まとめ

DNSの機能を低コストで提供できてよかったです❗️
VPNへの依存度も減らしたいので、Google IAPを検証中です。
同じインフラチームの先輩社員 山口さんが、記事にされていました。
old schoolerなネットワークエンジニアがIAP Connectorを試してみた - エニグモ開発者ブログ

最後に

明日の記事の担当は、情シスの足立さんです。お楽しみに。

株式会社エニグモ 正社員の求人一覧

hrmos.co

今年組織作りに貢献するためにやったこと

今年組織作りに貢献するためにやったこと

こんにちは。アプリケーション開発グループの穴澤です。

この記事は Enigmo Advent Calendar 2020 の 22 日目の記事です。

今年の振り返りとともに主に自分が去年から今年にかけて中途で入社した方にやってきたことを書いておきます。 これからチームに新しい人を迎える人や、中途採用入社する方、チームの組織づくりに興味がある方に読んでいただければとおもいます。

実際に取り組んだこと

  1. オンボーディング資料
  2. 開発手法、フロー・チェックリストの読み合わせ
  3. 1on1

1.オンボーディング資料

f:id:enigmo7:20201209113806p:plain

エニグモでは部署問わず、今年から中途で入社した社員向けのzoomでのオンボーディングが開始されました。 簡単にいうと、「各事業部が具体的になにをやっているか」「どんな取り組みをしているか」を中途入社した方に説明します。 入社された人は部署ごとに数回に分けて参加しています。

思えば今年の早い段階からリモートワークが推奨された状況で、中途入社問わず、自分の所属する部署以外の方と顔を見合わせて話をする機会というのが極端に減りました。例えば「先月入社した方ですね、XX部署のXXです!」といったようなコミュニケーションも、廊下やエレベータで顔をあわせたり、ミーティングの終わりですれ違う、お手洗いで顔を合わせるなどのタイミングで行われてきました。それぞれを取るととても些細なことですが、これらを積み重ねた何かが会社の社風や文化を醸造する一部になっていたんだなと感じます。

社風や文化をオンラインでも実現するために、このオンボーディング時に自分が紹介する担当として実践していることは以下の点です。細かい箇所は割愛しますが、リモートワークならでは、でしょうか。

  • 説明資料に自部署の社員の氏名とSlack名の紐付け(顔とアイコンと名前とSlack名が一致しない問題)
  • アプリ、インフラ、データ基盤、それぞれについての相談相手としてまずは覚えておいてほしい人をエピソードを添えて紹介(そんなに色々紹介されても覚えられない問題)
  • BUYMAの仕組みで聞きたいこと、相談したいことがあったら、ここで相談してね、のチャットの紹介(何かを相談したくなってもどこだかわからない問題)
  • 参加してくれた方とサービスエンジニアリング本部との具体的な関わり(紹介してもらったけど具体的にどういう関わりがあるんだろう問題)

2.開発手法、フロー・チェックリストの読み合わせ

f:id:enigmo7:20201209112322p:plain

BUYMAというサービスが産声を上げて10年以上たちます。尖った技術を使っているところもあれば枯れているところ、 やや温かみのある仕組みのところもあり、中途で入社するエンジニアの方が躓くところもあるため、主に若手の方対象に週1回程度開発やリリースの際に 気をつけてほしい点をesaにまとめたフロー・チェックリストの読み合わせを行いました。

基本的に開発に関わる問題点は、所属しているチームのリーダーやメンターが答えてくれますが、彼らに一点集中よりも、誰にきいても答えてもらえる、誰にきいても大丈夫、という雰囲気作りに自分も貢献したかったからです。ましてや、自分の所属するチーム以外のエンジニアと、躓きや悩みを共有する場所はいくつあってもいいと考えています。 時には検索エンジンチームのエンジニアをゲストに迎えて検索周りの説明をしてもらったり、チェックリストについては実際トラブルに遭遇したエンジニアに「なぜこのチェック項目があるのか」というのを語ってもらいました。

3.1on1

1on1は前職でも取り組んできたことですが、今年特に自分が取り組んできたことをあげます。

アジェンダを用意する

序盤はなかなか用意できませんでしたが、後半は実施の1,2日前にいくつかアジェンダを用意するようにしました。 4,5つ用意してその中のトピックで話が広がれば盛り上がり、割愛してできるだけ「話が盛り上がる」「相手の指向性、興味関心がわかりそう」な所を意識してすすめていきました。

1on1は「・・・最近どうですか」というやり方もありますが、1on1を実施するメンバーの身になって考えてみると 「なにを話せばいいんだ」「なにを言われるのか」と身構えられてしまうこともあります。明日はこういう事を話そう。を用意する方が 時間も有意義ですし、もしネガティブな話をされるということが事前にわかっていれば、自分が言いたいことも事前に用意するなど、お互いに準備ができ、結果的に少しの準備で得られる物が大きいと感じました。

会社全体の動きがわかるトピックをアジェンダに混ぜて話す

メンバーの仕事や取り組みと直接関係のない、会社の動きや施策。最近の売上。他部署に入社した人のこんなところが凄いなど。 会社の中での私達の部署の動き、施策以外の取り組みや課題など、自分と会社をつないでいる環境にどんなものがあり、どんな動きをしているか。中途入社の序盤だと、見えにくい組織の動きを定期的にアジェンダに混ぜて話をするようにしています。

  f:id:enigmo7:20201209112739p:plain

まとめ

今年は、いつもやっていること+αの「工夫する」注力をしました。特に、コロナ禍のリモートワークで感じやすい「孤独感」を和らげるための「皆さんは一人ではないですよ」ということを伝えるために、様々なできることを模索した年だった様に思います。取り組みの結果を定量的にはかることはできないので難しいですが、フィードバックを受けながら、来年も少しずつ改善していきたいと思います。 よいお年を。

明日の記事の担当は インフラグループ の 加藤 さんです。お楽しみに。

株式会社エニグモ 正社員の求人一覧

hrmos.co

データアナリストが転職活動で求めたこと

こんにちは、データアナリストの田中里澄です。
エニグモではデータ活用推進室という部署に所属しており、主に他部署が行った施策の効果検証を担当しています。

私は2020年11月にエニグモに入社したので、今回はその転職活動の中でどうして今の職を選んだのか、また入社後どのような仕事をしているのかを紹介できればと思います。
前職はライブ配信サービスを運営している会社で、同じくデータアナリストとして働いていました。
転職理由について前職に対してネガティブなことは一切なく(むしろ今も大好きな会社です)、今の自分は別の会社で経験を積んだ方がいいと判断したためです。

なぜこの内容を書くのか?

理由は社外の方向けと社内の方向けでそれぞれあります。

  • 社外の方にはデータアナリストの転職活動の参考にしてもらいたいため

  • 社内の方にはまだ入社して日が浅い私の自己紹介になるためです。転職活動だけでなく、自分がどんな仕事をできるか/したいかについても書いています。

そもそもデータアナリストとは?

ここであくまで自分の考えにはなりますが、データアナリストとはどんな仕事をするのか?を説明します。
読んでくださっている方に知っていただきたいですし、私が転職活動をしたときにも実際に自分の中で整理しました。
その整理のおかげで、無数にある求人(特にデータ〇〇という職種は最近多い)の中でピックアップする際や、面接時に自分がしたいことを説明する際に役立ちました。

データアナリストがどんな仕事をするのかを一言で表すと、「意思決定に必要な情報/インサイトを提供する仕事」だと思っています。
データを分析する仕事じゃないの?という意見もあるかもしれませんが、分析はあくまで手段であり意思決定をすることが目的だと考えているのでこのような書き方をしました。
もしかするとコンサルという職種でイメージされる仕事に近いかもしれません。(余談ですが、思考法を勉強するためにコンサル向けの本を読むこともあります)
逆にいうと、こういった仕事をする人のことを「データアナリスト」と定義している会社が多いとも言えます。(本質的にはこちらが正しいかもしれません)

どんな会社を求めていたのか?

上記で書いたデータアナリストとしての仕事ができることはもちろんですが、さらにそれを具体化した自分のしたい仕事について2点、またそれに関連した仕事の環境について2点合わせて4点求めていることがありました。

どんな意思決定に携わりたいのか

意思決定にも長期的な経営に関するものや日々のオペレーションに関するものなど色々な種類があります。
その中でも私はプロダクトの改善に関する意思決定に携わりたいと考えていました。
なぜならユーザーに喜んでもらえることに直結して実感しやすく、また分析するなかで人がどんな考えで行動するのかを垣間見ることができるためです。

どんなデータを分析するのか

データは大きく分けると定量と定性の2種類に分けることができますが私はその両方を用いて分析したいと考えていました。
特に定量的なデータだけを扱うことが求められる場合もありますが、ユーザーの行動理由を知るためにはそれだけでは分からないことがたくさんあるためです。

他の職種(特に意思決定者)との連携が取りやすい

上の方で書いていたデータアナリストの仕事内容を遂行するためには他の職種の方との連携が大切です。
その中でも特に最終的に意思決定をする方との連携がとても大事だと考えていました。
分析をする前にはどんなことが分かれば意思決定ができるかを摺り合わせ、分析後にはそこで分かったことを共有し議論することで意思決定に付き添うためです。

分析をするためのデータ基盤が整っているか

整っているという言葉が曖昧ですが、例外はあれど日々の分析をする際の前処理やデータの準備に自分の持っているスキル以上のことを求められないことが基準でした。
もちろん後々はデータ基盤の構築などのスキルも伸ばしていきたいのですが、それをすぐに求められて本当にやりたいことに時間が使えないのはしんどいので求める要件に入っていました。

実際に入社してみて感じたこと

最終的にエニグモ社に決めた理由としては、上記の求めていることを全て満たせていると選考中や内定をいただいた後の面談で感じたからです。
ここでは入ってみて実際に感じたことを紹介します。

  • 分析結果を共有する際に、集計結果だけでなく考察やネクストアクションも求められまた歓迎されていい。
  • 求めていた意思決定者との連携について、非常に取りやすいので分析の方針を立てやすい。
  • データ分析基盤について、基本的に必要なデータがBQにあって扱いやすい。ただし、それぞれのテーブルの定義などがわからないところやGAのデータについての扱い方を調べる必要があったりと、データはあるが扱い方は聞いたり調べたりが必要なので、今後入ってくる方のためにまだまだ整える余地がある。

入ってからどんな仕事をしているか

主に2種類の施策の振り返りとアプリの分析方針を立てる仕事をしています。

施策についてはどちらも私が入社する少し前から始めていたもので、毎月改善を加えてやっていこうという前提のものでした。
なので振り返りでどんな数字を見るのか?というところから任せてもらい、翌月の改善点の提案を出すところまで行っています。

アプリの分析方針については、私が入社するまでは売上というKGIを追いつつ、KPIとして何を追うべきかについて試行錯誤をしていたという状況です。
そこで今後追うべきKPIについて決める仕事を担っており、今は私の提案を元に議論しています。

総じていうと、現在自分のしたいと思っていた仕事ができており今後もまだまだやりたいことが溢れています。
コロナ禍で入社後のコミュニケーションは以前と比較すると難しいなとは感じておりますが、より一層迅速で納得感のある意思決定に貢献できるように日々の業務に努めていければと思っています。


株式会社エニグモ 正社員の求人一覧

hrmos.co