GameWith Developer Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

UX MILK Fest 2019にスポンサーとして協賛します #uxmilk_fest #GameWith #TechWith

こんにちは。GameWithのエンジニアのtiwuです。

この度、UX MILK Fest 2019にスポンサーとして協賛することになりました!

uxmilkfest2019.studio.design

当日は来場者の方にノベルティが配布されるのですが、弊社からは社内デザイナーが制作したデザインマネージャー採用のお知らせチラシをお渡しいたします。チームが求める人材について熱く語っておりますので、ぜひ目を通していただけますと幸いです...

f:id:tiwu:20190913143156j:plain

当日はGameWithのデザイナーが複数名参加するので、一緒に楽しみましょう!

さいごに

GameWithでは一緒に働く仲間を募集中です!

毎月もくもく会なども開催しているので、気軽に連絡ください!

hrmos.co

GameWith フロントエンド もくもく会 #14 開催しました #GameWith #TechWith #gamewith_moku2

こんにちは。GameWithのエンジニアのtiwuです。

8月29日(木)にGameWith主催で第14回目のもくもく会を開催しました!

GameWith フロントエンド もくもく会 #14

gamewith.connpass.com

今回のテーマも前回に引き続き、僕自身が関心を高く持っているフロントエンドを採用しました。

今回は社内1人、社外7人の合計8人で開催しました!

f:id:tiwu:20190329134140p:plain

もくもく会は最初にお知らせ、次に自己紹介と今日のもくもく内容を発表して、もくもくし、最後に進捗発表という流れで開催しました!

2時間ほどもくもくしたら本日の進捗の発表をしました!

  • Firebase functions + Express + Web Componentsの開発
  • 新しいJSフレームワークの作成
  • enebularを利用したIoT開発
  • ReactのSSRでブログを作成
  • 「JavaScriptコードレシピ集: スグに使えるテクニック278」で勉強
  • PWAのpush通知の実装
  • 画像をフロントで圧縮しFirebaseにアップロード機能の実装
  • Vue.jsを利用したtodo listの実装

といった様々なテーマの取り組みのもくもく会でした!

新しいJSのフレームワークの作成は驚きました!完成が楽しみです!

次回告知

次回は9/26に開催します!次回のテーマはiOSです!

gamewith.connpass.com

最後に

参加していただいた皆様ありがとうございました!

GameWithのDeveloper向けTwitterアカウントを開設しました。

もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

DIKitで人間がクラス間の依存関係を解決するのを終わらせる #GameWith #TechWith

こんにちは、つい最近入社したiOSエンジニアのみなみ(@yuuxeno)です。

DIKitとは、AndroidのDaggerの影響を受けて作られた、iOSアプリ開発(Swift)でも使える、コード生成型のDIライブラリです。コード生成でDIを実現する仕組みは他の言語にも存在し、例えばGo言語にはWireというツールがあります。

先日、potatotips #64において、DIKitについての発表(下のスライド参考)をしました。


今回は、 DIKitとは何なのか?コード生成でDIを実現するメリットとは?などについて、発表した時とは違う話の構成で、ブログ記事で紹介したいと思います。

はじめに

コンポーネント間の依存を解決し、そのコードを書く。ということを、ソフトウェアエンジニアは日常的に何度も行います

例えば、iOSであればViewControllerが単体で使えることは稀です。PresenterやViewModelなど、ViewControllerは大抵なんらかのクラスに依存しています。

// ViewControllerはViewModelに依存
let viewController = ViewController(viewModel: ViewModel())

ViewControllerだけでなく、ViewModel(もしくはPresenter)も大抵なんらかのクラスに依存しています。

// ViewControllerはViewModelに依存、ViewModelはModelに依存
let viewController = ViewController(viewModel: ViewModel(model: Model()))

ViewControllerが依存しているものを"目"で確認します。すると、ViewModelに依存してることが分かりました。今度は、ViewModelが何に依存しているかを確認します。どうやらViewModelはModelに依存しているようです、、、。この間、Xcodeのコード補完の助けを借りながらも、"手"で何度もキーボードをタイプします。この作業をひたすら繰り返します

ViewControllerを生成するというたった1つのことに対して、"人間"が"目"で何度も確認して、"手"でキーボードを何度もタイプしてコードを書く必要があります。

ViewControllerも、ViewModelも、Modelも、1つのアプリにそれぞれいくつもあります。この単純で退屈な作業を、人間が何度も繰り返しています。

人間が依存関係の解決をすることで起こること

DIできない

class ViewController {
    // 生成処理が直接書かれている
    let viewModel = ViewModel(model: Model())
}

ViewController内でViewModelを直接生成しています。ViewControllerに限らず、これは結構あるあるパターンだと思うのですが、何が問題なのでしょうか?

