GameWith Developer Blog

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

GameWith メンバーのリモートワークデスク事情! #techwith #gamewith

はじめに

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

gamewith.co.jp

弊社は新型コロナウイルス感染症拡大に備えた在宅勤務(フルリモートワーク)を2020年3月30日から実施しています。

そこで、今回のブログは GameWith メンバーのデスクについて写真と一言コメントともに紹介していきたいと思います!

Tさん

f:id:tiwu:20200716173006j:plain

L字のテーブルを有効活用し、ウルトラワイドモニターを活かす匠のデスク。

Tさん

f:id:tiwu:20200716172932j:plain

モニター小さくて作業辛いので、モニターアームとディスプレイ注文中。

Kさん

f:id:tiwu:20200716172836j:plain

部屋の奥に横100cmのスペースがあったのでちょうど収まるように横100cmのデスクを設置。

電動昇降デスクを設置予定。

clas.style

Lさん

f:id:tiwu:20200716174332p:plain

大大大好きな彼女からもらったデスクがポイントです。

Tさん

f:id:tiwu:20200716175048j:plain

f:id:tiwu:20200716175111j:plain

ミクさん(とプラモ)。同じモニタでwindowsやswitchなどのゲームプレイできます。

Yさん

f:id:tiwu:20200716183303j:plain

最近デスク周りのライト設備を増やしました。

デスク裏にはLEDライト貼り付けて、その日の気分に合わせてムード変えたりしてます。

モニター裏にもライトライトを点けて置くことで、モニターの光と裏の影のコントラスト和らげてます。

Iさん

f:id:tiwu:20200720120848j:plain

ゲーミングPC系の機材環境に仕事用のMacを繋いでます。仕事モードとゲームモードを簡単に切り替えられるように頑張ってるので配線が汚い!

机全面のマウスパッドがかなり快適なので、マウスパッドは大きめがオススメです!

Oさん

f:id:tiwu:20200720160138j:plain

最後に

エンジニアやデザイナーに協力をお願いしたのですが皆さん個性的でそれぞれ最高のパフォーマンスが出るよう工夫されていますね!

Twitter

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

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

https://twitter.com/gamewith_devtwitter.com

エンジニアがオブジェクト指向 UI デザインに入門しています #GameWith #TechWith

こんにちは! エンジニアコミュニティでは、ごーと呼ばれている只野です。

tl;dr

今回は、弊社サービス開発エンジニア3名が オブジェクト指向UIデザイン(OOUI) という手法を学んでみて、所感を持ち寄りました。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 から、キャッチアップをさせていただいております。

OOUI を知る前後の考え方は、人によって違うところがあるだろうと想像し、このことをテーマに話したら、デザイン手法を学ぶモチベーションが今後も高まることを期待して進行していきます。

よかったらお聴きください。

出演者

  • エンジニアマネージャー: serima
  • iOSエンジニア: かつらやま
  • フロントエンドエンジニア: ごー

編集後記

OOUI は、我々がよく使う OS で既に実現されています。

ユーザーは、作業フローに支配されているのではく、フレキシブルな方法で操作を成し遂げられるデザインであることが大いに便利であることがわかります。

今回の収録に向けて、オブジェクト指向 UI デザインを学んでみて、使い勝手が良いデザインをイメージできるようになったと実感しています。

UI を構成している部品それぞれを直感的に操作できることが、便利で欠かせない要素であると心から感じますし、サービス開発においても OOUI の手法で今後アプローチしてみたいと思いました。

再現性が高いであろう OOUI の手法は、サービス開発に関わる組織の誰にでもそうですが、特にエンジニアにはかなり親和性があるのではないでしょうか。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 、お薦めです。

終わりに

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

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

https://twitter.com/gamewith_devtwitter.com

GameWith における CLB から ALB への移行 #GameWith #TechWith

はじめに

こんにちは!リプレイスチームの野口と @inosy22 です!

今回のブログは GameWith のロードバランサーを AWS の CLB から ALB に変更した背景や変更手順、詰まったところや解決方法について書いていきたいと思います!

リプレイスに関してはこちらの記事で紹介しています!

tech.gamewith.co.jp

ALB(Application Load Balancer)とは

docs.aws.amazon.com

サービス概要

