00:06
こんにちは、10X CTOの石川です。
10Xfmは、10Xで働くメンバーが緩く話すポッドキャストです。
今回は、Staylerの特徴的な技術の一つであるサイトコントローラーを
今後は取り扱わないという意思決定をしたんですけども
その話をしようと思います。
このエピソードでは、サイトコントローラーとはそもそも何なのかとか
どういう背景で導入されたのかとか
どういう背景で廃止になったのかという話をしようと思います。
ゲストには、ソフトウェアエンジニアの北経に来てもらっていて
何で呼んだかというと、北経が割とサイトコントローラーを変えてきたメンバーなので
その思い出話でもしてもらおうかなと思って呼びました。
北経、自己紹介をお願いします。
めちゃくちゃ噛んだな。
はい、北と言います。
みんなからは北経と呼ばれています。
ソフトウェアエンジニアをやっていて、最近はライフのネットスーパーのアトリを担当しています。
よろしくお願いします。
サイトコントローラーとはどれくらいの付き合いなんですか?
入社してからずっと2年くらいですかね。
当時と今ではもう見る目が違うというか。
サイトを見る目がちょっと変わったかもしれないですね。
この要素はこれに使えるなみたいな。
この通信内容はこういうことをやってるんだなみたいな。
そんなこんなでサイトコントローラーを開発していると
ウェブサイトを見る目が変わるということで。
そもそもまずはサイトコントローラーとは何なのかというのを
簡単に説明しようと思います。
サイトコントローラーというのは名前の通りで
ウェブサイトを自動操作するものになっていて
そのプログラムのことを指しています。
ステイラーでは何に使っているかというと
パートナーシップを組んでいるパートナー企業さんが
ネットスーパーのAPIを持っていないので
それを代用するためにサーバーサイドで
カペティアというヘッドレスクロームを立ち上げて
リクエストに応じて自動操作の内容を変えて
それでレスポンスを返すという形で
APIの代わりをするものになっています。
それは最初事業上必然性があって
ネットスーパーと提携するという上で
普通にAPIの要件を定義して
開発期間もあって結合テストして
それで初めてリリースするという形でも
いっちゃいいんですけれども
それにもどうしてもパートナー企業に
投資リスクを受け入れてもらわなければいけないし
開発期間としてもすごいかかるという状態だったので
このデメリット2つを一気に解消するものとして
先方は既存のネットスーパーさえ
引き続き運用していればよくて
03:01
我々がそのサイトを自動操作することによって
APIを不要にするという形で
開発の投資リスクと期間の圧縮というのを
図っていたという形になっています。
今このサイトコントローラー方式で
動いているものが3つありまして
糸床堂のネットスーパーのアプリと
広島のフレッサのネットスーパーのアプリと
あと東京と大阪中心にある
ライフのネットスーパーの3つで動いています。
これまではサイトコントローラーを中心に
アプリをやってきていて
運用も1年ぐらいやっているのかな
1年以上ぐらいやっていて
いろんな問題点を我々は経験しているんですけど
その点について聞こうかなと思います。
まずサイトコントローラーといえば
こういう問題があるよというのを
簡単に説明してもらえると。
3つくらいあるかなと思っていて
まずAPIと比べた時に遅いという問題があります。
普通のAPIだったら
例えばカートに商品を入れるとかって
APIのリクエスト1回で済むと思うんですけど
サイトコントローラーの場合は
例えばまずログインをして
その後に商品ページに移動して
カートに追加するボタンを押して
ちゃんとカートに追加されているかチェックして
こういうステップを踏んでいく必要があって
どうしてもAPIを呼ぶよりも遅くなってしまう。
2個目は不安定というところですかね。
そういうふうにサイトを操作していくので
例えばこのボタンを押したら
この新しいUIの表示が現れて
それを参照するみたいにするんですけど
それが表示するのにアニメーションが付いてたりとかして
値を取ろうとしたタイミングで
まだアニメーションが終わってなくて
値が取れなかったりとか
そういう不安定さがあったりとか
あとは壊れやすいってところもあって
先方のシステムの回収とかで
HTMLの構造が変わったりとか
あと僕がよく体験したやつだと
年末年始とか
次の日台風が来ますみたいなときに
サービスが一時的に注文を受け付けなくなって
普段と違う表示になってて
それでもう失敗しちゃったりとか
そういうこともよく起きたりとかしてましたね。
この話を聞いていて
サイトコントローラーを開発したいっていう人は
相当な物好きしかいなそう
そんな気します
一個一個掘り下げていくと
遅いっていうのも
普通に遅いっていうよりは
もうなんだろうな
ウェブサイトって考えたら
ログインして
商品のところに行って
カートに追加して
06:00
それでカートに入ったことを確認できるっていうのに
5、6秒とかかかるのは
自動操作でそれぐらいかかるのは
しょうがないかなって感じするんですけど
APIで5、6秒とかってなると
むちゃくちゃ重いみたいな
要パフォーマンス改善必要なAPIみたいなね
そうそう
モニタリングシステムから
このエンドポイントが異常に遅いから
直せって言われるようになった
遅い要因も
ページ遷移してるからとか
そもそも余計なリソースも
いっぱい読み込んだりとか色々あって
遅い中でも最小と比べて
多分いくらか改善はしてると思っていて
例えば
画像みたいなリソース
読み込まないようにするとか
確かそういう改善も入れてたよね
そうですね
ページの遷移を検知するにあたって
なんだろうな
画像とかそういう全部のリソースが
ロードが終わったタイミングで
ページ遷移完了みたいな風に
最初検知してたんですけど
特定の画像のレスポンスが返ってくるのに
数十秒かかってくるとか起きたりとか
する時があって
そういう時はもう
リクエストをアボートするようにしたりとか
そういう対応を
入れたいとかしました
そういうことあったね
特定のリソース
特定の外部サイトの
SDKのJavaScriptを読み込むのに
かかって
そいつのせいで
ローディング完了のイベントが
飛んでこなくて
操作ができないみたいな
確かにそういうの経験してから
他のサイトで
読み込みっぱなしのやつとかたまにあるけど
ちゃんとしてくれよって
思うようになって
サイトを見る目が変わりましたね
そうそう
レポートしてあげたくなっちゃう
あと不安定っていうのもね
これもしょうがないことかな
これに対しては
あんまり
いろいろ改善するにも
限界はあったかな
一個今思いついたのだと
UIを操作するんじゃなくて
そのウェブサイト内で
内部で読んでるAPIを
JavaScriptから
AJAX呼んであげるっていうのは
一個改善
策の一個だったかなという気がしてます
確かに
それを
最初の方にやり始めて
全部APIでやればいいじゃん
ってやったら
思いのほかのAPIで呼べるやつが少なかったりとかして
クリックからは逃れられない
と思ったり
あと壊れやすいっていうのも
オンラインで
やっぱりもともと
既存のネットスーパーさえあれば
できるっていう形で
09:00
推してるんだけど
そこの
こちらとしては既存のネットスーパーが
変わらないっていう前提でサイトコントローラーを書いてる
けど
パートナー企業からすると
既存のネットスーパー
改善していくのって当たり前だし
施策とかは絶対うつに決まってるじゃん
っていう感じがあって
常にギャップがあって
ふとしたときにあれ壊れてるみたいな
ことになったりとかして
大変でしたな
そうですね
そういうのを
なるべく検知できるようにするために
いついいテストを定期的に実行したりとか
実行したテスト開発したときの
ページを保存しといて
ページ単位でユニットテストを書けるようにしたりとか
やれることは結構やっていて
サイトコントローラーっていう
スタートからして
地獄みたいなところではあったんだけど
なんとか技術的に
改善できる限りは
してたけど
最終的には
サイトコントローラーの運用って大変やなっていう
結論かな
そうですね
なんやかんやで
今1年弱ぐらい運用してきたんですけど
結構我々としては
事業の仕様が変わってきたかな
と思っていて
このステイラーを始めたときって
最初は
いわば実績がない状態
パートナー企業にとっても
我々が信頼にたる
会社なのかどうかって
わからない状態だったんだけど
今は伊藤八角さんとか
フレッサさんとかライフさんとか
八角さんとか
そういう
パートナー企業の方々と
組ませていただいて
実際に成果を出していて
我々と組むことができれば
ある程度成果は出せるっていうのが
業界の中でも示せたかなと
思っています
そういう状況になってくると
もともと標語をしていた
開発不要でサービスインできることっていうのは
優先順位がかかってきたなと思っていて
もともと回避していた
開発の投資リスクとか
開発の期間とか
っていうものは
そんなに重視しなくても良くて
むしろ楽しくAPI連携していきたいし
やっと会社としても
その土俵に立てるようになったかな
っていう感じ
だったと思います
そこが一つの
事業の強めの変化かなと思っていて
もう一個は
既存のネットスーパーを
ネットスーパーを持っていない企業も
パートナー候補の
ターゲットとしてメインに
据えるようになってきたっていうのがあって
もともと
ネットスーパーを持っている会社って
ごく人握りの
限られた会社しか持っていなくて
スーパーって
全国つつ裏裏にあって
それぞれの地域でそれぞれの会社が強いみたいな状態
12:00
で
そうなっている中で
ネットスーパーを持っているところだけを
パートナー候補にしていると
どうしても広がりが持っていないので
持っていないところに対しても
フルセットで
システムを提供して
サービスできるようにするっていうのが
もう一つ
さらにもう一つが
ネットスーパーって
その構造自体にすごい課題があって
もともと
サイトコントローラー方式だと
お客様が操作する側しか手を出せなかったんですけど
より
もっと深いというか
広い範囲にシステムとして関わることによって
もっと
総合的な体験の向上に取り組める
っていうのがあるかな
あるかなと思います
そこに足を踏み入れていく
っていう決断が
三つ目の塩目の変化かなと思います
ちょっとサイトコントローラー方式の話に戻ると
サイトコントローラーが
解決した課題
もう一個あって
実は既存のネットスーパーがあると
店舗の在庫管理とか
入った注文のピッキングとか
配送管理とか
そういうシステムを開発しなくてもよかったんで
TENXとしても開発ボリュームが
ちっちゃく済んでたっていうのが
ありましたと
でも我々は開発システムも大きくなってきたんで
そういうところに対しても
開発リソースを当てて
システム全体を作っていくという
仕組みになったっていう感じですかね
そういう感じで
ネットスーパーに関わるすべてを
開発することによって
どういう課題が解決できるかっていうと
在庫管理とかこないオペレーションとか
配送管理ができることによって
品揃えを店頭のものに近づけたりとか
サービス現価をきちんと把握できるようにしたりとか
配送ステータとお客さんに
もっと細かくコミュニケーションする
例えば今
トラックが前の家を出たんで
あと10分くらいで着きますみたいな
コミュニケーションができるようになるとか
そういう感じで
あらゆるところに手を出せるようにしているっていうのが
今の仕組みの変化かなと思います
そういう感じで
スタートの時点は
ちょっと荒い感じで
既存のサイトを操作して
APIなしで
スタートしてきたんだけど
だんだん自分たちの足元が
固まってきたことによって
正しくAPI連携できるという形になりました
サイトコントローラーは
我々としてはもう卒業かなという段階になりました
このサイトコントローラー時代を
振り返ってみて
だけはどうですか?
ぶっちゃけ結構大変だったんですけど
よく人と飲みに行ったりとかして
きたけさん最近何の仕事やってるんですか?
15:00
こういうことやってるんです
反応されちゃうことも多かったんですけど
でももしこれやってなかったら
今のこういう状況には
絶対なってないと思うんで
そこは今振り返ってみて
やってよかったなというふうに思っています
僕たちがネットスーパーのシステムを作る
本当に足掛かりになってくれたんじゃないかな
というふうに思います
確かに
ここはこの技術によって
明確にこの事業の
土俵を変えたなというのは
僕も実感としてあるんで
これは
すごいCTOとして
面白い体験ができたなという
感想を持っています
事業のしお目を読んで
技術的にもちゃんとシフトしていくのは
大事かなと思っていて
最初はサイトコントローラーでうまくいったから
サイトコントローラーでやっていこうぜ
ちゃんとしお目を
終わったなというタイミングで
サイトコントローラーを卒業しようと
会社全体で
すっと合意したじゃないですか
それがすげえよかったなと思ったので
今後もちゃんと
しお目を読んでいきながら
適切な技術を選択していくのは
すごい大事だなと思いました
今日は
そんなところですかね
そうですね
今後もやっていくということで
はい
今回は北経をゲストに
お呼びして
サイトコントローラーの思い出話をしました
ありがとうございました
