クラウドネイティブ化までの道程——目的の明確化と3つの課題
セゾンテクノロジーは1993年に発売した「HULFT」のクラウドネイティブ化に取り組み、2024年に「HULFT10 for Container Services」としてリリースした。
なぜ、この開発に取り組んだのか。「クラウドネイティブ化したくて、クラウドネイティブ化する組織なんてない。クラウドネイティブ化はあくまでも手段で、その背景には何かしらの目的がある」。こう語るのは、長年、HULFTの開発に携わってきた伊藤氏だ。
クラウドネイティブ化する目的は千差万別だ。例えば「新技術や新サービスを柔軟に取り入れて連携し、システムをアップデートしたい」「インフラレベルの管理、運用、脆弱性対策、障害対応などをクラウドベンダーに任せて運用の負荷を減らしたい」「エンジニアが多い技術を採用することで人材確保を容易にしたい」……。いくつかのパターンがあるが、重要なのは「目的をはっきりさせておくこと」と伊藤氏は言い切る。なぜなら、目的に応じてクラウドネイティブ化の構成が異なるからだ。
例えば運用負荷を軽減することを目的とするなら、単一ベンダーで固めたサーバレスを主体に据える構成が考えられる。一方で、移行や人材確保の容易さを目的とするのなら、可能な限りオープンな技術を使用してベンダーロックをしないシステム構成にすることが良いかもしれない。
セゾンテクノロジーの場合、その背景にあったのは、HULFTがいろいろなプラットフォームと連携するという特性を持っていたこと。加えて、各プラットフォームの差を限りなく減らし、ファイルを扱うことができる同プロダクトの強みを活かすには、各クラウドベンダーで共通して扱えることを条件とする必要があった。「このようなことから今回、コンテナオーケストレーションをベースにしたクラウドネイティブ化を行うことにしました」（伊藤氏）
クラウドネイティブ化するにあたって立ちはだかったのは、技術的課題、組織的課題、契約的課題の3つだ。
1つ目の技術的課題とは、実現可能な技術なのか、どのような要素技術が必要なのか、あるいは身につけるためのコストや実現するためのコストなど。「技術的課題については、きちんと調査してタスクを分解してどのように対応、判断するかを、地道に繰り返していけば意外と立ち向かうことができます」（伊藤氏）
なぜなら、技術的課題についてはさまざまなエンジニアがナレッジを公開してくれているからだ。ただ、判断が難しいのが、ベストプラクティスに関する扱い。やった方がよいが、やらなくてもどうにかなるために悩まされた。
2つ目の組織的課題とは、組織構造や風土により発生する問題だ。具体的にはどういった組織構造を取るか、取り組むメンバーにはどういう意識が必要か、考えることである。組織構造については、「コンウェイの法則を知っておくと良い」と伊藤氏はアドバイスする。コンウェイの法則とは、組織が自らのコミュニケーション構造を真似た構造のシステムを作り出してしまうという法則である。一方で、開発部門だけではなく、運用、サポート、マーケティング、営業など関わるすべての人たちのコミュニケーションパスを、つくりたいシステムに合わせてデザインしておくのが逆コンウェイの法則だ。そうすることでシステムがコミュニケーションパスに引っ張られないように防御することができる。だが「実際にやろうとするといろんな問題が出てきました」と伊藤氏は言う。
3つ目の契約的課題とは、クラウドネイティブな製品を世の中にリリースするにあたって直面する問題である。「大きな問題が3つあった」と伊藤氏。
1つ目は前例がないこと。技術の話だとエンジニアが発信しているので情報が見つかるが、会社対会社の契約の話になると、情報がまったく流れてこない。
2つ目は法令に関すること。「HULFT10 for Container Services」のようなコンテナ製品はコンテナイメージとデプロイテンプレートのセットで構成されるが、AWS Marketplaceに出品すると、コンテナイメージは米国に配置され、輸出扱いになる。 そのための法律を知らないと出品する段階で手続きが止まったりすることがある。
3つ目は課金に関すること。AWS Marketplaceに出品した場合、売上はドル建てかつマーケットプレイスで管理されることになる。それを社内に連携しないといけないのだが、単純に売上を加算するだけでは、さまざまな問題が発生する。
「技術、組織、契約の課題をいかに解決したかについては菊池から説明したい」と伊藤氏は語り、菊池氏にバトンタッチした。次の章では、各課題の深堀りと、同社がどのようにベストプラクティスを選んだかについて解説する。
「コンテナ版HULFT」だからこそ選んだベストプラクティスでの構築
菊池氏は新卒でセゾンテクノロジーに入社し現在4年目のエンジニア。Go言語やAWSを利用して、HULFTのContainer版「HULFT10 for Container Services」の開発に従事している。
伊藤氏の解説にもあったように、HULFTのクラウドネイティブ化の選択肢は2つあった。1つがベンダーのサービスをフル活用するパターン。もう1つが、コンテナオーケストレーションに対応するパターンだ。ベンダーのサービスをフル活用するパターンは、短期間で構築できる、サポートを集約できるというメリットはあるが、移植性が低い、機能がベンダーごとに異なるというデメリットがある。一方、コンテナオーケストレーションに対応するパターンは、ベンダーサービスをフル活用する場合とまったく逆で、移植性が高い、機能が共通というメリットはあるが、開発が比較的複雑、サポートが分散するというデメリットがある。この2つの選択肢から菊池氏たちが選んだのは、後者だった。「HULFTは先ほども紹介したとおり、いろんなプラットフォーム、同じ機能で互いに通信できることが強み。だから移植性や別プラットフォームでも機能を共通化できることを重視した」（菊池氏）とはいえ「ベンダーロックが悪いわけではない。目的に合わせてやり方を選ぶこと」と菊池氏は補足した。
伊藤氏が「判断が難しい」と語っていたベストプラクティスの付き合い方についても菊池氏は言及。「ベストプラクティスへの対応の選択肢も大きく2つある」という。一つは既存のものをそのまま移行した後にベストプラクティスに寄せていくパターン。短期間で移行ができ、これまでの機能がそのまま使えるというメリットがある反面、技術的負債を残すことになり、またベストプラクティスへの対応要望にタイムリーに応えることができない。
もう1つはMVP（顧客に価値を提供できる最小限のプロダクト）に限定してベストプラクティスで再構築し、優先度の高い機能を過去の資産から移植していくパターン。「ベストプラクティスに沿った設計が出来るのが大きなメリット」と菊池氏。加えて、柔軟な方向転換も可能な一方、移行が長期間となり、機能が足りない場合があるなどのデメリットがある。
この2つの付き合い方のうち、菊池氏たちは後者を選択。先述したように必ずしもベストプラクティスに対応する必要はない。しかし、菊池氏たちが移行時にベストプラクティスに寄せることにこだわったのは、移行先のサービスとの兼ね合いが悪くなり、恩恵があまり受けられなくなるためだった。またオンプレミス向けにつくられたシステムやプロダクトを後からベストプラクティスに移行しようとすると、オンプレミス向けの仕様に引っ張られて変えにくいため、技術的負債になってしまう。
続いて菊池氏はコンテナ設計におけるベストプラクティスの例を紹介。オンプレミス版のHULFTはマルチプロセスかつシングルスレッドで動作していた。これをコンテナ版ではシングルプロセスかつマルチスレッドに作り変えたという。「コンテナオーケストレーションの周辺サービスがシングルプロセスにつくられているため」と菊池氏はその理由を述べる。例えばコンテナ内でマルチプロセスが動作していると、子プロセスが何らかの理由で落ちた場合に、コンテナオーケストレーションで死活監視ができなくなる。親コンテナの作り込みをせず、コンテナオーケストレーションの機能を活用するには、シングルプロセスかつマルチスレッドに再構築する必要があったのである。
さらに菊池氏はMVPで再構築して方向転換の余地を残す理由についても解説。クラウドでは日ごとに新技術、新サービスが出てくる。またそれに紐付くユーザーの要望も次々に変わって行く。つまり方向転換の余地を残す背景は、このリリース速度に適応するためだった。
菊池氏が紹介したベストプラクティスとの付き合い方は、レガシーな技術を含み、社内システムをクラウドに移行する場合にも当てはめることができるという。
AWS Marketplaceでの販売に向けて——組織と契約の問題を乗り越える
クラウドネイティブ化で最も難しかったのが、組織的課題の解決だ。その過程では、他部門との調整や意思決定が欠かせなかったからだ。
従来のオンプレミス版のHULFTは、パートナー経由で販売していた。だがコンテナ版はマーケットプレイスでの販売になるので、売り方や売上情報の上がり方、サポートの仕方などが変わるため、新しく仕様や戦略を決める必要があった。「このような問題の多くを開発が音頭を取って解決を図ろうとしていたことで、なんでも開発に聞こうという風潮ができあがり、中央集権的なコミュニケーション構造になっていった」と菊池氏は話す。他部門との調整や意思決定などのコミュニケーションに時間が取られてしまい、開発を残業でカバーするバンク状態に陥ってしまったという。「中央集権的な構造を取るなら、コミュニケーション専業の人を立てること。一方、目指すシステムが中央集権型でないのであれば、意思決定のコストは各部門に分散されるのが良いでしょう。」菊池氏は、目指すシステム構造に組織のコミュニケーションパスを寄せる、逆コンウェイの法則に基づき、そう解説する。
契約的問題への対応については、「早めに関係各所に問い合わせること」と菊池氏は語る。AWS Marketplaceでの販売方法や課金の仕方、法令対応など、契約関連では前例のないことだらけだった。特にHULFTのようにAWSマーケットプレイスに出品するケースは日本で少なかった。「公式ドキュメントはあるが、情報が足りない、初学者が読むのには難しいなど、うまくいかないことが非常に多かった」と菊池氏は振り返る。だからこそ、早めに問い合わせることが大事だと言うのである。
問い合わせ方にもコツがあると菊池氏。クラウドベンダーは海外に拠点がある。時差もあるうえ、曖昧な聞き方をすると、ドキュメントを案内されて終わってしまうことも多い。「どんなことをして、何を期待したか、実際にはどうなったか、どんな回答を求めているかを可能な限り端的にたずねること」とアドバイスする。
また法令対応については法務部、課金対応については財務部に、早めに相談しておくことも重要だ。HULFTのようにAWS Marketplaceで販売する場合、モジュールは米国に配置され、使うユーザーは世界中になる。そのためEAR判定（米国から輸出される製品や技術に対する輸出管理規則の対象となるかどうかを判定する手続き）への対応が必要になり、その判定に半年かかるうえに、場合によっては100万円単位の弁護士への委任費用がかかることも分かった。
このようにさまざまな課題を乗り越え、クラウドネイティブ化した「HULFT10 for Container Services」。「1カ月無料で使える試用版を用意しているので、関心を持った方は、ぜひ、試してみてほしい」と菊池氏は締めくくった。
データマネジメント、AI活用、モダナイゼーションを軸に、さまざまな学べるセッションをご用意しています。チームみらい党首でAIエンジニアの安野貴博さんや、「ソフトウェア・ファースト」の著者でも知られる及川卓也さん等、多くの著名人も登壇します。詳細はSAISON Technology Days 2025公式サイトにてご確認ください。（登録無料）
