くら寿司、ロボティクス活用での非接触型店舗実現の歴史

群雄割拠の回転すし業界。生き残りをかけた戦いは熾烈を極める。回転すしは1958年に大阪に一号店を出店した元禄寿司がそのルーツだといわれ、その後1990年代に入るとベルトコンベアの代わりに水流で寿司を回転させ、均一100円売りを展開していたかっぱ寿司が一躍注目を集めるようになり、業界トップに躍り出た。 しかし質の高いネタと多店舗展開で収益を拡大し2011年に業界トップに躍り出たスシローは12年もの間、業界トップの座を守り続けている。 そんなスシローに猛追しているのがくら寿司だ。2021年からは外食業界がコロナで辛酸をなめる中で増収を実現している。 くら寿司は1977年に田中邦彦が大阪の堺に普通の寿司屋として創業。 87年には座席の間をすしレーンが流れていくE型レーンにボックス席を導入し、95年には本格的な回転すしチェーンを展開するため株式会社化された。 「食の戦前回帰」と「無添」を掲げ、無添加で新鮮なネタを使う一方でロボティックス化やITを活用して店内の効率化を図り、急成長してきた。入店から退店まで利用者自身がセルフで行える「非接触型店舗」をいち早く全店舗で実現したのもくら寿司だけだ。くら寿司のDX戦略とはどのようなものなのだろうか。 「当社では、DXという言葉がなかった時代から、テクノロジーの活用を積極的に進めてきております。一番わかりやすいものだと、水回収システムや時間制限管理システムなどがあげられると思います」 くら寿司の広報部マネージャー、辻明宏氏はこう語る。 水回収システムは1996年7月に導入されたもので、利用者が寿司を食べ終わると、その皿をテーブルに設置してあるお皿ポケットに投入し、すしの回転レーンの下を流れる水流で厨房の洗い場まで運ばれるという仕組みである。皿をお皿ポケットに投入する際に皿の枚数を数える仕組みもこの時考え出されたものだ。 時間制限管理システムは1997年2月に導入された仕組みで、レーンの上に流れている寿司の時間を正確に管理し、廃棄の時間になると厨房に知らせて廃棄するというものだ。 「こうした取り組みはそれぞれ店舗が抱える課題を解決するためにそれぞれ取り組んできたものです」(辻氏) 課題解決の基本は現場の声、店長の声 では新しい技術を使ってどのように課題解決を進めていったのだろうか。 「水回収システムが導入された1996年というのはまだ大阪で20店舗程度、本社も総務部ぐらいしかない小規模な会社でした。課題設定については、安全性、経費削減、品質管理を常に進めていくという観点から100円で提供するためにより質の高いものを提供するにはどうすればいいのか、という前提の中で課題を見つけています。基本は現場の声、店長からの声です。システムの導入では、実店舗に社長が行ってお客様の声なども聞いていました」(辻氏) 今でこそ、DXソリューション部が存在するが、当時はまだシステム開発を進めていくようなチームは存在しなかった。 「社長がいて、その下に総務の担当がいて、店長がいて、といったレベルでした。ただ私たちが開発したいと思っているものは、世の中にはないもの。そのためそうした取り組みに力を貸していただける業者さんを探してきて開発を進めていました」(辻氏) ではどのようにして開発は進められてきたのか。 例えば水回収システムについて見てみよう。きっかけは利用者の声だった。それまでは食べた皿はテーブルの上に高く積み上げられ、その皿の枚数を店員が数えて会計していたが、テーブルに高く積みあがる皿をほかのお客にみられるのが恥ずかしいという声が利用者の間から広がっていた。  利用者が直接皿を返却するような仕組みを採用している回転すしチェーンは現在でもくら寿司以外にはないが、これを既存のやり方を改良して進めていってもいろいろ大きな問題が発生する。 例えば、回転すしチェーンは店員が皿の枚数を数えた後、それをトレーなどで集めて客席と厨房とをつなぐベルトコンベアのようなもので洗い場に運ぶ。しかしこれを客席まで広げると、商品のにおいが客席に広がってしまう恐れがある。 「だから自分たちで、『こんなことできないか』ということを考えて、やってもらえるような業者を探して提案したのです」(辻氏) ロス率改善で収益力をアップ 1997年2月には一定時間経過した回転レーンに流れている商品を安全のために廃棄し、新鮮でおいしいネタを提供するために、お皿の裏の高台の部分に取り付けたQRタグ(現在は抗菌寿司カバーに付いている)を厨房に設置しているカメラで横から読み込み、回転レーン上の商品の時間を管理する「時間制限管理システム」を導入した。 「それまで廃棄は1時間ごとに人が目視して確認していました。1996年に堺市でO-157による集団食中毒が発生し風評被害をすごく受けたのです。人の命にかかわる問題なので『人の目に頼っていてはダメ、機械を入れ、きちんと管理しよう』という話になったのです」(辻氏) しかし管理するだけではダメ。しっかりと管理していることを利用者にも理解してもらわなければならない。 「客席から見えるところにレーンを敷いて、時間がたった皿をベルトで引き込んで廃棄しているところをお客様が一目見てわかるようにしたのが自動廃棄システム(1999年4月導入)なのです。当時は食品偽装の問題などが社会問題化し、そうした問題にも企業としての姿勢をお客様に示したいという思いもあったと思います」(辻氏) ところが時間制限管理システムで厳しい時間管理を行ったことにより、廃棄ロスが増えてしまった。そこでくら寿司ではこの問題を解決するため、1998年に「製造管理システム」を導入した。これは食品ロスの削減を目指したものだ。 製造管理システムの仕組みはこうだ。利用者の滞在時間を3段階で分け、時間の経過ごとに消費される皿数(食べる量)を予想し、係数化して表示し、厨房に設置されたパネル画面に数値として表示する。くら寿司ではこの数値を「顧客係数」と呼び、いわば「お客様のおなかのすき具合」を数値に置き換え、見える化したものだ。その係数から、レーンに流す皿数や種類を、新人からベテランまで誰が見てもわかるようにしたことで、食品ロスを軽減することができた。また、スタッフは次に行うべきことが判断しやすくなり、さまざまな無駄を省くことにもつながっている。 くら寿司 お寿司の廃棄時間を教えてくれる「時間制限管理システム」と、レーンに流すべきお寿司の種類や量が見てわかる「製造管理システム」の2つのシステムを組み合わせることで、「商品鮮度の維持」と「廃棄ロスの低減」が両立でき、「低価格で高品質」の商品提供を実現した。 この製造管理システムの導入・進化により、元々12%だった廃棄率が約6%まで減少した。 「従来は、各店舗の店長が経験や感覚でレーンに流すお寿司の種類や量を決めていましたが、人によって精度にばらつきがありました。しかし、製造管理システムの導入により、 必要なタイミングで、必要な種類、必要な量を提供できるようになり、食品ロスの削減に繋がりました。また、食品ロスの軽減だけでなく、常に鮮度のよい商品がレーンを流れるようになるなど、CSの向上にも役立っています」(広報部、岡本愛理氏)女性) ただSARSやノロウイルスなどが一般にも知られるようになった2003年にくら寿司は一つの課題を突き付けられていた。 「時間制限管理システムで菌の増殖による食中毒の問題を解決したため、それまで使っていた使い捨てのカバーはいったん廃止されました。ところが社長が、『空気中のウイルスやほこりが舞う中で、カバーもなしにすしを回転させるのは衛生上どうなんだ』と指摘し、カバーが再びつけられるようになりました」(岡本氏) そして2011年11月に導入されたのがカバーを触れずに皿の出し入れができる抗菌すしカバー『鮮度くん』だ。 しかしお皿全体を包み込むような「鮮度くん」を導入したことで、皿の高台につけられたQRタグが読めなくなり、自動廃棄もできなくなった。 そこで「鮮度くん」のカバーにQRタグをつけ、客席の前に設置したAIカメラで読み込み、厨房側に廃棄するものをブザーと独自のやり方で知らせることができる仕組みに変えた。 「こうしたシステムの導入があったからこそ、コロナ禍でも大きく売り上げを落とさずに済んだのです」(岡本氏) IT化加速のために専門部署設立 くら寿司ではIT化を加速させるために2010年ごろ、専門部署「DXソリューション部」の前身「店舗開発部システム担当」を設立した。これは独自で「鮮度くん」などを開発する一方で、外注業者とくら寿司とのつなぎ役を務めている。 「自分たちが考えたシステムを業者に委託するときに、ITに詳しい人間が間に入って交渉した方がいいのではないか、ということからこうした部署が誕生しました。ただテクノロジーの担当者は外部からの採用だけでなく、営業上がりの人間もいます。店舗のことをよくわかっていますから。しかも当時店長でもパソコンに非常に詳しい人間がいたので、そんな機械に詳しい人間が選抜されていました」(辻氏) 店舗開発部システム担当は2022年11月、DX本部DXソリューション部(人員は30人弱)に移行。DX本部長には元パナソニック出身の執行役員、中林章氏が就任した。 「それまではお客様が関わってくる部分を中心に取り組んでいましたが、今後お客様や従業員、事業基盤など全面的にDXをやっていこうということで部署名を変更しました」(岡本氏) DXソリューション部の内部ではどのようにして開発を進めているのだろうか。 「すでに世の中にあるものはそれを活用したり、外部に依頼したりしていますが、まだ世の中になく、くら寿司で必要としているものは、我々が独自で作ります。今活用しているAIカメラも部内の従業員が独自で開発しました。このAIを使ったシステム開発なども、いきなりAIありきで始まったわけではなく、課題と向き合った際に赤外線を使うかなど複数のアイデアが出てきた中で、たどり着いた手段の一つなんです」(辻氏) 赤外線を選ばなかったのは、商品が流れてくるときに、その高さによっては機能しないといた不具合があったからだという。 ロス率は6%から2%へ その後AIカメラの技術の進化とともに、2023年3月には廃棄時間の確認だけでなく各テーブルに1台(ベルトの上に設置)設置されたAIカメラはカバーが開けられたかどうかなどもチェックできるようになり、利用者が皿を取ったかどうかも分かるようになった。 くら寿司 「昨年2月ごろに迷惑動画の問題などから、AIカメラの仕組みを応用して、お寿司のカバーだけがレーン上で開閉される仕組みを察知できるようにシステム改修したので、2か月ぐらいで防犯の仕組みができました」(辻氏) 不審な皿の開閉についてはAIカメラが従業員にアラートを発信し、声がけするようにしている。皿にはすべてナンバーリングがされており、不審な開閉のあったさらはすぐにレーンから取り除く。 しかし客席へのAIカメラの導入当初は苦労したという。 「お客様から監視されているみたいでいやだという声が上がるんじゃないかといった不安はあったのですが、寿司をとる動作だけを検知するものです。お客様をずっと狙っているものではないのです。回転レーンに流れているお寿司のカバーの開閉だけをチェックしているのです」(辻氏) ところで、客席すべてにAIカメラを設置するとなると、かなりのコストがかかると考えられる。この点についてくら寿司ではどのように考えているのか。…

