見出し画像

「高い技術力を持っている人が活躍する組織にしたい」新VPoEとCTOが語る STORES の今イベントレポート

2025年1月より STORES のエンジニア組織体制が変わり、VP of Engineering(以下、VPoE)が交代し、新VPoEとして小室 直が就任しました。今回の記事では、VPoE就任にあわせて2025年1月23日に行われた対談イベント「高い技術力を持っている人が活躍する組織にしたい」新VPoEとCTOが語る STORES の今をレポートします。

スピーカーは、VPoEの小室(以下、社内の呼び方に合わせhogelog)とCTOの藤村。聞き手はVP of PXの佐俣です。

プログラミングの面白さ

佐俣:STORES Meetup『新VPoEとCTOが語る STORES の今』を始めます。まず簡単に自己紹介をします。全体の司会を務めさせていただきます、VP of PX、人事組織周りを担当している佐俣と申します。よろしくお願いします。

hogelog:新しくVPoEになりましたhogelogこと小室です。よろしくお願いします。

藤村:CTOをやっている藤村です。よろしくお願いします。

佐俣:今日はこの3人で進行します。まず、STORES の紹介をします。2018年2月にCoineyとSTORES.jpが経営統合をしたところからスタートしています。来週でようやく7年です。

今、プロダクトとしては10個、いろんなプロダクトを出しています。たくさんの製品を作っていくエンジニアの組織が、今どんな感じなのか、これからどういう風にしていきたいのかというお話をできればと思っています。

STORES は、経営統合したり、グループ化して、違う技術スタック、基盤を使っている会社がひとつになって、すべてが統合されて今 STORES としてやっています。コンパウンドやマルチプロダクトなど、いろんな呼び方で一社が複数の製品を出すというトレンドがありますが、まさにその内のひとつです。STORES は、本気でデータ統合をやったり、いろんなものをひとつにすることを気合を入れてやっています。

特にこの数年は基盤の方に力を入れていて、ようやく整ってきたので、お客さんの課題解決ができるアプリケーションを出していくことが、去年の後半ぐらいからできるようになってきました。今日は組織と技術と面白さみたいなところをお話できればなと思います。 

まずはプログラミングについて。個人の志向性が出るかなと思うので、ここから聞いていきます。プログラミングは面白いですか? 

hogelog:プログラミングは面白いですね。これは本当に間違いなく面白い。書いてるときも楽しいし、でき上がったときも楽しいし、一体これは何なのか。改めて問われると謎なんですけど間違いなく楽しいです。

藤村:しかも人によって面白ポイントが違ったりしますよね。

佐俣:どういうときにテンションが上がりますか?

hogelog:例えばネットショップを作ることを考えたとして、お客さんの注文があって、リクエストを受け取って、データベースに記録して、決済処理を動かして……といった機能を粛々と実装するのも面白い。でもそういう「リクエストを受け取ったら何かをする」という処理自体は、いろんなものに共通する仕組みじゃないですか。それらを処理する共通化した枠組みを作って、その枠組みを使って、その上にある機能までしっかりできたときが、一番気持ちいいのかもしれない。

佐俣:そういう機会って、過去に所属していた会社と比べて、STORES だと多いんですか? テンションが上がる場面って結構あったりしますか?

hogelog:先ほど STORES は4社の会社からできているという話がありましたが、ひとつの会社になっていったのは割と最近で、それぞれ別のシステムだったんですよね。でも、そのまま別々だと困るんですよ。

佐俣:何が困りますか?

hogelog:プロダクトとしては「ひとつのSTORESです」と言っていて、いろんな機能やいろんなプロダクトを提供しています。でも「ネットショップを使うにはこちらでアカウント登録を」「決済を使うには別のアカウント」「予約システムを使うならまた別です」という状況だとしんどいですよね。ひとつと言っているのが嘘になってしまう。だから当然ひとつにしていかなきゃいけない。なので統合していこうと。

さっき話したことと順番は逆なんですが、STORES はすでにそれぞれ仕組みが動いている中で、共通化すべきものは何かを考えて共通化していく。レールを敷いていくっていう面白さがありましたね。

