オーダーメイドのビジネスウェアを提供しているアパレルブランド、株式会社FABRIC TOKYO。
自社ECサイトに加え、リアル店舗も展開しているオムニチャネル形式を採用しています。FABRIC TOKYOの前身である「LaFabric」がリリースされた2014年当初。創業者のみでスタートしたブランドでしたが、現在従業員は86名に増え、売上は2018年度時点で前年比350％を達成するほどの急成長を見せています。

その最たる特徴は、これまでレガシーなビジネスモデルが続いていたオーダースーツという分野を全面的にIT化したこと。一度店舗で採寸さえすれば、いつでもどこでもオーダースーツを購入できるようになりました。

Fashion Techのリーディングカンパニーとして、FABRIC TOKYOが従来のビジネスモデルをどう変革したのか。また、NHNテコラスやアマゾンなど数々のサービスに携わってきた中筋さんがCTOとして参画した理由なども詳しくお伺いしました。

CTOが会社のロードマップを定め、事業成長にコミットする

Webだけで完結しないサプライチェーンにエンジニアが関わる魅力

多彩なキャリアを持つ中筋さんですが、FABRIC TOKYOに参画した理由はなんだったのでしょうか？

中筋：ファッション自体がそこまで大好きというわけではなく、関心は人並み程度です。ファッションという文脈で入社したというよりも、レガシーなビジネスモデルが抱えていた問題を、ITによって解決したかったという思いが一番の動機ですね。
当たり前ですが、すでにある程度効率化されて大勢の人が現状に満足している分野なら、挑戦する意味はあまりありませんよね。他社の参入障壁が低いということでもあります。一方で課題が多ければ多いほど、レガシーであればあるほどゲームチェンジ（技術的変革）はしやすい。そこにエンジニアとして魅力を感じました。大変なことにチャレンジする方が、価値が高いと思っているんです。

具体的には従来のオーダーメイドのどこがレガシーで、どのようにゲームチェンジを行ったのでしょうか。

中筋：従来のイメージとしては、お役所仕事が近いでしょうか。紙に情報を書いて決裁を回し、判子を押すのに似た世界です。
まず、オーダーメイドスーツをつくろうと思うと測ったサイズを紙に書いてFAXで工場に情報を送り、工場で情報を手打ち入力していました。ただ店舗に訪れて採寸をしますよね。従来であれば、データベースがあるわけではありませんから、もう一度オーダーメイドしようと思うと系列店であっても店舗が違うともう一度採寸することすらありました。

そこをすべてIT化したのが当社です。最初だけは採寸のために店舗に来てもらうことになりますが、あとはお客様個人のサイズ情報がクラウドに保存されるので、ECからいつでも何度でもオーダースーツを作れます。
発注も生産管理システムでコントロールしていて、提携している縫製工場に保存した発注データを出力するだけで済みますから、工場側にもベネフィットがあります。さらに人的コストが軽減される分、商品の価格も適正化できるのです。


つまり、業務改善を図りながら、お客様の購買体験、すなわちUXを改善したのです。
IT化よってオムニチャネルの利便性を高めることができたということでもあります。逆に言えば、オムニチャネル形式を取っていても、生産管理システムがきっちりしていなければ生産スピードが落ちてUXを損ないます。どの工程も表裏一体になっているということです。

このサービスはサプライチェーンが長いです。お客様の行動があり、サイズ・注文情報の管理、製造、在庫管理、物流を経てようやく1着の製品がお客様の手元に届きます。
Webだけで完結するサービスであれば、こんなに長いフローにはなりません。これらすべての工程にエンジニアとして携われるのは、非常に面白いと思ったんです。

今後の世の中も、フィジカルとWebの世界をいかにシームレスにつなげて、カスタマーの日常生活をより良いものにしていくのか、という視点にどんどんシフトしていくはずですしね。

変更前とIT化後

御社のエンジニア組織について、人数や役割を教えていただけますか？