エンタープライズアーキテクチャにまつわる6つの大罪

企業の運営維持は決してたやすいことではありません。ソフトウェアツールの台頭により、誰にとってもワークフローの多くの部分がより高速で、よりスムーズで、より一貫性のあるものになりましたが、ソフトウェアを稼働させ続けなければならない人たちにとってはそうではありません。それは、池を滑るように進んでいくアヒルについての使い古されたセリフのようなものです。水の上はすべて穏やかに見えますが、水面下では必死に足を動かしているのです。

何気なく使っているだけのエンドユーザーやマネージャー、経営幹部にとって、エンタープライズアーキテクトの仕事は魔法のようなものです。同期化や統合化、安定化などの終わりない作業はすべてコンピューターが行い、人は最も得意とする作業に集中できます。しかし、ウェブポータルやコラボレーションスタック、レポジトリオムニツールなどの順調な実行には、果てしない課題が隠れているのです。すべての進化にとって、エンタープライズアーキテクチャは依然として、誰もが完全に把握できていない作業や責任で溢れた新しい世界なのです。

エンタープライズアーキテクトはまだ、様々なことを学び、試している段階にあります。何をすべきか、さらに重要なことは何をできないかについてさらに学んでいます。ソフトウェアスタックを実行し続け、企業全体のすべての社員のワーキングライフをできる限りシンプルにする方法を模索する過程において多くの間違いを犯してきましたし、今後も何度も間違いを犯していく可能性があります。作業が高度に技術的で複雑なことがその理由の1つですが、エンタープライズアーキテクトが犯す以下のような罪(過ち)もその原因となっています。

