2020年2月26日水曜日

ソフトウェアが世界の小売市場のゲームを変えている理由 2


今から7年前の記事ですが、最近になって少しつづではありますがソフトウェアの力が小売にどのように影響しているのかを解説したいと思います。
元記事はこちらです。 Software eats retail

要約すると、2013年にテクノロジーの投資家として有名な Marc Andreessen が放った言葉です。ソフトウェア業界が小売のあり方を根本から変える日が来るということです。彼はWebブラウザNetscapeの共同設立者でありシリコンバレーで最も影響力のある投資家で今までにFacebook、Airbnb、Twitter、Pinterest などさまざまなインターネットテクノロジー企業に関心を持っています。またFacebookやHHewletter-Packardの取締役会にも参加しています。

ずばり、「小売業の大半は廃業し、Eコマースは誰もが購入する場所になる。」この言葉を当時はなったあと、多くのアナリストは懐疑的だったそうです。(当然です)

彼の主張の1つとして、人間が店舗に行き、製品を閲覧し、それらの製品の代金を支払うという行為は200年前と基本的に同じで、レジや決済方法はたしかに変わりましたがコアモデルは1800年代と全く変わっていません。つまり小売業だけが他のどの分野の進歩よりも進化していない産業だということです。

仮に物理的な小売が存在しない未来など想像できるでしょうか。人間が物理的な買い物をする心理的欲求を根本から否定し、全てはEコマース化される世界です。

現実はソフトウェアが小売業を食べていますし、現在進行形でその影響力はますます強くなっていることは否定できません。2020年以降もあらゆる消費行為、広告にはソフトウェアが侵入してくると私も思います。

2020年2月24日月曜日

ソフトウェアが世界の小売市場のゲームを変えている理由

先日、こんな記事がありました。

TESLA COMPUTER HARDWARE STUNS COMPETITORS: “WE CANNOT DO IT”

日経アジアレビューというサイトで電気自動車大手のテスラのモデル3の解体を行い、ある日本のエンジニアは電気自動車に搭載されたコンピュータ技術の高さにショップを受けたという記事です。

日本人エンジニアは「We Can Not Do It = できません。」という回答だったそうで、テスラで採用されている中央制御ユニットを分析した結果、この技術にはすでに追いつくことができないと言及したそうです。

CEOのElon Musk氏によると、Teslaの「ハードウェア3」チップの現世代は、昨年車両に搭載を開始し、Tesla車両が完全に自力で運転できる十分な計算能力を備えています。現時点ではTeslaの自動運転機能はレベル2(5段階中5が完全に自律した自動運転)に制限されています。つまり、車線の変更、方向展開、ドライバー不在での駐車場のナビゲートを処理できます。

さて、日本の自動車メーカーであるTOYOTAですが、完全な電気自動車はまだリリースしていません。ガソリンと電気のハイブリッド自動車の代表であるアクアやプリウスの成功や水素電池自動車の投資によって完全に電気自動車への投資があやふやである印象を受けかねないですよね。

TOYOTAとTESLAの違いは、TESLAはすでに自動車をソフトウェアによってコントロールしている点です。TOYOTAは未だハードウェア先行の会社です。

ここからやはり学ぶことは多いと思います。
世界的に急成長をしている業界というのは、あらゆるものにソフトウェアが侵入してきており、ソフトウェアがまずは主であり、その次にハードウェアという点です。


小売業界はどうでしょうか。

小売業界は元々は大型商業施設にモールとして出店したり、路面店を出したりということで、やはりハード(外観やディスプレイや売り場での商品の見せ方)が先行していました。すべて手で触って感じることができますから、ハード先行です。

一方で価格.comに掲載するネット通販サイトは店舗を持たず、自社サイトと最先端の広告だけで売上数十億円規模の事業者もこの時代に存在します。彼らは小売の生態系を変えてしまっています。

IT時代にモノを売ることを学習した新人類はやはり売り方も違います。

