ID:72381さん

# プロジェクト概要 社内の分析プロジェクトにおいて、以下の課題が発生している。 1. コーディングやファイル管理方法がチームごとに大きく異なることにより、無駄なキャッチアップコストの増加やコードの保守性および再利用性が低下している。 2. プロジェクトで培ったノウハウが広がらず車輪の再発明が生じている。 これらの課題に対し、以下のアプローチを行うことで解消を行う。 1. 社内専用の機械学習パイプラインフレームワークを開発し、コーディングのインターフェース統一を行うことで無駄なコストを削減し全社の生産性向上を行う。 2. 開発したフレームワークにて、チームごとの独自メソッドを吸収・再配布することでノウハウのサイロ化を防ぎ、知見の展開サイクルを作成する。 ## 担当フェーズ - 仕様策定 - 設計 - 開発 - テスト - リリース - 運用 ## 開発環境 - Python、Kedro、Apache Spark、pytest、Gitlab ## OS - Ubuntu ## 開発方式 - スクラム ## 採用技術の背景詳細 Kedroというフレームワークを以下の理由で採用。これをベースに開発を行った。 1. データやパラメータを一つの特定のファイルで管理する。このファイルを見ることで確認ができるため人材流動が高い弊社においてはキャッチアップコストの削減につながると考えた。 2. 全社で利用されているSpark（大規模データを効率的に扱えるフレームワーク）をサポートしており非常に相性がいい。 ## 担当概要 現時点でのメンバー構成は以下の通り ・マネージャー：1名 ・開発メンバー：2名 て開発の主担当および新規 自身は開発メンバーの一員としメンバーの育成を実施している。 これまで担当してきた業務としては、設計・機能開発・展開に従事。クロスバリデーション機能開発・データ取得から特徴量マート作成を行うパイプライン構築・テスト、ユーザー向けドキュメント作成・テストコードのバグ調査を担当。各パートの詳細については別の項目に記載している。直近はv1.0.0として社内へリリースし、試験導入チームのフォローアップ・フィードバック収集、機能追加を担当中。 ## 分析環境更新に伴うソフトウェア内部アップデートおよびテストコードのバグ調査 ### 詳細 #### [ソフトウェア内部アップデートに伴うバックエンド改修] 分析環境のアップデートに伴い、開発しているパイプラインモジュールで利用しているPythonライブラリをアップデートする必要があったため、それらの更新を担当。利用していたKedroのバージョン変更が余儀なくされ、ライブラリアップデートだけでなく一部機能の改修を行う必要が生じた。改修を行うにあたらいライブラリの変更点を把握し、利用ユーザーへの後方互換性を失う変更がないかをまとめあげ・上長に共有。特段大きく影響を与えるものではなかったため、バックエンド改修を行い新しいバージョンとしてリリースを実施。リリース時には念のため変更があったことを利用者に周知した。 #### [テストコードのバグ調査] 上記のバックエンド改修後、それまで成功していたテストコードが失敗をするようになったため、原因の特定を調査した。調査の結果、SparkSessionをテストケースごとに停止・作成を行う際に、ケースごとに異なる設定値を渡すことができなくなっていることがわかった。 Sparkの仕組みや内部のJVM挙動を調査したが理想的な回避策が見つからなかったため、調査結果を上長に共有し暫定的な対応策の実施を提案。上記の実施策を実施後、他担当者も後から状況を追えるように解決できたこと・残課題をドキュメントにまとめた。 ## 技術選定：可視化ライブラリの選定 ### 課題 - 構築した機械学習パイプラインモジュールで利用する可視化ライブラリについて、特に理由がなく採用されているためあるべきを踏まえた選定になっていない ### 解決策・工夫点 - Pythonのライブラリを調査し、機能・コスト・信頼性の観点で情報を整理 - PySparkを用いたデータ分析におけるデータ可視化において、「Spark公式が推奨しているライブラリがあるか」「他企業が公開しているプラクティスがあるか」を調査 - 上記を踏まえたうえで各ライブラリの強み・弱みを整理し、メンバーでディスカッションを実施して選定を行う ### 成果 - 大量のデータを一度に描画するならmatplotlibを、インタラクティブな可視化を行うならplotlyを採用する方向になった。理由としてはplotlyを利用する場合、データ数が多すぎると動作が重くなってしまうというデメリットがあり、数千万単位のデータを扱うことが多いため、集計するユーザー数や集約値を用いるかどうかという点が重要な論点になったため。 ## 開発物のリリース・導入先支援 ### 担当フェーズ - 仕様策定 - 設計 - 開発 - テスト - リリース - 運用 ### 詳細 - 背景 　- 開発していた機械学習パイプラインモジュールにて、特徴量作成やモデル構築を担うパイプライン機能は作成されていたが、その前段階となるデータマートを構築するためのパイプラインの機能は当時は未実装だった。しかし、社内の分析状況を調査するにあたってマート構築を担う機能もあったほうがよいのではと議論を行い、このクラスの実装を行うことになった。 - 思考のプロセス 　- 機能開発時には仕様策定から、どのようなクラスとして持たせるべきかからまず考えた。マート構築とモデル構築はそれぞれ独立した機能として持たせたほうが保守性が高くユーザーも扱いやすいだろうと考え、異なるクラスとして設計を行った。機能の実装後にはpytestでテストコードを実装し頑健な機能の保持に貢献した。 ## データマート構築パイプラインの開発 ### 担当フェーズ - 仕様策定 - 設計 - 開発 - テスト - リリース - 運用 ### 詳細 - 背景 　- 開発していた機械学習パイプラインモジュールにて、特徴量作成やモデル構築を担うパイプライン機能は作成されていたが、その前段階となるデータマートを構築するためのパイプラインの機能は当時は未実装だった。しかし、社内の分析状況を調査するにあたってマート構築を担う機能もあったほうがよいのではと議論を行い、このクラスの実装を行うことになった。 - 思考のプロセス 　- 機能開発時には仕様策定から、どのようなクラスとして持たせるべきかからまず考えた。マート構築とモデル構築はそれぞれ独立した機能として持たせたほうが保守性が高くユーザーも扱いやすいだろうと考え、異なるクラスとして設計を行った。機能の実装後にはpytestでテストコードを実装し頑健な機能の保持に貢献した。 - 成果 - 関心の分離を徹底したコードの作成 ## 機械学習パイプラインモジュールの機能追加[クロスバリデーション] ### 担当フェーズ - 仕様策定 - 設計 - 開発 ### 詳細 - 背景 　- 2名チームの1担当者としてリーダーと共に設計・機能開発・展開に従事。機械学習モデルの構築において重要なデータ分割（クロスバリデーション）が未実装だったためその機能の追加を担当。クロスバリデーションを用いることで手持ちのデータから効率よく汎化性を高めることができるので必須の機能であることは上長も認識しており、開発を進めることとなった。 - 思考のプロセス - 機能開発時には仕様策定を行い、どのクラスに機能を持たせるべきかの定義から行い、どのコードを改修すべきかをまず決めたうえで上長と認識を統一してからコーディングに着手。開発時には命名や適切な型選定を行うことで保守性の向上に努めた。 - 成果 　- 最終的には機能としてリリースされ、今ではモデル構築における欠かせない機能の一つになっている。

