dely engineering blog

レシピ動画サービス「kurashiru」を運営するdelyのテックブログ

データサイエンスチームでの1ヶ月インターンの記録

こんにちは。delyインターンのしょーといいます。 データサイエンスチームで1ヶ月間インターンさせていただきました。
本記事では、インターンで行なってきた事柄を紹介していきます。

目次

1. コホート分析

レシピ詳細画面のUIが変わったことによるリテンションの変化を分析しました。

分析手法

コホート分析を用いました。なぜコホート分析を用いたかというと、リテンションの変化が一目で分かりやすいからです。

roboma.io

今回はGoogleアナリティクスではなく、Pythonを用いてコホート分析を行いました。

まず、以下のデータをSQLで取り出して分析に使用します。

date: 最初にレシピ詳細画面を開いた日
past_days: dateから何日後にアプリを起動したか
user_count: dateの日にアプリを起動した人の中で、さらにpast_days後にアプリを起動した人数
total_count: dateの日にアプリを起動した人数

user_countをtotal_countで割ると、それぞれのリテンションを算出することができます。この値と、date、past_daysを用いてピボットテーブルを作成し、seabornで図を作成しました。

結果

完成した図がこちらです。
(イメージ図となっています、ご了承ください。) f:id:syou818:20190822184050p:plain

こちらを用いてUI変更前との比較を行なった結果、新しいUIの方がリテンションが改善されていることが分かりました。

2. アプリダウンロード数の推移

データレイクごとのアプリダウンロード数のデータを抽出し、それぞれのデータレイクにおいてデータが欠損してないかを調べました。
クラシルのデータレイクは以下を参照ください。

logmi.jp

今回はeternalpose、logpose、firebaseの3つのデータレイクを用いました。

分析手法

それぞれのデータレイクからアプリダウンロード数を、SQLを書いてデータを取り出し、seabornを用いて可視化しました。
日毎に5ヶ月の期間で推移を見ていきました。

結果

可視化したグラフは非公開とさせていただきます、申し訳ございません。

それぞれのデータレイクのアプリダウンロード数を確認したところ、firebaseにおいて、他の2つのデータレイクに比べて所々極端に少なくなっているところがあり、データの欠損が確認できました。このデータの欠損は今後のクラシルのデータ分析にも影響を与えると考えたので、開発チームに伝えてデータの修正をしていただきました。

また、logposeに格納されているアプリダウンロード数が、序盤から中盤まで他の2つのデータベースより少なかったことが分かりました。更に詳細に調査を行った結果、iOSのダウンロード数は正常でしたが、androidのダウンロード数が序盤から中盤まで少なかったため、androidのデータに何か異常が起きていたのだと考えられます。

3. 動画視聴予測モデル作成

ユーザが任意のレシピ動画を見るか見ないかを予測するモデルを作りました。   目標は実際のサービスに組み込めるようなモデルです。

以下用いるデータは、Athenaのeternalposeより取り出しています。

基礎となるデータフレームに至るまで

まず初めのアプローチとして、あるユーザがお気に入りしている動画に含まれている食材のデータを用いることを検討しました。

user_id: あるユーザー
video_cnt: ユーザがお気に入りしているビデオの個数
ingredient_count_list: ユーザがお気に入りした動画に含まれている食材とその個数のリスト

f:id:syou818:20190910212432j:plain

しかしこのまま用いようとすると、ユーザのお気に入りしている食材の情報しか使用できません。また、個々の動画の情報も入れないと良いモデルは作れないだろうと考えました。

そこで、ユーザがお気に入りしている動画で使われている食材のカテゴリを使用することを考えます。しかし、このデータをAthenaから取り出すのにとても時間がかかってしまいました。さらにデータを取り出した後に、カテゴリでなく個々の食材をそのまま使用する方がいいのではないかと考え、結局苦労して取り出したデータは使用しないことにしました。(大きなタイムロスでした・・・)

このようなアプローチを続けていく中で、まずは以下のデータセットを試してみることにしました。