ALB は、アプリケーションレイヤー (L7) でルーティング決定を行い、パスベースのルーティングをサポートしている高機能なロードバランサーです。

メリット

  • パスベースルーティング
    • URLのパスによって Lambda や EC2, ECS などに振り分けることができます!
    • 例:/api の時にAPIサーバー、/app の時にアプリケーションサーバーに振り分ける
  • リスナールール
    • URL のパス以外にも、IP や UserAgent で振り分けることもできます!
  • AWS WAF (Web Application Firewall) が利用できます!

なぜ CLB から ALB に変更をしたのか

主な理由はパスベースルーティングでリプレイスしたサービスに段階的に振り分けることをしたかったからです。

GameWIthが利用していた CLB では上記のような柔軟な振り分けが難しかったので、ALB に変更することにしました。

それ以外にも ALB だけでメンテナンス画面を表示する対応が完結したり、リスナールールで IP 制限など、メリットが多かった為です。

移行方法

1. ALB を作成する

ALB は ALB の作成画面で簡単に作れます。

しかし、CLB から ALB に移行する場合、CLB の画面から移行ウィザード経由で作る方法があります。

docs.aws.amazon.com

GameWith は独自のスケーリングシステムを構築しているので、CLB の移行機能ではなく、ALB 作成画面から ALB を作りました。

2. 独自のスケーリングシステムの改修

GameWith は EC2 の台数を独自のスケーリングシステムによって増減させています。

www.slideshare.net

このシステムを ALB に対応させるため改修を行いました。

詰まったところ

独自のスケーリングシステムは、ALB のリクエスト数によってスケールの基準を変更しています。(例:20万アクセスだったら20台)

CLB の時と同様に実装をしたところ、リクエスト数の取得を安定して行えませんでした(例:たまに取得できなかったり、取得できても0アクセスだったりなど)

CLB の場合は1〜2分前のリクエスト数であっても安定的に取得ができていたのですが、ALB ではそれがうまく動きませんでした。

そこで、リクエスト取得の時間を5〜6分前に変更してみたところ安定して値が取得できるようになりました。

いろいろと調査をしているなかで似たような問題を Google フォーラムで取り上げられているのを発見でき、解決の糸口となりました。

3. 移行前に ALB の暖気申請をする

暖気申請とは、予めスパイクが来そうな時間を AWS に伝え、CLB から ALB の切り替えによって瞬間的に増える大量の接続をさばけるように ALB のキャパシティを事前に上げておいてもらう申請のことです。(AWS サポートプランのビジネス・エンタープライズに入っているのが条件です)

今回の暖気申請の理由としては、GameWith はアクセス数が多いサービスなので、切り替えの瞬間などで落ちないように申請をしました。

実は暖気申請の存在を知らず、移行リリースギリギリに知りました。

知った当日に申請をしましたが、リリース日には間に合わず、リリースの予定を後ろにずらしました。

詰まったところ

ALB の暖気申請をする場合はマルチ AZ で配置をする必要があります。

GameWith の場合はシングル AZ だったため、暖気申請のためにマルチ AZ 配置をしました。

終わりに

これからサービスが成長する際に、パスベースルーティングが使えるようになりマイクロサービス化がしやすくなりました!

独自スケーリングシステムがブラックボックス化していたので、リファクタリングしバージョンアップができたのでよかったです!

暖気申請は忘れずに!(2回目)

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

ブログの更新情報などを発信するので良かったらフォローよろしくお願いいたします!

https://twitter.com/gamewith_devtwitter.com

エンジニアの教養について談義しました #GameWith #TechWith

こんにちは! エンジニアコミュニティでは、ごーと呼ばれている只野です。

tl;dr

今回は、弊社サービス開発エンジニア3名が 教養 に関して、これまでの開発キャリアでどんな視点を持つようになったのかを意見交換をしました。 雑談するノリでゆるい掛け合いをしています。 よかったらお聴きください。

出演者

  • エンジニアマネージャー: serima
  • シニアエンジニア: のぐち
  • フロントエンドエンジニア: ごー

編集後記

なぜ、このような収録を公開してみようかというと、上司の serima とは、30分〜1時間の 1on1 をしていて、お互いにいい歳なので内容は話題が多彩な雑談(笑)になっていました。

