非エンジニアが業務効率改善のためのSlackbot開発を引き継いでみた

アカウントストラテジストの奥です。今年夏ごろよりフライウィールにジョインし、広告媒体事業に携わっています。アカウントストラテジストという肩書で、一応プランニング業務と施策推進を中心に担当しつつも、代理店営業や実際の運用調整、事業全体の売上管理、業務フローの構築など幅広く担当しています。
今回はそんな何でも屋さんをやっている「非エンジニア」である私が、業務効率改善のためのSlackbot開発を引き継ぐに至った背景、そしてこのプロジェクトで学んだことを書きます。

botが生まれた背景

弊社の広告媒体は昨年からクローズドでいくつかの案件で配信させて頂いて、この前の10月より正式にスタートした生まれたばかりのプロダクトです。
そのため2019年12月現時点で、DSP自体としても、管理画面としてもまだまだ改善しなくてはいけないポイントがたくさんあります。
今でさえそのような状況なので、自分がジョインした夏はもっと色々あったころで、すぐに以下の点で課題を感じていました。

• 運用工数の肥大化
  • 広告アカウント構成の複雑化。
  • 入札や配信するクリエイティブの自動最適化の機能は現時点ではない。
    
• 運用調整の精度
  • 一部のアカウントに関してはデイリーの予算が大きいため、データ判断と集計などに時間をかけずに調整をかけていく必要があり、必ずしもすべての調整がデータ分析による判断ができているものではなかった。
• 運用調整の属人化
  • 成果を確認するための過去広告媒体の運用経験のある一部の人には理解できるかもしれないが、運用経験のない人には理解しづらい部分も多い。

いずれも人的リソースが豊富ではないベンチャー企業にとっては大きな課題。
これらに対してはいくつかの観点から複数の対策を社内で提案したのですが、そのうちの一つに「広告運用者をサポートするbot」プロジェクトがありました。
このプロジェクトで目指していたのはざっくりいうと以下です。
広告媒体の運用にあたって必要な分析、調整業務のうち人間が判断する必要のない部分に関してはbotが教えてくれる（or調整してくれる）ようにしたい！
自分が提案する前から最初に列挙したような課題は認識されていたので、このプロジェクトはすぐにスタートしました。
当時はちょうど学生が夏休みの時期ということもあり、弊社にもとても優秀なインターン生が何人か来ていました。そしてこのプロジェクトは短期でインターン生としてきたAくんのプロジェクトとして、運用チームや私の意見を聞いてもらいながら進んでいきました。
しかし、いくつかの機能が実装されて、そろそろテスト運用かな、というタイミングでAくんは無事フライウィールを卒業することになりました。
このbotの開発はほとんどそのAくんひとりによって進められており、開発チームのリソースも潤沢ではないことを考えるとこのプロジェクトがたち消えてしまうのでは、という危機感を感じました。
せっかく作られたのにもったいない、そして元々自分が提唱していたことに由来するプロジェクトでもあるということで、この開発を引き継ぐことを社内で宣言しました。
軽く引き継ぎのMTGをしたのですが、Aくんはソースコード上のコメントやドキュメントをしっかり残してくれていただけでなく、今後の拡張性を踏まえた実装をしてくれていたので、構成を理解するのにそこまで時間はかかりませんでした。

どういうbotか

ざっくりとした概要

各広告主の成果状況を集計したり、どこを調整するべきかを教えてくれたりするbotです。
弊社は全社的にSlackをコミュニケーションツールとして使っているので、なじみやすさを考えてSlackbotとして実装されています。Tomson君（Aくん命名）という名前でフライウィールのワークスペース上にいます。

つぶらな瞳でこちらを見つめるTomson君

Slack上でお願いすると、各案件の成果状況の通知や、簡易的な集計、分析業務を人間に代わってやります。

ちょっと口が悪いときもあるTomson君

技術的な話

少しだけ技術的な話にも触れておこうと思います。
以下のような構成でTomson君は動いています。

• • EKSで作ったk8sクラスタのなかで動いている。
  • 集計データはAthena上にある配信ログから読み込む。
  • 言語的にはPythonを使用。
    • 以下のライブラリを使用。
      • flask：webアプリケーションが簡単に
      • slackbot：その名の通りslackbotが簡単に
      • numpy：数値計算
      • pandas：データ解析
  • A君はしっかりテストも書いた上でCircleCIでCI/CD環境も構築してくれていました。
    • なので私が何か変更を加えたときには、masterブランチにマージすれば自動的にDeployされるのでほとんど何も意識せずにDeployできています。

全くわかっていないインフラ周りについて質問する筆者と優しく答えてくれるエンジニアの方、そしてそれを見守る運用チームの方

どう改善してきたか

ここからはこのbotを奥がどう改善してきたかを具体的な例を踏まえてまとめます。
Tomson君で使えるコマンドの中に「note」コマンドというものがあります。
このコマンドはクライアントIDとtCPAを与えると「広告アカウント内の広告グループのうち、目標CPAを達成できていないものを通知する」というコマンドです。
使い方

@Tomson note {クライアントID} {tCPA}

