実現したこと、やめたこと。 株式会社ベーシック 唐澤 1.5年も紆余曲折した アクセス解析システムの作り直し。

今日は 僕の体験からの学びの共有と 現場のリアルを感じてもらえたら プロダクトの将来のためにエンジニアだからできること それを非エンジニアに理解してもらうこと 妥協せず理想のシステムを追うこと 目的の見極めが大事

題材 ferret One の レポート数値が合わない問題の解決

ferret One について

© 2022 Basic inc. BtoBマーケするなら ferret One とは 5 オールインワンマーケティングツールの提供と マーケティング実行支援サポートをセットで行っています 簡単に操作できる環境 運用サポート ツール ノウハウ

© 2022 Basic inc. BtoBマーケするなら ferret One = オールインワンマーケティングツール BtoBのリード獲得に必要な機能がそろった
 マーケティングツールです
 6

No content

© 2022 Basic inc. BtoBマーケするなら LPも作り放題 ferret Oneは記事コンテンツの更新だけでなく、LPも作成可能で す。複製も簡単なので、できあがったLPをベースに、ターゲット別・ キーワード別・ユースケース別など、様々なLPを展開し、どんどん テストも回すことができます。
 フォーム・CTA設置 ブログ機能 資料ダウンロード機能 項目を選択するだけで、制作したページに簡単にフォーム やCTA（申込などのボタン）を設置できます。
 
 コンテンツマーケティングに欠かせないブログ機能。 WordPressからのインポートも可能で、既存のコンテンツ記 事も有効活用できます。
 アクセス解析はもちろん、SEO順位チェック機能やSNSとの 連携投稿もできます。
 PDFファイルをアップロードすることで、ユーザーが資 料ダウンロードできるページも簡単に作成できます。 フォームと組み合わせることで、ホワイトペーパー施策 などのマーケティングに活用できます。
 ダッシュボード お問い合わせ管理機能 ユーザー行動履歴 シンプルな画面でWebサイトの重要指標が一目で 確認できます。目標に対しての進捗を素早く把 握。わかりやすいUIでセールスチームや経営陣と もWebサイトの状況が共有しやすくなります。
 コンバージョンしたユーザーのステータスがすぐに わかるボード型の管理画面で顧客の状態を一元 管理。対応状況をマーケター、CS担当、営業担 当、誰でも把握できます。
 Web上でのユーザー行動が確認できます。
 ユーザーが何を経由してこのページに辿りついたの か？ どのページを見てコンバージョンしたのか？な どユーザーの思考を考察し、施策のヒントになりま す。
 メールマーケ機能 SEO順位チェックツール セグメントメールで特定のユーザーにメールを送ったり、ス テップメールでタイムリーに配信することも可能。
 HTMLメールも見たまま編集で作成できます。
 ※ステップメールはスタンダードプラン 、
 　またはオプション機能となります
 ※カンバン形式からのメール配信機能は全プラン共通
 一定期間のSEO順位の変化、
 キーワードごとの順位、
 前日からのアップ・ダウン、
 直近の動きのグラフなども確認できます。
 自動メモ機能 行った施策をメモできる機能はもちろん
 新規ページを追加すると、その履歴が
 自動で記録され、アクセスの変化と
 付け合わせて考察することができます。
 その他マーケティング機能（リード獲得〜育成まで） 8

No content

No content

No content

16コの軸

問題 レポート数値が合わない

対応 アクセス解析システム & レポート の作り直し

CS の人 < お客様からお問い合わせが来てます < レポートの数値がおかしいそうで、こちらで再現できました 再現して確認しますねー > 僕が ferret One チームにアサインされたある日のこと （ ……確かにおかしい上にやばそうな臭いがプンプンするぜ 🙁）

何が起きていたのか

● 使われない機能がある ● なぜあるのかわからない機能がある ● レポートの数値が合わない 起きていたこと - プロダクト機能面

