ID:82138さん

【概要】 Azure Data Factory(ADF)を中心としたETL基盤の開発・保守運用を担当。 Azure SQL ServerからADLSへデータを集約し、SnowflakeにDWHを構築するデータ統合基盤を運用している。 外部システムのデータ統合要望に応じて、継続的にパイプライン開発・改修を実施。 【期間】 2023/06/21 ～ 現在 【チーム情報】 チームリーダー1名、担当4名 【役割】 担当領域の開発計画管理、ETL開発、ETL保守運用、DL/DWHの開発・保守運用 【使用技術】 Azure Data Factory / ADLS / Azure SQL Database(SQL Server) / Snowflake / Git / Azure Virtual Machine / Azure Functions 【開発・実装内容①】ADFによるETLパイプライン構築 【どのような機能の開発・実装か】 外部システムのデータをAzure SQL Serverから抽出し、ADLSへ格納後、SnowflakeへロードするETLパイプラインをADFで設計・実装。 新規データ統合要望に対して、1〜2か月に1システムのペースで追加開発を継続的に行った。 【課題・問題点】 データ統合対象が増えるにつれて、パイプライン数が増加し、運用負荷・障害対応負荷の増大が課題となっていた。 また、扱うデータ量も大きく、最大で1回あたり5000万レコードを処理する必要があり、性能面・安定稼働を意識した設計が求められた。 【打ち手・使用した技術】 ADFのパイプライン設計において、スケジュール管理・依存関係を考慮しつつ、運用を前提とした実装を行った。 障害発生時の調査・復旧が容易になるよう、処理単位の分割やログ確認しやすい構成を意識して構築した。 また、Gitを用いてソース管理を行い、レビューを通して品質を担保した。 【成果】 1日100本以上稼働するETL基盤を安定運用し、エラー発生は月1〜2回程度に抑えた。 継続的なデータ統合要望に対しても、安定したペースで新規パイプラインの追加を実現した。 【開発・実装内容②】ADLSを中心としたデータレイク運用 【どのような機能の開発・実装か】 抽出したデータをADLS上に格納し、後続のDWH処理やデータ利活用に繋げるデータレイク領域の設計・運用を担当。 【課題・問題点】 データ量・連携対象が増加する中で、格納ルールが曖昧になるとデータ探索性が落ち、利活用が進まないリスクがあった。 【打ち手・使用した技術】 フォルダ構成やデータ格納方式を意識し、後続処理・運用負荷を考慮したデータレイク設計を行った。 【成果】 データ統合案件を継続的に追加できる基盤構造を維持し、データレイクの拡張性を担保した。 【開発・実装内容③】SnowflakeでのDWH開発・運用 【どのような機能の開発・実装か】 ADLSに格納したデータをSnowflakeにロードし、DWHとして利用可能な形に整備。 テーブル作成、データロード処理、保守運用を担当。 【課題・問題点】 複数システムの統合が進むにつれて、テーブル数・処理数が増加し、データ品質担保や運用管理が重要になった。 【打ち手・使用した技術】 DWHとして継続利用できるよう、テーブル設計やロード処理を運用前提で実装し、障害時の調査・復旧を意識した構成を採用した。 【成果】 Snowflake上で継続的にデータ統合を実施し、社内での分析・活用に繋がるDWH基盤を維持した。

【概要】 既存DWHの機能向上を目的として、Azure Synapse Analytics / Snowflake / Azure Databricks / Microsoft Fabric を対象に製品比較・検証を実施。 想定データ量10GB（約1億レコード）規模での利用を前提に、性能・コストパフォーマンス・保守運用工数の観点から調査を行い、DWH基盤の方針決定に向けた報告を担当した。 【期間】 2024/09/20 ～ 2024/12/21 【チーム情報】 チームリーダー2名、担当5名 【担当業務】 プロジェクト計画 / 工数管理 / 検証環境構築 / 製品比較・検証 / 調査結果の整理・報告 【使用技術】 Azure Synapse Analytics / Snowflake / Azure Databricks / Microsoft Fabric 【開発・実装内容①】要件整理・評価軸の策定 【どのような機能の開発・実装か】 DWH刷新に向けて利用者視点の要件整理を行い、複数製品を比較可能な形で評価軸を策定した。 【課題・問題点】 今後の利用者増加により、クエリ実行負荷の増大やリソース競合が発生する可能性があり、負荷分散可能な構成が求められていた。 また、運用工数やコストが増加すると継続利用が難しくなるため、性能だけでなく運用性・費用対効果を重視した選定が必要だった。 【打ち手・使用した技術】 性能を前提条件とした上で、コストパフォーマンスの高さ、保守運用工数が少なくなる構成を実現できるかを重点的に評価。 Synapse / Snowflake / Databricks / Fabric の特徴を比較し、スケール性、運用負荷、利用者増加時の負荷分散可否を整理した。 【成果】 短期間で要件を整理し、意思決定に必要な比較情報を収集・整理して報告することで、DWH基盤の選定プロセスに貢献した。 【開発・実装内容②】Snowflake選定に向けた検証・提案 【どのような機能の開発・実装か】 想定データ量10GB（約1億レコード）規模を前提に、各製品の性能・運用性・コスト面を比較検証し、最終的にSnowflakeを選定候補として提案した。 【課題・問題点】 利用者数やクエリ実行負荷の増加に伴い、リソース競合が発生すると処理性能が低下し、データ利活用が進まないリスクがあった。 そのため、負荷分散可能なアーキテクチャと、利用者が増えても運用負荷が増えにくい仕組みが必要だった。 【打ち手・使用した技術】 Snowflakeの分散コンピューティングによるスケール性や、仮想ウェアハウスによる負荷分散が可能な点を評価。 また、複雑なクエリや運用設計を前提とせず、利用者が扱いやすい点を強みとして整理し、保守運用工数削減とコストパフォーマンスの観点から有効性をまとめた。 【成果】 性能に加えてコスト・運用工数の観点を含めて比較検証し、利用者増加を見据えた負荷分散設計が可能な製品としてSnowflakeを選定した。 調査結果を報告資料としてまとめ、DWH基盤方針の決定に貢献した。 【開発・実装内容③】プロジェクト推進・管理 【どのような機能の開発・実装か】 調査プロジェクトにおける計画策定・工数管理を担当し、短期間で成果物（比較結果・報告資料）をまとめるための推進を行った。 【課題・問題点】 調査期間が短く、複数製品を並行して検証する必要があったため、調査範囲の取捨選択とスケジュール管理が重要だった。 【打ち手・使用した技術】 検証観点を優先度付けし、チーム内で分担を行いながら進捗を管理。 期限内に必要な情報を揃え、報告資料としてアウトプットできるよう調整した。 【成果】 短期間で調査プロジェクトを完遂し、製品選定に必要な情報を整理して意思決定を支援した。