# プロジェクト概要 旅行代理店にて売上や広告成績（クリック数・表示回数など）を可視化して意思決定を支援するダッシュボード作成。 ## 担当フェーズ - データ基盤設計 - 構築 - 運用保守 ## 業務内容 - 要件定義 - 実装（ワークフロー構築、SQLによるクレンジング、ダッシュボード作成） - 運用保守 ## 使用ツール - Treasure Data - BigQuery - Tableau Online ## 背景 - 別代理店が構築していたダッシュボードの移管としてプロジェクトが開始。構築環境を代理店が所有していたため、ダッシュボードの裏側で働いている詳細な処理が開示されないという状態でゼロから構築を行うこととなった。構築した代理店にの名寄せやデータ結合条件を問い合わせたものの返答がもらえず、この内容を解明しなければダッシュボードが再現できなかった。 - また、過去の広告マスタが廃棄されておりその時期の構築をいかにして行うかが課題だった。 ## 解決策・工夫 - 利用するデータの項目を洗い出し、結合可能な列・ユニークになる条件の仮説をたてて実行・妥当性を評価するというサイクルをまわし、条件の洗い出しを行った。 - ダッシュボードのから過去の広告マスタがもつべき値を抽出し、復元を実行した。 ## 成果 ブラックボックス状態での再現は非常に苦労したが、無事に構築・移管・改善提案活動を行うことができた。

## プロジェクト概要 アプリユーザーのLTVを機械学習によって予測し、広告配信へ活用してロイヤリティの高いユーザーを効率よく獲得する。 ## 担当フェーズ - 要件定義 - 提案折衝 - 開発 - 運用保守 ## 業務内容 - データクレンジング - 機械学習モデル作成 - ワークフロー作成 - データ運用保守 ## 使用ツール - SQL - Adjust - GCP (BigQuery, Vertex AI, Cloud Composer: Apache Airflow) - Google Analytics 4 ## 実績・取り組み ### 背景 2名のチームでリード担当としてプロジェクトが開始した。しかしデータクレンジング工程の途中でスタッフが別のプロジェクトにアサインされることとなったため、自身が主担当を務めることとした。 ### 課題 - モデルを構築後、広告配信を行うために予測結果をAPIリクエストする必要があったが、使用予定だったAPI (Google Ads API) が終了することが判明し、利用するAPIの変更および追加で必要なデータ取得が発生した。こちらについて顧客に対して期限の延長および追加データ取得依頼を説明し了承を得ることができた。 - Google Ads APIの後継としてMeasurement ProtocolというGA4を利用したアーキテクチャが必要になったが、これの利用方法についてドキュメント読み込みやGoogle本社へ問い合わせを行うことで実現可能性を調査し、無事再提示した期限内に配信開始を行うことができた。モデルの構築後は定期的に予測結果を広告媒体へ連携する必要があったため、Airflowを用いた自動化を行った。 ### 成果 配信成果としてはクライアントKPIであるROAS 13.5%を達成し、高いときには20%となった。また、配信後の分析にてアプリの月次売上が徐々に落ちてきていることに気が付いた。そこから課金者と非課金者の行動の違いを分析したところ、一部のイベントにて両者の間で差があることや、未継続のユーザーはインストールから早いタイミングで離脱していることが判明した。 そこで、クライアントに対して機械学習によって行動ログからユーザーの離脱を予測し、確率が高いユーザーに対してPush通知を送り復帰を促す施策が効果的だと推測して提案。クライアントからは「まさに最近抱えていた課題で、是非協力してほしい」と返答していただき、新しい案件につなげることができた。