お会計チームとその役割
皆さん、こんにちは。株式会社10Xソフトワークエンジニアのふたぶです。
今回は、10Xfm内の企画の一つである、エンジニアの部屋の第7弾として、
iguchi-sanにお越しいただいています。iguchi-san、よろしくお願いします。
よろしくお願いします。
最初に、簡単に自己紹介していただいてもよろしいでしょうか。
はい、10X所属、iguchiです。
今、3年目になりまして、入社してから開発ソフトウェアエンジニアとして働いています。
お会計チームというところに所属していて、気づきはチームで一番フル株になってしまっていますが、
その中で、決済周りとか、会員周りの開発を日々している感じです。よろしくお願いします。
よろしくお願いします。
お会計チームって、具体的にどんなことをやられているかって、また教えてもらってもいいですか。
はい、今10Xの中では、いくつか開発チームが分かれている感じで、
かつ、ネットスーパーを扱っているチーム群と、新規の開発をやっているチームがある状態です。
僕が所属しているのは、今話したいわゆるネットスーパー側の開発で、
かつ、ドメインとしては、お会計という名前の括りで固められた内容を扱っています。
具体的には、先ほどお話ししたような決済とか、ポイント利用、ポイントの付与、
あるいは、実際にユーザーの人が認証するときの認証の基盤周りの開発等がメインになっています。
ありがとうございます。
OIDCの実装とその課題
最近だと、僕も別のチームで見てて、OIDC周りの実装とかやられてたなと思うんですけど、
その辺のお話、最初に聞いてもいいでしょうか。
そうですね。早速という感じではありますけど、良さそうです。
OIDC、スギーですね。パートナースギーでやられてたと思うんですけど、
開発で大変だったところとか、こういうとこ工夫したよとか、もしあれば聞いてみたいなと思ってるんですけども。
そうですね。今回、いわゆるOIDC認証というのを、
去年ですね、パートナーとしてスギー様に提供したというのが始まりになります。
基本的にStaylerの認証は、自社の認証基盤といってファイアスターを利用した一般的な認証を利用していたんですけど、
結構パターンが広がっていく中で、彼らの認証と統合したい、
要は顧客の基盤というのを一つにした上で、彼らが提供するサービスの一つとして、
ネットスーパーみたいなもの、あるいは小売のECサイトとして、
我々を使っていただくという形にされたいパートナー方が結構、
潜在的にもいらっしゃるというのが、このOIDC開発の背景にありました。
難しさ的なところ、今のが背景なんですけど、難しさ的なところで言うと、
今回、いわゆるOIDCという共通の基盤を利用するということになったので、
テイクス側として、そのOIDCの調査から始めて、
実際にStellarのアプリに組み込んでいくというところをゼロからやっていきました。
割と既存の認証に、実装としてくっついているところとかもちろんあったんですけど、
そのあたりをリファクターとかをしつつ、生きもときながらOIDCという基盤の
組み込みみたいなものを進めていきました。
ありがとうございます。いろんなパートナーさんが、自分たちを認証基盤と統合したい
みたいなところがあるというふうにお伺いしたんですけど、もう少し聞きたくて、
どういった用途があるので、そういうことをやりたいみたいなのってあるんですかね。
そうですね。これは結構一般論になっちゃうかなと思うんですけど、
一つはユーザーの方のUX改善。具体的に言うと、サービスに応じて毎回IDパスを入れていくというのは
比較的煩雑な作業ですし、管理するIDパスが増えるというところからも、
ユーザーの負担を減らすという意味で、認証基盤を一つにするという道があります。
もう一つは、データとして横串に統合、顧客の情報基盤として横串で見れるというところがあるので、
例えばサービスAとサービスBを利用しているユーザーがこれだけいるとか、
そういったデータの利活用が、特にパートナー側のほうでやりやすくなるみたいなところが、
このOIDCと共通の基盤を利用するモチベーションになるのかなと思っています。
なるほど。ありがとうございます。確かにそれができると、
ステーラーじゃない他のサービスを使っていて、
スギーさんのIDを使ってログインしている他のサービスとデータがやり取りできるので、
あっちで買ったこれ、あなたが買っているので、こっちでもこれどうですかとか、
そういうのもできるようになるという感じなんですかね。
そうですね。どうしてもステーラー側からのデータを提供すると、
Eメールとかの都合になるんですけど、やはりそれだと識別紙としては十分ではない。
それと比べるとパートナー側で裁判している、いわゆるサブと言われるような識別紙を利用すれば、
より個人の特定がしやすくなるというふうになるかなと思っています。
なのでデータとしてもきれいになるので、OIDCなどを利用して基盤を共通化するというのは、
パートナーとしてはデータ利活用という意味でも嬉しいところかなと思っています。
今後の開発の展望
ありがとうございます。実装する上で既存のところが割とべったりみたいなのも、
さっきおっしゃっていたと思うんですけども、具体的にこの辺苦労したとか、
大変だったこととか聞いてみてもいいですか。
はい。いわゆるファイアベースの、ファイアベースソースの認証に実装部分がかかっていたりとか、
それを前提とした、いわゆるお客様にどういう売り場を表示するかみたいなところの制御みたいなところが、
比較的サービス当初からファイアベースソースの制約の中で作られてきたというところがあるので、
そのあたりの認証基盤として抽象化しきれていない処理を利用されていたというところで、
ファイアベースソースの依存みたいなところが一定あったというのが振り返っての所感になります。
ファイアベースの依存は剥がすの大変でしたか?
そうですね。例えばファイアベースソースって結構嬉しいポイントとして、
ゲスト会みたいなことは割とやりやすくなっていたりすると思っていて、
そのユーザーがどういう人かみたいなやつをログイン前から識別資料を付与して管理できるような状態だと思うんですけど、
一方でOIDCの認証を入れることによって、そのあたりのゲスト会みたいな概念が使えない方が整理としてスッキリするみたいなところがあったので、
改めて会員としてどういうふうに扱うかみたいな議論から、
このOIDCの認証の開発が行われていたという感じはしていますね。
めっちゃいいですね。開発で機能する開発だけじゃなくて、
そのために必要なリファクタリングとか準備もしっかり時間を取ってやっていけたみたいなところですかね。
そうですね。OIDCの実装も振り返ってみたら、いきなりOIDCの実装をしたわけではなくて、
既存のいわゆる会員のアカウントみたいなところをリファクタリングなり、
ドミニモデルとして改めて再定義するみたいなところが割と作業の初期の重要な部分として利用されていたという形になりますね。
あれがなかったら多分そんなに簡単にOIDCの認証に切り替わるというのはやっぱり難しかったのかなという印象はあります。
素晴らしいですね。今ので思い出したんですけど、そういえばお会計チームというと、
開発の進め方が結構独特というか、僕のいるチームとは違うなと思っていて、
最初に必ず1人みんなでそれぞれがPoC的な実装をやってみてから、
それぞれのいいとこやメリデリみたいなのを意見交換して、
この実装で行こうみたいな進め方をしているというふうに伺っていたんですけど、合ってますかね。
そうですね。そういうアプローチを去年やっとも実験的に取ったというのはあります。
今回の統合IDに関しては別にそのやり方ではなかった。
一部そのやり方を取っています。
話が広がってしまいますが、YDC以外にも3D石油みたいなところの導入も去年やったんですけど、
その時は各々が考える最強のホゲホゲみたいな形で実装した上で、
それをもとに実装方針とか実装内容みたいなのを叩き台として検討するみたいな、
そういうアプローチは手段の一つとして取りましたね。
他の方法も開発の中ではやるけど、一個の方法として取ることもあるみたいな感じですかね。
そうですね。去年のやつは割と実験性が高く、結果的にうまく回ったので、
そういう選択肢として今後も取り入れるかなという感情は持ってますね。
ありがとうございます。
お会計チームやってることで他のところもちょっと聞いてみたいなって思ってまして、
例えば決済とかのところ以外でも会員周り、さっきの都会議員もそうですけど、
今ステイラーだと事業者会員っていうのもあったりとか、
あとはプラットフォームとして開発進めていこうみたいな話があったりとかすると思うんですけど、
その辺もちょっとお話聞いてもいいでしょうか。
そうですね。チームの名称がお会計と言っているんですけど、
比較的より抽象度を高くしていくと、
扱っている技術特性として割と硬いものを扱うみたいなところがチームの特性としてこれまで多くありました。
具体的にはよく言われるシステムオブレコードみたいなところで、
比較的自動テストなどを厚めに作っていって、
守るべきものを強く守るみたいなところが開発のテーマとしてよくありました。
それが一つとしては決済だったりポイント利用、
あるいは認証周りも固く作る必要があるので、
お会計チームが一部になってやっているという背景がありました。
ありがとうございます。認証周りについて、最近やったやつで大変だったなとかあったりしますか?
そうですね。認証に関しては、今回Sugi向けにOIDCを会員向けに入れていたんですけども、
今後踏まえて実際に他パートナーへの展開だったりとか、
あるいは顧客向けだけではなくてパートナーの従業員向け、
そのあたりの認証もOIDCを利用したプラットフォームというのを広げを持ってやっています。
ありがとうございます。
お会計チームの今後の開発とか、こういうことは今後やりたいみたいなのってあったりしますか?
比較的これまで守りの開発みたいなやつがやはり多くありましたと。
具体的に言うと、ステーラがリリースされてから3〜5年程度経っていると思うんですけど、
自立性の高い開発文化
その中でもプロダクトの進化とか利用されるユーザーが増加することに応じて、
比較的より固めに開発するということをここ数年やってきましたと。
一方で事業のトップラインを上げる、売り上げを上げていったり、
パートナー側のコストを下げるみたいな観点で言うと、
例えば先ほどFutabさんからも出たような事業者会員という形で、
パートナー側の選択肢を増やす取り組みが取り込めるようになってきましたと。
今後もこういった守りの開発だけではなくて、
そういったパートナーのトップラインを上げるような開発として、
例えば決済手段を増やしていくとか、
あるいはより柔軟性の高い決済フローを提供することで、
より良い購買体験をお客さまに提供するなど、
そういった伸びしろは今のチームの状態だったら全然あるかなというふうに感じています。
ありがとうございます。
OIDC連携の挑戦
リスナーの方にはTenXに興味があって、
働くことも考えたりとかいるかもなって思ったりするんですけど、
どういう人と一緒に働きたいとかってあったりしますか?
そうですね。結構先ほども一人一人が一旦僕を動かしてみたみたいな話あったと思うんですけど、
割と自律性高く動かれる方の方がよりやりやすさを感じるかなと思っています。
結構各々がそれぞれを信頼したりとか、
あるいは会話するときの目線みたいなところが、
比較的会いやすいような方々が今所属して開発をしているので、
割と自由度高くとか、自分の信念を持って何か開発したいみたいな人に関しては、
割と解き込めやすい状況なのかなというふうに感じています。
ありがとうございます。
一旦最初に用意したところは聞いたのかなと思ってまして、
まだこれも話したいみたいなやつとかってありますか?
そうですね。
ちなみにふたべさんが所属されるリバチームから見て、
外形チームの印象とか、どんなことやってるなみたいな、
そんな印象論みたいなやつをぜひ伺ってみたいなと思います。
理由としては、あまり他のチームの内容みたいなやつを定期的に交流して会話するみたいな場がそこまでないかなと思っているので、
ぜひこの場を借りて伺っていきたいなと思います。
そうですね。
イメージはさっきの一旦自分の考える最強のホゲホゲみたいなのをやるみたいなのが強烈に自分の中には残ってたんで、
一気当選というか、みたいな人たちがいるチームっていう印象がすごいありましたね。
一人一人が能力が高くて、実装は比較的なんでもやれる人たちっていうのが思っているところで、
だからこそ決裁とか会員とか、固く守らなければいけないところになっているチームだというふうに思っていましたね。
次Togo.idの時とかは、僕も多分ちょっと関わるというか、
ウェブ版をリリースするときにちょっとやり取りさせてもらったと思うんですけど、
大概的なパートナーとのやり取りとかもご自身でやられたりとかして、
すごい守備範囲が広いなって思ったりしてました。
ありがとうございます。
そうですね、やっぱり外から見ると、
割と一人一人が自立性を持ってやっているみたいな印象を持たれているだろうなというふうには思いましたね。
結構振り返ってみると、特に去年なんですけど、
結構扱っているものがそんなに三つも四つもあるわけではなくて、
チームとして一内四に個程度メインで集中して取り組むみたいな形を取ることが多かったです。
他に特別な話で言うと、結構OIDCとか先ほども話した3Dセキュアみたいなところは、
割と業界表情みたいなものとか、
割とパブリックなドキュメントみたいなものが割とある世界かなというふうに感じていて、
割とそれらを加味しながらStellarにどう組み込むかみたいな、
そういう部分が割と開発をするときの規模になってくるような感じがしていました。
割と自由度があるように見えつつ、
制約みたいなガードレールみたいなものは結構惹かれやすい開発かなというふうに感じていて、
その中で各々がそれぞれのアイデアを持ってやることで、
比較的ガードレール自体も守られているので、
その中でより良い実装とかより良いアプローチみたいなやつは、
割とそれぞれが開発したとしても、
比較するときの軸みたいなものは割と近い形でできたのかなというふうに感じました。
めっちゃいいですね。
社内だと実装の比較みたいなところで、
すみませんパッと出てこないんですけど、
保守性とか変更容易性とかそういった言葉で定義されているものがあったかなと思うんですけど、
この辺を観点としてやったらレビューしちゃうとか、
そういうのがある程度みんなここは見るよねというのが揃っているみたいなイメージなんですかね。
そうですね。
比較的抑えておきたい部分とか抑えておきたいテーマというのは、
ある程度共通認識を持った上で開発することが多いです。
チームの中で担保しきれない部分とか、
他のチームに依頼することでより強固に守れるようになる部分ってもちろんあるので、
そういったところはQAのチームだったりとか、
あとはセキュリティチームのレビューベースの協力依頼みたいなことをさせていただいて進めることが多いですね。
ありがとうございます。
今日いろいろお話が伺ってきたんですけど、
ぼちぼちいい時間かなと思ってまして、
また次回ぜひいろんな話聞きたいと思っているので、
ゲストに呼ばせてください。
よろしくお願いします。
ありがとうございます。
エンディングです。
10XFMではリスナーさんからのお便りを募集しています。
エピソードの感想や10Xのメンバーに聞いてみたい質問など、
どんなことでも構いません。
番組概要欄にあるお便りフォームからの投稿、
またはXでハッシュタグ10XFMでツイートをお願いいたします。
また10Xでは現在さまざまな職種のメンバーを募集しています。
この10XFMを聞いて10Xに興味を持ったカジュアルに話を聞いてみたいと思われましたら、
こちらも番組概要欄にある採用情報または10Xのホームページのリクルートから応募をお待ちしております。
最後にSpotify、Apple Podcastなどお聞きのPodcastアプリで番組のフォローをお忘れなく、
最新エピソード配信時にお知らせが届いたり、また過去エピソードの再生済み、
未再生が一目で分かるようになり大変便利です。
今日の相手はふたぶーと井口さんでした。
それではまた次回。
