無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

2019年、何をしてきたのかを振り返る

去年の年末にこんなエントリを上げました。 gdgd-shinoyu.hatenablog.com

あれからもう一年経ってしまいましたね(´・ω・`) 気を抜くと一年あっという間に終わってしまう現象に見舞われてしまい、年々時の過ぎ去りし速度が増していく感覚を味わってます。

ちょっとこちらの更新が色々と止まっていましたが、その分仕事に追われる一年でしたね...まだこの流れは続きそうですが可能な限りアウトプットをしていくようにはしたいですねぇ....

今年の振り返り

さて、去年のエントリで「ここ数年で一番動きがあった一年」と書いていましたが、今年は更に大きな動きのあった一年だったと思います。


大きく2点あるのですが、まず本格的に副業を始めたこと。

もともと知り合い経由でちょっとした作業をもらうくらいはやっていたんですが、本格的に仕事として請けるって経験はなかったんですよね。そんな中、とあるスタートアップ企業からTwitterで回ってきた募集から始まった仕事がありまして、それに手伝わせてもらいました。

今も仕事を頂いていて大変ありがたい限りなのですが、参画した当初は活躍できなかったなーという反省が大きかった一年です。 Golangを本格的に書いたのは初で私としてはとても良い経験をさせてもらっていたんですが、やはり事業としてやられているので力不足なのは否めず。結局Golangではなく慣れたRails側のタスクを回してもらっていました。

まあ、後で書く話に繋がるんですがこの件に関しては、大いに力不足を感じさせる一年ですね... 当時の所属会社ではエンジニアリングから離れて初のプロダクトマネジメントの仕事をやることになり、開発から離れていたのも焦る要因でした。「このままではいけない」の気持ちを強くした一年だったと思います。


もう一つは、小さな会社に転職したこと

今年の10月くらいなのでまだ最近の話ではあるんですが、まともにプロダクト開発ができない職場から、受託で生計立てている会社に転職することになりました。ここもまあ、色々と悩んだ選択ではあったのですが、すでに仕事が完成された企業ではないところを選びたかった、というのが理由でした。

所属していた会社で感じたことなんですが、ある程度事業の柱となる製品がある会社では、現状から逸脱した何かをやりにくい、という課題が見えたんですね。 ECモール事業をやっていた会社で、もともと楽天Amazonに勝てる方法を考えてプロダクト開発をしていく体で入社したんですよ。ただ、蓋を開けてみると楽天ベンチマークの施策を行うことが多く、最終的には親会社の意向に沿って開発するだけの会社になってしまい。 そういうところを経験したこともあって、よいプロダクトを志向していくためには新たに作り上げるところから入っていかないとダメだ、と結論付けました。プロダクト本体もそうですが、それを作るチーム、組織も作っていくべきだと。

そういう想いを持って、様々なジャンルの事業をされているいろいろな会社とお話をさせていただいたときに感じたんですが、 ある程度会社が大きくなり回すだけになっている会社では諸々整理されていることが多く、新しく何かを作り上げていくという経験があまり狙えないんですよね。

ガンガン新規事業を作っている会社もいくつかあったんですが、そういうところは大量に募集をかけて人を取っているため、自分の動ける範囲はかなり限定されてしまう。各事業の責任者はその会社でも要職な人が多くプロダクトを作る組織は概ねもうできている。そこに自分が動ける可能性を感じることができなかったのです。 単純に1エンジニアとして働くならそういう企業を選んでメンバーとしてJoinするのがおそらく最適解ではあったのでしょうね。


で、そういう会社の話を伺って散々悩んだ結果今の会社にJoinすることになります。成長意欲はあるが実態なかなか伸ばせていない。そういう課題を持っている企業です。

まあ待遇は前より下がってはいるんですが、会社を伸ばすために何をするべきか?のところから任せてもらえる数少ない会社でした。そのへんをやってもらいたいと言われる。自分のやりたい方向性にマッチしていたのと、伸ばし甲斐の高さに惹かれてJoinを決めてます。

まだ入社して2ヶ月、3ヶ月ほどですが会社の「次」を見据えた評価制度を考えさせてもらったり、社内にエンジニア文化を広げるための活動を主導させてもらったりと、いろいろと動かせてもらっています。幸い、自分が動いた分の効果が芽吹いてきており、今後一年本腰を入れて立ち会って行けるとおもしろい光景をつくれそうだな、という確信があるので、今後も楽しくい仕事はできそうだと思っています。

その話の片鱗は、 https://qiita.com/shinoyu/items/5888fa769a3f28b23f45 とかを見ていただくとなんとなく分かるかと思います。このアドベントカレンダー自体もその一部ですね。

とにかく動かしてみて結果を追わせてもらえる。そういう活動を今後もしていきたいと考えてます。



さて、今の時点で結構長くなっちゃったんですが、今年一年を統括して言えることは、『やってみる』を体現してきた一年だった、ということですかね( ・`ω・´) 転職して、組織づくり会社づくりから携われる。これまでの1開発者から一歩踏み出した先の仕事にチャレンジできている。 つまり、去年誓った「期待以上の一年にする」という点について、無事達成できたのではと感じてます。

