GameWith Developer Blog

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

2021年 GameWith の技術広報の1年間の振り返りとこれから #GameWith #TechWith

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

今年も始まりましたアドベントカレンダー!

1発目のブログは去年に引き続き、今年1年間の技術広報活動を振り返っていこうと思います!

qiita.com

Blog

今年(2021年12月1日時点)の投稿数は 13 本でした!

去年が 24 本だったので、約半分の投稿数になります。

PV は2万3千ほどになります!去年は2万4千ほどだったので、投稿数は半分ですが、PVは去年とほぼ同じでした🎉

f:id:tiwu:20211129120228p:plain
2021年のPVの推移

f:id:tiwu:20211125141147p:plain
2020年のPVの推移

f:id:tiwu:20211126190403p:plain
2019年のPVの推移

ちなみに今年1番PVの多かった記事はこちらの記事でした!

tech.gamewith.co.jp

月1のリモートペア・モブブログ

弊社はフルリモートワークを実施しているので、今まで行っていたリアルでのペアブログ・モブブログは実施できなくなりました。

ペアブログ・モブブログ自体は以前から月に1回開催をしており、フルリモートワークになって今でも頻度を変えず月1で実施しています。

フルリモートワーク環境では Google Meet でビデオ会議を行い、VSCode Live Share を利用して執筆作業を行っています!

詳しくはこちらの記事を御覧ください。

tech.gamewith.co.jp

ポッドキャスト

新たな取り組みとして GameWith メンバーが企画し、ポッドキャストでの発信も行いました!

tech.gamewith.co.jp

GameWith メンバー3人の談義が収録されているので是非聞いてみてください!

GitHub Repository

また、新たな取り組みとして @serima がリードして、採用情報をまとめた GitHub Repository を公開しました。

tech.gamewith.co.jp

先週採用技術の更新をしたので Repository も是非チェックしてみてください!

github.com

ツイッター

引き続きブログの告知が主なつぶやき内容になっていますが、運用中です 💪

twitter.com

振り返り

去年に引き続きフルリモートワークな1年でした。

今年も主に活動はブログでしたが、ポッドキャスト・GitHub Repository の公開など GameWith として新しい取り組みにチャレンジすることができました。

継続的なアウトプットや広報活動を続けることができたのは、技術広報の活動に携わっていただいた方々やブログを見ているユーザー、サービスを利用しているユーザーのおかげです!ありがとうございました!

来年も継続的に、アウトプットしていくのでよろしくおねがいします!

GameWith のログの実装について #GameWith #TechWith

はじめに

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

今回のブログは普段の開発の際にどのようにログの実装をしているか解説していきたいと思います。

ログの環境周り

GameWith では Google Analytics と タグマネージャーを利用しログの管理を行っています。

tech.gamewith.co.jp

こちらでも触れていますが Google Analytics に送信されたログは BigQuery へエクポートし、DataPortal などを利用し可視化・調査を行っています。

実装例

例1

画面下部にあるこちらのコンポーネントを例に紹介していきます。

f:id:tiwu:20211021180604p:plain

このコンポーネントでは「インプレッション」と「クリック」の2つのログが実装されています。

<div class="walkthrough-recruit-banner gtm-ga4-walkthrough-imp-event" gtm-walkthrough-name="ゲームプレイワーカー" gtm-walkthrough-type="攻略トップ">
    <img src="https://img.gamewith.jp/walkthrough/recruit/banner.png" class="_img" alt="recruit banner">
    <div class="_link">
        <a href="https://recruit-writer.gamewith.co.jp/" class="btn is-accent-nuri btn--full gtm-ga4-walkthrough-click-event" gtm-walkthrough-name="ゲームプレイワーカー" gtm-walkthrough-type="攻略トップ" target="_blank" rel="nofollow">詳細を見る</a>
    </div>
</div>

インプレッションは gtm-ga4-walkthrough-imp-event クラスをつけることで発火し、クラスが付与されているタグの gtm-walkthrough-namegtm-walkthrough-type の値が送信されます。

このインプレッションの処理はタグマネージャーでトリガーを定義しています。

