ホーム ブログ ページ 5

「デザイナーに寄り添って話を聞きたい」山田 有里沙インタビュー

0

ゲームグロース部で部長代行としてチームをけん引する山田は、2Dデザイナー出身です。今も現場でプレイヤーとして活躍しつつ、後進の育成をしています。「私は“外に向かってグイグイ行くぞ!”ってタイプじゃないんです」と言いつつも、ある局面では「プレッシャーを感じない」そうで……? 仕事をするうえで大切にしていることを教えてもらいました(取材 2022年12月)

式姫Projectに惹かれて入社

ーー 2017年に新卒のデザイナーとして入社されていますよね。アピリッツを選んだ理由を教えてください

アピリッツの自社IP「式姫Project」に惹かれたことが一番の理由でした。就職活動中に企業研究の一環で式姫のポータルサイトを見たり実際にゲームをプレイしていたのですが、他ではあまり類を見ない筆タッチの特徴的なイラストや、ドット絵、それから華やかなドット絵のアニメーションに魅せられてしまい……。すっかり式姫Projectのファンになりました。今も変わらず大好きで大切な作品です。

アピリッツに入社して、式姫Projectのチームに配属されました。大好きな式姫とお仕事で関わることができたのは、とても幸せな体験でした。今開発中の新作も、いちファンとしてドキドキしながら楽しみに待っています。

ーー 女性管理職が増えてきていますよね。アピリッツのゲーム開発の現場は働きやすい環境だと感じますか?

働きやすいです。とくにデザイナー職の方は温厚で優しい人がとても多いなと思います。

新卒からずーっとアピリッツにいるので「他社と比べてココがいい!」っていう特徴は、私からはちょっと言えないんですが、フレックスタイム制を活用すると通院もしやすいですし、育児休業や産休制度を取得している人を多く見かけます。男性の育児休業も最近は増えていますし、いい環境だなと感じます。

性別によって働き方や仕事内容に差を感じたこともないので、私にとって働きやすい会社です。

―― 入社してすぐの頃と現在とを比べて、何か変化はありますか?

入社したばかりの頃は、自分が新人だったこともあって、先輩に声をかけるのに勇気がいりました。社内の雰囲気もすこし緊張感があったような気がします。

今は、社内は程よく柔らかい雰囲気になったかなと思いますし、自分でも積極的に動くようになりました。

―― 積極的に動くようになったきっかけは?

デザイン業務の管理を任されるようになったからです。デザイン制作の最後のゴーサインを出すのが私の役目になりました。もともと社員にチャレンジをさせてどんどん任せる社風ですし、任されたからには、もうやるしかなかった(笑) 最初は不安でたまらなかったです。

「雑な仕事」はユーザーに必ず伝わる

―― 「最終判断を自分で出さないといけない」ことにプレッシャーを感じる人も少なからずいますよね

いますね。ただ、私は自分で責任を負って最終判断を下すこと自体は、しんどくなかったんです。大学生のとき、フリーランスのイラストレーターとして活動していたので「自分の制作物がユーザーの目に触れる」ことに慣れていたのもあるのかもしれません。

それに、ユーザーがゲームに没入できるよう、粗のないグラフィックを制作することはデザイナーにとって大切なことだと思っています。だから、そこは責任持ってちゃんとやろう、って思って動いていました。雑な仕事はユーザーに必ず伝わってしまうものですし、あってはいけないことなので……。

―― デザインの管理をしながら自分でもプレイヤーとしてデザインの仕事をしていますよね。最初から両立はできましたか?

最初は難しかったです。チェックだけをずっと続けていたら1日が終わってしまって「自分が作業する時間が取れない……!」って焦ったこともありました。この時期は精神的にしんどかったです。絵をチェックするスキルや「デザインを見る目」が成長している実感はあったけれど、じゃあ自分の絵の技術はどうなんだろう、上がったかな、ちゃんと自分でも作れるのかなって不安でした。

アピリッツの広報キャラクター「山田アイコ」は山田がデザインしました(だからアイコの名字も山田なのかも?)

―― その「管理職兼デザイナー」としての不安や葛藤はどうやって克服したのでしょう?

毎日デザインの管理業務をやっていくうちに、少しずつ慣れて、効率化できるようになりました。作業を少しずつメンバーに振り分けて、自分でもデザインをしてみたり。

それに、人のアウトプットを見るのは、基本的にとても好きなんです。「そのアプローチは思いつかなかったな」など、日々刺激を受けています。

あと、社会人になってからもプライベートでの制作はずっと続けてきました。これも精神衛生上、すごく効果的だったと思います。社会人になると、個人で制作する人は減っちゃうんですが、趣味の制作は続けたほうがいいです。とくにデザインを仕事にする人にはオススメします。

そしてなにより、私が今こうしてがんばれているのは、いいメンバーに恵まれて励まされてきたことも大きいです。私が別のプロジェクトに異動するときに、私の仕事を引き継いでくれた新卒デザイナーの鈴木もすごく頑張ってくれたと思います。

デザイナー同士でどんな話をする?

ーー 山田さんのマネージャーとしての面について、教えてください。アピリッツでは1on1の文化がありますよね、どんなことを伝えていますか?

まずは、どんな対話の場でも「私はあなたの味方だ」とわかってもらえるように努めています。これは私が実際に本心から思っていることなので、伝わっているといいなといつも思います。

私自身、怒られたりキツい態度をとられるのが昔からすごく苦手なんです(笑) だからこそ自分が伝える側になった今は、やわらかな物腰を心がけています。

最近の1on1では、将来のキャリアプランや、それを実現するためにどうすればいいかといった目標の話をすることが多いです。私はアピリッツでの勤続年数が長いですし、今までの経験がメンバーと話をする上で役に立っていますね。

―― 2Dデザイナー出身の管理職として、どんな話をしていますか?

2Dデザイナーに求められていることは、今も昔も変化はあまりないかもしれません。正社員であれば、アセットの品質管理やディレクション能力は必要です。そしてエフェクトやモーションなど、イラスト以外で強みになるスキルを持つことが求められています。

たとえば、UI/UXができる2Dデザイナーは市場価値が高いです。とはいえ、2Dデザイナーになりたい人のモチベーションって、最初は「イラストがうまくなりたい!」だったりするんですよね。私もそうです。でも、絵だけを書いている社員はいません。イラスト以外の強みを持つ必要があります。だから好奇心強い人が生き残れる。

入社当時は、とにかくいろんな分野の業務を振ってもらいました。そこでスキルを身につけられてよかったなと思います。新しいことを覚えるのが大好きなんです。

―― 「正社員のデザイナーになるには?」といった相談も受けますか?

受けます。相談へのアドバイスとして、まずはプロジェクトへの貢献意欲や、いろんなソフトを扱えることが大切だよと伝えています。あとは、先程もお話ししたように、好奇心を持って仕事に取り組んでほしいです。

―― ゲームグロース部をどんなふうに引っ張っていきたいですか?

デザイナーに寄り添って、適切な評価や配置ができる管理職になりたいです。デザイナー出身の管理職は今はまだ少ないので、まずは私がそこを担いたいなと思います。

部長代行になってからは、現場でプレイヤーとして活躍しつつ、2Dデザイナーの育成に力を入れるようになりました。最近の1on1では、2Dデザイナーとじっくり話す機会がとても増えて、デザイナー同士で話すからこそできることについて考えるようになりました。

打ち明けてもらった悩みに耳を傾けて、力になれることがあると信じています。だから「私はあなたの味方だ」ってわかってもらうことは、私にとってとても大切なことなんです。

そうやってまずは内部の環境をよりよくすることに力を尽くしていきたいです。

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

Looker Studio(旧:Googleデータポータル)で用いる図・グラフの特徴とポイント!

0

【はじめに】

デジタルエクスペリエンス部_GAチーム所属の富浦です!
デザイン制作チームから2022年の春にGAチームに異動してから、データに触れる機会が以前よりかなり多くなりました。特にLooker Studio(旧:Googleデータポータル)を用いてデータを図・グラフ化する機会が多いです。

今回はLooker Studioで用いる図・グラフの特徴と表示時のポイントについてご紹介していきます!

2022年10月11日に「Googleデータポータル」は「Looker Studio」に改称されました。
参考:https://cloud.google.com/blog/ja/products/data-analytics/looker-next-evolution-business-intelligence-data-studio

【本題】

1. 棒グラフ

■特徴
項目毎の数値を棒の長さで表したグラフ。項目毎の量を把握できます。

■表示時のポイント
①表示順
デフォルトは指標順となっているため値が大きい項目が左、小さい項目が右の降順に設定されています。例えば年齢別の場合は、若年層から昇順で配置した方が各年齢層の数値を分析しやすいため、その場合は並び替えの項目を「年齢」に変更し、「降順」から「昇順」に変更する必要があります。

②棒の数
デフォルトは「10」に設定されているため、項目が11以上の場合は設定を変更しないと表示されません。反対にTOP5を表示させたい場合は、棒の数を「5」に変更すると上位5つのみ表示されます。

③データラベル
「データラベル」を表示しておくと直感的に数値を確認することができます。

2. 折れ線グラフ

■特徴
項目毎の数値を線で繋いだグラフ。件数などの推移・変化の度合いなどを把握できます。

■表示時のポイント
①ポイントを表示
折れ線グラフはデータラベルを表示させると数値が重なって見えにくいです。Looker Studioはグラフをホバーすることで数値を確認することができるため、どこにホバーすれば良いか分かるように「ポイント」を表示しておくと親切です。

②色
各項目が近い色相やトーンだと見えづらいです。例えば性別毎の折れ線グラフであればイメージカラーに沿って青系統と赤系統にすると直感的に把握しやすくなります。

3. 円グラフ

■特徴
項目毎の占める割合を円盤状に表したグラフ。項目毎の割合を把握できます。

■表示時のポイント
①凡例
デフォルトは円グラフの右側に凡例が表示されています。スタイルの凡例から位置を「下」に変更することで、左右の余白をコンパクトに納めることができます。

②スライス数
表示される項目数が多いと割合が分かりにくくなるため、スライス数は「5個」程度にすると見やすいです。加えて色も境界線が分かりやすいように配色すると割合を把握しやすいです。

4. 帯グラフ

■特徴
帯状の中に項目毎の占める量を示したグラフ。項目毎の構成比の相違を把握できます。

■表示時のポイント
①データラベルの表示形式
表示するデータラベルを「数値」から「割合」に変更することで、より各項目の割合が直感的に分かるようになります。

5. 散布図

■特徴
2つの要素を縦軸と横軸にとり各データをプロットしたもの。データの分布状態や要素間の相関関係を把握できます。

■表示時のポイント
①データラベル
散布図はバブル数の量によって表示/非表示を選択する必要があります。大体10〜15程度でデータラベルが重なり見えにくくなるため、その場合は非表示がおすすめです。

②トレンドライン
トレンドラインを引くとデータの相関関係がより分かりやすくなります。

【まとめ】

◎各グラフのまとめ

No.図・グラフ特徴分析手法
1棒グラフ項目毎の数値を棒の長さで表したグラフ集計分析・対比分析
2折れ線グラフ項目毎の数値を線で繋いだグラフトレンド分析・対比分析
3円グラフ項目毎の占める割合を円盤状に表したグラフ構成分析
4帯グラフ帯状の中に項目毎の占める量を示したグラフ構成分析・対比分析
5散布図2つの要素を縦軸と横軸にとり各データをプロットしたもの集計分析・トレンド分析

◎各データ分析のまとめ

No.分析手法特徴
1集計分析データの分布状況や、平均値・ 中央値を集計し、分析する方法
2トレンド分析データを時系列に並べ、推移状況などを把 握し、分析する方法
3対比分析複数のデータを比較し、 その差異を把握し、分析する方法
4構成分析全体の中での構成要素の割合を 把握し、分析する方法

図・グラフは他にもヒストグラム、レーダーチャート、パレート図など様々あります。今回は良く使用する基本の図・グラフを紹介しましたが、データの性質や分析内容によって適切に使い分けることが重要です。今回ご紹介したポイントを押さえてデータ分析に役立てていただければと思います!

アピリッツでは、GA4導入をイチから支援するだけでなく、今回のようなGA4とのツール連携やABテストの運用、ECを含むWEB制作など幅広くサポートしています。WEBサービスでお困りの方や、ご興味のある方は遠慮なくご相談ください。

【GA4】経路データ探索を活用してCVに貢献したページを調べる方法

0

GA4を使い始めて「コンバージョン(CV)したユーザーが閲覧したページ(コンテンツ)を知りたい」
そう思ったことはありませんか。
おそらくそのように思われた方は「CVしないユーザーにそのページのコンテンツを接触させればCVするのではないか」という仮説があるのでしょう。
そのような方に朗報です!GA4の経路データ探索でそれを簡単に実現できるようになりました!

あ、どうも申し遅れましたyサイトーです。最近はGA4導入やWEBマーケティング支援をしております。
つい先日、GA4の経路データ探索の機能がアップデートされ、冒頭に挙げたようなことが簡単にできるようになったので、今回はその方法をご紹介していきたいと思います。

本題に入る前に簡単に経路データ探索について説明しておきます。

経路データ探索とは

経路データ探索とはGA4のデータ探索レポートのテンプレートの1つで、ユーザーの行動をツリーグラフで可視化するレポートです。
Universal Analytics(UA)を利用されている方でしたら、行動フローと似たようなものと思ってもらえればイメージしやすいと思います。

UAの行動フロー