user_id: あるユーザー
video_id: ユーザーが見たビデオ
watch: ユーザーがその動画を見たら1、見ていないなら0
fav: ユーザーがその動画をお気に入りしていたら1、していないなら0
また全食材の列を作り、動画で使われている食材の列に1、使われていない食材の列に0

f:id:syou818:20190910212501j:plain

このうち「fav」と動画の食材を説明変数に、「watch」を目的変数にロジスティック回帰で学習させたところ、99%の正解率が出ました。
しかし考察したところ、

・ユーザー特性が何も入っていないこのモデルになんの意味があるのか?
・そもそもお気に入りしてるかを最初に知れることはありえないんじゃないのか?

となり、大幅な改良が必要であることが分かりました。

学習

これまでのことを踏まえ、以下のデータを特徴量とし、ユーザが動画を見るか推測するモデルを作りました。以下、学習はロジスティック回帰を使用し、グリッドサーチでハイパーパラメータチューニングを行い、k分割交差検証で評価(k = 10)で評価を行います。

・ユーザのアプリインストール日(days)(動画を見た日から何日前かが入っている)
・ビデオのカロリー(calorie)
・ビデオの再生時間(duration)
・ビデオの料理を作るのにかかる時間(cooking_time)
・ビデオに使われている食材1つ1つ(食材が使用されていればその食材の列に1、使用されていなければ0が入る)

f:id:syou818:20190910212528j:plain

テストデータに対して90.4%もの正解率が出たものの・・

f:id:syou818:20190901230733p:plain

上のような混同行列になり、またF1スコアは0.059となりました。これはつまり新規データに対して約6%程度でしか動画を見るか判断できないというものです。混同行列を見たときに、真陰性が7810と、他の要素より飛び抜けています。このことから、今回はとりあえず動画を見てない方に分類してしまえばおおよそ正解してしまうために、正解率は高く出たのだと推察されました。偽陰性が806であることからも上記のことが言えるはずです。

色々悩んだ挙句、どの特徴量を用いればより良いモデルを作れるか検討するために、ランダムフォレストを用いて、今回のモデルの特徴量ごとの重要度を算出してみることにしました。結果は以下のようになりました。値が大きい方がより重要な特徴量であり、範囲は 0 ~ 1 です。

days:0.42, dulation:0.04, calorie:0.03, cooking_time:0.02・・・

これより、daysだけとても重要であることが分かりました。今回ユーザの情報として用いたのはこのdaysだけであり、より良いモデルを作るために、ユーザの特徴量を増やしていけばいいのだと考えました。

精度向上に向けて

次の3つのことを行いました。

①特徴量ごとの分布を正規分布に近づける
学習率は下がってしまうけれども、今回のような予測では、癌予測のように癌である人を確実に当てなければいけないものというよりは、様々なデータに対して予測できる汎化性能の方が重要と考えたためです。正規分布に近づけるアプローチとして、それぞれの特徴量の箱ひげ図と基礎統計量を観察し、外れ値を除去するように、平均値と中央値が近づくように、データを切り取ることをしました。

②データ数を増やす
これまで使用したデータはベルヌーイサンプルによってランダム抽出を行なっていました。データ数を増やす事によって、さらに汎化性能が上がることが予想できます。

③特徴量を増やす
先程までの特徴量に加え、以下の特徴量を追加しました。
・ユーザがお気に入りしている動画の個数
・動画を見たときにユーザがログインしていたか(していれば1、していなければ0とした)
・ユーザがプレミアム会員か(プレミアム会員ならば1、通常会員ならば0とした)

この結果、

テストデータに対する正解率:94.2%

f:id:syou818:20190901233943p:plain

F1スコア:0.76

となり、これまでで最も良い結果が得られました。

このモデルを利用した機能提案

ユーザがアプリを開いたとき、そのユーザーに合ったおすすめ動画を4つ表示させる

ユーザがアプリを開いたときに、API通信をしてdatabaseにアクセスします。そのdatabaseには各ユーザに対して提案する4つの動画が含まれており、このdatabaseを作るのに先程までのモデルを使用します。以下イメージ図です。

