2020-08-27

Google Cloud Functionsを使ってバックアップデータからログの再収集を行う方法の紹介

こんにちは！オールアバウトでデータエンジニアをしている@ondaljhです。

皆さんはGoogle Cloud Functions(以降、Cloud Functions)を利用したことがありますか？自分も業務上では使ったことがなかったんですが、今回ある案件でCloud functionsを利用する機会があったので、私たちのチームでのCloud Functionsの利用シーンを紹介させていただきたいと思います。この記事を最後まで読んでいただいて、「こんな利用シーンもあるんだ～」程度で理解していただければ幸いです。

従いまして、本記事は下記のような方を想定して書かせていただきます。

Google Cloud Functionsに興味はあるが深くかかわったことがない方
Google Cloud Functionsの利用パターンを調べてる方

また、Cloud Functions以外に出てくるGoogle Cloud群についての詳細な説明は記事の最後の方に公式サイトへのリンクを貼りますので、興味ある方はぜひ見てみてください！

概要

冒頭で書いた「ある案件」とは、チームプロジェクトで「ログ収集基盤のサーバーレス化」というものがありまして、そのうちの1つである「バックアップデータからログの再収集」を意味します。

まず、ログ収集基盤のサーバーレス化の基本的なアーキテクチャをお見せします。

f:id:allabout-techblog:20200826165138p:plain — ログ収集基盤のログ転送フロー(通常)

図の通りにウェブから発生したログはGoogle Cloud Run(以降、Cloud Run)で受け入れて最終的にはTreasure DataとGoogle BigQuery(以降、BigQuery)まで流れていきます。
また、Cloud RunからGoogle Cloud Dataflow(以降、Dataflow)までのデータ転送にはネットワーク上の通信の高速化のためにProtocol Buffersを使ってデータ通信を行います。(Protocol Buffersは通信の高速化以外にもいくつかのメリットがありますが、本題とずれるので詳細については記事の最後の方に貼ってある公式サイトへのリンクをご確認ください。)
なお、Cloud Runが受け入れたログはバックアップとしてBigQueryのあるテーブルへ格納します。その際のフォーマットは、Cloud RunからGoogle Cloud Pub/sub(以降、Pubsub)へ転送する、Protocol Buffersにてシリアライズされたフォーマットのままにしてます。
このBigQueryへ格納するバックアップデータが「ログの再収集」の肝になりまして、PubsubやDataflowに障害が発生した場合、このバックアップデータからリカバリーが可能になります。

ここからが本題で、Cloud Functionsの導入に伴う下記の2点について紹介させていただきたいと思います。
- リカバリー処理(BigQueryからデータを取得して～)
- Cloud Functionsのソース管理及びデプロイ

通常時と比べてリカバリー時のイメージは下記の図のようになります。

f:id:allabout-techblog:20200826165207p:plain — ログ収集基盤のログ転送フロー(リカバリー)

それでは、リカバリー処理から見てまいりましょう！

リカバリー処理

リカバリー処理自体はシンプルで、BigQueryへ格納されているバックアップデータを取得して、通常処理のPubsubへ投げる、だけになります。

BigQueryへバックアップされたデータは通常処理でPubsubが扱うデータと同じフォーマットとなっている
PubsubとDataflowはオートスケールできるため、通常処理にリカバリー処理をかぶせても負荷的な影響はない

実際の処理負荷に対しては気になるところだと思いますが、その詳細につきましてはここでは割愛させていただき、別の機会でご紹介できればと思います。

Cloud Functions設定情報

今回のCloud Functionsの設定情報は下記のようになります。

トリガー : HTTP
ランタイム : Go 1.13

また、内部的にはGCP関連いくつかの環境変数とあわせて、リカバリー用の環境変数も設定してソースの中で参照することにしています。

必要なIAMロール