経路データ探索自体は今までもGA4にあったのですが、ディメンションのラインナップが3つ「ページタイトルとスクリーンクラス」「ページタイトルとスクリーンクラス」「イベント名」しかなかったのです。
今回それに「ページパスとスクリーンクラス」が加わったことで、CVしたユーザーが閲覧したページを調べやすくなりました。
それではCVユーザーの閲覧したページを調べてみましょう。

CVユーザーが閲覧したページを調べる6つのステップ

  1. データ探索を開き、空白を選択
  2. 手法を経路データ探索に変更
  3. 最初からやり直すをクリック
  4. 終点を「ページパスとスクリーンクラス」にする
  5. CVページのパスを設定
  6. ステップを追加

1. データ探索を開き、空白を選択

まずはGA4の左メニューの探索をクリックして、データ探索のテンプレートを「空白」を選択してください。
※この時点で経路データ探索を選択しても良いのですが、不要なセグメントやディメンションがデフォルトで入ってしまいます。

データ探索のテンプレート一覧

2. 手法を経路データ探索に変更

自由形式のレポートが表示されたら、手法を経路データ探索に変更します。

3. 最初からやり直すをクリック

UAの時の行動フローのような図がデフォルトで出てくるかと思いますが、CVからの行動を追っていきたいので、画面右上にある「最初からやり直す」をクリックしてください。

4. 終点を「ページパスとスクリーンクラス」にする

終点と表示された部分をクリックして「ページパスとスクリーンクラス」を選択してください。

5. CVページのパスを設定

画面右の方に虫眼鏡のボタンをクリックして、出てきた検索欄にCV(完了)ページのURLに入る文字列を入れて、ページパスを検索してください。
多くの場合、CV(完了)ページのURLにはcompleteやthanksといった文字列が入るので、それらで検索して、出てきた候補リストからページパスを選択してください。

6. ステップを追加

CVのステップを選択すると、その1つ前のステップが出てきます。
その1つ前のページを知りたいページパスをクリックすると、その1つの前のステップがまた出てきます。
このようにして、CVしたユーザーがページを見ていたかCVから逆に遡って追うことができます。

まとめ

経路データ探索を実際に設定して気付いた方もいらっしゃるかもしれませんが、実はCVしたユーザーの行動をCVから遡ることは以前から可能でした。但し、CVしたユーザーを計測する為のイベントを設定したり、ページタイトルから遡る必要がありました。
とりあえずGA4のタグは入れてあるという方でも、今回の方法なら分析は容易ですね。

今回のように「GA4導入は済ませたものの使い方がわからないからセミナーを開催してほしい」

代理店の方で「お客様のGA4導入をサポートしてほしい」

など、幅広いお問い合わせに柔軟に対応しております。GA4に関するお困りごとがございしましたら、まずはお気軽にご相談ください。

Looker Studio(旧:Googleデータポータル)をより見やすくする7つのポイント!

0

【はじめに】

デジタルエクスペリエンス部_GAチーム所属の富浦です!
2021年にデザイナーとして入社し、主にデザイン案件のディレクターを1年間勤めました。その後当時在籍していたデザイン制作チームから2022年の春にGAチームに異動して半年が経ちました!
同期や先輩方に助けられながら、業務にも少しずつ慣れてきたかなと思います。

今回はGoogle Analyticsなどで計測したデータを簡単にグラフや表にして視覚化するBIツール、Looker Studio(旧:Googleデータポータル)をご紹介していきます!

2022年10月11日に「Googleデータポータル」は「Looker Studio」に改称されました。 
参考:https://cloud.google.com/blog/ja/products/data-analytics/looker-next-evolution-business-intelligence-data-studio

Looker Studioは定量分析用のレポートを作成する上でとても便利なツールではありますが、UIについてはまだまだ発展途上のツールだと感じています。だからこそ、いくつかのポイントを抑えてから使用することで作業しやすくなるだけではなく、簡単に見やすく使いやすいレポートを作成することができます!

今回はLooker Studioでより見やすく使いやすいレポートを作成する上で事前に知っておきたい7つのポイントをご紹介していきます!

【本題】

1. グリッド表示

Looker Studioでデータを視覚化しても、バラバラに配置されていては見にくいです。そんな時にはグリッドを使って整えることがおすすめです。

▼設定方法
テーマとレイアウト内のレイアウトタブから配属先を「グリッド」に変更し、グリッドのサイズを「50」から「10」に変更します。次に全体共通タブの「表示」から「グリッドを表示」にチェックを入れることでレポート上に10px単位のグリッドが表示されます。

2. タブ表示

レポートの全体が見えるように作成するためにはスペースを少しでも広く確保する必要があります。ページ切替のタブを上部に配置することで無駄なスペースを軽減することができます。

▼設定方法
テーマとレイアウトからナビゲーションの種類を「左」から「タブ」に変更すると、上部にタブが配置されます。

3. 背景色

各グラフは基本的に白背景がベストですが、レポート全体の背景色が白のままだと背景が同化してしまいます。そこで背景色に薄いグレーを引くことでグラフがくっきりと見えます。

▼設定方法
テーマとレイアウトからカスタマイズを選択し、レポートの背景を右上の白から一つ隣の「薄いグレー」を選択することで、レポートに薄いグレーの背景色が適用されます。

4. パディング

テキストには自動で左右と上部に8pxのパディングが設定されています。デフォルトのパディング設定のままだと、上下左右を揃えて配置することが難しいため適宜調整する必要があります。

▼設定方法
テキストを選択し、テキストのプロパティ内にあるパディングから「左、右、上の数値を調整」します。下記の図では、テキスト下のスコアカードと左を揃えるために左のパティングを「0px」にしています。また、テキスト横のプルダウンリストと中心を揃えるために上のパディングを「4px」に設定しています。

5. シャドウ

背景色と明度差を付けると各グラフがくっきり見えますが、シャドウを設定するとさらに各グラフをくっきりと見せることができます。

▼設定方法
各グラフのスタイル内にある背景と枠線から「枠線に影を付ける」を選択することで、グラフにシャドウが付与されます。

6. 円グラフ

円グラフは指標の項目名を表示させることができないため、そのまま配置すると何の割合なのか分かりづらいです。
そこで見出しを付ける必要があります。ドーナツ型の円グラフにして中央にテキストを配置することでスペースを有効活用できます。

▼設定方法
円グラフのスタイル内にあるドーナツ型のイラストから「穴のサイズ」を調整します。そして空けた「穴の中にテキスト」を配置します。その際は全体共通タブの「配置」から「中央揃え」などを選択すると簡単に揃えることができます。

7. 表

表は複数のディメンションと指標を設定できるため利用シーンも多いです。背景色とシャドウの設定に加えて、ヘッダーと行に背景色を付けることでさらにデータが見やすくなります。

▼設定方法
グラフを選択し、スタイル内の「表の色」を変更します。ヘッダーの色を任意のメインカラーに設定し、偶数行の色をレポート背景色と同じ「薄いグレー」に設定することで表に反映されます。

【まとめ】

Looker Studioを導入することで、定期的な集計データの分析が効率よく行えます!レポートを使いやすくすることでより効率良く定量分析が行えますので、是非今回ご紹介した7つのポイントを取り入れてレポートを作成いただければと思います!

アピリッツでは、GA4導入をイチから支援するだけでなく、今回のようなGA4とのツール連携やABテストの運用、ECを含むWEB制作など幅広くサポートしています。WEBサービスでお困りの方や、ご興味のある方は遠慮なくご相談ください。

新卒1年目におけるGoogleアナリティクスの学び方

0

新卒7か月目のWebアナリストです!

2023年7月1日に計測が停止するUA(Universal Analytics)と2022年10月1日にリリースされたGA4(Google Analytics4)を活用して、データ分析や解析基盤構築をしています。

今回は未経験で入社した私が、UAとGA4をマスターするにあたり、学び、実践したことをご紹介します(^^)/

これからご紹介することは、Google Analytics未経験の方でも取り掛かりやすい内容となっておりますので、気軽に読み進めていただければと思います。

Google Analytics(通称GA)を一言で説明すると、

「Webサイトへのアクセス状況をさまざまな視点から分析することができる解析ツール」です。

例えば、ユーザーがどのページを閲覧し、どのページでWebサイト内からいなくなってしまったのかなどの行動を知ることができます。

UAとGA4では根本的な計測ロジックが変わり、クリック一つで設定・計測できるようなイベントが加わるなど大きく進化しました。

来年夏以降はUAの計測が停止するため、特にGA4の勉強を中心に学習を進めました。

①用語調査で「Google Analyticsの基礎」を学ぶ

まずは「Google Analyticsで何ができるのか」を理解するために、会社にある参考書やネットを活用して勉強をしました。

勉強を進めていくうちに不明な用語が増えてきたため、方針を変え、出てくる用語を徹底的に調べることにしました。また、調べて学んだことのアウトプットの場として、チームメンバーに発表する場を設けていただきました。

先輩方に発表するのは少し緊張しましたが、そのプレッシャーによって調べたことへの理解度が深まった気がします。

用語調査によって得た知識を活かし、次にGoogle Analyticsへの理解度の確認として「GAIQ取得」を目指しました。

          

②入社1ヶ月でGAIQ取得を目指す

GAIQとは、Googleが実施している「Google Analyticsの理解度をはかる」オンラインの認証試験のことです。なんと無料で何度でも受けられます!

いいスタートを切るためにも、1か月以内の取得を目標としていました。

入社してあっという間に1週間が過ぎ、少し焦りを感じ始めました。無料且つ何度でも受験可能であることから、腕試しとしてGAIQを受験しました。

案の定、見事に不合格でしたが、点数は100点中76点という悪くない点数でした、、(合格点は80点)

2週間前まで無知だった私でも、実際にGAに触れて、勉強するようになって、少しずつ身についてきている実感が湧いてきました。

試験内容が想定よりも幅広い分野に及んでいたので、勉強する範囲を広げ、4日後再受験し無事に合格することができました!

GAIQ取得までに学習した時間や活用したWEBサイトなどを記載しておきますので、これからGAIQ取得を目指す方はぜひ参考にしてください(^^)/

勉強日数・8日間

勉強時間・約40時間(5時間×8日)

★私が活用したサイト↓

■【保存版】Google Analytics基本用語集【まとめてみました】

https://awe-some.net/2017/04/google-analytics-basic-word/

■Googleアナリティクスとは/衣袋教授のGoogleアナリティクス入門講座 コーナーの記事一覧

https://webtan.impress.co.jp/l/6342

③学習環境を作るべく実践したこと

GAIQの取得も完了し、少しずつ実案件に携わることが増えていく中で、先輩にすぐ質問してしまうことが増えてきました。

それ自体は悪いことではないと思うのですが、私は自分で調べて苦労して得た知識の方が忘れにくいので、ネットでおすすめされている本を購入し、参考図書をPCの横に置いて自分で学習する環境を整えました。

個人的には、ネットで調べて学ぶよりも、実際に本を読んで学んだ方がしっかりインプットできるタイプなので、この作戦は効果的だったなと思います。

★私が読んでいる本↓

■1週間でGoogleアナリティクス4の基礎が学べる本(1週間で基礎が学べるシリーズ)

■Googleアナリティクスプロフェッショナル~分析・施策のアイデアを生む最強リファレンス~

④セミナー聴講で学びを加速する

本での視覚的学び、業務を通じての体験は、知識を身につける上でとても大事なことです。

ただ、私は早く一人前になりたかったので、さらに学びを加速するため、WEBセミナーを受講することにしました。

セミナーは人が話したことを聴いた上で、考えてインプットすることができるので、記憶に残りやすいと考えたからです。

また、知りたかったことだけでなく、現場で役立つ話をまとめてわかりやすく教えてくれるので、時間がない人にこそおすすめの学習方法です。

⑤すき間時間を活用した学習

最近は、すき間時間に「Google Analytics 〇〇 〇〇」といった形で検索し、Google Analytics関連の記事を読むことを心がけています。

内容は似ていても、記事を書く人によって視点が異なることから異なった内容の記事に思えてきたりします。

このように思えるのは、少しずつ自分に知識がついてきている証なのかなとポジティブに考えています(笑)

多種類の記事を読む→知識量が増える→物事の判断軸が増える→自己肯定感の上昇

というポジティブな連鎖が起き成長できているなと感じています、、!

Google Analyticsに限らず、色々な方が書いた記事を読むことは糧になると思うのでお時間あるときはサクッとなんでも検索しちゃいましょう!!

⑥おわりに

ここまで読んでくださった方本当にありがとうございます(^^)/

入社して半年しか経っていない私でも、模索しながら「Google Analyticsのスペシャリスト」を目指して走り続けています。

GAIQにチャレンジしようと思っている方、これからGoogle Analyticsを活用してみようと思っている方のお役に少しでも立てれば嬉しいです。

第2弾は、「新卒1年目におけるGoogleタグマネージャーの学び方」を投稿予定です。
次回も読んでくださると嬉しいです!

アピリッツでは、GA4導入をイチから支援するだけでなく、今回のようなGA4とのツール連携やABテストの運用、ECを含むWEB制作など幅広くサポートいたします。WEBサービスでお困りの方や、ご興味のある方は遠慮なくご相談ください。

GA4とオプティマイズの連携方法(360対応)

0

Universal Analytics(以下UA)サポート終了のアナウンスがされてから早くも半年が過ぎました。
既にGoogle Analytics4(以下GA4)を導入している企業も多いのではないでしょうか。

GA4を導入したら、UAと同様に他ツールとの連携もしないといけませんよね。Google広告とSearch Consoleは代理店に依頼するか、調べれば比較的スムーズに連携できると思います。
しかし、Googleオプティマイズ(以下オプティマイズ)の連携に関する情報はまだあまり出回っておらず、何も設定せずにオプティマイズでABテストを始めると「GA4でテストデータが見れない」なんてことになりかねません。