まず、ViewControllerを単体でテストするのが難しくなります。ViewModelをモック用のオブジェクトに差し替えることができないからです。

コードの見通しが悪い

また、ViewControllerにとって重要なのは、ViewModelが使えるかどうか、それだけです。ViewModelがどのように生成されるか(この例ならModelが必要とか)は、ViewControllerにとって知る必要のないことです。

そのクラスがどんな機能持つかと、そのクラスが依存しているオブジェクトの生成方法は、別の種類のものです。全く異なる種類の処理が1つのクラスにあまりに増えることは、コードをぱっと見で把握するのを難しくします。

依存関係を解決する処理を人間が管理する必要

protocol AppResolver {
    func resolveViewController() -> ViewController
}

final class AppResolverImpl: AppResolver {
    // ViewControllerの依存関係を解決する処理
    func resolveViewController() -> ViewController {
        return ViewController(viewModel: ViewModel(model: Model()))
    }
}

let viewController = appResolver.resolveViewController()

今度は、AppResolverという依存関係を管理する専用の場所を作りました。
AppResolver内で対象のクラスに依存性を注入できるようにし、依存関係を解決する処理をAppResolverに分離します。
ViewControllerは単体でテスト可能になりました。依存関係を解決する処理が分離されたことで、ViewControllerのコード自体も少しすっきりしたことでしょう。

これで色々な問題を解決することができました、、、本当にそうなのでしょうか?

依然としてViewControllerの依存関係は、"人間"が"目"で確認し、キーボードを"手"でタイプして解決する必要があります。

なにより、人間が書いたコードは、人間が管理する必要があります。ミスがある可能性があるからです。
例えばメソッド名などが規約通りなのかは、コードレビューで人間がチェックする必要があります(resolveViewControllerでなく、resolveVCになっていないかなど)。
また、引数名や引数自体が変更になった場合など、それぞれのコンポーネントが依存するものに変更があった場合、その修正も人間がする必要があります。

DIKitが可能にすること

DIできなかったり、依存関係を解決する処理が整理されていない、というのは良くあることです。

何故なのでしょうか?DIについての知識がたまたま無かった、かなり急いでいた、、、。理由は色々あるように思えますが、突き詰めれば、依存関係の解決を"人間"がするからではないでしょうか?

人間がするからミスが発生します、全ての人が全てのことに詳しいわけではありません、人によりコードに差が出ます、そしてこれらが色々なところで繰り返されます

解決策はないのでしょうか?

もしかすると、これから紹介するDIKitというライブラリが、1つの選択肢になるかもしれません。全ての問題を解決できるわけではないですが、依存関係の解決を人間がすることの煩わしさを、DIKitにより軽減できます。

DIKitとは?

DIKitとは、コード生成によりDIを実現するためのライブラリです。

DIKitライブラリには、コード生成を行うコマンドラインツールであるdikitgenが含まれています。dikitgenは依存関係を解決 & その処理をコード生成します。これにより、今まで人間が行なっていたクラス間の依存関係の解決を、部分的に自動化することができます。

DIKitは実際に使ってみて真価が分かる系のライブラリです。このライブラリを使うことにより、Xcodeの実行ボタンを押した時(dikitgenが実行された時)に何が起こるのか、ざっくり簡単に説明したいと思います。

ViewController, ViewModel, Modelの3つのクラスがあります。ViewControllerはViewModelに依存、ViewModelはModelに依存しています。
ここで、他のものに依存しているViewController, ViewModelについては、それぞれprotocol Injectableを実装します。
他のものに依存していないModelについては、AppResolver(AppResolverImpl)にその生成処理を追加します。

// ViewController
class ViewController: Injectable {
    struct Dependency {
        let viewModel: ViewModel
    }

    required init(dependency: Dependency) {...}
}

// ViewModel
class ViewModel: Injectable {
    struct Dependency {
        let model: Model
    }

    required init(dependency: Dependency) {...}
}

// Model
protocol AppResolver: Resolver {
    func provideModel() -> Model
}

final class AppResolverImpl: AppResolver {
    func provideModel() -> Model {
        return Model()
    }
}

これで準備は完了です。Xcodeの実行ボタンを押しましょう。

コード生成されるときの様子

f:id:yuuxeno:20190902124737g:plain

生成されたコード

extension AppResolver {

    func resolveModel() -> Model {
        return provideModel()
    }
    
    // ViewControllerの依存関係を解決する処理
    func resolveViewController() -> ViewController {
        let viewModel = resolveViewModel()
        return ViewController(dependency: .init(viewModel: viewModel))
    }