彼らはひたすら商品データベースを作り、それを人工知能などが搭載されたGoogleの最新広告技術を駆使することにより、パーソナライズされた広告を消費者に配信するという手法です。

彼らは何を売るかよりも、商品データベースを構築し、それをGoogleやFacebookの広告配信先に掲載することのほうが遥かに合理的であることに気づいてしまっています。

彼らは何かを売るために、価格調査をしたり売り場のデザインを改良したりすることよりも(もちろん後々デザインなどは改善もしています)、結果として売れたものをよりマーケットに競争力のある価格で提供するという、今までの小売の常識では考えられない手法で小売市場の生態系を根底から揺るがしかねない存在です。


ソフトウェアが世界の小売市場のゲームを変えている理由をもっと詳しく知りたい方はセミナーで → https://www.live-commerce.com/seminar/cross-border200318.html






2019年10月26日土曜日

モバイルアプリの未来 PWAの作り方〜既存スマホサイトのアプリ化 

先日、ウェブサイトをアプリ化する課題があって、いろいろ調べていくとPWAという2018年ごろから話題になっている技術に出会いました。

この出会いはこの10年ぐらいのテクノロジー基盤としては、かなりのインパクトがありそうなので、自分なりの知識で解説しておこうと思います。

クロスプラットフォームの問題


そもそも、アンドロイドとiPhone のスマホアプリ、それからウェブサイトとしてのスマホサイトの3つを開発しようと思うと、それぞれの開発言語が異なるので、開発者としては3つの言語とそれぞれのシステムの管理が必要です。


ネイティブアプリの開発の場合、iOSだと Swift で Androidだと Kotlinで ウェブサイトはHTMLCSSですね。これだと開発者泣かせということで、iOSでもAndroidの共通開発言語としてクロスプラットフォームという考え方が次に広まりました。有名なクロスプラットフォームとしては XamarinやReact Native がありますが、これもまた独自の言語に近いのでゼロから学習しなければならないし、ネイティブアプリのような体現ができるかといえば、微妙です、、。

PWAの登場


そんな過程で2018年ごろに登場したのがPWAです。
 PWAとは、「Progressive Web Apps」の略称で、モバイル向けWebサイトをGooglePlayストアなどで見かけるスマートフォン向けアプリのように使える仕組みです。


特別な技術は必要なく、既存のウェブサイトに数行のJavascriptコードを追加するだけでGoogleストアやアップルストアで見かけるネイティブアプリのようにユーザーは自分のスマホにインストールして使えるようにするものです。

PWAを既存のウェブサイトに実装すると以下のようなメリットがあります。

  • ネイティブアプリと同じく全画面で閲覧できる
  • プッシュ通知が行える
  • オフラインで閲覧できる
  • ファイルがスマホにキャッシュされるので読み込み速度が格段にアップする
  • 検索エンジン経由でアプリをインストールさせることができる
  • 管理者側としてはサイトの審査が不要


などなど、、非常にメリットが大きいのです。

Googleのケース事例として紹介されている、不動産検索サービスを提供するSUUMOの場合、
  • 読み込み時間75%短縮
  • プッシュ通知開封率31%
  • 検索エンジンでのランク評価に好影響
という結果がでています。

そのほかにも、NIKKEIやTwitterやスターバックスなども事例として紹介されています。

ブラウザの対応


PWAという仕組みはスマホのブラウザで動作するため、AndroidとiOSにそれぞれインストールされているブラウザの対応状況によっては正しく動作しない場合があります。

2019年時点では、Google Chromeは完全にPWAに対応しています。Safariについてはまだプッシュ通知ができない、バックグランド同期ができないなど課題が残ります。近い将来、AppleがPWAを完全サポートすることを願うばかりです。

PWAの作り方


前提条件としては、以下の条件です。

  • 最近のバージョン(74以降)のChrome。 PWAは単なるウェブアプリであり、すべてのブラウザで機能しますが、ブラウザレベルで何が起こっているのかをよりよく理解してインストール体験をテストするためにChrome DevToolsのいくつかの機能を使用します。
  • HTML、CSS、JavaScript、そしてChrome DevTools に関する知識。