そこで、今回はGA4とオプティマイズの連携方法を解説していきたいと思います。GA4有償版を連携する際に陥りがちなポイントも詳しく解説しますので、GA4有償版を利用されている方は必見です。

オプティマイズのアカウント作成

UAは使っていたけどオプティマイズは初めてという方は、オプティマイズのアカウントを作成しましょう。

Googleのオプティマイズのサイトにアクセスし、アカウントを作成してください。

オプティマイズのアカウント作成画面

オプティマイズのコンテナ作成

UAでオプティマイズを利用されていた方は、UAとは別のコンテナを作成してください。「1コンテナ1プロパティ」と覚えましょう。
初めてオプティマイズを利用される方はそのままコンテナを作成してください。
コンテナとはフォルダ(箱)のようなもので、コンテナ内にテスト(エクスペリエンス)を作成します。

オプティマイズコンテナ作成画面

GA4とオプティマイズのコンテナ連携(360の方必見)

オプティマイズのコンテナ作成が終わりましたら、次にGA4のプロパティとオプティマイズのコンテナを連携させます。テスト(エクスペリエンス)を作成する必要があるのですが、テストパターンの作成方法などは割愛します。
テスト(エクスペリエンス)を作成するプロセスの中で「アナリティクスへリンクする」というボタンが出てきます。このボタンをクリックし、連携したいGA4プロパティを選択してリンクしてください。

オプティマイズ詳細設定画面
オプティマイズコンテナとGA4のプロパティをリンク

この際、GA4有償版(360)を使っていて、連携したいプロパティ名が出てこない場合があります。これはオプティマイズが360化されていないことが要因です。
360化するには下記ステップで設定が可能です。

まずマーケティングプラットフォームにアクセスし、下記ステップで設定します。

  1. 組織設定でプロパティを管理している組織を選択
  2. アナリティクスサービスを選択
  3. アナリティクスアカウントを選択
  4. プロパティを選択
  5. プロパティ情報の枠内をクリック
  6. オプティマイズ360の無効化済みを変更

360化できましたら、オプティマイズの管理画面に戻ると360化したプロパティ名が選択できるようになります。

オプティマイズを360化

オプティマイズ用のディメンション(カスタム定義)作成

GA4とオプティマイズ連携において最も大事なポイントは、テスト(エクスペリエンス)をスタートする前にオプティマイズ用のディメンションを作成することです。これをやらないと、GA4でテストデータを見ることができません。
プロパティ毎に一度設定するとそれ以降の設定は不要なので、テストを始める前に必ず設定しましょう。

まず、GA4の管理画面の左側のメニューの設定内にあるカスタム定義をクリックして、下記2つのディメンションを作成してください。

①ディメンション名とイベントパラメータ:experiment_id、範囲はイベント
②ディメンション名とイベントパラメータ:variant_id、範囲はイベント
※イベントパラメータは固定の為、変更できません。ディメンションや説明文は任意で変えられますので、覚えやすいものにしましょう。

カスタム定義登録は画面左のメニューから管理画面内に移動にしました
オプティマイズ用のカスタムディメンションを作成

オプティマイズ用のセグメント作成

オプティマイズのテスト(エクスペリエンス)をスタートすると、テスト毎にテストIDが発行されます。このテストIDを用いて、オプティマイズ用のセグメントをパターン毎に作成しますので、テストIDをコピーしてどこかにメモしておいてください。

テストIDはエクスペリエンスの詳細画面にあります。

次に、GA4のデータ探索を開きます。レポートのテンプレートは何を選んでいただいてもかまいません。
レポートの詳細設定画面のセグメントを作成を開き、ユーザーセグメントを作成をクリック。
条件を入力する画面になりますので、「variant_id」と入力してください。
次にパラメータを入力する必要があるので、先程コピーしたテストIDを入力します。この際、オリジナルパターンのセグメントを作成する場合は「テストID.0」、テストパターン1のセグメントを作る場合は「テストID.1」と入力して、保存してください。

この画像は.0なのでオリジナルパターンのセグメントとなります。

まとめ

ここまでの作業を終えることで、ようやくGA4とオプティマイズを連携し、GA4で分析する環境が整います。
オプティマイズ用のディメンション作成は忘れがちなので、GA4を導入した際に作成しておくと良いでしょう。

弊社ではGA4導入をイチから支援させていただくだけでなく、今回のようなGA4とのツール連携やABテストの運用、ECを含むWEB制作など幅広くサポートさせていただいております。WEBサービスでお困りの方や、ご興味のある方は遠慮なくご相談ください。

走る時のシルエット

0

アピリッツの知識共有サイト「ナレッジベース」で公開されている内容をアピスピでも紹介します。こちらはES部の3Dデザイナー・石井 開さんによる記事です。

すばやく走るアニメーションを作る時や見る時、足を前に出す時のポージングが難しいなと思ったので
考えていることをまとめます。

通常走る時に足を前に踏み込む時、膝をまっすぐ伸ばしてカカトから着地するかと思います。
走り 作画 で検索したり、youtubeで走り方の講座動画などを見ると姿勢をまっすぐ伸ばし、脚もまっすぐ伸ばしたポーズが伺えるかと思います。

しかしこれがゲームなどでよくある姿勢を低くして素早く走る様な動きを付けたい時、
(個人的に)踏み込むポーズとして適してないと感じます。
(脚を伸ばして踏み込むポーズがキャラ的に一瞬だけブレて見えたり前傾姿勢の勢いが崩れるなど)

なのでそういった場合、足が着地するまで膝がまっすぐならない様にしたり、場合によっては着地する瞬間でも
若干膝が曲がった状態で着地するなどすると印象や勢いを崩さずに済むかもしれないなあというお話です。

ちなみにANTHEMという神ゲーがあるんですが、そのゲームはジャベリンエグゾスーツという特殊なパワードスーツに身を包んで戦うんですが、このジャベリンエグゾスーツは脚の関節がチーターなどの様に人間より関節が一つ多い(厳密には人間の足にあたる部分が長く、つま先にあたる部分で着地する構造になっている)ので、足を前に十分踏み込んでも膝を曲げた状態が維持され、前傾姿勢の勢いが崩れない様になってるんですよね。

61名入社予定!「2023年 新卒内定者顔合わせ会」

0

アピリッツの新卒内定者顔合わせ会は、2019年以降、オンラインとオフラインの同時開催となっています。すでに会社で働き始めている人、4月からジョインする人、そしてこれから上京する人。いろんな新メンバーを迎えるために、人事企画部が毎年アピリッツにまつわるクイズやグループワークを考えて実施しています。今年の様子を報告します!(取材 2022年11月)

同期入社のメンバーと会社を知ってもらう会

アピリッツに2023年に入社予定のみなさんをお呼びして開催する「新卒内定者顔合わせ会」は、学生同士の顔合わせの機会であり、会社のことをより知ってもらう大切な場です。あ、入社前の連絡事項などもこちらでご案内していますよ!

今年は61名入社予定です。昨年と比べると16名増。どんどん会社が大きくなっています。

企画・運営を担当する人事企画部の元野(ちゃいろいモコモコの服)と、和田(ピンクのカーディガン)

まずはリモート参加の人も、会場参加の人も、みんなで自己紹介を順番に行います。好きなものや気になっていることなど一言添えて挨拶をしてくれたので、これからの会話のきっかけになればいいなと思っています。

今年のクイズは結構本気だった

毎年恒例の催しになっているのがアピリッツクイズです。ルールは超簡単。

検索するスキがない

「アピリッツクイズ」って名前のとおり、出てくる問題はアピリッツに関するものばかり。

今年は意外と難しかったかもしれません。

コミュニケーションゲームでディスカッション

4~6名ずつくらいに分かれてコミュニケーションゲームもやりました。お題はこんな感じ。

さあどうする

じっくり20分間話して意見をまとめます。「全員が発言すること」「否定しないように話す言葉選び」そして「オンライン上で話し合うこと」は、実際に仕事が始まってから必要とされることです。

どのチームも盛り上がっていました

コミュニケーションゲームのあとは社内見学でオフィスやカフェの様子をカメラ中継でご紹介し、人事企画部の部長の川口から「今やるべきことをしっかりやってくださいね」「コロナ禍も少し落ち着いているかもしれません。ならば、今のうちにお友達との思い出作りや遠くへの旅行などチャレンジしてみてください」とエールが送られ、最後はアピリッツの社員寮「アピトリー」についてお知らせして終わりました。アピトリーが首都圏以外から入社される方のよい選択肢になればと思います。

▼アピリッツの寮についてのレポートはこちら
住み心地はどう? アピリッツ社員寮「アピトリー」、入居者インタビュー・女性編

住心地はどう? アピリッツ社員寮「アピトリー」、入居者インタビュー・男性編

ご内定者のみなさん、春にお会いできることを楽しみにしています!

ラムダ式を比較

0

アピリッツの知識共有サイト「ナレッジベース」で公開されている内容をアピスピでも紹介します。こちらはES部のクライアントエンジニア・足立雅史さんによる記事です。

クライアントのゲーム開発において、 2大フレームワークにUnityとUnreal Engineがありますが、
この2つのフレームワークで異なるところは実装言語です。
UnityはC#で、Unreal EngineはC++なのですが、 そのラムダ式の記法の違いについて説明します。

ラムダ式とは 

ある手続き(処理)のかたまりをオブジェクトのように扱える「関数オブジェクト」があります。
以下のコードだとfunc_obj や f_lambda が関数オブジェクトです。
func_objにはprint_numberという関数が代入されていますが、
f_lambdaにはその場で記述された無名の手続きが代入されています。
この名前付けされずに定義された関数を「ラムダ式」と呼んでいます。

#include <iostream>
#include <functional>

void print_number(const int i) {
    std::cout << i << std::endl;
}
    
int main() {
    std::function<void(int)> func_obj = print_number;
    // 実行したら3と表示される
    func_obj(3);
    
     std::function<void(int)> f_lambda = [](int i) {
        std::cout << i < std::endl;
    };
    // 実行したら5と表示される
    f_lambda(5);
    return 0;
}

ラムダ式の記法を比較 

最近までUnityでC#を使って開発してきたのでC++と違いを調べていました。
型表現として、C++ではstd::functionを用いますが、C#では System.ActionSystem.Funcを用います。
比較しやすいように一覧表を書いてみました。

C++C#関数表現
std::function<void()>System.Actionvoid func()
std::function<void(int)>System.Action<int>void func(int i)
std::function<bool(void)>System.Func<bool>bool func()
std::function<bool(int,double)>System.Func<int,double,bool>bool func(int, double)
std::function<int(int)> a = [](int x) {return x + 1;};System.Func<int,int> a = x => x + 1;

「主体的に動いて、お互いを補完しあうチームにしたい」 佐藤香絵インタビュー

0

アピリッツのデジタルエクスペリエンス部の佐藤は、2021年から部長代行としてデザイン制作グループ(通称「デザプラ」)を率いています。クライアントも業種もさまざまなデザプラの仕事のこと、管理職としてのプレッシャー、1on1の狙い、そして社内制度を上手く使いながらの子育て。たくさん話してもらいました。(取材 2022年10月)

管理職になるなら、脳みそが若いうちがおすすめ!

―― まずは経歴の話を聞かせてください。アピリッツの前身のKBMJに新卒入社したのですよね?

はい。実はWebエンジニアがキャリアの最初です。もともとは編集者になりたかったのですが、出版業界は不況で……2000年代前半はウェブメディアの黎明期だったのもあって、IT業界に入っていればそういう仕事につながるかなと思ってKBMJに入りました。新規事業を担当する部署でサイトリニューアルなどに携わり、ディレクターやデザイナーの仕事を任されるようになったことが現在の業務にもつながっています。結局のところ、編集者にはなりませんでした(笑)

―― 2021年に部長代行になりましたね。アピリッツは女性管理職の登用が進んでいますが、タイミング的に「早い」や「遅い」と感じましたか?

結婚・出産を経験してからではありますが、育児との両立にも慣れて、ちょうどよかったんじゃないかなと思います。仕事の経験値も積めた段階でしたし。ただ若手には「管理職やマネジメント職を目指すのであれば、若いうちでもどんどんチャレンジしたほうがいいよ、 脳みそが若いうちがおすすめだよ!」って言いたいですね。

―― 脳みそ!

インプットすることが一気に増えるんです。管理職になると幅広い視点が求められます。チームを率いるマネジメントの視点、案件を獲得してきちんと進める視点、それから経営の視点。上場してから社内の環境は刻々と変わっています。関わる仕事の規模や性質も変化してきました。そういったスピード感についていくことにやりがいを感じられるのであれば、いいキャリアが積めると思います。まわりもサポートしてくれますし。

脳みそが若いうちにぜひ挑戦してほしい!

「さとかえさんらしくやればいいんじゃないですか」

―― プレッシャーは感じましたか?

相当感じています! 私の歴代の上司が優秀すぎるので、自分はそんな風にはなれないと思っています。でも同僚が「さとかえさん(注:佐藤の愛称。社内のほとんどの人間がこう呼ぶ)らしくやればいいんじゃないですか」と背中を押してくれて。この言葉をふと思い出して、立ち止まることができています。そうやって誰かの背中を押せるような管理職になれるといいですよね。さらに「あの人ができるなら……」とハードルを下げられる存在でもあるといいなと思っています。

―― 保育園のお迎えで慌ただしく退社するさとかえさんを何度か見かけています。子育て真っ最中に女性管理職として働くのは大変そうな印象ですが……