例1: レポート絞り込み ● なし PV: 5,000 ● あり PV: 5,200 条件をきつくしてるのに、数値が増える？！ 数値が合わない

例2: レポート集計軸 ● デバイス別 PV: 5,000 ● 流入元別 PV: 5,200 同じ数字を見ているのに、集計軸によって数値が違う 数値が合わない

コンバージョン（CV） ● ユーザーが何かのアクションをすること ● サイトにおいて目標到達になる行動のこと 例： ● ECサイトの商品購入 ● メディアサイトのメルマガ登録 用語補足

例3: ● お問い合わせ数: 30 ● CV 数: 28 とか ● お問い合わせ数: 50 ● CV 数: 51 数値が合わない

● レガシーコード ● スパゲッティコード ● ふくざつなシステム 起きていたこと - 実装面

● レガシーコード ○ テストがない ● スパゲッティコード ○ 命名が統一されてない ○ 責務が適切じゃない ● ふくざつなシステム ○ クラスとクラスの関係がパッとわからない ○ AWS のいろんなサービスを使ってる 起きていたこと - 実装面

どうしてこうなったのか

当時の関係者じゃないので予想ですが... 1. 度重なるピボット とにかく PMF するぞ！！！ 2. 機能追加して出すことが正義 営業が機能をアピールして契約を取る 3. 新卒＆オフショアメインの開発体制 監督者、中堅以上エンジニアが不足していた

その後の組織改編で人・組織の問題は一定解決したが、、、 当時を知る人は減っていき ● ターゲットを見失った機能たち ● 技術的負債 が取り残された説 そして顕在化した問題の一つが・・・

レポート数値が合わない

そしてゴングが鳴らされる CTO < ぺっぱー、ferret One よろしく システムのリニューアルですね！ 任せてください！ > ということで...

「趣味リニューアル」と会社の飲み友達にいじられるほど ゼロから積み上げる経験をしてきた彼（僕）は その全てを携えて ferret One に立ち向かうことを決意しました これが 2019年11月の出来事

アクセス解析システム / レポート の組み直したこと

1. 機能の整理 2. システムの作り直し 組み直したこと

1. 機能の整理 a. 削除、適切な形に変える 2. システムの作り直し a. 既存のリプレイス 組み直したこと

機能の整理

詳細レポート - OSバージョン別レポート < OS のバージョンを気にしている人いるのかなぁ そうなんですか？ GA にもありますし必要では？ > < toB のマーケティングでどう役に立てるのかな？ Windows 10 か 11 かでアプローチを変えることあるのか 確かに... > なんなら PC か SP かくらいでも十分そうですよね

CS チームにヒアリング、使用状況を確認する → 全然使われてないことがわかった → 削除 他の細かいレポートも同じく 5ページくらい削除 詳細レポート - OSバージョン別レポート

コンバージョン < 何それ？！お問い合わせ以外にあるの？！ コンバージョンモデルに 4パターンのデータがあるんですけど、知って ました？ > クリックと、重要ページと、外部フォームってのが あるみたいです > < それってコンバージョンって言えるの？

コンバージョン 1. お問い合わせ 2. クリックイベント 3. 重要ページビュー 4. 外部フォーム計測 2~4 ってコンバージョンなの？ そもそも ferret One におけるコンバージョンって何？

コンバージョン is 何？ fO は「見込み顧客を獲得するためのツール」なので 1. お問い合わせ 2. クリックイベント 3. 重要ページビュー 4. 外部フォーム計測 < だよね？ そうですよね >

CS にヒアリング ● 使用状況 ● どんな使われ方をしているのか ● なくなる場合の影響 コンバージョン

1. お問い合わせ 2. クリックイベント → 切り出し　効果測定に使っている 3. 重要ページビュー → 削除　　　存在が不明。副作用を使う 4. 外部フォーム計測 → 別機能　　fO に情報が残らない 使われている機能だったが、存在理由がわからない物たち 紐解いていくと「『コンバージョン』ではないね」 コンバージョン

