移行のための技術選定とプロジェクト進行のポイントは？
技術選定のポイントには、大きく分けて組織と技術の2つの観点がある。組織的な観点だと、「人的なコストも含めたTCO（総保有コスト）を考慮する」「仕様変更がある場合に事業部ユーザーが対応できるか」「人材が多く確保できる言語・技術を選定する」「メンバーが疲弊しないようにチーム全体で運用・保守できるか」「他組織との連携」が挙げられる。
技術的な観点としては、「要件を満たせるか（既存の利用・運用維持が最低限）」が当然ながら大事になる。そのうえで5年先を見すえて「大きな改修・廃止をしないですみそうか」「ベンダーロックインしにくいか」も考慮しておいたほうがいいだろう。
プロジェクトは約1年半ほどかけた。最初に非機能要件を事前に検証し、社内調整した。もし非機能要件を満たせなければオンプレ更改も視野にいれていたものの、社内調整で許容範囲内に収めることが可能となった。続いて、OS変更やアップデートでコンテンツ移行がうまくいくか、想定通りデータマートまで流せるか、各処理で同じデータを流せるか、既存の年次切り替えなどのオペレーションが実現できるかなどを検証した。
検証は優先順位が高いものから実施し、ある程度進むと残処理の開発を並行して行った。終盤にはコンテンツが今まで通り使えるかを確認するために環境移行と並行稼働を挟み、最後に事業部ユーザーと協力してコンテンツを移行し、新環境の利用を開始した。
プロジェクトを振り返り、あらためて良かった点としてよそじ氏は「机上の見込みではありますが、向こう5年のTCOを約8000万円削減、データ連携速度は1時間以上短縮、エラー対応時間は少なくとも年100時間以上削減できました。またユーザーを増やしやすくなったことで、新たな用途の提案も出てきています」と話す。
逆に反省点を挙げるなら、技術選定時に把握しきれなかった仕様があったこと。例えばSnowflakeにはクエリ長やリスト数の制限がある。BIツールと組み合わせることでフィルターでクエリ長が長くなり、上限に達してしまうことがあった。他にもMWAAのオートスケーリングではバグを踏んでしまい、ゾンビタスク（実行されるはずだが実行されていないタスク）が発生してしまった。ここはオートスケーリングを回避することで対処した。
他にもユーザー部門との調整時間の見積もり不足が挙げられる。ユーザー部門は通常業務の合間に対応するため、なかなか時間がとれず進行的に危ぶまれたものの、ドキュメント作成や作業巻き取りなどでカバーした。最後に他部署担当機能の仕様に対する理解不足もある。例えばSnowflake利用でAzureADを利用することになったものの、SnowflakeとAWSを繋ごうとした時に社内ルールの都合でプライベートリンクを利用できなかった。「関連部署と詳細な情報を連携して確認すべきだった」とよそじ氏は言う。
最後によそじ氏は「データ活用はそれぞれのフェーズで課題があり、エンジニアの負担が大きいものの、こうして技術刷新でエンジニアの負荷軽減と採用しやすい体制作りに取り組んでいます。技術選定では組織的な観点と技術的な観点の両面から考慮する必要があります。プロジェクトを進めるうえでは、落としてはならないところを確認し、段階を踏んでいくことが大切です」とまとめた。
今後については「モダナイズが進んだことで、データ民主化に充てられる時間が増えました。ユーザー向け勉強会開催ほか、戦略策定、全社KPI、データ統合、AI民主化、ツール導入など、やりたいことが多くあります。他部署とも力を合わせてデータ民主化に資する活動を行っていきたいと思います」と力強く述べた。
