【ログ物語】第2章 ～ログ/収集の仲間～
こんにちは！オールアバウトでデータエンジニアをしている@ondaljhです。
「 データエンジニアってどんなことやってるの？」という方々にも、こちらを読めばデータエンジニアの業務の一片がわかるようになる！ 連載企画「ログ物語」の第二回をお届けいたします。
バックナンバー
- 【第1章】ログ物語の始まり
今回の構成
第2章.ログ/収集の仲間
- 1.ログ収集
- 2.業務データ
第2章.ログ/収集の仲間
1.ログ収集
話す内容としては、All Aboutメディアを含む、PrimeAd(以下、PA)のメディアパートナーサイトからTreasure Data(以下、TD)までどの経由でログが収集されるかが対象になります。
ログ収集の概要
前回の記事で既にお見せしたことがある図になりますが、ログ収集の概要を簡略に表すと下記の図の通りになります。
ログの転送と集約・フィルタは両方ともfluentdを使っていますが、転送(いわゆるFowarder)サーバーと集約・フィルタ(いわゆるAggregatorとProcessor)サーバーをそれぞれ用意し、各自の役割を担っています。
ログ転送(Fowarder)
All Aboutメディアを含む、PAのメディアパートナーサイトからのログは各サイトに仕込んでるイメージトラッキングやリダイレクターによってログ転送サーバーに転送されます。ログ転送サーバーに転送されたログは、fluentdエージェントによって、ログ集約・フィルタサーバーにアクセスログとして転送されます。基本的にサーバーのスケールアウトが必要な時以外は設定変更が発生しません。 ログ転送サーバーは、各サーバーから発生したログをログ集約・フィルタサーバーに右から左へ流すだけなので、サーバーインスタンスはAWSの汎用インスタンスを複数使っています。
ログ集約・フィルタ(AggregatorとProcessor)
ログ集約・フィルタサーバーではアクセスログをfluentdの機能を使ってフィルタリングやデータの簡単な正規化等を行ってからTDまで転送します。新しいログパターンが発生したり、新しいフィルタを適用したい場合には設定変更が必要になります。ログ転送サーバーとは異なり、一つ一つのログに対してfluentdの処理を行っているため、サーバーインスタンスはAWSのコンピューティング最適化インスタンスを複数使っています。
上記のように、ログ転送サーバーとログ集約・フィルタサーバーは役割も異なり、設定変更の発生頻度も異なります。また、役割によってサーバーへの負荷も異なります。従って、PrimeAdでは下記の観点でログ収集サーバーを各役割ごとに分けています。
- サーバーの役割の明確さ
- 設定変更の頻度による障害リスクの軽減 (設定変更が必要なサーバーのみ設定変更を行う)
- 負荷に対するメンテナンスのしやすさ (負荷が高まった役割のサーバーをスケールアウトする)
ログ転送とログ集約・フィルタの構成図
ここまで見てきたログ転送サーバーとログ集約・フィルタサーバーを図で表すと、下記のようになります。
上の図では、TD以外にもBigQueryが登場しています。BigQueryは下記の役割を担っています。
- データウェアハウスとして、広告配信の機械学習や目標クリック到達判定で利用するためのリアルタイム集計用の生ログを格納。
学習やリアルタイム集計等は別の機会があれば説明することにしますので、この場では「そのようなものがあるんだ～」程度で問題ありません。
fluentdとは？
Fluentd is an open source data collector for unified logging layer. 一言で言うと、各種ログをデータとして収集するオープンソースになります。 集計チームではログの転送及び集約・フィルタでもう既に何年も前から使っている状況です。 2018年12月時点での利用バージョンは下記になります。
ログ転送 : 0.12.12
ログ集約・フィルタ : 1.0.2
ログ集約・フィルタサーバーではマルチスレッドが使いたかったので、2018年から1.0.2を使っています。
簡単な説明
fluentdはRubyとCで実装されていて、Rubyのデーモンとして動きます。 従って、設定ファイルもRuby処理ができるようになっています。 そして、fluentdは数多くのプラグインが提供されていて、ログの収集でも下記のようなプラグインを使っています(プラグインの説明は省きますが…)。
fluent-config-regexp-type (1.0.0) fluent-logger (0.7.1) fluent-plugin-bigquery (1.2.0) fluent-plugin-extract_query_params (0.1.1) fluent-plugin-forest (0.3.3) fluent-plugin-record-modifier (1.1.0) fluent-plugin-record-reformer (0.9.1) fluent-plugin-rewrite (0.1.1) fluent-plugin-rewrite-tag-filter (2.1.0) fluent-plugin-td (1.0.0) fluent-plugin-td-monitoring (0.2.3) fluentd (1.0.2)
fluentdは設定ファイルにディレクティブを書くことで設定できるし、設定した内容通りに動作します(これは当たり前ですねw)。 基本的なディレクティブは下記になります。
| ディレクティブ名 | 概要 |
|---|---|
<source>~</source> |
入力プラグインの指定を行う |
<filter>~</filter> |
フィルタリングプラグインの指定を行う |
<match>~</match> |
出力プラグインの指定を行う |
実際にTDへログを転送する処理では数多くのディレクティブ処理が行われています。 下はそのソースの一部を抜粋したものになります。(一部マスキング済み)
#-------------------
# ログ転送サーバーからログの受け取り
#-------------------
<source>
@type forward
</source>
#-------------------
# 不要行及びブラックリスト削除(共通処理)
# 共通処理の場合、ユーザエージェントは「ua」として渡される
#-------------------
<filter raw.**>
@type grep
<regexp>
key uri
pattern /hogehoge.gifuga.php
</regexp>
<exclude>
key ua
pattern bot|Bot|BOT
</exclude>
</filter>
#-------------------
# uriから特定パラメータを取得する
#-------------------
<match raw.**>
@type extract_query_params
key uri
remove_tag_prefix raw.log
add_tag_prefix after.check.xxxtag
only xxx, v
</match>
#-------------------
# xxxパラメータがあるかないかによって分岐
#-------------------
<match after.check.xxxtag>
@type rewrite_tag_filter
# xxxパラメータがある場合 - 英数字のみOK
<rule>
key xxx
pattern ^[0-9a-zA-Z]+$
tag decoding.xxxtag
</rule>
</match>
Fluentd v0.12 Filter プラグインの使い方と作り方等を参照したので、興味ある方は一読してみてください。
2.業務データ
集計処理を行うためには意図したログなのかどうか等を判定するためのデータが存在し、集計側ではそのデータを「集計としてのマスタ」という意味で、「マスタデータ」と呼んでいます。が、その正体は「業務データ」になりますので、ここでは「業務データ」として説明させていただきます。
※正規化については前回の記事で軽く書いていますが、「第3章.ログ/二つの塔」にて詳しく説明させていただきます。
業務データとは
上記でも少し話しましたが、各種ログが意図したログかどうかを判定する材料になります。
例えば、All Aboutの一つの商品であるタイアップ記事の場合、掲載期間がありますが、既に掲載期間が過ぎた場合でも記事として残しています。
しかし、掲載期間が過ぎたタイアップ記事に対しては、掲載期間が終わった時点でもう集計は不要になります。
そのようなタイアップ記事データを集計しないように、ある業務データと結合して、掲載期間内のログだけを集計する等の処理を行います(「第3章.ログ/二つの塔」で詳しく説明しますが、この処理も正規化の1つになります)。
業務データの処理フロー
集計としての業務データは各種フロントデータに依存しているため、各種フロント側からデータを取得します。
フロント側のデータをそのまま使うパターンもありますが、集計用途に合わせて加工してから使うパターンがもっとも多いです。
取得して加工まで終わったデータは、TDへアップロードされ、そこから実際のログデータと結合されて利用されます。
文言だけだとわかり辛いので、簡単な図で出しますと、下記の感じになります。
この処理はバッチサーバーからTDのEmbulk機能を使ってMySQLから直接TDへのアップロードを行うようになっています。
Embulkは大量データの転送を楽にしてくれる技術で、業務データのアップロードでは下記サイトを参考にしました。
Bulk Import for MySQL
まとめ
PAのメディアパートナーサイトから生成されたログをどうやって収集し、TDまで蓄積しているかを紹介させていただきました。また、ログデータが意図したログデータであるかどうかを判定する等に使ってる、業務データの処理についても簡略に説明させていただきました。次回はこのように収集されたログデータをBIツールや人が使えるようにするための処理である、正規化と集計について書いていきたいと思います。
【ログ物語】第1章 ～ログ物語の始まり～
こんにちは！オールアバウトでデータエンジニアをしている@ondaljhです。
オールアバウトはコンテンツマーケティングプラットフォームPrimeAdというサービスを提供しています。 今回のブログでは本サービス運営上でのログにまつわるお話を4回の連載企画でお届けします。
前提
本題に入る前に、今回の連載記事はADNWの中でも、効果測定のためのログやデータの集計に関する内容がメインになります。まずはどのような目的で、どのような方を対象に書いていくのかを明記したいと思います。
連載記事の目的
データエンジニアってどんなことやってるの？と思ってる方々に、実務者が今までの経験に基づいて説明することで、データエンジニアの業務について少しでも理解していただくことを目的としています。 一言でデータエンジニアといっても、ビジネス毎に扱ってるアーキテクチャやデータは異なるため、細かいところは現場毎で異なりますが、データパイプラインを構築する上での基本的な概念はそれほど変わらないと思うので、ADNWのデータエンジニアとして書いていきます。また、集計データはADNWの機械学習にも使われていますが、今回の連載では割愛させていただきます。
閲覧してほしい対象読者
- データエンジニアって、何やってる人？と思ったことがある方
- データパイプラインについて興味ある方
- ADNWのログ・集計について興味ある方
持ってたほうがいい知識
上記知識がなくても読むには問題ないと思いますが、専門用語などが出てくるかと思いますので、専門用語の説明がない場合にはご了承ください。
全体構成
第1章.ログ物語の始まり
- 1.PrimeAdでのデータパイプラインの概要
- 2.ログのライフサイクル
- 3.ログの種類
第2章.ログ/収集の仲間
- 1.ログ収集
- 2.業務データ
第3章.ログ/二つの塔
- 1.正規化
- 2.集計
第4章.ログ/データの帰還
- 1.データ可視化
- 2.レポートツールへのデータ連携
- 3.データマート
これから「第1章.ログ物語の始まり」が始まります！
第1章.ログ物語の始まり
1.PrimeAdでのデータパイプラインの概要
PrimeAdとは
オールアバウトが提供しているコンテンツマーケティングプラットフォームで、約100のメディアと提携した広告配信からレポーティングまでをサービスしているプラットフォームです。 詳細はPrimeAdを参照ください！
データパイプライン
一般的にデータパイプラインとは、データ分析基盤、また機械学習基盤にとって、要望を満たすデータを収集、整形、準備、提供する一連のプロセスを指します。PrimeAdでのデータパイプラインも似たようなもので、PrimeAdでのADNWから発生するログの収集からデータの正規化、集計、可視化までがパイプラインによってつながっています。
2.ログのライフサイクル
PrimeAdでのライフサイクルを図式化すると下記のようになります。
一見するととても複雑に見えるかもしれません。 ですが、ところどころ切り取ってみれば難しい話ではないので、一つ一つ説明していきます。 ※各プロセスの詳細は第2回以降からになりますので、今回は概略だけ書かせていただきます。
ログの誕生
最初の方にも書いてありますが、ここで扱ってるログはあくまでも「ADNWでのログ」となります。 ご存じの方も多いかと思いますが、ログにはいろんな種類があり、種類ごとに生成されるタイミングが異なります。 基本的にはビーコンとして、ブラウザ上で発生するアクションデータがログとして生まれます。
例えば下記のようなものです。
PV(Page View) : ブラウザであるページが表示されたタイミング
Imp(Impression) : ブラウザであるページが表示される際に、ADNW等を経由して広告が表示されたタイミング
Click : ブラウザであるページからイメージリンクやテキストリンク等がクリックされたタイミング
ログの収集
PrimeAdではログ収集の際に、fluentdを使っています。各ウェブサーバーへアクセスが発生するたびに、アクセスログをポーリングしていたfluentdが検知し、ログ転送サーバーへ転送します。ログ転送サーバーはさらにログをログ集約・フィルタサーバーに転送し、ログ集約・フィルタサーバーはそのログをデータウェアハウス(以下、DWH)の一種であるTreasureData(以下、TD)へ転送します。 この辺の詳細は第2回で書いていきます。
ログの正規化と集計
正規化とは
データ等々を一定のルールに基づいて変形し、利用しやすくすること。 非常に多くの分野で使われている言葉で、分野によって意味も大きく異なります。 ※出典 Wikipedia
例えば、あるウェブページに対して、普段はURLにトレイリングスラッシュがついてるが、何らかの理由でURLにトレイリングスラッシュがなかった場合、トレイリングスラッシュを付ける等を指します。
正規化前のURL : https://allabout.co.jp/gm/gc/475094
正規化後のURL : https://allabout.co.jp/gm/gc/475094/
これにより、正規化前のログでは下記のURLは別々のものとして扱われていましたが、正規化後のログでは同じURLとして扱うことができるようになります。
https://allabout.co.jp/gm/gc/475094/
https://allabout.co.jp/gm/gc/475094
集計
正規化されたデータをベースに様々な切り口で数値の合計値をMySQLへ格納しています。 ここで言ってる切り口は、「ディメンション」を指してます。また、合計値は「指標」を指してます。 ディメンションと指標について、グーグルアナリティクスではこのような説明をしています。
- ディメンション : データの属性です。たとえば、ディメンション「市区町村」はセッションの性質を表し、「横浜」、「川崎」などセッションが発生した市区町村を指定します。ディメンション「ページ」は、閲覧されたページの URL を表します。
- 指標 : データを定量化したものです。指標「セッション」はセッションの合計数です。指標「ページ/セッション」は、セッションあたりの平均閲覧ページ数です。
PrimeAdではADNWの効果測定として様々なディメンションで各種データを集計しています。
正規化と集計の詳細は第3回で書いていきます。
集計データの活用
集計処理で個別のログではなくなったデータを活用する段階です。 ADNWの効果測定として集計されたデータは直接BIツールで参照されたり、PrimeAdのウェブレポートとして活用されるため、関連システムへ連携されたりします。 この辺の詳細は第4回で書いていきます。
ここまでがPrimeAdでのログのライフサイクルになります。
3.ログの種類
第1回の最後として、PrimeAdのADNWとしてのログの種類を簡単に紹介します。
| 種類 | 概要 |
|---|---|
| 広告リクエスト | ユーザーがサイトへアクセスし、ADNWが呼ばれたことの情報を持つログ |
| 広告インプレッション | 実際に表示された広告の情報を持つログ |
| 広告クリック | ユーザーがクリックした広告の情報を持つログ |
| 広告コンテンツPV | 実際に表示された広告コンテンツ記事の情報を持つログ |
| 読了率 | ユーザーが広告コンテンツページをどこまで読んだかの情報を持つログ |
| 滞在時間 | ユーザーが広告コンテンツページへ滞在した時間の情報を持つログ |
各ログの詳細情報をここに記載するのはできませんが、上記以外にも色々の種類のログを収集しています。 ※PV、CV等のADNW用語については割愛させていただきます。
まとめ
連載の第1回として、PrimeAdでのデータパイプライン、ADNW上でのログのライフサイクル、ログの種類などを簡略に紹介させていただきました。次回は集計で使われる業務データについて、また、ログ収集についてもう少し具体的に書いていきたいと思います。
今年も全社巻き込んだ年末LT大会を開催しました
この記事は、All About Group（株式会社オールアバウト） Advent Calendar 2019 25日目の記事です。
こんにちは、@k_shiotaです。
今年のAdvent Calendar 2019の最後は毎年恒例になりつつある年末LT大会の準備から実施までの流れを紹介したいと思います。
年末LT会とは
年末LT会とは、毎年年末に開催されている、その年にあった出来事や技術・趣味に関することなどをライトにトークする会です。
昨年から、全社的に行う方針となっています。
前回の開催についてはこちら↓ allabout-tech.hatenablog.com
目的
開催の目的は下記のように設定しました。
- 技術縛りをせず、みんなでとにかく発表して話すこと
- エンジニア同士や部署を横断した交流
参加人数を記録して数字としても把握します。
企画から開催までのスケジュール
前回同様、社内広報・人事も巻き込んで全社的にやる方針に変わりは有りません。
合計9名の「年末LT会運営チーム」を立ち上げ11月中旬頃から準備をはじめました。
目的を確認し前回の経験を活かしつつ事前にスプレッドシート等で相談したいことを共有してから打ち合わせをするようにしました。
はじめて運営側となった自分にとって前回を知っている方たちは心強かったです。
打ち合わせでは下記のような内容を相談しました。
前回で出た問題点も踏まえて進めました。
- 予算
- 開催日時・場所
- 当日のタイムスケジュール
- 当日の役割
- 参加者の告知方法
前回の経験を生かして
前回はピザが少なかったという意見もあったため、ピザの量を増やし非公式カレー部の料理も提供してもらえました。
そして、コミュニケーションを取りやすくするために立って聴くスペースを多く用意しました。
社内での告知
開催日時などが決定してからは、下記の方法で社内に広報しました。
- 全社メール
- Slack
- ビラ作成
事前に参加者の登録とライトニングトーク発表者の募集用にGoogleフォームを作成し、そのURLをQRコードが読み取れるようなビラを作成して社内のいたるところに貼りました！
発表者はやはり集まりにくいのですが、参加申込みのフォームに誰から話を聞きたいかなどのアンケートを取るようにしました。
- 「この人の話が聞きたい！」があれば、その人の名前を書いて下さい
- 推薦する場合は、その人に話して欲しい内容・テーマなどを自由に書いて下さい
こうしたことで発表の依頼がしやすくなり、無事に増やすことも出来ました。
年末LT会、当日の様子
当日は下記のタイムテーブルで開催され、LTの発表時間は一人あたり5分（時間を過ぎたらタイムキーパーのベルがなります）としました。 食事の用意やカレーの準備も裏で進めています。
当日のLTのテーマは下記の通りでした。発表者は合計12名でした！みなさまありがとうございました！
終始笑いやツッコミが起こる展開で和気藹々とした会場でした。
この発表を聞いてみたいということでしたら、ぜひ遊びに来てください。
振り返ってみて
前回の反省点で上がっていた点が改善されて、前回よりも運営の準備に不足はなかったと思います。
開催時間については週末の夕方となりましたが、時間帯によっても参加者の数に変化がありそうです。（例えばランチの時間とか）
事前に発表内容を共有していたためこの話を聞きたいと思った方はその時だけふらっと聴きにいらっしゃることもありました。
参加者の把握はポストイットに名前を書いてもらってフィードバックの数で把握していましたが、一気にどっと参加者が増えたときに名前がかけなかったりするのでもう少し違った形が良かったかもしれません。
振り返りは時間を取ってやりたいと思っています。
まとめ
前回もそうでしたが、普段あまり関わることのなかった人たちの話を聴くことができました。 部署間やグループ間のつながり、さらには社外とのつながりを増やすべく、来年もいろいろな取り組みをやっていきたいと考えています。
メリークリスマス🎄🎅🛷
【イベント出展レポート】「PHP Conference Japan 2019 」スポンサーとして企業ブースに出展しました！
この記事は、All About Group（株式会社オールアバウト） Advent Calendar 2019 5日目の記事です。
2019年12月1日に開催された「PHP Conference Japan 2019 」に協賛し、企業ブースの出展をしました。 オールアバウトは2015年から毎年スポンサーとして参加し、本イベントならびにPHPの発展を応援しています。 今回は当日のブースの様子や、事前の運営準備の様子をレポートします。
PHPカンファレンスの紹介
PHPカンファレンスは今年で20回目を迎え（おめでとうございます！！）、1500人を超えるPHPerが全国から集う大規模カンファレンスです。 会場ではPHPや関連技術についてのセッションが行われたり、各協賛企業の企業ブース、書籍の販売などが行われ、例年同様の大盛況でした。
オールアバウト企業ブースの紹介
オールアバウトの企業ブースでは「オールアバウトグループに関するクイズ」や「PHPカンファレンス参加者の参加目的アンケート」を行い、来場された方々と様々な交流をすることができました。 クイズの正解者の方にはオリジナルノベルティをプレゼントしたのですが、非常に好評で途中で用意していたノベルティが足りなくなるほどの盛況ぶりでした！ ご来場された方々、改めてありがとうございました！！
いつから動き始めたか
本イベントの約２ヶ月前からオールアバウトグループのエンジニア横断チームであるチームテックボール（以下、TTB）を中心に以下のようなことを行いました。
- 昨年の振り返り
- イベント参加の目的
- ブース内で実施する企画
- ノベルティの選定
昨年の振り返りから改めて企業としてイベントに参加する意味や意義を考える事ができました。 チーム内でイベント参加の目的を共有できたのは今思えば非常によかったと感じています。
何をしたかったか
イベント参加の目的についてチーム内で議論した結果、今回の目的は以下のように決定しました。
- モチベーションが高いエンジニアに対して自社のアピール、オールアバウトの技術/環境/サービスに対して「オールアバウトってイイね！」と思ってもらう（オールアバウトのことをカンファレンス来場者に知ってもらう）
- PHPのコミュニティへの還元・発展
上記の目的が決定し、次に具体的な施策としてブースで何を行うか、どうすれば来場者にオールアバウトを知ってもらえるかを話し合いました。 結論までのプロセスは以下のようなイメージでした。
プロセス①：来場者をブースに引き込む施策
ブースに来てもらえないと会社のことは知ってもらえない
→ブースに来てもらうために何かをプレゼントするのは有効
→昨年のチロルチョコも好評だったが、それだけでは弱い気がする
→他のプレゼントについても考えよう
プロセス②：来場者にオールアバウトを知ってもらう施策
ブースに来てもらえてもビラやPCの画面見せても来場者の記憶に残らない
→来場者参加型の企画をしよう
→オールアバウトのことを知ってもらえるようなクイズに参加してもらおう（聞くだけでなく、参加者に思考してもらうことで記憶に残してもらいたい)
→クイズへのモチベーションを上げるために正解者へのプレゼントは別に用意しよう（プロセス①と重なる）
プロセス③：PHPカンファレンスへの還元
企業として参加してるし、普段PHPにはとてもお世話になってるから還元したい
→運営さんに来場者のことを知ってもらおう
→参加者の参加目的とエンジニア歴をまとめたアンケートを取って公表しよう
当日やってみてどうだったか
会場の様子
最初は無機質なボードでしたが、徐々に来場者の方々が集まってくるにつれ、ブースもボードもどんどん盛り上がっていきました！！
クイズボード
当初用意していたクイズ正解者へのノベルティ（スマホスタンド：120個）もおかげ様で品切れとなり、合計で140名以上（来場者全体の10%くらい）の方にクイズにチャレンジしていただけました！
少なくとも140名の方にオールアバウトについて知ってもらえたのはとてもありがたいです！！
アンケートボードの結果
以下、アンケート結果まとめ
| 目的・エンジニア歴 | ~3年 | 4~5年 | 6~10年 | 10年~20年 | 20年~ | total |
|---|---|---|---|---|---|---|
| PHPの最新動向 | 21 | 8 | 7 | 4 | 5 | 45 |
| 設計周りの知見 | 11 | 6 | 5 | 3 | 0 | 25 |
| セキュリティ周りの知見 | 7 | 1 | 1 | 3 | 1 | 13 |
| DB周りの知見 | 1 | 0 | 1 | 0 | 0 | 2 |
| テスト周りの知見 | 3 | 1 | 0 | 0 | 0 | 4 |
| 他企業の情報/ノウハウ | 11 | 6 | 6 | 2 | 0 | 25 |
| 技術本 | 0 | 0 | 0 | 0 | 0 | 0 |
| その他 | 18 | 5 | 3 | 1 | 2 | 29 |
| total | 72 | 27 | 23 | 13 | 8 | 143 |
結果を見ると、3年目以下の若手エンジニアの来場が非常に多かった事が分かりました。 また、1/3の方はPHPカンファレンスに最新技術の動向が気になって来場されているようです。 このアンケートが来年のPHPカンファレンスに何かしらお役に立てれば非常に嬉しく思います。
イベントを終えて
イベントを振り返り、改めてイベントを企画してくださってる運営の方々、来場されていたPHPerの方々ありがとうございました！ エンジニアのみなさんの熱量を感じる事ができ、スポンサー企業として参加させていただけた事、大変ありがたかったです。
オールアバウトでは現在、エンジニア採用を新卒中途ともに行なっております。 弊社に興味を持って一緒に働きたいと思った方は是非こちらからお問い合わせください。
また、最後になりますが隣の企業ブースで色々とお世話になったFABRIC TOKYOさんにもお礼申し上げます！！
オールアバウトグループは今後ともPHPの発展のため、貢献してまいります。
第3回 開発合宿@五番地に行ってきました
この記事は、All About Group（株式会社オールアバウト） Advent Calendar 2019 1日目の記事です。
こんにちは、最近購入したAirPods Proのノイズキャンセリング機能に感激した @amymd です。 10/26(土)-10/27(日)に、社内のエンジニアたちで開発合宿に行ってきたので、その報告をしたいと思います！ 私は今回開発合宿の運営 兼 参加者として活動を進めていました。
前回の開発合宿については過去のテックブログの記事でも紹介してるので、ぜひご覧ください。 allabout-tech.hatenablog.com allabout-tech.hatenablog.com
今回の合宿先はなんと「山梨県」！（これまでは「静岡県」「千葉県」でした） 大自然に囲まれた合宿地で、一泊二日集中して開発を行うことができました。 また、今回も費用については全額会社が負担する形となり、大変助かりました。
続きを読む