    // ViewModelの依存関係を解決する処理
    func resolveViewModel() -> ViewModel {
        let model = resolveModel()
        return ViewModel(dependency: .init(model: model))
    }

}

今まで手動で書いていた依存関係を解決する処理が、一瞬でコード生成されました。
これぐらいのサンプルコードであれば、手動で依存関係を解決するメリットがあまり感じられないかもしれません。

しかし、そこそこの規模のアプリで、今まで何行も手動で書いていた大量の処理が、一瞬でコード生成され、DIKitの管理下に入る。そんな光景を見ると、このライブラリの持つポテンシャルの高さを感じることができます。(ちなみに後述するのですが、依存関係を解決する全ての処理をコード生成できるわけではないので、その点は注意が必要です)

DIKitでできる

人間の代わりに依存関係を解決

依存関係の解決というのは単純なパズルです。必要なピースは全て決まっていて、あとはひたすらそれをコード全体から集めてくるだけです。その単調な作業をDIKitに任せることができます。

依存関係を解決するコードの管理

それぞれが数行の依存関係を解決する処理でも、プロジェクト全体だとすごい量になります。DIKitはその大量の依存関係を解決する処理を、人間の代わりに管理してくれます。人間が管理する処理を少しでも減らすことができるのは、大きなメリットです。

プロジェクト全体をDIできる仕組みの提供

今はプロジェクトの度に、アプリ全体としてどう依存関係を解決するのかを考える必要があります。依存関係を解決する専用の場所を作るのか、必要なところでそれぞれ依存を解決するのか。依存を解決する処理の規約をどうするのか、、、などです。

依存関係を解決する処理はとても普遍的なものです。星の数ほどあるアプリ、それぞれで独自の仕組みを1から考えるのは効率が良くない気がします。

DIKitは単に依存関係を自動で解決してくれるだけでなく、プロジェクト全体をDIできる仕組みも提供します。DIKitの規約に従いながら、依存関係を解決すれば、あなたのプロジェクトは自然とDIできるものになります

DIKitでできない

全ての依存関係を自動で解決することはできない

DIKitで自動(コード生成)で依存関係を解決できないパターンが何個かあります。

その1つが、protocolの実体クラスが、他のものに依存しているパターンです。
以下のコードでは、ViewControllerがprotocol ViewModelに依存し、そのprotocol ViewModelの実体クラスViewModelImplが、protocol APIClient(実体クラスAPIClientImpl)に依存しています。
ここでは、ViewControllerの依存関係を解決する処理はコード生成されます(resolveViewControllerメソッド)。対して、protocol ViewModelの実体クラスViewModelImplの依存関係を解決する処理は、コード生成自体はされるのですが、そのままでは使えません。この部分だけは、従来通り依存関係の解決を手動で行う必要があるのです。

// APIClient
protocol APIClient {
    ・・・
}

final class APICientImpl: APIClient {
    ・・・
}

// ViewModel
protocol ViewModel {

}

final class ViewModelImpl: ViewModel, Injectable {
    struct Dependency {
        let apiClient: APIClient
    }

    init(dependency: Dependency) {...}
}

// ViewController
final class ViewController: Injectable {
    struct Dependency {
        let viewModel: ViewModel
    }

    init(dependency: Dependency) {...}
}

final class AppResolverImpl: AppResolver {
    func provideAPIClient() -> APIClient {
        return APIClientImpl()
    }

    // ViewModel(ViewModelImpl)の依存関係を解決する処理は、以下のように手動でする必要
    func provideViewModel() -> ViewModel {
        // 一度dikitgenを実行すると、下のコードと同じようなViewModelImplの依存関係を解決する処理が生成されますが、  
    // それを下のコードと置き換えて使ったとしても、いずれにせよdikitgenだけで依存関係を解決することはできません。
        return ViewModelImpl(.init(apiClient: provideAPIClient()))
    }
}

// ViewControllerの依存関係を解決する処理は、以下のようにコード生成される
extension AppResolver {
    func resolveViewController() -> ViewController {
    let viewModel = provideViewModel()
    return ViewController(dependency: .init(viewModel: viewModel))
    }
}

もう1つがシングルトンです。
シングルトンについても、ここら辺のissueを参考に、手動で依存関係を解決する処理を追加する必要があります。

以上のように一部の依存関係については、従来通り人間が解決する必要があります。

ただ、DIKitなどのコード生成型のDIライブラリを使わない従来の方法では、人間が100%依存関係を手動で解決していたことを考えると、一部分でも自動化できるのは大きな前進です。

現状のGameWithアプリにおけるDI

GameWithアプリは現在手動でDIする処理を書いていたり、そもそもDIせず直接生成するコードが書かれていたりバラバラです。
将来的にはプロジェクト全体をDIできるようにするついでに、DIKitなどコード生成型のDIライブラリを入れたいと思っています!