システムの作り直し

元のシステム ストリームで解析して 指標ごとにインクリメント

ログを溜めてバッチで解析、 全体を集計する 新しいシステム

スッキリ & データがずれない

2021.07 リリース

その過程でのすったもんだ

1. リファクタリングの必要性 2. 機能を整える必要性 3. 目的を見極める 4. 実装を妥協しない 5. 開発体質の改善 過程の話

リファクタの必要性

エンジニアにしかシステムの状態はわからない このままだと老い先短い状態だと理解してもらう 「レポートがおかしい」に対して、リファクタ提案 ● その場しのぎでは無理 ● 状態の数字出し ● コードの状態を図示 ● 原因のプロット リファクタが必要だということ

数字を集めて突き合わせると... ● CV数が実 CV の 92% しかない ● アクセスログと集計データを突合すると 76% しか合わない 状態数字

クラスの依存関係を洗い出し 一目で悲惨な状態がわかる コードの状態

システムがこんな感じ こんな流れで、 要所要所でこんな問題がある 虫食い状態を可視化 原因のプロット

リファクタが必要だけども・・・ ● 正直、どのくらいかかるかも今の段階ではわからない ● 調査含め進めながらスケジュールを引いて行きたい 横暴・・・でも理解してもらえた 理解してもらうために

愚直にシステムの状態を理解して、わかりやすい形にしていく なんで俺が・・・ コードも書けずに・・・・と泣いた夜もありました（ない とにかく愚直にコードを読みました 理解してもらうために

こんな感じでシートに grep 結果を書き溜めてました ちなみに

機能を整えること

プロダクトへの思想がぶれていた。世界が崩壊してた ● ピボット前の機能が残ってカオス ○ 今のターゲットには不要 ○ 副作用だけ必要 ● 消せない理由 ○ 開発リソース ○ 解約リスク 数%のために大多数が幸せになれない → 緩やかな死 機能を整理してみてわかったこと

さっきの例は結構省略しましたがw めちゃめちゃ議論しました プロダクトを良くしたい気持ちはみんな同じはず PM, CS, エンジニアなど関係者の認識を合わせていく 他者のやりたくないことも理解して一緒に考える 作るだけじゃなくて消すことも大事 機能を整えること

目的を見極める

既存コードをリファクタしようとしていた 当初の計画

No content

● テストコードはないし ● 原因っぽいものはあるし ○ コンバージョンモデルへのクエリで条件が抜けてる...? ○ 到達するレコードが時系列で前後するとバグるっぽい ○ スレッドセーフじゃない...? ● スパゲッティだし 当初の計画

● テストコードはないし ● 原因っぽいものはあるし ○ コンバージョンモデルへのクエリで条件が抜けてる...? ○ 到達するレコードが時系列で前後するとバグるっぽい ○ スレッドセーフじゃない...? ● スパゲッティだし コードを整えないと理解が無理だ... 当初の計画

「ぺっぱー最近何やってるのー？」 「レポートの数値がおかしいのでリファクタやってて」 「かくかくしかじか」 「面白そうだねー。話聞かせてよ」 「そ、それは....正しくなるはずです...!!」 「そっかー。でもそれでレポートの数値は正しくなるのかい？」 「結局ぺっぱーの敵は誰なんだい？」 「本当かなー？」 「え、だから、スパゲッティをリファクタしたいんです！」 「そもそも何をやりたいんだっけ？リファクタするのが目的なんだっけ？」 「どうなったら『正しい』と言えるんだい？」 < > 「ぐぬぬ...」

「ぺっぱー最近何やってるのー？」 「レポートの数値がおかしいのでリファクタやってて」 「かくかくしかじか」 「面白そうだねー。話聞かせてよ」 「そ、それは....正しくなるはずです...!!」 「そっかー。でもそれでレポートの数値は正しくなるのかい？」 「結局ぺっぱーの敵は誰なんだい？」 「本当かなー？」 「え、だから、スパゲッティをリファクタしたいんです！」 「そもそも何をやりたいんだっけ？リファクタするのが目的なんだっけ？」 「どうなったら『正しい』と言えるんだい？」 < > 「ぐぬぬ...」 気づけば 手段が目的に...!

