山下 直也氏
株式会社フェリシモ
ビジネスプラットフォーム本部
IT推進部 部長
インターネットという最も変化の激しい領域にビジネスの軸足を置くなかで、基幹システムと密接に連携しているがゆえに迅速に動けない。その解決に向けて、フェリシモは基幹システム中心のデータ共有型モデルからデータ中心アーキテクチャへと、新しいシステム基盤への移行を進めている。最前線で指揮を取る山下直也氏に、そのコンセプトを聞く。
i Mag 猫の肉球の匂いがする「肉球ハンドクリーム」が話題でしたね。
山下 当社はファッション、生活雑貨、手芸、レッスンプログラムなどのバラエティに富んだ商品をECやカタログを通じてお客様にお届けするダイレクトマーケティング企業ですが、お客様と一緒になって何かを生み出していく仕掛けづくりの1つとして、「フェリシモ部活」を展開しています。現在は「フェリシモ女子DIY部」や「フェリシモ魔法部」など14の部活が活動中で、先ほどのハンドクリームはその1つである「フェリシモ猫部」から生まれた商品です。
i Mag 山下さんはいつフェリシモに入社されたのですか。
山下 私が新卒で最初に入社したのは家庭用インテリアメーカーでした。そこはIBM iユーザーで、情報システム部門に配属された私は、RPG IIで書かれたプログラムをRPGⅢに書き換えていく開発者としてキャリアをスタートさせました。その後、2007年にフェリシモに転職しました。
当社はもともとメインフレームユーザーだったのですが、転職してまもなく構想・企画を繰り返していた基幹刷新プロジェクトが再開されました。2009 〜2014年の5年間を費やして、システム統合とTCO削減をテーマにアーキテクチャを刷新し、基幹システムを全面再構築する大規模プロジェクトでした。債権管理、商品管理、そして販売管理の各システムを3段階でメインフレームからIBM iへ移行しました。開発言語はILE RPGで、業務画面はすべてWeb化しています。
もちろん外部ベンダーの手を借りていますが、上流から 下流まで全工程を自分たちの手でコントロールし、ストレ ートコンバージョンではなく、さまざまな新しい要件を反 映して作り込んでいく相当にタフなプロジェクトでしたね。私はこの時期に、さまざまな経験や気づきを得ました。最も痛感したのは、「使う人（ユーザー）」「設計する人（IT部 門）」「実装する人（外部ベンダー）」の3者間のコミュニケ ーションが少しでも滞ると、どんなに卓越したテクノロジ ーでもうまく使いこなせないことですね。要件定義で合意 できていたはずの内容が、設計レビューで実装できていないとわかったり、受入テストの段階で想定と異なるといったクレームになることが多々あり、日本語でドキュメントに記載されていても、受け取り方がこうも違うのかと、頭を悩ませました（笑)。
i Mag 部長に就任されたのはいつですか。
山下 新しい基幹システムの全面稼働後は、運用グループ のサブリーダーとして、チケット管理システムである Redmineを導入し、開発案件やインシデント管理、ナレッ ジ蓄積など、運用や開発プロセスの整備を行いました。そ の後、全社のITインフラを企画・運用するインフラ基盤グ ループのリーダーを経て、2019年に部長に就任しました。メインフレームからIBM iへ移行して、システムを全面刷 新したことで、高コスト構造からコスト削減できた一方で、メインフレーム時代からの課題であった業務ロジックやデ ータモデルのシンプル化にはメスを入れられず、リリース 時点で複雑なモデルのシステムができ上がっていました。 ASISに対して課題を1つずつ、つぶしながら進めていった 一方で、機能の断捨離や、TOBE像の描き方が弱かったな どの反省点もあります。既存メンバーによるボトムアップ 型のアプローチだとどうしても改善ベースとなり、あるべ き姿を描く力が弱い。かと言って、外部コンサルなど現状把握が弱いメンバー主体で進めると、絵に描いた餅となる。両方のバランスをとることの必要性を感じました。
i Mag 最も大きな課題として残っていたのは何ですか。
山下 当社は1980年代からスクラッチ型の開発を続け、システムを充足させてきました。それらの各システムをIBM iへシステム統合した結果、基幹システムを中心にした巨大な密結合システムができ上がりました。そのためシステムの維持・追加・変更に、多くの工数やコストが発生していました。さまざまな変化が求められる現在、とくにECや Webサービスにおいて、顧客接点であるフロントエンドシステムと基幹システムの結合度が高いために影響範囲が広く、変化が必要な際に迅速に改修していけないわけです。安定稼働、資産継承性は基幹システムの最優先課題では ありますが、一方でインターネットという最も変化の激しい領域にビジネスの軸足を置く中で、基幹システムと連携しているがゆえに迅速に動けないという状況に直面しました。モバイルデバイスが普及し、生活もよりインターネット化が進む中で、基幹システムを中心に置いたままでIT環境を描くのは危険ではないかと思い始めました。
IBM i自体は資産継承性が高く、システム都合によるマイグレーションコストがほぼ発生しない素晴らしいインフラです。ただ変更・変化が多い機能やシステムに関しては、コンテナやクラウドなどのオープン系基盤のほうが向いており、機能ごとに適材適所を棲み分けたほうがよいと判断しました。つまり基幹システム自体にも柔軟性をもたせたいが、不確実性が高まってきている中で、基幹システム再構築といったビッグバンプロジェクトの実施や、システムの長期停止を伴う移行はリスクが高すぎます。
巨大な基幹システムに保有する機能やデータをサービス側へ少しずつステルスにシフトさせていく、その切り出し 方を試行錯誤しているうちに、システムの中にロジックと データを一緒にもたせることが問題なのではないか、とも 考えました。こうしてロジックとデータをきちんと切り分 け、基幹システムを中心としたシステム共有型モデルから、データを中心としたアーキテクチャへ移行する必要がある との考えに至りました。
i Mag データ中心アーキテクチャとは、具体的にはどのような環境ですか。
山下 今までは、基幹システムであるIBM iを中心にさまざ まなシステムと連携・結合させたアーキテクチャでした。 IBM iは大きな母艦であり、IBM iを中心にECや業務支援、情報系などの各種システムを連携させるスター型構成です。その構成から、IBM i 自体も各種システムと同じデータソ ースの1つであると位置づける。そして別途中央に、共有 データやサービスを管理するための「データハブ」を構築 し、基幹システムなど多様なアプリケーションからデータ を集約・蓄積・加工・配信して、全社的な活用を目指しま す。データはシステム側ではなく、データハブ側で一元管 理し、アプリケーション処理への依存度を下げることで独 立性を高めます。
一方、ビジネスロジックに関しては基本、各システムで内包させますが、必要に応じてAPI化し、サービスハブとしてデータハブ領域に配置させます。このデータハブの概念に関しては、それこそ絵に描いた餅にならないように、外部コンサルと徹底的に壁打ちをしながら、段階的な移行を突き詰めていきました。そうするうちに、このデータハブ環境をデータ統合基盤にも流用することにしたのです。これはデータ活用におけるデータ連携・加工のコストや工数を削減することにも役立ちます。
i Mag 今、DXの文脈では「データ活用」が非常に重視されていますね。
山下 そうですね。当社は早い時期からユーザー部門主導で、データ分析基盤を構築してきたのですが、データソース側では、データウェアハウス（DWH）に合わせたデータ加工・変換に多額のコストが発生していました。DWHにデータを集めようとすれば、データを送るシステム側がDWH仕様にデータを加工・変換する必要がある。そうなると連携コストが障壁となってデータが不足するし、データ品質の低下も招きます。
今回構築したデータハブ環境は、さまざまなデータが集まる場所となります。ここはETLツールによりデータの加工・変換機能を高めているので、データ活用を行いたい分析領域に関しても、データハブを介して送信すれば、データの品質を担保できる。つまり、全社のデータ連携をデータハブで統合的に管理したほうがよいと判断しました。 また、データ活用を推進させる仕掛けづくりにも着手し ています。ビジネス部門にはデータの明確な利用目的があるけれど、データ区分の意味理解や、必要なデータを集める開発ができない。まだまだデータはシステムが処理するもの、というイメージが強いです。
一方でIT部門はデータを理解し、データ連携の開発はできるけれど、システムで使う目的以外で、ビジネスでどのようにデータを使えばよいかがわかりません。だからデータを連携して終わり、BIツールなどを導入して終わりになりがちです。活用側にまで関与することが少ない。また失敗が許されないと思い込み、クイックな開発や試行錯誤が苦手です。こうした課題は、多くの企業に共通しているのではないでしょうか。
そこで双方の苦手な領域を補うために、データカタログの整備に取り掛かっています。データ設計や区分値などの意味理解をシステムの言葉でなく、人間にわかる形に置き換えることで、ビジネス部門での理解を支援し、活用を推進します。また、データがビジネスにどのように使われるのかをビジネス部門側が補足・追記することで、IT部門側ではデータとビジネスの紐づきを理解し、ビジネス部門側へよりよく提案できる材料を得られる。すなわち「、データの民主化」を実現しようというわけです。
さらにデータ活用のための連携開発では、失敗を繰り返しながら精度を高めていけるよう、他の環境へ影響しないように独立した環境を用意し、ETLツールや複数のデータソースを共通的に取り扱えるBIツールによる内製化を推進しています。
i Mag データ中心アーキテクチャへの刷新には、どのぐらいの期間がかかりそうですか。
山下 大きなロードマップとして5〜8年スパンだろうと想定しています。まずはデータハブの構築を完了させましたが、基幹システムの疎結合化に関しては、各システムのリプレースに応じて、順次データハブを介して移行していくことで、結果として全体的なシステム構成が疎結合になるといった進め方をしています。基幹システムの再構築といったビッグバン型のプロジェクト実施は、今のところ考えていません。
i Mag IBM iの疎結合化は具体的にどのように進めていくのでしょうか。
山下 本丸である基幹システム自体の内部システムを切り出していくプロセスについては、疎結合と密結合をどう棲み分け、どう組み合わせていくかが今後の大きな課題ですね。巨大な密結合の塊である基幹システムの中から、どの部分を疎結合にして切り出していくか。疎結合にすればするほど、運用コストが増大していくので、TCOを改善するメリットから見れば、無理に切り出さないほうがよいとも言える。基本的にはユーザーインターフェースに関わる領域だったり、他システムでも利用したい、あるいは他との共通性があるようなビジネスロジックをAPIで切り出していくことになるでしょう。
たとえば当社の場合はECサイトを運営していて、販売管理システムの中でも受注のインターフェースは時代に応じて頻繁に変わるので、受注プロセスに対するインターフェースは疎結合化が望ましいわけです。しかしマルチチャネルを意識した販売管理・在庫管理全体となると、データの重複や整合性担保という観点で疎結合化は望ましくない。今のところは、1つ１つを手探りで考えていくしかないと思っています。
i Mag 現在、データハブ型の組織編成を進めていると伺っています。
山下 そうです。当社ではIT部門を大きく3つの構成にしています。システム開発を担当する組織、システムインフラを担当する組織、従業員・オフィスのIT環境をサポートする組織です。ここにデータを管理する組織機能を追加することにしました。
組織編成の考え方は、「ミックス」させることを重視して います。 当社でも以前は開発・運用分離型で組織していま した。しかしこれだと、確かにIT統制はやりやすいですが、役割によって目的が異なるのでコミュニケーションギャッ プが生じやすい。開発チームはリリースを目標に業務を進 め、運用チームは安定稼働を目標に活動するので、できる だけ変更したくないと考えるわけです。
それを解決するために、開発組織は開発・運用をワンチームにする、いわゆるDevOpsに近いような機能型組織に 編成しました。各機能でのサービス実現・維持・改善とい った共通目標をもつワンチームです。これは開発から運用 までを一気通貫することで作業効率を上げられる一方、完 全な縦型組織なので、サイロ化の弊害が出やすくなります。そこでデータのサイロ化を防ぐべく、水平型組織として、 データ基盤チームを作りました。ここには各チームを兼任 するスタッフも所属させます。システム間のデータを横串 で管理するので、データ品質を維持しやすく、必要に応じ てデータ連携の必要性を共有することで、不要な機能重複 を防げますし、全社的なデータ活用を促進する狙いもあり ます。システムごとのAPI管理の機能などは、この組織にもたせる予定です。
あと希望的観測ですが、OJT機能を保有できないかと企んでおり、今後、採用するスタッフはまずデータ基盤チームに配属させて、システム全体でのデータの流れや保有データについて把握させたうえで、各システムチームを担当させるつもりです。いきなりピンポイントで担当システムに配属するよりも、まずは全体像を把握したうえで、担当システムにドリルダウンしていくほうが、個人の引き出しが増えますし、将来的な成長に寄与できるはずです。 将来的にはビジネス部門のメンバーも兼務でデータ基盤 チームに所属できるように受け入れ態勢を整えることで、全社データ活用のPDCAサイクルを回せる場所としての機能役割をもたせようと考えています。
このように組織を再編していく中で、インフラ基盤を担当する組織はインフラ企画に従事しながら、アカウント管理・セキュリティ管理といった管理機能にエンジニアリング手法で運営する、いわゆるSRE的な組織へシフトさせようとしています。
もちろん基盤構築が必要な場合は実施・支援しますが、今後はサーバーレス、マネージド、SaaSの活用にシフトしていくことで、構築・運用より管理、あるいは性能改善やコスト管理等が重視されるのは間違いありません。クラウド界隈はもちろん、IBM i領域でも積極的にオープン系テクノロジーが投下されており、周辺のソリューションも賑わっています。学びがなければ「IBM i＝レガシー」と感じるかもしれませんが、学べば学ぶほど、共存させていくべき面白い領域ではないかと感じています。
このように、システムのアーキテクチャ変更に合わせて、組織構造も変えています。システムが変われば、人も変わる必要があるし、人が学べば、作り方や使い方も変わってくる。やはり、システムと人は切っても切り離せないものだと考えています。
山下 直也氏
株式会社フェリシモ
ビジネスプラットフォーム本部
IT推進部 部長
新卒にて家庭用インテリアメーカーのIT部門に従事後、2007年にフェリシモに入社。販売管理システムの開発・保守を担当後、5年以上にわたる基幹再構築プロジェクトを完遂。その後は開発・運用プロセスの整備、インフラ基盤のクラウド化を行うなど、開発、運用、インフラを転々としながら 2019年より現職。
株式会社フェリシモ
本社：兵庫県神戸市
設立：1965年
資本金：18億6800万円（2022年2月末）
売上高：337億2900万円（連結、2022年2月期）
従業員数：745名（連結、2022年2月）
https://www.felissimo.co.jp/
［i Magazine 2022 Spring（2022年4月）掲載］