リカバリーではサービスアカウントを使いますが、そのサービスアカウントに必要なIAMロールは下記になります。各ロールに詳しい方も多いと思いますが、補足として簡単な説明も記載させていただきます。

bigquery.jobs.create : プロジェクト内でジョブ（クエリを含む）を実行する権限。
pubsub.topics.publish : 1つ以上のメッセージをトピックへ追加する権限。
cloudfunctions.functions.setIamPolicy : 未承認のデベロッパーによる該当Functionsへの権限変更を防ぐために、該当Functionsをデプロイするユーザーまたはサービスに与える権限。

ファイル構成

functions.go : メイン処理
go.mod : go言語の依存モジュール管理ファイル

処理の流れ

基本的な処理の流れは下記のようになります。

1.トリガーでCloud Functionsの実行対象関数が呼び出される
2.BigQueryからデータを取得し、Iteratorを回してPubsubへメッセージを送る関数へデータを渡す
3.Pubsubへメッセージを送る

ソース

バックアップデータからログの再収集を行うソースを全部載せると記事が長くなりますので、流れが把握できる範囲で紹介させていただきます(エラー処理もすべて省きます)。

functions.go

package p

import (
    ~省略~
    "cloud.google.com/go/bigquery"
    "cloud.google.com/go/pubsub"
    "google.golang.org/api/iterator"
)

// ①Cloud Functionsでエンドポイントとして使われる関数
func EndPoint(w http.ResponseWriter, r *http.Request) {
    // BigQueryからデータを取得し、1行ずつPubsubへメッセージを送る
    fetchBigQueryData()
}

// ②BigQueryからデータを取得し、Iteratorを回してPubsubへメッセージを送る関数へデータを渡す
func fetchBigQueryData() {
    ctx := context.Background()

    client, err := bigquery.NewClient(ctx, {GCP_ID})
    defer client.Close()

    // バックアップデータ取得用クエリ設定
    q := client.Query({SQL})

    // 実行のためのqueryをサービスに送信してIteratorを通じて結果を返す
    // itはIterator
    it, err := q.Read(ctx)

    for {
        var tc {BQTableColumns 構造体}

        // 引数に与えたtcにnextを格納する
        // Iteratorを返す
        // これ以上結果が存在しない場合には、iterator.Doneを返す
        // iterator.Doneが返ってきたら、forを抜ける
        err := it.Next(&tc)
        if err == iterator.Done {
            break
        }

        // pubsubへメッセージを送る
        sendPubsubMessage(&tc)
    }
}

// ③pubsubへメッセージを送る
func sendPubsubMessage(tc *{BQTableColumns 構造体}) {
    msg := &pubsub.Message{
        Data: tc.Message,
    }

    ctx := context.Background()
    if _, err := {Pubsubのtopicインスタンス}.Publish(ctx, msg).Get(ctx); err != nil {
        return
    }
}

go.mod

module DOMAIN/MODULE_NAME

go 1.13

require (
    cloud.google.com/go/bigquery v1.10.0
    cloud.google.com/go/pubsub v1.6.1
    google.golang.org/api v0.30.0
)

Cloud Functionsのソース管理及びデプロイ

Cloud Functionsはサーバーリソースを各自が管理しなくても良いメリットがあります。
その代わりにというのも不適切かもしれませんが、CloudFunctions上で動かせるソースの管理をどうするか、また、デプロイはどうするかを検討しないといけません。
自分にとっては初のCloudFunctionsだったので、一旦検証時に利用したソース管理とデプロイ手順を紹介させていただきます。

Cloud Functionsへのソース反映方法

Cloud Functionsへのソース反映はCloud FunctionsのウェブUIからも確認できるように、下記の4種類があります。

Inline Editor
ZIP Upload
ZIP from Cloud Storage
Cloud Source repository