想像以上に大変ですね。私はもともと不器用なタイプで、とにかく気合で乗り切っているところはあります(笑) ただ、仕事と子育てが気持ちの切り替えになっていますし、寝かしつけた後はひたすらマンガを読んだりして、好きなことに費やす時間も大切にしています。まわりに仕事と育児を両立しているパパママも増えましたし、仲間意識が生まれますよね。仕事する上でも心強いなと思っています。

働き方に関しては、アピリッツの裁量労働制度の「アピプロ制度」をフル活用しています。

時短勤務じゃなくフルタイムで働きたい、でも保育園のお迎えには早めに行ってあげたい、子供を寝かしつけた後に家でちょっと働きたい……って人には、アピプロ制度はオススメですね。

私は子供を持ってから、仕事で裁量権を持って働くことの大切さがわかりました。子供はコントロールできないので……自分と仕事をコントロールする方にシフトしています。意外となんとかなりますよ(笑)

会社の変化に合わせて進化するデザプラ

―― さとかえさんが率いるデザプラグループのことを教えてください

ひと言でいうと「まじめ」ですね! みんな、任された案件や、自分の仕事やスキルに対して真摯に向き合いながら、しっかりとやり遂げる意識を持っています。

経験豊富なメンバーは、チームに対しておのおのが経験を惜しみなく還元し、引き上げようという気持ちが強いです。チームとしての課題解決にも積極的に取り組んでくれます。若手も、それに応える勉強家ばかりです。

会社の状況が変化するのと同じように、デザプラグループも進化しています。単なるデザイン制作だけでなく、スタートアップ支援やUX・UIデザインプロセス支援、モックアップを活用した要件定義といった上流工程にもどんどんチャレンジしています。アピリッツが強みとする「ワンストップソリューション」の一翼を担うために、成長が求められている状況だと思います。

私たちの担当するクライアントは業種も業態もさまざまで、ビジネスやクリエイティブの面では多様な課題に向き合う必要があります。そういった案件に日々対峙しているメンバーは本当にタフだなと思います。模索して、ときには迷走しつつ……そんなメンバーの姿に私自身が支えられていますし、学ばせてもらっています。

―― どんなふうにデザプラグループを引っ張っていきたいですか?

理想をいうなら「俺について来い!」みたいなリーダーに憧れますが、性に合わないので(笑)、私は対話を大切にしたいと考えています。私達の仕事は、クライアントも案件内容も千差万別です。ひとつひとつの仕事にそれぞれのミッションがあり、それを理解しなければただの作業者になってしまい、仕事に対しても自分に対しても、もったいないですよね。自分で考えて主体的に動いて、お互いを補完しあうチームにしたいと思います。

「お客様のビジネスに対して、何が価値のある提案になるか?」

―― 1on1やメンバーとの対話を繰り返すと、変化や手応えを感じますか?

感じますね。たとえば、デザプラが大切にする「開発側と正確に連携するためのコーディングや、論理的に裏付けのあるデザイン」について、私だけじゃなくメンバー全員が自分の言葉で話せるようになるべきだと思っていますが、この考え方はチーム内にも浸透してきていて、業務を通して感じられる場面が増えてきました。週ごとに実施している勉強会でも、メンバーの学びがよく感じられます。

―― メンバーを育てるための1on1なのでしょうか

「育てる」というのがあまりしっくりこないのですが……どちらかというと、考えていることや思いを伝えて、同じ方向を向くための時間として重要だと考えています。

せっかくアピリッツでデザインの仕事をやっているのだから、この環境を自身の糧として最大限活かしてほしい。「お客様のビジネスに対して何が価値のある提案になるか?」を身につけるために、「踏み台にして成長してほしい」と伝えています。

アピリッツのデザインが関わる領域は、マーケティングやSaaSなども含めてとても幅広く、キャリアやスキルアップの選択肢も多彩です。

ここで何を強みとするべきか、何ができたら自分の価値が上がるのか、考えながら仕事をしてほしいです。そしてメンバーのキャリアを拡げるような仕事を作ることが私のミッションだと思っています。

メンバーが少しづつでも「成長できた、貢献できた」と感じられるチームや環境を作っていきたいです。

アピリッツ決算説明資料のつくり方。デザインプランニンググループの挑戦

0

上場企業が四半期ごとに作成・公表する決算説明資料。もちろんアピリッツも年4回しっかり発表しています!「正しく、わかりやすく伝えること」と「美しさ」を両立させた資料を、ステークホルダーの皆さまへお届けするために、アピリッツでは上場当初からIR担当者と社内のデザインチームが一緒に決算説明資料を作ってきました

「どんどんよくなっていくよね」と評判のアピリッツの決算説明資料や、制作チームのことを、もっと知ってもらいたい!ということで、デザインを担当するデジタルエクスペリエンス部の「デザインプランニンググループ(通称「デザプラ」)」とCFOの永山が、怒涛の制作風景や使用ツール、そしてチーム体制について振り返ります。(2022年10月 取材)

「絶対CFO一人で作ってないでしょ」と言われる

―― アピリッツの決算説明資料はお褒めの言葉を頂くこともあるそうですね

永山:評判いいです! 上場企業のCFOやIR担当者と集まってIR活動に関する勉強会を頻繁にやっているのですが、そこでよく「デザインきれいだよね、IR資料のアワードに応募したらいいですよ」って褒められます。あと「これ絶対に永山さん一人で作ってないでしょ、プロのデザイナーが作ってますよね。デザインは最高だから、あとは永山さんの構成力が課題だね!」とも言われる(笑)

実は、アピリッツの上場審査が終わって上場するまでのあいだに使ったエクイティ・ストーリー(=機関投資家向け資料)だけは、外部の方や和田(アピリッツの代表取締役)に相談しながら自分で作りました。で、パワーポイントを操作しながら「我ながらこのデザインはダッセーな。これを使いまわすのはイヤだな」と思ったんですよね。「これ使って和田さんに投資家たちと対話させるの、申し訳ないな」って。

そしたら和田や執行役員の長谷が「社内にデザインチームがあるんだから、今後のIR資料はそちらにも手伝ってもらおうよ」と言ってくれて。「エッ! いいの!?」ってビックリしました。「みんなクライアントワークで忙しいはずなのに。頼っていいんだ!?」って。

―― 頼ってよかったんですね

永山:はい。それ以降は、決算発表のたびにデザプラのみんなと資料を作るようになりました。

梨子田:会社の管理部門と事業部門が一緒になって仕事を進めることは珍しいかなと思いますし、開発だけでなくデザインができるアピリッツらしいスタイルですよね。

永山:それは個人的にもうれしいです。毎回「ひとつの作品を社内みんなでつくるぞ!」と思って準備しています。

少しずつメンバーが増えて、決算説明資料デザインチームは現在5人体制です

情報収集と体制づくり

―― 決算説明資料の制作チームは、最初に梨子田さんがデザインとディレクションで参加して、回を重ねるごとにメンバーが増えていきました。資料作りの第一歩はどんな感じでしたか?

梨子田:今もこれは変わりませんが、まずは情報収集をやります。決算説明資料で伝えたい内容を経営層に確認して、それをもとに各セグメントのリーダーに質問して情報や資料をもらって、決算説明資料に落とし込みます

最初はこの情報収集と体制づくりに苦労しました。「直接的に売上が発生する仕事ではないし、どこまで事業部のメンバーに協力してもらうか?」と悩んだり。

永山:現場の理解を得るって大切です。IR担当者や経営層は決算説明資料が会社に与えるインパクトや大切さをわかっているけれど、IR活動はクライアントワークとは違って、「売上が上がる」といった直接的なインパクトがあるわけではないし、株価は業績や地合い(=株式市場の環境)にも左右されてるので、重要さを伝えるのは難しいかもしれません。

―― 決算説明資料ではインサイダー情報を多く取り扱うので、関わるメンバーも限定されていて、いったい何を準備しているのか社内からも見えづらいですし……

黒須:ですね。でも、最初は「そうは言っても社内の資料でしょ?」くらいの認識だったのが、少しずつ社内の流れが変わって、ことの重大さがわかってくるんです。現場でも「ここに力を割く価値はある。重要な仕事なんだ」という意識に変わりました

鈴木:デザプラ内のリーダー層と話し合って、クライアントワークを調整してベテランデザイナーを投入できるようになったり。

黒須:そうやって決算説明資料チームに新しく参加した私達が「やっぱりすごく大切だし、大変だよ!」ってたくさんアピールすると、ますます協力体制が生まれてくる(笑)

Adobe XDとパワーポイントのハイブリッド

―― どこが一番「すごく大変!」でしたか?

黒須:二度大きく作り直したタイミングがありました。

まず、私が参加したタイミングで制作環境を変えました。パーツの多さや見栄えを考慮して、パワーポイントからAdobe XDで一通り作り直したんです。このときが一番大変でした。やってもやっても終わらない(笑) ただ、一度変えてしまえばAdobe XDで共通のパーツを使ってその後も制作できますし、やってよかったです。

それから、DTPのデザイン経験のある宮本さんが参加してくれてクオリティがさらに上がったと思います。細部まで整えると美しくなるんですよね。これが二度目の作り直しです。宮本さんが細かく調整を入れて作り変えました。

宮本:フォントの雰囲気を「繊細で信頼感がありスタイリッシュなもの」に統一しました。決算説明資料のルールを守りつつ、レイアウトに遊び心を入れてみたり。

黒須:そうやって細部にこだわりを入れられるようになってきました。

フォントにもこだわってます

黒須:そして、今はパワーポイントとAdobe XDのハイブリッドで作っています。たとえば「ちょっとここだけあとで変えたい」と永山さんが思ったときに、永山さんの手元で修正できたほうが小回りは効くので、そういった部分はパワーポイントを使っています。

永山:修正は最後の最後まで入ります。実は、資料制作と並行して決算数値の監査法人監査が入るので、数値を変更する場合もあるし、途中で「やっぱり構成はこうすべきだな」と思ったりして原稿がギリギリまで確定しません。ページの並び順を変えることもありますし……。いつも原稿が遅くて申し訳ない。

デザプラ全員:みんな毎回覚悟しています(笑)

覚悟してるみなさん

鈴木:決算の頃になると梨子田さんが遅い時間まで仕事しているのは知っていたので「決算を出す今だけだ!」と覚悟を決めて参加したんです。でも、単に大変なだけじゃなくて、ディレクターとして得るものも大きかったです。クライアントワークにも活かせます。なのでデザプラのいろんな人におすすめしたいです。

丹羽:「読み手が一番知りたい情報は何なのか」と考えながら資料を作るので、ただキレイにデザインをまとめるだけではなく、情報を整理してデザイン制作する視点が身につきます。これは通常のデザプラでの仕事でも役に立ちますね。

黒須:査定での評価にも入りますし。

梨子田:「(決算説明資料の作成は)会社の根本に関わる重要な仕事だから責任を持ってね」と佐藤(デザプラを率いるデジタルエクスペリエンス部の部長代行)からも言われていますし、グループのメンバーにもそれは伝わっています。

伝えたいメッセージをデザインする

宮本:数字をキレイに並べるだけがデザインではないので、どこを強調すればよいかは常に考えています。全部大切な情報ですし、とはいえ全部真っ赤な太文字にはできないし……。

永山:こちらから出す原稿は「会社のみんなの頑張りを投資家たちへ伝えたい!」って思いが強くなってしまうので、つい「昨対比もいい、予算比もいい!ああ俺は全部言いたい!だから原稿の文字も全部真っ赤だ!」ってなりがちなんですよ。

黒須:そう、本当に真っ赤(笑)なので、そこから永山さんや経営陣が伝えたいことをくみ取って、その上でデザインでどこを強調するかを、デザプラ側でしっかり考えます

真っ赤な原稿から資料を作るデザイナーの黒須。となりはディレクターの鈴木

永山:ありがたいことです。つい「言葉で全部伝えちゃえ」って考えがちなんですが、事業のことをダラダラしゃべっても伝わらないんですよ。パワポに文字をぎっしり詰め込んでもダメ。だから、伝えるデザインの力をいつも感じています

宮本:事業の概念図を作るのは苦労しますね。「成長のイメージを表現する図」ってどういうものがいいだろう? と考えたり。

鈴木:ただキレイなだけじゃだめですし。一番大変なんじゃないかなと思います。

梨子田:イメージを伝えるデザインづくりは毎回苦心しています。「グループ企業になったムービングクルーの事業をどう表現しようかな?」と思案したり。永山さんたちと直接やりとりしてイメージをすり合わせています。

アピリッツの成長イメージ!

永山:成長企業なので、新しい事業や取り組みがどんどん増えているんですよね。四半期ってつまり3ヶ月です。たった3ヶ月しか経っていないのに、その短いあいだに新しいことが増えるから、資料も数字を更新するだけじゃない。それでご苦労をかけている面もある。

あと、個人投資家向けのセミナーや機関投資家との1on1で資料のフィードバックをもらうんです。そのフィードバックをもとに資料をアップデートしていくから、毎回いろいろデザインチームへの注文が増えてしまう。

黒須:それは普段のクライアントワークでも当たり前のようにやっていることで、アップデートとブラッシュアップを重ねるのは大切なことです。だから大丈夫です!

永山:黒須さん今日ほんといいこといっぱい言ってくれてうれしいです。これからも一緒にいい資料を作っていきましょう。よろしくお願いします!

アピリッツのIR情報はこちらで公開しています!

デザインプランニンググループへの仕事のご相談はこちらよりお送りください!

【アピリッツのカフェ「アピカフェ」のご紹介】ハロウィーンパーティーやりました

0

