目指すは究極の“個客”対応。ファーストリテイリング「デジタル改革」の本気度

ファーストリテイリングが取り組んでいる全社改革「有明プロジェクト」が注目を集めている。

この取り組みの一環として、同社は2017年2月、東京・有明の新社屋UNIQLO CITY TOKYOに、商品企画、生産、物流、マーケティングなど、ユニクロのものづくりに関わる部署の社員1000人以上を移動させた。

一大プロジェクトの狙いは、「作ったものを売る」という従来型の「製造小売業」から、「情報製造小売業」へと変貌を遂げることにある。

つまり、顧客が求めているものをリアルタイムに把握・商品化し、素早く顧客の元へ届けるビジネスモデルに転換するためのプロジェクトなのだ。

その中軸を担っているのが、同社のデジタル業務改革サービス部である。

Web企業やITコンサルティングファーム、ITベンダーなどで活躍していたメンバーを多数採用して、社内の業務システムからECサイト、自社アプリの開発・運用まであらゆる面を刷新してきた。

2017年12月6日にTECH PLAYで行ったエンジニア向け勉強会『Fast Retailing tech meetup #1』で、同社のグループ執行役員（CIO）である法華津誠さんは、デジタル業務改革サービス部の現状と今後についてこう語った。

世界的ITベンダーやシリコンバレーのスタートアップを経てファーストリテイリングに入社したCIOの法華津さん

「我々の役割は、あらゆる業務をデジタル化して効率を圧倒的に上げることです。以前はファーストリテイリンググループが展開する8ブランドで複数の業務システムを使っていましたが、すべて統合して世界同時展開の基盤づくりを進めてきました。そして今、注力しているのは『究極のUXづくり』です」

ここで言う「UXづくり」とは、ネット通販の利便性向上や物流の改善だけにとどまらない。

服を作る人と着る人の境をなくし、世界中の1人1人にジャストフィットする“個客”対応を究極の目標に、商品企画から生産、販売のプロセスすべてをテクノロジーで最適化する取り組みだという。

本記事では、前述した勉強会で披露された。

【1】AI×画像認識技術を活用したファッショントレンド分析
【2】ユニクロECサイトにおけるパフォーマンス改善
【3】Amazon ECSを利用したDockerマルチリージョン運用

の3つについて詳しく紹介していこう。

【1】AI×画像認識技術を活用したファッショントレンド分析

2017年8月期決算の売上収益は1兆8600億円と、過去最高の業績を収めたファーストリテイリング。だが、2020年度の売上3兆円達成を目標に掲げている同社にとって、さらなる施策が必要不可欠となっている。

そこで現在力を入れているのが、店舗とECサイトの双方で顧客データを収集しながら、リアルタイムに需要予測を行うこと。中でも、消費行動を大きく左右するトレンド予測で、次の売れ筋アイテムを企画・生産していくことだ。

この難題に取り組んでいるのは、デジタル業務改革サービス部の機械学習・AI担当である伊藤芳幸さん。この日は、試行錯誤しながら作り上げた「AI（人工知能）×画像認識技術を活用したファッショントレンド分析エンジン」について話した。

東京工業大学の情報理工学研究科計算工学専攻修了で、大学では音声認識系の研究を行っていた伊藤芳幸さん

伊藤　私は2015年にファーストリテイリングに転職するまでSIerに勤めており、そこで小売のEC事業を展開するお客さま向けに「TwitterのつぶやきとEC上での売上相関」を分析してレポーティングするような業務を担当していました。

現在のミッションは、データドリブンで売れる商品を世に出すこと。入社後は、SNSからマスへのファッション伝播検知、インフルエンサー分析などをやって来ました。

直近の1年間くらい取り組んでいたトレンド予測はまだまだ実験段階なのですが、ファッション業界は着こなしやスタイリングが消費者の購買行動に大きな影響を与えるため、何とかして次のトレンドを定量的に予測できないか？ と考えて動き始めました。

これまでの商品企画は、主に

（1）ファッショントレンド情報
　コレクション（ファッションショー）の最新動向や百貨店の展示状況をチェックする他、街中で観察して把握する。

（2）消費者動向
　店舗＆ECサイトの購買データはもちろん、外部調査も使って把握する。

（3）過去の販売実績
　社内データを参照する。

の3つを踏まえながらコンセプトを決めていて、特に（1）のトレンド情報は定性的にならざるを得ませんでした。例えば、百貨店に視察に行ったデザイナーの好みによって、写真に収めるアイテムも変わってしまう、ということがよく起きていました。

そこでまず行ったのは、ファッショントレンドがどのようにマスに伝播していくのかを仮説立てて、画像データを集める対象を絞ることでした。

私たちが立てた仮説は、コレクションから発信されてマスに伝播していくのが基本形だろうというものです（下画像参照）。

次に行ったのは、さまざまなファッションブランドが過去に開催したコレクションの画像をひたすら集めて、そこに「タグ」付けして傾向分析をする作業でした。