f:id:tiwu:20211021190227p:plain

トリガーのタイプを「要素の表示」にすることでタグマネージャー側でインプレッションの監視を行ってくれるため、実装者が自前でインプレッションの監視処理(例えば Intersection Observer)を書く必要はありません!

クリックは gtm-ga4-walkthrough-click-event クラスを a タグに付与することで a タグを含む a タグ内のタグ全てのクリックで発火し、インプレッションと同様にgtm-walkthrough-namegtm-walkthrough-type の値が送信されます。

このクリックの処理もタグマネージャーでトリガーを定義しています。

f:id:tiwu:20211021190923p:plain

トリガーのタイプを「クリック - リンクのみ」にすることで a タグのクリックの監視を行ってくれます。

※トリガーのタイプを「すべての要素クリック」にすると、a タグ内の別のタグをクリックした際に発火しないので要注意です

実装者はログを送信したい対象に対してクラスなどを付与するだけでログが送信されるため、ログ送信の実装工数はかなり少なくなっています 🎉

例2

ケースによっては JavaScript から任意のタイミングでログを送信したいこともあります。

その場合例1のようにクラスを付与するとタイミングを制御できないのでタグマネージャーでカスタムイベントを作成し、JavaScript から発火させます。

const fireWalkthroughClickEvent = (name, type) => {
  window.dataLayer.push({
    "event" : "Walkthrough_Click_Event",
    "gtm-ga4-walkthrough-name" : name,
    "gtm-ga4-walkthrough-type" : type,
  })
};

例1と別のトリガーを作っていますが、最終的には例1と同じイベント名でログが送信されます。

f:id:tiwu:20211022102304p:plain

例3

GameWith には GameWith Design System という Vue + TypeScript で Web Components を作る仕組みがあり、こちらでもログを送信することができます。

GameWith Design System について詳しくはこちらをご覧ください。

tech.gamewith.co.jp

GameWith Design System は TypeScript で書いているため、下記のような型定義を作り利用しています。

※利用しているトリガーは例2と同じものです

type GTMEvent<T> = {
  event: string;
} & {
  [P in keyof Omit<T, "event">]: P extends `gtm-ga4-${string}` ? T[P] : never;
};

interface GTMWindow extends Window {
  dataLayer: {
    push: (args: unknown) => boolean;
  };
}

declare let window: GTMWindow;

class GA4 {
  public static push<T extends GTMEvent<T>>(args: T): void {
    window.dataLayer.push(args);
  }
}

利用時は下記のようなイメージです。

interface ClickEvent {
  event: "gtm-ga4-walkthrough-click-event";
  "gtm-ga4-walkthrough-type": string;
  "gtm-ga4-walkthrough-name": string;
}

GA4.push<ClickEvent>({
  event: "gtm-ga4-walkthrough-click-event",
  "gtm-ga4-walkthrough-type": "type",
  "gtm-ga4-walkthrough-name": "name",
});

終わりに

インプレッションの監視・クリックによる発火などタグマネージャーに任せることができ、かなり便利と感じます 🎉

ぜひ何かの参考になればと思います!

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com

ゲームをより楽しむための攻略ツール開発コンテストを開催! #GameWith #TechWith

はじめに

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

今回のブログは現在エントリー募集中のツール開発コンテストについて紹介していきます。

ツール開発コンテスト

f:id:tiwu:20211011120826p:plain

この度 GameWith では、ゲーム攻略のためのツール開発コンテストを開催いたします。

最優秀賞の賞金は何と100万円、18歳以上であればどなたでもご応募いただけます!

開催の背景

GameWith は“ゲームをより楽しめる世界を創る”をミッションとして掲げています。

GameWith がユーザーがよりゲームを楽しめるツールを提供するだけでなく、ユーザー自らがゲーム攻略ツールを開発し、それを世の中に公開する機会を提供することで、ミッションの実現を目指しています。

スケジュール

  • エントリー期間:2021/9/17~2021/10/21
  • 応募締切:11/15
  • 結果発表:11月末~12月初頭(予定)

※延長可能性あり

