プロダクト開発おける失敗の考え方と分析基盤

こんにちは、OPEN8 CTOの @hisatake です。前回は不確実性の中、進むための捨てる勇気とマイクロサービスについて書いたが、今回は少し具体的により弊社で取り組んでいる事例を紹介します。

TL;DR

プロダクト開発においては、小さな失敗はむしろ積極的にし、重要なのはその失敗を計測・検知・修正ができること。その取組として、ログの基盤の構築を始めたこと。

プロダクトの開発における失敗

「失敗」というと、元来ネガティブな意味合いで捉えられることが多いと思う。ただ、プロダクト開発においては「失敗」は許容され、むしろ積極的にしていくことが望ましい。

TDDという手法

プログラム開発手法において、テスト駆動開発（TDD）はまずあえてはじめに失敗する。

1. 失敗するテストを書く
2. できる限り早く、テストに通るような最小限のコードを書く
3. コードの重複を除去する

https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%B9%E3%83%88%E9%A7%86%E5%8B%95%E9%96%8B%E7%99%BA

TDDのようにあえて失敗することを現実のプロダクトの開発には適応しなくてもいいが、この「1. 失敗するテストを書く」という行為は、失敗を検知を確認しているのが重要である。

失敗を検知できる状態作り出す

このように失敗を検知できる状態を作り出す事により、マイクロな意思決定をスピーディーに行え、意思決定の粒度を小さくすることにより、全体としての開発スピードを上げていくことが可能になります。

プロダクトの開発において、失敗の計測・検知をできるポイントは多々あります。

上述のコードレベルでの失敗検知としてのTDD。プロダクトの開発サイクルにおけるKPT等々たくさんありますが、今回はその中でもユーザーの行動の計測・可視化のための収集基盤について書きたいと思います。

ログの収集基盤

弊社はWebのAPIにはRailsを使うことが多いが、ユーザーの行動履歴をAPIのログベースで収集している。これも1年ぐらいから前ようやく取り組み始めた試みで、最近少しづつワークしてきている。

ざっくり書くとLTSV形式で必要なAPIが叩かれた際に必要な情報をlogファイルに書き込む。ここでいきなり具体的なコードになるのだが、下記のようなコードをRailsに仕込んでいる。

module LtsvLogger
 extend ActiveSupport::Concern

 LOG_FILE_PATH = "LOG_FILE_PATH"

 private

 def data_analysis_log
   log_base = [].tap do |arr|
     arr << "Datetime:#{Time.zone.now.to_i}#{format('%03d', (Time.zone.now.usec / 1000).round)}"
     arr << "ServerName:#{request.host}"
     arr << "IPAddress:#{request.remote_ip}"
     arr << "UserID:#{....}"
     arr << "Locale:#{I18n.locale}"
     arr << "Path:#{request.fullpath}"
   end

   (@data_analysis_option || [nil]).each do |option|
     log = log_base
     if option
       par = option.map { |k, v| "#{k}:#{v}" }
       log += [par]
     end
     log = log.join("\t") + "\n"

     save_log_file(log, LOG_FILE_PATH)
   end
 end

 def data_analysis_option(value)
   @data_analysis_option = [] if @data_analysis_option.nil?
   @data_analysis_option << value
 end

 def save_log_file(text, file_path)
   logger = Logger.new(file_path)
   logger.formatter = proc { |severity, datetime, progname, message| message }
   logger.info(text)
 end
end

これをEmbulkに食わせて、DBに格納、顧客情報と突合するという基盤化しています。

※弊社のデータアナリスト作成のデータ基盤フロー図

この基盤で取得したデータをSalesforceなどのデータと連携させ、ユーザーの行動履歴とNPSなどの相関性を見ていくことというのが可能になっていきます。ここはまだ弊社の中でもやれてないことが多い + 常に改善改良してくポイントです。

最後に

THE 宣伝ですが、真面目な話とご飯の話を混ぜながらnoteを更新してくので良かったらフォローしてください。

Twitterもぜひ！ https://twitter.com/hisatake

前回の記事はこちら。