DIKitが持つ大きな可能性

星の数ほどあるアプリ、その全ての依存関係を解決する処理が整理されて、DIもできるものだったら、、、
依存関係を解決する処理を整理したり、DIできるようにリファクタリングすることは不要になり、多くのコストが浮きます。見通しの良いコードがより効率的な開発を可能にします。DIについて考える時間は必要ありません、全ての仕組みはDIKitが用意してくれています

その結果、もっと別のこと、例えばアプリをもっと使いやすいものにする、などのことにリソースを注力できるようになります

そうなれば、もっともっとおもしろいアプリが出てくる、そんな未来がやってくる、そうあなたも思いませんか?

参考

最後に

GameWithのDeveloper向けTwitterアカウントを開設しました。

もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

GameWith フロントエンド もくもく会 #13 開催しました #GameWith #TechWith #gamewith_moku2

こんにちは。GameWithのエンジニアのtiwuです。

7月25日(木)にGameWith主催で第13回目のもくもく会を開催しました!

GameWith フロントエンド もくもく会 #13

gamewith.connpass.com

今回のテーマも前回に引き続き、僕自身が関心を高く持っているフロントエンドを採用しました。

今回は社内2人、社外6人の合計8人で開催しました!

f:id:tiwu:20190329134140p:plain

もくもく会は最初にお知らせ、次に自己紹介と今日のもくもく内容を発表して、もくもくし、最後に進捗発表という流れで開催しました!

2時間ほどもくもくしたら本日の進捗の発表をしました!

  • AMPの勉強
  • HTMLとPHPの勉強
  • Vueの本を読みながら、Vue.jsで書籍検索APIを利用し書籍検索フォームを実装
  • Vue.jsとFirestoreの実装
  • Vue.jsの公式サイトを読みながら勉強
  • Flutter Webの勉強
  • Tensorflowとフロントエンドの勉強
  • jQueryを利用し、ポートフォリオを作成

といった様々なテーマの取り組みのもくもく会でした!

全体的にVue.js関連が多いですね!

次回告知

次回は8/29に開催します!次回もテーマはフロントエンドです!

gamewith.connpass.com

最後に

参加していただいた皆様ありがとうございました!

GameWithのDeveloper向けTwitterアカウントを開設しました。

もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

非エンジニアがBigQueryとDataPortalを使って初日のイベント別継続率を出してみた話 #GameWith #TechWith

こんにちは!

ディレクターのケンシロウです。

今回は非エンジニアの自分がGoogle Big QueryとData Portalを使ってのアプリデータ分析に取り組んだので、勉強方法や実際のクエリなどを紹介したいと思います。

目次

Google BigQueryとは

BigQueryはグーグルが提供しているビッグデータ解析サービスです。SQLクエリで大量のログデータから、欲しい情報を取り出すことが簡単にできます。

データのクエリは課金されます。最初の1TBは無料です。

cloud.google.com

Google Data Portalとは

Data Portalはグーグルが提供しているBI(ビジネスインテリジェンス)ツールです。様々なデータベースに接続して、簡単にデータをまとめたり、グラフで表示したりできます。 datastudio.google.com

BigQueryとDataPortalを使うことになった背景

もともと弊社ではBigQueryを使っていて、今回可視化のツールとして相性が良いDataPortalを選びました。

非エンジニアの自分がやるきっかけ

自分が所属している開発部内で、データドリブンなプロダクトの改善をしていきたいというニーズがありました。

しかし、社内には専属でデータ分析を行うエンジニアがいませんでした。

自分は5年前に少しだけSQLを触ったことはあり、この機会に知見を深めたいと思い立候補しました。

しかし実際はほぼ覚えていない状態からスタートだったので苦戦しました。

学習方法

社内で書かれている既存のクエリをとにかく読み込み、実際に叩きながら自分でコメントもつけていき、一行一行理解していきました。

次に、BigQueryのデータテーブルのプレビューを見てデータ構造の理解を深めました。 プレビューはスプレッドシートとそんなに変わらない印象を受けました。

f:id:tiwu:20190719183846p:plain

わからないところはQiitaで使えそうな記事がないか探して、まずはそこに載っているクエリをコピペして叩いてみて理解を深めました。

qiita.com

ぐぐってもわからないものは社内のエンジニアに聞いてました。

さらに、社内のエンジニアとペアプロ的な事をして勉強をしました。

実際のクエリの紹介

アプリの継続率を高めるにあたってマジックナンバーを見つけるために、どういう事をしている人が継続率が高いのかをまず知る必要がありました。

