はじめに
こんにちは！データ戦略室の田代です。
近年の目覚ましい技術進化と当社の事業拡大に伴い、社内システムのフルリプレイスや大規模改修といった重要なプロジェクトに、データ戦略の観点から関わる機会が増えてきました。 そこで今回は、私がこれまでに当社で3度経験したシステム大規模改修プロジェクトにおいて、データ担当者としてどのように貢献し、そこから何を得たのか、具体的な事例を交えながらご紹介します。
この記事が、データ活用に取り組む方はもちろん、システム開発に携わるエンジニアの皆様にとっても、日々の業務のヒントとなれば幸いです。
プロジェクト概要：
どのようなシステム改修に携わってきたのか、簡単にご紹介します。
事例1：Aサービス オウンドメディアシステムのフルリプレイス
概要：
当社Aサービスが展開するオウンドメディアのシステムを全面的に刷新しました。データベースおよびテーブル構造も一から再設計し、従来は正規化が不十分だったテーブル構造を、第3正規化を意識した設計へと移行しました。
データ戦略室の役割：
- DB設計やシステム要件に対するレビュー
- 一部機能におけるテーブルデータの作成支援
- 新旧両システムを横断的に分析可能なデータマートの再構築
参画タイミング：
要件定義の途中段階からプロジェクトに参加しました。
事例2：Bサービス オウンドメディアシステムのフルリプレイス
概要：
こちらもオウンドメディアシステムのフルリプレイスですが、事例1とは異なるBサービスに対して行なった改修です。同様にDB、テーブル構造を含めて全面的に刷新し、正規化を意識したDB設計を行いました。
データ戦略室の役割：
- 新旧両システムを横断的に分析可能なデータマートの再構築
参画タイミング：
要件定義の段階でご相談いただき、本格的な参画は開発がスタートしたタイミングからとなりました。
事例3：Cサービス SFA（営業支援ツール）の大規模改修
概要：
CサービスのSFA（営業支援ツール）において、新機能追加に伴う大規模な改修を実施しました。この改修はSFAで利用しているほぼ全てのテーブルに影響が及ぶものでした。
データ戦略室の役割：
参画タイミング：
要件定義がほぼ完了した段階からプロジェクトに参加しました。
良かった点と苦戦した点、そして学んだこと
3つのプロジェクトは、対象サービスも、関わるメンバーも、そして私自身の関与の仕方やタイミングもそれぞれ異なりました。そのため、スムーズに事が進んだ局面もあれば、思わぬ困難に直面した場面もありました。
良かった点
背景理解の重要性
改修の目的や背景を深く理解した上でプロジェクトに臨めたことは、改修後の適切な対応につながりました。
なぜこの改修が必要なのか、ビジネス上の課題は何かを把握することで、データマート設計や分析基盤構築において的確な判断ができました。
早期の設計書共有
開発途中の状態であっても、DBの設計書を共有いただけたことは、DWHやデータマートの設計を進める上で非常に助かりました。これにより、プロジェクト管理者や担当者がリリース後にすぐ分析できる体制を整えることが実現できました。
標準化による効率アップ
複数回の改修経験を通じて、データ戦略室内でどのような対応をしていくかがある程度標準化されました。これにより、プロジェクトごとにゼロからデータマートの設計を検討する手間が省け、より本質的な課題解決に注力できるようになりました。
苦戦した点
ドキュメント不在の衝撃
改修する前になってしまいますが、過去のDB設計に関するドキュメントがほとんど残っておらず、当時開発されていたエンジニアの方もほとんどいらっしゃらなかった状態でした。その状況下であったことから既存システムのデータ構造を理解するために、変換処理のコードを直接読み解く必要に迫られたケースがありました。これは多くの時間と労力を要し、正直会社に入って1、2を争う辛さでした。
曖昧な要件定義の罠
要件定義が理解できていないまま進んでしまうと、リリース後のデータマート開発に想定以上の工数がかかります。特に、ビジネスサイドの要求とシステム仕様の間に認識齟齬があると、分析に必要なデータが取得できないといった問題が発生しかねません。欲しいデータが思った通りに抽出できないとなったときの絶望感は今も忘れません。エンジニアの方に相談した結果、欲しいデータの抽出条件が違っただけで良かったです...
サイレント修正の恐怖
関係部署で仕様変更が行われたものの、データ戦略室への連携が漏れており、リリース直前に偶然その変更を検知して事なきを得るという冷や汗ものの経験もしました。もし見逃していれば、データ不整合や分析の誤りを引き起こしていた可能性があります。
プロジェクトから得た3つの教訓
これらの経験から、システム大規模改修プロジェクトをデータ活用視点で成功に導くために、特に重要だと感じた教訓は以下の3点です。
要件定義・設計フェーズでの積極的な関与
要件定義・設計フェーズでの積極的な関与は、システムの設計思想に大きく左右されます。そのため、可能な限り要件定義や設計といった上流工程からデータ戦略室が関与し、データ取得の要件や活用イメージを開発チームと共有することが不可欠です。現在のタスクが多くてもMTGに参加するだけで後々だいぶ楽になると思います。
設計書を可能な限り早く入手する
開発初期段階のものでも構わないので、早期に共有いただくことで、認識齟齬を防ぎ、手戻りのリスクを大幅に削減できます。リリース時には正確なものが必要になりますが、事前に対応するためには少し粗い段階でも共有いただくように依頼することがおすすめです。
改修前後のデータ関係をすり合わせておく
改修前後のデータがどのように対応するのか、その定義や意味合いについて、エンジニア、プロジェクト責任者、データ戦略室が共通認識を持つことが極めて重要です。この認識合わせを丁寧に行うことで、精度の高い分析基盤を構築できます。逆にすり合わせができていないと、プロジェクト関係者が1番多用な時期であるリリース前後のタイミングで追加ですり合わせが必要となり関係者の工数を逼迫してしまいます。
最後に
今回ご紹介した内容は、ある意味で「当たり前」と感じられることかもしれません。しかし、これらの「当たり前」を確実に実行することが、いかにプロジェクトを円滑に進め、予期せぬトラブルを回避するために重要であるかを、身をもって経験してきました。
この記事が、システム改修プロジェクトに携わる皆様にとって、少しでも業務を効率化し、より良い成果を生み出すための一助となれば、これほどうれしいことはありません。
最後までお読みいただき、ありがとうございました。
