はじめに Power BIでレポートを作成する際、データの取り込み元としてExcelやCSV、あるいはSQL Serverなどのデータベースを利用するのが一般的です。 しかし、インポートモードで扱うデータが「数十GBクラスの大容量」になったとき、その運用に頭を抱えたことはありませんか？今回は、30〜60GBという膨大なデータを扱うプロジェクトにおいて、運用効率化のためにSharePoint接続を検証・導入した際の知見を共有します。 対象読者 ・Power BIで扱うデータ量が肥大化し、パフォーマンスや運用に課題を感じている方 ・複数人でダッシュボードを共同開発しており、ファイルの

こんにちは、SCSKの松岡です🔗 データ連携の実装でAWS Glue (Python Shell Job)を導入した際の試行錯誤を整理しました。 RDSからデータレイクであるS3 Tablesに連携する際に、横展開可能な軽量なデータ連携ジョブを実現するために気にしたポイントについて紹介します。 背景 データ活用基盤を構築するにあたり、「データをどのように集めるか」は重要なテーマの一つです。 仮に収集元のシステムが単一であっても、対象となるテーブルが複数存在する場合、テーブルごとに連携方法を検討し、ジョブとして実装していく必要があります。そのため、連携対象のテーブル数が多い場合には、テーブル単位での開発工数をいかに抑えつつ、効率的に横展開できるかが重要なポイントとなります。 また、データ連携方式を検討する際には、データ量だけでなく実行頻度も重要な判断軸となります。1回あたりのデータ量が少量であっても、高頻度で実行する必要がある場合、実行回数に比例してコストが増加するため、想定以上にコストが膨らむ可能性があります。 連携元はRDS(PostgreSQL)のみだが、連携対象テーブルが多数 処理1回あたりのデータ量は少量だが、毎時で何度も差分連携しなければならない 開発コストと運用コストの両方をなるべく抑えたい データレイクとしてIceberg (S3 Tables)にデータを連携したい このような前提のもと、開発コストと運用コストの双方を抑えつつ、シンプルに実現できるデータ連携方式を検討しました。   構成と選定理由 Why AWS Glue（Python Shell）？ データ連携方式として、AWSサービスを利用することを前提に、以下から比較検討しました。 AWS Glue (Python Shell) AWS Glue (Spark) AWS DMS AWS Lambda その結果、今回は AWS Glue (Python Shell) を採用しました。 主な理由は以下の通りです。 AWS Glue (Python Shell)は起動時間が短く、小規模かつ高頻度なデータ連携を効率的に実行できる AWS Glue (Python Shell)は、PythonベースでSQL抽出や変換処理を柔軟に制御できる AWS Glue (Spark)は大規模データ処理に適しているが、要件に対して過剰スペックになる AWS DMSには差分レプリケーション機能があるが、S3 Tablesに対応していない(※2025調査時点) AWS Lambdaで柔軟な処理開発が可能だが、15分の実行時間制約がある 参考：AWS Glue の料金 構成 データソースからRDS（PostgreSQL）に集約したデータを、AWS Glue（Python Shell）ジョブによりAmazon S3へ連携し、未加工データとしてS3 Tablesに蓄積します。その後、AthenaやRedshiftから参照・集計し、BIツール（Power BI）で可視化する構成としています。 構成図では簡略化していますが、ジョブの起動はGlueトリガーによりスケジュール実行し、実行結果の監視や通知についてはEventBridgeおよびAmazon SNSを組み合わせて実現しています。 ※本記事ではGlueジョブ中の変換処理は扱わず、未加工データをそのまま連携するシンプルなデータパイプラインにフォーカスしています。   気にしたポイント 差分更新の設計 Glueの処理にフォーカスしたデータ連携の概要は、以下の通りです。 Glueジョブを動かすための要素として、RDS側で管理・履歴テーブル、S3側に各種ファイル配置先を設定しています。 本構成では、RDS（PostgreSQL）に格納された業務データを、AWS Glue（Python Shell）ジョブによりS3へ連携します。 差分更新を実現するため、RDS側にはジョブ実行日時を管理する「管理テーブル」と「履歴テーブル」を配置し、S3側にはデータ出力先に加えて、Glueで利用するソースコードやドライバ、ライブラリを格納するバケットを用意しています。 Glueジョブは実行時に管理テーブルを参照し、前回処理日時をもとに差分データを抽出します。抽出したデータはS3へ出力され、その後、処理結果を管理テーブルへ反映することで、次回実行時の差分基準として利用されます。 また、GLueジョブの実行結果は履歴テーブルにも記録されるように設計しています。具体的には、各実行ごとに「連携対象日時（FROM/TO）」「処理件数」「実行成否」などをRDSに記録することで、過去の実行状況を追跡可能としています。 さらに、実行結果はCloudWatch Logsにも出力し、個々のジョブ実行の詳細を確認できるようにしています。 参考：AWS Glue ジョブのログ記録 ジョブのパラメータ設定 Glueジョブでは、パラメータを指定することで、ジョブごとに処理対象や抽出条件を動的に制御することができます。 このパラメータ設計は、複数テーブルのジョブ実装対応を効率化する上で重要なポイントとなります。テーブルごとに個別のジョブを1から作成すると開発負荷が高くなるため、ジョブをパラメータ化し、共通のジョブ定義をベースとして複製することで、複数テーブルに対応できるようにしました。 （GlueジョブはClone機能により簡単に複製が可能です） 具体的には、以下のようなパラメータを定義しています。 table_name ：対象テーブル名を指定し、スクリプト内で参照するテーブルを動的に切り替える primary_key ：主キー項目を指定し、更新処理時のキー条件を動的に制御する last_update_column ：差分抽出に利用する列を指定し、当該列をもとにフィルタ条件を動的に生成する これにより、ジョブ定義の共通化と再利用性を確保しつつ、テーブル数が増加した場合でも効率的に展開できる構成としています。 参考：AWS Glue の Python パラメータの受け渡しとアクセス PostgreSQL → Icebergのデータ型変換 出力先をIcebergテーブルとして利用する前提のため、データ型の整合性を意識した設計を行いました。 PostgreSQLとIcebergでは型の扱いに差異があるため、スキーマをもとに列ごとの型変換を動的に適用する方式としています。これにより、テーブルごとに個別対応することなく、共通ロジックで型整合性を担保できる構成としています。 また、今回のケースに限らず、システム間連携においては、各システムで扱うデータ型の仕様を正しく理解しておくことが重要です。特に、型の不一致による連携漏れや桁あふれなどの問題が発生しないよう、事前に設計段階で考慮しておく必要があります。 参考：Icebergのデータ型の仕様 ライブラリ管理 Glue Python Shellでは、処理内容に応じて必要なPythonライブラリを自前で準備する必要があります。 今回の構成では、PostgreSQL接続用にpg8000、S3 Tables / Iceberg操作用にpyicebergなどのライブラリを利用しており、これらをwhlファイルとしてS3に配置して使用しています。 これらのライブラリを事前に配置しておくことで、実行時に外部リポジトリへアクセスして取得する必要がなく、インターネット接続に依存しない安定した実行環境を構築することができます。 また、Glue Python Shellにはあらかじめ利用可能なライブラリが含まれている一方で、用途によっては追加でライブラリを用意する必要があります。そのため、利用するライブラリが事前インストール済かどうかを確認した上で、必要に応じて追加対応を行うことが重要です。 さらに、ライブラリによってはGlueの実行環境との互換性によりそのまま利用できない場合もあるため、事前の検証やビルド方法の調整が必要となる点には注意が必要です。 参考：AWS Glue Pythonジョブにおけるライブラリ管理   まとめ AWS Glue Python Shellは、起動時間が短く、コストを抑えながらPythonで柔軟に実装できる点が特徴であり、軽量なデータ連携基盤として非常に有効な選択肢です。特に、SQL主体のシンプルなETL処理や高頻度のバッチにおいては、その特性を活かしやすく、効率的なデータ連携を実現できました。 一方で、ライブラリの準備や実行環境との互換性、差分更新の設計などは自前で考慮する必要があり、構成によっては設計・運用面での工夫が求められます。また、ジョブのパラメータ設計やログ出力などを含めた運用設計も重要なポイントとなります。そのため、処理内容やデータ量、運用要件に応じて、Glue SparkやDMS、リアルタイム連携であればKinesis Data Firehose、またはTROCCOのようなサードパーティ製ETLツールも含めて、適切に使い分けることが重要だと思いました。 本記事のような軽量かつ柔軟なデータ連携のユースケースにおいては、Glue Python Shellは実用性の高い選択肢であると感じました。   (宣伝) クラウドデータ活用サービス 今回ご紹介した内容は、SCSKで提供しているクラウドデータ活用サービスの中で扱っているテーマの一部になります。 お客様のデータ活用状況に応じて、基盤構築から可視化、データ連携、データマネジメント、高度データ活用までを段階的にご支援しています！ ご関心あれば、以下のサービスページもご参照ください。 クラウドデータ活用サービス｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション クラウドデータ活用サービスは、お客様のデータ活用状況に合わせ、適切なご支援が可能です。 www.scsk.jp