いろいろ調べたましたが、ちょうど使えるクエリがなかったのでクエリを自作しました。

qiita.com

クエリ1

初日に行ったアクション別のユーザー群の継続率を表示するクエリ

#standardSQL

#日付を文字列にするファンクションを生成
create temp function date_to_string(date date) returns string as (
  concat(format_date("%Y", date), format_date("%m", date), format_date("%d", date))
);

#集計する最終日を現在の日付の差で指定
create temp function end_date() returns date as (
  date_add(current_date(), interval - EXTRACT(DAYOFWEEK FROM current_date())-1 day)
);

#集計する開始日を現在の日付の差で指定
create temp function begin_date() returns date as (
  date_add(end_date(), interval -14 day));

#必要な仮想テーブルを記載していくので定義
WITH 

#──────────────────────
#まずは初回起動の日のユーザIDの仮想テーブルを作成する。
start AS (
SELECT 
#ユーザID
  user_pseudo_id,
#初回希望日 
 EXTRACT(DATE FROM TIMESTAMP_MICROS( user_first_touch_timestamp) AT TIME ZONE "Asia/Tokyo") AS start_date
#データテーブルを選択
FROM
`<参照するデータテーブル>`

#条件式を記載していく。 

WHERE
#まずは集計期間の設定、ファンクションで定義したものを使う。(データセットで指定しているので文字列)
_table_suffix between date_to_string(begin_date()) and date_to_string(end_date())

 #初日に行なっているアクションの条件
 AND event_name = "<イベント名>"
#初日にイベントを行なっているかどうかの条件
and date(timestamp_micros(user_first_touch_timestamp), "Asia/Tokyo")  = PARSE_DATE("%Y%m%d", event_date)

#以下でグルーピングする。
GROUP BY
  user_pseudo_id,start_date
),

#──────────────────────
#ここからは初回起動の日に関わらず使用日ごとのユーザIDをみていく。
usedate AS (
#以下でユーザIDと日付を取得
SELECT 
#ユーザID
user_pseudo_id,
#イベントを行なった日付(この場合アプリ起動日)、文字列から日付データに変換している。
PARSE_DATE("%Y%m%d", event_date) AS use_date

#データテーブルを選択
FROM
`<参照するデータテーブル>*`

#条件式を書いていく 
WHERE
#まずは集計期間の設定、ファンクションで定義したものを使う。(データセットで指定しているので文字列)
_table_suffix between date_to_string(begin_date()) and date_to_string(end_date())

#継続して同じイベントをしている継続率が欲しい場合は下記のイベントを変更する。現状は起動時に送るセッションスタートを使用
AND event_name = "session_start"
#以下でまとめる。
GROUP BY
  user_pseudo_id,
  use_date
),
#──────────────────────
#ここからはリテンションしているユーザのIDを出す。
retention AS(
SELECT
  start.user_pseudo_id,
  start.start_date,
  IFNULL(DATE_DIFF(usedate.use_date, start.start_date,  day), 0) AS retention_day

FROM
# 上記2つの仮想テーブルからINNER JOINでIDが一致するデータのみに絞り込んでいる。(一応初回起動日以降もいれている。)
  start
  INNER JOIN usedate ON start.user_pseudo_id = usedate.user_pseudo_id AND usedate.use_date >= start.start_date

GROUP BY
  start.user_pseudo_id,
  start.start_date,
  retention_day),
  
#──────────────────────
#ここからリテンションDAYのユーザIDをカウントしてUU数にしていく。用途によっては不要
retention_sum AS(
SELECT
  start_date,
  retention_day,
  count(user_pseudo_id) AS uu
FROM
  retention
GROUP BY
  start_date,
  retention_day)
#──────────────────────
#最後に表示する項目をまとめる。
SELECT
  start_date,
#初日のUU数を出しておく。これが分母になるのでグラフ表示にも使いやすい。 
 SUM(CASE WHEN retention_day = 0 THEN uu ELSE NULL END) AS startuu,
#初日からの差分(経過日数)別に継続率を出していく。
 SUM(CASE WHEN retention_day = 1 THEN uu ELSE NULL END) / SUM(CASE WHEN retention_day = 0 THEN uu ELSE NULL END) AS oneday,
  SUM(CASE WHEN retention_day = 3 THEN uu ELSE NULL END) / SUM(CASE WHEN retention_day = 0 THEN uu ELSE NULL END) AS threeday,
  SUM(CASE WHEN retention_day = 7 THEN uu ELSE NULL END) / SUM(CASE WHEN retention_day = 0 THEN uu ELSE NULL END) AS week
FROM
  retention_sum
GROUP BY
  start_date
ORDER BY
  start_date ASC

実際にデータを出してみて

