非エンジニアが作る社内Rパッケージ活用例とその効果 #R

私は「VALUES」という会社のデータ分析チームで働いています。
昨年末より社内Rパッケージ「valeuR」(バローと呼んでいます)の開発を進めており、業務の効率化・Rの社内普及の観点で一定の成果が見えてきたので、開発に至る経緯、開発した関数の内容、開発してよかったこと、の3つをまとめたいと思います。
私自身新卒でデータアナリストとして働き始め、R以外の言語の知識やエンジニアとしての経験もほとんどありませんでした。エンジニアでなくともRの社内パッケージを作り、分析業務のシステムに組み込み、組織に貢献できるという一例として、何かのお役に立てればうれしいです。

開発に至る経緯

airbnb社の2つの記事「How R Helps Airbnb Make the Most of ItsData」と「Using R packages and education to scale Data Science at Airbnb」を読んだことが社内Rパッケージ開発を考えるようになったきっかけです。特に後者の記事は社内でRのパッケージを作成するべき理由や、効果、指針が書かれており、とても参考になりました。

この記事を読んだ当時私は2つのことに悩んでいました。

1つは業務の煩雑さです。
クエリを投げるためだけに複数のツールを利用して、サーバへの接続、認証など複数のステップを経なければならなかったり、特定の集計をするためにいくつかの社内ツールにアクセスしなければならなかったり・・・。分析をしているのかマウスをポチポチしているのか、これでは判別付きません。これらすべてを簡略化し、RStudioだけで完結できたらいいな、という強いモチベーションがありました。そして、もっと分析部分に集中したいと思っていました。

もう1つはRの社内普及についてです。
チーム内では特定の言語を使うという強制は（記事執筆現在でも）ありません。R、Python以外の方法をメインにしている者もいます。それぞれが異なる言語を使う中、組織の規模が大きくなるとナレッジの共有がしづらいという問題意識を持つようになりました。そして、R（tidyverse）は習得が比較的容易で、分析（特にETL）に非常に適しており、もっと多くの人にRを使ってみよう、初めてみようと思ってもえたらなあと漠然と思っていました。

airbnbの記事ではこの「業務の効率化」と「Rの普及（教育）」という2つの問題に社内Rパッケージを使って対処しており、airbnbを参考にパッケージの作成を進めてみようと思い立ちました。

開発した関数の内容

1.データの取得

airbnbの記事中でも、社内Rパッケージで第一に着手するべき事項としてデータの取得部分のサポートが挙げられています。実際に現在でもダントツでチーム全体の使用頻度が高いのはこのデータ取得の関数です。

社内パッケージ開発以前のデータ取得

弊社ではDWHにRedshiftを使用しています。サーバは隔離された場所にあり、クエリを投げるためにはまず踏み台サーバに接続し、そこからRedshiftの近くにあるサーバに接続、サーバ内でunloadを行うクエリを作成し、unloadでクエリを実行、処理が終わったら別途S3に返ってきた結果を取ってくる、という作業を行う必要がありました。多少簡略化する術はありますが、いくつかのソフトウェアを立ち上げる必要があり、Rから通常のDB接続と同じように作業を行うのは困難な状況です。

社内パッケージ開発後のデータ取得

下記コード1つでDBからデータをRに読み込めるようになりました。

res <- vls_unload_auto(query, schema)
# 社内Rパッケージの関数には[vls_]という社名由来のprefixを付けています。

Redshiftの近くにEC2インスタンスを稼働させ、少し強引に実現しました。

Rからschemaを指定してクエリを投げると、Redshiftへunloadを行う形式に変換し、S3の所定のbacketに格納。
Redshift近くのEC2インスタンスは、所定のbucketにファイルが置かれたことをトリガーに、Redshiftへクエリを投げる。
Rは、結果の返却されるS3のbucketを監視し、結果が返却されたら読み込む。

インフラの状況やセキュリティ要件によりデータの取得方法や煩雑さはそれぞれだと思いますが、データの取得は発生頻度も高いので、日々の業務で煩雑に感じているなら多少強引にでも解決する価値があると思います。
ちなみにEC2のインスタンスやEC2で動くプログラムは先輩のエンジニアにお願いして作ってもらいました。

なお、S3とRとのやり取りには{aws.s3}というパッケージを使用しています。
こちらの記事を参考にしました。
https://blog.hoxo-m.com/entry/2017/07/18/210200

2.クエリの保存

業務上よく使うクエリをgithubのRパッケージ開発用のレポジトリで管理し、Rのオブジェクトとして参照できるようにしています。

