女性のキャリアに関するサービスの、技術を支える2人

米山　私は新卒でリクルートに入社し、Webサービスの企画、ディレクションを担当していました。その後、フリーランスのエンジニアとなって起業準備をしていた時に代表の松本と出会い、一緒にLiBを創業しました。現在はCTOとして、組織作りをメインに担当しています。

弊社は、女性のキャリアに関するサービスを展開しています。キャリア系のサービスには、セールスやコンサルタントといったメンバーが必要です。システムだけですべてが解決できる事業ではないですが、できる限り人手がかからないように、システムの力を借りるような組織設計を心がけています。

浦川　私は前職ではビッグデータを取り扱う、データ分析の会社に勤めていました。そこでAWSをはじめとして、いろいろな技術を学びました。そして、そこで学んだ知識を活かしてイチからやってみたいと思い、LiBへ入社しました。

サービス本体の開発というより、いかに安定してリリースや運用ができるかという点を担当しています。新しい仕組みを取り入れたり、開発者が安心して開発していけるような環境を作っています。

「Slack担当」がどんどんカスタマイズしていく

米山　弊社では創業間もないタイミングから、社内コミュニケーションに「Slack（スラック）」を活用しています。全社的なコミュニケーションだけでなく、GitHubのコミットやプッシュのログを流していたり、サーバーのアラートが飛んでくるようにしています。

また、自社のサービスに対する要望を集める場としても使っています。Slackで特定のワードをつけてコメントをすると、それがエンジニア全員に通知されるような仕組みですね。

例えば「UIをこうして欲しい」という要望や、新入社員が「ツールの使い方が分からない」という質問をするという用途で使われています。

▼Slackで要望をあげる

浦川　そういったカスタマイズや、絵文字を追加する「Slack担当」が私になっています（笑）。もちろん他のメンバーが作ることもあるのですが、Slackの設定画面を見てみると、外部連携やカスタム絵文字はほとんど自分の名前で登録されていますね。

※Slackの「外部連携」についての解説は▼をご覧ください。

Slackの使い方【外部サービス連携】です。

マーケが「SQLだけ考えられる仕組み」を作るため、Slackを活用

浦川　弊社でのSlackの特徴的な使い方として、SlackからSQLを直接実行し、必要なデータをいつでも確認できる環境を構築しました。

▼SlackからSQLを直接実行

▼クエリの実行結果

▼ファイルがダイレクトメッセージで届く

この仕組みは、マーケティング担当者の依頼から始まりました。レポートを作るのが面倒だと、去年あたりからチクチク言われていまして（笑）。

当時は、データが欲しい時は米山に依頼し、テーブルのデータを全部持ってきて、そこからエクセルでピボットテーブルを駆使して集計していました。

しかし、データ量が増えてくるとそれも難しい上、米山が病欠するとデータが取り出せなくなる、といった状況も起こってしまいます。そこで、マーケティング担当者が直接SQLからデータを出せるようにしようと考えました。

誰でもSQLを実行できる環境を作るため、最初はSQLのクライアントツールを入れてもらいました。ただ、ツールの設定や使い方が分からないから使えない、と言われてしまったんです。

URLやパスワードを管理したり、ツールの使い方をサポートしたりというのは、本質的ではないですよね。本当は、SQLだけに集中してもらいたい。

このような仕組みは使ってもらってなんぼなので、SQLのことだけを考えられるように作ろうと考えました。せっかくなら面白い方がいいと思い、普段から使っているコミュニケーションツールであるSlackから、SQLを投げられる仕組みを構築しました。

AWSをフル活用し、安全なSQL実行環境を構築

浦川　SlackからSQLを投げられる仕組みは、2段階に分けて作りました。分析用のデータベースを用意する仕組みと、そのデータベースへSlackからクエリを投げる仕組みの2つです。

本番用のデータベースに好きなようにSQLを投げてしまうと、負荷がかかってしまったり、不要な情報が見えてしまうことがあるので危険ですよね。そのため、本番用とは別に分析用のデータベースを用意しています。

仕組みとしては、AWS RDSが1日1回スナップショットを取る機能を利用しています。スナップショットが取れたタイミングでAWS SNSの通知が受け取れるので、そのイベントを元にスナップショットからインスタンスを作り、不要な情報をマスクするためのSQLを流しています。

そして、Slackからのコマンドを受けとる部分はAPI GatewayとLambda、EC2 RunCommandを使用しています。

EC2 RunCommandは、サービスが出たときから「何か面白いことに使えないか」と思っていて、でも上手い使い方が思い浮かばず，お蔵入りしていたんですね。今回のシステムを考えていた時に、もしかしてEC2 RunCommand使えるのでは?と思い試してみました。

SlackからSlash Commandを利用してAPI Gatewayにリクエストを投げ、それを受け取ったLambadaがEC2 RunCommandを実行する仕組みです。

Lambdaはサーバーレスで気軽に動かせますが、調子に乗って使っていると、凄いお金をとられる可能性があります。なので、Lambdaは便利に使いつつも、できるだけ短い時間で処理を終わらせるように気をつけました。

▼全体の構成図

教えたSQLが後輩に、他の部署にと勝手に広がった

浦川　初めはマーケの人の「この数値取りたいんだけど」という依頼に、それはこう書けばいいんですよと答えていましたが、今ではそのクエリを元に原型をとどめないくらい改造して使っているようです（笑）。

いくつか難しいところ、例えばテーブルをJOINするところだけ教えてあげると、後はWebのドキュメントを参照しながら自分で学んでくれています。

そしてその魔改造したクエリを、部下や関係者の人たちに配っていて、今ではいろいろな人がSQLを投げられるようになりつつあります。最近ではカスタマーサポートの方も、ユーザーの細かい状態を知りたいという目的で使うようになりました。

米山　もちろん管理画面から確認できる数字もあるのですが、すべてを見られるわけではないんです。特に、新機能を追加したときは、つい管理画面を後回しにしてしまって、最近追加されたデータが分析できないというケースがあります。

以前は私がすべてのデータを出していたので、その作業が無くなっただけでもだいぶ楽になりました。マーケの人から数字を聞かれることも減りましたし、勝手に勉強してくれるので、教えがいもあります。やって良かったなと思いますね。

ログ分析や自動化に取り組み、生産的な組織を作る

浦川　マーケだけでなく、開発の人にとっても意外と便利でしたね。システム開発をしている中で、「あのテーブルの構造どうなっていたっけ？」と思う時にSlackからすぐに確認できたり、重そうなクエリの実行計画を確認したりと、使ってみて気付いた良さもありました。

米山　今は、別のデータベースに保存されているアクセスログを、どうやって分析するかという仕組みに取り組んでいます。

同じようにSlackから取れるようにするのか、別の仕組みが良いのか、検討しているところです。他にも、本番サーバーのログもSlackから検索できたらいいな、という要望がポロッと出ていますね。いちいちサーバーに入って確認するのも面倒ですし、事故るのも怖いですからね。

今後は、自動化が進んでいない領域がいっぱいあるので、その辺りをどんどん構築して、より生産的にしていきたいですね。もっと事業を前に進めるためのタスクを、どんどん実行できるようにしていきたいです。（了）