アピリッツの社員向け無料カフェ「アピカフェ」は、社員の憩いの場として大人気です。先日、10月31日のハロウィーンに先立って人事企画部がアピカフェでハロウィーンパーティーを開きました。いっぱい来てくれましたよ! ってことで、ちょっと覗いてきました。(取材 2022年10月)

今年入社した社員を連れて来たら「いいこと」があるよ!

ハロウィーンといえばお菓子。ということでお菓子の抽せん会を開催しました。

参加条件は「今年入社の人と一緒に来ること」。新しく仲間に加わった人と誘い合って遊びに来てね、そして仲良くなって仕事でもがんばろうね、ということです。

仮装した人事企画部のみなさんがお出迎え。

バーカウンターで好きな飲みものを注文して作ってもらいます。

お菓子の抽せんコーナーです。ハロウィーン的お菓子がもりもり積まれていました。

大当たりな社員も続出。当たる人は当たる。

楽しそう。アピカフェは「社員同士のコミュニケーションの場になれば」という狙いでスタートして、コロナを留意しつつ人事企画部が運営してきました。社長の和田も、ときどきアピカフェでコーヒーを飲んでいますよ!

ちなみに、アピリッツのオフィスがあるのは渋谷です。毎年ハロウィーンが盛り上がりすぎて警察が出動することでも有名な街。このため、アピリッツでは社員の安全を考慮して10月28日と10月31日はリモートワークを推奨しています。みなさん安全で楽しいハロウィーンを~!

エンジニアが問題を説明する時に気を付ける事

0

コンテンツデザイン部の金井と申します。今回は、分かり易い説明をする為に心掛けている事を書いていきます。

結論

読む人のリソースを少なくするように心掛ける。
その為に、

  • 結論から先に言う
    • 何を要求しているのかが一目で分かる
    • 読み返す際も、全てを読む必要がなくなる
  • 長文で纏めず、要点を切り分けて説明する
    • 文章を読者に噛み砕かせる手間を極力省く
    • 文章としての体は重視せずに、箇条書きや強調を駆使する
    • フォーマットがあれば、それに従えば知識などなくてもある程度分かりやすく記述出来る
  • 専門用語は必要に応じて噛み砕く
    • 読者が何に長けていて、何に疎いのかを想像する

悪い例

お疲れ様です。
先日より発生している、お勧めユーザーを検索するAPIで長い時間が掛かってしまう問題に関してですが、ユーザーデータの量が想定より多く、またそれに対してデータベースのインデックスが適切に張られていなかった事が原因でした。
また、現在業者によるリセマラアカウントが日々増加している事も鑑みると、インデックスを適切に張り直しても現在の仕様ではその内また時間が掛かるようになってしまう事が想定される為、お勧めユーザーの検索ロジックの変更をしたいと考えています。
現状のお勧めユーザー検索ロジックの問題となっている部分は、3日以内にログインしている、という条件が現状のDAUから考慮すると多過ぎる点と、また、その他の絞り込む条件もその莫大なユーザー数からの抽出には時間が掛かってしまう点です。
その為、3日以内にログインしている、という条件を、直近にログインをしたユーザーの指定数に変更し、その中から抽出するという形にしたいです。
これに変更しても直近に遊んでいる人からお勧めユーザーを参照したいという要望は変わらないまま、DAUに関わらず参照量は一定になりますので、APIで掛かる時間も一定になるからです。欠点を挙げるとするのならば、ゲームが遊ばれなくなる時間帯などには同じユーザーが参照されてしまう可能性が高いという事がありますが、現状の盛況振りから考えるとこれから先も基本無く、またあったとしてもそう強い問題でもないと思いますので、一考願いたいです。
よろしくお願いします。
……何言ってるんだこいつ? ……読むの面倒だし、後回しにしよう

どこが悪いのか?

順序立てて説明していますが、読むのに疲れますし、最後まで読まないと何をどうしたいのか分かりません。
と言うより……読もうと思えないですよね、これ。
まあ……この文章を総括してしまえば、エンジニアの自己満足です。

エンジニアは問題の原因究明、解決に100%のエネルギーを注いで対応しているかもしれませんが、
プランナーやプロジェクトマネージャー、ディレクターといった、仕様を考える人、最終的に判断を下す人達はもっと色々な事を同時並行でやっていたりします。
要するに、上に立つ人はエンジニアと同じだけのエネルギーを原因解決だけに注いでいられない訳です。
エンジニアから欲しいのは主に、どのような問題が発生し、その解決に必要な事柄は何なのか? という事です。
そういう事を留意した上で、タスクが多い人のリソースをエンジニアと同等レベルに食わせない事を考えましょう。
その為にすべき事としては、以下になります。

  • 結論から先に言う
  • 要点を分かりやすくする
  • 専門用語は必要に応じて噛み砕く

現状の個人として強く意識している考えなので、もっと考えるべき事柄や無意識に行っている事柄もあると思いますが、ひとまずそれぞれに対して詳細を書いていこうと思います。

返信来ないなぁ……。

結論から先に言う

先ほども述べた、最後まで読まないと何をどうしたいのか分からないという事の何が問題かと言えば、

  • 最後まで読む必要がある……言いたい事を理解するのに時間が掛かるし、要点を掴むのにも文章の全てを咀嚼する必要がある
  • 読み返す時も、最初に読む時と同程度リソースを要求する

という点です。
なので、まずは言いたい事を先に言ってしまいましょう。
何の為にこの文章は書かれたものなのか?
最終的に何を言いたいのか?
それを最初に提示するだけでも、ぐっと読者のリソースは減ります。
例をざっくり纏めてしまうと、

お勧めユーザー検索に時間が掛かっている問題の解決の為に、検索ロジックそのものを変更したい
“3日以内にログインしている”という条件を”直近にログインをしたユーザーの指定数”に変更したい

という事になるので、まずそれを提示すべきですね。

様々なタスクに追われて忘れてしまい、そのまま昼食に

要点を分かりやすくする

悪い例の文章は、要点が文章の中に紛れ込んでいる為、実際に読んでみないと結論に対して、

  • 何の目的でそれをしたいのか?
  • それをするメリット、デメリットは何なのか?

と言った事が分かりません。
読者に国語のテストなんてさせるな、って話ですね。
評論文とか書く訳じゃないですし、最初から解答を明示しておけば良いのです。
そういう分かり易さの為には、必ずしも文章の体をしている必要はありません
必要に応じて箇条書きや強調も使っていきましょう
それで、要点を纏めてそれを分かりやすくするとなると、フォーマット化してしまうのも良いでしょう。
それだけで誰でも、何も知らなくても、分かりやすいように報告出来るようになるでしょうから。
ただ、フォーマット化に頼り過ぎると報告したい事によってはイマイチ収まりが悪かったりする事もあるので、そこ辺りは柔軟に。
例を要点で分割してみると、

問題:
お勧めユーザー検索で時間が掛かっている

原因:
SV想定より多くのユーザーが遊んでいる
SVの検索処理が最適化されていない
仕様におけるユーザーの参照量が多過ぎる

対応:
ロジックそのものを変更する

対応詳細:
3日以内にログインしているユーザーから対象を抽出する
を、
直近にログインをしたユーザーの指定数
にする。
理由としては以下。
・その仕様が一番冗長且つ時間の掛かる要因
・SVの最適化不足もあるが、DAUの観点からしても参照するユーザー数が多過ぎる直近に遊んでいるという条件を崩さない上記の変更を行えば、DAUに関わらず参照するユーザー数が一定となりレスポンスがいつでも安定する
また、これに変更するデメリットとして、
プレイ人口が減ると同じユーザーが選出される可能性がある
が、
現状のDAUを考えると殆ど発生しない
と考える為、問題ないと思う。
返信来ないなあ……。

専門用語は必要に応じて噛み砕く

悪い例において、データベースのインデックスが適切に張られていなかったと説明していますが、
ぶっちゃけプランナーとかになると、エンジニアを経験していたり、DBに対する理解が無かったりしないと、そんな事知らんがなというだけで終わります。
どういう人に読まれるかという事を考えて、専門用語は適切に言い換えたり、抽象化したりしましょう。
この例を書き換えるとすると、
想定以上のユーザー数に対して検索処理に時間が掛かるようになってしまった
データベースの検索の効率化が考慮不足だった
とかで良いかと思います。
他にも、APIだとかDAUだとかリセマラだとか、これらに関しては同じゲームを開発している人達なら基本通じるでしょうが、専門用語には違いないので、ゲーム開発者だったりエンジニア以外に何か説明をする際は、噛み砕いておいたり、注釈を隅に書いておいた方が良いかもしれません。

忘れてた。で…………………………………要するに?

例を書き換えてみる

フォーマットがあるなら、それに記して出力して終わる……というか、前述の要点を分かりやすくするで書いた形でいいと思うのですが、
先出しとして、チャットツールとかに投げる形を想定して、書き直してみましょうか。

お疲れ様です。
先日より発生している、お勧めユーザー検索で時間が掛かる問題に関して、解決の為に一部仕様変更を願いたいです。
仕様変更したい部分は、検索条件の
3日以内にログインしているユーザーから対象を抽出する
を、
直近にログインをしたユーザーの指定数
への変更です。
詳細を以下に記します。

まず、そもそもの原因に関してですが、
・SV想定より多くのユーザーが遊んでいるSVの最適化不足ユーザー抽出条件の、3日以内にログインしているユーザーが多過ぎる
が主な問題でした。
また、SVの最適化をしたところで、3日以内にログインしているユーザーが余りにも多い為、それだけでは解決出来ないという結論に至りました。

その対応案として、
3日以内にログインしているユーザー直近にログインをしたユーザーの指定数
に変更したいと考えました。
理由としては、
"お勧めユーザーには、直近に遊んでいるユーザーから抽出したい"という要望を崩さない
ままに、
DAUに関わらず参照するユーザー数が一定となりレスポンスがいつでも安定するようになる
からです。
また、これに変えるデメリットとしては、
プレイ人口が減ると同じユーザーが選出される可能性がある
という事が考えられますが、
現状のDAUを考えると殆ど発生しない
と思います。

ご一考願えればと思います。
よろしくお願いします。

……まだまだ分かり易く出来そうだなー。

忙しいだろうけど、催促して良いかなぁ……。

Locust x Fargateで10000RPS越えの負荷試験をした話

0

コンテンツデザイン部の金井と申します。今回はLocustとFargateを使ってゲームアプリケーションの負荷試験をした話をしていこうと思います。

背景

結構前の話になりますが、自分はとあるゲームアプリケーションの開発・運営に携わっていました。
開発・運営に携わると言う事は、リリースにも携わるという事で、その点において自分は負荷試験を主に担当していました。

負荷試験ツールに何故Locustを使ったのか

負荷試験に関しては、別のプロジェクトから引き継いだサーバーソースではJMeterを使っていたのですが、JMeterは

  • 専用のGUIでの負荷試験シナリオ作成がややこしく、学習コストも高い事
  • 保存されるソースがXML形式であり、gitでのバージョン管理に向かない事
  • 負荷試験を行う際も面倒臭い点が多い事

という難点が他にも色々あるのに対し、Locustは

  • コードベースでの負荷試験シナリオ作成であり、学習コストは低く、またそれ故にgitでのバージョン管理に向く
  • 負荷試験の実行がJMeterに比べると単純で分かり易い

とメリットが多く、また他プロジェクトでも使用実績があった為、Locustに乗り換える事にしました(そして100近いAPIの負荷試験シナリオを1から書き直す事になりました)。

Locustは日本語でイナゴです。サーバーに蝗害を起こしにいくイメージですね

負荷試験サーバーに何故Fargateを使ったのか

そもそもFargateが何なのかを説明すると、AWSにおける、コンテナ向けのサーバーレスコンピューティングリソースです。
実態の無いサーバー、とでも言えばいいでしょうか。
実態……ホストマシンの存在が隠されている為、IPアドレスをこちらで決められなかったり、EC2のようにssh接続して中身を見たりする事は基本出来ない(方法が無い訳では無いみたいだけど)という欠点がありますが、
コンテナベースで立ち上げる為、OSなどを考慮する必要もなく、より手軽な使い方が可能です。
また負荷試験に対しては、インスタンスの増減に必要な設定がEC2よりも少なく、容易であるという点より、

  • 負荷試験の規模に関わらず準備の手間が殆ど変わらない
  • コストも鑑みて頻繁に起動と削除を繰り返す必要がある為、手軽であるのは強い

というメリットがありました。
それに元々サーバーインフラはAWSで立てていましたし。

負荷掛け環境構築まで

ネット上に先駆者が沢山居ましたので、そこ辺りで色々調べていけば、そこまで苦労する事は……一つだけありましたね。
AWSのPowerUserAccess権限ではECSでのタスク定義やクラスター定義の作成、編集が出来ないという点です。
務め人で、しっかり権限が個々に割り当てられているからこそ起きる問題ですね。最小権限の原則ってヤツです。
そして、AWSはそういう時にコンソール上で、これこれこういう理由で作成出来ませんでしたって通知してくれない場合が多くて(セキュリティ上の都合もあるんでしょうけど)、もっと上の権限を割り当てられていた先輩に聞いてみたら、俺は出来るけど? 何かミスってない? と返されたりして。
同じ画面で全く同じ操作をして自分だけ出来ないと証明して、やーっと気付きました。
コロナでリモート勤務だったのもあって、1~2日は潰した気がする。

GithubやSentryも権限がない状態でリポジトリやらプロジェクトやら開こうすると、冷徹に404返して来るしなぁ

負荷掛けられサーバー環境構築まで