例えば女性用のジャケット一つを取っても、「カラー」「柄」「丈」「ディテール」「シルエット」など、さまざまな特徴があります。そこで、以前アパレル企業で働いていたことのある女性社員に協力を仰ぎながらこれらを「タグ」として分類し、デザイナーチームと都度すり合わせながら人力でタグ付けしていきました。

こうやって地道にモデルを作った後は、過去のコレクション画像に自動でタグを付与していくソフトウエアを作りました。

画像認識技術に精通したベンダーや研究機関に相談し、最終的には最も精度の高かったところと共同で独自の画像認識用エンジンを作ることになりました。今は、「カラー」「柄」「丈」「シルエット」までは自動で識別できるようになっています。

開発のポイントは、ユニクロのデザイナーやマーチャンダイザーが見たい・知りたい情報を元にモデルを構築していったことです。それと、ディープ・ラーニングで不可欠な「教師あり学習」用のデータをきちんと作ったことが奏功しました。

ちなみに、新しい技術を使って従来の業務フローを変えていく際は、業務側とテクノロジー側との「期待値のギャップ」を丁寧に埋めていくことも大切になります。

その一環として、専用のビューワーを開発してデザイナーやマーチャンダイザーが視覚的に分析データを閲覧できるようにするなどの配慮もしています。

今後は、店舗にご来店くださったお客さまが試着室で店員と話す内容の音声分析であったり、カメラを用いた動静分析などにも取り組んでいき、よりリアルタイムで精度の高い需要予測をしていきたいと思っています。

【2】ユニクロECサイトにおけるパフォーマンス改善

続いて紹介するのは、“個客”対応の鍵を握るECサイトの利便性を高める取り組みだ。

同社の2017年9-11月期連結決算によると、国内ユニクロ事業に占めるEC比率は7％だという。同社はこれを30％まで引き上げたいと公言している。

その施策の一つとして、AIコンシェルジュサービス『UNIQLO IQ』をモバイルアプリに搭載予定だが（2017年9月より一部会員へ先行公開）、それ以前にTTI（Time to Interact / 通信時間）の短縮やデータ処理順序の工夫なども必要になる。

これらを支えるアーキテクチャとパフォーマンス改善の取り組みについて、デジタル業務改革サービス部でフロントエンド開発を担当する弥吉修英さんは次のように語る。

2016年12月に現職に就く前もアパレルEC大手でファッションコーディネートアプリの開発に従事していた弥吉さん

弥吉　ユニクロはご存知の通りグローバル展開をしていて、ECサイトも世界各地で展開しているので、フロントエンドエンジニアの仕事はこれらの実装とサイトパフォーマンスを上げていくことになります。

現在のアーキテクチャを簡単に説明すると、ECサイトはSPA（シングルページアプリケーション）を採用しており、主にReact.js + Reduxで実装しています。

ルーティングの部分はNginxで作っており、Akamai (CDN )からのリクエストを振り分けるようにしています。Backends for Frontends（BFF）の部分はNode.jsで書かれており、 マイクロサービスからのレスポンスを束ねてフロントに返すような仕組みにしています。

チーム全体で意識しているのは、やはりパフォーマンスです。TTIが短いほどコンバージョンレートが上がるというデータが一般に出ているからです。

ビジネスサイドの関心も非常に高く、Webサイト計測でよく使われるWebpage Testの結果を見て「Speed Indexが下がっているよ」というレポートが来ることもあるので、その原因を探って随時対応していくような仕事もやっています。

パフォーマンス改善の面では、主に（1）ネットワーク処理、（2）スクリプト処理、（3）レンダリング処理の3つを最適化していく取り組みを行ってきました。

それぞれの説明に前置きしておくと、個人的には改善を行う前の定量的かつ定期的なパフォーマンス検証が大事だと考えています。そこで、Jenkinsと、Googleが開発しているLighthouseを使って定期的にパフォーマンス計測を行う仕組みを取り入れました。

また、バンドルファイルに何が入っているかを可視化したり、ファイルサイズが大きくなってしまった場合のコミットを防ぐような仕組みも導入しています。

その上で、どういった最適化をしてきたかを実際に説明していきましょう。

（1）ネットワーク処理の最適化

最初に行ったのはHTTP/2の有効化です。これによってマルチプレキシングが使えることになるので、アセットに関してはCSSスプライトなどを使わなくても並列読み込みが可能になりました。

その他、データ圧縮プログラムのgzip圧縮でコンテンツサイズの縮小を行ったり、preloadによるフォント先読み込みをやっています。

（2）スクリプト処理の最適化

今、フロントエンド開発のチームではモジュールバンドラにwebpack 3を使っていて、これに搭載されている機能を使ってバンドルファイルのサイズ縮小を心がけています。

Tree Shakingを使い、ES6の import/export syntaxを解析してdead codeを抽出することもやっています。dead codeの削除には、JavaScript用の圧縮・最適化ツールであるUglifyJSを使っています。