このシリーズでは、当社のデジタルテクノロジー戦略本部（通称：デジ戦）で働く社員が、どのようにスキルを伸ばし、キャリアの幅を広げてきたのかを紹介します。キャリアチェンジの背景や挑戦のプロセス、日々の学びを通じて、デジ戦で描けるキャリアの可能性をお伝えします。 筆者プロフィール 所属：ビジネスイノベーション第1統括本部 ITソリューション第3統括部 ビジネスシステム部 入社時期：2019年 中途入社 職種：システムエンジニア 経歴： 新卒で鉄道会社に入社し、駅係員などの業務に従事。 2019年2月にマイナビへ中途入社し、企画職としてマイナビ転職フェアのイベント企画に従事したのち、採用支援部門へ異動。 企業の採用を支援する商材の企画やカスタマーサクセス、部門の業務効率化支援などを担当。 2024年10月にデジタルテクノロジー戦略本部へシステムエンジニア職として異動。 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発などを行っています。 はじめに デジ戦への異動が決まったとき、うれしさと同じくらい不安がありました。30歳、未経験でシステムエンジニアとしてやっていけるのか。正直、自信があったわけではありません。 この記事では、私がITに興味を持ったきっかけや、デジ戦へ異動した理由、異動直後に感じたギャップ、現在担当している業務、そしてこれから目指したいキャリアについてお話しします。キャリアチェンジは決して簡単なことではありませんが、これまでの経験がどのように今の仕事につながっているのかをお伝えできればと思います。 現場で感じた違和感が、ITへの入口になった 私がITに興味を持ったのは、鉄道会社で現場の仕事をしていた頃でした。 駅係員として働く中で、「もっと効率的にできるのではないか」「この手間は仕組みで減らせるのではないか」と感じる場面が多くありました。そうした思いから社内プロジェクトに参加し、業務ツールの開発に関わる機会がありました。そこで、ITやデジタルの力で仕事の進め方そのものを変えられることを実感しました。 単に便利なツールとしてではなく、現場の負担を減らし、仕事の質を高める手段としてITに惹かれるようになったのが、この頃だったと思います。 企画職として働く中で、「使う側」から「つくる側」へ気持ちが変わっていった 2019年にマイナビへ中途入社してからは、企画職としてイベント企画や商材企画、カスタマーサクセス、業務効率化支援などに携わってきました。 この時期に特に力を入れていたのが、業務改善です。手作業や属人的な運用を見直しながら、VBA、GAS、BIツールなどを活用して、部門全体の業務効率化を進めていました。 その中で実感したのは、ITは単なる作業効率化にとどまらず、業務の進め方そのものを変える力があるということです。課題を整理し、関係者を巻き込み、運用まで含めて形にしていく経験は、今振り返るとシステムエンジニアとして必要な視点につながっていたように思います。 30歳、未経験でシステムエンジニアへ異動するという挑戦 デジ戦への異動が決まったのは、30歳のときでした。 それまでITツールや業務改善には関わっていましたが、システムエンジニアとしての実務経験があったわけではありません。うれしさはありましたが、それ以上に「本当にやっていけるだろうか」という不安もありました。 デジ戦には、技術畑を一直線に歩んできた人だけでなく、事業側の経験を持つ人や、さまざまな職種を経て今の仕事に就いている人もいます。そうした環境に触れる中で、システムエンジニアとして大切なのは技術力だけではないのだと感じるようになりました。 もちろん、未経験からでも簡単に通用するという意味ではありません。技術を学び続けることは前提です。そのうえで、現場を理解する視点や、業務を整理する力、関係者と認識をそろえながら前に進める力も価値になる。そう思えたことで、自分がこれまで積み重ねてきた経験にも、挑戦する意味があると前向きに捉えられるようになりました。 それでも挑戦しようと思えたのは、「現場や事業の課題を仕組みで解決したい」という思いが自分の中にずっとあったからです。やらずに後悔するよりも、まずは飛び込んでみたい。そうした思いを持つ中で、デジ戦へ異動することになりました。 また、マイナビには、研修やUdemyなどの学習機会に加え、キャリア希望申告や社内公募制度など、挑戦を後押しする仕組みがあります。自分のキャリアを考えながら、次の一歩につなげやすい環境だと感じています。 異動直後の3か月は、知識不足と向き合う時間だった 実際に異動してみると、最初にぶつかったのは想像以上の知識差でした。ベンダー様との打ち合わせではシステム用語が当たり前のように飛び交い、会話の前提も意思決定のスピードも速い。単語そのものは調べれば分かっても、その場の文脈や論点の重みまですぐにつかむのは難しく、最初の3か月は特に苦労しました。 会議が終わるたびにメモを見返し、分からなかった言葉を調べる。必要に応じて生成AIも活用しながら、一つずつ知識の穴を埋めていきました。その繰り返しで、少しずつ理解できることが増えていきました。 また、未経験だからこそ、実務に触れる量を増やさなければ前に進めないと感じ、できるだけ案件に手を挙げるようにしていました。加えて、後輩、先輩、上司を問わず、分からないことは素直に聞くようにしていました。初歩的な質問でも受け止めてくれる雰囲気があり、そのことに何度も助けられました。 今振り返ると、この3か月は知識を増やすだけでなく、未経験の立場で前に進むための姿勢を身につけた時間だったと感じています。 今担当している仕事と、そこで活きているこれまでの経験 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発に携わっています。 システムエンジニアの仕事というと、実装や設計のイメージが強いかもしれませんが、実際にはそれだけではありません。利用部門の要望を整理し、課題を言語化し、関係者と認識をそろえながら、開発や運用につなげていくことも重要な役割だと感じています。 業務では、たとえば以下のような技術・ツールを活用しています。 言語・スクリプト：OfficeScript、VBA、Python、SQL インフラ・クラウド：AWS ツール：Power BI、Power Automate 、Dify、denodo、Reckoner また、生成AIも情報整理や論点の洗い出し、理解が曖昧な領域のキャッチアップなどに活用しています。 ここで活きているのが、これまでの現場経験や企画職の経験です。現場で働いていたからこそ、「使う人にとって無理のない運用か」「本当に役立つ仕組みになっているか」という視点を持ちやすい。また、事業部門での経験があるからこそ、「何の課題を解決したいのか」「どう伝えれば関係者の認識がそろうのか」を考えることにも自然と意識が向きます。 全社横断プロジェクトのPJリーダー経験で、課題を仕組みに変える面白さを強く実感した 私にとって大きな転機のひとつになったのが、全社横断プロジェクトのPJリーダーとして取り組んだ、社内備品共有の仕組みづくりです。 事業部門にいた頃、まだ使える備品が十分に活用されないまま廃棄されていく状況を見て、「社内で共有できる仕組みがあれば、もっと有効活用できるのではないか」と感じていました。 そこから始まったのが、社内備品共有ツール「マイカリ」につながる全社横断のボトムアップ型プロジェクトです。課題意識を持つだけでなく、それを関係者と共有し、実際に使える仕組みとして形にしていく難しさと面白さを、このプロジェクトを通じて強く実感しました。 特に印象に残っているのは、デジ戦の方々と一緒に進める中で、単に機能を作るのではなく、「どうすれば使われるか」「どうすれば運用に乗るか」まで見据えて考える姿勢に触れたことです。立ち上げから約4か月で都内拠点でのリリースにつながり、その後、全社リリースまで進めることができたのは、多くの関係者の協力があったからこそだと感じています。 また、この取り組みは社内にとどまらず、日経GXなど複数の社外メディアにも掲載されました。現場の課題意識から始まったボトムアップの取り組みが、社外からも関心を持って見ていただけたことは、大きな励みになりました。 この経験を通じて、私は「ITを業務改善に活用する」だけではなく、「ITで仕組みそのものをつくる側に回りたい」と、より明確に思うようになりました。 関連リンク マイナビ サステナビリティニュース https://www.mynavi.jp/sustainability/news/2025/10/post_50484.html これから目指したいキャリア システムエンジニアとしては、まだまだ道半ばです。現在担当している社内システムの開発・保守・運用や、業務ツールの内製開発を通じて基礎を固めながら、今後はさらに扱える領域を広げていきたいと考えています。 具体的には、開発言語の幅を広げること、AWSなどのクラウドサービスへの理解を深めることに加え、AIも適切に活用しながら、開発や業務改善の質とスピードを高めていきたいです。 将来的には、既存業務の改善や運用支援にとどまらず、新規事業の創出にも関わっていきたいと考えています。現場や事業の課題を起点に、新しい価値を形にしていくプロセスにも挑戦し、仕組みづくりを通じて事業の可能性を広げられる人材を目指したいと思っています。 そのうえで目指したいのは、技術だけに強い人ではなく、現場や事業のことも理解したうえで、使う人にとって本当に意味のある仕組みをつくれる人です。 これからマイナビのデジ戦を目指したいと考えている方には、新卒・中途を問わず、これまで培ってきた経験や自分なりの視点を強みとして大切にしてほしいと思います。最初からすべてできる必要はありませんが、学び続ける姿勢に加えて、分からないことを素直に周囲に聞き、吸収していく姿勢はきっと力になります。自分の経験やこれまで培ってきた力を、デジ戦でどう活かせるかを考えながら、ぜひチャレンジしてみてください！ 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。