手持ちのシャツから自動採寸する機能も追加、Original Stitchがブランド向けカスタマイズプラットフォームを発表

既成品のシャツだとちょっと腕が長かったり、身幅が余ったりして、しっくりこないという経験はないだろうか。サンフランシスコに本社を置くOriginalは、そういった悩みを解決するため、シャツのフルオーダーサービス「Original Stitch」を提供している。本日Originalは記者会見を行い、アパレルブランドや小売店に向け「Original Stitchカスタマイズ・プラットフォーム」を提供すると発表した。このプラットフォームに登録すると、どのブランドでもフルオーダーメイドシャツの受注から生産、配送までできるようになる。このオープンプラットフォームを通してOriginalは、より多くのカスタマーがカスタマイズシャツを手に入れられるようにしたい考えだ。

Original Stitchは、カスタマイズシャツのデザインから注文までできるサービスで、日本でも2014年4月からサービスを提供している。シャツの生地やボタンをはじめ、襟や袖の形まで自由にデザインすることができる。基本となる型紙に合わせて首まわりと裄丈を変更するパターンオーダーと11箇所のサイズを採寸して型紙から作るフルオーダーメイドでの注文が可能だ。

OriginalのファウンダーでCEOのジン・コウ氏は、同社のミッションは「全てのクローゼットにカスタマイズシャツを届けること」と話す。それを実現するために「Original Stitch カスタマイズ・プラットフォーム」では様々なブランドや小売店を迎え、より多くのユーザーにカスタマイズシャツを提供できるようにしたい考えだ。

アパレルブランド、ドレスシャツテーラー、百貨店がこのプラットフォームに登録すると、すぐにユーザーからカスタマイズシャツを受注できるようになる。各ブランドは、ブランドイメージに即した生地やボタン、襟周りのデザインなど独自のものを提供することが可能だ。シャツの生産はOriginalが日本国内で構築している縫製工場のネットワークが担うという。Originalは工場からはコミッションを得ず、プラットフォームに登録するブランドからプラットフォーム利用料、販売手数料を得るSaaSモデルでのビジネスを考えている。

ファッションECの最大の悩み「フィット感が分からない」

Originalは2013年に創業し、2017年3月時点の会員数は世界で35万人いる。カスタマイズシャツをさらに普及させていくのに最大の課題となるのは「採寸」であるとコウ氏は話す。ファッションECの平均返品率は30%ほどだと言う。PCやスマホの画面では素材感や色味が実施とは違うというのもあるが、サイズが合わないのは返品につながる大きな要素だろう。Original Stitchの返品率は5%にまで抑えることに成功しているものの、各ユーザーにぴったりフィットするシャツを提供することが、リピーターを増やすために重要だと考えている。

そうした採寸の問題を解決するため、Originalはオープンプラットフォームの発表と同時にディープラーニングによる自動採寸機能「Bodygram」を提供すると発表した。「誰でも身体にしっくりくるシャツを1枚は持っているでしょう」とコウ氏は話す。Bodygramはそのシャツの採寸を取ることで、次にOriginal Stitchでシャツを発注する時にぴったりのサイズ感のシャツを提供する。

Bodygramを利用するには、まず採寸したい衣服を広げた上にA4サイズの紙を乗せてスマホで撮影する。あとは、Original Stitchにアップロードすると自動で衣服を採寸し、保存できる。

Bodygramはディープラーニングで採寸のアルゴリズムを開発していて、採寸の精度は96%になるという。最終的にはアルゴリズムに採寸を任せる予定だが、現段階では人の目でもチェックし、精度をより高めるためにアルゴリズムを鍛えているそうだ。Bodygramについてコウ氏は「コピーペーストするように」お気に入りのシャツのフィット感を再現すると話す。

アパレルブランドからすると採寸データだけとは言え、それがコピーされて別の商品に使われることには良い気持ちはしないかもしれない。けれど一方で写真を撮るだけで採寸できるのなら、Eコマースでファッションアイテムを購入してみたものの、サイズが合わなかったという体験は減らせそうだ。

API至上主義の愚

Colorful ceramic cube texture and background

【編集部注】著者のDavid Lee氏は、RingCentral社のプラットフォーム製品担当副社長である。

すべての重要な技術は、ハイプサイクルを通過する。

おそらくガートナーによるハイプサイクル図を見たことがあるだろう:期待が膨らみ、それが失望へと転じて、やがてテクノロジーの価値に対する実際の理解が訪れる。

もしジェットコースターから完全に落ちてしまわなければ、「世界を変革する」という約束はやがてありふれた現実に姿を変えていく。

ハイプ・サイクルガートナーハイプサイクル

クラウドAPIはこのサイクルをかなり奥まで進んできた。その中の優れたものたちは日々重要なビジネスサービスに力を与えている。それでも「APIエコノミー」は、定期的に誇大宣伝で翻弄されている。私が気にしているAPI愛好家によるレトリックは、「組み立て可能エンタープライズ」である。企業全体のソリューションを縫い合わせて作り上げる、日曜大工的アプローチだ。

大きなアプリケーションの一部としてプラグイン可能な、個別APIサービスの販売を通して成功したビジネスを構築した企業は、これからの企業はソフトウェアソリューションを買うのではなく、無数のAPIやマイクロサービスを通して自分たちのアプリケーションを組み立てるのだという、信じがたい極端な夢を見がちである。その見返りは、究極の無限のカスタマイズの形で与えられると語られている。