Inline Editorの場合はウェブUIから直接ファイルを更新するパターンなので、ソース管理ができない問題があります。
ZIPを利用する方法も、ソース管理ツールからファイルをダウンロードして、ZIP圧縮して、等の遠回りをすればある程度のソース管理はできますが、手間が増えるし、ミスも増える可能性があります。
Cloud Source repositoryはGCP上でのソース管理サービスです。このサービスにはなんと！他のソース管理ツールへのミラーリング機能があったので、今回はCloud Source repositoryを使ってみることにしました。
※現時点でミラーリングできるのは「GitHub」と「Bitbucket」の2種類のみですので他のソース管理ツールをご利用中の場合にはご注意ください。

ミラーリング設定

弊社ではBitbucketを使ってソース管理を行っているので、下記公式サイトの説明に従ってリポジトリのミラーリング設定を行いました。
Bitbucket リポジトリのミラーリング

デプロイ

まずは、Bitbucketの該当リポジトリへ今回のソースをcommitしました。
そのあと、Cloud Source repositoryの該当リポジトリでミラーリングが正常にできたことを確認したので、gcloudコマンドを使ってCloudFunctionsへデプロイを試してみました。

gcloudコマンドを使ってのデプロイは下記公式ドキュメントに詳細が載っているので参考しながらコマンドを書きました。

ソースコントロールからのデプロイ

gcloud functions deploy CLOUD_FUNCTION_NAME \
  --region REGION_ID \
  --source https://source.developers.google.com/projects/PROJECT_ID/repos/REPOSITORY_ID/moveable-aliases/master/paths/SOURCE \
  --runtime go113 \
  --service-account=SERVICE_ACCOUNT@appspot.gserviceaccount.com \
  --trigger-http \
  --set-env-vars HOGEHOHE=AAA,FUGAFUGA=BBB… \
  --entry_point ENTRY_POINT \

基本的には公式ドキュメントに従って書けば問題なくデプロイできることを確認しました。
また、「--runtime」オプションは該当Functionを最初に作るときに指定すれば良くて、そのあとからは該当オプションをしないことで同じFunctionへの更新になります。

おわりに

Cloud Runと比べてCloud Functionsはコンテナイメージのメンテナンスが不要というメリットがあります。
通常のログ収集処理はCloud Runで行うことにしましたが、めったに発生しないであろうログの再収集処理はCloud Functionsで行うことで、メンテナンスコストが節約できると思います。
また、今回は「HTTPトリガー」を試してみましたが、Cloud Functionsには「HTTPトリガー」以外にも「Cloud Pub/Subトリガー」や「Cloud Storageトリガー」もあるので、今後それらも試してみたいと思います。
デプロイについても、今回はgcloudコマンドでの手動デプロイを試してみましたが、近いうちにCircleCIからの完全自動デプロイも試してみたいと思ってます。

今後ともよろしくお願いいたします。

参考サイト

公式サイト

ブログ等

GoでBigQueryクライアントを実装してBigQueryからデータを取得する

2020-06-30

Cloud RunからCloud SQLやMemorystoreへの繋ぎ方

こんにちは！@y_hideshi です。

今回はCloud RunからCloud SQLやMemorystoreにつなぐ方法について紹介します。

Cloud SQLへの接続方法
Memorystoreへの接続方法

Cloud SQLへの接続方法

検証のため、phpMyAdminからCloud SQLにつなぐシンプルな構成のシステムを作ります。

f:id:allabout-techblog:20200629200338p:plain — Cloud Run - Cloud SQL

2020-05-29

データ活用を推進しようとしているお話

はじめに

初めまして、オールアバウトの @akidukin(@Akidukin14) です。この度上手く出来たら noteで公開しようと思っていた内容を「自社のtechblogで書いてよー」と~~低めに脅された~~依頼されたので、気持ちよく執筆させていただくことにしました。

初めてTechBlogを執筆させていただきますので、簡単に私がどんな業務を担当しているのかを説明させて下さい。

興味が無い人は ## 何をしようとしているのかの説明 に飛んでください。(データサイエンティストとして仕事している人なんだなーって認識を持っていただけたら十分です。)