f:id:syou818:20190910215259j:plain

databaseの作り方
各ユーザに対して任意の数の動画をモデルに入れます。そこであるユーザーに対して、見ると判断されたビデオが4つ以上あったら、ランダムに4つの動画をそのユーザーに対する推薦動画としてdatabaseに入れます。もし見ると判断されたビデオが4つ未満のときには、4つに満たない分だけビデオの視聴ランキングの上位から選択して追加し、そのユーザーに対する推薦動画としてdatabaseに入れます。このdatabaseは様々な条件を考慮しつつ適当な頻度で更新をかけます。

databaseに登録されていないユーザーに対しては、ビデオの視聴ランキング上位4つを推薦することとします。

4. データサイエンスチームの取り組みに参加した

以上までが、私個人が取り組ませていただいた課題になります。
この他に、データサイエンスチームとしての取り組みに、私も一部参加させていただきました。内容はsakuraさんの記事にうまくまとめられています。

tech.dely.jp

tech.dely.jp

成果報告会を行なった

インターンの成果発表会を1時間ほど行わせていただきました。開発部の他チームからも聴きに来てくださったり、多くの質問をしてくださったりなど、とても貴重な時間でした。

最初どういうバックグラウンドの人が聴きに来てくださるか分からなかったので、どこまで説明するかとても悩みました。また、結構緊張しましたが、終始柔らかいムードで聴いてくださったためとても話しやすかったです。

発表は、使い慣れてるPowerpointがパソコンに入っていなかったため、Jupyter NotebookのRISEを用いて行いました。

qiita.com

終わりに

いかがでしたでしょうか?
この1ヶ月でとても多くの経験をさせていただき、物凄く成長することができました。これにはデータサイエンスチームの方々が、私のどんな質問にも丁寧に答えてくださったり、多くの貴重なお話をしてくださったことに尽きると思います。リソースが限られている中で、私に多くのリソースを割いてくださり本当にありがとうございました。

急成長を続けているベンチャー企業のスピード感を肌で感じつつ、皆がプロダクトのために熱心に取り組んでいる環境で急成長を遂げたい方、是非インターンに挑戦してみてください。

データサイエンスチームの取り組み Presto勉強会

f:id:sakura818uuu:20190826152215p:plain

はじめに

こんにちは。データサイエンスチームのsakura (@818uuu) です。
クラシルの検索改善を担当しています。

データサイエンスチームでは今月 Presto勉強会 を毎日行っていました。
本記事ではその取り組みをご紹介しようと思います。

Prestoとは

Prestoとは、Amazon Athenaで使用されている分散SQLエンジンのことを指します。
※本勉強会ではPrestoで動く「SQL記法」を勉強しています。

概要

Presto勉強会の概要です。

[内容] Prestoの公式ドキュメントを読み知見を深める
[目的] Prestoの知られざる機能などを学び、開発効率化に活かす
[時間] 毎日ランチに行く前の10〜20分
[参加者] データサイエンスチームメンバー(3人〜4人)

f:id:sakura818uuu:20190826150059p:plain
こんなかんじでディスプレイに映しながら話し合いました

Presto勉強会を一言でいうと
「毎日ランチ前にチームでPrestoの公式ドキュメントを読む取り組み」です。

実施内容

f:id:sakura818uuu:20190820175434p:plain
このページの単元を一つずつ読んでいきました

上記のドキュメントに従い1日大体1章ごと進めていきました。
わからないところは実際にAthenaでクエリを書いて試しながら進めていきました。

f:id:sakura818uuu:20190826115411p:plain
json_size関数を試している図 (公式ドキュメントだけでは理解するのが難しかったため)

取り組んでみた感想

複数人で公式ドキュメントを読む機会はなかなかないので貴重な経験となりました。

一番驚いたことは、ドキュメントの読み取り一つでも自分とメンバー間に違いがあったことです。
人によって読み取り方が様々で、
「この一行からそこまで読み取ることが出来るんだ」
「このメンバーだとそういった応用例まで考えているのか」
と技術ドキュメントの読み取り方の勉強としても参考になりました。