藤村:本当に難しい空中給油をずっとやっていて、気がついたら、何事もなかったかのように大きな仕組みができているというのが面白かった。

佐俣:事業の観点でいくと、複数のプロダクトがある場合、それぞれ別々のシステムのまま売っていく成長の仕方もあって、むしろそっちが主流なのかもしれません。でも STORES は、そこを繋げていくことをこの3、4年ずっとやってきています。そこにおけるプログラミングやエンジニアとしての楽しさって、どういうところにありますか?

hogelog:僕は動いているシステムを読み解いて、それがどういうものかを理解するのが好きなんです。STORES って本当にシステムがいっぱいあるんですよ。その中から、単純に処理が共通するとかじゃなくて、本質的に共通できる部分は何なのかを見つけるのが楽しい。藤村さんがさっき「空中給油」って話していましたけど、まさに空中給油ですよね。それぞれのプロダクトをまったく止めずに会社的にはくっついてきました。

佐俣:全然止まってないですね、なんなら伸ばしながらくっつけてくださいっていう。

藤村:動いているものに繋げるのは面白いんですよ。どうにかこうにかして「これは無理かな? でもこうしたらいけるか?」を探して、禍根が残らないようにやるけど、本当に禍根を全部残さないようにするととんでもなく時間がかかるから、ほどよくリーズナブルな量だけ残しつつ、バランスを取るのも面白いですよね。

佐俣:藤村さんは仕事をしててテンション上がる時はどんな時ですか?

藤村:僕も同じかもしれないですけど、導入した仕組みが何事もなかったかのように動いているのが一番嬉しいですね。ソフトウェアの仕組みでも、組織的な仕組みでもそうかもしれないですけど、ゼロフリクションで動いていて、もう誰もが何かあることすら考えていないくらい自然になっていると最高ですね。

佐俣:当たり前にあるものとして存在するってことですよね。それは気持ちいいですよね。

STORES はいまどんな状況?

佐俣:では次の質問なんですが、新しくVPoEになって「STORES はいまどんな状況か?」を聞きたいです。どう見てますか?

hogelog:大きめのプロダクトが10年選手ぐらいで4つあって、それらを「ひとつにしていきましょう」という流れだったわけです。経営統合をしましょうとなった時に、いきなり全力で全部を統合しようとすると、何回か止めるみたいなことになってしまうから、ちょっとずつ空中給油しながら走ってきたと思うんですよね。

今は、もともとのシステムやもともとの組織みたいな考え方がほぼなくなっていて、「ひとつのSTORES」として走っているのは、なかなか面白い状況だなと思っています。

佐俣:くっつけるという時、まず最初に統合したのは財務面、その後に組織面、そして次に技術・プロダクトをくっつける、と順を追ってやってきました。本当に「くっついたな」と思ったのって最近ですか? それとももっと手前から進んでいる感覚はありますか?

藤村:去年すごくなかったですか?

hogelog:そうですね。特に開発まわりはものすごい勢いで統合が進みました。それまでも一緒にやっていたんですが、プロダクトを止めずに走るというのを考えながらだったので、それぞれのやり方だった。でも去年は本当にくっついて、今年は「ひとつの開発組織」として走ってますね。

佐俣:「くっつける」って口では簡単に言えるんですけど、やるのは結構大変で、社内では「吐きそう」っていう声が出ることもありましたが、その中で面白かったことや印象に残っていること、つらかったことってありますか?

hogelog:つらかったことは思い浮かばない。何に対してもあんまり思わないんですよね。今の会社の状況を見ると「これが自然だよね」と素直に思えるので、なんで前はバラバラだったんだろう、元々別の会社だからしょうがないかと。

佐俣:当たり前にそうあるものと今は思っていますよね。

hogelog:間を繋ぐためのシステムとして、先行して作ったAPI GatewayやWebhook的な共通基盤の仕組みもカチッとハマりましたね。それは僕がVPoEになる前で、藤村さんや卜部さんが作ってきました。

藤村:技術的な部分はやばいことにはならなかったので、粛々と苦労するだけだった。