1、manifest.json ファイルの作成

manifest.json というファイルを作成し、以下の記述をします。
{
  "name": "Weather", //ウェブサイトの名称
  "short_name": "Weather", //ウェブサイトの名称(短文)  "icons": [{
    "src": "/images/icons/icon-128x128.png", //128pxアイコンの場所      "sizes": "128x128", //サイズ定義      "type": "image/png"     }, {
      "src": "/images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-256x256.png",
      "sizes": "256x256",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }],
  "start_url": "/index.html", // アプリインストール後のURL転送先
  "display": "standalone", // 変更なし
  "background_color": "#3E4EB8", // アプリ起動時のブラウザの色
  "theme_color": "#2F3BA2" //テーマ色
}

Note: Chromeをインストールするには、少なくとも192 x 192 pxのアイコンと512 x 512 pxのアイコンを用意する必要があります。しかし他のサイズを提供することもできます。 Chromeは48dpに最も近いアイコンを使用します。たとえば、2xのデバイスでは96px、3xのデバイスでは144pxとなります。

2、ウェブアプリマニフェストへのリンクを追加する

アプリの各ページに<link rel="manifest"...を追加して、ブラウザにマニフェストについて通知する必要があります。 index.htmlファイルの<head>要素に次の行を追加します。

public/index.html


<!-- CODELAB: Add link rel manifest -->
<link rel="manifest" href="/manifest.json">


3、iOSのmetaタグとアイコンを追加

iOSのSafariはウェブアプリマニフェストがまだサポートされていません。そのためindex.htmlファイルの<head>に伝統的なmetaタグを追加する必要があります。

public/index.html


<!-- CODELAB: Add iOS meta tags and icons -->
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta name="apple-mobile-web-app-title" content="Weather PWA">
<link rel="apple-touch-icon" href="/images/icons/icon-152x152.png">


4、アドレスバーのテーマカラーを設定する

PWA監査で、Lighthouseはアプリの「 アドレスバーのテーマカラーが設定されていない 」と指摘しています。ブランドの色に合わせてブラウザのアドレスバーをテーマにすると、より没入型のユーザー体験を提供できます。
モバイルでテーマカラーを設定するには、次のmetaタグをドキュメントの<head>に追加します。

public/index.html

<!-- CODELAB: Add meta theme-color -->
<meta name="theme-color" content="#2F3BA2" />

基本的には以上の実装で終了です。各種パスはサイトの構造に合わせて変更してみてください。また、もっと詳細にスマホアプリとウェブサイトの統合を行う場合は、Googleが提供しているドキュメントに はじめてのプログレッシブウェブアプリを参照してみてください。



AppleはPWAフレンドリーに近づくか?


答えはおそらくYESです。いずれにせよ、AppleがPWAテクノロジーに近づき、それに近づいていることは大きな一歩ですね。iOS 12.2およびiOS 13ベータ版のPWA対応は多くの人が待ち望んでいたことですので。

PWAはモバイルアプリケーションの未来だと考えています。ネイティブアプリケーションは今後数年後、PWAを基本としたウェブアプリに置換えられ、ネイティブアプリはウェブサイトと完全な組み合わせになる可能性があると思われます。


結局のところ、Googleはこの点で先導的であり、常にProgressive Web Appsの開発を推進しています。PWAについては今後もウォッチを続けていこうと思います。最新記事についてはメルマガを購読していただけると助かります。










2019年10月11日金曜日

越境ECビジネスモデル塾

To: デジタルスタジオのサービスをご利用しているお客様へ

Live Commerceでは今月から週1回のメールマガジンを配信しています。以前は私が行なっていたので月に1回がやっとでしたが、担当者が引き継いていただく形になって、これからは週1回の配信です。

メールマガジンのコーナーに作ってもらったのが、越境ECビジネスモデル塾です。
これは、私が経験した越境ECにおけるマーケティング施策の過程で生み出した企業単位での個別のビジネスモデルを紹介します。まあ、ビジネスモデルというか、個別のマーケティング施策と言ったほうがいいかもしれません。それが結果的に企業単位での独自性の高いビジネスモデルになった形ですね。