また、いくつか今後業務で活かせそうな関数も発見することができました。

f:id:sakura818uuu:20190826113346j:plain:w300
今後活かせそうな関数などをメモしています

もちろん、bool_and()to_iso8601(x) などこれいつ使うんだと思った関数もたくさんありました笑
一通り全ての関数に目を学んだことで「Prestoで出来ること/出来ないこと」を把握できたのがよかったと思います。

おわりに

Presto勉強会で公式ドキュメントを一通り読んだことで、チーム全体でPrestoへの理解が深まりました。
この勉強会で得た知見を業務に活用していきたいと思います。


データサイエンスチームでは、Presto勉強会やサーベイチャレンジなど様々な取り組みを行っています。もしご興味があればご応募・ご連絡ください: )

www.wantedly.com

データサイエンスチームの取り組み サーベイチャレンジについて

はじめに

こんにちは。データサイエンスチームのsakura (@818uuu) です。クラシルの検索改善を担当しています。

データサイエンスチームでは今年の3月から サーベイチャレンジ という取り組みを行っています。 本記事ではその取り組みをご紹介しようと思います。

概要

サーベイチャレンジの概要です。

[内容] 論文を読み、データサイエンスチーム内で共有する
[目的] 料理に関する様々な研究を知る・様々な分野の最先端技術を知る
[作業時間] 基本的に業務時間内に実施
[共有時間] 週1回のチームMTG内で共有及び議論
[参加者] データサイエンスチームメンバー(2人〜5人)

サーベイチャレンジを一言でいうと
「みんなで論文を読み、その知見を共有する取り組み」です。

進め方

サーベイチャレンジの進め方を紹介します。

  1. 各々が読む論文をmendeleyに格納し、チーム内で共有
  2. 論文を読んだ感想をテンプレートに従って記載。(Githubのissueで管理)

f:id:sakura818uuu:20190819170507p:plain
論文を読んだ感想のテンプレート

3.週1回のチームMTGでそれぞれがその週読んだ論文について議論し合う

当初はGithubのみで管理していましたが、論文の管理が少し面倒でした。
そこで文献管理ツールのmendeleyを導入し、簡単に一括管理ができるようにしました。便利です。

実施内容

どんな内容の論文を読んでいるか少しご紹介します。

f:id:sakura818uuu:20190820091307p:plain
実際に読んだ論文1

f:id:sakura818uuu:20190820092454p:plain
実際に読んだ論文2

f:id:sakura818uuu:20190820092334p:plain
今までに読んだ論文の一部

今までに30本以上の論文を議論しています。

取り組みに抱く感想

サーベイチャレンジを始めたことで論文を読む習慣が出来ました。 一人だとすぐ飽きてしまいそうですがチームで共有し議論することで一定のペースを保てて継続出来ているのが良いことだと思います。

また、実際にやってみてサービス開発に活かせるような知見をたくさん発見できたのが驚きでした。論文というと少し学術的な方面によっているのかな・・と思っていたのですがめっっちゃ役に立つ情報が眠っています。

最後に

サーベイチャレンジをすることで継続的に最先端の技術を知ることが出来たり、様々な研究内容をチーム内で共有し議論することができています。
今後も続けていき新たな発見をしていければと考えています。

Xcode11でデバッグ機能がいい感じにアップデートされたので紹介

こんにちは!クラシルiOSアプリを開発しているknchstです。

6月のWWDC19はSwiftUIなどのサプライズもあり、とても盛り上がりましたね!様々なセッションがあったのですが、個人的にいいなと思ったのがXcode11のデバッグ機能についてです。

この記事では以下の項目について紹介します。

  • Device Conditions
  • Environment Overrides
  • Debugging SwiftUI View Hierarchies

Device Conditions

f:id:knchst:20190801105018p:plain
https://developer.apple.com/videos/play/wwdc2019/412/

Thermal state condition

Xcode11から新たに端末の発熱をシミュレートする機能が実装されました。 これにより、端末を実際に発熱させることなく温度状態によるアプリの動作を確認することができるようになります。