佐俣:何でうまくいったんですかね? うまくいかないケースもあると思うんですけど。

藤村:全部を止めて一気にやるのではなく、それぞれのタイミングで繋げるように心がけました。

佐俣:時間軸をずらしたり、そういう体制を取ったということですよね。

藤村:そうですね。あとは僕、個人で気をつけていたのは、なるべく普遍的な仕組みに寄せる、OpenID ConnectやGraphQLを採用すること。IdPとAPI GatewayとWebhookの仕組みぐらいしかないじゃないですか。それで開発できるようにしておけば、あまり事故は起きないかなぁと。

hogelog:簡単だったとは言えない話だと思う。でも、技術的な問題はやればできるという感覚があって、そう思って進めてきた。それよりも組織や動き方のほうが大変だったかもしれない。元々違うやり方で動いていたチームがいきなり一緒になるわけだから、そこで互いのバリューが最大限出せるようになるには多少時間かかったのかな、と。

佐俣:技術で解決できるところは技術で解決すればいいけど、そこに至るまでの組織のあり方やコンディション、考え方、動き方を合わせていく必要がある。そちらのほうが、時間がかかりましたね。

藤村:時間かかっちゃったな、という反省もありますが、一方でこのペースでやったから今この(ポジティブな)状況ができたんだよなって。

佐俣:急いだら壊れていたかもしれないですよね。

藤村:それはすごく思っていました。

佐俣:意思決定をしてドラスティックにやる方法もあるけど、それによって壊れることもある。壊れないようにするっていうのは、この会社を作る上で気をつけていました。

藤村:僕の差配はゆっくりとしたペースだと思われていたかもしれないけど、その結果が今なのかなと。

統合によるレバレッジ、エンジニアとしての楽しさ

佐俣:組織・技術面でも統合が進んだ状況で、この先、技術力でどうレバレッジをかけていくのか。あるいは技術力を高めることでどんな価値が出るのか、どう思ってますか?「高い技術力を持っている人が活躍する組織にしたい」と言った時に、そもそも高い技術力、高いの定義や技術力は何なのかをどう考えていますか?

hogelog:信じること。根性論ではない感じで言いたいんですが、それぐらいの問題はできると信じて進む力が高いと、技術的な解法が見えてくる。それこそ技術力の引き出しが多いとスムーズに進むことがある。技術者の中でたまに言われる「ハンマーを持ってると全てが釘に見える」みたいな。つい今持ってる道具を基準に、これを作るにはどうすればいいんだと考えてしまう。引き出しが多いと、そんなところで頑張らなくてもいいじゃん、ハンマーじゃなくてのこぎりを使えばいいというシーンがあったりする。

それぞれがいろんな道具を持っているし、組織の中を見回すとまた別の道具を持ってる人もいて、横からきて「このいい道具を使うと一瞬でできるよ」みたいなことができるようになる。いろんな技術力という引き出しを個人が持ってることで、いきなり組織を一気にドライブするパワーがあることが多いなというのを経験の中からも思っていて、STORES の中でも、何々さんがやったら一瞬で終わった!みたいなこともあったりします。

佐俣:今の話はhogelogさんそのものだなと思いました。できると信じてやればできると思うところとか。引き出しを増やすために意識していることはありますか?

hogelog:意識していることは何もないんですが、振り返ったり、周りをみてみると、自分の興味、好きなものがいろいろあって、それが活きてるんだなと思います。

佐俣:好奇心からきてるんですね。

hogelog:好奇心ですね。好奇心の力を信じてます。

藤村:それは僕もそう。

hogelog:最近社内であった話なんですけど、プライベートパッケージレジストリをいい感じにしたいという話をしていたら、開発ツールやセキュリティに興味を持っているメンバーが「こういうふうにやったらできそうですね」「ちょっと作ってみました!」と、すごい勢いでプライベートパッケージレジストリの基盤ができたんですよ。 その人がそういう領域が好きで興味を持っていて、引き出しがあったから、すごい勢いで出てくる。そういうものをまるで知らない人にお願いしたら、そうはならないですよね。もちろんそういうアサインの仕方もありますが。