基本的に越境ECマーケティングは 広告 → LP → 売上 という流れは国内ECと同じです。

ただし、商材によってユーザーの属性が全然違うので LP → 売上 の導線に至るまでに教育させるべき手段が異なります。

消費者は広告を見た後に、その日に注文する人がだいたい46%、12日から30日後に注文する人が23%という数値があります。これは私が直接管理してい越境ECサイトなのですが、広告を見ても後日注文する人は全体としては54%もいるのです。広告を見た人の2人に1人の割合です。

マーケティングの施策としては、広告を見てから2日から30日の間にユーザーにどんなアクションを起こすのかが重要になっています。

一般的にはユーザーとしての足跡を残してもらう仕掛けをLP内に設置しておき、たとえ当日に注文されなくても再訪してもらえるようにしておくのです。

  • メールマガジン登録してもらう
  • SNS登録してもらう
  • リマーケティング広告で追いかける

ただ、ここからが問題です。
広告を見ても後日注文する人(広告を見た全体の54%)に対して、どんな内容のメールマガジンやSNS投稿にするのかです。


メールマガジンにしてもSNS投稿にしてもコンテンツを考えなければなりません。創造(想像)が必要です。

そこで私はクライアントとよく話すのが、

  • メールマガジンの内容(薄い、濃い)は気にしない。とにかく書く、配信する
  • SNSの内容は気にしない。とにかく投稿する

ということを強調します。

というのは、商品の販売に結びつくようなセールスレターは、良質な教材を使って教育された人でないと、書けません。

普通の人が書けるレベルの文章は、商品のちょとしたうんちくか、「かっこいい」とか「かわいい」といった自分がその商品に対して主観的に思うことぐらいではないでしょうか。実際書くとしたら。


世の中のメールマガジンと比較すれば非常に薄っぺらい内容なので、「こんな程度でも配信して大丈夫なのか?」

とよく聞かれますが、全然問題ないと思います。


なぜかというと、文章には他人の言葉自分の言葉があり、人の感情を動かすのは、自分の言葉だからです。自分の言葉は一見薄っぺらそうに思われがちですが、共感されます。

説明します。


他人の言葉とは、その通り誰かが言ったようなことです。まあ、本に書いてあるようなこともそうですね。他の誰かが言ったようなことを焼き直しして自分の言葉に置き換えた内容です。他人の言葉はほとんど響きません。


先日私が買った朝食用のナッツです。



これを紹介するときの他人の言葉。

オーツ麦に自家焙煎された玄米を加えたグラノーラベースに、シールド乳酸菌が500億個入った、甘さ控えめでより健康志向のグラノーラです!!
保存料・着色料・香料は無添加で牛乳や豆乳と一緒に、またはヨーグルトやアイスクリームなどにトッピングしてお召し上がりいただけますよ!!


これを自分の言葉にするとこうなります。

恥ずかしながら、自分はお腹が弱いのであまり食べたことないものを口にすると、昼食後とかに下痢になることがった。ただ、これを朝食としてとるようになってから、お腹の調子がめっちゃいい。下痢もほとんどしなくなったし体もなんとなく軽い感じ。仕事中にお腹痛くなると最悪、仕事集中できないしね。


公式サイトやSNSやブログなどの公にさらす場合は、他人の言葉。
メールマガジンで読者と1対1で送るなら自分の言葉。


私は公式サイトに掲載する文言とメールマガジンに掲載する文言は全く別です。
メールマガジンは読者と1対1なので、自分の言葉でもっと自分を深く知ってもらうように書きます。

自分の言葉で書いた文章は、いままで多くの企業担当者から反応をいただきました。
やっぱり、自分の言葉は人の感情を動かします。

話を戻しますが、広告を見ても後日注文する人(広告を見た全体の54%)に必要なのは、自分の言葉をとにかくニュースレターを介してユーザーに届けることです。


