株式会社フェリシモ
本社：兵庫県神戸市
設立：1965年
資本金：18億6800万円（2022年2月末）
売上高：337億2900万円（2022年2月期）
従業員数：745名（連結、2022年2月）
事業内容：ダイレクトマーケティング事業
https://www.felissimo.co.jp/
幅広い年齢層の女性を主なターゲットとして、ファッション、子供服から生活雑貨、手作り雑貨、手芸、レッスンプログラムなどのバラエティに富んだ商品をオンラインショッピングで販売する総合カタログ通販企業として成長している。
IBM i中心の考え方から
データ中心アーキテクチャへ
フェリシモは受注管理、顧客管理、在庫管理、商品管理、債権管理といった基幹システムをIBM i上で運用している。もともとはメインフレームユーザーであったが、2009〜2014年の5年間を費やして、システム統合とTCO削減を狙いにアーキテクチャを刷新し、IBM i上で基幹システムを全面再構築した。
基幹システムであるIBM iを中心に据え、そこをハブとして、オープン系環境で開発した周辺システムや外部システム、たとえばECサイトや業務支援、情報系などの各種システムを連携させたスター型構成のアーキテクチャを構成した。
IBM iには膨大な量のデータが蓄積されており、周辺システムでそれを活用する機会は多い。例を挙げるなら、ワークフローエンジン上で開発された多彩なアプリケーション、たとえばキャンペーン管理や顧客に発送する文書管理、ポイント管理といった各システム。あるいはコールセンターで利用するCRM／CTIシステム、自社倉庫で活用する出荷管理システムなど、少なくとも20種類以上の周辺システムがIBM iと連携し、基幹データを活用している。
しかしそうした運用を続けてきた結果、基幹システムを中心とした巨大な密結合システムが出来上がった。そのためシステム変更の影響範囲が大きく、システムの維持・追加・変更に多くの工数やコストが発生していた。
とくにECサイトやWebサービスなど、顧客接点であるフロントエンドシステムでは、ニーズに迅速に対応するため頻繁に改修が発生する。しかし基幹システムとの結合度が高いがゆえに影響範囲が広く、迅速な改修を阻んでいた。
そこで同社ではIBM iを中心にしたアーキテクチャから、IBM iを他のシステムと同じようにデータソースの1つに地位付ける「データ中心アーキテクチャ」への転換を図っている。
アーキテクチャの中央に位置するのはIBM iではなく、データやサービスを共有・管理するための「データハブ」である。
データハブの実体は、クラウドストレージ上で稼働するRDBMSとスキーマレスDBであり、定型データから非定型データまで、あらゆるデータが存在する。基幹システムを含む多様なアプリケーションからこのハブへデータを集約し、蓄積・加工・配信して活用する。
システム同士の連携を避け、データハブ経由で連携させることで、密結合を解消して、各システムの独立性を高めようというわけだ。
こうしたアーキテクチャでは、システム連携の手法が非常に重要になると、山下直也部長（ビジネスプラットフォーム本部 IT推進部）は次のように指摘する。
「IBM iという単一のシステム環境内であれば、これまでのスキルセットを活用して影響範囲を探りつつ、対処することが可能でした。しかし周辺システムとの連携の規模や数が急速に増えつつある中、保守運用性や連携コストを考えると、従来のアーキテクチャや連携手法を変更する必要が生じていました」
リアルタイム性を求める場合は
「API-Bridge」によるAPI連携
データ中心アーキテクチャへの移行は今も進行中である。現時点ではデータハブの構築が完了し、開発ルールとして原則的にアプリケーションからのデータハブのDBの直接参照を禁止。各システムで利用したい場合は、システム側にデータをもたせて利用する構成をとっている。これは、データハブを単一障害点にさせないためである。
「DBの直接参照を原則禁止にした場合、すべてをファイル連携で実施するのかと考えることになります。ファイル連携には、それぞれメリットとデメリットがあります。メリットとしてはシステムの責任分岐点が明確になり、保守性を高められる点が挙げられます。たとえば基幹システム側から周辺システムへファイルを送出してしまえば、なにかエラー処理が発生しても、それは周辺システム側の問題として対処できるわけです」と語る山下氏は、さらに次のように続ける。
「一方、デメリットとしてはリアルタイム性に欠ける点が挙げられます。ビジネススピードが急速に加速するなか、リアルタイム性を高め、リードタイムを短縮すべき業務は確実に増えています。従来は、各システム同士のDBを直接参照する方法で対応してきました。しかし前述のとおり、データハブのDBを直接参照させると単一障害点となってしまいます。データのリアルタイム性を求めたい場合は、複数システムからの取り扱いを鑑みると、APIで連携させたほうが有効ではないかと考えました」
IBM iのAPI化について、当初はOSのネイティブ機能を利用したり、オープンソースツールであるSwaggerをテスト的に使用したりと、試行錯誤を続けていた。そんななか、2022年1月に「API-Bridge」（オムニサイエンス）と出会う。
もともと同社はデータ分析ツールとして「PHPQUERY」（オムニサイエンス）を利用しており、その縁でAPI-Bridgeの存在を知ったのである。
「トライアル利用を進めた結果、これまでのIBM iのスキルセットを活かしたAPI開発が可能で、連携コストを確実に削減できると判断し、この秋に正式導入を決めました。当社にはIBM iの開発者とオープン系の開発者がいますが、今後はAPI-Bridgeを通じて、APIに処理を寄せていくことで、IBM iの開発者スキルのオープン化・標準化が図れればと考えています」と山下氏は語り、さらにこう続ける。
「アプリケーションによっては、バッチ的なファイル連携で要件を満たす場合もあれば、どうしてもリアルタイム処理が求められるケースもあります。要件をよく見極め、必要に応じて段階的にAPI化に着手していく予定です。今後は確実にAPIの数が増えていくので、全社的なAPIの管理が必要になるでしょう。基幹システムの疎結合化を進めていく中で、API管理はキーワードになってくると考えています。再利用性を高めなければ、保守性・運用コストが上がるリスクがあるので、API設計スキルの向上もセットで取り組んでいます」
データ中心アーキテクチャへの移行は、5〜8年程度のロードマップで描かれており、今はまだ移行途中である。基幹システムの一部を外部へ切り出しつつ、疎結合化を進めていく計画である。疎結合と密結合をどう棲み分け、組み合わせていくかは大きなテーマであり、API化の手法と考え合わせながら推進していくようだ。
［i Magazine 2022 Autumn（2022年11月）掲載］