運用者はこのコマンドを使って、頭を使うことなく抑制するべき広告グループを知ることができます。
使用頻度が一番高いコマンドだと考えたため、このコマンドのアップデートに注力しました。
これ以外にも色々な要望を反映させたコマンドが多くあったのですが、運用経験が少ない人のハードルを下げるためにも少ないコマンド数でシンプルに実現する必要があると思いました。

引き継いですぐの頃のnoteコマンドとそれに対するTomson君の返答

このようなかたちで各広告グループのCPAがどの値からどの値の間にあるのかを統計的に求めて下限値がtCPAより上回っている広告グループを通知するようになっています。
最初はこれで問題ないかのように思えたのですが、実運用で使ってみている間にいくつかの改善点が出てきました。
例えば以下のような点です。

1. 当日のデータで集計しているので、予算規模の大きいクライアントでないと有効な通知ができない。
2. 信頼区間を元に判断しているので、コストを多く使っていてCVが0件というような、本来極悪と判断するべき広告グループを通知することができない。
3. tCPAを満たしていない広告グループを通知することはできるが、逆にtCPAを満たしていて配信を伸ばすべき広告グループを通知することができない。

これらの点は実際に広告運用したことのある人でないと課題にそもそも気づきにくいかもしれませんし、実際のソースコードを見たり、
統計的な視点がないと何が原因でそうなっているのかがわかりづらい内容かもしれません。

それぞれの点に対して、以下のように解決しました。

1. 当日のデータで集計した後に、一定の基準以上のimpressionがない場合には過去1週間で集計し直してデータ量を担保する。
2. CVが0件で一定基準を超えて予算を消化している広告グループは極悪な広告グループとして通知する。
3. tCPAを満たしている広告グループは、抑制が必要な広告グループと区別した上で同時に通知する。

改善後のTomson君。口の悪さも引き続き。

これらの実装を通して思うのは
エンジニア、データ分析、運用の各領域を横断したコミュニケーションが大事
ということです。（とても月並みな内容）
今回のケースでは自分がそれらの領域を横断してかじったことで同等の役割を担えているのかなと思っています。
「統計学的に正しい」と「広告運用として正しい」は必ずしも一致しないことがあるので、その塩梅を取る必要がありますし、技術的な実装が本当に「統計的に」or「広告運用として」あっているのかを判断する必要があります。
この点に関しては、広告運用としての理想を伝えた上で、データサイエンティストの方と統計的な観点からの判断方法を議論し、社内のエンジニアの方にはそれを実現するためのより効率的な実装方法などを聞きながら進めることができました。

これから

実装が必要な機能リストにあって、実現できていないことはまだまだたくさんあります。短期〜長期それぞれの時間軸で以下を実現していこうと考えています。

• 短期
  • 実運用が難しかった要因である点を直したことが直近であるため、まずは使ってもらうように啓蒙していく。その中でさらに改善点が見つかるはず。
• 中期
  • 決めの数値を入れている部分に関しては、今後、より確実性の高い根拠に基づいた判断ができるように精度を上げていく。
  • 短期的な記憶領域を作成して、それに基づいた判断ができるようにする。
    • bot用のDBを構築。より高度な判断ができるようにする。
• 長期
  • 広告ビジネスにおける業務の「人間がする必要のない」すべての業務をやってくれるようにする。
    • 管理画面の機能と重複する部分があるため、棲み分けを議論しながら実装していくことに。

学んだこと、改めて感じたこと、個人的な思い

今回のプロジェクトを踏まえて学んだことをまとめます。（継続中のプロジェクトでまだ終わってないですが現時点の学び！）

• 自分の業務範囲だけでなく幅広い知識を「浅くでも」知ろうとすることが大事
  • それぞれのメンバーの得意領域の知識を最大限に活かすためにも！
• エンジニアリングとマーケティング、データの融合
  • それぞれの領域で進歩している。ビジネスにおいてはそれぞれの最先端である必要は必ずしもなくて、それらを少しずつ掛け合わせができることが重要（なのではなかろうか）
• こんな経験はなかなかできないんじゃないか
  • エンジニアでもないのに、エンジニアリング的なことを学べるだけでなく、同時に”プチ”プロジェクトマネジメントを学んだ気がする。

最後にちょっとした宣伝ですが、上の3点のどれか一つにでも共感するポイントがあるようであれば、ぜひオフィスに遊びにきてください！
フライウィールでは全職種で積極的に採用を行っています。そして私のポジションは今のところ一人のためきっと穴場のはず。。。お待ちしています！

おまけ

• Tomsonの由来
  当時Aくんと同時期にいたインターン生の一人がクリエイティブ最適化配信のロジック開発に取り組んでいて、そのアルゴリズムの候補のうちの「Thompson Sampling」というアルゴリズムの言い間違いか何か、という由来だった気がするのですが忘れました。。。
  参考：Thompson sampling – Wikipedia

下書きの段階で発生した由来に関するやり取り

• Tomson Jr.
  開発の際にローカルでサーバーを立ち上げることになるのですが、そうすると開発中のTomson君と本番環境のTomson君とで二重で返事が返ってきてしまい、紛らわしい状況でした。そのため開発用のTomson君を切り出してTomson Jr.としてリリースしました。本家Tomson君と画像が若干違うところがポイントです。