#使用イメージ
vls_sql_list$`分析対象`$`分析内容`$`id`
> "select userid, access_time from db where access_time >= '{access_time1}' and access_time < 'access_time2'"

分析者が都度変更する箇所を、{glue}パッケージで簡単に修正することができる形で格納している点がポイントです。{glue}パッケージについては過去に記事を書いています。
https://qiita.com/kosshi/items/fb8b745975ca6fd2515c

3.社内ツールのRラッパー

社内ではデータを所定の形に集計するツールや、所定の形でDBからデータを取得するためのツールが、WEBツールとして提供されていました。業務上「所定の形」であることが大事である理由があり、これらのツールと業務を切り離すことはできませんでした。
{httr}や{Rselenium}を使い、これらのWEBツールにアクセスし、結果を取ってくる関数を作成することで、RStudioからWEBツールを使えるようにしました。

WEBブラウザからアクセスするタイプの社内ツールなどを分析の途中で挟むと、どうしても手作業での操作が発生してしまいます。分析を再実行する際に、そういった手作業があるがゆえに、不当に時間や手間がかかってしまったり、コードに現れないためステップを飛ばすミスをしたりといったことに繋がります。Rから実行できるようにしたことで、そういった手間や時間、ミスの削減につながりました。

4.社内での研修向け関数

レビュー系

新入社員向けの研修期間で、クエリやコードのレビューを行っています。Rstudioを離れてメーラーやslack、githubを立ち上げてレビュー依頼を送るのが（新卒当時の私は）面倒だったので、RからSlackにレビューを送る関数を作成しました。

#SQLレビュー依頼の例
vls_sql_review_req(query, mention = "reviewr", massage = "レビューお願いします。")

レビューをする側としてインデントなどで整形されたSQLをslackに投稿したかったため、SQLの整形にJavaScriptのライブラリを{V8}パッケージを使って活用しました。
https://github.com/zeroturnaround/sql-formatter

DBの環境再現

新卒メンバーにSQLを教えていますが、慣れるまでは権限の問題で本番のDBにアクセスすることができません。慣れるためにはDBにアクセスできたほうが良いけれども、慣れるまではアクセスできないというジレンマですね。
そこで本番環境のデータベースの構造を再現したdockerファイルを作成しました。そして、クエリを投げるとdockerが立ち上がり、クエリが実行され、クエリが正しいか確認できるというRの関数としてラップしました。

#イメージ
res <- vls_query_check(query, schema)

dockerの操作は、{reticulate}と{docker}というパッケージからPythonのモジュールを使うことで実現しています。
ほぼdockerの話な気もしますが、Rの関数としてラップすることでdockerコマンドを覚える必要もなく、非エンジニア向けの研修としてやさしい設計にできている点がポイントだと個人的に思っています。（Rの研修は別途ある）

JavaScriptやPythonのライブラリを簡単に使える環境があることはRを使うメリットの1つですね。

開発してよかったこと

業務の効率化面

データの取得をRから行えるようにしたことと、社内ツールをRから操作できるようにしたことで、分析に関わるほぼすべての操作をRStudioで完結できるようになりました。RStudioが好きだからこういった試みをしたわけではありません。これにより、RMarkdownファイル1つでデータの取得から最終的なアウトプットまでをすべて記録できるようになり、データ分析の再現可能性が劇的に高まりました。
データ作成後に「期間を変えて同じ集計して！」という依頼を来ることがあるかと思いますが、最初や途中にマウス操作でポチポチが入ると、再集計時にもマウスでポチポチせねばなりません。RMarkdownで一気通貫できると、ファイルの期間の箇所を修正するだけで再実行可能になります。
また、データ分析者が分析に頭を使う時間を増やすことにもつながります。

Rの普及面

「Rからだとデータの取得が簡単！」ということで、PythonとRを併用して使っていた人たちのR利用頻度が上がりました。この部分の簡略化の威力は絶大だと思います。個人的にはRユーザが増えるとうれしいですが、Pythonでも同じような仕組みがあるに越したことはありませんね。
また、毎年非エンジニア向けにRの研修を行っていますが、エンジニア寄りの部分が社内のRパッケージに隠ぺいされることで、Rを使ったデータ分析という行為そのものの敷居が下がるというメリットもあるように思います。

（最後に）明日からできる社内パッケージ開発

airbnbの記事を読む。[記事1]、[記事1の日本語訳]、[記事2]
hadleyのパッケージ開発の本を読む。
まずはデータの取得部分を簡略化するシステムを作りRのパッケージでラップする。

3だけでも実現できれば業務は変わると思います。
~~データの取得に煩雑さを感じていないならばうらやましいです。~~