引き出しを持っている人が周りにいると、いきなり高いバリューを出してくる、それって大事だよなって。そういう人たちは普段から興味深くいろいろ見てる、でも別に仕事に役立てようと思ってやってるわけでもないんですよね。 好きなんですね。

技術力の高い人がたくさんいる組織にしたい

佐俣:hogelogさんは STORES をどうハックしますか?これまでの延長線上で作っていくよりも、非連続に面白いプロダクトを出していく、お客さんの課題解決をもっと多くできるようになるために、何かやろうとしてることってありますか?

hogelog:本質的にやるべきことは何かと言ったら、STORES の開発を良くして、プロダクトの価値を高めることですね。 まず一番はプロダクトの価値を高めることなんですけど、そのために開発組織をどうしていくか。不真面目な発言に聞こえるかもしれないですけど、すごく技術力の高い人がたくさんいるたのしい組織にしたい。

佐俣:なんでですか?

hogelog:技術力が高い人がやっている仕事は、面白いんですよね。そういう人たちがいると、一緒に働きたい人が増えて、さらに技術力が高い人たちが集まってくる。結果的に開発スピードも品質も上がって、プロダクトにも良い影響がある。だから僕が面白いと思う、高い技術力がある人に来てもらいたいし、今いる人にも技術力を高めてほしいと思っている。

佐俣:「技術力が高い人」「面白い人」は、技術力が高い=面白いなのか、技術力が高い×面白いなのか、どういう風に見ていますか?技術力が高い人はすべからく面白いのか。

藤村:技術力が高い人はだいたい面白いですよね。なんでだろう。

hogelog:僕の思う技術力が高い人はみんな面白い。

佐俣:さっき話していた、信じるとか引き出しの多さってことですね。

hogelog:はい。

佐俣:基本的に組織は、今いる組織にないもの、もっとすごいものを持っている人を集める方がよくなると思います。技術力を持っている人を集めていくための課題はありますか?

hogelog:魅力的な会社が世の中に多くあることですかね。個々人の情報発信力が高まっている時代では、本当にいい組織にしていかないと、小手先では採用できない。各社本当にいい組織づくりに取り組んでいる。いい会社がいっぱいある中で、STORES は百戦百勝ですみたいな感じではない。

佐俣:いい会社、いっぱいありますよね。

藤村:でも、STORES はこの規模で統合されたソフトウェアを開発していて、どの領域にも手を出せて、まだまだハックできる余地がある。実力派の人はインパクトのあるプルリクエストを出せる環境になっていると思います。

hogelog:チームとしてのアウトプット量を最大化するっていうのは、それぞれのプロダクト開発をしていく中で大事なんですけど、今の社内にいる人たちを見ても、すごい人の活躍が秀でてる状況っていうのもあって。ソフトウェアエンジニアって面白い職業だなというか、すごい人の活躍をスポイルしないチーム作りも大事なんだろうなって思っています。

佐俣:下げないってことですよね。すごい人はもっとすごくなるようなミッションだったりとか、そういう形で動けるようにする。外れ値を許容するというか。

hogelog:外れ値を許容する、外れ値こそ最大に活用する。

佐俣:外れ値が我々の最大の魅力かもしれませんね。

hogelog:エンジニア個々人のプルリクエスト数も見てるんですけど、 すごい人って桁が違う。チームで開発を進めるときには標準化も必要かもしれないですけど、それをやりすぎることでそういうのをスポイルしてはいけないと思いますね。 

佐俣:外れ値についてもう少し聞きたいんですが、そういう人たちって引き出しの多さ以外に共通することってあるんですか?その人たちって、今 STORES でどういうふうに仕事を楽しんでいるんですか?

hogelog:それぞれの人の内心の楽しさを正確に答えられる自信はないんですが、ただ見ていて思うのは、こうやったらできるだろうというのがそれぞれの人たちにあるんだろうなと。その人たちなりの答えがあって、答えはこうなんだから、こうやれば進めるよねみたいな。なので、やり方を決めて進めていくスピードが速い。

