![[山岡家さんセッションレポート] リアルタイムWEBアプリを楽しく開発していたら、200店舗で活用されてしまった件 #jawsugibaraki #jawsug](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/v1762660896/user-gen-eyecatch/ckhrynwqeupvkiee6aqy.png)
[山岡家さんセッションレポート] リアルタイムWEBアプリを楽しく開発していたら、200店舗で活用されてしまった件 #jawsugibaraki #jawsug
コーヒーが好きな emi です。最近はカフェインを控えています。
2025/11/8(土) に開催された「JAWS-UG 茨城 #9 1周年だよ！水戸に集合だぁ！」に参加しました。
山岡家さんのセッションを拝聴しましたので、レポートします。
セッション情報
- セッション名: リアルタイムWEBアプリを楽しく開発していたら、200店舗で活用されてしまった件
- 登壇者: 田中 陽里 氏
セッションレポート
1. ラーメン山岡家について
山岡家は店舗で原材料からスープを作っているラーメンチェーン店です。この規模のチェーン店では珍しく、材料は豚骨と水だけで、野生味のある味わいが特徴です。店舗でスープから手作りしているため、お昼のピークの後は少し味が薄いなど、店舗や時間帯によって微妙に味が変わるそうです。
「ガツンと来て、くせになる。」というキャッチフレーズがあり、ロードサイドの店舗が多く、主にお仕事中の男性がメインのお客様でリピート率も高いとのこと。24 時間 365 日営業の店舗がほとんどです。2 年ほど前に SNS でバズり、最近は若いお客様が急増しています。
近頃のラーメンと比較すると価格帯はかなりお得で、ラーメン 1 杯 690 円（税込）〜となっています。
2. 登壇者の経歴と AWS との出会い
田中 陽里氏のプロフィール
- 元々 Java エンジニアで、SQL、FRP（Functional Reactive Programming）といった宣言型プログラミングが好き
- 山岡家には情シスとして入社し、開発要員が田中さんだけだったため、山岡家で導入したシステムはほぼ全て田中さんがインフラから一人で構築してきた（！）
AWS との長い付き合い
- 2009 年から AWS を使用しており、アベイラビリティゾーン B を持つ古参ユーザー
- 本格利用のきっかけは 2011 年の東日本大震災
- オンプレミスサーバーが震災で停電・UPS 停止により 1 週間停止
- 震災当時田中さんは北海道に出張中で帰れず、サーバーを復旧できない状況に
- 帰京後、数ヶ月かけてオンプレの AD（Active Directory）とインナーネットワークを AWS に移行
- 2015-16 年頃には全てのオンプレサーバーを廃止し、全インフラを AWS に移行完了
- 2010 年代の AWS 活用
- VPC と Direct Connect を使って全店舗をスター型に接続]
- 店舗機器監視や PC リモート操作、複合機アプリ利用
- 売上処理
- 発券機から飛んでくる売上を SFTP→S3→Athena→SQS→Lambda→RDS（Oracle）で集計
- 社内API「whereami」
- iPad から叩くとどの店舗からアクセスしているか特定できる仕組み
- iPad を持って行けば、その店舗の仕様で立ち上げられるなど
- VPC と Direct Connect を使って全店舗をスター型に接続]
3. ゆでめんタイマー V1 の開発背景
山岡家の店舗では「麺上げ」という調理担当者が司令塔の役割を果たします。この仕事は店舗で最も経験のある人が担当する難しいポジションです。
- 麺上げが難しい理由
- 山岡家ではお客様が麺の硬さを指定できるサービスを提供している（かため、やわめ…）
- 3 種類以上の麺を扱っており、配合によって茹で時間が異なる
- 高頻度でオーダーが来るため、同時並行で複数の麺を茹でる必要がある
- ベテランは効率的にこなせるが、経験の浅い人には困難
- 既存ソリューションの課題
- 飲食業界にはよくあるキッチンディスプレイシステムは存在したが、オーダーに表示のみで茹で時間管理には使えない
- 厨房機器メーカーのタイマーは存在したが、調理器具のレイアウトと画面レイアウトが一致せず使いにくい
上記課題から、田中さんは調理器具のレイアウトとタイマーの画面レイアウトを一致させればオペレーション改善できるのではないかと考え、ゆでめんタイマー V1 を開発することにしました。
4. V1 の開発と 200 店舗への展開プロセス
- 開発までの道のり
- 構想期間約 2 年間
- 残業時間で 2〜3 人月程度で開発
- 現場ヘルプの人に iPad を渡して使ってもらい、フィードバックを収集、継続改善
- 新店舗には標準装備として導入し、約 3 年前に全店展開完了
V1 で使用した技術要素
- WebSocket
- Slack を使って動きを理解
- Redis
- 単純なキャッシュではなく、イベント通知から発火できる仕組みとして利用。イベント管理をほぼ任せられる
- React + Material-UI
- フロントエンドを簡単に作成できる
- Airtable
- 設定やマスターデータの管理を任せることで、画面を作る手間を省略
- パパッと作るには良かったが、後に障害の原因にもなった
- iPad
- スターバックスの厨房で防水カバー付き iPad が使われているのを見て着想
- 全く同じ防水カバーを購入して使用
- 200 店舗で年に 4〜5 台故障する程度の高い耐久性
- 初期は Raspberry Pi と防水タッチパネルも試したが、iPad の方が可用性が高かった
実装では、Redis から発火されるイベントを起点に、FRP の考え方を取り入れた宣言的な処理の流れを構築しています。具体的には、Redis からイベントを受け取り、それを FRP っぽく宣言的に処理し、最終的に WebSocket を通じてクライアントに流すという、イベント駆動のアーキテクチャになっているとのことでした。
5. V1 の成功要因
- クラウド× Web システム採用の判断
- 従来の飲食店システムは店舗に小さなサーバーを置くのが一般的
- しかし、保守要員が必要で POS メーカーなど大手しか実現できない
- 「店舗ハードウェアの故障率」 vs 「通信と AWS の故障率」を比較
- 通信と AWS の可用性の方が高いと判断し、Web ベースのシステムを採用
- iPadの強さ
- 防水ケースと組み合わせることで、過酷な厨房環境でも高い耐久性を実現
- 軽量アーキテクチャ
- Redis 主体でディスク IO が全く発生しない。全てインメモリで動作する
人力フェールオーバー！！
Twitter でバズった「障害が起きたら麺が茹でられないのでは？」という質問に対して。
- 現在の機能の範囲であれば、タニタのキッチンタイマーで人力フェールオーバーが可能
- 実際、先日の US 障害時にシステムが落ちたが、店舗からトラブルの連絡はなかった（さすが）
- 機能が高度化すると人力では無理になる可能性も？
6. V1 の運用課題と V2 への移行
- V1 で直面した課題（2〜3 年の運用後）
- 「VPN 障害」「Airtable 障害」のどちらかが発生すると全店サービスが停止
- 券売機とのオーダー連携が未実装
- 通信障害（店舗のインターネット接続不可）時の全店停止
開発を進める中で上記課題がありましたが、時間もなく田中さん一人だけでは解決が困難な状況に直面しました。この課題を解決するため、AWS 開発パートナーであるフォージビジョン社に協力を依頼することになりました。
7. V2 の設計と改善点
- V2 の主な改善
- VPN 依存・Airtable 依存を排除
- 券売機からのオーダーをタイマー画面に直接表示
-
V2のアーキテクチャ
- 前段にALB、ECS Fargate + ElastiCache (Redis) + RDS
- 券売機オーダーは Fargate が受けて Redis に投げる
- Snowflake、Salesforce の連携で Airtable の機能を置き換え
- 一般ユーザーがマスターデータをいじれるように
-
完全サーバーレス化達成！
- プロビジョニング型リソースを使わず、Fargate と Lambda を採用
- Elasticache Redis から Valkey（Redis 互換の OSS）に移行
-
高度な機能の実現
- Amazon Bedrock を活用し、店舗に届くオーダーを並べ替えて最短調理順序で提示（未稼働、今後稼働予定）
- 一人で考えるより、エンジニアチームで考えることでより洗練されたシステムに
-
AWS SUMMIT での発表機会を得て晴れ舞台に
8. 現状と今後の野望
- 現状
- V1 から V2 へ移行中。年末に V2 全店展開を目指す
- 今後の野望
- 調理工程の拡大
- 現在は麺茹でにフォーカス中だが、他の調理工程にも展開したい
- 食券 QR コードを撮影してどの席の食券か特定
- 茹で上がり後の調理
- どのスープにどの麺を入れるかの配膳マニュアル、指示
- チャーハンや餃子も同じタイミングで出せるような時間管理
- マーケティング活用
- オーダー情報を Web やアプリと連携
- 「この店はあと 20 分で食べられる」といった待ち時間情報の提供
- オーダー情報を Web やアプリと連携
- 調理工程の拡大
9. 教訓
-
- ユーザーの現場にできるだけ近づく
- 現場の声を直接聞き、フィードバックループを回すことの重要性
-
- 楽しむ
- 楽しみながら開発したのが成功の鍵
- 楽しくなくても楽しいポイントを見つける、将来の楽しいポイントを探す
-
- 作った後、どれだけ楽をするか追求
- 作ったもののお世話は自分でやっているので、作っている時から運用を意識していた
- 開発と運用が分かれていると、次に運用する人の気持ちが分からず大変
- ユーザーのことと保守運用する人のことを考えて携わることが大事
感想
本セッションでは、山岡家という実店舗のビジネスにおいて、リアルタイム Web アプリケーションがどのように現場の課題を解決し、200 店舗規模まで成長したかが語られました。
まずラーメン店の裏側の業務を知ることができたのが面白かったです。普段飲食業界に触れる機会がないため、麺の硬さと麺の種類を掛け合わせると何種類もの組み合わせになることや、オーダーによって「こっちの鍋先にあげる！」みたいな判断が必要になるなど、厨房での複雑なオペレーションを初めて知りました。確かにこれは大変だなと思いました。
業務をシステムに落とし込んで楽にしていく過程が特に興味深かったです。システムは業務を楽にしてこそ意味があるという本質を改めて感じました。田中さんが自分で運用保守も担当しているからこそ、最初から運用を考えた設計になっていたという点も、設計構築する身として非常に学びになりました。
また、iPad などのハードウェア面での話も聞けたのが新鮮でした。普段は AWS のインフラ構築ばかりしているため、実際の店舗でどのようなデバイスが使われ、どのような制約があるのかといった現場の話は貴重でした。ソフトウェアだけでなく、ハードウェアの選定や設置場所、使い勝手まで考慮する必要があるという、システム開発の全体像が見えたセッションでした。
技術的な面白さだけでなく、ユーザーに寄り添い、運用を見据えた開発の大切さを教えてくれる、とても学びの多い面白いセッションでした。こうした実践的な話をユーザーコミュニティで直接聞けて、大変良かったです。
参考
