経営管理データ基盤の構築

セガサミーホールディングス株式会社

2024.05.28

概要

業績管理・戦略立案を目的としたデータ基盤を、クラウド上に実装するプロジェクト。
PoC(Proof of Concept:概念実証)実装後の二次開発フェーズより参画し、より広範囲かつ詳細なデータを効率的に蓄積・活用できるよう、AWSのマネージドサービスを組み合わせて再構築。「必要な人に必要な形で」というコンセプトの元、経営管理に必要なデータを提供する仕組みを構築し、各部署の運用および意思決定を支えるシステムとなった。

お客様の声・座談会形式インタビュー

セガサミーホールディングス株式会社
ITソリューション本部 HR・
生産システム部 HRシステム課
田口様
セガサミーホールディングス株式会社
ITソリューション本部 HR・
生産システム部 HRシステム課
五十嵐様
中央システム株式会社
クラウドアーキテクト
米元


中央システム株式会社
開発リーダ
作間


「手集計」からの脱却を目指したデータ基盤

田口様
元々の業績管理は、手集計が中心でした。セガサミーグループには海外含め多くの拠点があり、それぞれの拠点からの報告をExcelによって集約・加工してきましたが、精度や工数に問題を抱えていました。そういった状況を改善すべく、Amazon Web Services(以下、AWS)上に一括でデータを集積・加工できる基盤を実装し、グループ全体として運用することを目指したのが、今回のプロジェクトになります。

五十嵐様
PoCとして、国内のデータに絞って一次開発を行いました。それから二次開発に向け、海外のデータまで拡大することを考えると、運用体制やパフォーマンスについて見直す必要があると考えていました。そこで、別のプロジェクトでご協力いただいていた中央システム様にお声がけしました。

多様なフォーマットと、運用面のハードル

田口様
取り込むデータを拡大すると、その分フォーマットも多岐に渡ります。PoC時点では個別のフォーマットに合わせてデータを取り込む形式を採用しましたが、二次開発フェーズでは統一化されたフォーマットを設計する必要がありました。

五十嵐様
フォーマット以外にもいくつか課題がありました。一つはエラー発生時の問題です。PoC時点ではエラー検知の仕組みがなく、運用者が監視し続ける必要がありましたエラー発生時に調査するログについても、当時は「不具合がある」ということしか分からず、解決までに時間がかかっていました。また、パフォーマンスについても問題を抱えていました。取り込むファイルの件数や規模が大きいこともあり、特に複数のファイルを同時に取り込む際に、相当な時間がかかってしまうことがネックでした。


課題1

取り込むデータがそれぞれ多様なフォーマットで作られている

解決方法

対象となるデータフォーマットを調査・解析し、可能な限り共通化された機構で処理できるよう実装。

米元
多様なフォーマットを前提としつつ、それらを取り込んだ際の大きな処理は共通しています。そういった処理に対して、品質良く短時間で開発できる機構を、オブジェクト指向で用意できたかなと思います。中央システム自体、オブジェクト指向型の開発に強みがあるので、その強みを今回も活用させていただいた形ですね。


課題2

エラー検知の仕組みがなく、運用者が監視し続けなければいけない

解決方法

開発環境・本番環境それぞれのログ出力を実装。AWS上での検知〜特定までのフローを支援。

米元
開発環境・本番環境それぞれのログ出力を、AWS Lambda / AWS Glueに実装しました。異常データの追跡についても、実際に運用されるお二方にお話を伺いながら、速やかに原因特定ができるようになったかと思います。

五十嵐様
実装後はエラーの検知もシステム側に組み込まれ、ログから原因を探ることも容易になりました。仕組みを作っていただいただけでなく、どういう風にログを辿るかといった運用の部分までサポートいただき非常に助かりましたね。


課題3

複数のファイルを同時に取り込む際に、相当な時間がかかってしまう

解決方法

ボトルネックとなっていた既存処理を特定・解析。処理方式を変更し、改善。

米元
1件ずつ逐次処理するようなコードがあり、それがパフォーマンス上のボトルネックとなっていました。そういった部分を新しい方式で処理する形に切り替えたことで、取り込み速度の向上を実現しました。

五十嵐様
実際に、取り込みの際の時間は大幅に短縮されました。以前は40分程度かかっていた取り込み作業も、今では10分程度になっています。運用の負荷が減り、より活用しやすいデータ基盤に生まれ変わったと思います。

AWSスペシャリストが伴走する安心感

作間
本プロジェクトは、AWSスペシャリストである米元と密に連携を取って進行しました。
実際のソースを紐解きながら、同時に内部資料として共通認識が取れるドキュメントを作っていきましたね。

五十嵐様
私達もAWSに知見があるわけではなく、具体的な改善点をお伝えするのも難しかったのですが、中央システム様には丁寧にコミュニケーションとドキュメンテーションを進めていただいた印象があります。

田口様
日頃のやり取りから資料に至るまで一貫して精度が高く、お互いに認識を揃えながら議論や仕様検討ができていたので、後戻りも少なく非常に助かりました。

作間
私たちとしても、開発にあたって認識の齟齬はなるべく減らしたいと考えています。システムの設計書だけでは、認識を揃えるには足りない部分もありますので、出来る限り論点をクリアにしながらプロジェクトを進行することを心がけています。