賞金

最優秀賞 100万円

優秀賞  50万円

特別賞  10万円

応募方法・詳細

応募方法や詳細はこちらの特設サイトをチェックしてください!

tool-contest.gamewith.co.jp

GameWith とツール

本ブログでも過去にいくつかツールについて執筆しています!

tech.gamewith.co.jp

tech.gamewith.co.jp

Firebase と GDS(GameWith Design System) により以前と比べ高速な開発が可能になり、現在もいくつかツールを開発をしています 👍

GDS についてはこちらを御覧ください。

tech.gamewith.co.jp

終わりに

「応募したい!」「応募するか悩んでいる…」という方は、まずはエントリーをお願いいたします!

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com

コネクテッドシート導入時に意識したい料金について #GameWith #TechWith #ConnectedSheet

はじめに

GameWithディレクター兼分析チームの@fujii86です。 Googleのグループウェア機能の1つ、コネクテッドシートを社内で活用するにあたり、気になる料金面についてまとめていきます。

Connected Sheetとは

Googleが米国時間2020年6月30日「G Suite」ユーザーに向けて一般提供を開始した、Spreadsheet上でBigQueryデータを取り扱うことができるサービスです。
Google WorkspaceのEnterpriseサービスプランでのみ活用が可能となります。

SQLを活用せず、データをインポートするかのようにBigQueryデータを連携し、取得したデータを「グラフ」「ピボットテーブル」「関数」等の形式で集計表示する事が可能です。 ※より高度な事もできます

経緯

GameWIthはGoogle のグループウェア「Google Workspace(旧G Suite)」を活用しておりますが、最新の機能を取り入れ業務の効率化やセキュリティ強化を図る為、先日サービスプランを「Enterprise」へアップデート致しました。

アップデートに伴い多くの機能が追加されましたが、その中にある「コネクテッドシート」は、スプレッドシートでBigQueryデータを関数やグラフ、ピボットテーブルなどを使用して分析できます。ただ注意点として、BigQuery はクエリを実行する度に都度課金が発生するため、仮に全社員が毎日全データを select するといったことが起きてしまうと利用料金が跳ね上がってしまう可能性があります。

そこで、私のほうでコネクテッドシートの料金周りの調査を行う事となり、その調査結果を共有させて頂く形となりました。

結論としてビッグデータを多くの人が活用できるようにするという観点に置いて、とても素晴らしい機能である為、是非読んでる皆様においては料金の発生箇所を把握して運用に踏み出して頂けたら幸いです。

料金に関しての調査結果

料金が発生する場所

  • 連携データから「グラフ」「ピボットテーブル」「関数」「計算された列」「列の統計情報」の適応(作成)をする時
  • 作成した「グラフ」「ピボットテーブル」「関数」「計算された列」「列の統計情報」の更新をする時
  • カスタムクエリでbigqueryと連携をする時

料金が発生しなかった場所

  • データ連携時
  • 異なるアカウントでの接続時
  • Spreadsheet開閉時

料金を軽減する為に意識したい事

  • 更新タイミングをデフォルトの手動同期で活用していくこと
  • 適応又は更新時には表示されている処理量を確認すること
  • カスタムコスト管理の作成を実施すること

補足

  • 自動同期を活用したダッシュボードを作成する場合は、管理が行いやすいデータポータル活用を推奨

コネクテッドシートが有効なケース

  • SQL知識が無くてもビッグデータの分析が行える為、企画職等が直接分析を行いやすい
  • 手動更新が行える為、今後継続して活用するかわからない分析のテスト運用を行いやすい

機能概要

コネクテッドシートの具体的なイメージが沸かないかと思うので、機能の紹介です。
コネクテッドシートは、スプレッドシートから活用することができます。

①データコネクタでbigqueryと連携を行う
指定するテーブルの情報は別途活用者向けにまとめておく必要があります。 f:id:fujii86:20211006190528p:plain

②連携シートから活用したい形式を選択
主にはグラフ、ピボットテーブル、関数を活用していきます。 f:id:fujii86:20211006190935p:plain