人 : @akidukin14 https://twitter.com/Akidukin14
出身 : 福岡
現所属 : 株式会社オールアバウト開発部マーケティング開発データサイエンティスト

主な業務 :
【ちょっと前まで】

広告配信に利用している機械学習の改善
営業向け資料の拡充
広告配信のレポーティングの拡充 ... 等

【現在】

株式会社オールアバウト全体にデータ活用やっていきましょうよーと話しまわっている(非公認)
出てきた活用案をプロジェクト化して
- PMしたり
- 分析で実際に手を動かしたり
- ダッシュボード作ってみたり
- 機械学習のPoC回してみたり
- 一般で利用できるようにツール化したり ... 等

今回は【現在】主に対応している物についてご紹介しようと思います。

何をしようとしているのかの説明

タイトルの通り「株式会社オールアバウトの各部署のデータ活用を推進しよう」としています。

きっとこの記事を読んで頂いている方は
「会社としてデータ活用を推進していく共通意思があって進めているんだ...!!」
と思われるかもしれませんが、凄く雑に言うと個人的に ~~暇だから~~ やってみたいので進めています。

オールアバウトグループという単位でどんなサービスを運営しているかを簡単に説明します。

株式会社オールアバウト : メディア運営 / タイアップ広告配信の運営
株式会社オールアバウトライフマーケティング : ECサイト運営
株式会社オールアバウトナビ : SNSを利用したエンタメ事業の運営
日テレライフマーケティング株式会社 : ECとTV放送を連動させた事業の運営
株式会社オールアバウトライフワークス : 講師育成や教室運営サービスの運営

様々なサービスの運営をしており、データアナリストやデータサイエンティストといったデータを触る方々からすると垂涎物な環境なのかなーって思います。
(違う業種違う情報のデータが比較的豊富に取得できる点が)

今回、データ活用を推進しようとしているのはメディア運営 / タイアップ広告配信運営の事業領域になります。

※...データ活用 : データソースの整理や掃除、から、実際にデータ分析 ~ 機能の提供を対象のイメージとしております。

現在のデータ活用フェーズについて

そもそも、現在株式会社オールアバウトではデータの活用が全く進んでいないのかというと、そういうわけではありません。
メディア運営に於いてはGoogle Analyticsが社内にかなり浸透し各自でDataportal等を使っていたり、タイアップ広告配信ではTreasureDataにデータがたまっており、タイアップごとの効果測定等にもデータを利用してたりします。
ECサイトを運営しているオールアバウトライフマーケティングではRe:dashを利用して定常的に数値を追う環境もあったりします。

しかし、データの活用度合いが個人の知見に任せされていたり、情報の共有があまりされていなかったり、形骸的にデータを見るだけになっていたりしていました。
いくつかの業務の中では定量的ではなく定性的な判断をすることが常になっている業務、人の知見を元に判断をしている業務等がある。。。
というのが現在の株式会社オールアバウトのデータ活用のフェーズになります。
イメージは伝わりますかね...??

現在のフェーズにおいて、実際に作業にあたっている方やその上司の方々は大なり小なり課題感は抱えており、今までその部分に介入する+出来る人的リソースが無かったというのが背景になります。

「あれ??これデータ活用進めたら、強力に売り上げ貢献とか利益貢献出来るんじゃね??」

f:id:allabout-techblog:20200528104258p:plain — イメージ

どう進めているのか

実際にどのようにデータ活用を推進しているのかという点について、説明させてください。
プロジェクトが動き始めたのが4月からでした。

基本的には

各グループの上長や担当者にデータを利用してやってみたい事をヒアリング
データ環境の情報整理
優先順位付け、プロジェクト化
分析案や仮説のブレスト
タスク化
分析作業及び報告

という流れで進めています。