田口様
決して大人数のプロジェクトではありませんでしたが、その中でもAWSの豊富な知見をもとに、しっかりとコミットしていただきました。何か1つご相談すると、それに対して1以上のご提案が返ってくるのもありがたかったですね。こういう方法が良いのではないか、こういう形がスムーズではないかと、運用も含めてアイデアを提供いただき、それが高い品質につながったと考えています。

五十嵐様
こちらの指示に対して、常にひと工夫加えていただけるので、より良い方向に向かっている安心感がありました。

米元
せっかくプロジェクトに参画させていただけるなら、お客様が使いやすいものを目指したいと思っています。「お客様の立場で考える」というのは、弊社の理念として大切にしているスタンスの一つです。

プロジェクトの未来を見越した開発環境の整備

作間
今回は、将来的にプロジェクトが持続することを踏まえて、開発環境の整備も行いました。具体的にはAWS CodeCommitでバージョン管理を行う形に変更しています。

五十嵐様
AWSを利用するプロジェクトで、どのようにソース管理を行うべきかといった点も、社内では課題になっていました。他のプロジェクトでAWSを利用しているメンバーからも、どういった運用や管理になっているか参考にしたいという声が挙がっています。

田口様
運用面についても、社内にAWSを取り扱う技術者が少ない中で、制度を検討している最中でした。本プロジェクトが先行して整備できたことで、他のプロジェクトにもポジティブな影響を与えられると考えています。

作間
「作って終わり」ではなく、長期的に改善サイクルを回しやすい状態を実現することが重要だと考えています。今回のフェーズを経て、今後開発を進めていくためのベースとなる環境が用意でき、三次開発以降の資産として活用いただけるかと思います。

田口様
データ基盤のプロジェクトに終わりはなく、今後は取り込むデータを増やしながら、見せ方まで改善していくフェーズに入っていきます。今回実装いただいたシステムをベースとして、国内外のデータや、実績のみならず計画・見通しに関するデータも扱えるようになっていくと思います。適切なステップを踏んで、セガサミーグループ一体となって活用できるシステムにしていきたいですね。

部分的な仕組みから始めるAWS導入

田口様
AWSにはメリットが多い一方で、いきなり大きなシステムを移行するということは、中々ハードルが高いように思います。今回のプロジェクトのように、データをストックする仕組みから導入してみるというのは、AWS活用の良いきっかけになったと感じています。

米元
確かに、コスト面や安全性を考えても、比較的着手しやすい領域かも知れません。

田口様
部分的な仕組みから導入し、徐々に領域を広げることもできるので。クラウド化について検討していらっしゃるご担当者様には、そういった導入フローもあるとお伝えできればと思います。セガサミーホールディングスとしても、今後AWSの活用を拡大したいと考えていますので、中央システム様にはぜひまたご相談させていただけると幸いです。

米元
AWSは活用の幅が広く、様々な用途でお力添えできると思います。お客様の目線に立ち、誠心誠意よりよいものを作ってまいりますので、ぜひお声がけください!

プロジェクト詳細

課題

  • エラー発生時の対応

    問題が発生した際、エラーの検知から異常データの特定まで時間がかかっていた

  • 特定の処理におけるパフォーマンス

    性能ボトルネックが存在し、特定の処理において長い処理時間が発生していた

  • ソース管理・運用ルール

    バージョン管理ミドルウェアが導入されておらず、運用管理に懸念があった

  • コードの処理構造化・共通部品化

    同じ処理が複数のコードで記述されており、冗長性・再利用性の点で課題があった

ソリューション

  • ロギング機構とログ出力内容の整備

    ・ログレベルによる出力内容切り替えの機構をAWS Lambda/AWS Glueに実装

    ・開発環境の詳細ログ・本番環境の運用ログそれぞれの出力分けを実装

    ・データ連携異常発生時、異常発生個所から異常データ特定の追跡を行えるようになった

  • 処理方式の変更

    ・ボトルネック(1件逐次処理)となっているトランザクション処理を解析

    ・Amazon Redshift組み込みのCopy処理(一括取り込み処理)とMerge処理(Insert&Update)について、方式の変更を行い、新方式での処理時間短縮を図った

  • ソース管理と運用整備

    ・AWS CodeCommitを活用し開発環境と本番環境のバージョン管理を導入

    ・複数人での共通部品開発におけるデグレード防止、緊急事態の切り戻し対応など、運用管理業務の向上に貢献した

  • オブジェクト指向を用いた開発

    ・AWS Lambdaのレイヤー機能、AWS Glueの参照ファイルパスの機能を利用し、業務クラスの継承関係を整理

    ・プロジェクト内の「車輪の再発明」を抑止し、同系統の横展開処理を実現する際のコード記述量を大幅に削減した

構成

成果

  • エラーの検知〜調査〜原因特定にかかる時間の短縮
  • パフォーマンス向上によるスムーズな利用体験の実現
  • 長期的な改善を見越した、効率的で安全な運用管理の実現

事例一覧

お問い合わせはこちら

Contact

各サービスへのお申し込みは
下記フォームで受け付けております。