来年目指していきたいこと

ここまでは今年の話。ここからは来年の話。


いろいろと展望は考えているんですが、まずなにより今の会社の「次」を作り出すことですかね。 今動いている評価制度の切り替えもそうですし、新しく自社プロダクトを走らせようとしているタイミングです。 まずはこの辺を実行に移して確かなものにしていく。そういうところに注力していこうかと。


あとは純粋に開発者としての技術力を高めること。 少なくとも思いついた事業をすぐ形にできるプロトタイピング力を強化することを目的にしていきたいです。 今のところ、バックエンドはだいたい分かるようになってきました。フロントエンドとインフラ部分の知識が弱いのでここを強化した上で、 更にグラフィックデザインあたりを履修して、自分でPoCできる精度くらいのモノを作る力を得たいと考えています。



ザクッとした目標なのでどこかのタイミングで精緻化は必要ですが、まずはこの2つを確実に達成していく一年にしていく。まずは今見えている山に向けて一歩から。来年また同じように報告できるよう、やっていきします!

alpine+Railsでの ld-linux-x86-64.so.2: No such file or directory 問題について

使っているイメージ: ruby:2.6.5-alpine

techblog.gmo-ap.jp

この症状と全く同じ。ld-linux-x86-64.soが不足していると言われる。

LoadError: Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/local/bundle/gems/grpc-1.23.0-x86_64-linux/src/ruby/lib/grpc/2.6/grpc_c.so) - /usr/local/bundle/gems/grpc-1.23.0-x86_64-linux/src/ruby/lib/grpc/2.6/grpc_c.so

このときのDockerfileは以下の通り

FROM ruby:2.6.5-alpine
ENV LANG C.UTF-8
ENV BUNDLE_JOBS 4
WORKDIR /usr/local/src

... いろいろディレクトリのADDとかやっているところ