機密事項以外であれば公開してみると、GameWith のサービスは、どんなエンジニアが開発にあたっているのかを伝えることが出来て、おもしろいんじゃないかと提案してみました。

初回なので、多少お聴き苦しいことは否めないですが、今後は更にキャラが立った話をお届けできたらと思います。

終わりに

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

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

https://twitter.com/gamewith_devtwitter.com

ダッシュボードの新機能開発にVue.jsを導入した背景と苦労したこと #GameWith #TechWith

こんにちは!サーバサイドエンジニアのkuromokaです!

こちらの記事でもあったように、GameWithのリプレイス開発ではVue.jsを使っています。 tech.gamewith.co.jp

今回はリプレイスではなく、GameWithの社員の方が使っているダッシュボードの新機能開発に、Vue.jsを導入した背景と苦労したことについて、お話します。

Vue.jsを導入した背景

GameWithのダッシュボードは社員の方しか見れない画面で、フロント側は次のような技術が使われています。

  • Bootstrap v2.0.3
  • jQuery v1.8.3

それぞれのリリース日を調べてみたら、Bootstrap v2.0.3は2012年の4月*1、jQuery v1.8.3は2012年の11月*2のようです。

2020年の今となってはかなり昔のバージョンを使っているのですが、裏側の画面のためにフロント側で凝った画面にする機会があまりなく、苦労さは感じつつ開発はしていました。

ただダッシュボードが使い辛いことでの作業効率が下がっているという話はたびたび聞いていて、今回もそういった作業効率を改善するための新機能開発でした。

今回の新機能はかなり根本的な改善を行うための機能だったため、フロントの改修も大幅に必要な見込みになりました。

開発チームでも相談して、この開発を今のフロント環境でやるのはちょっと辛いなということになりました。 あとはダッシュボードなので比較的新しい技術を取り入れやすいというのもありました。

そういった経緯で、今回はVue.jsを採用することにしました。具体的には次のような技術を使いました。

  • Vue.js v2.6.11
  • Composition API
    • Vue.js3系に備えて採用。v2系のため@vue/composition-api を導入
  • BootstrapVue
    • Bootstrap v4ベースのコンポーネントを、Vueコンポーネントとしてコーディングするため
  • Vue CLI
  • TypeScript
  • Jest
  • Go(バックエンドAPI)
    • Vue.jsからは基本的にGoのAPI経由で、データの取得や更新を行う

Vue.jsの導入で苦労したこと

今回の新機能開発に関しては、開発環境が整ってからはVue.jsの恩恵も受けながらスムーズに開発できたので、新しい環境にして良かったと思っています。*3

ただVue.jsの導入までが、既存プロジェクトへ導入するような事例があまり見つからないのと、私自身もそこまでVue.jsに詳しいわけではなかったので結構苦労しました。

細かいところを含めればもっと紹介したいのですが長くなってしまうので、今回は「既存プロジェクトへのVue.jsの導入で苦労したこと」について、3点紹介します。

1. Vue.jsのインストールからビルドまで

Vue.js公式ドキュメントには、CDN・NPM・Vue CLIでのインストールが紹介されています。最初は一番手軽なCDNにしようとも思ったのですが、今後規模が大きくなることやビルド設定が最初から入っていることもあり「Vue CLI」でインストールをしました。 jp.vuejs.org

ダッシュボードの画面はPHPで動いています。PHPのプロジェクト内に、Vue CLIで「frontend」プロジェクトを作りました。

$ cd ${DASHBOARD_APP_PATH}
$ vue create frontend


Vue CLI v4.1.1
? Please pick a preset: Manually select features
? Check the features needed for your project: Babel, TS, Linter, Unit
? Use class-style component syntax? Yes
? Use Babel alongside TypeScript (required for modern mode, auto-detected polyfills, transpiling JSX)? Yes
? Pick a linter / formatter config: Basic
? Pick additional lint features: (Press <space> to select, <a> to toggle all, <i> to invert selection)Lint on save
? Pick a unit testing solution: Jest
? Where do you prefer placing config for Babel, ESLint, etc.? In dedicated config files
? Save this as a preset for future projects? No

Vue CLIはビルド設定が最初から入っているため、$ npm run build するだけで、ビルド結果が出力されるのはすごく楽でした。

