大手総合カタログ通販企業のフェリシモは、
新しいシステム基盤への移行を進めている。
IBM iを中心に密結合で構築したシステムを抜本的に見直し、
アーキテクチャを全面的に変更して、
変化への即応性と柔軟性に富む仕組みを導入する。
同社IT推進部の山下直也部長と日本IBMの佐々木幹雄氏に、
フェリシモの取り組みと意義ついて語り合っていただいた。
山下 直也氏
株式会社フェリシモ
IT推進部 部長
佐々木 幹雄氏
日本アイ・ビー・エム株式会社
パワーシステム テクニカルセールス
シニアITスペシャリスト
TCO削減を目的としたシステム統合が
逆に足かせになる
山下 当社は今年で創業57年になりますが、システム化の流れではいくつかの節目がありました。
創業から1990年代後半まではカタログ通販事業の急速な拡大に合わせて、いかに生産性を上げていくかがテーマでした。年々増加するお客様の注文データなどをいかに効率よく処理していくか。キーワードとしては「汎用機」や「バッチ処理」が挙げられますが、システム化の目的は大量データの処理であり、手作業からのシステム化ということで、ほぼすべてのシステムをスクラッチで開発していました。
2000年前後になると、インターネットが普及し始めました。当社もいち早くシステム化に着手し、インターネット上でのカタログ通販事業を確立しました。汎用機とは別のシステムをインターネット通販用として作ったのです。
そうこうするうちに、汎用機上の通販システムとインターネット通販用のシステムを、同じビジネスロジックでありながら2つ同時に維持・管理することの負担が大きくなってきました。
そこで、システム全体の維持管理のしやすさとコスト削減を意識してアーキテクチャの変更に取り組み始めたのです。このときのキーワードは「システム統合」と「TCO削減」です。アーキテクチャの変更とシステム統合を同時に進める大規模な基幹刷新プロジェクトとなり、さまざまな苦労や課題もありましたが、その結果として、TCOの削減は大いに効果が上がりました。
プロジェクトの進行中にクラウドが台頭し始め、システムの変更・変化を急いで求める潮流が拡大してきました。ちょうどiPhoneが普及し始めた頃で、手のひらの中の世界に対してカタログ通販事業として何をご提供できるのか、真剣に悩んだ時期でもありました。
当社ではフロントシステムのインフラをクラウド化することで、オンプレサーバーの運用負担を減らし、スケールしやすい世界を手に入れました。一方で全体のアーキテクチャ自体は密結合であり、ロジックの追加や変更などにおいて、変更コストが大きく、迅速なリリースが難しくなり、小回りが利かないシステムとなっていることが大きな課題となりました。
揺り戻しと言いますか、TCO削減を目的としたシステム統合が逆に足かせになりつつあり、小回りが利くように疎結合なアーキテクチャへ刷新するべく、次期アーキテクチャへのシフトをスタートさせています。
佐々木 従来のシステムが密結合ゆえに足かせになっているという課題意識は、多くのIBM iユーザーの間でも急速に広がりつつあるように思います。端的に言えば、プログラムの改修やシステムの拡張が思うように進まないということですが、その課題意識について話をうかがったのはフェリシモ様が非常に早かったと記憶しています。
今目指しているのは、どのようなシステムですか。
データはハブに集中させ
アプリケーションは最適な基盤に配置
山下 一番のポイントは、アジリティを前提とした疎結合アーキテクチャということです。ただし、疎結合に変えていくだけでは、過去の課題であるTCOが増加してしまいます。そこで単純な揺り戻しではなく、過去の課題を解消しつつ、疎結合化していく方法を検討しました。
方針としては、ハブ＋疎結合システムです。データという共通に管理すべきものは2重化せずに、一元管理を目指します。そのためにデータハブという概念を中心に置き、アプリケーションは最適なインフラで稼働するようにします。そしてアプリケーション側でデータが必要になったら、中央のハブから配信するという仕組みです。
ビジネスロジックに関しては、密結合のシステムから個々のインフラへ複製という形で切り出します。そして元のアプリケーションとは関係性を断ち切ります。その結果、アプリケーションのメンテナンスが2重になる可能性もありますが、切り出した先では小回りが利くようになります。マスターデータやトランザクションデータはハブを通じて共通化するため、データの維持・運用コストが2重になることはありませんし、ハブを介することでアーキテクチャの変更を段階的に実行することが可能です。つまり、密結合と疎結合を使い分ける考え方でシステム化を進めています。
佐々木 まさにデータ中心設計の考え方ですね。非常に合理的な考え方だと思います。
オンプレミスで構築されてきたシステムは、使われ方のパターンがある程度決まっているために密結合を選択し、可用性を高めるアプローチを取ってきました。しかし今のDXの文脈で重要視されているのはそこではなく、山下さんが言うように、変化への即応性や柔軟性です。変化に対していかに機敏に対応し、低コストですばやく展開するか。今、そこへ向かってシステム再構築の動きが広がっていますが、その中でもフェリシモ様は全社を挙げて、率先して進んでいる印象です。
山下 私のエンジニアとしてのスタートは、RPG ⅡのプログラムをRPG Ⅲへと書き換えるところから始まっていて、リアルタイム性や密結合をベストとする考え方をずっと引きずっていました。しかし、当社のシステムが密結合ゆえに問題となってから、その考え方を変えました。「リアルタイム性＝密結合」という設計思想から、疎結合にしても連携の頻度を高めたらよい、という考え方にシフトしたのです。
そう考えた背景には、テクノロジーの進化があります。昔はストレージが高価だったのでデータを1カ所に集めて無駄なく使うことが奨励されましたが、今はクラウドがあるので、使わないときはオフにして、使うときだけオンにすることが可能です。だからストレージを密結合から解放して切り出すことが可能になります。
通信速度の向上も同様です。昔は大量のデータを外へ出すと1日がかりの転送になることもありましたが、今は5分、10分で済んでしまいます。であれば、データを外に配置できる。テクノロジーの進化によって考え方が真逆になることもあるわけですね。
経営層や社内を巻き込むには
「言葉の変換」が非常に重要
佐々木 山下さんが今さらっとお話しになった、リアルタイム重視からそうでないものへの考え方の転換は、実は非常にむずかしいことです。かつての山下さんのように、リアルタイム性は絶対に変えてはいけないという考えを持っている開発者や運用担当者は、とても多いと思います。
たとえば、オンプレミスとクラウドに同じデータがあるのなら、2フェーズコミットで完全に同期させないといけない、と考える。すると、システムにいろいろな制約が生まれてしまいます。その結果、DXで本来やりたいことや新しいアプリケーションのすばやい開発が思うようにいかなくなる。
そうした話を私はよくお客様にするのですが、理解はしていただけるものの、実際の行動へ移されるお客様はそう多くはありません。山下さんが考え方をシフトし、会社やシステム部員を巻き込んで大きな方向転換を果たされたことは、とても大きな功績だと思いますね。
山下 それはQCD（品質・コスト・納期）という昔からあるフレームワークのどこを重視するかだと思います。リアルタイム性（Q）を突き詰めると、コスト（C）や納期・スピード（D）は犠牲になる。昔はそれでよかったのですが、今世の中で求められているのは間違いなくDでしょう。企業システムは限られたリソースの中でバランスをとって進めていくしかないので、スピードを出すならリアルタイム性をあきらめるしかない、という考え方に行き着きます。
佐々木 正しいアプローチだと思います。会社やシステム部員を巻き込んでシステム化の方向を変えていくときに、注意していることはありますか。
山下 アーキテクチャの変更によって何が変わるのかを、経営から見たときの言葉に置き換えて伝えるということでしょうか。システムの改訂を早くするために、とか改修のスピードを上げるためとしたら、それはIT側の都合だろうとなってしまいます。そうではなくて、市場の変化に付いていくためとか、お客様のニーズに対してデリバリーを早くするためといった経営視点やお客様視点の言葉に置き換えることによって、やろうとしていることの目的と成果をはっきりさせることができ、結果が得やすくなると思っています。
システム部門は、システム部門の言葉で仕事をしがちですが、経営視点やお客様視点の言葉に置き換えることによって社内を巻き込むことができるようになります。「言葉の変換」は非常に重要です。
佐々木 私どもも「言葉の変換」の重要性をお客様にお話しするのですが、山下さんのように自信をもって発想の転換を実践されている方は少ないように思います。
山下 無理に発想を変えていくのではなく、当事者たちが納得して変わっていくことが重要です。企業の目的はお客様の利益の追求とその延長上にある社会変革の追求で、その目的を共有する人が社員です。だから営業だろうがシステム部門だろうが本来の目的は一緒ですから、発想を切り換えると言うよりも、本来の目的を見直せば済むはずです。私どもの会社では非常に明確な企業理念があり、発想を変えていくうえで企業理念に基づいているかどうかを常に指針としておくことができます。指針が不明確な際は、何のためにしているのかの目的を追求していけば、部門にかかわらず共通のゴールにたどり着けるのではないでしょうか。心の底に眠っているものの言語化だけの問題ではないかとも思いますね。
「開発」「運用」の担当分けをやめ
ファンクションごとにチームを作る
山下 システム部門とそれ以外の部門は対立関係になりやすい構造なのですが、視点をずらせば「対立」ではなく「協業」と捉えることが可能です。
今までの働き方は、事業部門（ユーザー）は要望者、IT部門は実現者として、責任分岐点を明確にして業務を進める分業が中心でした。そして個々の部門の利益を追求していくと、部門間で利益が相反することがよくありました。しかし、そうした「分業」ではなく、視点をずらして共通の目的を見るようにし、相手側に踏み込んでいく（いわゆる越境していく）ことで、ITの人間が事業を考えたり、事業の人がITを考えることが起こるようになります。
オープンソースの理念の中に、システムのバグや不具合は皆でつぶすという考え方があります。システム部門も、システム開発ではそうしたことを実践しているのですが、仕事の進め方自体はそうなっていないことのほうが多くあります。システム部門が他の部門と「協業」や「越境」ができれば、部門を横断したアジャイル的な動き方・働き方が可能になると思うのです。
佐々木 それはDevOpsやCI/CD（継続的インテグレーション/継続的デリバリー）につながる世界のことですね。DevOpsやCI/CDは、システム部門だけで取り組んでも独り相撲になるだけで、絶対にたどり着けない世界です。プログラムの開発をシステム部門だけの仕事とするのではなく、業務部門に参画してもらって進めることが不可欠なのですが、その体制に行き着けないお客様も多くおられます。コンテナやマイクロサービスを使ってシステムを構築しても、それを活かすDevOpsの体制がないために行き詰ってしまっている例をよく目にします。
山下 当社では2000年代にシステムを密結合に変えた頃に、組織を「開発」と「運用」に分けました。そして現在はその分け方を撤廃して別の形にしているのですが、そもそも「運用」という言葉が非常によくないと思うのです。開発とはシステムを作る人、運用とはそれを回す人、のような「開発者＞運用者」というイメージができあがっていますが、実際はシステムを回すだけでなくサービスも提供しています。エンドユーザーに対してよりよいサービスを提供する役割を担っているわけですね。
佐々木 確かに、インフラのサービス部門と言えますね。
山下 そこで当社では、開発と運用のチーム分けを止めて、ファンクションごとにチームを括り直すことにしたのです。考え方としては、ファンクションに関わる企画・開発・運用といったすべての作業を1つのチームが担います。
運動会で例えて言うと、バトンリレーから騎馬戦への変更です。バトンリレーは一人が走ってバトンを渡して次の人が走る形ですが、騎馬戦は数人がチームを組んで１つとなり、上に乗る人ががんばったり下で担ぐ人ががんばったりと、お互いを考えながらいろいろな戦い方ができます。
佐々木 騎馬戦は、まさにアジャイル的な戦い方で、それに合ったチーム編成ですね。
山下 アーキテクチャと組織形態は追従するものだと思うのです。密結合のシステムでは開発と運用を明確に分けた大きなチーム編成が合いますし、粒度の細かいシステムを集めたアーキテクチャであれば、小単位のアジャイル的な動き方が可能なチーム編成が向いています。
佐々木 どちらか一方を変えても、アーキテクチャと組織形態がちぐはぐだと成功は難しいでしょうね。
山下 アーキテククチャの変更と組織・プロセスの変更に加えて、今、密結合から疎結合への転換にあたってレガシーをどうするか、交通整理を進めているところです。一般的によくあるのは、「脱レガシー＝脱ホスト＝ホストに関わるすべて」ですが、脱レガシーとしたときに、インフラを捨てるのか、その上のアプリケーションを捨てるのか、開発言語を変えるのか、そこに至る開発プロセスを変えるのか、課題を整理していくことで検討することが多くなり、その交通整理が必要だと考えています。
IBM i自体が1つのコンテナ
移行コストをゼロにする奇跡の箱
佐々木 どのように考えているのですか。
山下 脱ホストに関しては、IBM iを捨てるという考え方はまったくしていません。IBM iは、アプリケーション資産の継承性の点では、マイグレーション・コストをゼロにする奇跡の箱だと思っています。その点は他のプラットフォームの追随を許さない最強の部分だろうと思います。
一般にコンテナ化とは、インフラの変更や差異に関わるコストを最小限に抑える考え方です。そのことを踏まえると、IBM iはシステム全体が1つのコンテナであり、箱だけ差し替えてもそのまま動くプラットフォームと言えます。
ただし、その上に載っているアプリケーションの作り方や形態がレガシーである場合どうするか。変更や変化が不要ならば、IBM i上でそのまま稼働させるほうが効率的でしょう。しかし営業時間にしか使わないのならクラウドへ上げ、使いたいときだけ動かすほうがコスト面で効果が出ます。
IBM iは、資産継承性のような卓越した部分を活かしつつ、テクノロジーの進化を活かしオープン系技術とうまくミックスさせるような棲み分けの考え方が普及すると、もの凄く強力なマシンになるだろうと思います。
佐々木 山下さんにそう言っていただけると非常に説得力がありますね。私どももクラウドへリフトし、IBM iのアプリケーションをコンテナ化することをお勧めしていますが、踏み込んで考えておられるお客様は、残念ながらまだ少数派です。
山下 コンテナに関しては、システム管理者の視点で言うと、使いやすさや作りやすさよりも、万一のときの戻りやすさが大きなメリットとして映ります。戻りやすさがあるからこそ一歩踏み出せる、と考えられます。
佐々木 どこででも動くのがコンテナのメリットですが、どこででも動くからこそ、万一のときはすぐに戻せるということですね。
新たな疎結合へ転換するプロジェクトは、かなり進んでいるのですか。
山下 まだ始まったばかりで、登山で言えば地図を持って登り始めたところです。基幹システムの中ではさまざまなシステムが統合されて稼働しているので、一斉に変えるととてつもなくコストがかかり、大きなリスクを抱え込みます。少しずつ変えていくアプローチを取っています。
佐々木 一番苦労されているのは何ですか。
山下 レガシーシステムのどこを切り出すかという切り出し方の問題ですね。それとオンプレミスとクラウドの両方で、インフラとアプリケーションをどう設計するか、という問題にも直面しています。
佐々木 そこは一般的に活用できるベストプラクティスがない領域ですね。真剣に取り組むと、そこが課題になるだろうと思います。
山下 その解決のヒントを得るために、いろいろな人に話をうかがっています。これは当社のシステム部門の考え方でもありますが、とにかく外を見て情報を吸収し、いいところはどんどん採り入れようとしています。当社の企業文化として独自性を重要視するのですが、ITインフラに関しては独自性を出すと維持・運用面でデメリットが大きいので、横展開可能なベストプラクティスを追求していく方針にしています。
ベンダーの方が営業に来ても、ただ話を聞くのではなく、これを教えてほしいとか一緒に考えてくださいということを積極的に申し上げています。そのことはベンダーにとっても目的に適うはずで、製品をよりよく使えれば、次の取り組みにもつながります。長いお付き合いが生まれ、絆も深まります。
佐々木 IBMは今年、組織体制を過去にないくらい大幅に変更し、「Go To Market」をスローガンに取り組みを始めています。その目指すところはお客様との共創で、お客様と一緒に作ろうというモデルです。今までは「新しいIBM iはいかがですか」というご提案だったかもしれませんが、今はコンテナやクラウドやサービスなども材料にして、うまい使い方を一緒に考えましょうという体制に変わっています。今までとは違った価値をご提供できる体制を整えています。
山下 それはいいですね。大いに期待しています。
◎会社概要
株式会社フェリシモ
設立：1965年5月
本社：兵庫県神戸市
資本金：18億6800万円（2019年2月末）
連結売上高：288億8200万円（2019年2月期）
連結従業員数：800名（2019年2月末）
事業内容：ダイレクトマーケティング事業
https://www.felissimo.co.jp/
［i Magazine 2021 Spring（2021年4月）掲載］