【概要】 既存DWHの機能向上を目的として、Azure SQL Serverで稼働していたDWHをSnowflakeへ移行するプロジェクトを担当。 移行対象は40システム以上、200テーブル以上の規模となり、移行計画策定から工数管理、移行作業、切替手順整備まで主軸となって推進した。 【期間】 2025/01/21 ～ 2026/01/20 【チーム情報】 チームリーダー1名、担当4名 【使用技術】 Azure Data Factory / ADLS / Azure SQL Server / Snowflake / Git / Azure Virtual Machine / Azure Functions 【役割】 プロジェクト計画 / 工数管理 / 移行作業推進 / 手順書作成 / 切替対応 【開発・実装内容】DWH移行プロジェクト推進（計画・工数管理・移行作業） 【どのような機能の開発・実装か】 Azure SQL Server上で運用されていたDWHをSnowflakeへ移行するため、移行方式の検討、移行計画の策定、タスク分解、工数管理を担当。 移行対象となる40以上のシステムをチーム内で分担し、段階的に移行作業を推進した。 【課題・問題点】 移行対象が200テーブル以上と多く、システムごとに処理仕様が異なるため、作業の属人化や品質ばらつきが発生しやすく、移行の手戻りリスクが高かった。 また、SQL ServerとSnowflakeではテーブル設計思想や型定義が異なるため、設計変換作業がボトルネックとなり、移行スピード低下が懸念された。 【打ち手・使用した技術】 移行作業の効率化と品質担保のため、移行テンプレートを作成しチームメンバーへ共有することで、作業手順や実装方針を標準化した。 これにより、システム単位での分担作業を可能とし、並行して移行を進められる体制を構築した。 また、処理が複雑なシステムについては自身が率先して対応し、移行のボトルネック解消に貢献。 さらに、SQL ServerからSnowflakeへのテーブル設計変換を支援するプログラムを作成・提供し、設計作業の自動化・高速化を実現した。 【成果】 40システム以上・200テーブル以上の大規模DWH移行において、計画・工数管理から移行作業まで主軸となって推進し、移行を完了。 テンプレート共有と設計変換プログラムの提供により作業効率を高め、チーム全体での並行移行を可能にした。

【概要】 社内で公開されているデータ資産の認知機能拡大を目的にどのようなデータが存在するかを検索・閲覧できる社内向けWebサイトを新規開発し、社内のデータ利活用推進に貢献した。 【チーム情報】 個人開発(要件調整・レビュー担当：上司) 【どのような機能の開発・実装か】 上司への要件ヒアリングをもとに、社内で公開されているデータの一覧表示・検索・詳細閲覧が可能なWebアプリケーションを設計・実装した。 アーキテクチャ選定から開発、Azure App Serviceへのデプロイまで一貫して担当。 【課題・問題点】 自身にとって初めての本格的なWeb開発案件であり、設計や開発プロセスに関する基礎知識が不足していたため、実装の方向性が属人化しやすく、保守性や拡張性を意識した設計が課題となっていた。 【打ち手・使用した技術】 開発を進めるにあたり、システム設計・Web開発に関する書籍で基礎知識を補強し、設計観点（責務分離、画面設計、データ管理、デプロイ方式）を整理したうえで実装を進めた。 また、上司とのレビューサイクルを短い単位で回し、要件の認識齟齬を早期に解消しながら段階的に機能を追加する形で開発を推進した。 最終的にAzure App Service上で稼働する形でデプロイし、利用可能な状態でリリースした。 【成果】 社内で公開されているデータ資産を可視化する仕組みを整備し、従業員がデータの存在を把握しやすい環境を提供することで、社内のデータ利活用推進に貢献した。 また、以前まではデータの収集の許可のお願いすることが多かったが、サイト作成後からはデータの収集依頼をデータ管理者から受ける機会が多くなった。