00:00
今回はStellarのプラットフォームへの挑戦というテーマで
プラットフォーム化に向けてどういうことを取り組んでいるかを
チームのリーダーの4人のメンバーに来てもらって話そうと思います
1人ずつ自己紹介をお願いしたいので
まずカズさんからお願いします
現在プラットフォームラウンジというチームでソフトウェアエンジニアとして開発を担当している坂本と申します
ハンドルネームはカズとカズ0620と言うのでやっています
同様にパートナーラウンジチームでPMをしている浦と言います
よろしくお願いします
松田と申します
TENXの中ではグロース&サクセスというディビジョンにいるのですが
パートナーラウンジチームでは主にデータマネジメントの領域で仕事をしています
よろしくお願いします
パートナーラウンジチームの田村です
VizDevとしてパートナーとの窓口に立って
ラウンジまでのサポートをさせていただく役割を担っています
よろしくお願いします
お願いします
4人に6つぐらいトピックを持ってきているので
これについてそれぞれ5つ話を聞いていきたいなと思っています
まずはカズさんに聞きたいなと思っていますが
そもそもこのプラットフォーム化の歴史を簡単に教えてもらってもいいですか
プラットフォーム化と言いつつ
最初の段階では特定のパートナーに紐づいたプログラムが多くて
最初からすごい抽象度高く作るというよりは
今ある分かっている情報から
そのパートナー向けにどう作るかみたいなところから
まず始めたという経緯があります
なのでどのパートナーでも対応できるプラットフォームというよりは
去年の段階では結構特定のパートナーに強く紐づいたプログラムとかが多かった
ですけどそれを複数のパートナーに対してリスしていくという過程の中で
より抽象度高くプラットフォームとして
Staylerにある機能はどのパートナーでも使えるみたいな改修を直近行ってきて
だんだんプラットフォームとしてStaylerが成り立ってきているというのが
今みたいな感じですね
なるほど
特定のパートナーに紐づいていたものを
多分初めの段階は次の会社さんに提供する
パートナーに提供するとなった時のコストを
大体100だとすると
今ってざっくりどのぐらいの割合になってきている感覚ですか?
ものによっては本当に3とか5とかレベルまで減っていると思います
がまだ10とか20とかかかるものもあるかなっていうのはありますけど
既にある機能であればほぼほぼ開発コストはほぼゼロで提供できる
みたいなのがだんだん増えてきてはいるなと思います
それはすごい進化ですね
ありがとうございます
03:00
ちょっとそこに対してシフトしていく時とかに
どういう苦労したかみたいなのも合わせてお願いできますか?
やっぱり最初は僕もキャッチアップできてない時
どの機能がどのパートナーに紐づいた機能なのか
みたいなのが把握できていなくて
StayLineにあるんだから動くかなって思ってみたら
これはなんかもうこのパートナーでしか動かないなみたいなのが結構あって
それをより抽象度高く
例えば今コード上にパートナーごとの設定のファイルみたいなのを
用意しているんですけど
プログラムに直接このパートナーだった動きだみたいに
ハードコーディングされてたのを
その設定の方にステイラーとしてそれはどういう機能なのか
みたいなのを抽象化して設定に持っていくってしました
例えばプログラムの中で
例えば配達があるとしたら
このパートナーの時は配達がありますみたいな
プログラムの特定の箇所に直接書かれているのを
設定ファイルの中で配達っていう機能が
このパートナーがあるかどうかっていうのを
パートナーごとの設定ファイルに定義すると
その通りに動くっていう風に切り離していくみたいなのを
大小いろんな抽象度の機能に対して
行ってきたっていう感じですね
めっちゃ具体的で面白いですね
これ多分開発にどうしていくかっていう反映の前に
そもそもその大量の機能をどのパートナーは何を使うのかみたいな
膨大なもののマネージみたいなのも必要かなと思うんですけど
そこら辺なんか浦さんとかPMとしてはどんな感じで
はじめどんな状態から今どんな状態になっていったのか
みたいなのも合わせて聞いてみたいなと思いました
はい 機能リストみたいなのを
これは僕が作ったっていうか
ヤモトさんが作ってくれたものが実は
社内には存在していて
それを活用する形で
マスターの機能があります
それがどのパートナーにどの機能を提供しているかっていうのが
分かるようになっている状態ですと
そこは機器メンテだったりとか
プラットフォーム自体に機能が追加されたら
それに応じてパートナーのテーブルにも追加されるみたいなものを作っています
それは機能単位の話で
もう少し細かい設定項目とかですかね
いろいろ機能を作ってはいるものの
A社には提供していてB社には提供していない
だとかサービスの形態ですかね
いくら以上の配達で数量をいくらにしますとか
それは内勢なのか外勢なのか
めちゃくちゃ細かい設定が数多く出てくるものを
今は一覧一ページのノーションで
一覧で見れるような状態にはなっています
ただこれが将来的に何か数百社
パートナーを迎え入れた時に機能するかというと
そういうのは多分ありえないので
また別の方向性とかを模索していくことが
必要になってくるかなという気はしています
はいなるほどめっちゃ面白い
これなんかそれぞれ聞いてみようかな
マッツンさんもデータマネジみたいな文脈で言うと
初めの段階から多分初めの方もやられてますもんね
06:01
トライアルの段階で
今にかけてどういう風にマネージの形態変えていったかとか
ちょっとお聞きしてもいいですか
はいデータマネジメントって一言で言っても
ちょっとイメージしづらい部分があると思うので
具体的に言うとですね
ネットスーパーでトマトが買えるよっていうことの裏側には
それぞれの小売り事業者の方が
今日トマトが15個あって
1個128円だよっていうデータがあって
それを私たちのプラットフォームのステイラーに連携するっていうところが
まず必要になってきますと
これだけ聞くと簡単な仕事のように思えるんですけれども
特徴としてはかなり大量のトマトとかキュウリとか
SKUにおいて毎日値段が変わったり
特売とかあると思うんですけど
ああいうのを反映したりですね
毎日在庫が変わったりっていう状況を
作っていかなければならないっていうのが
難しい点としてあると思います
山手寺さんの質問に戻ると
初期の頃どうやっていたかっていうと
結構ですね
我々がサーバーサイドで採用しているDARTのコードの中で
データ連携を表現していたっていう形になっています
これのいいところとしては
サーバーサイドがDARTで抱えているので
結構そことの親和性が高いっていうのがあるものの
デメリットもあってですね
それが例えばですね
データ連携のコードの仕様を変えたりとか
あるいは運用していく中でミスが見つかったときに
なかなかどこが悪さしているかっていうところを
特定するのが難しかったりしたということですね
かつもう一つ大きな課題としては
パートナーが増えていくっていう未来を考えたときに
データ連携のコーディングが
結構各社ごとに最適化されてしまうので
なかなか横展開しづらいっていう課題がありましたと
それを解決するために
私たちはDBTっていう
データパイプラインを作るツールみたいなのを導入しました
これはそもそも何なんだいっていうところなんですけれども
かなりですね
簡単にデータパイプラインが見通しよく作れるっていうもので
中身としてはSQLがかければ
データパイプライン作れますよっていうものになっています
なのでこれによってデータパイプラインっていうものを
既存のコードから結構独立した形で
作ることができるっていうのがすごい強みかなと思っていて
なのでエラーが出る箇所の特定もすごい簡単ですし
回収とかも割と柔軟にできるよっていう風になります
私が入社した頃は去年の8月ぐらいですけれども
そこら辺はまさにDBTを使ってデータパイプラインを作っていくっていう
09:00
言い換えるとデータパイプラインの独立性を
高めていくっていうことに取り組んでいたかなと思いますね
ありがとうございます
タムラさんがアジェンダを全体作ってくれたのを
すごい無視して進めちゃって申し訳ないんですけど
タムラさんのビーズデブみたいな領域でもあるかなと思っていて
そこもいわゆる特定のパートナーに
個別についていた時からプラットフォーム化していくみたいなところで
どういう変化があったか聞いてもいいですか
ありがとうございます
一言で言うと実現したいことの抽象度を
どうやって適切に上げていくのかっていうところに
ビーズデブとしてはコミュニケーションとドキュメンテーションを
気を配ったなっていうのがあります
1年前で特定のパートナーにひも付いた開発を行っていた時っていうのは
我々も裏側のオペレーション
店舗の作業ですとか配達の作業ですとか
それに必要な機能っていうのを
解像度が我々自体が低かったので
本当にディープに入り込んで何が必要なのかっていうのを
すごくつぶさに見ていく
それに達成するために必要なことを丁寧に並べていく
具体にフォーカスしていくという開発をしていたんですけれども
今はいろんなパートナーに対して
汎用的に使えるものを開発していく必要があるので
あるお客様からいただいた内容っていうのが
他のお客様に対して適用可能な形に
実現したいことを1個抽象化して
何を達成したいんだっけっていうのを
もっと鋭敏になって考える必要が出てきたなというのがあります
具体的な話をすると
複数のお客様からステーラーで
法人向けの配送をやりたいというふうに
おっしゃっていただいているお声がありまして
結構細かいところでいうと
決済の手段ですとか
誰が運ぶのかですとか
パートナーによって別々の差別設計をやっているので
そこに最適化しようと思うと個別の開発にはなってくるんですけれども
ステーラーとして法人配送を行うというのは
どういう機能が必要で
ミニマムでいうとどういう決済手段を
口として用意していて
どういうふうに法人の中での注文を仕分けするべきかのような
どのパートナーに対しても必要になるものを
枠としてまずは用意して
それに対して今現状をパートナーさんが
リクエストしている個別の内容を
どういうふうに付加することで
それぞれに対して合うプロダクトを作れるかというのを
考えているというような形にしているので
なのでプラットフォームとして実現したいことを
抽象化してそれに対してギャップを埋め込んでいくという
開発にしているし
VizDevとしてもそのようなコミュニケーションを
パートナーとしているかなというようなイメージです
VizDevとかPMのレイヤーがあって
データと機能とか開発のレイヤーとか
どのレイヤーでも割と個別でやっていたものを
どうやって裾野を広げるかという取り組みを
12:02
結構この1年くらいしてきたというのが
なんとなく伝わったんじゃないかなというふうに思います
もう少しミクロの話に戻すと今って
故に開発のプロセス自体もすごく複雑なものから
ある程度マネージできるような形に
変えていっているかなと思っていて
どのような形でマネージしているかというのを
もう一回カズさん裏さんに聞きたいなと思っています
カズさん今どんな形でマネージしているか
お聞きできますか
今の前に元々の話で言うと
結構このパートナーごとに
タスクを元々管理しようとしていたんですけど
ただ結局
特定のパートナーさんのがいつまでにできる
というのを出すためには
同じリソースで僕らは開発する必要があるので
じゃあ全てのタスクを
直列に並べて管理しないと
結局並列にいろんなものが存在しているけれど
僕らが手を動かせるのは
直列にしか動かせないので
いつ何ができるんだっけというのが
不透明な状態だというのが課題としてありました
それをどうするかというのに
取り組んで今は
僕らのパートナーラウンジっていうチームで
単一の一つのバックログを持っています
そのバックログの中に優先度順に全て
順番をつけて必要なタスクを並べた状態にしています
なので基本的にはやるべきものを
上からこなせばあるべき状態に
たどり着けるというバックログがある状態になっている
かつそのバックログの一日一つの
一周に対して見積もり
ストーリーポイントで見積もりを振っています
この見積もりっていうのは
基本的には相対見積もりで
ある基準となるタスクを例えば3ポイント
そしてそれと比べたら何ポイントですか
みたいなのを全てのタスクに対して見積もっています
全てのやるべきことが優先度順に並んでて
見積もりがある状態なので
このタスクが完了するまでには合計で
何ポイント必要なのかみたいなのが分かっている状態になっている
かつ1週間にどれくらいポイントを
消化したのかっていうのも計測しています
なのでだいたい過去3週間で
どれくらいのポイントが消化できたのか
なのでこれからの2週間3週間でどれくらいのポイントが
消化できるのかっていうのが分かっている状態になっているので
じゃあどれくらいの期間までにやりたい
マイルストーンを達成できるのかっていうのが
分かっている状態になったっていうのが
この半年で取り組んで一番大きく変わったところかなと思っています
めっちゃ健全な匂いがしますね
すごい健全になったんだろうなって
うらさんの観点に付け加えることはありますか
それでいうと僕の場合は各種
15:00
細かいスケジュールの調整とかっていうのはたびたび発生します
具体的な内容でいうと
ビジネスチームが最新のアプリをパートナーに提供して
リリース前の最新のアプリを提供し
研修をしたいとか各種データの繋ぎ込みのテストをしたいみたいなタイミングを
そのバックログ上で先のイテレーションに先に
突っ込んでおくみたいなことをして
この時期にこれが必要ですっていうのを見える化しておく
そういうことをデザインも含めてそういうのをやると
デザイナーさんとかはこのタイミングで開発チームが動くから
その前のタイミングでそのチケットを消化するとか
開発チームとしてもこのタイミングで
ビジネスチームとかパートナーが研修だったり
検証を行うからタイミングでリリースしなきゃいけないとか
分かるような形で先のあんまり大きくはないんですけど
そういったマイルストーンも細かく管理できるようになってきたので
かなり可視化できていていい感じになってるなっていうのはありますね
確かにリズムがちゃんとコミュニケーションできるようになったというか
不透明な状態だと
すいません来週はアプリが出せそうで出せないような
そんな雰囲気がありますみたいなコミュニケーションになりやすいのが
今だいぶ健全なパートナーと内部を一致させていく
みたいなのができてますもんね
確かにありがとうございます
あとこのいわゆるストーリーポイントを見積もって
ベロシティを測っていくっていう取り組みって
結構データを作っていくところにも最近導入されたかなと思ったんですけど
一通さんこれはグロスチーム的にはどんな効果あったとかありますか
はいこれはですねかなり見通しがよくなるっていう効果があるのと
あと意外とですね周りの関係者の方々との認識合わせも
しやすくなったっていうポイントがあります
まず一つ目の見通しがしやすくなったっていうのは
これは一通さんがおっしゃった通りでですね
基本的にはもう上からやっていけばいいみたいな状態に
立ち上げるっていうところがそこまでできれば
かなりやることが単純化されてくるので
今週はここまでやればいいんだみたいなのが
チームの中で作っていってそういう状態になると
かなり安心して仕事に取り組めるかなっていうのが思ったことです
加えてですね周りの人との連携もやりやすくなるっていう点なんですけど
これは今週これをやるんだよリストを作った後に
僕たちは他のチームとこれでいいですかっていう
合意形成を取るっていうことをしているんですけれども
これがやってみるとかなりいいなと思っていまして
特にこのメンバーでいうと田村さんとやっていたりするんですけど
事業側ビズデブ側からすると
今週はここまで進捗したいなっていうものが
結構あると思うんですけれども
それと私たちのチームの認識を揃えることで
会社としてこういう今日はここまで
今週はここまでやればいいんだっていうのが明確になるので
結構そのボールを落とすですとか
ちょっと期限の認識が違うみたいなものは
18:02
未然にある程度防げるようになったかなというのが
大きな収穫ですね
なるほどこれやっぱり田村さんの目線でもそこの変化というか
プロセスが整っていくことで
対パートナーに対する信頼の積み上げ方に対する影響みたいな部分での
実感みたいなのってありますか?
大きな変化があったなと思っていて
パートナーに対してしっかり説明責任を果たしていくっていう意味で言うと
本当に我々としてのプロジェクトマネジメントの確実性というのが
上がったなと思っています
一番最初に聞いたスケジュール通りに
すべて物事がうまくいくのがベストではあるんですけれども
当然不確実性がある中でのプロジェクトを進行しているので
何か起きるというのは当然あるし
それをパートナーに対して話していかなきゃいけないという場合は
絶対にあるんじゃないかなと思っています
その時に我々として今どういう状況で
何週間後に何ができていて
ただこれを外すと何週間も負けるというような
ある程度の現状把握とシミュレーションというのができるようになったことで
パートナーと問題解決ができる幅というのがグッと広がったなと思っています
例えばあるリリースを後ろに倒すのか
それともある開発を優先順位を落としてリリース日に間に合わせるのか
あるいは別の何らかの方法があるのかというような
オプションを根拠をもとにテーブルに並べて
パートナーと本当にフェアに話ができるようになったというのが
本当にコミュニケーション上は信頼環境につながる
大きな一歩なんじゃないかなというふうに思っています
確かにフェアさを獲得する前は苦しかったですもんね
そうですね 0か100かみたいなところがあったかなと思っていて
やらないでそのままリリースか後ろに倒すかといったような形
でもじゃあいつになるかというといつにリリースできるかも難しいですというような形
結構暗中模索感を弊社内でもタイプパートナーという意味でもやっていたと思っているので
その透明性が上がったというのは本当に進めやすくなったんじゃないかなと思います
ありがとうございます
開発のプロセスをどうマネージしたっていうところを話すと
結局全ての人の行動の連動みたいなものが必要になっているというのは
すごくよく感じられるエピソードだなと思いました
プログラムをどういくかというもっと手前側で言うと
プラットフォームとしてどうやって開発の判断をしていくかみたいなところ
ここを田村さんから少し説明いただけますか
ありがとうございます
パートナーと結局何を作るかというのを一番最初の段階で捌くんですけれども
ここで結局Yを今までもやってたんですけれども
どういうことを期待値としてやりたいのかということをベースに
パートナーと要求事項を擦り合わせしていくというのが
21:03
今我々の中ではかなり出来上がっているのかなと思っています
1年前とかですとそもそも我々がステーラーとして
ものが大部分なかったので
皆さんとコミュニケーションベースでこういうことをやった方がいいよね
というのをブレストしていきながらものを開発していったんですけれども
今はプラットフォームという土台があって
要求もドキュメントに落ちていてプロダクトを見せれるものがあるので
まずはパートナーに現地でデモをしに行くんですね
店内の作業のスタッフアプリみたいなのを一緒に見ながら
こういうふうに作業するんですよこういうふうに使うんですよと言って
これを一覧の流れとしてやった時に
まだ足りないものってありますか?ですとか
本社のオペレーションですとか制約条件の中で
追加しないといけないものって何ですか?と
その中で絶対にリリース前にやらなきゃいけないものって何ですか?
ということを並べていくと
かなり本当にやらないといけないエッセンシャルなものに絞って
パートナーの皆様と合意した状態で出来るんじゃないかと
パートナー様にとっても何が必要なのかというのが
理解度がグッと上がると思いますし
プラットフォームとしてもそれっていうのはやっぱり結局
プラットフォームを良くするという観点が必要になってくるので
そういう意味でもすごく必要なものから優先してやっていくっていうのが
出来る措置が仕上がってきたのかなと思っています
ありがとうございます
今デモっていう言葉があったんですけど
うらさん相当な回数の現地に行ってデモを経験していると思うんですけども
その中でギャップをどう抽出していくかみたいなのも
だいぶ整理されてきたのかなと思っていて
この辺りの工夫とかをちょっとお話しいただけますか
そうですね
そもそもデモをやる前に何が起こっていたかみたいなところもあるんですけど
まずStaylerで何が出来るかのドキュメントを頑張って書いていた時期があります
年末ぐらいですかね
それはホワイトペーパーと呼ばれるものなんですけど
もうすぐ消えます
他の部分に吸収合併されていく
より次のステップに行くみたいなことが起こります
ただそれってあくまでドキュメントなので
パートナーの現場で働く方だったり関連する部署の方だったり
ドキュメントを読んでもプロダクトのことを理解できるのとごく一部にしかならないので
実際に触ってもらいましょうみたいなことをやります
それに差し当たって現地に行き
そんなことのアプリを作って現地に行きデモしましょうみたいなところをやります
いろいろ要求はやっぱり出てきます
細かい要求含めて代償様々
具体的に行くとフォントサイズが小さくて現場の人は見えないんじゃないかとか
もちろんそれはおそらく正しい事実であって
ただOSの機能で拡大してもらうとちょっと表示は崩れちゃうけど何とかなりますよねみたいな
運用が止まるかより便利になるかみたいなとこのギリギリを結構攻めるみたいなのが多いです
他で行くと商品をピッキングするスタッフアプリにジャンコードを表示して欲しいという要求が
24:03
今回新しく3社導入するにあたって各社出てきました
要求としては理解できつつ実はその前段階のあるパートナーに出した機能の時にも要求としてはできたんですけど
なくてもなんとかなるみたいな判断だったものが各社出てきた時に
これはさすがに必要なんじゃないかみたいな
あった方がいいが4社ぐらいから出てくるんだったらそれはもうプラットフォームに入れましょうっていうのをやったりとか
そういう判断をしたりしてますね今は
ただ声が多いから本当なのかはもうちょっと様子見ないと分かんないですけど
今はそういう判断軸で動いてます
相当量のインプットの津波みたいなのが来てて
その中で何をマストとしていくのかって判断って
もちろんオペレーション止まるみたいなのはデモやったら分かるから分かりやすいけど
そうでもないんだけど複数の会社から来てるっていうのも
多分その都度実装のコストとかを考えていくとやっぱマストでプラットフォームに入れてった方がいいんじゃないかみたいな
そういう難しい判断をし続けてるってことですよね
そうですねやってます
ありがとうございます
ちょっとなんかこれでだいぶ総合格闘技感伝わってきたかなと思うんですけど
ちょっと最後ここからどういうふうにさらに進化させていくか
個別のパートナーにくっついてたのがバージョンゼロで
今プラットフォームかバージョン1みたいなのを言うと
V2はどこを目指してるのかみたいなのをちょっと各自の視点で語ってもらいたいなと思って
カズさんからちょっとお願いできますか
はいそうですね2つあると思っていて開発的には
まず1つはさっきこれまで話したように
Stayler共通の機能として取り込むべきものだけどまだないものっていうのがあるので
それを抽象化してStaylerに設定とかを変えればすぐに動くようになりますよっていうのを増やして
マスターなものを対応していくって方向性が1つ
もう1個は逆にこれは明らかに共通化できないなっていうものをうまく取り込めるようにしていく
例えばパートナーごとにポイントの計算とかって違っていて
それを僕らがこの計算式でやってくれって押し付けることっておそらくできないんですね
みたいにあらゆるパートナーから上がってくるんだけど
完全に同じ仕様としては共通化できないものっていうのをどう扱うかっていうのを考える必要があります
そのために今考えているのはプログラムでいうと
特定のインターフェイスに沿った実装すれば対応できるようになるっていう状態にするのが次の目標かなって思っています
もう少しわかりやすく言うとプラグインみたいな形で
この規格に沿ったポイントの計算ロジックを作れば簡単にStaylerに取り込むことができますよっていう状態にする
っていう風に同じ振る舞いをするものを共通化するっていうのと
27:03
同じ振る舞いにはできないものをプラグインとかみたいにインターフェイスに切り出して
簡単に取り込めるようにするっていう二軸を両方同時にやっていくっていうのが
次のバージョン2みたいな感じなのかなと思っています
ありがとうございます
自分たちのコスト、開発していくコストが下がるってのもそうだし
先方が何かを表現したい時にそのAPIにインターフェイスに沿ってやれば
先方で完結できるっていう世界線ですよね
そうですね、最終的にはそこまでたどり着けるといいなっていう
それはもうバージョン3かもしれない
なるほど、ありがとうございます
じゃあまず小刻みなV2を挟んでいきましょうというところですね
ちょっとデータマネジメントのところで松野さんいかがですか
バージョン2というか目指すべきところっていうと
複数のパートナー様がローンチしようとしても
それを受け切れるための体制を作るっていうことが目指したいところだと思うんですけど
これに対応するにはこちら側の効率を上げるか
あるいはリソースを増やすかみたいなところがあるかなと思っています
両方僕たちはやっていくといいかなと思っていて
まず効率を良くするっていう点でいうと武器は2つあると思っていて
それは今作っているのはデータマネジメントのアーキテクチャを
よりすっきり効率的なものにしていくっていうことでして
究極系でいうと結構カズさんのイメージに近いんですけれども
ボタンポチで基本的なデータパイプラインのアーキテクチャができるとか
テンプレをコピペすれば大体できるみたいなところですね
そこは正直結構難しいんですけれども
ちょっとやれるとこまでやってみようかなと思っていて
ここ半年ぐらいで試行錯誤をしていきたいなと思っているところですね
もう一つの武器としてはチームの運営っていうのがかなり大きいなと思っています
これはリソースを確保するってところにも大きく絡んでくるんですけれども
基本的にデータマネジメントのチームはですね
かなり業務委託の方々と協力し合ってやっています
というのもそれぞれの小売り事業者様のデータっていうのは
皆様のご想像の通りかなり個別性が高いですし
スーパーなのかドラッグストアなのかによってだいぶ違ったりするんですよね
これを一人の人が全部やるっていうのは無理なので
並列化するために業務委託の方々と一緒に仕事をしています
彼らとどういうふうに効率的にやりとりができるのかっていうところで
スクラム開発を導入していて今試していたりしていて
そういったところも今よりもさらにスムーズにできるんじゃないかなって思うところもあるので
そういう点でやっていくというところですね
30:01
なのでまとめると効率とリソースを拡充するっていうのがやるべきことかなと思っていて
それはアーキテクチャを整えていったりとかチームを整えていったりするっていうところで対応しようとしている
というところになります
ありがとうございます
田村さんの目線で全体のプロセスとか体制とかかな
そのあたりを今検討してもらっていると思うのでそのあたりをご紹介いただけますか
はいありがとうございます
私の方から組織という観点と業務プロセスという観点を2つで簡単にお話しできればと思っています
パートナーロンジチームは今後今よりももっとたくさんのパートナーに対して
効率的に安定して同じぐらいの品質で事業を立ち上げるということを目指していきたいなと思っている中で
今より例えば今の2倍3倍のパートナーを同時に抱えるってなったら
今の体制って破綻してしまいますというのがあって
どういう風に進めていくのがいいかなというのを検討している中で
ある種クロスファンクショナルなチームっていうのを
いくつか抑えていく必要があるんじゃないかなと思っています
何を言っているかというと
大体のパートナーの皆様は市販機に1回ぐらいリリースを迎えるタイミングというので
区分けすることができて
例えば来年の1月から3月に3社パートナーがローンチしますとなると
その3社を1つのチームとして
イズベルやプロダクトマネージャーやクロスチーム
開発チームがチームとして組成される
そうすると同じぐらいのタイミングで動くプロジェクトというのは
同じタイミングでデモを実施してギャップを抽出して
要件を定義して開発をしてリリースするというような流れになるので
そういったような形で括っていった方が効率的なのかなというので
そのような体制を今組もうとしています
業務プロセスという意味でいうと
徹底的に何をやればいいのかというのが
パートナーにも社内の文脈を知らない人にもすぐに理解できるような
そのキャッチアップのドキュメントというのを型として作っています
例えばパートナーに対してプロジェクトボードという
プロジェクトを立ち上がった時に出すドキュメント一覧というのを今用意していて
これをデータとしては用意してください
これを議論しなきゃいけないですよというのが50個ずつあって
その50個を全部クリアしたらもうリリースできますよというのが
もうなんか見れば誰でも分かるみたいな状態です
そうするとパートナーが何をやればいいかも分かりますし
我々のVizDevで例えば入社したての方にオンボードしていただくってなった時も
何をやればいいかというのがすごくクリアになるので
良いのかなと思っています
そういったような形でスケーラビリティを確保していきたいなという風に考えています
ありがとうございます
うらさんに最後ツールとかプロセスとか
開発っていう観点とか
あとはそこのVizと開発を間に入って
繋いでいくっていう観点で
どういう進化をしていこうかみたいなところを最後に伺えればなと思います
はい
田村さんが言ってくれたことの繰り返しになる部分はかなり多いんですけど
33:01
今だと一桁社が我々のパートナーとしていますけど
将来的に100社とか迎え入れられるんだっけみたいなところを最近は見越していて
そうなるとコミュニケーションの量って今
それぞれが打ち返しているものって
もうそれじゃなりたくなくなるよねっていうのがあるので
ちゃんとFAQを作ろっかみたいな
当たり前のことは当たり前にやるって言っちゃうとそうなんですけど
プラットフォーム化していくっていうところを進めています
プロセス等々に関しても
PMの属性ってこの間Kさんが
オープンオフィスかなって発表してくれた通りで
機能を作るようなPMもいれば
プラットフォームをよりブラッシュアップしていくPM
両方必要かなと思っていて
この開発プロセスにおいては
パートナーからのギャップに対しては
機能を作っていくPMがアサインされて
そのプロセス自体をよりブラッシュアップしていく
プラットフォーム型のPMみたいな
そういう属性に応じてアサインができるとより
スケーラブルな体制とかを作っていけるのかなっていう気は最近してますね
なるほど PM言うても結構いろんな強みとか型が発生してきそうだなって感じですね
そうですね
でもそんなとこですかね
量をこなせる仕組みとプロセスを作っていきたいというところですね
確かにありがとうございます
というのでぼんやりとV2の姿が見えてきて
ただこれはできているものではないので
これから作っていくっていうところで
仲間を募集しているっていう話と
あとV10くらいには
きっとVisDevの人がZoomでパートナーと会話してやら
チェックリストなどバーっと埋めていって
それボタンポチッと押したら
ダートのコンフィグにバカッと書かれて
アプリがなんかシュッとディストリビューションされていって
パートナーの方は次の日もデモができるみたいな
各支店にいる弊社のメンバーが
そのパートナーのところに
例えば栃木だったら栃木支店の人間がいて
デモをサポートして
その翌日にはギャップが洗い出されているみたいな
それが多分バージョン10くらいですよね
10かな100かな
そのくらいを目指せるといいなっていう
もっと早い方がいいんじゃないですか
5くらいかな確かに
このくらいのリソーズを目指して
今動いてくれていると思うので
ちょっと引き続きやっていきたいなっていうのと
最後に3月の末頃に
パートナーのチームの詳細を話すようなイベントを
企画しようと思っているので
決まり次第一緒に周知できればなと思っています
今日話できてない内容とかQA
裏話みたいなところも含めて
いろいろとお話できればなと思うので
ぜひ
ありがとうございました
ということで今日は4人に来てもらって
パートナーのチームについて話してもらいました
ありがとうございました
ありがとうございました
ありがとうございました
ありがとうございました
[音楽]