苦労した事

仮想テーブルを理解するまで時間がかかりました。

2つのテーブルのJOINの結果のイメージが最初はできず、実際に手でとにかくノートに書いてみたりしました。

f:id:tiwu:20190719183921j:plain

f:id:tiwu:20190719183938j:plain

f:id:tiwu:20190719183954j:plain

最初はクエリを叩いてもデータが見つからなくて苦労しました。

特にイベントネームとカラムの名前の区別がついておらず、全部変数を日本語にしてほしいなと感じました。

(エンジニアが定義した変数をググっていて、全然出てこなくて徒労に終わりましたw)

firebaseの純正のものはsession_startだったり基本英語で用意されているが社内のイベントは日本語のものも多く、混乱しました。

無限ループになるとエラーが表示されないので、デバッグに苦労しました(時間で課金ではないはずなのでヒヤヒヤしました)

仮想テーブルを一つずつ実行してどこで無限ループになっているか、地道にデバッグをしました。

→デバッグはできるだけ少量のデータで実行して節約しました。

学習中のため表示できない理由が自分の知識不足なのか、そもそもログが存在しないのか判断が難しかったです。

頑張ってみてだめだったら、別のアプローチで似たようなデータが出せないか模索をしていました。

DAUでUUを定義してしまうと、MAUを出すときにDAU * 30みたいな数値になり正確な数値が取れないのでUUの定義は気をつけないといけませんでした。

(自分はGAのデータと比較して差異があったので気づけました)

自分はBigQueryでUUを集計するのではなく、DataPortalで集計することで正確なMAUを算出しました。

(DataPortalでは参照する日付を簡単に変更することができるため、DataPortalでの算出がおすすめです)

良かった点

周りのエンジニアに綺麗なクエリを書くと褒められた!

基本を覚えるとその組み合わせで割と何でも出せるようになるので、もう出せないものはなくなりました。

クエリをわかってくるとデータを算出するのが面白くなってきました!

今後半年の目標がデータアナリストとして活躍することになった(キャリアめっちゃ変わった)

終わりに

現場でデータが身近になっているところは少ない印象です。

なので、ここを整備すると全体のアイデアの質も数字に対する意識も上がっていくと思います。

是非みなさんの現場でもデータ分析を活用してみてください!

今後やりたい事

  • ユーザーが行ったイベントの回数に応じてユーザー群を切り分けて継続率を算出
  • 常に見えるところに大きなモニターなどでデータを表示

最後に

GameWithのDeveloper向けTwitterアカウントを開設しました。

もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

GameWith フロントエンド もくもく会 #12 開催しました #GameWith #TechWith #gamewith_moku2

こんにちは。GameWithのエンジニアのtiwuです。

6月27日(木)にGameWith主催で第12回目のもくもく会を開催しました!

GameWith フロントエンド もくもく会 #12

gamewith.connpass.com

今回のテーマも前回に引き続き、僕自身が関心を高く持っているフロントエンドを採用しました。

今回は社内3人、社外3人の合計6人で開催しました!

f:id:tiwu:20190329134140p:plain

もくもく会は最初にお知らせ、次に自己紹介と今日のもくもく内容を発表して、もくもくし、最後に進捗発表という流れで開催しました!

自分はFirebase Functions + Node.js + Expressの勉強をしていました。

2時間ほどもくもくしたら本日の進捗の発表をしました!

  • Firebase Functions + Node.js + Expressの勉強
  • Vue.jsの書籍でVue.jsの勉強
  • TodoMVCという同じ機能をいろいろなFWで作るサイトを参考にVue.js + Vuexを利用し実装
  • WordPressのサイトのCSSの実装
  • Vue.jsの書籍でVue.jsの勉強
  • ReduxとReact hooks、useReducerの勉強

といった様々なテーマの取り組みのもくもく会でした!

次回告知

次回は7/25に開催します!次回もテーマはフロントエンドです!

gamewith.connpass.com

最後に

参加していただいた皆様ありがとうございました!

GameWithのDeveloper向けTwitterアカウントを開設しました。

もくもく会の告知やブログの更新情報などを発信するので良かったらフォロー宜しくお願いします!

twitter.com

6月のデザインチームトーク #GameWith #TechWith

f:id:fukiworks:20190619201030p:plain

GameWithのデザイナー3名がチャット形式でゆるっと情報をお届けする「デザインチームトーク」です。


Fuki

こんにちは!!!!!!!!!

sono

こんにちはっ

Fuki

我々はGameWithのデザインチームです!あれっ、リーダーがいない

sono

いない

YOHAN

キタ━━━━(゚∀゚)━━━━!!

sono

ヒーローは遅れてくる

Fuki

