株式会社シイエヌエス北海道
本業
事業内容 | アプリケーション開発・インフラ構築事業、クラウド構築事業、データ分析・AI事業、DX支援事業 |
資本金 | 2500万円 |
売上高 | 7億5,351万円 |
従業員数 | 39名 |
上場/非上場 | 非上場 |
勤務地 | 北海道札幌市 週に約4回リモートワーク実施 |
雇用形態 | 正社員 |
所属 | [2022/04 - 2024/03] デジタルビジネス推進部 |
以下、最終更新順にプロジェクトを記載しております。
- [データ] データエンジニアとしての業務
- [ML] MLOps エンジニアとしての業務
- [その他] その他業務
1. [ML] 情報通信企業向け 機械学習ワークフローと AI プラットフォーム移管
1.1. 概要
- DataRobot 中心で構築していた機械学習ワークフローから Snowpark ML (Snowflake) 中心の構築への移管
1.2. 期間
- [2023/12 - 2024/01] Snowpark ML 事前検証
- [2024/02 - 2024/03] 追加調査・ワークフロー設計
1.3. 規模・役割
- [2023/12 - 2024/01]
- 役割:メンバー
- 規模:1名 (私)
- [2024/02 - 2024/03]
- 役割:リーダー
- 規模:2名
- 自社の若手2名
1.4. 担当業務
- [2023/12 - 2024/01] (私1名) Snowpark ML の事前検証
- [2024/02 - 2024/03] (2名) DataRobot から Snowpark ML への移管のための追加調査
- [2024/03] (私1名) ワークフロー設計
1.5. 機能開発・実装詳細
移管前後の構築詳細は以下の通りです。
- 移管前構築 (AWS MWAA + ECS + DataRobot + Snowflake)
- MWAA にてワークフロー管理を行っており DAG ファイルにてジョブを定義し並列処理や直列処理を記述していました。
- MWAA KubernetesPodOperator にて利用する ECS イメージを JupyterHub (ノートブック実行環境) でも共有していたため本番と開発でライブラリ依存関係の齟齬がない環境でした。
- AI プラットフォームとして DataRobot を採用し、ハイパーパラメータチューニングやモデル評価を全てフルマネージドで実施させていました。ただしコストが嵩む問題がありました。
- 移管後構築 (AWS SageMaker + Snowpark ML + Snowflake)
- AI プラットフォームとして Snowpark ML を採用することとしました。使用感は scikit-learn に近く、ラベルエンコーディング・ハイパーパラメータチューニング・モデル評価を自力で実装する必要があります。
- ワークフローは “SageMaker + Papermill” でノートブック上での管理となります。
- モデルはモデルレジストリ機能にて管理させます。
- 他部署 (他の環境) とも共有できるように素朴な実装を目指しました。
1.6. 目的・背景
- コスト上の問題から DataRobot の利用を2024年8月に停止するという判断を受けて AI プラットフォームの移行先を探す必要がありました。
1.7. 課題
- 移行業務は付加価値を生みづらい都合で移行先調査の優先順位が低くなってしまい、分析基盤管理側の社員も移行先調査がほとんど実施できていない状況でした。
- Snowpark ML は新しいサービスのため公式ドキュメント以外で参照出来る情報が社内外ともにかなり限られている状況でした。
1.8. 工夫した点
- 調査作業での工夫点
- 後から続く方が参照しやすいように調査記録を丁寧に取りました。
- Snowflake 公式のリポジトリに置かれているサンプルコードや公式ドキュメント・公式ライブラリソースコードのどの部分を参照したか記録に残しました。
- 調査記録を客先社内公開済み。
- 必要最低限の領域までの調査に留めることで、スケジュールや実装方針について予定より早く合意を取ることができました。
- 関係者が多くなるため情報提供をいち早く行うことを優先しました。
- 後から続く方が参照しやすいように調査記録を丁寧に取りました。
1.9. 成果
- Snowpark ML の利用は前例が少なかったため Snowflake 社からの個別開示情報などを利用して情報収集と事前検証を行ないました。結果、既存ワークフローに比べてコスト・性能面・セキュリティ面で優位性があることを示し、客先での先行事例を作ることができました。
- 価値を生みづらいと見込まれていた移管作業の意義を示したため、注目度を上げ、周囲を巻き込むことに成功しました。客先での社内政治的にも Snowpark ML 導入推進の話を通しやすくなる状況作りに貢献しました。
- 本プロジェクトではリーダーとして技術調査・スケジュール策定・チームへの作業指示・顧客他部署への情報共有など多様な役割を担うことができました。
1.10. 担当フェーズ
- 要件分析
- 基本設計
- 詳細設計
- 開発
- テスト
1.11. 開発環境
- AWS
- SageMaker
- CodeCommit
- Secrets Manager
- SQL
- Snowflake
- Python 実行環境
- SageMaker (conda_python3)
- AI プラットフォーム
- Snowpark ML
2. [データ] 情報通信企業向け データマート整備
2.1. 概要
顧客情報と紐付けて分析や機械学習に利用するための下記特徴量の作成
- ポイントサービス加盟店と顧客推定住所との距離
- ポイントサービス詳細情報
- 決済情報
- 様々な特徴量を次元圧縮して生成する特徴量
- 行動履歴からルールベースで推定されたライブイベント実績
2.2. 期間
- [2023/04 - 2023/05] ポイントサービス加盟店と顧客推定住所との距離
- [2023/06 - 2023/07] 決済情報
- [2023/08 - 2023/09] 行動履歴からルールベースで推定されたライフイベント実績
- [2023/10 - 2023/12] 様々な特徴量を次元圧縮して生成する特徴量
- [2024/01 - 2024/03] ポイントサービス詳細情報
2.3. 規模・役割
- 役割:サブリーダー
- 規模:4名
2.4. 担当業務
- (主に私1名) データ作成月次作業向けワークフロー構築
- (4名) データレイク調査
- (4名) データ抽出クエリ作成
- (リーダーと私の2名) レビュー
- (4名) 検証
- (4名) 保守
- (4名) 月次運用作業
2.5. 機能開発・実装詳細
データマート構成のためのクエリは Juupyter Notebook 上から Python API 経由で実行していましたが、2023年秋頃から dbt Core を導入し SQL ファイルベースへ置き替えつつある状況でした。
- [旧環境] Snowflake の Python API 利用 (Jupyter Notebook にて管理)
- Snowflake Python API を Jupyter Notebook から実行します。
- ファイル数が増えたりコード量が増えるとコードの見通しが悪くなりやすい欠点があります。
- ワークフローは MWAA にて構築しています。
- Snowflake Python API を Jupyter Notebook から実行します。
- [新環境] dbt Core 利用 (SQL ファイルベース)
- dbt Core により SQL ファイル主体で管理を行います。
- 入出力の依存関係が明示され管理が容易になります。
- CI/CD、自動テスト、自動ドキュメント生成など現代的な開発・運用が可能となります。
- 必要に応じて増分データのみを対象とするクエリに変更できます。
- dbt Core により SQL ファイル主体で管理を行います。
2.6. 目的・背景
- データレイクは充実しているものの、機械学習や顧客情報分析に利用できるデータマートは発展途上のため適宜追加していく必要がありました。
2.7. 課題
- 分析に利用できる特徴量が不足している状況でした。
- 従来作成していた特徴量が上流データの仕様変更や不具合によって作ることができない場合がありました。
- Jupyter Notebook で管理しているデータマート向けプログラムが長大なため不具合発生時の原因究明に時間が掛かることが多くありました。
- 上流データが全て揃ったタイミングでデータマートの月次更新を行っておりましたが、一部情報をできるだけ早く更新してほしいと言われるようになりました。
2.8. 工夫した点
- 分析に利用できる特徴量が不足している状況でした。
- 従来作成していた特徴量が上流データの仕様変更や不具合によって作ることができない場合がありました。
- ユーザーアンケートにより整備すべきデータを決定し、より必要とされるデータマートを目指しました。
- できるだけ早くデータを提供できるような上流データを選定しつつ、上流データの障害発生率を調査し取捨選択を行いました。信頼性の高いデータマート運用のために設計時に十分考慮を行いました。
- Jupyter Notebook で管理しているデータマート向けプログラムが長大なため不具合発生時の原因究明に時間が掛かることが多くありました。
- 上流データが全て揃ったタイミングでデータマートの月次更新を行っておりましたが、一部情報をできるだけ早く更新してほしいと言われるようになりました。
- いずれも解消できるポテンシャルをもつ dbt に移行することとしました。
2.9. 成果
- ユーザー目線での改善を続けたことでデータマートのアクセス数増加につながり、部内の大きな成果として表彰を受けました。
- 自チーム・他チームともに顧客行動予測を行っており、そのために必要な特徴量を自力で作成し社内の多様なモデルの精度向上に貢献できました。
- dbt 移行を推進することでソースコードを SELECT 文中心の理解しやすいものに置き換えることができました。
- 上流データが追加されたタイミングで必要に応じてデータ作成処理を行える (セマンティックレイヤ対応ができる) ように dbt 環境に移行を順次進めることができています。
- セマンティックレイヤ対応は dbt Core では非対応のため dbt Cloud 導入時の対応となります。
2.10. 担当フェーズ
- 要件分析
- 基本設計
- 詳細設計
- 開発
- テスト
- 運用
- 保守
2.11. 開発環境
- AWS
- CodeCommit
- Cloud9
- Secrets Manager
- SageMaker
- MWAA
- EKS
- ECS
- SQL
- Snowflake
- dbt
- Python 実行環境
- SageMaker (conda_python3)
- JupyterHub (conda_python3)
3. [ML] 情報通信企業向け 機械学習ワークフローのクラウドシフト
3.1. 概要
- オンプレ基盤で実施していた顧客行動予測モデル作成 (50モデル分) ワークフローのクラウドシフト
3.2. 期間
- [2022/07 - 2022/10] 28モデル分
- [2022/11 - 2023/03] 22モデル分
3.3. 規模・役割
- 規模:4名
- 役割:メンバー
3.4. 担当業務
- (私1名) ワークフロー設計・実装
- (私1名) 各ジョブ設計
- (4名) 各ジョブ実装
- (4名) 上流データ調査
- (4名) 機械学習用データ作成クエリの再構成
- (4名) 検証
- (4名) 保守
3.5. 機能開発・実装詳細
MWAA (Airflow) + EKS + Kubernetes + Papermill な Python 実行環境が構築済みのため以下の要領で実装を行いました。
- MWAA ワークフローを設計し DAG ファイルとして実装
- 大まかにはモデル共通処理を実行した後、モデル固有の処理を並列で実行する流れです。
- Snowflake Python API と DataRobot API を実行する Python コード (Jupyter Notebook) を各ジョブの設計内容に応じて作成
- 機械学習用データ作成・モデリング・スコアリング・モデル評価指標取得などの処理を実装します。
3.6. 目的・背景
- 従来の基盤の廃止に伴い AWS 基盤にて機械学習ワークフローを構築する必要がありました。
3.7. 課題
- 上流データは仕様が変わりつつ移行済みだったため、従来基盤で利用していたクエリと同等のものを作るには調査・検証の時間を大きく取る必要がありました。
- MWAA と DataRobot に関するノウハウがチーム内になく、自力で調査をしつつ基盤担当者から情報提供を受けながら取り組む必要がありました。
3.8. 工夫した点
- MWAA (Airflow) + EKS + Kubernetes + Papermill の構成で並列処理に強いことを利用し、並列処理を最大限活用できるようにジョブの粒度を調整しました。
- 移行対象のクエリの量が膨大かつ移行先上流データがどれか分からない状況だったため、初期調査段階では件数比較を活用しある程度当たりを付ける方法で効率的に設計を進めました。
- 最終的にはレコードの一致率確認を行っていますが、初めから一致率確認をしていると時間が足りなかったと思われます。
- MWAA による機械学習ワークフロー構築時に従来手動で実施していた検証処理も含め、最終的に Slack 通知確認で完了するように作業を簡素化することで単純な移行ではなく価値を生むことを意識しました。
3.9. 成果
- 従来と同等のワークフローを維持しつつ、自動化と時短の工夫を入れることで大幅に運用工数を減らすことができました。
3.10. 担当フェーズ
- 要件分析
- 基本設計
- 詳細設計
- 開発
- テスト
- 保守
- 運用
3.11. 開発環境
- AWS
- SageMaker
- CodeCommit
- Secrets Manager
- MWAA
- EKS
- ECS
- SQL
- Snowflake
- Python 実行環境
- SageMaker (conda_python3)
- JupyterHub (conda_python3)
- AI プラットフォーム
- DataRobot
4. [ML] 小売企業向け 客数予測処理実行環境構築
4.1. 概要
- オンプレ基盤で実施していた客数予測処理の AWS 環境移行
4.2. 期間
- 2022/05 - 2022/06
4.3. 規模・役割
- 1名
- メンバー
4.4. 担当業務
- 予測処理実行環境構築 (EC2, Python)
- 環境変更に伴う Python コード修正・スクリプト作成
- 予測処理実行手順構築
4.5. 機能開発・実装詳細
- EC2 に Anaconda をインストールしベイズ統計モデル作成環境を構築します。
- 顧客の要求により客数予測に費せる日数が4日程度のためその範囲内で十分終了するよう処理の並列化を行います。
4.6. 目的・背景
- (前提) PoC として1店舗毎にベイズ統計モデルで客数予測を行うプログラムが作成されており、客数予測処理は1店舗あたり4時間程度かかる状況でした。
- その上で4日程度で約200店舗分の客数予測を出す環境構築を求められていました。
- インスタンス性能を上げるための AWS 移行となります。
4.7. 課題
- 要求を満たすためには EC2 高性能インスタンスを利用する必要がありコストは最小限とする必要がありました。
- 前任者の作成した並列処理に問題があり総実行時間が長くなってしまいまう。
- 経験の浅い作業者に運用を直ちに引き継ぐことになっていたため、手動実行するプロセスを挟むと不具合や遅延が想定されました。
4.8. 工夫した点
- 前任者の作成していた並列処理は先にコア数に基づきジョブを分割する形式のシェルスクリプトで構成していましたが、各店舗毎にデータ量が異なるため予測処理が早めに終了して遊びの出るコアが発生してしまっていました。
- 改善のため xargs に並列処理を管理させることで空きコアに逐次ジョブを実行させる構成に改善させ総実行時間を短縮させることができました。
4.9. 成果
- 当初の構成に比べて総実行時間を短縮することができ EC2 インスタンス利用時間の削減に成功しました。
- 総実行時間は2日程度に抑えることができ、顧客要求を満たすことができました。
- 利用可能なリソースが EC2 のみという制約の中、スクリプトを活用し極力自動化し引継ぎ後の業務負荷を軽減させました。
4.10. 担当フェーズ
- 要件分析
- 基本設計
- 詳細設計
- 開発
- テスト
- 保守
4.11. 開発環境
- AWS
- EC2
- SQL
- PostgreSQL
- Git
- Python 実行環境
- Python (公式)
- Anaconda
- シェルスクリプト
5. [その他] プロジェクト以外の業務
5.1. 新卒採用一次選考の面接官対応
- 2024年新卒採用:学生6名分
- 2025年新卒採用:学生6名分
5.2. データ分析業務担当者育成
- 育成用プログラム進捗管理 (2023/06 - 2023/12)
- 利用教材:データサイエンス100本ノック
- 育成対象者:7名 (2023年度)
- 業務:環境構築手順作成・質疑応答対応・作業進捗管理 (すべて私1名で対応)
- ローカル上の環境構築手順の共有 (随時)
- 社内 Wiki にて記事作成
- 具体例
- Amazon Linux (EC2) + Anaconda + PyStan 環境構築
- Windows + Anaconda + PyStan 環境構築
- Ubuntu (WSL2) + Docker (Dockerfile) + CPython + venv 環境構築
- Ubuntu (WSL2) + Docker 環境構築 (データサイエンス100本ノック向け)
- Amazon Linux (Cloud9) + pyenv 環境構築
- VSCode と Vim での Linter Formatter 導入方法
- データ分析関連技術情報共有 (随時)
- ニュースサイト・技術ブログ・技術コミュニティにて情報収集し、社内チャットにて随時共有