元々各GMや担当者はデータに対しての理解度が高かったのですが、データを使って何が出来るか分からないという壁がありました。

そこで、テーマを「ドラえもん」に設定し、「あんなこっと良いな、出来たら良いな、不思議なデータで叶えてあっげっるー」という理想ドリブンでそれぞれやってみたい事をヒアリングしていきました。
この時、ooを解決したい!!みたいな形ではなく、ooがxxみたいになればいいのになー。という形でふんわりした内容を上げてもらって、それを詳細に詰めていくという導入から始めました。

やりたい事いっぱい出た。
中には「知見に基づいてやっている作業の自動化が出来たら凄く嬉しい。」等も出てきて狙い通りでした。

そして、出てきたものに対して、優先順位をつけ PO(プロジェクトオーナー) を付け、プロジェクト化を行いました。

その後、どういった分析をすれば実現できるのか、や、どういったデータを見れば示唆が出そうなのかのブレストを行い、タスクへ落とし込み、分析の作業に移ります。

データ活用するにあたって、壁になる事の一つに担当者と作業者間の期待値コントロールがあると思います。
正直最初は「理想ドリブンでプロジェクト立ち上げちゃったけど、期待値コントロールどうしよう...」と悩んでいました。
期待値が凄く実現性と離れた時は、ミーティング外での啓蒙活動やミーティング自体の開催頻度を上げて細かくOUTPUTを出しつつ期待値や結果を下げていく方向へ持っていこうと考えてたりしました。
が、そんな心配が具現することなく、思ってたより大丈夫だった(今後出て来るかもしれませんが...)

こうしたい未来のお話

まだ走り出したばかりで100年後も変わらず、こう思っているかと言われると自信は無いですが、、、

将来的にはグループ会社全体でデータ活用なら @akidukin (または付随するその組織)に相談してみよう、となるのが理想です。
後はニーズをくみ取りながら、効果的な機能の提供を自発的に出来るようになるともっと嬉しい。企画 ~ 提供を一手に担える

受けた相談を元に実際にデータを見てみたり、分析してみたり、結果を元に改善案や何かしらの機能提供まで出来るようになったら良いです。みんな幸せHappy

上記のような理想に対してはまだまだ溝があり(始めたばかりなので当たり前ですが)、その溝を埋めるためにこんなロードマップを考えています。

こちらからデータ活用についてのニーズのヒアリングを行い、プロジェクト化 <- イマココ
プロジェクトに対して対応、及び改善案の提案や実施
良いor悪い影響の社内共有
メディア運営 / タイアップ広告配信運営以外の事業領域へデータ活用についてのニーズのヒアリング、プロジェクト化
プロジェクトに対して対応、及び改善案の提案や実施
良いor悪い影響の社内共有
... ぐーるぐる回す
ニーズの策定 + 企画立案 + 企画試行

まずはご用聞き -> 誠実に対応 -> 正しく結果を共有のサイクルを繰り返してデータを使う事の効果を知ってもらう (と同時にそれぞれの事業部で何をしているのかをより深く知る) その後、生まれそうなニーズや生まれたニーズを元に改善できそうな部分を考えていく。という大まかな流れになるかなーと妄想しています。

きっとその間で、

一緒に分析を進めてくれる人達のレベルアップとか
一緒に実装を進めてくれる人達のレベルアップとか
どうやって膨大になっていくプロジェクトを適宜割り振っていくかとか
そうなるともっと人が必要になるよなーとか
分析するマシンリソースがひっ迫してくるだろうから対応考えないと行けないよなーとか
複雑になっていくデータリレーションをどう管理していけばいいのかなーとか
etc...

多分今考えている 5倍ぐらいは出て来るとは思いますが、来る未来を想像しながらとりあえず目先の事を頑張る。

終わりに

改めて書き出してみるとあまり固まっていない事が判明して困惑しています。