保存するデータが多すぎる(または少なすぎる)

ソフトウェア開発者は何でも詰め込みすぎがちです。できることなら、すべてのデータをキャッシュし、すべての事象をログし、企業の限りない進化に関わるバックアップコピーを保管するでしょうが、これらのギガバイトやメタバイトはどんどん多くなっていってしまいます。一部のクラウドベンダーが提供する低コストのコールドストレージでも、データが大量になればコストは高額になります。

さらに困ったことには、データレイクがいっぱいになるにつれて、適切なビットを見つけるのがさらに困難になっていきます。「レイダース/失われたアーク《聖櫃》」の終盤に出てくる聖櫃と同じです。技術的にはすべての情報はそこにありますが、それを見つけることができるのでしょうか。

問題は、保持する情報が少なすぎると、それ自体による不具合やペインポイントが伴ってしまいます。規制が許す限り、すべてを破壊するデータ保持ポリシーを設定しようした企業もあります。しかしそうすると、あらゆる質問への回答を探そうにも、「ファイルが存在しない」という記憶喪失のような状態になってしまいます。誰も何もわからなくなってしまうのです。

正確なバランスを見つけることは不可能かもしれません。私たちにできることはただ、暗闇の中を手探りで電気のスイッチを捜すような事態を避けるために、適切な情報を簡単にアクセスできる構造で保管して、優れたデータストレージアーキテクチャを見つけることです。