キタ━━━━(゚∀゚)━━━━!!

YOHAN

いやぁーブログチャットついに始まりますね、楽しみ!!!

Fuki

お待たせいたしました!!!! さて、こちらはGameWithに所属するデザイナー3人が、より多くの方にこんなデザイナーがいるよ!こんな活動してるよ!ということをわいわい伝えるブログになります

YOHAN

よろしくおねがいします〜!

sono

よろしくおねがいしますっっっっ

Fuki

なんと見た目はチャット仕様!!!!みなさんお気軽に流し読みしてね!!!!
早速ですが...私たちが何者なのか....自己紹介してもらっちゃおうかな...!
私はブログいくつか執筆したかと思うんですが、他の2人は初露出??ですか???

sono

おはつです

sono

あっ初じゃないかもしれない

YOHAN

GameWithでは以前エンジニアブログにマイニング部の活動について書いたことありますね〜

Fuki

はつみみ

sono

はつみみ

Fuki

じゃあすでにちょっと露出してる私から!軽く自己紹介させていただきやす
名前はFukiです!ふうきとよみます!女の子です!!!!!
GameWithのデザイナーで今はUIデザインの勉強と新しいプロトタイプツールをいじいじすることにはまってます
あと街を徘徊することとお酒がだ〜〜いだいだいすき
あとなんか質問あります???(唐突)

sono

趣味が年齢にあってないのでは・・・・???????

Fuki

年齢は3万5千歳なので問題ありません

YOHAN

仙人じゃん

sono

良かった

Fuki

そういうことです もう世の中全部知っちゃってるけど UIデザインだけが未熟 (ほんとは他もまだまだ勉強中) はい!私はこのくらいにしておくかな!

YOHAN

え速い、聞こうと思ったのに

Fuki

次!ヨハンさん!!!!!
あっ言い忘れてたけどこのチャット30分の制限時間つきなんで
つぎつぎ!!!!!!!!!!! GOGOGOGOGOGO

sono

シッ

YOHAN

大分プッシュしますねw

Fuki

手をぶんまわしている

YOHAN

どうも、GameWithでUI/UXデザインして3年目に入る ナ・ヨハンと申します

Fuki

大御所すぎる 格が違う

YOHAN

趣味はDJ、ゲーム、アニメ鑑賞など!周りからはよくパリピィーって感じで思われてるみたいです

Fuki

パリピじゃないんですか!?!?!?

sono

あ怖い

YOHAN

人生お祭りですよ

Fuki

パリピならではの格言

YOHAN

ゲームの中でもパーティを組むのもお祭りでっせ

Fuki

すきなゲームは!

YOHAN

ゲームは幅広く好きですが、今だとFPS系のAPEXというゲームをPS4で遊んでますね!

sono

あ〜〜〜いいですよねわかる

Fuki

ライフラインちゃんすこ

YOHAN

ライフラインの飛んでるロボちゃんかわいい

Fuki

わかる アッ!?!?!?もう5分たってる!!?

YOHAN

てか、この話の流れだと僕がただのパリピのイメージで終わっちゃうぅーーー / ( T A T) \

sono

あ〜〜〜〜〜〜 合ってます

Fuki

次回に期待!!!つぎ!!!!!!

YOHAN

次回はもう少しイメージアップしますw

Fuki

sonoちゃ〜〜〜〜ん

YOHAN

次はsonoさんのターン!(遊戯王風)

sono

おろろ

Fuki

ドロー!!!!!!!!

sono

