"What Would You Do?"
「あなたならどうする？」
2025年11月26日（水）に開催された STORES Tech Conf 2025 "What Would You Do?" に学生支援制度を利用して参加させていただきました。
カンファレンスのクロージングキーノートで語られた「I Do.」という言葉が、今も頭から離れません。カオスな時代の中で、ソフトウェアエンジニアとしてどう生きるか。技術的な選択、キャリアの選択、人生の選択——すべてにおいて、「あなたならどうする？」という問いが投げかけられました。
カオスな時代のソフトウェアエンジニアリングの中で、「あなたならどうする？」と問われたときに、自分で選んで I Do と言えるか。
本記事では、参加した学生の視点から、カンファレンスの内容や感想、学びを詳しくまとめます。そして、この問いへの僕なりの答えを探していきます。
こんにちは、とわです！
情報工学を学びつつ、北海道を拠点に、研究・スタートアップ・学生コミュニティ運営（Q-PIT）・インターンを行き来しながら、いい感じにカオスな生活を続けている地方学生エンジニアです。
STORES Tech Conf 2025について
開催概要
- 開催日時: 2025年11月26日（水）13:00〜19:00、懇親会19:00〜21:00 (学生はランチも！)
- 開催場所: 浅草橋ヒューリックホール&カンファレンス
- テーマ: "What Would You Do?"
- 参加費用: ご支援いただきました！！！！！
- 主催: STORES 株式会社
テーマについて
今年のテーマは "What Would You Do?" でした。STORESが「ひとつのSTORES」を目指す中で、製品とシステムが不可分に接続され続け、さらにソフトウェアを作るという営み自体がAIの進化でめまぐるしく変わっている。そんなSTORESの進化とソフトウェア開発そのものの大きな変化をどう捉え、どのように決断し、何に挑戦したか。いま、ここで、「あなたならどうする？」——それを問うカンファレンスでした。
会場の様子
学生支援制度について
STORES Tech Conf 2025では、学生向けの参加支援制度が設けられており、宿泊交通費の支援を受けました！
遠方からの参加でも気軽に参加できる素晴らしい制度でした。このような支援制度があることで、地方の学生でも最新の技術カンファレンスに参加できる機会が広がっていることを実感しました。
北海道からだと、普通に自腹で行くと「うーん、見送りかな…」となりがちですが、支援のおかげで「迷ったけど行くか」が「行く前提でどう調整するか」に変わりました。
これだけでもう、「地方学生にもちゃんと開かれているイベントだな」と感じました。
会場の様子
会場は浅草橋ヒューリックホール&カンファレンスで、コンテンツもとても多かったです。セッションルーム、ポスターセッションエリア、ブースエリア、そして交流スペースが充実していて、1日中楽しめる構成になっていました。
プロダクト体験ブースやキーボード展示エリア
STORES CAFE for STUDENT
学生限定のミニセッション 「STORES CAFE for STUDENT」 にも参加しました。新卒1〜3年目くらいの若手エンジニアが中心で、就活・キャリアの話をかなり生々しくしてくれます。
座談会の内容 - ざっくり
「STORESで働いてて辛いことは？」
いきなり質問が攻めていて、「これ、聞いていいやつなんだ」と思いましたw
出てきた話をざっくりメモベースで書くと
-
「しんどすぎて無理」ってなったときに、周りが結構本気で支えてくれる→ メンタル的に落ちたときに、一人で抱え込ませない文化がある
-
チームが小さい（2〜3人）ことが多くて、一人あたりの責任範囲が広い→ やることが多い＝楽しいという人には合うけど、そうでないときつい
モデレーターの一言がまとめとして強かったです。
「良くも悪くも、今のSTORESは中身をそのまま話すと結構カオスなんですよね。そのカオスを楽しめる人にはすごく合ってるけど、一つの環境で落ち着いて細かい改善だけやっていたい人には、今のフェーズはちょっと違うかもしれない。」
「あ、この人たち本当にそう思ってるんだな」と思える温度感でした。
「学生の時にやっておいて良かったこと」
ここは、自分の学生生活とかなりリンクしたポイントでした。
-
授業 + 個人開発 + 研究で完結してしまっていて、サークルやコミュニティ活動をほとんどしてこなかった
-
同年代の横のつながりが薄くて、今になってちょっと損してるなと思うことがある
という話が出ていて、逆に言えば
「学生のうちにコミュニティに関わっておくと、思っている以上に後で効いてくる」
ということでもあります。
自分は今、学内コミュニティや学生団体を運営している側でもあるので、「やっておいて良かった」側の話をリアルタイムで聞けた感じでした。反面、「もっとちゃんと運営に時間割くか…」というプレッシャーも地味に増えましたw
「STORESの気に入らないところは？」 (これを聞くのか...)
この質問もストレートすぎて笑いましたが、ちゃんと答えてくれました。
- オフィスの物理的な広さ的に、休憩スペースとワークスペースの境界があいまい
ただ、それでも最後に
「カオスはカオスなんですけど、それを楽しんでる人が多いですね」
とあり、STORESに限らず、「今のフェーズのスタートアップ全部そうなんだろうな」とも思います。
印象に残ったセッション
オープニングキーノート「ひとつの開発環境」
shiaさん（技術推進本部）によるオープニングキーノートでは、STORESが「ひとつのSTORES」を目指す中で、複数のシステムを跨いだ開発環境をどう整備していくかという挑戦についての話。
学び
- 開発環境の重要性: 大規模なシステム統合において、開発環境の統一がいかに重要か
- 開発者の体験を重視: 技術的な正しさだけでなく、開発者が楽しく、ストレスなく開発できる環境を目指す姿勢
- 果てしない旅程: 完璧な開発環境は存在せず、常に改善し続ける必要がある
このキーノートから、STORESが技術的な挑戦だけでなく、開発者の体験を大切にしていることが伝わってきました。
年2回のリリースということでそのうち、リリースの四季ができそうというw
「なぜRubyをわざわざ作り直すのか」
Ruby コミッター笹田耕一さんのセッションは、Ruby の VM や GC、Ractor の話ももちろん面白かったのですが、それ以上に
「楽しいからやる。Just for Fun です。」
とさらっと言い切っていたところが刺さりました。
Rubyの歴史
※本セクションは当日の説明をもとに、筆者理解でまとめています
- 1993年: 開発開始
- 1995年: リリース（今年で30周年）
- 2007年: 笹田さんがコミッターにジョイン、仮想マシンの導入
- 2020年: Ractor（並列並行のための仕組み）の導入
主な取り組み
1. 仮想マシンの導入
Javaのバーチャルマシンが有名になった1995年頃、Rubyにも仮想マシンを導入することでパフォーマンスを向上させました。しかし、「これだったらできるよ」というテクニックがRubyに通用しないことが多く、そこをどう無理やりにでも通用させていくかが挑戦だったとのこと。
2. 世代別GCの導入
「RubyのGCって遅い」というのは20年前によく言われていたことですが、世代別GCを導入することで10倍速くなったとのこと。ただし、Rubyには技術的に難しい部分があり、「ちょっと今のRuby捨てなきゃいけないね」と言われていたところを、新しいテクニックを発明することで乗り越えたというエピソードが印象的でした。
3. Ractorの導入
2020年に導入されたRactorは、全く新しい概念を創出するもので、言語デザイン、世界観をデザインする仕事だったとのこと。並列並行プログラミングはむちゃくちゃ大変だが、Rubyユーザーにむちゃくちゃ大変なことをさせないための仕組みとして作っている、という姿勢が素晴らしいと思いました。
学び
- 30年続く設計の良さ: Rubyのインタープリターは30年経っても大きく変わっておらず、最初の設計がよくできていた
- パフォーマンス改善への情熱: 電車で30分立っている間もずっと考え続けるほど没頭できるパズルとして、パフォーマンス改善に取り組んでいる
- 「Just for Fun」の精神: 楽しいからやる、というシンプルな動機が30年続く開発を支えている
「Railsでgraphql-rubyを使い倒して（振り返り、未来へ、RESTと比較して）」
プロダクト開発本部のyubrotさんによるGraphQLのセッションを聞いてきました。
結論から言うと、 「REST API設計の『あの』面倒な意思決定から解放されたいなら、GraphQL一択かもしれない」 という話です。
STORESでのGraphQLの活用
- 2020年頃から: サーバとWebアプリ間で使用開始
- 主な用途: モバイル・WebのためのAPI、システム間通信（最も多く使用）
- 背景: 複数の独立したシステムを「ひとつのSTORES」に繋げる中で、APIスキーマが求められ、デファクトとしてGraphQLが広く使われた
GraphQLの利点:意思決定が少なくなる
REST APIを作る際には様々な意思決定が必要になります
- APIスキーマをどう書くか
- エンドポイントをどうするか
- リスト vs 1要素のAPIで、それぞれどこまでの情報を返すか
- fieldsクエリのような仕組みをサポートするか
- ページネーションをどうするか
一方、GraphQLはもう全部決まっている
- スキーマ言語が持つ表現（Union、Enum、インターフェース、タイプ）が機械的に決定できる
- オンデマンドなクエリができる（「One size fits all」）
- API設計は理想的なグラフ上のデータを1つ定義するだけ
REST API、意思決定すること多すぎ問題
- このエンドポイントのURL設計どうする？
- リスト取得と詳細取得で返すJSONの形、微妙に変える？
- ページネーションのパラメータ名は？
セッションで語られたGraphQLの最大の利点は、ここが 「もう全部決まっている」 こと。
スキーマ言語の仕様に従うだけ。「One size fits all」で、欲しいデータはクライアントがクエリで指定すればいい。この 「サーバーサイドが悩まなくていい」 という一点だけでも、導入コストを払う価値があるなと感じました。
graphql-rubyは "Batteries Included"
Rubyistにとって嬉しいのが、graphql-rubyの実装スタイルです。
コードファーストで、Rubyのクラスを書けばそれがそのまま型になる。
例えばページネーションなんて、これ一行です。
field :activities, ActivityType.connection_type
これだけで ActiveRecord::Relation と統合されたページネーションが動く。魔法かな？
破壊的変更のマークも deprecation_reason を書くだけ。
とはいえ、銀の弾丸ではない（監視とか）
もちろん良いことばかりじゃなくて、 「監視」 については一工夫必要とのことでした。
エンドポイントが /graphql ひとつしかないので、そのままだとDatadogで見ても「全部同じリクエスト」に見えてしまうんですよね。
STORESではOperation NameをSpanに乗せたりして可視化しているそうです。
正直、この辺の監視の話は、まだ実務でGraphQLを使ったことがないので、実感が湧きにくかったです。「なるほど、そういう課題があるのか」という理解止まりで、実際に自分で実装するときにどうなるかは、まだ分からないな、という感じです。
学び
学習コストは高いですが、RESTで独自規格（オレオレREST）を量産して消耗するくらいなら、GraphQLという「巨人の肩」に乗ってしまったほうが、結果的に開発体験は良くなりそうです。
「道具を知り、うまく使う」。
当たり前だけど、それが一番の近道なんだなと再確認したセッションでした。
「決済だけでは終わらない、決済手段追加の舞台裏」
島田幸さん（テクノロジー部門BPR本部）による決済手段追加のセッションでは、表側の機能追加だけでなく、裏側の審査フローやオペレーションの複雑さについて知ることができました。
キャッシュレス決済の仕組み
決済業界では以下のような用語が使われているそうです
- イシュア（Issuer）: お客さんにカードを発行する会社
- アクワイアラ（Acquirer）: 加盟店が契約する会社
- STORES決済: アクワイアラと加盟店の間に入るサービス
決済手段追加の表側
2024年11月に、国内の主要QRコード決済（PayPay、d払い、楽天ペイ、Smart Code）に同時対応しました。Smart Codeを導入すると、メルペイやファミペイなど20以上のQRコードブランドが一度に使えるようになります。
決済手段追加の舞台裏
決済まわりのセッションは、「技術」というよりはオペレーションと業務設計の話でした。
- 加盟店がSTORES決済に申し込み
- STORES決済がアクワイアラに審査依頼
- アクワイアラが審査（申請内容が正しいか、取り扱い商品に問題ないか）
- 審査通過後、決済ゲートウェイに加盟店を登録
- STORES決済から加盟店に通知
審査の複雑さ
ファイル出力の大変さ
- 必要な項目が100以上並ぶ場合も
- アクワイアラごとにフォーマットが違う
- 業種コードがアクワイアラごとに違うので変換が必要
- バリデーションルールもバラバラ（住所の「何階」をカタカナにするかアルファベットにするかなど）
審査の依存関係
決済手段が増えると、審査フローは複雑になります
- Visa・Masterの一次審査が通ったら
- JCB・Amex・Diners・Discoverの二次審査と交通系電子マネー・iDの審査に提出
- JCBの審査が終わらないと、QUICPayや国内QRコード決済の審査に進めない
既存加盟店への対応
11月11日のリリースに向けて、6月頃から既存加盟店の審査提出を開始。
- DBに保持しているデータそのまま使える想定だったが、過去に登録された一部の加盟店では住所のカナが登録されていない
- 外部APIを使って郵便番号からカナの変換が必要に
- 登録内容の変更があった場合、実態と違っていて不備になる加盟店が多数
- 審査期間が想定よりも長くかかった
結果として、2025年3月に既存加盟店の審査結果の登録が終わってプロジェクトが完了したとのこと。
学び
一回きりの対応だからシステム化しない判断をしたところが、
後から揺り戻してきたエピソードも含めて、
「表のリリースノート一行の裏に、どれだけ泥臭い仕事があるか」 を実感できるセッションでした。
そういえば、このセッション聞いてて、大学の研究で似たような経験を思い出しました。一回きりのデータ処理だから手動でやったら、後から「あ、これもう一回必要になった」ってなって、結局スクリプト書く羽目になった、みたいな。STORESでも同じようなことが起きてるんだな、と思って、なんだか親近感が湧きました。
でも、STORESの規模だと、その「一回きり」の影響範囲が全然違うんだろうな、とも思います。
プロダクト体験ブース
STORESの実際のプロダクトを体験できるブースがありました。特に、新しく発表されたスタンドアローンで使える決済端末の実機を触ることができて、とても興味深かったです。
大学の学生団体で食堂関連のデジタル化周りの開発を行っているので、とても勉強になる話ばかりでした。
技術的な学び
STORES Tech Conf 2025では、単なる技術の紹介だけでなく、なぜその技術を選んだのか、どのような課題を解決しようとしているのかという背景まで深く学ぶことができました。
特に印象的だったのは、STORESが「ひとつのSTORES」を目指す中で、技術的な選択がビジネス目標と密接に結びついていることです。
クロージングキーノート「I Do」
ykpythemindさん（プロダクト統合本部）のクロージングは、技術の話というより、この時代にエンジニアとしてどう立つかを真正面から問いかける内容だった。言葉の選び方も温度も、生々しくて、刺さるところが多かった。
「I Do」の対義語は「Do It」
最初に出てきたのが、この一言。
「I Do の対義語は Do It（やれや）です」
上から言われて動くのではなく、自分で選んで足を踏み出すかどうか。今みたいなカオスな時代だと、その差がとんでもなく大きくなる——そんな話だった。
カオスと認知の限界
話はそのまま、“今どれだけ世界がカオスか” という方向へ転がっていく。
- 情報は止まらず流れ続ける
- AIの進化で、使う技術が週単位で変わる
- SNSがFOMOを煽ってくる
普通に生活しているだけで、頭がパンパンになる感じ。さらに、コンパウンドスタートアップの構造やAIの加速もあって、「誰でもある程度は作れる時代」 に突入している、とのこと。
ここは普段エンジニアをやっている中でも強く感じるところです。
広がった責任範囲と、重たくなる“こだわり”
AIのおかげで、一人でできることは間違いなく増えた。でも、その裏では、
- 全体を把握しながら一つずつ進めるしんどさ
- 昔あった素朴な「作る楽しさ」を感じにくくなる瞬間
- でも価値を出そうと思うと結局“こだわり”や“情熱”が必要
みたいな、どうしようもない現実も積み上がっていく。
ykpythemindさんはこれを 「俗人化の時代」＝「情熱の時代」 と言っていた。技術で差がつかないからこそ、なぜそれを作るのか、どこにこだわるのかが価値になる、という話に強く頷いてしまった。
3つのバッドエンド
この時代でやりがちな“詰みルート”として、こんな3つが挙げられていました。
- 情熱だけで突っ走る → 認知負荷で潰れる
- 献身で支えようとする → AIとの境界が曖昧になって価値が希薄になる
- 現状維持で流される → ゆっくり終わっていく
どれも「ありそうだな…」と思えるリアルさがありました。
「行けるところまで行く」
黒沢清監督『回路』のセリフが引用された。
行けるところまで行く。
逃げるでもなく、立ち止まるでもなく、宣言もしない。ただ進む。雑にも見えるけど、そこに人としての強さがある、という話だった。妙に胸に残った...
学び
- カオスが強まるほど、最後に残るのは情熱とこだわり
- "What Would You Do?" に対する答えとしての 「I Do」
- 諦めず、抱えたまま、それでも進むという選択肢
このクロージングは、技術の話を超えて、どう選んで、どう生きるかを問いかける時間でした。
終わりに：どこまで行くか、どこで I Do と言うか
そもそも今回のテーマは “What Would You Do?” でした。
CTO の藤村さんはクロージングで、
- SaaS もソフトウェアも、これからどうなるかは誰にも分からない
- そんなカオスな時代に、STORES が「こうしてきた／こうしている」を 30 本くらい並べてみた
- それが、ここにいる一人ひとりの
What would you do?を考える材料になればいい
という話をしていました。
正直、まだちゃんと整理できていません。
「I Do.」と口にするのが、ちょっと怖くなったのも事実です。
- カオスは加速している
- ソフトウェアはコモディティ化していく
- 情熱は“要求されるもの”になっていく
- それでも、行けるところまで行くしかない
話していたことって、エンジニアのキャリア論というより、「どう生きるか」の話だったなと思っています。
「行けるところまで行く」
このセリフを聞いたときに、なぜか北海道に戻ったあとの自分の生活が頭に浮かびました。
研究、スタートアップ、アルバイト、学生コミュニティ、インターン…
冷静に考えると全部ちゃんとやるのは大変なんですけど、それでもまだどれも進めたい。
「何かを諦めて身軽になる」じゃなくて、
諦めきれないものを抱えたまま、それでも前に進む という選択肢があるんだな、と思えたのが、この日の一番の収穫でした。
僕にとっての I Do は、今のところこんな感じです。
- カオスなソフトウェア業界からは逃げないで変化を楽しむ
- なんだかんだ言いながら、それでも書き続ける
どこまで行けるかは分からないし、途中で「やっぱ無理でした」と言う未来も普通にありえます。
それでも、楽しんで、試行錯誤して、作って届ける。やっぱりここなんだよな、と思っています。
I Do.
関連リンク:
Discussion