どんな状態が理想なのか、思いを馳せる ● レポートでは CV 数が正しいことが一番大事 → ユーザーの売上に直結する数字だから ● 「 ferret One における CV 」は何？ → お問い合わせ 「お問い合わせ = CV 」の状況を作るべき 「 CV が 4種類」の仕様を変える → さっきの話 戦略を練り直す

それをやることで何を実現したいのかを考える 見切り発車しない 目的を見極める

実装を妥協しない

計画 v1 ● 既存のリファクタ ○ 解析・集計 ○ レポートクエリ ● マイクロサービス ● React & GraphQL 計画の変遷

計画 v1 ● 既存のリファクタ ● マイクロサービス ● React & GraphQL 計画の変遷

計画 v2 ● 追加リファクタ New ● DynamoDB の見直し New ● 既存のリファクタ ● マイクロサービス ● React & GraphQL 計画の変遷

お問い合わせを CV に変換してあげれば良い リファクタしてその変換処理を突っ込めばいい！ > ここで「お問い合わせ = CV 」にする話

「今のストリームとバッチで回すのがベストな方法なんだっけ？」 「やっぱり集計スクリプトを直せばいいですよね？」 < > 「ビッグデータの一般的な手法を知りたいよね？」 うーん。。。（時間がない ... > 確かに。調べてみますね > < 違うとしても、それをわかった上で実装するのとまた違うよね

以前：完全増分アーキテクチャ → 実は一般的な問題がたくさんあった さらに一般的なプラクティスにも従えてない 　保存場所：データレイク、DWH、データマート 　保存方法：ファクトテーブル、スタースキーマ... バッドプラクティスの盛り合わせ → 待つのは緩やかな死 ベストの方法を探す旅 アーキテクチャから変えましょう >

計画 v3 ● 追加リファクタ ● DynamoDB の見直し ● 既存のリファクタ ● マイクロサービス ● 解析作り直し New ● DB クエリを SQL New ● React & GraphQL 計画の変遷

● ストリーム？バッチ？ ● DWH のスキーマ ● バッチの管理は？ ● マイクロサービス 今の仕様を再現しつつも、 最適解はなんなのか v3 の議論

喧々諤々

ひたすら議論してベストを突き詰められた 貴重な経験 ● スケジュールを気にして解決策を探しがち ● 立ち止まって周りを見回すと、結果早いこともある （元の計画だとスケジュール内に終わらなかったと思う） 実装を妥協しない

開発体質の改善

● PR の説明が真っ白 ● 1PR が巨大 ● 指摘・議論の形跡もない という状態なので ● ノールックでマージしてたんじゃ...? ● 経緯・背景がわからないので、資産になってない もともとの PR / コードレビュー

ひたすら Request Changes ● PR のテンプレ作って、必ず書きましょう ● PR は細かく分けましょう ● テストコード書きましょう ● Linter 入れたので従いましょう ● こっちの設計がいいと思う 全部の PR をレビューした 1ヶ月間 体質改善 > > > > >

時系列的には一番最初にやった取り組み 水際対策 自分のところが整っても、別ラインの開発で負債が作られる 体質改善

ということで

リニューアルに立ち向かった彼だった。放つパンチの感触は気のせいで、気づ けば目隠しでリングの外に立っていた。 しかし、仲間の助言でリングに戻り、 理解と協力でワンツーコンビネーションを決めたのでした。 めでたしめでたし...?

まとめ

● 良く見たらリニューアルじゃなかった ● ただ作り直す以上のやり方がある ● プロダクトの根幹から理解して向き合うの大事 ● 理解と協力してくれた仲間・会社に感謝 まとめ

ありがとうございました