今後進めていけるのであれば、より影響範囲は広めていきたいなー、色々なデータを触ってみたいなーとか思っています。が、
グループ会社を横断するって事を考えると、良く分からない大人の事情も出て来るだろうし、、、、
じゃあ提案をして改善していきましょう、ってなったときのステークホルダーとの折衝とか、、、、

まあ未来を悲観してもしょうがないので、今は目先の事をちゃんとこなしていく事にしています。

その辺り、もし同様の経験をされた方がいらっしゃったらお話お聞きしてみたい...

拙い文章でしたが、ここまで読んでいただいてありがとうございました。
随時、経過とか得られた知見とかアウトプットしていきたいなーと思っているので、よろしくお願いします！

2020-04-27

Cloud RunとGCPの他サービスを使って簡単なシステムを作ってみました

こんにちは！オールアバウトの @y_hideshiです。

今回は、昨年GA(General Availability)された Cloud RunとGCPの各種サービスを連携させて簡単なシステムを構築、その際に得られた知見を記事にしたいと思います。

作成したシステム
Cloud Run について
- Cloud Runへのデプロイ
  - Webからのデプロイ
  - gloudコマンドによるデプロイ
- 設定値について
- Cloud Run：まとめ
関連サービスを利用することによるメリット
- Cloud Build
  - GCR、Cloud Runへのデプロイをするための認証をなるべく手軽に済ませたい
  - プロジェクトが変わってもすぐにデプロイしやすいようにしたい
- Cloud Pub/Sub
- Cloud Scheduler
所感

作成したシステム

今回作成したシステムは「GCP確約利用割引の期日を定期的にチェックして、期日の近いものをslackに通知する」というものです。

GCP確約利用割引は1年間または3年間の支払いを確約する代わりに、特定の量のvCPU、メモリ、GPU、ローカルSSDを割引価格で利用できる仕組みです

f:id:allabout-techblog:20200420213645p:plain — 作成したシステム構成

使用したサービス

※ 今回は連携するサービスの詳細については触れませんが、各サービスごとの採用理由やメリットなどを解説して行きたいと思います。

2020-04-24

1ヶ月以上在宅勤務を続けた弊社エンジニアのアンケート結果を発表します！

オールアバウトエンジニアの在宅勤務アンケート結果発表

こんにちは！オールアバウトでデータエンジニアをしている@ondaljhです。

新型コロナウィルスの影響で在宅勤務を実施している企業も多いと思います。オールアバウトグループも3月初めから在宅勤務を実施したので、実施から1か月以上になりました。
今回はオールアバウトのエンジニア達に在宅勤務による業務環境変化等をアンケートしたのでその結果を発表させていただきます！

業務関連

1.在宅勤務になってから打ち合わせの数はどう変わりましたか？

f:id:allabout-techblog:20200422162741p:plain

2.自身が開催する打ち合わせの場合、使用するツールはslackとzoom、どちらをより多く使用しますか？

f:id:allabout-techblog:20200423151351p:plain

その他を選んでいただいた方の中では下記のような意見もありましたー

社外の打ち合わせはZoom、それ以外はHangout使っています

2-1.質問2で選んでいただいた項目について、その理由を教えてください

※回答からいくつか抜粋

Slack派
- slackの方が常に見ているのでそっちの方が開きやすいため
- 少人数の打ち合わせが多いため、わざわざZoomで部屋を作る必要性を感じないため。また、Zoomはセキュリティが心配＆Slackのほうが画面共有時の書き込みが自由にできるので。
- Zoomだと40分の制限があるため
Zoom派
- 背景を変更できるから
- slackよりもzoomの方が軽い気がするから
どっちでも良い派
- 30分以内、3名ぐらいまではSlack。3名以上30分以上ならZoomでやっています
- MTGによって定着している、選び直すなら安定性を感じるZoom
- どっちでもよいので気分次第。
その他
- Slackは参加者固定の打ち合わせなら会議作るのが楽だけど、定例等のスケジュールを自動化できないのがつらいため。カレンダーベースでスケジュールできるHangoutが比較的楽だと思いました。