プランナーに本番想定のマスタデータを貰って、それを本番に寄せた開発環境の1環境に反映しておしまいです。
また本番に寄せたと言っても、負荷試験のシナリオの都合上、例えば以下の点で異なってくる部分なども出てくるので、そういうのはきちんと纏めておきましょう。

  • 通信の暗号化は本番と同等か?
  • ミドルウェアはきちんと全て動作させる仕組みになっているか(BigQueryなどにデータを入れるところまできちんと出来るようにしてるか)?
  • 課金処理は途中で飛ばしたりしていないか?

そうでないと、後で痛い目を見る事になったりします。

後、ちゃんと監視ツールも設定しましょう。
NewRelic, Datadogやら, それからAWSを使っているのならばCloudWatchで、APIサーバー、それからDBやMemcachedなど各種ミドルウェアのCPU使用率、メモリ使用率、その他諸々を可視化出来るようにしておきましょう。

本番想定の負荷試験を実行するまで

いきなり本番想定で流す、という事はしません。ちゃんと、API全般が基本問題ないかを確認した上で、想定される本番と状況を出来るだけ近付けてやります。

小規模に全てのAPIを流すシナリオを動かして重いAPIがないかを確認する

ここで重いAPIがあった場合は、根本的にソースが重いのでちゃんと直しましょう。

リセマラを想定したシナリオを動かして問題ないかを確認する

要するに、リリース直後にチュートリアル周りを何度も重点的に走らされても問題ないか、という確認ですね。
後、本番想定にする為にDBにユーザーデータを蓄えないといけないのですが、
スクリプトを組んでユーザーデータを大量生産するとかも手としてはありますが、リセマラのシナリオを長時間流していればそれと同等の代物が出来上がって来るので、その方が調査も兼ねられて良いのではないかと思います。

中規模に全てのAPIを流すシナリオを動かして重いAPIがないかを確認する

ユーザーデータが作られた後に、再び全てのAPIを通る負荷試験を流してみましょう。
ここで重いAPIがあった場合は、DBのインデックスが正常に張られてないのが主な原因です。ちゃんと張り直しましょう。

ここまでやれば、サーバーソースの基本的な部分に関しては問題ないと言えるでしょう。

このタイミングで仕様変更ですか!!??!!??

本番想定の負荷試験

ここまでやって、本番想定の負荷試験を行います。
本番想定の負荷を掛けても問題ないか、という他に、

  • 長時間に渡って負荷を掛け続けて問題ないか
  • 本番想定以上の負荷を掛けてサーバーは落ちないか(DBなどの拡張が簡単に効かないミドルウェアの性能限界はどこか?)
    唐突に急激なリクエスト数が来てもサーバーは落ちないか(AutoScalingは効いてくれるか?)
  • デプロイなどを挟んでもサーバーは正常に動くか

といった事等を調べていきます。
本番で起こり得るような事象を前もって列挙し、それらに対して問題ないか、また、この構成の限界はどこにあるのか、そういう点を調査していく訳ですね。

ここまで来たら負荷試験のソースもしっかり整ってますし、後はリクエスト数を変えたりして動かしていくだけなので、負荷試験を行う事自体には苦労はしないでしょう。
ただ……ここからで何か起きたりした場合は、苦労する事になりがちです。
原因がイマイチ見えにくいところにあったり、どこも正常なはずなのに動いてくれなかったり、エラーレートが唐突に爆上がりしたり……。
粘り強くやっていきましょう。はい。それしかないです。

おじいちゃん、AWSでmemcachedのクラスターエンドポイントを指定しちゃうと、キーが一緒でも参照するたびにクラスターの中の別のホストを見てしまうんですよ

そして、10000RPSの負荷試験は、本番想定以上の負荷を掛けてサーバーは落ちないかという負荷試験で達成しました。

え? そんな負荷掛けて、どれだけのクラウド料金が掛かったのかって?
うーん……自分の給料の半年分くらいかなあ。
ちゃんと負荷試験やってない時はこまめにサーバー落としたりしても、その位行っちゃいましたね。
まあ、その甲斐あって、リリース後にサーバーが落ちたりする事はなく、何秒も掛かるようなAPIは……ちょっと出てきちゃったけど、即刻メンテに入れなければいけないレベルではなかったです。

「みんなで成長していきたい」ゲームデザイン部 白井将司 インタビュー

0

アピリッツでは若手幹部候補の育成を続けています。8月から新たに部長代行に就任したゲームデザイン部(GD部)の白井は、受託開発と運営のチームを率いています。抱負について語ってもらいました。(取材 2022年10月

―― 2020年にアピリッツに中途採用で参加されましたが、アピリッツを選んだ理由は?

自社開発のゲームタイトルがあるのでいいなと思いました! 社内だけでゲーム開発を完結できるのは大きな強みですし、実際に運用しているゲームが何本もあるのは魅力的でした。また、前職でスマートフォン向けゲームを開発していた時に、『ゴエティアクロス』のSDキャラを参考にモーションの発注をしたことがあって、知っているタイトルがあったのも決め手のひとつになりました!

また、アピリッツはゲーム開発だけではなくWeb開発も事業の柱になっている点で、会社が安定しているのも素敵だと感じました。会社の規模も小さすぎず大きすぎず、ちょうど上場前だったのもあって今後大きくなっていくだろうなという期待感もありました。

あとは面接で話をしたGD部の長谷部とアピゲー部の江中の雰囲気がとてもよかったからです! ゲーム開発の話をしたときに、コミュニケーションが大事であることや、各メンバーがある程度の裁量を持っているほうがやりやすいなど、自分が考えるよい仕事のやり方で話が通じたので、理想の働き方ができそうだと感じました。

ちなみに、オフィスの椅子が全部よい椅子で、社員を大事にしているんだろうなと思えたのもポイントが高かったです!

アピリッツのいい椅子。うしろにちらっと見えるのは図書コーナーの一部です

―― 実際に入社して働いてみてどうでしたか、白井さんの予想は当たっていましたか

はい、面接で話をした通りでした! それぞれのセクションと距離が近く、コミュニケーションを取りやすい環境で仕事がしやすいです。率先してやりたいことを言うと「やってみよう、考えてみよう」という雰囲気がすぐ生まれ、やることが決まれば「任せた!」と、ある程度の裁量を持ってやらせてもらえるのも素敵です(もちろん投げっぱなしではなく、サポートもしてくれますよ!)。

―― GD部はゲームの受託開発のチームで、白井さんはプロジェクトをまるごとひとつ見ています。「ユーザー」「クライアント」「社内のチーム」といくつか要素がありますが、どのように考えて働いていますか

ユーザーの反応は常に気にしています。受託開発なので、「クライアントの要望に答えられたら良い」、「クライアントが満足してくれたら良い」という考え方もあるかもしれませんが、それでもユーザーが一番大切だと感じます。

もちろん、クライアントもユーザーを一番に考えているので、同じ目線でゲーム開発するためにも、必要なことです。その方がよい提案ができますからね!

そしてクライアントに対しては、クライアントのやりたいこと・目指したいことを、どのように実現するか、いかによりよくしていくかを検討するだけでなく、こちらからもやれること・やった方がよいことをご提案できるように、常に意識しています。

あとは「どうしますか?」ではなく「こうするのがよいと考えている」と伝えるようにしています。考える部分や土台を作る部分をしっかり担って、クライアントには考える時間や労力を少しでも減らしてもらいたいと思っています。連絡を密に取ったり、担当者や責任者を明確にしたり、そういったことも大切です。

相手にできるだけ楽をしてもらいたいです(笑)

社内のチームに対しては裁量を重視しています。「あなたの作業については、ここまでは自分で考えてやっていいからね」と伝えて、自分で考えて仕事ができる環境を作る努力をしています。また、「誰に何を聞いてOKが出たら進めてよいのか」を明確にしています。そうすることで開発がスムーズに進みます。

―― 部長代行になって仕事の質や量はどんなふうに変わりましたか

劇的になにか変わったということは今のところありません。

ただ、今まではプロジェクトに対してフルコミットでしたが、今のプロジェクトを継続することで部全体・会社全体に対してどんなメリットがあるんだろうかと考えるようになりました。心持ち的には、ちょっとだけ高い目線で物事を見るようになったのかもしれません。

また、今まではプロジェクトのメンバーの働きやすさを常に考えてきましたが、部長代行になってからはGD部全体の働きやすさを考えるようになりました。長谷部(GD部の部長)との1on1や打ち合わせでもそういった話はしています。

――アピリッツでは1on1の文化が育ちつつありますが、1on1の効果はどんなところに感じますか

まだ始めたばかりで実感を強く感じるわけではありません。ただ、目標や今後の進路を意識しようねと伝えているので、それらを意識して働けるようになるといいなと思っています。こんな偉そうなことを言っていますが、メンバーのみんなは私と比べると若いのにしっかりしていますよ! 私が20歳前半の時は何も考えず遊び惚けていたので……(笑)

あとは、「自分がやりたかったこと」や「なんでプランナーになったんだっけ」といった原点を振り返るよい機会になります。

―― GD部をどんなふうに引っ張っていきたいですか?

「アピリッツに任せれば大丈夫!」とクライアントに思ってもらえるようになりたいです。

そのためには、今携わっているプロジェクトに対して「自分たちのプロジェクトで、自分たちが運用している」という当事者意識をより強く持つことが大切だと考えています。

まずはこれを私自身がしっかり体現することで、メンバーにも伝播してくれたらと思います。

そして、自分の成長はもちろん、メンバーの成長もしっかり促せたらいいななんてことをやんわり考えています。

Storybook for HTMLを使ってみた【準備編】

0

デジタルエクスペリエンス部デザイン&プランニンググループ所属Webデザイナーの今井です。
デザイン&プランニンググループはWebシステムやアプリ開発のチームとともに連携しながらのデザイン制作が得意分野でしたが、最近ではUXやビジネス要件定義という上流工程やReactなどフロントエンド案件に関わることも増えてきました。
今回はデザイン&プランニンググループとしても初めてとなる非常に大規模なコンテンツ制作案件を円滑にすすめるために導入したStorybook for HTMLについて書いていきます。

Storybookと使用目的

StorybookはUIコンポーネントとアプリケーションを切り離してコンポーネントを開発・管理できるツールです。
ReactやVueなどフロントエンドの開発で活用されることが多いのですが、今回は大規模なコンテンツ制作案件のため、コーディングに関わる人数も多くなり、スキルレベルも様々になるので、品質を一定レベルに保つことと作業スピードの向上を目的として導入しました。

Storybookのセットアップ

Storybookのインストールは公式にある通りに実行します
参考:https://storybook.js.org/docs/html/get-started/install

npx storybook init --type html

インストール中

Do you want to run the 'npm7' migration on your project?(y/n)

とでますが、これは何も入力しないでEnterでスキップします。

次にhtmlのコピーを簡単に行いたいので、アドオンを追加します

npm install @whitespace/storybook-addon-html

アドオンのインストールが終わったら、.storybook/main.jsにアドオンを追加します

module.exports = {
"stories": [
"../stories//.stories.mdx", "../stories//.stories.@(js|jsx|ts|tsx)"
],
"addons": [
"@storybook/addon-links",
"@storybook/addon-essentials",
"@storybook/addon-interactions",
"@whitespace/storybook-addon-html" //storybook-addon-htmlを追加
],
"framework": "@storybook/html"
}

main.jsを保存したら、Storybookを起動します。

npm run storybook

起動後ブラウザでStorybookを確認すると、HTMLタブが表示されます。

外部ファイルの読み込み

案件では共通のcssやjQuery、共通のjsファイルを読み込む必要があったので、Storybookでも同じ様に適用される様にしていきます。
storiesやnode_modules等と同じ階層にpublicディレクトリ を作成し、必要なファイルを配置します。

package.jsonを開き、scriptsの起動時にpublicが読み込まれるようにコマンドに -s ./public を書き加えます

"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"storybook": "start-storybook -s ./public -p 6006",
"build-storybook": "build-storybook -s ./public"
},

次に.storybookディレクトリにpreview-head.htmlを作成し、読み込みタグを書いて保存します。

<link rel="stylesheet" href="/common/css/style.css" />
<script src="/common/js/jquery-3.6.0.min.js"></script>
<script src="/common/js/common.js"></script>

Storybook再起動すると外部ファイルが読み込まれるようになります。

ブランドロゴの設定

Storybookはデフォルトでロゴ画像が設定されていますが、テーマの設定で変更することができるので、public内に配置したロゴ画像を出してみることにします。

テーマの設定に必要なファイルはmanager.jsYourTheme.jsです。
YourTheme.jsのファイル名は任意ですが、特に理由もないので公式のドキュメントの通りにします。
ファイルは.storybookディレクトリに配置します。

まずmanager.jsでテーマファイルを読み込む設定をします。

import { addons } from '@storybook/addons';
import yourTheme from './YourTheme';

addons.setConfig({
theme: yourTheme,
});

次にYourTheme.jsで任意のロゴに置き換える指定をします。

import { create } from '@storybook/theming';
import logo from "../public/common/img/logo_appirits.png"

export default create({
brandTitle: '任意のタイトル',
brandImage: logo,
})

指定したロゴに変わりました。

ロゴ以外にもテーマはいろいろと設定できるので、サイトのテーマカラーなどに合わせることができます。
参照:https://storybook.js.org/docs/react/configure/theming

Storybookの準備ができたので、次回【実践編】でコンポーネントを作成していきます。

Windowsでgitを使用する時に注意すべき設定【アピリッツクリエイターズナレッジベースから】

0

ES部の岡庭です。今回は以前担当していたプロジェクトのgit管理でつまづいた内容をまとめます。

はじめに

本題の前に改行コードというものについて少し話します。