③グラフの設定を埋めていく
ピボットテーブルは設定項目が異なり、関数は設定方法が異なります。
下図はグラフの一例となります。 f:id:fujii86:20211006191430p:plain

④データの更新時間の設定を確認する
手動更新を推奨してますが、自動更新についても触れておきます。 f:id:fujii86:20211005161828p:plain

最後に

ここまでお読み頂きありがとうございました。
活用次第では素敵な機能だと感じておりますので、より多くの企業に導入され、より多くの人が活用できることを願っております。

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com

GDS のビルド方式をパッケージビルド方式に変更しました #GameWith #TechWith

はじめに

こんにちは!スケールアーキテクトチームの @53able, @inosy22, @nog です!

今回は GDS のビルドの構成を変更したので、紹介していきたいと思います!

GDS についてはこちらのブログで紹介していますので、御覧ください。

tech.gamewith.co.jp

課題

GDS での開発も1年半が経ち、いくつか課題が見えてきました。

ビルド成果物が一つにまとまっているため、下記のような課題があります。

  • 開発/リリースの度に他の機能への影響を及ぼす可能性がある
  • 不要な箇所で不要な機能まで読み込まれていることが多く、無駄な通信が発生している
  • また、リリースの度にバージョンが変わるため変更をしていない箇所の JS のキャッシュが消え再読み込みが走り、無駄な通信が発生している
  • 開発時にバージョンがよくコンフリクトする
  • ビルドにかかる時間が長くなってきた

これらの課題を解決するためにビルド成果物を1つにまとめず、パッケージ単位(幾つかのコンポーネントをバンドルした単位)で分割してビルドする方式に変更をしました。

今までのビルド方式

ビルドターゲットを全てのコンポーネントにしており、ビルド成果物を1つにまとめていました(ビルドは下記コマンドを叩くイメージです)

$ yarn build

生成されるパスは以下のようになっており、ひとつのバージョンに対してビルドする度に全てのコンポーネントが更新されていました。

gds/${version}/gds.min.js
gds/${version}/gds.0.min.js
gds/${version}/gds.1.min.js
gds/${version}/gds.2.min.js
gds/${version}/gds.3.min.js
...

パッケージビルド方式

変更後のビルド方式はパッケージ単位でビルドし、更新するコンポーネントを減らしました。

$ PKG=Sample1 yarn pkg
gds-packages/sample1/${version}/gds-sample1.min.js
gds-packages/sample1/${version}/gds-sample1.0.min.js
gds-packages/sample1/${version}/gds-sample1.1.min.js
gds-packages/sample1/${version}/gds-sample1.2.min.js
gds-packages/sample1/${version}/gds-sample1.3.min.js
...

$ PKG=Sample2 yarn pkg
gds-packages/sample2/${version}/gds-sample2.min.js
gds-packages/sample2/${version}/gds-sample2.0.min.js
gds-packages/sample2/${version}/gds-sample2.1.min.js
gds-packages/sample2/${version}/gds-sample2.2.min.js
gds-packages/sample2/${version}/gds-sample2.3.min.js
...

パッケージビルド方式では、パッケージ単位でバージョンを管理しているため、上記のようにパッケージ名がパスに含まれています。

CI/CD 環境

今までのバージョンの指定は package.jsonversion を利用していました。

パッケージビルド方式ではパッケージ名ごとにバージョンが違うため、各パッケージのディレクトリに .version ファイルを設置し利用しています。

今までの CI/CD では差分などはチェックせず毎回ビルドを行っていました。

パッケージビルド方式では開発中の CI/CD では git diff を行い master ブランチの差分を元にデプロイの対象を選定します。また、 .version ファイルが設置されていない場合はリリース対象になりません。

本番環境の CI/CD では S3 にデプロイされているバージョンと比較し、大きい場合のみデプロイされます。

苦労した点

複数のパッケージを同じページで読み込むと、一部のパッケージの WebComponents が使えないケースがありました。

この原因を調査して解決するには、 vue-cli によってビルドされた成果物が、WebComponents を使えるようにするための、内部の構造を理解する必要があったので、紹介させていただきます。