Xcode11のメニューのWindowDevices and Simulators内に DEVICE CONDITIONS という項目が追加されていて、ここで設定することができます。

f:id:knchst:20190801114925p:plain

設定できる項目

  • Fair(わずかに高い状態、バックグラウンドフェッチなどが延期される)
  • Serious(高い状態、CPUやGPS、Bluetoothなどの使用量が削減される)
  • Critical(かなり高い状態、あらゆるリソースが最小限になる)

上記の3つをシミュレートすることができます。

Network link condition

通信状態をシミュレートする機能はiOS端末単体ではありましたが、今後はXcodeから直接端末の通信状況をシミュレートすることもできるようになります。

こちらもThermal Stateと同様でXcode11のメニューのWindowDevices and Simulators内に DEVICE CONDITIONS という項目が追加されていて、以下画像赤枠内で設定することができます。

f:id:knchst:20190801112938p:plain

デフォルトで設定できるプロファイルも

  • 100% packet loss
  • Very poor network
  • Edge Network - poor
  • Edge Network - average
  • Edge Network - good
  • Edge Network - best
  • 2G Network - poor
  • 2G Network - better
  • 3G Network - average
  • 3G Network - good
  • 3G Network - bet
  • LTE Network
  • WiFi Network
  • WiFi Network (802.11ac)
  • DSL Network
  • High Latency DNS

と増えて使いやすくなりました。

Environment Overrides

f:id:knchst:20190801103701p:plain
https://developer.apple.com/videos/play/wwdc2019/412/

Appleのプラットフォームには表示に関する設定や様々なアクセシビリティがあり、ユーザーが様々な設定を行うことができます。例えば、

  • ライトモード & ダークモード
  • ダイナミックタイプ
  • アクセシビリティ

などの項目があります。 これらの設定が変更された時に、アプリケーションのレイアウトが崩れないかを確認する必要があります。これらをデバッグする為にEnvironment Overridesという機能が新たに追加されました。

WWDCで行われたデモが以下になります。

f:id:knchst:20190801133322g:plain

Xcodeのデバッグ領域にEnvironment Overridesというボタンが追加されていて、ここから値を変更することができます。変更はリアルタイムに反映されます。また、シミュレーター・実機でも同様に動作します。

Debugging SwiftUI View Hierarchies

f:id:knchst:20190805115656p:plain

SwiftUIが新たに加わりView Hierarchiesのデバッガーも大きくアップデートされました。

Swift Reflection

SwiftUIでは、ビューにあるプロパティが自動でインスペクトされデバッガーに表示されるようになります。実際にデバッガで確認してみると、インスペクタにProfileViewのプロパティの情報が表示されています。

f:id:knchst:20190805123941j:plain

CustomReflectable

新たに追加されたCustomReflectableプロトコルに準拠することによって、独自のプロパティをインスペクタに表示することができます。

f:id:knchst:20190805123757j:plain

SwiftUIとその他のフレームワークのView Hierarchies

SwiftUIのプロジェクトでは既存のUIKitで提供されているUIViewControllerなどのクラスが利用できます。

f:id:knchst:20190805122645p:plain

上の画像のオレンジ色の枠はUIKitで実装されてもので、青色の枠はSwiftUIで実装されたビューになります。

まとめ

SwiftUIの登場によってデバッグもリアルタイム性がでてきて、より効率的な開発ができるようになりました。またDevice ConditionsやEnvironment Overrideなどのハードの機能をシミュレートできる機能を活用することによって再現しにくいランタイムエラーをデバッグすることができるので、リリース後の予期せぬ不具合も未然に防ぐことができます。

この記事で全てを紹介できていないので、詳しく知りたい方は以下をご覧ください。

RailsのCIにかかる時間を少しづつ改善している話

はじめに

こんにちは、delyでサーバサイドエンジニアをやっている山野井といいます。