たとえメールマガジンのコンテンツの質が最初は低くても1週間に1度でもそういった言葉をユーザーに届けることができるようになれば、立派なマーケティングです。まずは、これが基本中の基本。

これができるようになったら、少しづつメールマガジンの内容を良質なものにしていけばいいのです。

最初から、きれいな商品画像やビジュアルを用意する必要はないと思います。

大事なことは、自分の言葉で一定の間隔で続けることです。
継続すれば、そこからどうやって改善していけばいいのか、すぐにアイディアが浮かぶと思います。


















フィリピンで求人

To : デジタルスタジオのサービスをご利用のお客様へ

当社ではフィリピンで求人をしているのですが、現在は技術系ではなくデータ入力というデスクトップワークの職種で求人をしています。ECサイトの商品登録をする担当者ですね。


Indeedで求人をしているのですが、1日300円で1週間求人広告をしたところ、100件以上の応募が殺到します。

フィリピン国内でIndeedで求人


Indeedの機能でスペック、学歴、保有資格、居住地などでいろいろフィルターをかけることができるので、採用側としては高スペックの人材を選べるので、日本を一歩出るだけでまったく求人の市場環境が違うことがわかりますね。

日本の1/3のコスト感で同じ仕事ができます。

システム開発やデスクトップ作業など、フィリピンの人材を活用して御社業務も一生に最適化できる提案が可能です。 ⇨ フィリピンオフショア開発





2019年9月29日日曜日

オフショア開発

To: デジタルスタジオのサービスをご利用のお客様へ


当社は、自社で100%子会社となるフィリピン開発会社を持っています。
あまりフィリピン拠点の話をすることがないで、本日はフィリピンで稼働しているシステム開発について、どうやって会社を成長させるのかお話ししたいと思います。


オフショア開発の始まり


私が初めてフィリピンでオフショア開発をしたのは2012年です。


PHPなどのプログラムの開発をフィリピン現地の日系企業に発注したのが最初です。実はその前にも中国大連でオフショア開発を3年ぐらい行なっていた経験もあるので、オフショア開発は私にとってはもうすっかり馴染みのある開発手段となっていました。


当社は元々オフショア開発を使っていた立場でした。使っていた立場なので、外国人にどんな開発が得意で、とんな開発が不得意なのかもその過程の中でよくしっています。


結果として、今は自社のリスクで会社設立から従業員をフルタイムで雇い、給与やらベネフィットと呼ばれる福利厚生まで払って運用しているのですが、やはり自社で雇用して、私が理想とするエンジニアを育てたほうが他社のオフショア開発を利用するよりも何倍もよいのは今でははっきりしています。


そもそもなんでオフショア開発?


ウェブサイト上で何らかのシステムなりサービスを提供している場合、特にECサイトなんかでは必ず機能の追加・既存機能の拡張などいろいろな業務要件が入ってきます。


経営ボードや内勤オペレーターから要求される業務要件に対して、スピーディーにシステムに機能を追加していくには、社内にエンジニアを雇用して常駐して開発してもらうのか良いのですが、そこにはウェブサービスを改修するだけの内部コストが凄まじい金額で上昇してしまいます。


そこで2000年ごろから日本企業は中国の大連、北京、上海を中心に海外でシステム開発を依頼する企業が増えたというのが大きな流れになっています。


その後、中国沿岸部の開発コストが上昇する流れを受けて、フィリピン、ベトナム、ミャンマーと開発地域をより低コストな国へ移動していったのが今日までの流れです。


現在、「オフショア開発」と検索するとフィリピン、ベトナム、ミャンマーのいずれかの地域でオフショア開発を提供している日系企業の会社がヒットします。

当社もフィリピンを拠点にしたオフショア開発を提供しています。

オフショア開発に失敗すれば、コスト圧縮どころか痛手のでる想定外の出費も


オフショア開発は、究極的にはコスト圧縮です。
要件通りにシステムが完成し、特に大きなバグもなく稼働に漕ぎ着ければ、オフショア開発としては成功です。