新しいパスを見て気づいた人もいるかもしれませんが、ファイル名にもパッケージ名を入れています。

すでに ${package-name}/${version} のようにパスにパッケージ名を入れているので、ファイル名はどのパッケージ名でも gds.min.js にしてもよいはずです(わざわざパッケージ名を入れる必要はありません)。

しかし、ファイル名にパッケージ名を入れているのは理由があります。

vue-cli からビルドされた成果物の内部コードでは、ファイル名をキーにして window にオブジェクトが新しく作られます。

そのため、ファイル名を gds.min.js で共通にしてしまうと、window["gds_jsonp"] に対して上書きし合うため、バグの温床になってしまいます。

ファイル名にパッケージ名を入れることで gds-xxx.min.js になりますが window["gds-xxx_json"] になるため、上書きを回避できます。

$ vue-cli-service build --target wc-async --inline-vue --name gds ...
(window["gds_jsonp"] = window["gds_jsonp"] || []).push([[0], ... }]);

$ vue-cli-service build --target wc-async --inline-vue --name gds-sample1 ...
(window["gds-sample1_jsonp"] = window["gds-sample1_jsonp"] || []).push([[0], ... }]);

http:// https://cli.vuejs.org/guide/build-targets.html#async-web-component

最後に

ブログの冒頭であげていたこれらの課題は、パッケージビルド方式にすることで解決されました!

開発/リリースの度に他の機能への影響を及ぼす可能性がある

👉 パッケージごとにビルドされるため、他のパッケージに影響を及ぼすことはありません。

不要な箇所で不要な機能まで読み込まれていることが多く、無駄な通信が発生している

👉 必要なページで、必要なパッケージを読み込むようにすることで、通信量を削減できるようになりました。

また、リリースの度にバージョンが変わるため修正をしていない箇所の JS のキャッシュが消え再読み込みが走り、無駄な通信が発生している

👉 リリースが行われても対象外のパッケージのバージョンは変わらないため、引き続きがキャシュが有効になり無駄な通信は発生しなくなりました。

開発時にバージョンがよくコンフリクトする

👉 パッケージ単位で .version が定義されるため、コンフリクトがほぼ発生しなくなり分担して作業が行いやすくなりました。

ビルドにかかる時間が長くなってきた

👉 概ね30秒程度短縮されて、1分以内でビルドが完了するようになりました。

パッケージビルド方式での課題としては、以下があります。

  • 引き続きバージョンは手動で書き換える必要がある
  • 実は全てのコンポーネントをパッケージビルド方式に変更しておらず、新旧のビルド方式が混ざっている
  • 全パッケージで利用しているファイルを修正した際に、全パッケージのバージョンを変更する必要がある
    • パッケージ毎にビルドできるメリットの裏側的な
  • パッケージを横断する修正を行った場合に、複数パッケージをリリースする必要がある

今回の改修でコンポーネント実装がよりスケールできるようになりました!

今後もより良いコンポーネントを作り、GameWith を改善していきます!

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com

GameWith の フロントエンド を TypeScript へマイグレーションする #GameWith #TechWith

はじめに

こんにちは!Incremental Stream Team の @53able です!

今回は現在自分が着手中の TypeScript マイグレーション PJ について書いていきたいと思います!

GameWith の JavaScript

まず GamewWith の JavaScript について紹介していきたいと思います。

JavaScript のボリューム

Cloc というツールを利用し JavaScript のコード行をカウントしてみました。

github.com

brew 経由でインストールし、cloc ディレクトリ名 を実行すれば、カウントしてくれます。

brew install cloc
cloc /Gamewith

結果は3万6千行でした!

JavaScript のビルドフロー

次に、ビルドフローについて紹介します。

GameWith は Gulp を利用して JavaScript を連結・圧縮しています。

gulpjs.com

GameWith メインリポジトリでは Vue, React といったフレームワークは導入しておらず、jQuery を利用しています。

※GameWithDesignSystem のリポジトリでは Vue を利用しています

tech.gamewith.co.jp

TypeScript 化