中筋：メンバーは20名ほど。ECサイトや生産管理のシステムなどプロダクトごとに小チームを編成していて、１つのチームの中にフロントエンドやサーバーサイド、デザイナーがいる構成です。メンバー数が増えてきたので、ECはさらに新規機能開発と改善チームの2つに分けています。そのほか、SREやプロダクトマネジメントといった区分もあります。 各チームにはリーダーがいますが、コードレビューなどはリーダー以外のエンジニアが行うこともありますね。

CTOには、現在どのような役割が求められていますか？

中筋：一般論的ではありますが、いわゆる経営課題を技術で解決するのが大きな役割ですね。執行役員という立場でもあるので、会社と事業の成長も大目的です。
エンジニアリング寄りの視点で考えると、極力少ない投資で効果のある施策や機能を成功させ、大きなリターンを得ることが役目の一つであると考えています。
投資や資金調達などの具体的なタイミングは、会社が数年後にどうあるべきかというロードマップありきで判断することになりますが、当社の場合は僕がロードマップ自体も作成しています。そこから今年や半期の目標を細分化し、やるべきことをブレイクダウンしていくのが基本です。 一方でまだコーディングをすることもあるので、「なんでもやる人」になっていますね。

社内ではアーキテクチャへの関心が高いエンジニア同士の議論が活発

御社のエンジニア組織の技術スタックと、どのように技術力向上を図っているのかを教えてください。

中筋：技術スタックで言えば、サーバーサイドにはLaravelを、フロントエンドでアプリケーションライクに動くところにはVue.jsを採用しています。それなりにモダンな構成なので、古いフレームワークでモチベーションが下がるということは無いでしょう。

社内では勉強会などももちろん行なっているのですが、さほど頻繁ではありません。それよりも、常日頃からメンバーで技術に関する会話をすることの方が多いですね。アーキテクチャに関心のあるメンバーが多いですし、このフレームワークではどんな設計が良いのか…といった議論も活発です。 解決したい課題や理想がある中で、なるべくコードを破壊しないように新しい技術に追従するにはどうしたら良いのかといったテーマや、ドメイン駆動設計への関心も強いですね。

そのほか、開発手法などで特徴的な部分はありますか？

中筋：デプロイで言えばCI/CDを導入していて、基本的にすべてテストを書いています。サーバーサイドはPHPUnitです。レイヤードアーキテクチャを採用していて、ユースケースが正しく動いているかどうかを厳密にテストしています。テスト用のデータベースを作り、そこに対してテストを実行していますね。最近ようやくカバレッジが100％になりました。

開発手法はいわゆるアジャイルで、2週間を1スプリントとしてイテレーションをまわしています。プロダクトマネージャーがスクラムマスターの資格を持っているので、エンジニア以外の社員にも勉強会をしてくれていますよ。

社外CTOとして各社とも関わりながら考える、CTOの今後

中筋さんは社外CTOとしても活躍されていますが、概要を教えていただけますか？

中筋：現在関わっているのは3社で、いずれもB向けC向け問わずWeb系の会社です。
以下のように、稼働頻度は会社によってまちまちです。

月1回稼働の会社では、CTOというよりは技術顧問的な役割を求められています。
すでに会社にCTOがいるので、その方の壁打ち相手として月に1回話を聞くというイメージです。

CTOの先のキャリアについてはどうお考えでしょうか。

中筋：ゲームに例えると、CTOはエンジニアとしてのレベルをカンストしてしまったようなイメージだと思います。もちろんCTOの中でさらに高みを目指していく道もありますが、難しい課題だと思いますね。
僕自身も、これからどうすべきかをよく考えます。
30代後半の現在は、まだ事業やビジネスに直接関わっていたいという気持ちが強いです。ただ、たとえば僕が40代後半くらいになったら、いろいろな会社の手助けをしたいという方向にモチベーションが傾いて、一気に技術顧問や社外CTOの領域に振り切るかもしれません。
一方で、ただのエンジニアに戻りたいと思うこともありますし、自分でプロダクトを作りたいという気持ちもあって、なかなか定まりません。

ただ、現在CTOとしてマネジメントの比重が高い働き方をしていると、自分が持っているエンジニアとしての技術が古くなってしまうのではという恐怖感は常にあります。ですから、定まらない中でも極力最新の技術には触れるよう努力していますね。