1つのプラットフォームに依存しすぎる(または多数を採用しすぎる)

エンタープライズソフトウェアの最もシンプルな構築方法は、外部企業が構築した様々なツールやポータル、プラットフォームのの力を活用することです。作業の90%以上は、発注書にサインして少しだけグルーコードを書けば完了します。

しかし、企業の主要部分の構築に外部企業を頼ることには多くのリスクが伴います。非公開投資会社の中には、外部企業を買収して優秀な社員をすべて解雇し、相手が逃げられないとわかっていて価格を吊り上げるところもあるかもしれません。1つのプラットフォームですべてをインスタンス化することが急にひどくまずいことになり始めます。1つのプラットフォーム、単一のインターフェイスからくるシンプルさと一貫性をもう誰も覚えていないのです。

複数のプラットフォームを採用することもまた、同じぐらいに苦痛が伴います。ツールは相互運用でき、業界標準プロトコルに沿っているとセールスチームは約束するかもしれませんが、それだけではまだ到底十分ではありません。各プラットフォームがデータをSQLデータベータに保管していても、MySQLを使うものもあれば、PostgreSQLやOracleを使うものもあります。

正解は簡単には出ないのです。プラットフォームが多すぎるとバベルの塔のように実現不可能な計画になってしまいます。少なすぎるとベンダーロックインのリスクにつながり、契約更新のメールを開く際の諸々の苦痛が伴います。すべての開発を社内で実行することにかかるコストはまた別の問題です。

クラウドへのアウトソーシングが多すぎる(または少なすぎる)

クラウドによってエンタープライズアーキテクトの作業はかなり楽になりました。特定サイズのマシンが必要であれば、数分で利用できるようになります。発注書を作成する必要もなく、ラックスペースを探す必要もありません。クラウド企業にクレジットカードの番号を渡すだけで、他には何もする必要がないのです。

どんなマシンでも数分または数秒で利用できるメリットは確かに明らかですが、最大の欠点はそれにかかるコストです。クラウドコンピューティングは、社内での管理に比べて驚くほど高額です。そのコストは予想以上に高額なことが多いため、多くのCFOが毎月びくびくしながらクラウドの請求書を確認しています。

しかし自社で管理すると、スタッフやデータセンタなどを管理し、そのコストを払うことになります。それに伴う悩みや準拠すべき規制リストは延々と続き、低コストはつかの間の喜びになってしまいます。

エンタープライズアーキテクトの中にはクラウドで大きな成功を収めるものもいます。毎週、毎月、毎年のわずかな時間に需要が急増するのであれば、その負荷に対処するために数分または数時間サーバーを起動するだけで、社内で何かするより格段に安価になります。他の企業は皆、クラウドへの投資が多すぎたのか少なすぎたのか悩むことになります。

フレームワークを狂信的に受け入れる(または無視する)

現在のエンタープライズスタックの複雑さに伴い、優れたアーキテクトの中にはそれらを整理するのに役立つフレームワークを構築した人もいます。例えばOpen Group Architecture Format (TOGAF)。企業が必要とするほとんどすべてのもを構築する戦略的フレームワークです。TOGAFは、アーキテクチャ開発手法(ADM)やアーキテクチャ・コンプライアンス・フレームワーク(ACF)など、多数のガイドランやベストプラクティスを提供しています。その他、Zachmanフレームワークや連邦エンタープライズアーキテクチャなどのアプローチには、スタック構築において独自の規則や規制があります。

最も大きなメリットは一貫性かもしれません。スタッフ全員がテクニックや理論に慣れてれば、ソフトウェアを使いこなすのが容易になります。データやコードは(通常)構成されており、すべて予想できる場所に収まっています。