テキストファイル等でエンターキーで改行した際「改行」を表す文字というかコードが打たれるわけですが、その「改行」の種類が複数存在します。
使うOSによって主流の改行コードが異なるようです。

  • Windows:CR+LF
  • Mac  :LF

⇒このCRとかLFとかいうのが改行コードと呼ばれています。

プログラマーがMac、プランナーがWindowsという環境では改行コードの統一が必要です。

どんな問題が起きるのか

SourceTreeやTortoiseGitを使用しているとチェックアウト/コミット時にgitがWindowsに合わせた改行コードに自動変換する機能(AutoCrlf)が初期設定時のデフォルトはtrueになっています。

この設定が混在した状態になると、pullしただけで 触ってないのに全ファイル全行に改行コードの差分が出る状態 になったりします。

git上では変更として全行真っ赤に差分検知されますが、目視で違いに気付くのは難しいです。

こうなると本当の差分が埋もれてチェックの妨げになるため、ConnectではWindowsでgitを使用するメンバーは全員AutoCrlfの設定を統一するようにしていました。

WindowsとMacが混在するプロジェクトで、git上でテキストファイル系(csv/html/xml等)を扱う場合に注意が必要です。

どう向き合うべきか

このAutoCrlfという設定自体は悪いものではなく、リポジトリにCRLFが混ざってしまうということをユーザーに意識させずに未然に防いでくれる機能なので通常はありがたいものです。

問題は、プロジェクトメンバーのAutoCrlfの設定が統一されていないことで、falseユーザーがCRLFのままコミットした状態で、trueのユーザーがチェックアウトするとそれ以降全部のファイルが差分検知される状態になってしまいます。

設定値チェックアウト時コミット時
trueLF → CRLFCRLF → LF
input変換しないCRLF → LF
false変換しない変換しない

設定の種類は表の3種類があり、windows作業者は基本的にはtrueかinputで統一しておくのが安定なのかなと思いました。

エンジニア側でビルド前にLF置換作業を行う等のセーフティネットがあるのであればfalse統一でもいいかもしれませんが、falseとそれ以外が混ざると混乱が生まれるのでプロジェクト全体で方針を決めるのが良いと思います。

変更方法

初期設定で設定をtrueにするか選択できるようになってますが、初期設定をすり抜けた場合の修正方法が少しわかりにくかったので紹介します。

SourceTreeの場合

操作 > ターミナルで開く > 黒画面のターミナルが開くので以下のコマンドを入力しEnter

git config --global core.autocrlf 【設定値】

【設定値】には、true / input / falseの何れかを指定

TortoiseGitの場合  

TortoiseGit > 設定 > 設定の出どころ[グローバル] > 自動改行コード変換[AutoCrlf]のチェックボックス

まとめ

gitの設定で勝手に改行コードが変わって、覚えのない差分が出ることがあるというお話でした。

専門分野ではないので説明に不足があったかもしれませんが、詳しく調べたい場合は以下のキーワードで検索すると詳細な記事がたくさんあります。

  • AutoCrlf
  • git 改行コード自動変換

アピリッツは働く仲間を募集中! 採用ページはこちらです!

資格ってホントに役に立つの? アピリッツの若手エンジニアがAWS認定資格を勉強する理由(後編)

0

「2022 APN ALL AWS Certifications Engineers」に選出された21卒入社の串田 匠彌(くしだ たくや)と、今まさにAWS認定資格の勉強を続ける22卒入社の澤入 広(さわいり ひろ)に、胸の内を率直に語ってもらうシリーズ第二弾。今回は「AWSの資格や勉強は、仕事で役に立つの?」というテーマでぶっちゃけてもらいました。今回の聞き手も、アピリッツCDXOの西脇です。 (取材 2022年9月)

「テストと実務は別」だけど?

AWS認定資格のテストは、知識を頭に入れて、それでテストをうけて、合格しますよね。実際の仕事とのギャップはありますか? あと「これ役に立ったな」って点も知りたいです。

AWSのサービスの概要についてパッと調べてすぐ理解できるのは、開発の現場でとても役に立ちます。社内のAWSで困っている人の手助けができるようになったのも、すごくうれしい。前は「何が課題なのか、どうすれば解決するのか」がわからなくて、つらかったんです。

資格勉強をやったおかげで、とにかく調べる時間が圧倒的に減りました。考えている時間とタスクを終わらせるスピードが違ってくる。

たとえばお客様から「こんなソリューションを導入したい、こんなシステムを構築してほしい。AWSでどんなサービスを使えばいい?」とご相談いただいたときに、「調べてあとで回答します」じゃなくてその場で「コレです!」とちゃんと回答できる。

仕事全体を進める速度が上がるっていうのはその通りですね。もう一つの大きなメリットは、お客様からも信頼して頂ける点だと思います。お客様とお話ししているその場でバンバン! と回答できると、ファンになってもらえるし、次の打ち合わせを楽しみに待ってくれる(笑) 

たしかに、いろんなことをご相談頂けるようになっていますね。

うん、そうなるとね、いい状態でプロジェクトを進められます。これって自分たちのやり方1つで変えられることなんですよ。別にPMだけがすべてをコントロールしているわけじゃなく、開発に関わるスタッフ全員で信頼度を積み重ねていける。そのほうが良いものを作れるんです。お客様も僕らもうれしい。

自分はまだその境地に達していないというか、まだ課題はたくさんあるなと感じています。ただインターンで働き始めたころと比べると、勉強を続けて理解できることも増えてきました。だから、もっとインプットしなきゃなと毎日思っています。

澤入さんはアウトプットが得意なタイプだと思うんです。業務上のコミュニケーションはとても上手い。つまり、アウトプットはできているのだから、あとは知識のインプットを頑張ればいい。

アウトプットができるって大事ですよ。

AWS認定資格の話に戻りますが、「テストと実務は別だよね」っていう意見は世の中に一定数あります。僕はそれは正解でもあると思うけれど、それは「テストで学んだことが役に立たない」って意味では決してないとも考えています。

知識を身につけて、イチから調べる頻度が減るのは大きなメリットです。料理も慣れると早くなると思うのですが、それと似ているかも。慣れていないと「猫の手でこうやって切って……!」とか少しずつやりますよね。

初めて料理する人はレシピをいっぱい見るし、「大さじ1とは?」って考えるけど、慣れると味付けもチャチャっとできるもんね。

猫の手!の串田さんと、それを眺める澤入さん

「お客様に本当に必要なこと」をどう見極める?

串田さんも澤入さんも、社会人になってまだ1~2年ですが、未来予想を聞かせてください。

一生コーディングしていることはなさそうだなと思っています。技術を身に着けているという前提で考えると、お客様のビジネスを把握した上で、お客様のビジネスを技術面からサポートできる人になりたいです。本当に必要なことだけに特化して開発を進める立場の人間になっていくんじゃないかなと思っています。

串田さんの言う「(お客様に)本当に必要なこと」って、どう見極めていくのがいいんだろう?

最優先にすべきことは、お客様のビジネスを理解することだと思います。そのビジネスに必要な機能だけを実装できるようになりたい。それって技術的な知識だけでなく、理解力も求められるのかなと思います。

エンジニアとして仕事をしようと思う人は、ビジネスじゃないところで生きていきたいケースが多いかもしれません。「ひたすらコードを書いていたい!技術を磨きたい!」って。

職人気質と呼べるでしょうし、尊いものなのですが、その仕事って彫刻で例えるなら、彫刻を作る職人さんではなくて、彫刻を彫るためのノミを研ぐ職人さんの仕事なんですよ。研ぎ師。その研いだノミは、もちろんすごく鋭くていい道具ですよ。

でもね、そうはいっても僕らアピリッツの仕事は、あくまでその鋭いノミを使っていい彫刻を彫ることなんです。ずっと研いでばっかりじゃダメ。技術を使って良質な開発をして、お客様に納品するのが仕事。

たしかに使う技術ベースで話をするのと、お客様からの要件ベースで話をするのだと、おそらく後者のほうがプロジェクトとしては上手く進むように感じます。

「技術者としての好奇心」と「ビジネス」のバランス

とはいえ、技術に特化したい研ぎ師的エンジニアの気持ちもわかるんですよ。ずっと同じことを繰り返すのは飽きるし、やりたくない。やっぱり新しい技術的チャレンジが欲しいんです。そういう要素は仕事にちょっと入っていてほしい。

だから、技術的挑戦をどのくらい、どのタイミングで入れるか、いかに彼らが挑戦できる環境にするかはいつも考えています。たとえば「お客様のビジネスを成功させるには、この新しい技術は絶対に必要だ」と判断したら、提案の段階で入れます。たとえそれが初めてのチャレンジでも「僕らなら、AWSからのバックアップも得られます」って説得する

ビジネスを優先させるためだけに技術者としての好奇心を殺すのはよくないし、知識や技術にこだわることは仕事じゃない。バランスを取っていくのがIT業界ではすごく大事だと思います。

バランスのことを話す西脇さん

AWSの勉強だけじゃ身につかないこと

自分は今まさに選択肢があり過ぎて迷っている状態です。最近鈴木さん(FS部の部長)との1on1でもこの話になりました。

インフラにも片足を突っ込み、バックエンドもやらせてもらって、ちょっとわからないな……と思っていると正直に話したら、鈴木さんに「それ、100%迷子になるよ!」と予言されてしまい、いろいろと考えているところです。

AWSに限らずいろんなことを勉強し、経験を積んで、やがてトータルで考えられるようになったら、その終着点はPMのような全体を見る人なのかなと考えています。

AWSに限らずいろんなことを勉強するのはいいことだと思います。たとえばDockerの知識がないとECSはまともに使えないし、サーバレスで行くなら、要件に沿ってFargateを使ってコンテナサーバレスにするのかAPI Gatewayとか使って完全にサーバレスにするのかを判断しないと、あとあと面倒なことになるんです。そういう判断はAWSの勉強だけじゃ身につかないので、広く掘り下げていく必要があります

知識をもつこと自体は仕事じゃないんですけど、技術に詳しいことは立派な武器になりますね。ということで澤入さん、最終的にはAWS認定資格の全制覇を狙ってね。期待してます!

アピリッツの採用ページはこちらです!

120万円以上の報奨金? やりがい? アピリッツの若手エンジニアがAWS認定資格を勉強する理由(前編)

0

AWS認定資格を取得するエンジニアがアピリッツには多数在籍しています。そして、AWS認定資格をすべて取得するエンジニアも増えてきました。モチベーションってなんなのでしょう? 若手でも取れるもの? もともと勉強は好きだった? 「2022 APN ALL AWS Certifications Engineers」に選出された21卒入社の串田 匠彌(くしだ たくや)と、今まさにAWS認定資格の勉強を続ける22卒入社の澤入 広(さわいり ひろ)に、胸の内を率直に語ってもらいました。聞き手はアピリッツCDXOの西脇です。 (取材 2022年9月)

ぶっちゃけ、お金だよね? ……というわけでもなかった資格全制覇の動機

去年からアピリッツは「APN表彰手当」という社内制度を作って、社を挙げてエンジニアのAWS認定資格取得を応援しています。この成果はちゃんと出てきて、社内のエンジニア達のあいだでAWS認定資格の勉強が盛んになってきました。「この資格試験に合格しました」って報告が僕のところにもたくさん届いてる。

やっぱりこれって「APN表彰手当」が120万円以上出ることが大きいのかなと想像しますが、実際はどうなんだろう?

関連:アピリッツが報奨金総額120万円以上の「APN表彰手当」を始めた理由

自分の場合は、報奨金の総額120万円はもちろん魅力でした。モチベーションの4割くらいはお金だったと思います。

残りの6割は?

好奇心ですね。「APN表彰手当」が始まったとき、社内では「そんなの、ハードル高いよ」って声があがっていました。一部のベテランエンジニア以外は無理なんじゃないか、って空気感だったと思います。

「AWS認定資格を全部取る前に、段階的に出る報奨金が増えたらいいのに」という声がありましたね。でも、あくまで「全部取る」にこだわった。

で、ちょうど入社まもない串田さんが「ソリューションアーキテクト-プロフェッショナル(以下、SAP)」を取ったから、マネージャー陣は「彼は全部行けるんじゃないかな」って思った

関連:4月入社の新人がAWS Certified Solutions Architect-Professionalに合格した話

「入社一年目で無理なんじゃない?」って風潮も確かにあったけれど、「それ、本当かなあ?」と思ったんです。本当にダメなのかどうかを、限界までやって自分で確かめたかった。高校球児が甲子園を目指して精一杯がんばるような働き方にチャレンジするのも面白いかもなと思いました。

それに報奨金もいい臨時収入になるし、きっと実務もできるようになるだろうし、会社での評価も上がる。じゃあ試そうか、って。

試したら、全部とれちゃった。

去年串田さんがAWS認定資格をコンプリートした事実を、今年入社した僕らは知っています。だからもう「若手には絶対に無理」とは思っていません。道を切り拓いてくれた先輩がいるし、さらに報奨金でグッと後押ししてもらっています。

今年もFS部部長の鈴木さんが「AWS認定資格を勉強するエンジニアを増やそう!」「みんなで受けよう!」ってムーブメントを作っていますね。

をね、かけてますね。

どれかひとつのAWS認定資格に合格して「受かりました」って鈴木さんに報告しに行くと「おう。で、次は何を受けるの?」って言われていました(笑)

関連:「5年後、10年後のキャリアだけじゃなく、30年後も考えよう」メディアサービス部(現・FS部) 部長 鈴木利夫 インタビュー

合格発表はドキドキする?

勉強をして、受験して、結果を見るときは緊張した?

試験直後に自分ですぐに結果を確認できるのに、最初に受けたとき僕はそれを知らなくて、結果のメールが届くのをドキドキしながら待っていました。