kurashiruではサーバーサイドにRailsを使用しておりテストはRspecで書かれています。
CIはgithubリポジトリへのpushをフックしてAWS CodeBuild上でテストを走らせています。
またCI上のテストはparallel_tests gemを利用した並列化を行っていて、8プロセスで動いています。

弊社ではプロダクトの品質を保つ為、CIに通らないとデプロイできないルールを設けていまして、CIが完了するまでに時間がかかるとその分デプロイまでの時間もかかってしまうので1分でも早めたい気持ちがあります。

今回はアプリケーションコードには手を加えず、AWS CodeBuild上のCIの実行時間を少しづつ改善している話をしたいと思います。

実践

まずはCIの実行時間を改善する前にどこに時間がかかっているのかを把握する必要があります。

AWS CodeBuildには以下の11項目からなるphasesという概念があります。

SUBMITTED
QUEUED
PROVISIONING
DOWNLOAD_SOURCE
INSTALL
PRE_BUILD
BUILD
POST_BUILD
UPLOAD_ARTIFACTS
FINALIZING
COMPLETED

CodeBuildが実行されると各phaseが順番に実行されるようになっています。
この中で INSTALL, PRE_BUILD, BUILD, POST_BUILDのphaseはプロジェクトのルートに置いた buildspec.ymlに独自に処理を書くことができます。
以下がその例です。

version: 0.2
phases:
  install:
    commands:
      - service mysqld start
  pre_build:
    commands:
      - bundle install
      - bundle exec rake parallel:create
      - bundle exec rake parallel:migrate
  build:
    commands:
      - bundle exec parallel_rspec spec

AWS CodeBuildでは以下の画像のようにAWSのコンソールから各phaseどれだけの時間がかかっているのかを見ることができるので、それを見ながら改善策を考えていきます。

f:id:yamanoi-y:20190627143731p:plain


弊社では PRE_BUILDフェーズで bundle install やdbの作成、migration処理を行っているのですが、ここに10分ほど時間がかかっていました。
よく見ると処理時間のほとんどがmigrationにかかっていることがわかりました。
bundle exec rake parallel:migrateコマンドはcpuのコア数分プロセスを立ち上げコマンドを実行するため、migration処理が8プロセスで実行されていました。
これを1つのDBのみmigrationを行い、migration後のダンプを取得し残りのデータベースに流し込む処理に変えることで10分ほど短縮することができました。

  pre_build:
    commands:
      - bundle exec rake parallel:create
      - bundle exec rake parallel:migrate[1]
      - mysqldump -u root -prootpassword test > dump.sql
      - bundle exec parallel_test -e 'mysql -usomeuser -psomepassword test$TEST_ENV_NUMBER < dump.sql'


Before
f:id:yamanoi-y:20190627145817p:plain
After
f:id:yamanoi-y:20190627145920p:plain


またテーブルに変更が無い限りは前回のDBの状態を用いても問題ないため、db/migrateのgitのhash値からキャッシュキーを生成し、ダンプそのものをキャッシュすることで
初回のmigration処理自体をスキップすることもできます。

pre_build:
  commands:
    - git log --pretty=format:'%H' -n 1 -- db/migrate > ~/mysql-dump-checksum
    - mkdir -p ./.mysql-dump
    - |
      if [ -e "./.mysql-dump/$(cat ~/mysql-dump-checksum).sql" ]; then
        bundle exec parallel_test -e 'mysql -usomeuser -psomepassword test$TEST_ENV_NUMBER < "./.mysql-dump/$(cat ~/mysql-dump-checksum).sql"'
      fi


次に BUILDフェーズですが
BUILDフェーズでは主にRspecの実行を行っています。
今回はアプリケーションコードに手を加えない方法で高速化することを考えていたので特に変更は加えていません。
Rspec自体の速度を改善するには、一般的に遅いテストの洗い出しや、無駄なレコードの作成を行わないこと、無駄な通信を行わないことが挙げられます。
kurashiruでもここの最適化はさほど行っておらず、改善の余地があるので適宜改善していきたいと思っています。