ただそのままだとVue CLIで作った、「frontend」プロジェクト内にビルド結果が出力されます。公開フォルダにはしていないため、PHPから参照することができません。

そのためアセットの公開フォルダに対して、ビルド結果が出力されるように、vue.config.jsファイル*4を作って設定を調整しました。

具体的には、次のようにoutputDirassetsDir を調整しました(いろいろな事情がありVue CLIのプロジェクトが深くなっているので、こんな相対パスになっています)。

module.exports = {  
  outputDir: '../../../../../public/', 
  assetsDir: './assets/frontend/',
}

最後に公開フォルダに出力するようにしたビルドファイルを、PHPから読み込むようにしました。

<script src="/assets/frontend/js/app.js"></script>

2. カレントパスによるコンポーネントの切り替え

見ているページのカレントパスでVueコンポーネントを切り替えるために、「vue-router」を使いました。 router.vuejs.org

初期化時に追加していなかったので$ vue add routerで後から追加しました。このコマンドでvue-routerのインストールとサンプル用のルーティング設定まで一通りやってくれます。

Vue CLIはデフォルト設定だと #appの要素にApp.vueがマウントされる設定になっています。今回App.vue<router-view/>を追加して、この部分をvue-routerで切り替えるようにしました。

<template>
  <div id="app">
    <router-view/>
  </div>
</template>

PHPからは、Vueコンポーネントを表示したい箇所に#appを書きます。あとはvue-routerのルーティング設定を調整すれば、カレントパスによって#appの部分が切り替わるようになります。

<div id="wrap">
  <div id="app"></div>
</div>

3. ホットリロードで開発する

今回一番苦労した点です。

Vue CLIには最初からホットリロードが有効な開発サーバが$ npm run serveで起動できるようになっています。
ただ今回は「PHPの一部分をVue.jsにした環境で、Vue.jsの部分だけホットリロード」するような挙動にしたかったので、そのままでは開発サーバが使えませんでした。

そのためしばらくは$ npm run buildで毎回ビルドして確認していましたが面倒で開発効率が悪いので、なんとかホットリロードを使えないか調べてみました。

調べていく中で、vue.config.jsdevServer.proxyという、設定が使えそうなことが分かりました。この設定を使うと開発サーバの特定パスへリクエストがあったときに、別サーバにプロキシさせてリクエストすることができるようになります。 cli.vuejs.org

一部省略していますが、実際に設定したvue.config.jsは次のような感じです。http://php-local-server/はPHPのローカル開発サーバです。/なので全てのリクエストをPHPにプロキシさせています。

