Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

Diverseエンジニアの裏側に迫る!見せびらかし会レポート #1

こんにちは!Diverse広報担当です。

突然ですが、Diverseでは週に1回、エンジニア同士で「見せびらかし会」を開催しています。

f:id:diverse-tech:20210824183340p:plain

「見せびらかし会」とは、各エンジニアが1週間の中で頑張った開発Tipsを、仲間に向けて発表する場。
各自の知見やノウハウの共有を目的にトライアルとして始めてみました。”見せびらかす”という仰々しい名前ですが、ちょっとした工夫や改善も大歓迎!というラフな発表会です。

せっかくなので、見せびらかし会の様子を色々な方に知ってもらいたい!と思い、ブログで発信することにしました。

記念すべき第1回目は、菊池さん(@kikuchy)と藤田さん(@SAMUKEI)の見せびらかし会に密着しました。
ぜひお読みください!

▼目次

イベントの記録をシンプルにしたい

菊池さんの今週の見せびらかしについて

菊池:私は、youbrideでクライアントのアプリの開発をしています。先日、そこで解決すべき案件が発生しました。「イベントを記録する」という点についてです。
イベントをただ記録するだけだったら、FirebaseAnalyticsやAdjustを適当に呼び出しても問題はありません。

しかし、このイベントはFirebaseAnalyticsとAdjustで記録して、こっちのイベントはFirebaseAnalyticsだけで記録するなど統一されていないと、このイベント記録はどこで誰がやっているのかわからなくなってしまうという問題があります。今回、そこの部分を解決するための仕組みを作りました。

どんな仕組みを作ったのか?

菊池:まず、取り組んだこととしては、デザインパターンのFacadeパターンの応用をしています。

f:id:diverse-tech:20210824183414p:plain

イベントの種類を事前に定義をしておいて、例えば検閲前に登録を完了した・検閲後の登録完了イベント・提案に対して何か肯定的な行動をしたなどのイベントをいくつか用意しています。

f:id:diverse-tech:20210824183444p:plain

これ自体はシールドクラスで用意してあって、イベントによっては課金金額などのパラメーターを取れるようにしてあります。

f:id:diverse-tech:20210824183457p:plain

f:id:diverse-tech:20210824183512p:plain

以上のようにイベントの定義をしていき、登録済ボタンをタップしたというようなイベントにEventTrackerというものを持ってきます。
このEventTrackerのメソッドを呼び出すと、記録がされるというようにUIのコード中で設定されています。

次に、イベントの記録をどのようにするのかというのは、TrackingServiceを実装しているところがあれば、そこに記録することができるという仕組みにしてあります。

このTrackingServiceを実装しているのが現段階で2つ用意してあって、FirebaseAnalyticsとAdjustです。

f:id:diverse-tech:20210824183528p:plain

この2つのサービスというのが、対応したイベントについて記録するサービスにパラメーターを送り飛ばすという処理をしています。これで、FacadeになっているのはEventTrackerになり、処理の実装を持ったサービスを入れることで仕組みができます。

このような仕組みにすることで、EventTrackerを呼び出す側は、どのサービスを使っているのかを気にする必要がありません。

つまり、イベントを発行する側は、どんなサービスで記録しているかを意識する必要はありません。また、イベントを記録する側も、どのイベントを記録するかだけをチョイスして、記録をしていけばいいという仕組みにすることができました。

これは、大学生の時にいわゆるGoF本を読んで知った、Facadeパターンを応用した仕組みです。過去に培った知識が、何年か越しに活きてきたというのが今回の私の見せびらかしです!

スクラムで各自の進捗を見える化したい

藤田さんの今週の見せびらかしについて

藤田:技術的なことではなくチームのためのツールの話です。業務改善まで効果がでているかまだわからないのですが、YYCでやっているスクラムの数値測定周りのツールについて紹介します。

たぶんyoubrideでもやられているとは思いますが、今スクラムで開発をやっていて、日々のバーンダウンチャートをチームで毎日見るようにしています。
Sprintを変えるだけで過去のデータを見ることができるバーンダウンチャートは、GASとスプレッドシート力だけで成り立っています。

f:id:diverse-tech:20210824183548p:plain

どんな仕組みを作ったのか?

藤田:ASANAに入っている各セクションごとのストーリーポイントを毎日23時頃に取りに行ったものを合算して、完了や未完了という大まかに定義付けをして見える化しているというものです。

f:id:diverse-tech:20210824183605p:plain

例えばSprint16で見ていくと、緑色のレビュー部分が徐々に増えていって、一気に消化しているということが分かります。逆に後半になるまでレビューが積まれていない場合は、異常な状態ということをチームとして検知できるようにしました。

f:id:diverse-tech:20210824183618p:plain

また、スクラムイベントの終わりの振り返りのタイミングで、今週や今スプリントはどうだったのかというタスク消化率をグラフで出して、目標としては90%維持と考えて取り組んでいます。これらのグラフも全てGASの力で作っていて、TypeScriptで書いてclaspでGASに持っていくという形で作っています。

f:id:diverse-tech:20210824183631p:plain

f:id:diverse-tech:20210824183642p:plain


【質問】動作確認はどのようにされていますか?

藤田:がっつりやっている訳ではありません。技術的には微妙かなと思われるかもしれませんが、一度claspで出して確かめる方法で行っています。

また別の方法として、直接GASの方に書いて動作を確かめたら…claspのTypeScriptはキレイにコンバートされるので、それを参考にしながらTypeScriptへの適応をしています。

f:id:diverse-tech:20210824183657p:plain


【質問】TypeScriptの適応確認と言われましたが、TypeScriptを使用している目的はありますか?

藤田:TypeScriptを使うことでコンパイルしてくれるということもありますが、claspを使うことでGitHubで管理できるので、属人性を若干でも減らすことができるかなというイメージで使用しました。

GASだけだと説明も無かったりチームとして共有するには難しく、GitHubで管理するとドキュメントとしてREADMEなども置くことができるので取り入れました。


最後に

いかがでしたか?
Diverseエンジニアは、見せびらかし会でお互いを刺激し、チームのナレッジ蓄積を図っています。
今後も見せびらかし会を通じて、Diverseエンジニアの裏側を紹介していきます!お楽しみに!


◆Diverseの取り組みに共感いただいた方、エンジニアの働き方に興味がある方、ぜひ弊社の採用ページをご覧ください!

herp.careers