他にも、ルーティングベースでコード分割を行ったり、webpack 3から有効化されたScope Hoistingを使って200KBほどファイルサイズを縮小しました。

（3）レンダリング処理の最適化

今、ユニクロのグローバルECサイトはサーバサイドレンダリングを行っていないので、ブランクページの表示時間をできるだけ短くするための工夫が必要となります。

主だった点は、ヘッダーとロゴを最初に表示されるindex.htmlに含むことで早く見せるような工夫です。静的ヘッダーをHTMLでレンダリングした後でReactのコンポーネントをオーバーラップさせます。また、ロゴはSVGファイルにするなどで、お客さまに早くコンテンツを見てもらえるようにしています。

今後は、サーバサイドレンダリングも検討していきたいと話しています。他にも、まだまだできていない画像の最適化や、軽量ReactであるところのPreactの利用、AMP（Accelerated Mobile Pages）の導入など、ユーザーのUXを高めることにつながりそうな施策にはどんどんチャレンジしていきたいと思っています。

【3】Amazon ECSを利用したDockerマルチリージョン運用

最後に紹介するのは、より良いサービスを提供する上でいまや欠かせなくなった継続的インテグレーション（CI）と継続的デリバリー（CD）についてだ。

ファーストリテイリングでは以前から、海外出店の地域に合わせてAWSをリージョン（地域）ごとに使い分けるようなシステムを構築していた。そうすることで、キャンペーンのピークなどに現地で対応しながら拡張性を担保するためだ。

ただ、クラウドインフラは日本を拠点に管理することで効率的なDevOpsを実現している。デジタル業務改革サービス部でアーキテクチャ、DevOps担当の頼兼孝幸さんは、インフラ構築・管理ツールであるTerraformと、CIツールとして知られるJenkinsで行っている「Amazon ECSを利用したDockerマルチリージョン運用」の現状について説明した。

2017年に入社するまで、ヤフーやサイバーエージェントといった大手Web企業でサービス立ち上げや運用を経験してきた頼兼さん

頼兼　まずは私たちが行っているCI / CDの全体概要からご説明します。

まず、アプリケーションのソースコードをGitHubにプッシュします。プッシュされたコードは5分おきにJenkinsでスキャンして、スキャンに引っかかったGitHubのリポジトリを参照してjobを実行するようになっています。

Jenkinsfileの処理は主にDocker BuildとDocker Pushの2つで、リポジトリにあるDockerfileを元に実行しています。プッシュ先はAmazon ECRで、その後、Amazon ECSに対して、Terraformを使ってコンテナをデプロイする仕組みです。

JenkinsのScan Repositoryはマルチブランチ・パイプラインでjobを作成しており、スキャンした時にプッシュされたコードの一覧とプルリクエストの一覧リストがJenkins上に出るようになっています。このリストが、それぞれJenkinsfileを元にDocker BuildとDocker Pushを行う形になっています。

また、ユニットテストについてもこのJenkinsfileに書いてあって、Jenkins上でユニットテストができるようにしています。

Jenkinsはマルチリージョンで構築してあるのですが、Docker Buildは東京リージョンに集約しています。JenkinsでDocker Pushを行う際は、東京からマルチリージョンPush（東京でBuildしたものを、ブランチやPRの名前をラベルとして、各リージョンのECRへプッシュする）するような形です。

ただ、その後にTerraformでインフラ構築をする際、デプロイはリージョンごとに行うようにしています。東京でデプロイする時に各市場同時展開するのも可能ではあるのですが、「現地時間の0:00にリリースする」といったような場合はリージョンごとに作業する必要があるからです。それゆえJenkinsもリージョンごとに分けています。

最後に、Docker、Amazon ECSを使うメリット・デメリットをまとめた表がこれです（下写真参照）。

頼兼さんがまとめたDocker、Amazon ECSを使うメリット・デメリット

一番のメリットは、Dockerで使ってカプセル化することでイミュータブルな構成にできることだと感じています。それをAmazon ECSに乗せることで、一貫性とスケーリングが担保されるのも利点です。

また、ECSの機能の一つであるScheduled Tasksを使うとDockerでカプセル化したものをバッチ処理で定期実行できるので、非常に使い勝手の良い機能だと気に入っています。

さらに、インフラストラクチャを管理することなくコンテナをデプロイ・管理するツールとして最近登場したAWS Fargateによって、サーバ自体のECSインスタンスを意識する必要すらなくなったのも魅力です。

一方のデメリットは、DockerやECSを使ったことのある人がまだまだ少ないこともあり、チームとしての学習コストがかさむ点です。それと、Dockerを使うと簡単にデバッグできない状況になるので、きちんとログを出力して必要な情報は別途確認するひと手間もかかります。

アーキテクチャ、DevOps担当チームとして次に取り組みたいのは、AWS Fargateへの移行を本格的に進めていくことです。日本で仕事しながら世界中の拠点を束ねていくような職場は、日本のWeb企業ではほとんどないと思っているので、その醍醐味を味わいながらさまざまな技術的チャレンジをしていきたいです。