今回 GameWith の3万6千行を一度に TypeScript 化し、リリースするのは現実的ではないと判断しました。

そのため、ファイル単位で TypeScript 化して修正をするという影響範囲を小さくしたマイグレーションのフローにしました。

新しいビルドフロー

TypeScript 化の際に長年積み上げてきた Gulp で行っているビルドフローの改修はとてもリスクが大きいため、Gulp は引き続き利用することにしました。

f:id:tiwu:20210830150127p:plain

新しいビルドフローは Gulp の前に TypeScript を割り込ませ、既存のフローをできるだけ変更せず導入を考えています。

JavaScript を中間コードとして扱う発想でこの新しいビルドフローを考えました。

マイグレーションの作業フロー

JavaScript -> TypeScript は ts-migration というツールを利用しました。

github.com

今回マイグレーションの作業フローを作るにあたって、以下の作業を行いました。

  1. ts-migration をいくつか適当なファイルに実行
  2. 生成された TypeScript のファイルを ESLint で整形し既存の JavaScript のファイルと目で差分のチェック
  3. 次に、自動化したいフローを洗い出すため手動でファイル操作を行いました
    1. ts-migration はフォルダをターゲットに動作するため、変換用フォルダへ JavaScript をコピーする
    2. ts-migration をフォルダ指定で実行し TypeScript へマイグレーション
    3. マイグレーションで変換後の TypeScript を元の JavaScript と同じ場所へコピーする
    4. TypeScript を tsc でコンパイルし、オリジナルの JavaScript が上書きされる ( ここで JavaScript 👉 TypeScript 👉 JavaScript の差分がわかる)
    5. TypeScript 化された JavaScript は ESLint 対象外、ファイルを削除し、.gitignore に追加する

f:id:tiwu:20210830150147p:plain

ts-migration は、ディレクトリをターゲットに TypeScript へマイグレーションするので、一旦変換用のディレクトリに作業ファイルをコピーしてマイグレーションを実行するようにしています。

手動で作業を確認後、同等の動作を Node で動作するスクリプトを書き、自動化をしました。

※スクリプトを書く際に js-fire を利用しました

github.com

最終的に完成した自動化のスクリプトは下記のように3つになりました。

// 1. 変換させるたのフォルダへ JavaScript をコピーする
npm run migrate -- start /GameWith/xxx.js

// 2. `ts-migration` をフォルダ指定で実行し TypeScript へマイグレーション
// 3. マイグレーションで変換後の TypeScript を元の JavaScript と同じ場所へコピーする
// 4. TypeScript を `tsc` でコンパイルし、オリジナルの JavaScript が上書きされる
npm run migrate:sync

// 5. TypeScript 化された JavaScript は ESLint 対象外、ファイルを削除し、`.gitignore` に追加する
npm run migrate -- end /GameWith/xxx.js

スクリプトは下記のようなイメージです。

const migration = {
    start: async (jsFile) => {
        // 1. 変換させるたのフォルダへ JavaScript をコピーする
        return jsFile;
    },
    end: async (jsFile) => {
        // 5. TypeScript 化された JavaScript は ESLint 対象外、ファイルを削除し、`.gitignore` に追加する
        return jsFile;
    },
};

fire(migration);

おわりに

破壊的なビルドフローの変更ではなく、既存ファイル以前のソースコードを設けることにより、マイグレーションコストを格段に減らしました。

TypeScript へマイグレーションしますが、中間コードが JavaScript なので、既存ファイルと共存は問題ないようにしています。

また、短期間ですべての JavaScript をマイグレーションしてしまうと既存の動いている他案件とコンフリクトし、解消するコストがかなり高くなってしまうため、修正の際に1ファイルずつ案件を担当するエンジニアがマイグレーションできるフローにしました!

まだマイグレーションは始まったばかりですが、完走したいと思います!

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com

ペア・モブ作業(見積り・設計・プログラミングなど)の紹介 #GameWith #TechWith

はじめに

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

以前モブ設計・モブ見積りについて紹介しました。

tech.gamewith.co.jp

今回はチームや開発サイクルを紹介しつつ、いろいろなペア・モブ作業について紹介していこうと思います!

