久松氏
2023年の秋に、当時の上長からIIJが開催する「IIJ Sketch & Draw Workshop(以下、Workshop)」を紹介されたことが転機になりました。私がシステム更新の方向性の提示に行き詰まっていたこともあり、助け舟を出してくれたのだと思います。自力だけだと限界があることも感じていましたので、情報を持っている人の話を聞くことに抵抗はありませんでした。
久松氏
WorkshopはIIJの東京・飯田橋の本社で、3日間のプログラムで個別に実施するというものでした。IIJのサービス専任者とエンジニアが、システムにまつわる課題を一緒に考えて解決してくれるというものです。とはいえ、無償での実施であり、3日という限られた時間でもあるため、大きな期待はしていなかったのが本音です。「何をやるんだろうな」という興味があったというレベルでした。
ただし、現状のままでは状況は変化しないので、外部の意見を聞くことで何かにヒントを得たいと思って参加したことを覚えています。
久松氏
2023年秋に実施されたDay 1に上司を含めて3人で参加しました。このときは、現状や課題感、思いをヒアリングしてもらいました。課題についてどう思っているか尋ねられて、口頭で目指す方向性などについてお話ししたような状況です。お話ししながら、現実と理想のギャップを整理してもらったのだと思います。不足していた情報は、Workshopの後でIIJに送りました。
現状では古いOSのサーバなどがあり、一筋縄ではいかないことをIIJ側にも理解してもらえたと思います。
約1ヵ月後に実施したDay 2では、IIJ側から対策案やベストプラクティスなどについて説明いただきました。当社が抱えている課題感や現状を表にまとめた上で、今後の複数の方向性について説明を伺う中で、クラウド化の一番のメリットであるコストメリットが、商用システムならば出しやすいけれど、お金を生まない社内向けの業務システムが対象では見えにくいといったネガティブな面も整理して話をしてもらいました。
サーバの更新作業やセキュリティ対策をお任せできるというメリットと上記のコスト的なデメリットの両方を考慮し、当社ではすべてをオンプレで更新し続ける選択肢は、社内リソースと業務負荷を考えると難しいと判断しました。また、AWSならばエンジニアの数が多く、中途入社などで人材を確保しやすいこともあり、2024年の年始に実施したDay 3では、AWSにいったん方向性を定めて検討を進めることにしました。
当社の社内システムはWindows系のサーバが多いので、AzureとAWSのマルチクラウドという考え方もありました。しかし、複数クラウドの管理やそのためのエンジニアの確保などを考慮し、AWSに1本化する方向で考えることにしたのです。Day 3では、AWSを使った場合の災害復旧(ディザスタリカバリ)についての説明や、ネットワーク構成などについても話がありました。
3日間で課題のヒアリングから、方向性の確認、具体的な移行プランや技術的なインテグレーションの話もしてもらい、考え方が整理されました。3日間のWorkshopのプログラムはよくできていたと感じています。
久松氏
どんなものかな?という思いで参加したWorkshopでしたが、参加して良かったと思っています。技術的に詳しいエンジニアなどにも参加してもらい、真摯に話を聞いてもらえました。その中で、当社が抱えていた課題感や思いなどの抽象的な話を、具体化して整理してくれました。私としては、IIJの担当者やエンジニアの知見を使いながら、今までできなかった壁打ちをさせてもらったのかもしれません。
AWSについてもIIJはものすごくノウハウを持っていると感じました。うまくいった話だけではなく、うまくいかなかった事例やリスクなどの話もあり、とてもためになったと感じています。
久松氏
まず、利用するクラウドをAWSに1本化して、移行の検討を始めることにしました。しかしITプラットフォーム部にはAWSのノウハウも触れる環境もありません。そこで、IIJ経由でAWSのライセンス契約をして、検証環境を手に入れました。2024年4月に契約して、5月から使えるようになりました。
久松氏
AWS構築やシステムの移行は、基本的に当社側で行う方針です。しかし、AWSについてはノウハウがありません。現在はIIJのオプションサービス「クラウドよろず相談窓口」を利用して、分からないことなどへの対応をお願いしています。特にセキュリティの部分などは、とても加減が難しいと感じています。そうした中で、よろず相談窓口などを通じて相談しながら、IIJとは継続してお付き合いをさせてもらうつもりです。
久松氏
オンプレの既存のシステムは保守延長がかかっていて、長く使えたとしても数年以内に移行を終わらせる必要があります。具体的にどのシステムやサーバをAWSに移行するか、どのような順番で対応するかといったことは、まだ決定していません。これから、既存のシステムのAWS移行について、何が具体的な障壁や課題になり、どのような手法で実施すればいいかを検討しながら、数年内の移行を実施したいと考えています。少なくとも、最も重要な基幹業務システムである売上管理システムについては、Windows ServerのOSが古い上、大掛かりなシステムでもあるので、AWSへの移行の必要性が一番高いと考えています。
今後、多くの業務システムをクラウドに移行すると思います。適材適所でオンプレミスも一部残るハイブリッドな形になるのではないかと想定しています。最適解を見つけていけるように検討を進めていく考えです。
※ 本記事は2024年6月に取材した内容を基に構成しています。記事内のデータや組織名、役職などは取材時のものです。
社内業務用システムがオンプレミスに残存するも、課題が山積
久松様は普段どのような業務をしていらっしゃいますか。
D2C 久松奨平氏
当社のITプラットフォーム部は、いわゆる情報システム部門です。私は社内ネットワークやサーバのインフラ分野を担当しています。D2CはNTTドコモのデータを使ったマーケティングビジネスを展開しているため、今後のビジネス展開の「攻め」の部分で遅れを取らないように、インフラ側から支援しています。
社内の情報システムの状況を教えてください。
久松氏
広告配信システムなど顧客サービスを提供する商用システム以外の社内向け業務システムなどは、オンプレミスで運用を続けています。売上管理システムのような基幹業務システムから、Active Directoryサーバやプリンターサーバまで、多くのシステムがあります。古いOSを使っているシステムもあり、対応が課題になっていました。
業務システムの更新については、どのような取り組みが行われていましたか。
久松氏
業務システムは売り上げや利益に直結しないので、投資をしにくいこともありました。2021年ごろから、システムごとの保守の更新時期やEoL(End of Life)のタイミングなども考慮し、将来を見据えたインフラを作る必要があるのではという議論が始まりました。電気代の高騰の問題や、物理障害があった場合の対応などオンプレミスならではのデメリットもあり、クラウドへの移行を含めて検討を始めることにしました。
ただし、止められない基幹業務システムもあります。その上、OSの古さや複数のシステムがツギハギのようになっている状況があり、すぐにクラウド化などの対応をすることが難しいことも分かっていました。そもそも、オンプレミスを延長するかクラウド移行かという根本も方針が決まっていませんでしたし、クラウド移行するとしても国産か外資かという選択もしなければいけません。クラウド移行という結論ありきではなかったため、検討項目が多岐にわたり堂々巡りになってしまい、最適解や方向性を決めることができずに時間だけが経過していました。
ITプラットフォーム部内にはクラウドのノウハウの蓄積はなく、またクラウド移行に伴う新しい投資を引き出すための論理的な説明が難しかったことも理由の1つです。