オフショア開発で用いられる開発手法はアジャイル型開発が一般的で、システム開発をガンガン回し、同業他社に比べて早いリリースサイクルでサービスを市場に提供できますから、ウェブサービスを提供する企業としては、競争優位の点でアドバンテージを持ちますよね。

※システム開発におけるアジャイル開発とウォーターウォール開発の違いについて



ただ、システム開発の現場でのコスト圧縮やリリースまでの超短納期案件はセブンペイのシステム開発失敗のニュースで目立ちましたが、短納期で無理な業務要件を詰めすぎた結果、クレジットカード情報で外部から攻撃を受けて情報漏洩など、プロの開発者から見ればありえない副作用もでてしまうのです。

その火消しにかかるコストが、コスト圧縮を目的に採用したオフショア開発だったのに、逆効果となてしまいかねません、、。


これはオフショア開発に特定されることはありませんが、安い・短納期というのは、品質管理に関するコストを圧縮するわけですから、メリットと引き換えにデメリットもあるわけです。

この辺りの洞察なしに、オフショア開発を「素早い対応が売り」、「低コスト」などを謳ったコストばかりを重視する結果、オフショア開発先を一歩間違えれば、システム開発の失敗に終わり、かけたコストに対するパフォーマンスを回収できないものになってしまいます。


オフショア開発で失敗しないための考え方


そこで、システム開発でオフショア開発を採用した際に、失敗しないための鉄則のようなものを私の経験から描いてみようと思います。

現地責任者がコードが書ける現役エンジニアであるかどうか


私は、そもそもオフショア開発を長年発注していた立場です。同時に現在はオフショア開発を提供している立場の両方を経験しているので、企業の担当者からみた場合の視線で厳しく評価することができます。



まず、大前提ですが、オフショア開発で成功するか否かの最大の基準は、現地(もしくは日本の)にいる日本人の責任者が、単なるオペレーターや翻訳的な窓口の人ではなく、現役のエンジニアであるかどうかはとても大事だと思います。


私が過去にオフショア開発として発注していた中国大連とフィリピンセブの会社はいずれも担当者はエンジニアの人であり、コードが書けるエンジニアでした。


現場を務める担当者が日本人で、英語がビジネスレベルでコードも書けるエンジニアであれば、ほぼ即答できるのでオフショア開発としては業務は推進できますが、英語ができるだけとか、コードが書けるだけ、、といったどちらかのスキルしかない場合は、コミュニケーションエラーでどこかで炎上する可能性があります。


担当者がエンジニアであれば、初めての商談で、しかもその場で工数や実現するための難易度、さらにはどうやってビジネスをより成長させるかまで話することができますよね。
私はポイントはここに全てあると思っています。


オフショア開発として開発先に発注する前段階で、担当者がどこまでその業務システムを理解してくれるかが鍵です。


大学でコンピュータサイエンスの学識もない文系の人が担当したところで、具体的な話もできないし、ビジネスモデルの話をしたところで、具体的なコードの実装までは話せないので、そういう人が担当すると、開発は淡々と進んでいるものの、言ったこと以上のパフォーマンスが出ずに、あまり成長を実感することができません。


要はシステム開発はしてくれているのだけど、ビジネスを成長させるための提案がシステム開発の現場から話が上がってこないというか、、そういう感じです。


システム開発のコードは経営戦略そのものであることを理解しているかどうか


最近、セブン・イレブンが導入した 7pay というペイメント・システムの脆弱性をついた犯罪が起こるという事件がありました。誕生日と電話番号さえ分かれば、パスワードをリセット出来てしまうという、ごく初期的な設計上のミスがあったため生じた事件ですが、「なぜこんなことが起こったのか」の根本原因をさぐり出し、そこから直す必要があると感じています。


日本のコードを書かない上流のエンジニアが設計し、コーディングはオフショア開発先の下請けに任せる上下関係の意識が出来上がってしまうと、コーディングしている最中にいろいろな問題が見つかった時に、上の人に言える立場でないので、仕様書に文句をつけることができなくなってしまいます。


