開発

H-E-B、Haskellでメインフレーム移行に成功

テキサス州の小売大手H-E-Bは、COBOLメインフレームからHaskellへの移行プロジェクトを進め、現在約100万行のHaskellコードが本番稼働している。プロジェクトの経緯と課題を、担当エンジニアが報告。

5分で読める SINGULISM 編集チームが確認・編集

H-E-B、Haskellでメインフレーム移行に成功
Photo by Florian Olivo on Unsplash

テキサス州を拠点とする小売大手H-E-Bが、COBOLで動作するメインフレームからHaskellへの移行を進め、現在約100万行のHaskellコードが本番環境で稼働している。このプロジェクトは単なる言語移行ではなく、数十年にわたるビジネスロジックを新しいアーキテクチャに載せ替える大規模な取り組みだ。H-E-Bのエンジニアであるジョシュア・ミラー氏が、Haskell公式ブログに寄稿した記事で詳細を明らかにした。

メインフレームの限界

ミラー氏が2018年にH-E-Bに入社した当時、同社の基幹システムはCOBOLで書かれたメインフレームが支えていた。小売業であるH-E-Bはテキサス州最大の非公開企業であり、顧客にとって重要なのは棚に商品が並んでいることであって、背後にあるシステムではない。その期待に応えるべく、メインフレームは長年にわたり安定した動作を提供してきた。

しかし、顧客の期待は変化した。カーブサイドピックアップや宅配、リアルタイム在庫管理、店内検索などのデジタル機能が登場したのは、ここ10年のことにすぎない。こうした需要に応えるには、435以上の店舗と配送センターを結ぶサプライチェーン全体の拡張が必要となる。既存のメインフレームは、このような成長に対応できる設計にはなっていなかった。

他の多くの企業と同様、H-E-Bでもメインフレームをクラウドへ移行する選択肢は検討された。しかし、単なるリフトアンドシフトでは数十年来のビジネスロジックに埋め込まれた組織固有の知識を失うリスクが大きい。数百ものテーブルを扱うモノリシックなアプリケーションを、自律したチームが運用するマイクロサービスに分割する作業は、技術的にも政治的にも巨大な挑戦である。

ラムダへの飛躍

この状況に対し、コンサルタントが提案したのがHaskellだった。Haskellを共通言語として、最大のメインフレームアプリケーションを置き換える新プロジェクトが始動した。ミラー氏はこのプロジェクトの初期から参加し、本番環境で現実の影響を与えるプロジェクトでHaskellを使えることに興奮したという。

実験として始まった取り組みは、今や重要なサプライチェーンアプリケーションを稼働させる複数の本番システムに成長した。8年が経過し、複数のチームが異なるドメインで維持するHaskellコードは約100万行に達している。一定の成功を収めた一方で、課題も存在した。

Haskell採用の壁

プログラミング言語をビジネスソリューションとして提案することは容易ではない、とミラー氏は指摘する。Haskellは特にその認知度が低く、関数型言語への抵抗感も根強い。プロジェクトが成功した背景には、Haskellの型安全性や表現力がレガシーシステムの複雑なビジネスロジックを正確にモデル化する上で有効だったこと、またチームが言語習得に十分な時間を投資したことが挙げられる。

編集部の見解

短期的に見れば、H-E-Bの事例はエンタープライズHaskellへの関心を再燃させる可能性がある。メインフレームからモダンな言語への移行は多くの企業が直面する課題であり、Haskellがその選択肢として現実的な成果を挙げたことは、関数型言語コミュニティにとって追い風となる。特に、COBOLのようなレガシー言語からHaskellへの移行は、型システムの厳格さがビジネスロジックの保全に寄与するという点で説得力を持つ。 長期的には、Haskellはエンタープライズ領域で一定の地位を築くかもしれない。しかし、採用障壁の高さ(学習曲線、ライブラリの成熟度、人材確保)がネックとなる。H-E-Bのように大規模かつ長期にわたるコミットメントが可能な企業でなければ、Haskellの導入は難しい。とはいえ、RustやElixirなど関数型の要素を取り入れた言語が増える中、純粋関数型言語の価値が再評価される機会となるだろう。 編集部としては、本番環境で100万行のHaskellを運用するという実績は、単なる言語信仰ではなく、確固たるビジネス要求に基づいた選択である点が重要だと考える。

参考

よくある質問

H-E-Bのプロジェクトでは具体的にどのようなアプリケーションがHaskellで書かれているのか
記事では「重要なサプライチェーンアプリケーション」と説明されているが、具体的な機能(在庫管理、配送最適化など)については明らかにされていない。今後の続報が待たれる。
なぜクラウドへの移行ではなくHaskellを選んだのか
クラウドへの単純なリフトアンドシフトでは、数十年のビジネスロジックに埋め込まれた組織固有の知識を適切にモダナイズできないことが理由として挙げられている。Haskellは型安全性と表現力により、複雑なロジックを正確にモデル化できると判断された。
他の企業でも同じようなHaskell移行は可能か
可能だが、言語習得のための投資と長期的なコミットメントが必要。H-E-Bのように8年にわたるプロジェクトを継続できる組織体力が求められる。また、COBOL同様にHaskellの人材確保も課題となる。
出典: Lobsters

コメント

← トップへ戻る