RUN apk update \
  && apk add --update --no-cache \
    git \
    build-base \
    curl \
    tzdata \
    xz-dev \
    mariadb-client \
    mariadb-dev \
    mariadb-connector-c \
    libc6-compat \
    libssl1.1 \
  && rm -rf /var/lib/apt/lists/* \
  && gem update --system \
  && gem install bundler \
  && RAILS_ENV=$RAILS_ENV CFLAGS="-Wno-cast-function-type" BUNDLE_FORCE_RUBY_PLATFORM=1 bundle install --deployment

EXPOSE 3000

ld-linux-x86-64.so.2はlibc6-compatに入っているもので、apk addしているやつに含めている。

pkgs.alpinelinux.org

配置場所こそlibではなくlib64だが、64bit向けビルドするとシステム的に自動判定されるはず(´・ω・`)


考えても何もわからなかったので、冒頭のリンクで紹介されていた https://hub.docker.com/r/frolvlad/alpine-glibc/dockerfile を試すことに。 ただ、これをDockerfireに適用するのかなり大掛かりな気がして、このdockerfileの中で使われている以下の導入をそのまま実行。

github.com


検証なのでなるべくミニマムでな。これ通りやればすんなりdocker-compose build --no-cache nameで、イメージビルド自体は通った。

docker-compose runでコンテナの中に入り、まずは手動で実行してbundle install。 特に問題なくGemは入る。その後、consoleなりmigrationを実行すると以下のようなエラーが発生してしまう。

/usr/local/src # RAILS_ENV=development bundle exec rails db:migrate
/usr/local/bundle/gems/google-protobuf-3.9.2-x86_64-linux/lib/google/protobuf/any_pb.rb:17: [BUG] Segmentation fault at 0x0000000000019266
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-musl]

セグフォをくらう(´・ω・`)うーん....


セグフォの情報を元に調査すると、似たような症状を食らっている人が報告しているIssueを見つけた。

github.com

これを一通り読んでいった結果、結論、これで問題が解消した。

Segmentation Fault (Segfault) on the ruby gem · Issue #4460 · protocolbuffers/protobuf · GitHub

gem "grpc", "1.21.0", platforms: ["ruby"]
gem "google-protobuf", "3.8.0", platforms: ["ruby"]


ただ、確かに問題は解決するんだが、原因が全然わからず気持ち悪い(´・ω・`)で、いろいろ探した結果、以下に行き着いた。

github.com

I did a bit of digging and found that it was due to alpine gcc not being able to compile boringssl library due to function type cast error.

alpineのgccだと、boringsslのビルド時にキャストエラーで落ちてしまうらしい。なるほど。


ここで重要なのはおそらくplatforms: ["ruby"]
このオプションを指定することで、強制的にCRuby (MRI)としてビルドするように指定している。そうするとalpine向けでないビルドになるので、Alpineのgcc起因の問題は回避できるのだろうと理解しました。

意外なところで使えるMakefile

昨今Dockerを用いたコンテナ開発しているところでは、割と採用されているのではないでしょうかMakefile何番煎じかわからない内容ですが、とっても便利ですよ( ・`ω・´)


C++触っていたときはMakefileに大変お世話になっていましたが、その後JavaC#と渡っていくうちに、言語ごとのビルドツール(当時はantとかmsbuildとか)を使うことになりしばらくご無沙汰だったわけですね(´・ω・`)

特にWeb開発でLL言語開発を長くやっていると使うケースがあまりありませんでした。複雑なビルド等しないわけだし、Railsだとrakeって生き物もいるわけで。ほとんど見ることはありませんでした(少なくとも私の周辺では)


しかし最近、何でも実行できるそのポテンシャルが、普段利用していない層の人々にも評価されたのか、Docker活用した開発現場での利用が増えてきたように感じます。

今自分が担当してるRailsとVue.jsのプロジェクトではこんな感じのものを入れてます。

update:
    @make rails/bundle # 別のコマンド叩く場合@make {command}
    @make yarn/install
    @make rails/migrate

yarn/install:
    docker-compose run --rm web yarn install # フロントはpackage.jsonで実体を管理しておいて呼び出すだけ
 
yarn/build:
    docker-compose run --rm web yarn build

yarn/clean-build:
    docker-compose run --rm web rm -rf node_modules/.cache/hard-source/
    @make yarn/build
 
rails/bundle:
    docker-compose run --rm app bundle install
 
rails/migrate:
    docker-compose run --rm app bundle exec rails db:create db:migrate
 
rails/restart:
    docker-compose run --rm app bundle exec rails unicorn:restart

すごく簡易的なやつですが、docker-compose系のコマンドを手打ちしなくて言い分すごく楽です。人によってはalias作ったりshファイルを作成したりしているかもしれませんが、1ファイルにそのプロジェクトで使うコマンドだけを管理できるので、他の方法より管理手間が省けるかと感じてます。


特に強いのがコマンドの補完が効く。make yarn/buildならmakeとtypeしてy + tab、b + tab、でコマンド実行できます。完全に覚えてなくても補完で乗り切れるのは嬉しい。

zsh、fish使っている方なら間違いなく補完できるかと思います。bashユーザーなら bash-completionを入れる必要がありますがMac使っている方ならHomebrewでサクッと入ります。


Makefileには無限の可能性があるんだ、ということを言いたいがための紹介でした。

logicoolのc270nってWEBカメラを買いました。

副業で請けている案件でリモート会議する必要がでてきたので、一番手軽に買えるこいつを購入しました。2000円しなかったはず。安い( ゚д゚)

今日届いたので、普段使うWindows10へセッティング作業していました。 特にマニュアル等付属していなかったので、サクッとUSBポートにつないでHangouts Meetで動作検証をします。



「カメラでエラーが発生しました」

なんでや(´・ω・`)

おそらくドライバが入ってないのでは?と探してみたんですが、公式のソフトウェアダウンロードのリンクが切れていたり、ネットを探してようやくたどり着いた先にあった

Downloads - HD Webcam C270 – Logicool サポート + ダウンロード

のソフトウェア入れても解決しなかったりと、原因わからず。



結論、Windowsのプライバシー設定でカメラのアクセスを有効にしていませんでした。_(:3」∠)_

Windowsの設定から、[プライバシー]>[カメラ]を開き

  • [ アプリがカメラにアクセスできるようにする]
  • [デスクトップアプリがカメラにアクセスできるようにする]

を有効にします。自分の環境ではこれでカメラが映るようになりました。



あ、これマイクもプライバシー設定いるやつだ 😇

wsl2でdocker-composeの風を感じてみる

最近、Linuxノートを利用して作業しているんですが、いいですねLinux。とても軽くて使いやすい。
エンジニアからすればこれほんと最高な環境だと思います(`・ω・´)

PCはこれ使ってます。eBayで4万くらいで買いました。
CPUのベース900MHzなので、Intelli JといくつかのDockerコンテナ立ち上げるとかなり辛さありますが、この程度のスペックでもRails開発はできています。



しかし、Linuxを使ってると、しんどいことがちらほら

  • ドライバ周り基本問題ないけど、USBハブのHDMIを使うとき認識しなかったりと微妙にハマりポイントがある
    • displaylinkとかenviとか触ってみたけど解決できず。本体のHDMI-microポート使ってなんとか回避してます。2、3度端子折りましたけど...
  • もともとManjaro LXDEでインストールした環境にi3wmを後から入れたため、GUIの設定周りが使えずコマンドラインで頑張ることになり、環境構築に時間が取られる
    • キーリピートとかキーバインドとかディスプレイ操作とか
    • ただしLinux操作の知識が多少ついた。学習という意味では無しではないが、ただ開発できる最低限の環境が欲しかっただけなのだ(´・ω・`)
  • Adobe系ソフト、Unityなどが使えない
    • 最近はWEBも便利で代替も生まれてきてますが、代替できないのもある。
    • モバイルに求めるものじゃないのかもしれないので優先度は低いんですが、いざ使うとなったときに選択肢がない



と、いろいろとめんどいことが発生するのです(´・ω・`)

多分おとなしくUbuntuいれておけば、ドライバの問題とか基本的な操作の部分は問題ないんでしょうか...外で気軽にコーディングするための環境がほしいだけなのに、いろいろと設定調べて反映していくの、ちょっと疲れますね、楽しいけど。



さて、そういうこともありLinux以外の選択肢を考えてみようと思ってました。とはいえ最近のMacはなんか微妙(´・ω・`) キーボードとか、3面ディスプレイの認識が不安定とか、ハードウェアのコスパが辛いとか。値段の問題もあるし。

そんなことを数ヶ月前からウンウン考えていたんですが、先月くらいにこんな記事が。

www.softantenna.com

以前、wslでdocker最低限動く記事を書きました。

gdgd-shinoyu.hatenablog.com

あのときはdocker-compose動かなかったのです。しかしwsl2ではLinuxのエミュレートではなく、Linuxカーネルが動いてます。そう、ここには普通のLinuxが存在しているのです。つまりdocker-composeも普通に動く。



最近の開発だと、Dockerさえちゃんと動けばどんなOS上でも開発は困りません。WindowsにちゃんとDocker動く環境が来てしまえば、Windowsに戻ってしまうのもありかなーと思ってます。



ここまでダラダラと書いてきましたが、結論としては、wsl2で問題なくdocker-composeが使えますよ!というお話でした。

# docker, docker-compose を最新のものに切り替えておく

# uname -a
Linux 4.19.43-microsoft-standard #1 SMP Sat Jun 1 16:36:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

sudo service docker start                                                                                                                                                                                             
 * Starting Docker: docker
   ...done.

docker-compose up

Starting etl_digdag_1 ... done
Starting etl_db_1     ... done
Attaching to etl_digdag_1, etl_db_1
digdag_1  | Error: Unable to access jarfile /usr/local/bin/digdag
db_1      | 190724 17:28:31 [Note] mysqld (mysqld 10.0.35-MariaDB-1~xenial) starting as process 1 ...db_1      | 190724 17:28:31 [Note] InnoDB: Using mutexes to ref count buffer pool pages
db_1      | 190724 17:28:31 [Note] InnoDB: The InnoDB memory heap is disabled
db_1      | 190724 17:28:31 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
db_1      | 190724 17:28:31 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
db_1      | 190724 17:28:31 [Note] InnoDB: Compressed tables use zlib 1.2.8
db_1      | 190724 17:28:31 [Note] InnoDB: Using Linux native AIOdb_1      | 190724 17:28:31 [Note] InnoDB: Using CPU crc32 instructionsdb_1      | 190724 17:28:31 [Note] InnoDB: Initializing buffer pool, size = 256.0Mdb_1      | 190724 17:28:31 [Note] InnoDB: Completed initialization of buffer pool
...

マイクリプトヒーローズの作り方 参加メモ

techxgamecollege.connpass.com 行ってきました(`・ω・´)

暗号通貨ゲームプロダクトのリリースと運用周りの話、あまり表に出ることがない(と思っている)おり、貴重な会でした。
いろいろと興味深い話が聞けたので忘れないうちに記録しておきます。

聞いた数値は色々とぼやかしますが、もし出ちゃいけない数値や情報があれば、@shinoyu までDMください。

マイクリプトヒーローズとはどんなゲームなのか?

www.mycryptoheroes.net

ドット絵風味のRPG要素ありのゲームです。UIがリッチになった、古きブラウザゲーみたいなやつです。 クエストクリアしてレアアイテム掘ったり、イーサリアムを使って石買ったりキャラクター買ったりする、ERC721コントラクトを用いたDailyActiveUser・NFT取引量・NFT取引数で世界1位に輝いたDAppsアプリです。 もちろんNFT(Non-Fungible Token)を取り扱うゲームなので、 opensea.ioのようなNFT取引所で売買することができます。

この辺詳しく知りたい人は、 ↓が解説わかりやすいかと思います。 economies2.com

国内で開発していて、自分が遊んだDappsゲーだとかなりわかりやすいUIになってます。いいですね。
勉強会で話して頂いた数値関連。UUもDAUもそこまで多いわけではありませんが、リリースして半年?くらいでリクープ達成し大きく売上を上げているとのことでした。

開発は、フロント側がNuxt.js、バックエンドがGolang、DBはAmazonAurora。その間をgRPCで繋いでいるサービスですね。
スマートコントラクト部分は、みんな大好きSolidity。
最近のモダンな技術スタックを使いつつ、ブロックチェーンもやってるという、興味を惹かれる開発をされているそうです。

構成図

開発裏話

やはりすべてフルチェーンで実装はムリゲ

最初のベータ版、すべての処理をLoom Networkでフルチェーン開発していたそうです。 ただ、めちゃくちゃ遅い。結果、一部のNHT関連処理を除いてオフチェーン(いわゆる普通のWebアプリ)に、1月くらいかけて切り替えたそうで...

Loom Network、一般的なブロックチェーンより圧倒的に早くはあるそうなんですが、 loomx.io

サーバー数十台並べて運用する一般的なゲームアプリにはさすがに対抗できないらしく、せいぜいサーバー1台分くらいの処理しかさばけないんだそうです。
それをすべてブロックチェーン上で実装するとなると、到底捌ききれませんね(´・ω・`)

あと、cross-shardの問題もあったそう。
ETHは、ETHノード群を役割ごとに分けて並列処理するシャーディングというものがあるんですが、別shardにある者同士でトランザクションを行うと、どうしても相手側ノードが完了しないと処理が戻ってこない同期的な問題があるらしく、Shardの分け方も経験を問われるらしいですね。

シャーディングについての解説は下が詳しいかと思います。 lab.stir.network

また、フルチェーンだとゲームロジックをすべてSolidityでコントラクト上に実装しなくてはならず、そこも大変だったらしいです。
そのへんの事情が相まって、フルチェーンをやめて要所だけオンチェーン、それ以外オフチェーンで実装することでゲームとしてのUXを担保している。そんな話でした。

ETHノードのトランザクションを追いかける

あと、ブロックチェーンアプリであるある話として、オンチェーンのトランザクションの待ち時間。

マイクリプトヒーローズでは、コントラクトが走ったあと、該当のトランザクションを監視して完了したらオフチェーン上のDBに値を反映しているそうです。ただ、このコントラクトがETHノードへ伝搬されるのに時間がかかるらしく、ノードによっては安定して拾えないこともあるようで。

安定してトランザクションを追えるETHノードを知っておくことも大事だそうです。

gRPC-WEBでゲームを運用

フロントがNuxt.jsでバックエンドがGolangということで、この間の情報のやりとりはgRPC-Webで行っているそうです。
gRPCについては詳しく解説しないんで、各々調べてください。

結構面白い使い方してるなーと感じたのは、gRPC ⇔ JSONの相互変換をうまく使っているところでしょうか。DBに情報を保存するときはgRPCオブジェクトをJSONに変換して格納しているそうです。 MySqlではJSON型を扱えるんですが、変なJSONを弾いてくれたり、構造をそのまま維持してくれて正規化をしなくて済んだり。そういうメリットがあったと聞きました。

ただし、Golangで開発されているためOmitEmpty問題に悩まされたとのこと。 valueが空と認識されるとJSONからそのキー自体削除してしまう、ご丁寧な仕様がありまして。

qiita.com

上に記載あるように、整数の0もこの対象になってしまいます。
例えばアイテム所持数の管理を行っていたとして使用で所持0になった場合、キーが消えます。DBにJSONで格納する際に想定したキーが無いことによって、度々トラブっていると話されてました。

MCH+

マイクリプトヒーローズを開発した、double jump.tokyo さんが、MCH+という取り組みを始めたそうです。

www.mch.plus

ファイナンスなどの周辺も含めた開発支援プログラムだそうです。今後ブロックチェーンゲーム開発をチャレンジしようとしている人はお話してみると幸せになるかもしれません。

質疑応答・パネルディスカッション

興味深い話がちょくちょく出てきましたが、そろそろ書き疲れたので興味持ったところだけ抜粋です(´・ω・`)

  • 実装の公正性はどう担保しているのか?
    • コントラクト側の実装はGithub上で公開している
      • そもそもEthrscanでコード見れる設定でコントラクト作っている。
      • そのコードと実際のデータと、公開コードをみてもらって、確かにあってる、と考えてもらって運用している
  • infura.ioを使っていないのは?
    • 普通に使えるけど、たまにトランザクションのイベントが取れないことが月1くらいで発生するので使っていない。
      • お金を扱う以上死活問題。速度より安定している方を選択した。
    • 理想はinfura使いつつ、安定している方も用意して多重化しておくのが良い
  • ユーザー獲得どうしている?日本のユーザーあんまりいなくない?海外を前提にゲーム設計しないと難しいのでは?
    • 8割は日本のユーザーで思った以上に日本ユーザー率高い
    • Twitterに巨大なユーザーグループがあって、そこからの流入が多い
    • 日本が一番規制が厳しいが、そのおかげでどこまでビジネスしていいかの線引がはっきりしている
      • 海外ではまだNFTをどう扱っていくかも固まってないところが多い。ビジネスとしての先が不明瞭だと開発しにくいのでは?
    • DAppsゲームYoutuberなる人がいる。媒体として広まる可能性はあり
  • 今後のブロックチェーンゲームの将来ってどうなる?
    • 今はブルーオーシャンだけど、これまでのゲーム史と同じ感じになる。
      • 中小が勃興して数が増え、大手がお金で殴りにきて、海外勢が技術で奪いにくる
        • 年々サイクルが早くなっていて、あと4、5年くらいすれば今のアプリゲーと同じ感じになっているかも
        • 先に沖に漕ぎ出すことが重要。波打ち際で波にさらわれる前に沖にでて、そのジャンルで代表ゲームになることができれば安定するかもしれない

非常に濃い2時間でした。
私的にとても興味があったジャンルの話なので、質問も含め興味深い気づきが多くありました。

このような場を用意してくれた会場提供レバレジーズさんと、イベント運用のテクロスさん。あと登壇とパネルディスカッションされていた方々、ありがとうございました。(`・ω・´)

日本語でeBay商品が買い物できる「セカイモン」は果たしてどれだけお得なのか?

皆様、eBay使ってますか?(`・ω・´) 私は先日初めて使ってみました。購入周りでちょっとトラブルがあり、出品者とメールでのやり取りが大変でした...まあ、PayPalで英語の住所書いてなかった私が悪かったんですが。


さて、セカイモンの話。 今はECの広告の仕事やっている関係もあり、社内で他社EC関連の情報がそこそこ回ってくるんですよね。で、以下のようなニュースが舞い込み、セカイモンの存在を知ることとなりました。

prtimes.jp



セカイモン、eBay公認を謳っている通り、eBayの商品をそのまま買えます。

Webスクレイピングしているのかシステム連携しているか不明ですが、出品情報まで同じですね。全く同じ。これ見る限りだと、セカイモンのビジネスはECってよりeBay代行な認識ですね。

と思ったら書いてあった。
セカイモンではeBayでの検索結果から、日本に輸入ができないものを外して表示しています。
なるほど。

当然、直接eBayで購入するより商品金額は高くなります。出品者とのやり取りを代行している形なので手数料が間に挟まります。この商品だと5600円のものが9400円くらい。うーむ(´・ω・`)



一方、国際送料はセカイモンのほうが安いです。元が6300円の送料が4200円。送料安い理由はわからんですが、まとめて配送してもらって抑えてるのかもしれません。

トータルで見ると(この商品だと)、eBay直の11900円に対して13600円。
2500円くらいセカイモンが高くなります。販売者と直接英語でがんばるコストを考えてペイするかどうか。そこがマッチすれば使ってみるのはアリかもしれません。

他の商品も見てみる

Macbook pro

2017年モデルのMacbook Pro13。
eBay8.3万に対し、10.1万ほど。2万円くらい高いですね(´・ω・`)

iPhoneXR 128GB(Unlocked)

eBay10.06万に対し、12.1万ほど。
これも2万くらい高い。

HuaweiP30Pro 128GB

何かと話題のHuawei。eBay8.9万に対し、10.7万ほど。
これも1.8万とそこそこ高い。

The North Faceのパーカー

デジモノ以外も見ましょうか。

eBay側のセールも適用されるみたいです。これは50%OFF。eBay2.5万に対し、3.05万ほど。
これは5000円くらい高い。


手数料の率の法則性はあまり見えませんが、売れ筋の高額商品とかは手数料高めな結果になりました。_(:3」∠)_

結論: けっこうたかい

おいしい話はそこらへんには転がっていないものですね...

トータルだと、英語ちゃんと使える方にお金投資したほうが圧倒に安くなってしまう。
現実は非情であった。