私もそうですが、コーディングしている最中はいろいろなアイディアやもっと良いやり方がどんどん浮かびます。なので、最初に仕様書を書いたとしても、すぐに古いものとなってしまいます。


最初に仕様書を書いた人間がすべてを牛耳っているような経営戦略はとても古い体質であり、そんな会社がいまだに大手には存在しています。


コードは経営戦略のつまっているものであることをもっと経営者は理解すべきです。
私はアイディアはコーディングしているにどんどん変化するものなので。

ユーザーインターフェースの設計ができるか


オフショア開発の中でも多いのが、ウェブ系システム開発だと思います。
ウェブ系は一般ユーザーが利用するフロントエンドと、アルゴリズムが走るバックエンドの2つに分かれます。


画面のインターフェースには、ユーザーの目的達成のために必要とされるインターフェースが必要ですが、過去にオフショア先に委託した時にはこのインターフェースを設計できないエンジニアがほとんどだったというのが私の印象です。


こちらがモックと入力必要項目を作りプロトタイプとして渡しても、確かにその通りに設計はしてくれるものの、フォームUIなどの細部にこだわるエンジニアはほぼ皆無でした。

言ったことはやるが、そのままの状態ではとてもプロダクトとしてリリースさせることができないレベルです。

そこで学んだことは、オフショア開発は、アルゴリズムだけ完成させて、ユーザーインターフェースはある程度日本でもう一度完成度を高める作業を行った方が効率的であるということでした。

やはり、文化の違いや言葉の違いがあるため、仕様書があるものについてはその通りに作ってくれますが、ユーザーインターフェースのような使い勝手の部分については、気が利くエンジニアとそうでないエンジニアがいることは事実なので、ここは日本で詰めた方がよいでしょう。




オフショア開発について説明しましたが、私としては自社のプロダクトをオフショア開発で今でも開発していますし、一方で企業としてもオフショア開発を提供する立場でもあるので、今後も活用していただける企業が増えてほしいと思います。



デジタルスタジオのオフショア開発サービス


デジタルスタジオのオフショア開発サービス


当社はフィリピンのマカティーというフィリピン最大の商業都市にオフィスを構えています。日本の新宿や東京駅周辺のような商業都市です。

YoutubeでMakatiのイメージがありましたので、これをみていただくとイメージがよくわかると思います






現地のウェブサイトもあるので、ぜひみていただければと思います。

Limder というeBay Lazada Amazon の在庫連携システムを開発したり、ECサイトを開発したりしています。


フィリピンでオフショア開発を検討している方は、ぜひご連絡ください!
いろいろと、ビジネスがどう成長できるか、私なりに戦略支援させていただければと思います!!








2019年9月28日土曜日

人工知能による商品のレコメンド機能

To: デジタルスタジオサービス利用者様


現在、デジタルスタジオでは越境EC事業のソリューションとしてLive Commerceの越境ECカート以外にも、いくつか同時並行的に社内プロジェクトが動いています。まあ、どの会社にでもあることですが、私はプロジェクトの方向性決め、実際のプロジェクト毎に担当者を決めて、やっていく感じです。


で、今一番ホットなのが、人工知能による商品のレコメンド機能です。
要は、amazonのトップページにある、あの機能ですね。


1つの商品をクリックすると、それに関係性の高い商品が次々に提案されるやつです。


今、世の中でパーソラナイズできている通販サイトはamazonぐらいではないでしょうか。

ヤフーも楽天もまだ全然できていませんし、zozoもそもまで解析がすすでいるとは思えません。


amazonが圧倒的に個人にパーソナライズされたサイトになっているので、amazonの中から知らない商品が提案されたりすることが、購買体験以上の質の高いユーザー体験につながっていると思います。


で、当社もそれをまずはDiscovery Japanのサイトに統合すべぐ、いろいろ実験しています。AWSとGoogle Cloud Platformにはすでに開発者向けにAIが簡単に使えるようになっているので、これらの機能を活用してやっています。