最後に POST_BUILDフェーズですが、ここも5, 6分ほど時間がかかっていました。
AWSのコンソールからビルドログをよく見るとCodeBuildのキャッシュ機能によるs3へのアップロードに時間がかかっていました。
まだ設定の変更を完全に取り込むことはできていないのですが、CodeBuildのキャッシュタイプをs3から最近使用できるようになったローカルキャッシュに変更することで速度改善を試みています。
CodeBuildのローカルキャッシュは今年から利用できるようになった機能で、今まではキャッシュした結果をs3へアップロードしていたものをビルドホスト内に保持することができる機能です。
aws.amazon.com

この機能を有効にすることでs3への通信コストがかからなくなるため、ここにかかる時間を0にすることが確認できています。

最後に

1つ1つが地味な改善ですが、デプロイまでの時間を短縮でき、従量課金にかかる費用も節約できるので今後も時間を見つけて改善していきたいと思います。
最後までお付き合いありがとうございました。

プロジェクト管理を自動化してみたけど思うようにはいかなかった話

こんにちは。delyでAndroidエンジニアをしているkenzoです。
今回はAndroidの話ではなく、担当している別のプロジェクトの管理をいい感じにしようと思っていろいろやったけど、そんなにうまくいかなかった。という感じの内容です。

どんな話

「他部署の依頼でコンテンツを作成するプロジェクト」の管理を自動化した結果、うまくいったこと、失敗したことについてのお話です。 f:id:kenzo_aiue:20190507144040p:plain:w250

なんで自動化したの

今回のお話の背景

弊社では開発部が他の部署から依頼を受けてLP等のWebページを作成しています。
私は他の部署と開発部内の実装者とのやりとりの間に入って管理する取りまとめのようなことをしてきました。
やっていたことをざっくり言うと、依頼を受け、実装者に依頼して、配信の準備をする。という簡単なお仕事で、元々はスプレッドシートで管理をしていました。

発生した問題

新たに高い頻度でコンテンツを作る施策の開始や、開発部側で業務委託の方に実装をお任せするようになる等、次第にやりとりや確認・管理しなければいけないことが増えていきました。
そのため、業務の中でこれらのために使うリソースが増えてきたり、抜け漏れが発生しそうな気配を感じるようになったりと、既存のスプレッドシートを手作業で確認・更新するのにも限界を感じてきました。

どんな自動化したの

GASを使って下記の処理が定期的に実行されるようにしました。

  1. コンテンツの内容等が管理されているスプレッドシートから実装に関するものを抽出
  2. githubのプロジェクトに1をtodoとしてissueを追加
  3. 関係者に共有しているカレンダーに1を追加
  4. 開発側や業務委託の方と共有しているスプレッドシートに1を追加
  5. 素材・成果物が揃ったり、配信が迫ったタイミングでslackに通知
  6. 1の変更に合わせて2, 3, 4の内容を更新
  7. その他もろもろ、、、

これらの組み合わせで、今回のプロジェクトにおける業務フローのある程度の部分を自動化することができました。
f:id:kenzo_aiue:20190507174721p:plain:w250

うまくいったこと

作業削減

issueやカレンダーへの追加や更新を手動で行うという、そこそこ手間のかかる作業(定期的にスプレッドシートを確認して内容を様々な場所に追加・更新)をなくすことができました。

抜け漏れ防止

依頼が発生したり、配信日が近くなったら関係者のslackチャンネルにbotで通知を送りました。
抜け漏れを防ぐことができそうで、日々の心配事が減りました。

うまくいきそうだったこと

やりとり減らせそう

必要なタイミングで必要な人に通知を送ることで、やりとりが減らせそうな気がしていました。

うまくいかなかったこと

想定以上の戻り作業の発生

今回行った業務フローの自動化ではそれぞれの工程が完遂されているかのチェックが抜けていたため、次の工程に進んでからの戻りが度々発生しました。
その結果、その都度手動でのやりとりを行うことになってしまいました。

業務委託先の方との信頼を築けなかった?