3.割り込み作業の数はどう変わりましたか？

例えば、急な問い合わせや調査依頼、予定されていなかった打ち合わせなど、当日のスケジュールに含まれていなかった作業の増減について教えてください

f:id:allabout-techblog:20200422163008p:plain

3-1. 質問3の傾向についてご意見又は感想を聞かせてください

※回答からいくつか抜粋

減った
- うれしい。
- 口頭で質問しにくる人が減ったから。また、ある程度情報をまとめてきてから相談してくれるので、以前よりも進めやすい
- 通話をつなぎながらの作業が増えたので、割り込みで中断するというケースが少なくなりました。個人的には集中できて良いと思っています。
変わらない
- 業務のボリュームは変わらず。問い合わせが多いです。
- 自分の業務的には問い合わせ等はオフライン・オンライン関係ないのが多いから
増えた
- たぶん、増えたのは、在宅だからではなくコロナ対応のせいです（コーポレートサイト担当なので、コロナ関連のお知らせで、突発サポート業務が増えています）。

4.気軽な相談の数はどう変わりましたか？

f:id:allabout-techblog:20200422163044p:plain

4-1. 質問4の傾向についてご意見又は感想を聞かせてください

※回答からいくつか抜粋

減った
- 気軽に聞けないのでまずは自分で調べるようになった
- 口頭で質問しにくる人が減ったから。また、ある程度情報をまとめてきてから相談してくれるので、以前よりも進めやすい
- ただの雑談や通りすがりの雑談が出来ないのは長期的にはマイナスになる。
- 相談なしで進んでしまうと手戻りが増えやすいので、極力減らさないようにしたいと思っています。が、相手の方がオフラインだと「今日はお休みなのかな？」と思ってしまい、なかなか気軽には声をかけにくいです。
変わらない
- 相談する側であることが多いのですが、Slackのテキストベースで基本的にはやりとりするので、言語化のクオリティがお互いに上がりディスコミュニケーションが減ったような気がしています。
- slackで気軽に連絡が取れる
- 以前と変わらない感じで気軽に相談をするようにしているので、その辺りのハードルは高くない
増えた
- DMでのこれどうしたらいい？が増えました

5.業務への集中度の変化はありましたか？

f:id:allabout-techblog:20200422163108p:plain

5-1. 質問5の傾向についてご意見又は感想を聞かせてください

※回答からいくつか抜粋

集中しやすくなった側
- モブプロ中は余計なものが入り込まなくなって集中しやすくなった
- マイペースで働けるようになったからある意味集中度もあがったと思う
変わらない
- 最初は個人作業は集中しやすかったのですが、その分カレンダーやSlackの通知に敏感になり、結果総合的に見ると在宅じゃないときとあまり変わらないと感じました
- 特に在宅だからといって変わりはない
- 特に変わらない。気軽に気分転換にお散歩に行けるようになったぐらい
- 業務後もすぐ業務に戻れるため、公私の区別が付かなくなりがち。結果、緊張感が間延びしつつある。ただ、まとまった時間が取れるのは非常に助かる。
集中し辛くなった側
- 環境が整っていなかったので、仕事をする際の姿勢による負荷などであまり集中できていなかった
- 自宅前の緑地で毎日子供が遊んでいる＆隣のおうちに赤ちゃんがいるので、とにかく毎日騒音が……その間は、正直集中しづらいです。が、静かな時は、会社にいる時よりも集中しやすくなったと思います。
- 会社での作業は集中したいときにイアホンで音楽聞いてのですがいまは、寂しくて集中できないです。

6.ペアプロ・モブプロを行っていた方も多いと思いますが、在宅勤務になってからどのようにやっているか教えてください

※回答からいくつか抜粋