澤入さんが「受けたんですけど、まだ結果がわからない……!」と言ってて、「いやそんなはずないでしょ、受けた直後にわかってるよ!」って(笑)

紆余曲折ありつつ、受かったことがやっとわかって「ああよかった」と思いましたが、うれしかったのは一瞬で、「さあ次は何を取ろうかな」って。次はSAPを受けます。

利夫(注:FS部部長・鈴木のこと)のが効いてる(笑)

一番印象に残っているのは最後の試験です。問題を解きながら「ああ、受かるな」と思った。でその場で合格がわかってガッツポーズして、受験会場を出て「さあどうしようかな」って。

全制覇して、自分で合格祝いとかはしたの?

いやなにも(笑) で、合格がわかったその足で会社に行って、鈴木さんに「さっき(全部のAWS認定資格に)受かりました」と報告しました。そしたら「そっかあ……」って。「もうちょっと何かあるだろ!」と思いましたが(笑)

うれしかったんだろうね。

そう思います。「そっかあ……」のあと、すぐに「ここからAWSに申請できるから、やっといて〜」って教えてもらったので、やっぱり気にかけていたのかなぁ、と。

勉強って好き?

ふたりとも、もともと勉強は好きな方?

勉強はあまり好きではありませんが、、何もしないと不安なので、安心感を得るために勉強をしています。

私はインターンでアピリッツに入ったので4月に入社したときには仕事にも多少は慣れていましたが、それでも変化が激しいWEB業界でやっていけるのか不安でした。

きっと慎重なタイプですよね。澤入さんの仕事ぶりをSlackで見ていると「細かい報告もちゃんとしてくれる人だな」と思います。変化や検討状況を細かく共有してくれる。これができるかどうかって、新人とかベテランとかは関係ないんですよね。仕事をする上で、「これは有用で意味がある」って思ってできているかどうかの違いじゃないかなと。そして、周りにちゃんと伝えているほうが、頼む方もやってる本人も安心だなと思います。

串田さんはどう? 勉強好き?

自分の場合、「勉強する」っていうのは「気になったことを調べている」だけなので、それを勉強って呼んでよいのであれば好きですね。エンジニアは、開発で「なぜタスクでこれをやる必要があるのか?」と疑問を持って、それを突き詰めて調べるのが大事なんじゃないかなと思っています。

理由が自分なりにハッキリしていないと、何らかの答えを出したときに自分で腹落ちができないんですよね。自分で理解して答えを導き出すと、それは暗記じゃない形で頭にずっと残る。若手のうちからそのクセを身につけると、その後もナチュラルにできるんじゃないかな。

そのうち「何もしない週末」が耐えられなくなる(笑)。僕、こないだ自分の誕生日に「この土日は何もしない!」と決めていたのに、日曜の夕方になんだかすごく虚しくなった。「もったいねー!」って(笑)

私も同じく、AWS認定資格の受験勉強中は通勤の電車の中でずっと勉強していたんですが、受験が終わったあとに参考書を持たずに電車に乗ったら「あれ?」って思いました

澤入さんは、週末もちゃんと勉強するタイプの人なんだなと思います。そうしないと多分合格は難しいから。

―― つづきます!

お勧めユーザー選定方法考察

0

アピリッツ コンテンツデザイン部の金井と申します。今回は膨大なレコード数を保有するテーブルからのランダム抽出に関して書いていきます。

結論

元々ある莫大なテーブルから愚直にクエリを叩くのではなくて、別にテーブルを作ってそこから効率的に参照するようにすれば良いと思います。

良くある仕様相談

プランナー「ゲーム始めたてのユーザーにもフレンド機能を積極的に活用して欲しいから、以下の条件でお勧めユーザーが出るようにしてくれない?」

  • チュートリアル完了済み
  • フレンドでない
  • BANユーザーでない
  • フレンド数がMAXでない
  • 3日以内にログインしている
  • ユーザーとのプレイヤーランクの差が-5~+5以内
  • お勧めユーザーとして出る事を許容している

サーバーエンジニア「りょーかい。(クエリ叩いて該当するユーザーを検索して指定数絞り込むだけだから……うん、そんな時間掛からないかな)1~2営業日で実装できますね」

はい、落とし穴です。

愚直に実装した結果

例えば、以下のように愚直にクエリを叩くような実装にしたら、

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_DATE_RANGE = 3
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30
def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids

  recommend_users =
    User \
    .where("? < last_login_at", time - RECOMMEND_SEARCH_DATE_RANGE.day) \
    .where(rank: (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)) \
    .where.not(id: except_user_ids) \
    .where(is_allow_recommend_search: true, is_tutorial_finished: true) \
    .order(:last_login_at) \
    .limit(RECOMMEND_SEARCH_LIMIT_COUNT)
    .to_a

  friend_counts = 
    Friend \
    .where(status: Friend.status_value(:friend), user_id: recommend_users.pluck(:user_id)) \
    .group(:user_id).count
  recommend_users.select! { |user| friend_counts[user.id].to_i < MAX_FRIEND_COUNT }
  recommend_users.sample(RECOMMEND_SEARCH_SAMPLE_COUNT)
end

幾らインデックスをきちんと張ってようとも、QA検証まで恙無く通っても、負荷試験で莫大なユーザー数を登録するような試験を行うと、死ぬと思います。

もし、そのままリリースしてしまったら、その機能で数秒待たされるとか、そんな事が頻発したりだとか……。
原因としては、上記の仕様においてはユーザーを一意に絞り込めるような条件が存在しないので、ユーザーが増えれば増えるほど、クエリの負荷が増大していく訳ですね。

リリース1週間前までずれた負荷試験で平均レスポンス10秒越えのAPIが出ちゃったか〜……帰りたいなぁ……

じゃあ、どうしたら良いんでしょうか。
個人としての現状のベストとしては、以下です。

改善への考察

まず、現状の実装の問題点や、仕様でもうちょっと絞り込めるようにして良いような部分を見つけましょう。

現状の実装の問題点としては、愚直にクエリ検索をする一番のデメリットは、ゲームが繁盛するに連れて検索量が莫大になっていってしまう、って事ですね。

また、仕様を見返してみてみると、一番優先度の低いと言うか、もっと厳しくして良いものが一つありますね。

  • 3日以内にログインしている

繁盛しているゲームならこれを1時間以内、とかにしても良いと思いますし、それで検索量も一気に減って解決! とかなると思うんですけど、繁盛していないゲームになると、深夜にアクセスされた時には、工夫しないと何も検索結果として出てこないとか有り得そうだったり……。

まあ、この2点から考えると、最後に何らかのアクションを起こしたユーザー群から絞り込む、で良いんじゃない? って発想が浮かんできました。
要するに、別にお勧めユーザー検索用のテーブルを作り、そこにトリガーとなるアクションを起こしたユーザーを入れて、その末尾のレコード数十件を引っ張ってくるって形ですね。
そういう形ならば、幾らユーザーが増えようとも参照量は一定ですし、時間帯で検索に引っ掛からなくなるような不安もなくなります。

ただ……この手法にも欠点がない事もなくて。
ゲームが過疎ってしまうと、同じユーザーばっかり抽選されるようになります
この手法はお勧めユーザー抽選以外でも、アクティブなデータからの効率的な参照方法として使えると思いますが、ゲームそのものが過疎らなくても、その機能が余り使われなくなるとか、そういう要因でこの事象が発生してしまう可能性はぼちぼちあります。

そういう点も留意した上で、プランナーに今のままの仕様じゃサーバーが死ぬ事と、これこれこういう理由で、ここの仕様をこう変えて貰いたいという事を伝えて、首を縦に振って貰って、改修しましょう(振ってくれない? ……その時は青い空の広さをぼんやりと眺めましょう)。

書き換えたら多分こんな感じのソースになる

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30

# フレンド数が増減した、お勧めユーザーランクが上下した、ログインした、などの各種トリガーの度に呼び出す
def check_user_recommend
  # lastで参照する為、古いデータは削除する
  UserRecommend.where(user_id: self.id).delete_all

  return unless self.friends.where(status: Friend.status_value(:friend)).count < FRIEND_COUNT_MAX
  return unless self.is_allow_recommend_search
  return unless self.is_tutorial_finished

  UserRecommend.create!(
    user_id: self.id,
    user_rank: self.rank,
    ...
  )
  end
end

def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids
  rank_range = (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)

  recommends =
    UserRecommend \
    .where(user_rank: rank_range) \
    .where.not(user_id: except_user_ids) \
    .last(RECOMMEND_SEARCH_LIMIT_COUNT)

  User.where(recommends.sample(RECOMMEND_SEARCH_SAMPLE_COUNT).pluck(:user_id))
end

対象ユーザーを抽出する部分がとってもスッキリしましたね!

ごめんなさい。ここの部分の仕様が、SV的にとても危ないものだと分かったので、これこれこういう風に修正しました。なので、非常に申し訳ありませんが、ここの部分だけ再度QAをお願いします。挙動としてはこことここの部分がこんな風に変わっている以外は特に変わりありません。本当に申し訳ありませんがよろしくお願いします。

没案

ユーザー単位に1~100くらいでランダムな数字を振ったりして、その値を参照される度にランダムに指定し、数値が合致するユーザーだけを抽出する。
=> QA検証的にも分かりづらいし、本番で不具合が起きても検証出来ない

検索を全ユーザーDBからではなく、自分の属するユーザーDBのみからにする。
=> ……妥協案で敗北した気分になるから嫌だ。

住み心地はどう? アピリッツ社員寮「アピトリー」、入居者インタビュー・女性編

0

アピリッツは2022年から社員寮を導入しました。2023年の本格運用に向けて、先行で何名かのアピリッツ社員がモニター入居しています。入居のきっかけや手続き、そして肝心の住み心地について教えてもらいました。(取材 2022年8月)

→前回の男性編はこちら

「ひとり暮らししたいな」と思っていた

―― 社員寮に応募したきっかけを教えてください。

私は実家が都内にあります。アピリッツに入社した当初は実家から通っていたのですが、「社会人になったことだし、そろそろひとり暮らししたいな」と思っていました。でも、初めてのひとり暮らしを家族は心配していましたし、費用もかかるので、二の足を踏んでいたんです

そうこうしているうちに会社で「社員寮はじめます!」とアナウンスがあり、応募することにしました。

―― 社員寮なら、ひとり暮らしのハードルが下がりますよね

まず、部屋を借りるときの初期費用が社員寮なら不要なのがいいなと思いました。手続きも人事のみなさんが進めてくれて、電気やガスや水道の手続きもおまかせできました。

あと家族が「社員寮なら、いいよ」と賛成してくれたんです。「万が一何かあったときに安心だろう」って。

―― セキュリティの面でも安心ですか?

私が入居している寮はマンションタイプで、一階の共有エントランスも鍵がかかっています。あと寮母さんが常駐しています。

川沿いで暮らす夢が叶った

―― 寮は月島にありますね。街の雰囲気はいかがですか?

川沿いでとても気持ちのいい場所です。治安もよくて、スーパーマーケットも近くて、なにより銀座のすぐ近くなのでとても楽しいです! お台場へのアクセスもラクです。月島の家賃相場で考えると、私が今払っている家賃は格安だなと思います。会社が家賃負担をしてくれるのでありがたいです。家賃+水道光熱費+通信費で6.5万円ほどで生活しています。

―― 社員寮に入ったことで通勤時間は短くなりましたか?

5分短縮されました。勝どき駅から寮までは徒歩7分くらいです。駐輪場も借りたので、週末は自転車でいろんなところに出かけています。月島、楽しいですよ!

―― 寮にお友達は呼べますか?

基本的に同性の友人は入れます! 騒ぎすぎなければお泊りも可能です(笑)!

音は? 普通の賃貸との違いは? 気になる住み心地

―― お部屋のクオリティはいかがですか?

新築ではありませんが、壁の厚さもじゅうぶんですし、周りの生活音も聞こえません。Wi-Fiの速度も問題なしで、リモートワークにも対応できます。ワンルームなのでリモートワークと生活のメリハリをつけることが最近の課題ですね。

私が入居した寮は自分の部屋にキッチンやバスルームがあります。食堂はついていませんが、私は自炊したかったのでちょうどよかったです。

――引っ越しの荷物はどのくらいでしたか?

衣類など身の回りのものを大きなスーツケースに3こ分くらい持ってきました。ベッドと机と小さな冷蔵庫はすでにお部屋にあって、自分で揃える家具はあまり必要なかったのも寮でよかったポイントだなと思います。洗濯機も共用ですが待ち時間は全然ありません。好きなときに洗濯できています。

私が自分で持ち込んだ家具は、自炊用にもう少し大きなサイズがほしかったので冷蔵庫と、電子レンジ。あとはテレビです。ちなみにテレビは会社の懇親会の抽選で当たったものです(笑)

ということで身軽に入居できました。

通勤時間・広さ・街の雰囲気、何を優先する?

―― しばらくは社員寮に住み続けますか?

はい!快適ですし、月島も大好きなので、長く住み続けたいです。

―― 今後もアピトリーに入居する社員はたくさんいるはずです。アドバイスできることは?

社員寮を検討される方は、新卒採用で地方から東京に初めて来る人もいらっしゃるはずです。そうすると最初の部屋選びってきっと迷うと思うんです。ひとによって何が優先事項なのかも違うでしょうし。なので、ぜひ私に相談してください。「この駅は朝の通勤時間はとても混んでいるよ」とか「ここはいろんなお店や街に近くて便利だよ」とか、いろいろアドバイスできると思います!

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

アピリッツの採用ページはこちらです!

最近人気な記事