あまりやりとりをしていないまま、業務委託先の方とのやりとりもbotでの運用に変更してしまったために信頼を築けなかったかもしれません。
そのためか、締切が近くなっても連絡がつかず、紹介してくれた別の社員に連絡をお願いすることになってしまい、コンテンツが配信ぎりぎりの完成となってしまったこともありました。

こうしたらよかったのかも

「想定以上の戻り作業の発生」に対して

戻りを完璧に防ぐのは不可能だし、いろいろな手立てを講じる工数もあまりありませんでしたが、頻繁に発生していたシンプルなミス(素材の不足や工程忘れ)についてくらいはチェックする仕組みを入れておく必要があったように思います。
また、手順をもっと明確にして初めに伝えておくことや、困った時に参照できるものを作っておくとかでも防げた可能性はあります。
他の業務でも同じことが言えそうですが、必要な内容を伝える・参照しやすくしておくことは大事ですね。

「業務委託先の方との信頼を築けなかった?」に対して

もう少しやりとりをしたり、直接会う等して信頼関係が築けてからslack botの運用を始めるべきだったと感じました。
または、slack botでの通知はあくまで自分へのリマインドにとどめ、やりとりは自分で行う。といった方法を検討してもよかったのかもしれません。
信頼関係のないままslack botだけで完結させようとしてしまったため、なにかあった場合に気軽に言ってもらえるような心理的安全性を高められなかったのではと思います。
このような信頼関係は人と関わる業務全てにおいて大切なことだと思いますが、今回は効率を求めて自動化を進める上でおろそかにしてしまったのが反省点です。 f:id:kenzo_aiue:20190507173532p:plain:w300

まとめ

自動化によって便利になることはいっぱいあるので、これからもどんどんやっていこうと思います。
ただ、自動化するのが難しい部分も多々あると思います。もちろんそこは手作業等で補う必要があるのですが、ともすると、省いたかたちで自動化してしまうこともあるかもしれません。
そうすると、せっかく自動化したのに後々工数を取られたり、ミスに気付かないまま進んでしまうということも考えられます。
特に、今回私がミスった信頼関係における部分、人間的なコミュニケーションを省いてしまうと、理論的にはうまくいきそうに思えても、どこかで綻びが生まれて問題が起きることがありそうです。
業務を効率化する時でも、あえて人の手を介した方がうまくいくこともあると思うので、その辺りを頭に入れつつ今回の反省を活かし、これからも自動化を進めていきたいと思います。

Search Engineering Tech Talk 2019 Spring に登壇しました #searchtechjp

f:id:sakura818uuu:20190426185916p:plain

こんにちは。開発部のsakura(@818uuu)です。

2019年4月23日に開催されたSearch Engineering Tech Talk 2019 Springに登壇させていただきました。

会場は南青山にあるNAVITIMEさんで行われました。
NAVITIMEさんにははじめて行ったのですが、すごくきれいな会場で発表しやすい環境でもあったのでとても助かりました。
ありがとうございました!

あとお茶もらいました。ありがとうございます。

登壇は久々だったのですごく緊張していました。
25分枠だったのでタイムスケジュールのことがものすごく不安でした。

登壇は3名いて私は3番目の発表予定でした。
一人目はNAVITIMEさん、二人目はFessを作ってる方の発表でした。
どちらのサービスもばりばり使ったことあって好きな検索サービスだったので、そんな検索の中の人と一緒の舞台にたてるのが嬉しかったです。

お二人の発表資料はこちらになります。

www.slideshare.net

www.slideshare.net

お二人の発表が終わり緊張は頂点でした。↓登壇直前のツイート

登壇はなんとか無事終えることができました。(よかった……)
すごく話しやすい場を聞いてくださる方が作ってくださったので話しやすかった&楽しかったです。
本当にありがとうございました。

登壇資料はこちらになります。

登壇を終えてハッシュタグを拝見させていただいたのですが色々な感想をつぶやいてくださり本当にありがとうございます。

#searchtechjp - Twitter Search

懇親会でもたくさん検索のお話ができてよかったです: )
すごくすごく貴重な経験をさせていただきました。ありがとうございました!