全員で通話し、約１時間くらいで休憩し、そのタイミングでドライバーも変更
slackの画面共有またはvscodeのliveshare
基本モブプロですが、個人作業の場合もチーム内で分担してやる場合が多いので、通話をつなぎながら作業しています。
朝からずっとSlack通話繋ぎっぱなしです。

業務外

7.出退勤の電車に乗らなくなった分、余裕時間が増えたと思いますが、どのように活用してますか？ (複数選択可)

f:id:allabout-techblog:20200422163125p:plain

8.今後、新型コロナウィルスの影響が弱くなり、出社可能となった場合、在宅勤務をどの程度の頻度でやりたいと思いますか？

f:id:allabout-techblog:20200422163136p:plain

9.在宅勤務をする上で工夫している・気を付けていることがありましたら教えてください

※記述式回答でしたが、関連性があるものが多かったので、関連性軸で出してます

作業環境整備
- ディスプレイを追加
- 集中するための騒音対策。（音楽を聴きながら仕事をすると集中できないので）ホワイトノイズや環境音をスピーカーから流して、集中しやすいようにしています。
- ポモドーロタイマーの導入
心構え
- 会社に行く時と同様に身だしなみを整えるとスイッチが入る
- MTG時は事前のフォローと事後のフォローを一層手厚くする
- 朝起きたらとりあえず着替える、コーヒーを飲むなど出勤する感を出してます
その他
- 休憩時間に筋トレをする
- 夜は散歩に出るようにしています。
- 同居人に仕事中だとわかるようにする。
- 定期的に換気をする

10.在宅勤務のメリットを教えてください

※記述式回答でしたが、通勤関連の方が圧倒的に多かったので、通勤関連は別軸で出してます

通勤関連
- 出勤電車に乗らなくて済むのは結構いいこと。出勤電車による疲労が減った。
- これまで通勤時間という無駄な時間を浪費していたことを実感
- 出勤/退勤時間がいらない
- 無駄時間の削減（通勤）
- 通勤ストレスが減る。割り込みが減る。お昼代も減って経済的に優しい
- 通勤時間の有効活用
- 通勤時間が無くなる
- 電車通勤しなくてよくなる
- 通話をきったら即、帰宅できること
その他
- 晩ごはんを早い時間に食べられる（すごく大きいです）
- 宅配の荷物が受け取れる
- 部屋がどんどん綺麗になっていきます。
- 睡眠時間が増える
- 割り込み作業が減ったことで、まとまった時間の確保しやすくなった
- リラックスできる
- 自分のベストな環境で仕事ができるところ。

11.在宅勤務のデメリットを教えてください

※記述式回答でしたが、関連性があるものが多かったので、関連性軸で出してます

作業環境関連
- （全員が）自宅の仕事環境を整えるのが手間、面倒
- 通信インフラなどが個人環境に依存すること（品質悪い人とはビデオ会議は無理）"
- 寂しい、インターネットの速度・安定しないとつらい
ダイレクトコミュニケーションロス関連
- 同僚たちを物理的に会える機会が減ること
- 人とのコミュニケーションを撮る機会が減るので、入社してから信頼関係を構築していきたい人にとっては大変な気がします。また、一緒にコンビニに行ったりしたり、雑談ベースでの相談をする機会が減ってしまう。外に出ないのであしこしが貧弱になっていきます。
- ほかプロジェクトの方に、気軽な相談がしにくい
- 作業内容が見えづらい
- 画面越しでは表情が分かりづらい
- 表情などの視覚情報から状況を察し難い
体調関連
- 運動不足
- 明らかに運動不足になることです。通勤の往復2時間がどれだけいい運動だったか思い知らされました。
- 肩こりが悪化した
その他
- 会社帰属意識の希薄化
- リラックスしすぎる
- 出勤・退勤の移動時間が無いのと、人の目が無いせいなのか、つい仕事しすぎてしまうところ
- だらだら仕事になりがち
- 電車に乗れない