00:01
皆さんこんにちは、株式会社10Xソフトウェアエンジニアのふたぶーです。
この10X.fmは、10Xを作るおミッションに、
Quality MKCプラットフォームStaylerを提供している株式会社10Xのメンバーが、
キャリアや日々の出来事、学び、プロダクトに対する思いを
包み隠さずリアルにお届けしていくポッドキャスト番組です。
今回は、10X.fm内の企画の一つである
【エンジニアの部屋】という企画としての第3弾で、
お買い物チームのjojoさんにお越しいただいています。
jojoさん、よろしくお願いします。
よろしくお願いします。
jojoさんの自己紹介とお仕事
早速なんですけど、簡単にjojoさんの自己紹介をよろしくお願いします。
ソフトウェアエンジニアのjojoです。
10Xには今年の2月に入社して、今はふたぶーさんと同じお買い物チームで、
主にエンドユーザーが使うお客様のための
ネットスーパーモバイルアプリとウェブの開発をしています。
今日はこの企画、放送日1日1回目から
僕は聞いているのはヘビーリスナーなので、
この場はすごく楽しみにしていました。
よろしくお願いします。
お願いします。
緊張してますか?
若干緊張してますね。
ちょっと緊張をほぐす意味でも、
最近のお勧めのエンタメとかあれば教えてもらってもいいですか?
はい、ぜひ。
最近僕、Netflixのオリジナル番組で
ライトハウスっていうのがあるんですけど、
それにすごくハマってて、その話をしようかなと思います。
ライトハウスっていうのは、
大取の若林さんが悩みをテーマに
振り解きをするっていうバラエティ番組なんですけど、
星野源さんも五大ドームツアーをするぐらい売れてるし、
若林さんも来年か東京ドームでライブするぐらい
めちゃくちゃ売れてる芸人さんだと思うんですけど、
それぞれめちゃめちゃ悩みながら生きてて
満たされない人生を生き続けているっていう
めちゃくちゃ生き様をドキュメンタリー形式で
丸裸に話すっていうところが
すごい人間的な魅力を感じる2人で
いろいろ刺さる部分が多いなっていうので
めっちゃ面白かったですね。
もともと大取のファンっていうのもあるんですけど、
すごい最近見たコンテンツの中では面白かったですね。
いいですね。
僕はNetflixを解約しちゃったんで、
それを見るためにもう1回契約するか悩ましいとこですね。
ぜひ30分ずつで6回なんでめっちゃ見やすいんで、
このためだけに入る価値あります。
他にもおすすめのNetflixの音があれば聞いておいて、
1ヶ月でめっちゃ見るとかやってみたいなって思いました。
そうですね。まとめてめちゃめちゃ見れそうですね。
ありがとうございます。
そしたら今日はエンジニアの部屋っていうことで、
エンジニアリングのこととかいろいろ聞いていきたいなって
思ってるんですけど、最初に何でしょう。
最近のジョジョさんのお仕事、
お買い物チームでやってるお仕事について
お聞きしたいなと思っていて、
ウェブの改善とかやられてたと思うんですけど、
そこら辺のお話聞いてもいいでしょうか。
はい、オッケーです。
そうですね。もともと背景からお話しすると、
Staylerとして主にモバイルアプリを
開発してるんですけど、
Flutterを使うことによって
ウェブアプリも提供できるっていうところで、
副産部的な形で提供してたんですけど、
ウェブアプリ自体がかなりシンプルな構成になっていて、
実際に売り場に入るために
郵便番号を入力して、
それに紐づく売り場があると、
実際に商品が並んでいる売り場に入れる
っていう動線になってたんですけど、
この動線をよりシームレスな体験を提供するために
改善するっていうふうな
開発をしてましたというところです。
もともと前職は結構サーバーサイドメインに
書いてたんで、
Flutter自体触るの結構初めてで、
手探りで進めてたりはしたんですけど、
Stayler自体が結構、
デザインシステムが結構しっかりしている
っていうところがあって、
開発自体はかなりスムーズにできたかなと思ってます。
ただ、結構明治的なルールみたいなところが
まだまだStaylerの中で、
特にクライアントの開発はなかったりするんで、
そういうところを固めながら作っていった
みたいなところを背景としてありますね。
開発の困難と改善
あとは、
FigmaでMockを作って、
それベースで開発を進めたりしたんですけど、
新しくDevModeみたいなところが
使えるようになっていて、
DevModeっていうのを使うと
どういうふうなことができるかっていうと、
実際にFigmaで作ったデザインをベースに、
それをコードに自動的に落とし込んでくれる
っていう機能があります。
これそのまま実際に実装するコードに使えるかっていうと、
そこまでめちゃくちゃ精緻なものは出なかったりするんですけど、
大枠を作ってスタイルを調整するとかっていうところは
かなりしやすかったりしたので、
そういう意味でも開発はすごいしやすかったな
っていうふうには思ってますね。
ありがとうございます。
今お話の中で開発の仕組みというか決まりごと
あんまりなかったみたいなのがあって、
そこらへんはちょっと困ったかもな
みたいなふうにおっしゃってたんですけど、
具体的にどういうところが困って、
それを改善するためにこうしたみたいなのって
あったりしますか。
そうですね。
具体的にはページ固有のコンポーネントの扱い方
みたいなところに結構困ったというか
考えた部分で、
割ともともとはクライアントを開発する人が
今の最善の形で開発していくっていう形になっていて、
個々の実装に委ねられた部分がかなり多かったんですけど、
そうなってくると結構似たようなコンポーネントが
乱立したりとか、
共通化できるすべきものなのか、
それとも特定のページに閉じたものなのか
みたいなところが結構曖昧になってたりしたんですけど、
これを進めながら、
今このお買い物チームっていう軸とは別に
Flutter Guildみたいな、
Flutterの開発のプラットフォームというか
基盤としてどういうふうに開発してたほうが
いいんだろうかっていうところを考えるチームにも
所属してるんですけど、
そこと並行して進めながら固有のページを
それぞれプライベートな
ドメインとして意味のある形として
クラス化して
特定の固有のコンポーネントであれば
特定のページの中で閉じた形で実装を進めていく
みたいな形で一つ名言化して
開発を進めていったとかはあったりしますかね。
例えばそこでページに閉じたコンポーネントを作って
他のページでも似たようなものを作る
みたいになったときは
デザインシステムに組み込まれたりする
みたいなのもあったりするんですかね。
そうですね、それは全然めちゃくちゃあるかな
というふうに思っていて
特にデザイナーさんと連携していく中で
その固有のページをデザインシステムにするかどうか
っていうところは都度議論が発生するところかな
というふうに思うんですけど
そのデザインシステムに落とし込む
っていうふうになったときに
既に特定のクラス化がされているコンポーネントであれば
その辺もかなりシームレスにできて
セキュリティも割とクラスの中で閉じた形で
独立しているものとして切り出しているので
その辺の開発も結構スムーズにできたりするかな
と思いますね。
ありがとうございます。
Figmaのデブモードについて
もう一個Figmaの話もあって
そこら辺もちょっと気になったんですけど
Figmaのデブモードについても
もう少し具体的に聞いてみてもいいですか。
そうですね。
具体的には
もともと今年の春ぐらいですかね
新しくFigmaでできた新機能で
デブモードっていうのがあって
これを利用すると開発者が
よりFigmaをコードベースで見たいとか
パリングであったりとかマージンみたいなところを
かなりシームレスに見れるっていう機能が
新しくついてたっていうところです。
プラグインとして
Flutterでも
コードベースで
実際にデザインを見ることができるっていう
プラグインがあって
Flutterのコードによるデザインシステムの組み込みとFlutter for Webでの開発
それを使うと
Flutterのコードっていうところが
Figmaベースで見れたりします。
ただかなり
コンテナーであったりとか
パリング、マージンみたいなところが
多重で作られて
パッとなコードが
自動生成されたりするので
その辺は現状のデザインシステムに
組み込んだ形に
適切に置き換えたりとか
最終的にやりたかったところが
Flutter for Webでの実現だったりするんで
レスポンシブ対応みたいなところは
結構調整が必要だったりするんで
デブモードで作られたコードを
そのまま利用はできなかったりするんですけど
GitHubのコパイロットも合わせて
かなりサクサク開発するっていうのは
このデブモードを使った開発としては
結構良かったかなって思ったりしましたね。
なるほどですね。
一人でうんうん悩むっていうよりかは
一旦そこで叩きみたいなのが
Figmaなりコパイロットなりでできるんで
そこから自分がフィードバックを与えて
開発をしていくみたいなのが
できるようになってるっていう感じですかね。
そうですね。まさにそうで。
本当に全く新しいコンポーネントを
ゼロから作るとなると
割とフラッターにめちゃくちゃ慣れてる人であれば
かなりそこは問題ないと思うんですけど
新しくこのフラッターを触る
みたいな人にとっては
すごくその体験は良かったかなっていう風には思います。
めっちゃいいですね。
逆にフラッターで困ったところっていうと
ライブラリーが
フラッター法Web
Webでは対応してないとかっていうのがあったりとかして
具体的に言うと
もともとアプリで実現してた
マップを表示させて
そのマップに対してピンを打って
そのピンから郵便番号ベースで
住所を取得するみたいなライブラリーがあるんですけど
アプリ上では問題なく動いてるんですけど
ブラウザーだと
特にサファリだと
正常に動かないみたいなところで
フラッターのWeb版には対応してません
みたいなライブラリーがいくつか出てきて
それは
アプリとWeb
両方一緒に開発できるじゃんっていう
メリットとの逆として
うまく動かない部分があるとかは
ちょっと困ったところとしてはあったかなと思います。
なるほどですね。
ちなみに今回の場合は
Webのマップの対応っていうのは
どういう風にしたんですか?
そうですね。今回の場合は
完全にマップで実現するのは
既存のライブラリーだと難しかったので
UI自体をもう少しシンプルなものに変えて
マップ上にピンを打つっていうことではなくて
郵便番号から検索するみたいな形で
UI自体を大きく変えたっていう風な形になります。
なるほど。
アプリとWebでそこは
ちょっとUIも変わるようにはなっちゃうけど
やりたい体験とか
機能自体は実現できてるみたいな風に
落ち着いたっていうところですかね。
そうですね。おっしゃる通りです。
ありがとうございます。
Webトップの改善みたいなところ以外でも
いくつかやられてるなっていうのは
僕も同じお買い物チームなんで
横で見ててあったと思うんですけど
他にもこの辺ちょっと最近やってて
話しておきたいなっていうのってあったりしますか。
そうですね。
カテゴリーやランキングをタブで表現する改修
現在進行形でやってるところとして
タブの回収みたいなのをやってたりしますと。
これはどんな対応なのかというと
今実際にアプリを開いていただくと分かるんですけど
商品が並んでる売り場タブっていうのが存在するんですけど
その商品の一覧をお肉であったりとか
野菜であったりとかっていうところで
ナビゲーションで切り替えるっていう風な
今設計になってますと。
このナビゲーションタブっていうのが
完全にタブイコールこのカテゴリ
お肉であったりとか野菜であったりとか
っていうカテゴリで今完全に表現されてるんですけど
今後より拡張性を持たせて
幅広い売り場の表現を行うために
このカテゴリイコールタブっていうところから
タブっていう概念をカテゴリを一つ抽象化させて
上位概念として売り場
野菜の売り場お肉の売り場
見せ方としては同じになるんですけど
っていう形で表現することによって
今ナビゲーションタブで表現している部分を
カテゴリに紐づく商品以外に
例えばお客様のお知らせであったりとか
クーポンであったりとかっていう別の情報を
より広く表現できるようにするっていうふうな
改修を今入れてますと
これが結構
割と最初はタブに一個抽象化させて
上位概念入れて対応すればよいんじゃないか
っていうふうに進めてはみたんですけど
実際はかなり根深い問題で
なかなかやりがいはあるなっていう感じで
今考え進めたりしますね
やりがいっていうのはどういうのがありますか
そうですね
まず売り場っていうところが
かなりStaylerのお客様アプリを
使う上で
結構コア機能になっている部分で
商品の詳細情報とかっていうところも
深く紐づいている部分っていうところなんで
これを一つ一つ紐解く必要があるなっていうところが
結構面白いところであり難しいところでありますと
例えば今説明させていただいた
カテゴリーイコールタブみたいなところから
カテゴリーを一つ抽象化させて
上位概念を持たすっていうふうにやったときに
カテゴリーとは別にランキングみたいなところを
表現する必要がありますと
なのでカテゴリータブもあるし
ランキングタブもあるみたいな形で
表現するために一つ
売り場タブっていう抽象クラスを一つ用意して
それを実装する
それぞれカテゴリーとランキングが
その抽象クラスを実装することによって
型によってタブの振る舞いを変えていく
みたいなところを今やってたりします
めちゃくちゃいいですね
もともとタブと三つ結合になっていた商品
みたいなカテゴリーっていうところを
タブとカテゴリーを分けるっていうところと
タブがカテゴリーにもなれるし
ランキングにもなれるっていうような
実装を今やっているっていう感じなんですね
そうですね まさにやってますね
ありがとうございます
何か言いかけましたか今
ごめんなさい
あとは実装する上で
Flutter 3.0の新機能であるシールドクラスの利用
Flutterを使ってるんですけど
今Flutterの3型を使ってて
その新しい機能として
シールドクラスっていうのがあって
これを使って抽象化された
売り場タブっていうのを表現してるんですけど
これの良いところとしては
例えばカテゴリー ランキングっていうのを
それぞれ実装 抽象クラスを使って
実装したっていうふうになったときに
スイッチ分とかでそれぞれを
型で判別して出し分けるんですけど
新しくお知らせタブみたいなところが
実装されましたっていうふうになると
そのスイッチ分で
お知らせタブについての係数分がないと
ちゃんとコンパイルエラーになったりする
っていうところがあって
この辺はすごく実装漏れであったりとか
っていうところをふさげて
この仕組み自体はすごい良いなっていう感じで
この辺も試しながら
今実装できてるのはすごい楽しいですね
めっちゃいいっすね
僕とかは元々Androidのエンジニアで
Kotlinで書いてて
Kotlinもあるんですね
スイッチ分 ウェン書いて
満たす要素全てがケースに書かれていないと
コンパイルでエラーになるみたいなのがあって
最近だともそれが入って
自分は元々やらせたことができるようになってきて
嬉しいなって思ってたりしますね
いいっすね
ガンガンそういうのを入れてって
改善を回していきたいなっていう気持ちが
日々高まってますね
そうですね
ありがとうございます
ちょっと別の方向というか観点の質問にも
なっちゃうかもしれないんですけど
そうやって最近色々改善していって
くれている中で
お買い物チームの楽しさとフィードバック
お買い物チームの楽しさとか
大変さみたいなところって
何かあったりしますか
そうですね
お買い物チームの楽しさはやっぱり
実際に直接お客様が使うアプリに
価値を提供できる機能を
どんどん付加価値として付け入れていって
そこから実際にフィードバックが
もらえるっていうところがやっぱり一番
面白いところかなっていう風には思っていて
それと合わせて
最近は同じくらい
ユーザー体験の向上であったりとか
品質みたいなところも
よりコミットする必要はあるなという風に思っていて
その辺の幅広い領域ができるっていうところは
お買い物チームのすごい面白いところかな
っていう風には思ってます
逆に言うと
それが難しさにつながってくるところかな
っていう風に思っていて
お買い物チームとして
お客様アプリを作る上で
関わるところ全てっていうところが
僕らの守備範囲になったりするので
かなり幅広いドメイン知識が求められる
っていうところが難しいところ
やりたいところめちゃくちゃあるけど
リソースは限られるので
それで選択と集中しなきゃいけない
っていうところがあったりするので
そこは結構難しいところだなっていう風に
やりながら思ってます
ありがとうございます
優先順位の決定とロードマップの振り返り
今の流れ2つぐらい深掘ってみたいなと思っていて
1個は楽しさみたいなところで
お客様アプリ
お客様が使うところなので
直接のフィードバックがあるみたいなところとかは
結構楽しいところっていう風におっしゃってて
フィードバック得るための工夫とか
例えば社内で分析するためにも
必要なこととかってあると思うんですけど
この辺もチームの中でいろいろやっていったりとか
するんですかね
そうですね
今まさに進めてる施策として
実際にデザインを変更してみて
ユーザーフィードバックを取ってみる
っていうところがあるんですけど
それが実際にABテストを埋め込んで
効果測定をするっていう仕組みを
実際に要件定義をする段階で設計して
作っているとかっていうのがあったりとか
あとは実際にユーザーのアクションログを
埋め込むっていうところで
適切にフィードバックを獲得しよう
っていうところで進めたりします
そこに関してはまだまだ改善の余地とかはあるし
適切にもっと別の角度の情報を集めたい
っていうところもいっぱいあったりはするんですけど
今小さくそれを改善しながら回している
っていうのが現状だったりしますかね
ありがとうございます
もう1個優先順位の話もあったと思っていて
色々関名がチームにはたくさんあって
やることがたくさんある中で
何からやらなきゃいけないのかっていうのも
決めるの難しいっていうお話で
何かそこもチーム内で工夫しているところとか
あれば教えてください
そうですね
チーム内で工夫しているところとしては
基本的には
TenXとして達成したいフォーカスっていうところが
半期ごとに設定されていて
そのフォーカスから逆算して
ロードマップを引いていくっていう取り組みをしています
なので優先順位に関しては
それによって変わっていくっていうところで
僕らの共通な指標 目線合わせっていうのが
それで一定できているかなっていうところがあります
合わせてそこから逆算して
ロードマップアイテムを積んでいくっていうところは
基本的にPDMが行って
それを叩きを作ったものを
僕らお買い物チーム全体で叩いて
改善を回すっていうところをやってたりします
それで決まったロードマップに関しても
毎月振り返りって形で
現状の進捗であったりとか
優先度に入れ替わりがないかっていうところを
振り返りを行って
フィードバックをかけて改善するっていう取り組みも
できてたりするっていうところですかね
いいですね 定期的に振り返りっていうのはめちゃめちゃいいですね
そうですね その取り組み
すごい僕もいいなっていうふうに思っていて
半年ぐらいの単位でロードマップを引いても
そこでの見積もりってかなり荒見積もりであったりとか
そこでの地点での優先度っていうところは
半年後また変わってるかもしれないっていうところは
往々にしてあるので
その小さくフィードバックをかけていくっていう動きは
すごいいいなっていうところで
引き続きやっていけたらいいなって僕も思ってますね
ありがとうございます
結構いい時間になってきたんで
ちょっと今回はこの辺りで
まだまだたくさんお聞きしたいことあるんですけど
それまた別の機会でお話し聞ければなと思ってます
TenX FMではリスナーさんからのお便りを募集しています
エピソードの感想やTenXのメンバーに聞いてみたい質問など
どんなことでも構いません
番組概要欄にあるお便りフォームからの投稿
またはTwitterでハッシュタグTenX FMでツイートをお願いいたします
またTenXでは現在さまざまな職種のメンバーを募集しています
このTenX FMを聞いてTenXに興味を持った
カジュアルに話を聞いてみたいと思われましたら
こちらも番組概要欄にある採用情報
またはTenXのホームページのリクルートから応募をお待ちしております
最後にSpotify Apple Podcastなど
お聞きのPodcastアプリで番組のフォローを忘れなく
最新エピソード配信時にお知らせが届いたり
また過去エピソードの再生済み 未再生が一目で分かるようになり大変便利です
今日のお相手はふたずーとジョジョさんでした
それではまた次回