しかし人によっては多少行きすぎることもあります。ルールを採用するだけにとどまらず、狂信してしまうのです。スペックを徹底して読み、必ずルールに従って意思決定をしなければならなくなります。道から外れる者は災いなるかな。

全員がフレームワークを狂信し、オフィスの計画会議が喜んでルールに従う人たちで埋め尽くされていたとしても、別の問題が生まれることもあります。完璧なオープンソースコードであっても、自分たちが求めるアーキテクチャフレームワークに適合しないという理由だけでチームが拒否したり、ベンダーが優れたオプションを提供しても、適切な方向性のもとに開発されたものではないという理由だけで拒否してしまうこともあります。

何よりも方法論を遵守

フレームワークは構造を提供してくれますが、ずさんな行為や怠惰な行為、時には悪意のある行為の隠れ蓑になってしまうこともあります。チームの誰かが適切なTOGAFフォームに記入するのを待っているため、決定を長引かせてしまうこともあるかもしれません。改善を支援するルールと閉塞的な煩雑な手続きの違いは紙一重です。

以前一緒に仕事をしたある男性はアジャイル方法論の信者でそれをこじらせてしまったため、チームはアジャイルとは言えないもにになってしまいました。彼はミーティングでの儀式をすべて心得ており、先週書かれたばかりのコードをリファクタリングするために、数多くのストーリーポイントを「スプリント」に詰め込むのが得意でした。チームは、彼が納品することになっていたクレジットカードのチェックアウト方式の再構築においてそれほど速く動いているようには見えなかったのですが、各スプリントで獲得したアジャイルポイントのグラフを見るとオフィス内で最速に作業が進んでいるように見えました。

開発ワークフローを整理するためのなんらかの方法が必要です。プログラマーは、アジャイルかウォーターフォールかについて何日も延々と議論することができます。週末に1人だけで完了できない規模のプロジェクトであれば、なんらかの戦略が必要です。

目に見えるもの以上に方法論を信じるようになると問題が起こります。そうなると、賢いコーダーは、自分のコードがたいしたことをしなくてもシステムを操作して大きな成果を出してしまいます。

トレンドを追う(または無視する)

開発者は、エンタープライズアーキテクチャのための最新のアイディアやモデルに飛びつくのが大好きです。時には運よく新しいトレンドが彼らのニーズに合うこともあります。開発者のアプリケーションが、トレンドセッターが最初にそのアイディアを思い付くきっかけとなった良い例です。

しかしほとんどの場合、部分的にした当てはりません。ユースケースはトレンドに発想を与えたアプリケーションに似ているかもしれませんが、少々ごまかした後でのことです。一方、開発チームはそのコードをトレンドに合わせるために必死になっています。時には、完全に適合したコードの膨大なブロックが、以前流行っていた目標に合わせて書かれたというだけで破棄されてしまうこともあります。

ここで問題になるのは、流行を完全に無視することも命取りになるということです。確かに、ありがたいことに、コードは適切に機能するデータベースやフォーマット、コーディング標準、プロトコルを使い、当初のバージョンに忠実であり続けています。しかし、全世界が何らかのトレンドを追いかけたとしたら、すべてのベンダーやツールメーカー、将来の新入社員もそうしたことになります。トレンドや流行はある時点で標準となり、時にはもっとひどい場合は法的にコンプライアンスが義務付けられた要件となってしまいます。

エンタープライズアーキテクトに勝ち目はないということです。トレンドを追うと大衆が生み出す流行の奴隷になってしまい、トレンドを無視すると取り残されてしまいます。EAにできることは、トレンドを把握すべき組織の技術スタックやIT担当者のために、やるべき正しいことを慎重に行うしかないのです。

Enterprise Architecture


Read More from This Article: エンタープライズアーキテクチャにまつわる6つの大罪
Source: News

How to power intelligent enterprises with SAP on Microsoft Cloud

TCS’ strategic, decade-long partnership with Microsoft has helped enterprises migrate their on-premises SAP workloads to the cloud for native integrations, unmatched security, compliance, automation, and better data insights. ​ With SAP on Microsoft Cloud, enterprises can unlock the potential of machine learning, advanced analytics, and automation. Many CIOs have made the move as a catalyst…

Digital transformation’s fundamental change management mistake

Over the past decade, CIOs have invested significantly in digital transformation initiatives in an effort to improve customer experiences, build data analytics capabilities, and deliver productivity enhancements with automation. Underpinning these initiatives is a slew of technology capabilities and strategies aimed at accelerating delivery cycles, such as establishing product management disciplines, building cloud architectures, developing…