自分なりの答えを持って、その答えに向かってギャップを埋めていく。埋めるためのプルリクエスト、差分コードを書く速度が速くて、どんどん進んでいく。 かつ、その人なりの答えが精度高く出てくるのかなって思いました。 

藤村:自分で答えを持ってる人が活躍するし、高い技術力を持つようになる。因果関係は逆かもしれないけど、そうだと思います。引き出しの幅と深さがそこそこないと、思考の蓄積もできないので。

hogelog:何か課題があって、どうやるのかクエスチョンをまず出す場面もあるとは思うんですけども、プルリクエスト数やスピードが出る人は、そこでクエスチョンになることがあっても自分なりの答えを出す。だから速度が速いのかなって思いますね。 

佐俣:引き出しがある上での意思決定と、それを技術っていう実で解決していく両方が必要ってことですね。

hogelog:そうですね。

藤村:あと、こんなに面倒くさいのが許されるわけないだろうって思う時ありませんか?こんなにややこしくしないといけないことはないだろうって思う。

hogelog:ありますよね。

佐俣:そういう人たちが社内ですごく活躍していると。

最近面白かった技術

hogelog:最近、藤村さんが面白かった技術は?

佐俣:藤村さん、最近楽しそうですよね。

藤村:僕はClaudeが出したMCP(Model Context Protocol)ですね。AIが外部の世界に触れるようになったら未来が来るよねって話をよくしてたんですけど、まさにその外部の世界を触るプロトコルができた。LLMを介して外部のAPIなどを叩けるようにするっていう仕組みなんですけど、想像力が広がるんですよね。 MCPサーバの裏側って大体コンピュータなんですけど、MCPサーバの裏側が人間だったらどうなんだろうみたいなことを想像するわけですよ。 

佐俣:今週その話をしましたね。

藤村:ディストピアだなとも思う一方で、Claudeに即座に聞いてみると、「人間とAIのハイブリッドアプローチですごく有効だと思います」って言われて賢いなと思って。面白かったですね。

佐俣:hogelogさんは最近触ったもので面白かったものありますか?

hogelog:ちょっと前に楽しかったもので言うと、WordPressですね。STORES の組織の中でもちょっとしたWordPressが運用されていて、何かしらのプラグインでリダイレクト処理がされている。そのWordPress自体はもう動いていないが、どういうリダイレクトをしていたか一覧を取り出したいという話があったんですよ。

過去のやり取りを追って、スクリーンショットからおそらくこのプラグインだろうと目星をつけて、プラグインのソースコードを読んで、こういうデータベースの中にテーブルがあって、そのテーブルの中にカラムがあって、一覧があるはずだと思って見てみたら、リダイレクト一覧を取り出せたんですよね。

社内の中で誰もさっとできる人はそんなに多くないであろう仕事ができたなって。 楽しかったです。最近面白かった技術とはちょっと違う話かもしれないですけど。

藤村:すごいね、MCPって言ってる人とWordPressって言ってる人がいる。

5年後にRubyがどうなっているのかが楽しみ

佐俣:質問がきましたね。「これからもRubyをやっていくんですか?」

hogelog:はい、もちろんやっていきますよ。STORES にはフルタイムRubyコミッターが2人在籍していて、フルタイムじゃないコミッターもいます。それはRubyの価値を信じているからこそ、やってもらっていますし、Rubyでプロダクト開発もしています。

藤村:僕もhogelogさんもRubyというプログラミング言語を近いところで見ている。いろんな言語でプログラムを書いてきましたけど、Rubyは評判がどうとかではなく、内実としてすごく進化しているのを目の前で見ているし、まだまだ可能性があると思っているんですよ。5年後のRubyがどうなっているのか楽しみですよね。

hogelog:楽しみですね。Ruby、特にRailsの生産性に疑問符をつけられている世の中の評判もあったりするかと思うんですが、素直にRuby、Railsの生産性、もっと高い価値があると信じています。

佐俣:Ruby以外の言語に対してってありますか?

hogelog:もちろんGoも使ってますし、Javaのプロダクトもあります。

藤村:僕も色々好きなんで、Pythonも楽しく書けますよ。

