00:00
皆さんこんにちは、株式会社10X執行役員のえなみです。 この10Xfmは、高力MKCプラットフォームStellarを中心としたプロダクトを手掛ける10Xのメンバーが
キャリアや事業への思いなどを包み隠さず、リアルにお届けしていくポッドキャスト番組です。 今回は、橋原えなみの小声ラジオ第11弾として、10X執行役員の2人が10XやStellarの魅力
キャリアや仕事観など様々なトピックについて ザックバラにお話ししたいと思います。
はい、橋原さん。11回目の収録がやってまいりました。
毎月1回撮ってますけど、もうすぐ1年だなぁっていうのをさっき話してましたけど、ちゃんと続けられて良かったです。良かったですって。過去形ですけど。
計画的にやっているというかは、今日も朝橋原さんから、やばい今日、ポッドキャストの収録だっていうDMが来て、2人でわちゃわちゃするっていうね。
割と行き当たりばったりな感じではありますが、今日もちょっとお話ししていければなと思います。
今日何を話そうかというと、子社制とプラットフォームっていう。前回が野球の話とかあったんで、まただいぶ仕事の方に戻ってきましたが、
ちょっと子社制とプラットフォームというトピックで1本収録できればなというふうに思っています。
今、TenXでは大体月に1回ぐらい、経営人から全社ミーティングで話をするっていうコーナーがあって、
先月かな、自分のパートだったときに、この子社制とプラットフォームって話をさせてもらったんで、
ちょっとその話を膨らませながら、橋原さんと議論だったりとか意見交換だったりとか、そういったことができればなと思っています。
どこから話そうかと思うんですけど、この子社制とプラットフォームって、TenX、ステイラーとしてはもうずっと何年も向き合い続けているトピックで、
今さらかよっていう話ではあるんですけど、ちょっと最近もこれについて考えさせられる出来事っていうのがあったので、
社内向けに話したし、ちょっと橋原さんとも話してみたいなと思ったという感じですね。
前提として、ステイラーがプラットフォームっていうことをすごく強く意識しだしたのが、
2023年の夏頃だったかなと思っていて、結構社内でプラットフォーム指針っていう指針を周知したりとか、
あとは保守性に投資をしていくっていう意思決定をして、結構これまで機能開発に比重を置いていた開発のスタイルから、
一時的に保守性に投資するっていうことで、結構ダイナミックに新規の機能開発っていうのをストップして、
保守性の向上に取り組んだっていうような過去がありましたと。
その保守性に取り組むっていう中で、個社性、個社の使用とプラットフォームとしての標準機能っていうところをどういうふうに線引きをするかとか、
03:05
その個社性っていうものにどう向き合うかとか、もしくはその個社性っていうものをどういうふうに解消していくかとか、
そんなようなことを考え始めたのが2013年の夏頃で、大体そこから3年弱くらい経過して今っていう感じですかね。
そこで自分が改めてこの個社性とプラットフォームっていう話を前者にさせてもらったのは、
その個社性っていうのをうまく扱えていない。
もしくはその個社性とプラットフォームの線引きっていうのがうまくできていないやっていう機能というか事象を発見したので、
このタイミングで改めてこの話を持ち出したっていうところでした。
あんまり具体に踏み込んでもあれなんですけども、ちょっとサマリーを話すと法令要件が強く絡むような機能、
仕様というものがあって、ただその法令要件に対して当時我々はあまり詳しくなかった。
パートナー側がすごくそこに対して強い関心を持っていたり、深い知識を持っている中で、
そこから受けた要求っていうのをストレートに飲んでしまって、それを機能化したと。
さらにそれを個社の仕様から標準的な機能に格上げするときに、どこに個別性があって、
どこをプラットフォームとして扱うべきかっていう検討とかをあまりうまくできないまま、
それがスルッとそのまま標準的な仕様、プラットフォームに乗ってしまい、
それがずっとここまである種放置されてきたみたいな、そういう事象がありましたと。
それ自体が大きな問題というよりは、それ自体も問題ではあるんですけど、
そこから個社性とプラットフォームっていうのをどういうふうに扱うべきかとか、
なぜそもそもこういう事象が起きてしまったのかっていうのを自分なりに振り返って、
今後に生かしていこうっていう発信を社内にさせてもらったっていう、そういうことがあって、
この個社性をなぜうまく扱えなかったのかとか、なぜプラットフォームに個社性が
強く入り込んでしまったのかっていうところを自分なりに端的に整理をしてみると、
3つぐらいのポイントがあったかなというふうに思っていて、
1個が先ほど言った個社に対応したのっていうのを標準化していくっていう過程で、
その背景にあった法令要件をきちんと自分たちなりに整理したり解釈したり、
もしくはそれから導き出されていた個社の仕様っていうのを精査する必要があって、
結構ストレートにいってしまったっていうところだったり、
パートナーから受けた個社の要求のうち、ここが個社固有の要求で、
これはプラットフォームとして標準的に必要なものだっていうことを線引きしたり、
整理できるほどにその法令要件とかその周辺のことっていうのを理解できている人が、
06:04
当時やっぱり社内にあまりいなかった。
3点目がそのパートナーの要求とか期待に応えるっていうモチベーションを持っている人が、
唯一その法令要件に精通をしていたので、結構その機能の標準化をするっていうことを考えるときに、
どうしてもそのパートナーの要求とか期待に応えるっていうモチベーションが混ざってきて、
あまりそこを丁寧にっていうかきれいに線引きするっていう流れにならなかったっていう、
この3つくらいが噛み合わさった結果、この状況。
つまり、個社の要求っていうのがぬるっとプラットフォームに混ざってしまい、
それがここまで放置されてきたっていう、そういう状況を生じさせたかなっていうふうに思っていて、
ここっていうのをしっかり我々としては反省もしたいし、
次、今後に活かしていかなきゃいけないなっていう、そういう学びを得たっていう、そんな話でした。
これ、私も前者ミーティングでエラビさんが話しているようなのを聞かせてもらったわけですけど、
とはいえ、今その機能自体は、個社性はあれど動いているっていう状態だと思うんですけど、
そこが課題であるっていうふうに認識したのって、どういうプロセスで、
これは個社性があって、そのプラットフォームの標準としてはちょっと逸脱をしていて、
過去のプロセス含めて見直しが必要だっていう課題を見つけるタイミングってどういう形だったんですか。
そうですね。その周辺に新しい機能を追加するとか、
その周辺に新しい改善を加えていかなきゃいけないっていうシチュエーションになったことがきっかけでした。
これまで放置されていたっていうことからも分かるとおり、
我々としてはあんまりその周辺に対して手を加えるっていうことをしてこなかったので、
あんまり正直、課題を課題と認識するタイミングがなかったっていう感じなんですけども、
やっぱりそこをより改善を加えていく、その周辺に新しい機能を加えていくってなったときに、
じゃあ現状を改めて見てみようってなったときに、あれこれはどういうことかなとか、
なぜこうなっているのかに対して、社内で誰も答えを持っていないみたいな。
過去の経緯を掘っていくと、さっき言ったようなことになっていて、
別にその1個自体がものすごく大きな課題かというと、
それ自体は別に正直そのままにしておいても、さほど大きな問題ではないかもしれないが、
やっぱり抽象度を上げて考えると、こういう事象が起きる状態とか、
もしくは法令用件周りに法令としてのアップデートがあったときに、
我々あんまりそこにうまく追従できない可能性があるみたいな、
そういうのに課題感を覚えて、このタイミングで課題としてレイズさせてもらったっていう形。
今のお話でいくと、スコープが広がったタイミングで気づけたっていうのが多分今回のケースだと思うんですけど、
09:09
過去にそのスコープの広さでその問題に取り組むべきだったのかって考えると、
それも当時に振り返っても多分違う、狭いスコープで解いた方がいいよねっていう話にはなりそうな気はしていて、
スコープの広さの問題なのか、あるいは固者性として扱うべきなのか、
プラットフォームとして取り組むべきなのかっていうのは別の問題なのかっていうと、
どういう認識にあるっていう感じなんですか?
そうですね。スコープの広い狭いはあんまり関係ないかなっていうふうに思っていて、
やっぱり要はその機能を使うパートナーとかが本当に一社から始まって、ステップなんですね。
もともと一社からの要求に応えたっていうのが始まりで、
この時点では我々としてもそのパートナーの課題とか要求に応えることを目的としていたので、
そこの一社の強い課題とか要求に向き合ってそれに応えたこと自体は何も問題ないと思う。
このスコープが広いか狭いかっていうのはあんまり関係ない。
今回というと結構狭いスコープに答えたんですけど、それ自体は問題なくて、
この次にその機能を一社の利用から三社くらいの利用に広げるっていうタイミングがあって、
そこでこのもともと個社から始まった機能っていうのを標準機能化しようっていうタイミングがあったんですよね。
本来だったらそのタイミングで、もともと今あるこの機能のうちどの部分が標準的に必要なもので、
どこが個社のものっていうふうに切り分けられるかっていうのを考えなきゃいけなかったと思うんですけど、
そこがそういうふうにできず、ぬるっとそのまま標準機能にしてしまったっていう、
個人的にはこの1から2、3に広がるタイミングっていうところが1個ポイントだったかなというふうに思ってます。
スコープの広さというよりかは複数社が共通して使えるものなのかどうかみたいなの方が
視点としては重要で、そういう視点を持った上で、
それをその機能が個社に依存したものなのか標準的に使えるものなのかっていうところを
切り分ける観点になるっていう、そんな感じなんですかね。
そうですね。ちょっとここ結構大事なので、ちょっとあえて突っ込ませていただきたいんですけど、
使えるかどうかっていう観点ではないと思ってて、
今のものを別に使えるは使えるんですけど、
やっぱりそういうふうに使ってもらうべきかどうかとか、
12:03
そこまでの細かいシチュエーションにプラットフォームとして対応するべきかっていうスタンスが結構大事かなと思っていて、
そこに選挙できないまま、まるっと標準機能としてしまったことで、
本来プラットフォームとして抱える必要がない機能を抱えているとか、
プラットフォームとしては本来受領する必要のないデータをパートナーから受領しなきゃいけないみたいな、
そういう状態になってしまっているっていうのが結構課題の部分かなと思ってるんで、
当然そのデータ受領できれば他のパートナーも使えますっていうのは使ってはするんですけど、
そもそもそういうふうに使うべきなのかどうかとか、
プラットフォームとしてそこに応えるべきなのかどうかっていうのがより重要なポイントかなというふうに。
僕自身はもともと前職も事業会社で働いてきていて、今はビズレ部として働いているので、
どちらかというと個別の要求を受けたり、そもそも個別の要求の出し手だった時期も長かったんですけど、
そういう個別と標準みたいなところの切り分けて、
僕はあんまり能力として備わってないような気はしているんですけど、
えなみさんはその辺の分けるっていうところはどうやって身につけてきたのかみたいなところとか、
どういうふうに自分にはできなさそうだなっていう話聞きながら思っていたので、
その辺どうやってるんだろうなみたいなのを聞いてみたいなっていうすごくな質問なんですけど。
そうですね。それで言うとまず自分も決して100%ものすごくうまく扱えているかというと、
まだまだな部分もあるという前提で、ただ自分が割とそういう視点を持っていたりとか、
今のところうまく扱えているケースもあるっていうのが何から来てるだろうっていうのを考えてみると、
2つあるかなと思っています。1個が、これ今はもうそういう体制になっていないんですけども、
もともと自分が入社したとき、入社してから1年とか1年半ぐらいですかね、
プロダクトマネージャーもVisDevと一緒にパートナーに対峙するっていう体制を取っていて、
特に自分はVisDevの方と本当に毎週パートナーと対峙しながら、
そのパートナーの課題を吸い上げたりとか、現場にもかなり行かせてもらって、
そのパートナーが要求してきていることっていうのが、
実際どういう現場の課題から来ているものなのかとかっていうのを、
かなり深く見させてもらったかなと思っています。
つまりその個社の課題というものにかなり向き合ったり理解することができたっていうのが1つ。
このままいくと当然どんどん個社の要求に応えるっていう側になっていってしまうんですけど、
15:03
そこから先ほどお伝えしたようにプラットフォームっていう意識が高まって、
自分自身もパートナーに深く入るっていうところから少しずつ後ろに下がっていったっていう関わり方の変化があったのと、
そのために自分、かなり他のパートナーから上がってくる課題とかも結構くまなく見ている。
当然全てのパートナーの現場に行って深く見るみたいなことはできずとも、
やっぱりその上がってきた要求とか課題の背後にある事情とかが何なのかとか、
その辺っていうのはそのパートナーとのやりとりを追ったりとか、
もしくは担当のビジネスティブに聞いたりすることで、
結構それぞれのパートナーがどういう要求をしてきていて、背後にどういう課題があって、
その課題っていうのは他のパートナーで言っているこの課題と一緒だなとか、
そもそも要求自体っていうのが被っているなみたいな、
そういうのが一者を深く理解することと、幅広くその要求とか課題に目を向けるっていうことを、
2つ結構意識的に強くできたことで、その辺の勘どころというか、
どこまでが個者としての強い要求、課題で、
どの辺りからこれがフラットフォームとして共通的に扱うべきものなのかっていう、
肌感とかが自分の中に備わってきているみたいなところがあるかなと思います。
なので、一者に深く入るとより具体的なところが見えてくるかもしれないが、
そこに張り付いてしまうと、その個者の要求に対して結構引っ張られてしまったものを作ってしまう可能性があるけれども、
もう少し独立して引いてみたときにそれを標準化して、
複数のパートナーからの要求として吸い上げたときに、
じゃあどうフラットフォームとしてそれを実装すればいいのかっていう形で、
一歩引いてみて考えることによって、
個者性なのか標準として扱うべきなのかっていうのをジャッジされていると。
なので、近づいたほうがいい、より現場に行ったほうがいいっていうのもありつつ、
行き過ぎると今度引っ張られるみたいなののトレードオフがあるので、
そこのバランスをうまく取りながら、
プラットフォームとしてどう解くべきかっていうのを考えているっていう、そういう感じなんですかね。
そうですね。まさにそうだと思いますし、
あとはやっぱりそういう個者性とプラットフォームっていうものをうまく切り分けられなかった結果として、
やっぱり自分自身がたくさん困っている、品質の部分もそうですし、
18:02
何か新しいことをやりたいってなったときに、
いろいろ整理をしていくと整合しないみたいな場面に何度も向き合ったりしたことで、
その課題とか要求っていうのをどのように取り扱うかが、
結構未来の自分たちを楽にするか首を絞めるかっていうのが結構経験として備わってきているので、
その辺にかなり敏感というか、結構細かい指摘とかフィードバック、ビジネス側にさせてもらうことも多いと思うんですけど、
それはやっぱりそういうところから来ているかなと思いますね。
一回、痛い目に会わないといけないっていうのがあるのかもしれない。
その経験なしに、この要求は個別性だから、そのまま要求を受け入れずに、
ちゃんとプッシュバックしなきゃいけないみたいな、プッシュバックって返すのもコストかかるじゃないですか、
コミュニケーション重たいこともあるし、交渉もしなきゃいけない話があるので、
でもそれを判断するっていうのは、それ以上にデメリットがあるっていうことをやっぱり理解する必要があって、
そのデメリットの理解っていうのは、一回やっぱり痛い目に会って、
あまりにも個別を受け入れて複雑性が彼に上がってしまって、
それが将来の不細につながったっていう経験があるからこそ、そこに対して向き合って投資できるみたいなのがあるんだろうなと思うので、
一回やっぱり人は失敗して学ぶっていうことをしなきゃいけないんだろうなっていうのは、今話してても結局そうなんだろうなっていう気はしましたね。
それでいうと、柱さん最近個人開発されてるアプリとかで、そういう個別性と向き合うシチュエーションとかってあったりされるんですか?
ありありで、ユーザーが増えてきていろんな問い合わせっていうか、こういう機能が欲しいみたいなのを要望として個人開発のアプリでも受けるようになっていて、
すげえ細かい、その機能みんな使わないだろうみたいなのをお願いされることがあって、
でもそれ確実に受け入れると将来不採になるだろうなっていう、滅多に使わない機能だろうなっていうふうには思うところがあって、
それをプッシュバックっていうか、いやんわりお断りするみたいなことを今週末やっているんですけど、
その経験を通じると、僕はどちらかというと要求を出す側にはいるんですけれども、実際作る側のお気持ちみたいなのもかなり理解できてきたなっていうふうには思っているので、
21:01
いかに将来の不採を残さずに、より自分の場合は野球のアプリですけれども、今やっている事業だとネットスーパーのプラットフォームが長期で高い価値を出せるのかっていう視点で問題を解いていくってことはめちゃくちゃ大事だよなっていうのは、
個人開発の経験を踏まえても、完全にアグリーだなっていうふうには思いますという感じですね。
自分は全く野球には興味がないので、橋原さんのアプリそのものから恩恵を受けることは全くないと思うんですけども、そのアプリ開発の経験を通じた橋原さんの価値観とか感覚っていうところで、間接的に大きい恩恵を受けられそうなので、これからも野球アプリの開発を頑張ってほしいなと思いました。
野球アプリの開発は本当に開発側の気持ちにすごい向き合いさと思っているので、いい経験をしたなっていうふうには思うんですけど、だんだんと本当に機能を作るよりもバグ直したりとかする時間のほうが増えてきているので、だんだん楽しくなくなってきているっていうのは正直あったりするので、これどうしようかなみたいな感じにはアプリ自体は成長していってるんでいいことなんですけど、
だんだん責任が増えていって、趣味でやってたのになんかちょっと違うなみたいな感じになりつつあるっていうのが最近っていう感じですね。仕事にはすごい生きているっていう感じはします。
頑張ってください。今結構プラットフォームを作るとか運営する立場の側から話をさせてもらったんですけど、一方で個別のパートナーに対していて、個別のパートナーの事業をサポートするとか事業を成長させるとか、課題を解消しなきゃいけないっていう、いわゆる我々で言うとビジネスデブの立場の方からすると、
やっぱり個別の課題、個別の要求を挙げても、それが基本的にはそのまま受け入れられることってほとんどなくて、プラットフォームとしてっていう話に変換されたりとか、個別の要求自体はリジェクトされることが多いみたいな、そういうシチュエーションがあると思うんですけども、
やっぱりそこのもどかしさとか、ある種不満みたいなものとか、そういう感情とビジネス本部の方々っていうのはどういうふうに向き合っているんですか?
もどかしさは日々あると思っていて、具体的に例えば自分のケースでいくと、もともと医師やってたっていうのもあるので、こういう機能はあったほうがいいよねみたいなのは、感覚が既にあるものが、全職でやってて実際効果がありそうだよなみたいなのが例えばあって、
24:05
それもパートナーからこういう課題があるので解いてほしいみたいな依頼があったときに、自分の過去の経験を参照しても、それは早くあったほうがいいよねみたいなことがあるケースがあると。
とはいえ、まだその対応しようとしたときに、我々としてその一社から上がってきているケースをすぐに解くべきかどうかっていうのは、もう少し他のパートナーのシチュエーションも考慮しながら考える必要があるっていうのは普通によく出くわすケースではあるので、
個人的にはそれ賛成ですって言いつつも、とはいえ我々のコンディションだったり優先順位に応じて、今解くべき問題ではないですっていう回答をするシチュエーションっていうのはあるので、そこはもどかしさみたいなのは当然としてパートナーと対峙している中ではあるかなっていうふうには思ってますと。
一方で、最終的に我々が提供しているその価値を最大化しようとしてきたときには、やっぱり解く順番っていうのはとても大事だなっていうふうにも思っているし、その解き方そのものが将来の我々の開発コストに響いてくる。
その開発コストが上がってしまうこと自体は将来的にはそのパートナーに対して請求せざるを得ない話にはなってくるだろう。我々がうまくニーズを抽象化せずに解いてしまったがゆえに不採用を抱えてしまったコストっていうのは最終的にはパートナーに転化されるものになってしまうだろうなっていうふうには思ってはいるので、
長期的に考えたときには正しく解いて、自社で開発するよりもプラットフォームを使っている方が費用対効果がいいですよねっていう状態を作らないと、我々がプラットフォームである価値っていうのはあまりないだろうなっていうふうには思ってはいるので、
そこのトレードオフを意識しながら、短期的にはその要求に応えたいなっていうふうには思いつつも、長期的にどういう価値を提供できるのかっていうところに視点を持って自分を納得させながらやってるっていうところは少しあるかなっていう感じがしますね。
なので、より時間軸を短くしてみると、多分よりその個別の要求とか課題に向き合って、早くその課題を解いて前に進んでいったほうが良いっていうふうになりやすい。それは当然そうですよね。課題を早く解けるようにしたことはないんで、やっぱり見てる時間軸みたいなところは1個ポイントになるだろうなというふうには思いますね。
過去の収録会でも話してきているが、多分自分も橋原さんも長くやるって決めていてっていう、そこの時間軸の一致があるので、少なくともこの本部長官というか、自分と橋原さんの間では細かい部分では100%の満足はないかもしれないが、
27:23
やっぱり目線価値観があった中で、長く取り組むにはこういう順序、こういう優先順序でやるべきであるっていうところがすり合ってるっていうのがある程度平和にやれている理由ですかね。
あとさっき失敗を通じて学びましたみたいな話あったと思うんですけど、そういえば自分も過去、全職も含めて、主に全職ですけど、いっぱい要求出して不採を作ってしまった側にもいたっていう経験があって、スピードを優先して開発をして、
その時点ではいい結果は出たかもしれないけど、それって後々不採になって、その後の開発のスピードをめちゃくちゃ寄存するみたいな経験失敗も実際はあるので、それも含めて一定の時間軸で考えたときにベストな選択をしたいなっていうのは、
もともと自分も失敗から確かに学んで、そのオプションを取ってるなっていうのはあったので、経験からきて今の短期すぎる目の前のオプションを取るのではなくて、もう少し中長期で見たときにベストな選択を取りたいって思ってるのは、そういう失敗の経験もあるなっていうふうには今話してて思い出しましたみたいな感じですけど、ありそうですね。
あとはやっぱり、作っているプラットフォーム、運営しているプラットフォームの性質とか、抱えている責任みたいなところもかなりそういう方針に大きく影響するかなというふうに思っていて、やっぱり我々ってパートナー様の事業運営そのものを預かるプラットフォームであるっていうのは結構無視できない要素かなと思って、
これがそもそも自社で運営するECみたいな話だったりとか、プラットフォームであっても別に事業運営のど真ん中じゃない、横にあるような業務をまとめるようなプラットフォームとかであればまた事情も違うと思うんですけど、やっぱり我々のプラットフォームを通じてできることっていうのがパートナーが事業としてできることだし、
我々のプラットフォームを通じてできなくなったことっていうのはパートナーが事業としてできなくなることでもあるので、結構中途半端にやってはみるがダメなら撤退するみたいな、そういう意思決定とかも結構性質としてはしにくいものかなというふうに思っているので、余計に不細に対して敏感になるとか、得るべき課題の抽象化っていうところにすごく神経質になるっていうのは、
30:05
やっぱり運営しているものの性質とか抱えている責任によって濃淡つくような、我々はそれはかなり色濃く出るタイプのプラットフォーム事業を運営しているがゆえ、そうなっているなっていうのもきちんと認識する必要があるかなというふうに思います。
難しいという言葉ではちょっとないんですけど、一定の事業という領域そのものを扱っているがゆえの難易度みたいなのはやっぱりあるなとは思ってはいて、それがゆえに解き方を間違えると結構広範囲に影響があるし、
それをちゃんと解くことによって長期的には費用対効果の合う良いプロダクト、プラットフォームにできるっていうのが、特にネットスーパー事業に関しては言えることだなっていうふうには思うので、
この手の話をパートナー様にもたくさん理解してほしいなという気持ちもありつつ、とはいえ、それは我々が早く価値を提供できることには越したことはないので、正しく解きながらも実現したいことを早く実現していくことも同時に、
やれるようにはやっていきたいかなという気はしますね。
あと、時間もそろそろでありますけど、せっかくの機会なのでちょっと聞いてみたいなと思ったのが、かねてから自分は強調特権制っていう話をよくしてきていて、ただこの子社制とプラットフォームみたいな話でいくと、
強調特権制が半々かと言われると、結構立場もあって8割くらい権制になるっていうことがどうしても多くなってるかなっていうふうに自覚はしてるんですけど、権制ばっかりしてると結構ビジネスフォームからすると、なんだあいつみたいな、また権制かよみたいな。
そう思われても仕方がないかなって思ったりとか、課題とか要求を上げにくくなるみたいなふうになると、個人的には嫌だなと思ってはいつつ、権制ばっかりされてるとそうなってもおかしくないよなっていうような課題感というか、不安みたいなところも多少あったりもするんですけど、その辺ってどう映ってるんですかね。公開説教してもらってもいいんですけど。
正直に話しますね。えなみさんが別の会社の人で、違うKPIを見ていて、違うことにアラインしている人と僕がもしえなみさんと話して、権制された場合には同じ方向向いてくれよみたいな気持ちを強く持つかもしれないんですけど、同じ会社にいて同じことを目指している中で、権制しているえなみさんが今いるなっていう感じの認知をしているんですよね。
33:27
なので、そこって同じ方向向いてるけど、異なる意見、異なる意見というか異なる角度で今意見を言ってくれているっていうふうに受け取っているので、別にあんまりそこに対してアレルギーはほぼないっていう感じなんですよ。
今、えなみさん、権制モードだなっていうふうには見えてはいるんですけど、時々あるんですけど、それって方向性は同じ方向に向いていて、異なる視点で、ビジネス本部と異なる視点を持っていて、そこで意見を発している状態っていうふうに見えてはいるので、そこに対してアレルギーとかはほぼないっていうのは正直なところで、
これはもし異なることにアラインしている人のすごい権制が入ってくると、いやいやいやみたいな、これ他のところではそういうケースもありるかもしれないですけど、そういう話では全然ないので、別にえなみさんに対しておいっていうふうに思っていることはほぼないっていう、僕の見え方ですね。
どこまで本音だったかわかんないけど、橋原さんからお墨付きをもらったということで、これからも適切に権制していければなと思うし、決して強調の気持ちも忘れてないっていうのもあるし、多分自分説明は厚く知っているはずだし、強調すべき点では強調しているつもりでもあるので、ここは難しいですよね。
なんか変な嫌われたくないみたいな感情が働いて意思決定がねじ曲がるっていうのは絶対やってはいけないと思うんで、別に過剰に心を鬼にするつもりはないですけど、やっぱプラットフォームとして健全に成長していくために必要な強調と権制っていうのも、これからも意識してやっていきたいなと改めて思いました。
ビズ側からして、逆に不安なのは何でも受け入れられた時の方が不安は実はあるかもしれなくて、どっちかっていうと、それはやめといた方がいいってちゃんと精子してくれるであるとか、あるいはこういう方法の方がいいと思うよっていう技術を理解している側の人間のスタンスを正しく取ってくれる方がビズとしてはやりやすいなっていうふうには思っているので、
そこって、やなびさんが思っているほど、権制するとビズ側からするとうってなるというよりかは、健全な議論をしてくれている状態の方がヘルシーだなって正直思っているし、ビズが持ってきた要件に対してもっといい解き方ありますよってくれた時の方では異なる視点から他の解決方法を提示してくれるような、
36:12
同じ方向を向いて議論ができている状態っていうのが、認識できている方がヘルシーって言葉ばっかり使ってますけど、健全でいいかなっていうふうには感じるので、そこは多分ほとんどのビズはそういうふうに思っているんじゃないかなっていうふうには思いますね。
おだしょー これからは、検証するときはこの収録会のURLを添えて、橋原さんがいいって言ってるからっていうお墨付きとともに検証するようにします。
橋原 はい、わかりました。
おだしょー じゃあ、いい時間なので今日はこの辺にしておきましょうか。
今回は、個社制度プラットフォームというトピックで、Stellaが個社の課題や要求にどう向き合ってきたかを、ビズプロダクトの立場からお話しさせていただきました。
10XFMではリスナーさんからのお便りを募集しています。
エピソードの感想や10Xのメンバーに聞いてみたい質問など、どんなことでも構いません。
番組概要欄にあるお便りのフォークからの投稿、またはXでハッシュタグ10XFMでツイートをお願いいたします。
また10Xでは現在様々な職種のメンバーを募集しています。
この10XFMを聞いて、10Xに興味を持ったカジュアルに話を聞いてみたいと思われましたら、
こちらも番組概要欄にある採用情報、または10Xホームページのリクルートから応募をお待ちしております。
今回は10X執行役員の橋原とえなみがお送りしました。
それではまた次回。