デザイナーのsonoです。 この中で一番下っ端ですがはやく一人前になれるよう一生懸命学び中ですι(`・-・´)/ 今主にやっていることとしては攻略記事の装飾だったり画像だったりを作成しています。 好きなことは絵を描くことと食べることとゲームすること!!

Fuki

平和の象徴みたいなプロフィール ドローとか絶叫して恥ずかしいわ

sono

おもろくないとかいうな

Fuki

パリピと仙人と平和

YOHAN

良いメンバーが揃ったではないか。

Fuki

じゃあ平和な質問しよ!!好きな色は〜?????

sono

きいろきいろきいろ〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

Fuki

警告色で草

sono

ポジティブにとらえよ

YOHAN

黄色は食欲増しますよ!

sono

まじすか

Fuki

フォローが可愛すぎる これなんですよウチのリーダーは最高なんだ

YOHAN

ぉっ、おう。

Fuki

ヨハンさんの可愛さが全世界に発信されてしまう

YOHAN

かわいいパリピ・・・w

sono

先生時間が!!!!!!!!

Fuki

あああっ!?!?!?

sono

あああああああああああああああああああ

Fuki

タイムリープしたい

YOHAN

sonoさんに最後に質問!

sono

あはい

YOHAN

いま自分で流行ってる、美味しい食べ物教えてください!

sono

塩パン! 塩パン美味しすぎですよ

YOHAN

塩パン?!写真見たけど美味しそうですねぇ〜食べたこと無いけど今度食べてみよっと

Fuki

むりやりねじ込んだ質問がコレ どういうこと???????
そんなチームです、よろしくお願いいたします!!!!

sono

ふうきちゃんに疑問視されてますけど神レベルの美味しさ
あっよろしく〜〜!!!

Fuki

次行くわよ!!!塩パンの話はもうええよ!!!

sono

お腹すいた

Fuki

さて、GameWithにデザイナーがいたことすら知らない人も多いかと思うので、なんとなく現場の雰囲気をお伝えしたい
というわけで2人に1問1答してもらうよ!!!!!!
いくわよ!!!!!

YOHAN

とりあえず、ワイワイ感は既に大分つたわってるきがするなw

sono

えっはい!

Fuki

第一問
「使っているマシンはな〜に?作業環境教えて!」

Fuki

だいたいみんな一緒だけども!

sono

Mac!!!!!

Fuki

おおざっP〜〜〜

Fuki

我々はMacbook Proの15inchと外部モニターで作業してま〜す!

YOHAN

f:id:fukiworks:20190619191658p:plain

Fuki

めっちゃ具体的なスクショで草

sono

シンプルかつ真実のスクショ

YOHAN

こう見るとワシのMACふるい・・・

Fuki

けしからん....即買い替えましょう

YOHAN

そろそろアップグレードしますかねぇ!!!ふうぅぅ↑↑↑(パリピ感)

Fuki

第2問!
「GameWithってどんなデザインの仕事があるの??担当してるお仕事をざっくり教えて!」

Fuki

私はサービス改修、新規事業のUIデザインを主に担当してま〜〜す!スピードアタッカー!

sono

さっきちょっと言いましたけど、攻略記事のh2等の装飾や各ゲームごとのアイキャッチ画像などを作成しています。

Fuki

お世話になりっぱなし

YOHAN

sonoさん、この場を借りて本当にいつもありがとうございます!!!もちろんFukiさんも!!!

Fuki

GameWithがGameWithらしくいられるのはsonoちゃんのおかげなんですよ(?)

sono

突然のプレッシャー!!!

Fuki

ヨハンさんにほめられた〜!HAPPY

sono

先輩2人がすごいので追いつけるようにがんばりまする

Fuki

ヨハンさんヨハンさん!!!!時間がない!!!はよ!はよ!!!!

YOHAN

僕が関わっている、デザインタスクは様々な部署からいろんな案件がきますが、最近注力しているのはGameWithアプリでデザインリードさせて頂いてるので、UIやUX、調査なども含めて改善改修などゴリゴリにやってます!

Fuki

わかりやすい 理解ができる
なんと30分すぎてしまった.....!でももう少しだけ!!初回なんで!!!

YOHAN

ボーナスタイム突入!

Fuki

プリクラといっしょ

YOHAN

最近のプリクラのUX本当にすごいと思います

YOHAN

カメラ自分で動かせるんですよね?

Fuki

プリクラでUX観察するデザイナーの鑑....
なんでそこまで知って......あっパリピ

YOHAN

^0^;;;

sono

お察し

Fuki

じゃあまとめにはいりますよ〜〜〜!!!!!!

sono

は〜い

YOHAN

〆お願いします!

Fuki

これからも定期的にこの3人が情報をゆるく発信していきます! 次は3人の興味のあるコンテンツとか、シェアしたい知識などをモリモリ盛っていきますわよ

YOHAN

世界に向けて発信!楽しみですね!読者増えるといいなぁ!

sono

わ〜い!!楽しんでやっていきましょ〜!

YOHAN

スケールさせていきましょう(デザイン思考)

Fuki

初の今回は、とりあえず、みなさんに「GameWithにデザイナー、いるぞ!」ということが伝われば合格!だよね!

sono

優勝

Fuki

次回はもっ〜と有益になるよね?ハム太郎?

sono

へけっっっっっっっっっっっっっっっっっっ
反射しか誇れないので頑張ってもっと賢いこと言います

Fuki

わかる

sono

ありがとうございました

Fuki

ヨハンさんみたいにデザイン思考で話せるようになるまでの成長過程もみてほしい

YOHAN

僕も常に学んでいる身なのでデザインチームの皆さんも読者の皆さんともいろいろ学んで成長できるとよいですね!

Fuki

ヨハンさんが真面目にまとめてくれて助かる!それではみなさん、さようなら〜!また次回!

sono

またみてね

YOHAN

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