hogelog:僕もJavaが割と好きだったりします。仕事としての生まれと育ちはJavaなんで。この世代の人はみんなそうかもしれないですけど。

Goもすごいんですよ。データベースが絡まないようなHTTPで喋るアプリケーションを普通に書くと、Rubyで超絶チューニングしたアプリケーションみたいなパフォーマンスがでたり。

藤村:まじでそれ。僕は書き心地も好きだけどね、まっすぐ書いていけば書ける。

hogelog:言語はそれぞれに良さがありますからね。個人的にRubyがすごく好きですし、中身を一番見ているのはRubyですが、Javaは素直に好きですね。

藤村:どこが素直に好きなんですか?

hogelog:普通に一通りあるじゃないですか。

藤村:それは別にRubyでもそうじゃないですか。

hogelog:元々プログラミング言語処理系が好きで、学生時代に研究をしていたんですが、プログラミング言語処理系の研究をやっていた人たちはJava先輩に尊敬の念を抱く。もしかしたらその感情に今でもハックされてるだけかもしれない。でも普通にいい言語だと思います。 ずっと第一線ですしね。

藤村:しかも返り咲きましたよね。我々の若い頃から比べると。

hogelog:Java 6、Java 7の時代はずっと停滞している言語みたいな感じだったけど、どんどん進化している。最新のJavaの機能を追いかけるのが大変なぐらい、いろいろ増えていってますね。 面白いですね。

1年後、組織はどうなっているのか

佐俣:これから新しい体制で動いていく中で、1、2年後ぐらいの軸で、hogelogさんが「こうなっていたらいいな」と思う像はありますか?

hogelog:エンジニアの価値はプロダクトを使っている人に価値を届けることだと思っています。それに向けてすべてやることは大前提。その前提がありながら、「道具」にもこだわりを持って作っていく。それぞれが「あのハンマー最高なんだよ」ってワイワイしつつ、いざ「仕事するぞ」ってなったら本気で課題解決に集中する。そういうエンジニアが集まっている組織になっていったらいいなと思います。今もすでにそういう方向ですが、もっとそうなっていくといいなと思っています。

そうなるといい組織だし、もっと STORES のプロダクトをよくしていける。

藤村:ハンマーを使うときに、このハンマーがいい、あのハンマーがいい、チタンじゃない方が精度が高い、打つときの重心は腰より下の方がいいみたいな話をずっとしてたりするけど、さっき言った通りプロダクトで価値を出すときにはシュッとそっちに向かう。すると、必要なときにさっとハンマーが出せるんですよね。
それぞれが適材適所でよく練られたソフトウェアや技術的な問題解決を積み重ねることで、生産性が高いソフトウェア開発のチームができると思うので、楽しみです。それを目指していきたいですね。

佐俣:来年の今頃はそこに向かっていたり、そうなったねと言えるといいですね。

hogelog:そうですね。社内の仕組みも含めて、それぞれに求めることは課題を解決すること。エンジニアに限らず、社員に求めるパフォーマンスとは本質的な課題を解決することだという意識が統一されるように整備されていってる。それはいいなと思っています。なので、そういう組織になれると思っています。開発組織の中でもそれが一番大事。

一方で、道具も全力で磨こうというのは、僕や藤村さんの仕事の中で大事なことだとも思っています。でも課題を解決すること、それが一番大事だからねっていうことは繰り返し言っていきたいですね。 

佐俣:ありがとうございます。それでは、STORES Meetup『新VPoEとCTOが語る STORES の今』はこれで終了です。皆さんありがとうございました。


\ STORES では一緒にはたらく仲間を募集中です!/


いいなと思ったら応援しよう!

ピックアップされています

エンジニア

  • 117本

経営メンバー

  • 30本
STORES は “Just for Fun” をミッションに、「好き」や「こだわり」から生まれるお店の挑戦を支えています。このnoteでは、STORES で働く人やカルチャー、仕事のリアルなストーリーお届けしています!
「高い技術力を持っている人が活躍する組織にしたい」新VPoEとCTOが語る STORES の今イベントレポート|STORES note
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1