module.exports = {  
  host: '0.0.0.0', 
  port: 9000,   
  proxy: {   
    '/': {  
      target: 'http://php-local-server/',  
      secure: false,   
      cookieDomainRewrite: 'localhost',        
    },
}

PHPではサーバ変数の$_SERVER['HTTP_X_FORWARDED_HOST']でプロキシ時のホスト名を取ることができます。
この値を見てlocalhost:9000の場合にhttp://localhost:9000からのパスで、ビルドファイルを読み込むようにしました。

<script src="http://localhost:9000/assets/frontend/js/app.js"></script>

ここまで設定すれば、

  • $ npm run serveで、Vue CLIの開発サーバを起動
  • http://localhost:9000/vue-js-pathで、Vue.jsを使っているページを見る
    (PHPのhttp://php-local-server/vue-js-pathがプロキシ経由で表示される)
  • Vueコンポーネントを更新するとビルドが走って、Vue.jsの部分だけ自動でリロードされる

という感じで開発ができるようになって毎回のビルドが不要になりました!これで当初目指した「PHPの一部分をVue.jsにした環境で、Vue.jsの部分だけホットリロード」を実現することができました。

まとめ

今回はダッシュボードの新機能開発に伴う、「Vue.jsを導入した背景」と「Vue.jsの導入で苦労したこと」をお伝えしました。

記事で紹介した「frontend」プロジェクトは、今は「GameWithのリプレイスについて vol.2 ~Web Components を Vue で書いたら最高だった編~ #GameWith #TechWith - GameWith Developer Blog」で紹介した「GameWithDesignSystem」のように別システム化をして、PHPのプロジェクトから独立して開発できる環境に改善をしています。

今回の内容が同じような悩みの人に対して、少しでも参考になる情報だったら嬉しいです!

終わりに

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

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

https://twitter.com/gamewith_devtwitter.com

*1:https://blog.getbootstrap.com/2012/04/24/bootstrap-2-0-3-released/

*2:https://blog.jquery.com/2012/11/13/jquery-1-8-3-released/

*3:Composition APIだけは苦労したのですが、RFCを見たりGitHubでコード検索をしたりして、書き方に慣れていくようにしました

*4:https://cli.vuejs.org/config/ 今回このファイルを触る機会が多かったので、とても参考になったページです

iOSのViewが画面上に表示されたことを判定する実装方法 #GameWith #TechWith

こんにちは、iOSエンジニアの chuymaster です!

最近とある案件で、ユーザーが特定のViewを見たかどうかを計測しました。iOSエンジニア向けに、その実装方法について紹介したいと思います。

目次

背景

弊社は、設置したバナーの効果測定のため、ユーザーが何人バナーを見て、何人クリックしたかというデータを集計しています。

広告用語でいうと、クリック率(CTR)に当たる数字を集計して、分析しています。

それに基づいて、どういうバナーが効果が良いのかの実験が日々行われていますが、iOSアプリではそのようなことができませんでした。

要件

元々各バナーのクリックイベントは記録していますが、インプレッション(表示)イベントを記録していなかったので、CTRを測定できませんでした。

今回はインプレッションを記録する実装を下記の「統合トップ」画面で行いました。

f:id:gwchai:20200526150111p:plain:w300
統合トップ画面

インプレッションの定義は様々ですが、Googleアドマネージャーの定義に従いました。

Google アド マネージャーでは、業界基準に沿った方法でモバイルアプリ インプレッションがカウントされます。つまり、デバイスの画面に広告クリエイティブが 1 ピクセル以上表示されると、モバイルアプリ インプレッションが 1 回カウントされるという仕組みです。

実装要件に置き換えると、対象Viewが画面上に1pxでも表示されればインプレッションイベントを送ることになります。

実装

下記が対象画面の構成になります。

f:id:gwchai:20200526183630p:plain
インプレッションを判定したい箇所

見ての通り、インプレッションを判定したい箇所は3種類あって、かなり深い層にあります。 インプレッションログ送信の実装要件はこのようになります。

  1. UIScrollViewの中のUIViewが画面内に表示された際
  2. スクロールが無効なUICollectionViewの中にある、UICollectionViewCellが画面内に表示された際
  3. 横スクロールが有効なUICollectionViewの中にある、UICollectionViewCellが画面内に表示された際

基本的な実装コード

stackoverflow.com

上記のスレを参考に、scrollViewDidScroll(_:) 時に、スクロールして見える bounds と対象の UIViewboundsintersects(_:) したら、インプレッションログを送信します。

しかし、Viewが複数階層でネストされている対象画面では、そのまま UIViewboundsUIView が交差しているかどうかを判定すると、ローカル座標が返されて間違った判定になってしまいます。そこで登場するのが convert(_:to:) 関数です。

view.convert(bounds, to: UIScreen.main.coordinateSpace)

これで画面上の空間での座標に変換できます。詳しくはこちらを読んでみてください。 https://developer.apple.com/documentation/uikit/uicoordinatespacedeveloper.apple.com

①UIViewが画面上に表示されたことを判定するコード

完成したコードがこちらです。

func detectImpressions(scrollView: UIScrollView, view: UIView) {

        // スクロールした位置で見えているフレームの位置を計算する
        let currentVisibleFrame = CGRect(x: scrollView.contentOffset.x,
                                         y: scrollView.contentOffset.y,
                                         width: scrollView.frame.size.width,
                                         height: scrollView.frame.size.height)

        // 見えているフレームの位置を、画面上の位置に変換する
        let currentVisibleFrameInMainSpace = scrollView.convert(currentVisibleFrame, to: UIScreen.main.coordinateSpace)

        // Imp計測対象Viewのフレームの位置を、画面上の位置に変換する
        let viewFrameInMainSpace = view.convert(view.bounds, to: UIScreen.main.coordinateSpace)

        // 重なりを判定する
        if viewFrameInMainSpace.intersects(currentVisibleFrameInMainSpace)
         {
            // インプレッションログを送信する
         }
    }

スクロールして見えたフレームと、対象Viewのフレームを UIScreen.main.coordinateSpace 空間の座標に変換して、画面上に見えているかどうかを判定します。 あとは scrollViewDidScroll(_:) で呼び出せば良いです。

これで、要件①UIScrollViewの中のUIViewが画面内に表示された際の判定処理が実現できました。

②UICollectionViewのUICollectionViewCellが表示されたことを判定するコード

UICollectionView の場合は、中のセルのフレームを見て判定する必要があります。

stackoverflow.com

上記の回答を参考に、今見えているセルの indexPath.row を返す関数を実装しました。

   func getVisibleRows(currentVisibleFrameInMainSpace: CGRect, collectionView: UICollectionView) -> [Int] {
        var visibleRows = [Int]()

        let visibleIndexPaths: [IndexPath] = collectionView.indexPathsForVisibleItems
        for indexPath in visibleIndexPaths {
            guard let cell = collectionView.cellForItem(at: indexPath) else { continue }

            // 画面描画位置の重ねで表示されたかどうかを判定する
            let cellRect = cell.contentView.convert(cell.contentView.bounds, to: UIScreen.main.coordinateSpace)
            if currentVisibleFrameInMainSpace.intersects(cellRect) {
                visibleRows.append(indexPath.row)
            }
        }
        return visibleRows
    }

引数に①の関数で取得した画面上のフレーム座標を渡して、各セルの座標と比較して画面上に見えているかどうかを判定します。

collectionView.indexPathsForVisibleItems がそのまま使えない理由は、今回の実装では、全てのセルを最初から展開して描画させているため、すべてのセルの indexPath が返却されるからです。

これにより、要件②スクロールが無効なUICollectionViewの中にある、UICollectionViewCellが画面内に表示された際の判定処理が可能になります。

要件③横スクロールが有効なUICollectionViewの中にある、UICollectionViewCellが画面内に表示された際のも同じコードでできますが、scrollViewDidScroll(_:)delegateUICollectionView に変える必要があるので、ご注意ください。

スクロールが有効なUICollectionViewなので、 collectionView:willDisplayCell:forItemAtIndexPath: は一見使えるように見えますが、実際はユーザーが見えない場所で呼び出されることがあるので、使わない方が良いです。

注意点

初回表示時の判定

scrollViewDidScroll(_:) で判定処理を入れているので、画面ロード後、ユーザーの操作なしだと判定処理が走りません。

そのため、画面ロード後に明示的に判定する必要があります。

GameWithアプリでは RxSwift を使っているので、scrollView.rx.contentOffsetSubscribe して初期状態でも判定させることができました。

判定タイミング

この方法は、画面上の描画後の座標を元に、2つのフレームが交差したかどうかを判定しています。

そのため、描画完了前に判定してしまうと正しい座標になりません。

判定がおかしいなぁと思ったら

  1. view.layoutIfNeeded() で描画させる
  2. DispatchQueue.main.async 内で判定処理を呼ぶ

のどちらかを試してみてください

重複除外

scrollViewDidScroll(_:) で表示判定をしているので、イベントが何回も送られます。 一度送ったイベントを送らないように除外する必要があります。

最後に

この実装でかなり時間がかかったので、同じ課題に当たるiOSエンジニアの方に少しでも役に立ったら幸いです!

GameWithのDeveloper向けTwitterアカウントがあります。

ブログの更新情報などを発信するので良かったらフォローしてください!!

twitter.com

サスティナブルな社内LT #GameWith #TechWith

サスティナブルな社内LT

こんにちは! コミュニティではごーと呼ばれている只野です。

前回社内LTを続けるコツについて、ブログに書きました!

tech.gamewith.co.jp

今回はオフィスで開催していた社内LTをオンライン開催に変更をしていった経緯について書いていきたいと思います!

サスティナブルな社内 LT とは

私たちは、社内 LT を GamWith の開発組織における文化形成の手段として行ってきました。LT を行う機会が増えると、個性を共有できるようになり、個性の集まりが GameWith 特有の文化として根付いていくことが期待できます。 この取組みが長いスパンで行われることを sustain(持続する)とable(〜できる)からなる言葉と重ねて、「サスティナブルな社内LT」 と考えています。

社内LTの変化

1. オフィスで開催していた時期

以前書いたブログにもある通り、毎週金曜日の19:15 ~ 19:45 に社内 LT を開催していました!

この時期については上記のブログに詳しく書いてありますので、そちらをご参照ください。

2. 出社組とリモート組が混ざっていた時期

LTの発表は出社組が zoom でオフィスから社内LTを配信しリモートしているメンバーも視聴していました。

3. フルリモートになった初期

2の時期は在宅勤務の推奨となっていましたが、3/30(月)に発表のあったとおり弊社はフルリモートへ移行しました。

gamewith.co.jp

フルリモートに移行して1ヶ月ほどは社内 LT を開催していませんでした。

フルリモートという環境の大きな変化もあり、社内 LT の開催方法などについて考える余裕があまりなかったのが正直なところです。

4. フルリモート後の復活

4/17(金)に社内 LT を復活させ、今日まで毎週開催しています。

全員がフルリモートの環境に徐々になれてきたため、復活させました。

全員フルリモートなので、逆に社内 LT はやりやすいのでは?と気づきました。

プロセス

時間帯は毎週金曜日の19:30 ~ 20:00に行っています!

以前までは2,3人が10分程度LTを行っていましたが、現在は4人が5分程度 LT を行っています。

人数と時間を変更した理由としては、以前までは質疑応答や感想を話したりとコミュニケーションの時間を取っていました。 しかし、オンラインで双方向のやり取りが難しいと思い、視聴者にはマイクをオフにしてもらい配信形式のような形にしました。 また、視聴者が飽きないように短い LT にして発表者の人数を増やしました。

オンラインになったので無音の時間ができるだけ無いように、テンポの良いファシリを心がけています。

オフィスで開催していたときは写真を撮っていましたが、オンライン開催では社内 LT の配信を録画し編集しています。 編集で無音をカットした動画は、テンポが良くとても見やすいです。

最初の方は録画した映像を iMovie を使い手動で編集していたが、とても大変でした😭 現在は vrew というツールを利用して自動で編集をしています!

vrew.voyagerx.com

オフィスで開催していたときより発表者の人数が増えた分、時間通り30分で終わらせるために多めにバッファを取っています。

視聴者は Slack のスレッドにコメントをしています。 最初は画面にコメントが流れるツールを使っていたが、準備が大変で今の形に落ち着きました。

LTが5分になり発表者の準備もそこまで時間がかからないので、発表者の準備が以前と比べて楽になりました。

告知は週の前半で1回お知らせをして、開催時間の少し前に再度お知らせをしています。

f:id:tiwu:20200521190555p:plain

全員参加しているチャンネルで告知をしているので、頻繁に @here をしないように告知の回数は最小限にしています。

効果

オンライン開催になったので席が少し遠かった人も発表をしたり、視聴者として参加するようになりました!

オンライン化により可能性が広がった事で、今後外部との合同 LT なども検討しています。 弊社と共に LT を開催したい場合などは、是非 @gamewith_dev まで気軽にご連絡ください!

フルリモートになり曜日の感覚が薄まっていったが、毎週金曜日の19:30に開催をしているので、少しずつ曜日の感覚を取り戻してきたのではないかと思います。

またフルリモートになって他チームの人の顔を見る機会が以前よりも減ったので、この社内 LT で他チームの人の顔が見れることもオンライン化のメリットだなと感じました。

オンラインになったので、作業中の BGM として社内 LT を聞くこともできますし、参加するスタイルはより自由になっています。

まとめ

以前のブログで社内 LT を続けるのに特に苦労はなかったと書いたのですが、上記の通りフルリモートになった際に一ヶ月ほど社内 LT の開催を停止してしまう時期がありました。

ですが、いざ再開してみると意外と問題なくオンライン社内 LT が実施できることがわかりました。

この数ヶ月で日々の MTG などの通常業務もフルリモート体制に移行したこともあり、自分達が思いの外オンライン環境に適応していたことがわかりました。

これからもサスティナブルな社内 LT をやっていきたいと思います!

最後に

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

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

twitter.com