チーム・開発サイクルの紹介

自分が所属しているチームはエンジニア2人とディレクター1人の合計3人で構成されています。

チームは1週間のスプリント開発を行っており、ざっくり下記のようなサイクルで動いています。

※作業 = 設計・開発・コードレビュー・テスト・リリースなどが含まれます

  • 月曜日
    • 作業
    • 新規案件共有会・見積り会
  • 火曜日
    • 作業
    • スプリントの終了・開始
  • 水曜日
    • 作業
  • 木曜日
    • 作業
  • 金曜日
    • 作業

モブ見積り

新規案件共有会で新しい案件の共有を受けた後、モブ見積りを行っています。

自分が所属している開発チームのエンジニアとディレクター、他チームのエンジニアがモブ見積りに参加しています。

Google Meet で通話しながら Hatjitsu というツールを利用して見積りを行っています。

hatjitsu.toolforge.org

以前書いたモブ見積りでのブログでも紹介しましたが、とても重宝しています!ありがとうございます!

f:id:tiwu:20210719134903p:plain

見積りは1案件毎に下記フローで行っており、1案件 2,3 分で終わるスピードで進めています。

  • 案件の共有
  • 議論
  • 見積り
  • (ズレていたら)議論
  • 決定

見積もりの場に起票者はいないため、要件などに関する質問は新規案件共有会で起票者にしています。

見積りがズレた際は、3, 5 などの隣り合っている数値の場合は大きい方を採用しています。

3,5,8 など3パターン以上の場合は最小・最大の意見を聞いて、再度見積もりをしたり数値を変えたりして収束させています。

ペア設計

自分が所属しているチームはエンジニアが2人なので、スプリントの開始後は Google Meet で通話しながらペア設計をしています。

水曜日・木曜日・金曜日は基本的に 15:00 - 19:00 でペア作業をしているので、1時間毎に休憩を入れつつ作業を進めています。

ペアプログラミング

実装もエンジニア2人でペアプロしています。

Google Meet で通話しながら VSCode Live Share を利用してペアプロしています。

marketplace.visualstudio.com

ドライバー・ナビゲーターという役割分担はしていないですが、実際に docker を立ち上げている側が比較的ドライバーよりになっています。

Google Meet + VSCode Live Share + docker などを組み合わせると Mac の動作が結構重くなったり、一部言語はシンタックスハイライトが効かなかったりしますが、かなり重宝しています!

VSCode Live Share について詳しくはこちらを御覧ください!

tech.gamewith.co.jp

コードレビュー

普段1人で設計やプログラミングをした際は、チームメンバーにレビューをしてもらっています。

ペア設計・ペアプロをしている案件についてはメンバーと一緒に作業をしているので、レビューというフローは飛ばしています。

(PR を立てた後に簡単にチェック的なことはしたりしています)

テスト

テストケースもエンジニア2人で設計したりテスト作業も2人で分担して行っています。

案件によってはQAエンジニアと協力をしてケース作成、作業を行っています。

終わりに

チームのエンジニアが2人というのを最大限に活かし、ほとんどのタスクをペア・モブで作業をしています!

1人で作業をしているとレビュー待ちなどで案件がストップしたりしますが、基本的に止まること無く進んでいきます。

また、「案件 vs 自分」ではなく「案件 vs チーム」になり知恵を出し合いつつ、知見の共有を行うことができていると感じます。

作業側のメリットを考えペア・モブ作業を開始しましたが、雑談が発生するという副次的なメリットがあり、リモートワーク環境でのスタンダードになっていくのでは?と思ったりもしています!

チームのパフォーマンスは下記で計測しているので、ペア・モブ作業による変化を観測し、より良くしていきたいと思います!

tech.gamewith.co.jp

Twitter

Twitter にてテックブログの投稿をツイートしていますので、よろしければフォローをお願いします!

twitter.com

Wanted!

一緒に働く仲間(特にサーバサイドエンジニア)を絶賛募集中です!

以下 Wantedly のページからぜひカジュアル面談へお申し込みください!

www.wantedly.com