現実を見よう:そうしたことが起きることはない。少なくとも、多数の企業を横断して当たり前になることはないだろう。技術採用側のほとんどは、イノベーターも含んで、他に選択肢がないと考えたときに自家製のITを採用する。彼らが必要としているのは、あまりにも困難な仕事をしなくてもよいように、穴を塞ぎギャップを埋めてくれるようなAPIだ。期待する結果を得るための最も簡単なパスを彼らは求めている。

ほとんどの企業は、ただ1つのビジネスだけをしているわけではない。そしてソフトウェアを作成するのではなく、適合する傾向がある。

例外もある。Uberはそのモバイルアプリに、あなたの場所を検索し、ドライバーにあなたをピックアップするように通知し、支払いを受け付ける、といった厳選されたプレミアムAPIを取り込んでいることで有名でだ。サードパーティ製のソフトウェア機能にアラカルトでアクセスする能力は、必要な技術群を維持するためにリスクとコストをかけずに、誰もやったことがない機能を組み合わせて提供することが必要な、革新的なビジネスに最適である。別の言葉で言えば、サービスの組み合わせそのものが、キラーアプリをキラーアプリにしているものの大部分であることも可能だということだ。

一部の企業は、独自にUberのような革新を育もうとがむしゃらに進んでいるが、ソフトウェアの製作に特化していないビジネスのニーズは常に異なっている。ゼロから出発して、企業はその正確なニーズに合ったカスタムコールセンターやCRMを組み上げることができる。企業の規模でみると、それは、車輪の再発明のように見みられるだろう。

ほとんどの企業は、ただ1つのビジネスだけをしているわけではない。そしてソフトウェアを作成するのではなく、適合する傾向がある。どのように顧客サービスコールを捌くべきか、どのように顧客の記録を整理するかといった問題は、広範なビジネスニーズにアプローチする製品を作るソフトウェア会社によって、これまで何度も何度も解決されてきた。一般的な企業の購買戦略は、彼らの要件の中で1番旨味のある部分に最適である技術プラットフォーム上で、標準化を行うことだ。

これはAPIがソフトウェアの適合には無関係ということを意味しているのではない。ただコアエンタープライズシステムをゼロから作ることには、あなたの車をナット、ボルトそしてボールベアリングを用いて組み立てる以上の意味はないということだ。賢い技術採用者たちには、「最適」と「完璧」の間を埋めてくれる強力なAPIをもつクラウドプラットフォームへの選択バイアスがかかっている。

クラウドベースのコミュニケーションプラットフォームのためのAPIを扱う私の仕事で、私が見る最も一般的な例は、私たちの管理ダッシュボードを介してできるものとは異なる形でデータにアクセスしたいという顧客の需要だ。どんなに私たちがレポートをカスタマイズ可能にしても、データをさらに異なる形式でグラフ化したかったり、それを他のシステムから持ってきた自身の記録と組み合わせたいという顧客たちが必ず存在する。あるいは彼らは、出荷通知などの自動化されたSMSテキストメッセージを送信し、そして受信者がテキストメッセージまたは電話で返事することを可能にすることができるようにしたいかもしれない。

ソフトウェア作成者は個別のAPIサービスを必要とする可能性が高いのに対して、ソフトウェア適合者(大部分の企業だ)はAPIによって補われた全体的ソフトウェアソリューションを必要とする可能性が高い。Uberのようなデジタル変革を狙う企業は複数のAPIとマイクロサービスを拾い上げてカスタムアプリケーションを作りたい誘惑にかられるかもしれない。しかしながら、よく行われることは、最高レベルのビジネスソフトウェアと高度なアクセス性をもつAPIを縫い合わせることだ。

いつかどこかで、この原則を破るものを出てくる者が出てくることは間違いない ‐ APIの福袋から重要なアプリケーションを組み上げ、偉大な仕事を成し遂げる企業が出現するだろう。しかし、そうであっても、その営みが日常化しない限り、彼らは「組み立て可能エンタープライズ」にはならないだろう。

私たちはこうした妄想をとりこむことなく、APIエコノミーを受け容れていくことができる。もしソフトウェアが、マーク・アンドリーセンの言ったように、「世界を食べていく」のなら、クラウドAPIは最後のスナック菓子だ。ただ全体の食事ではないということだ。

[ 原文へ ]
(翻訳:Sako)

WordPress wp_headの各コード出力を無効にする

最近WordPress 3.3.1にアップデートしたサイトがあって、3.2時代に無効にしていた出力の一部が復活してしまってたので、ひと通り洗いだした。

link rel=”alternate” (フィードのリンク)

remove_action('wp_head', 'feed_links_extra', 3);

コメントフィードだけ消したいっていうのはできないっぽい?ので、無効してからテンプレに直接メインフィードのだけ記述します。

meta name=”genarator” (WPのバージョン)

remove_action('wp_head', 'wp_generator');

消した所でセキュリティリスクが減るわけではないですが、表示する必要性がないので。

link rel=”prev”とlink rel=”next”

remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);

3.2.1までは「adjacent_posts_rel_link」で消えていましたが、3.3.1ではなんか長ったらしい名前になってました。

link rel=”canonical”

remove_action('wp_head', 'rel_canonical');

消さない方がいいものですが、別にプラグイン等で出力している場合などに。

link rel=”shortlink”

remove_action('wp_head', 'wp_shortlink_wp_head', 10, 0);

これも使わないので。

link rel=”EditURI”とlink rel=”wlwmanifest”

remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

リモート投稿をしない場合はこれで消します。

はいこれでスッキリしました。