厨房君 開発ストーリー 厨房君 開発ストーリー
最初は、なんとなくやっていた業務でした。 「これって本当に効率的なんだろうか?」 気づけば、毎日の作業が属人化し、感覚に頼った判断が当たり前になっていた。 でも、もっと良くできる方法があるはず――そう思ったのが、『厨房君』開発の最初の一歩です。
「なんとなく始まった仕事」に違和感を覚えた頃
「なんとなく始まった仕事」
に違和感を覚えた頃
大学卒業後、あるきっかけで父と一緒にリサイクルショップを始めることになりました。 始めた頃は、ありとあらゆるジャンルの商品を扱っていて、まさに “なんでも屋さん”。 ノンジャンルで物を売る楽しさや、お客さんとのやりとりの面白さも感じていましたが、でもどこかで、 「これは趣味の延長線みたいな仕事だな」という感覚もあったんです。
どうせやるなら、ちゃんと専門性を持って、「この分野なら誰にも負けない」と言えるような武器を持ちたい。 そう思うようになってから、少しずつ業務用の厨房機器が増え始め、 気づけば中古厨房機器専門のショップへと自然にシフトしていきました。 スタッフも増え、取り扱い商品も増えていく中で、 やがて “仕組み” の必要性と、“継続性のある強さ” を追求するようになっていきます。
これって… 自分がやり続ける仕事?
これって…
自分がやり続ける仕事?
日々の業務の中で、ふと立ち止まる瞬間がありました。 「これって、自分がやり続ける仕事なんかな?」と。 たとえば、厨房機器の中古品の値段を決める作業。 その頃、店舗の責任者として働いていたので、値決めは大事な仕事のひとつです。 最初はそれが「仕事」だと思ってました。 でも、ふと我に返ると、これってずっと自分が抱えてる状態でええんかな?という違和感が生まれたんです。 もちろん、任せたい気持ちはありました。 でも、「じゃあどうやって任せたらいいのか?」が難しい。
つきっきりで教える形では、継続的な運用が難しい。 教える側の負担も大きいし、受け取る側の理解にも差が出てしまう。 そこで考えたのが、 「仕組みで安心して任せられる状態をつくろう」ということでした。 仕組み化すれば、教える側も教わる側もラクになる。 仕事の精度もブレにくくなる。 そしてなにより、「自分じゃなくても回る状態」「自分が次の仕事ができる状態」こそが、会社にとって必要なんだと。 ここが、“厨房君” に続くポイントだったと思います。
Accessを猛勉強して 業務に落とし込む
Accessを猛勉強して
業務に落とし込む
業務の仕組み化を本気で進める中で、私はあるソフトにチャレンジすることになります。
多くの人が挫折すると言われるデータベースソフト、Microsoft Accessです。
「Excelのマクロを組む」レベルの話ではありません。
Accessは、
“データを見せるためにどう入力し、どう蓄積し、どう出力するか” という、
情報そのものを構築していくソフト。
当時は「ACCESS使えます!」という人材は貴重で重宝されていたと思います。
入力フォームをつくり、テーブルにデータを書き込み、
クエリを使って処理・抽出・分析をかけたうえで、また別のフォームに表示させる。
Excelが「表計算ツール」だとしたら、
Accessは “頭の中のアイデアを、動くしくみに変えるプラットフォーム” です。
これを使いこなすことができれば、
“こうだったらいいのに” という思いつきを、自分の手でシステムに実装できる。
そう確信して独学で学び始めました。
最初は入門書から。 ひとつ理解するたびに、業務システムに組み込んで実践。 仕事の合間をぬっては改善し、次の知識を手に入れてはまた更新。 まさに、“構築 → 実践 → 気づき → 改善” の粘り強いPDCAの繰り返し。 そして何より、楽しかったんです。 思いついたことを形にできるワクワク。 作った仕組みがスタッフの業務を効率化していく手応え。
Accessというソフトが “難しい” と感じることはあまりありませんでした。 むしろ、モチベーションが勝ちすぎて、 多くの人が挫折する壁をスキップするように越えていたと思います。

Accessは、それだけでほとんどのことが実現できる優れたソフトです。 でも中には、Accessの標準機能だけでは難しい処理もあります。 そういう場面では、 「VBA(Visual Basic for Applications)」というプログラミング言語を使って、 動きをカスタマイズする必要があります。 当然、その領域にも踏み込みました。
最初はエラーの連発。調べてもよくわからないコードばかり。 それでも少しずつ動かせるようになっていくのが面白くて、 「こんなことまでできるのか!」という驚きと快感が、 学び続けるモチベーションになっていました。

やりたいことは全部 Accessに詰め込んだ
やりたいことは全部
Accessに詰め込んだ
Accessの中で、僕は次々と業務の仕組み化を進めていきました。 販売管理システム、売上管理システム、在庫管理システム、発注管理システム、 さらにはキャッシュフロー管理システムまで── あらゆる業務をAccessの中で “回る仕組み” として構築していきました。
もちろん、Accessに取り組むきっかけになった「値決めの仕組み」も、しっかり実現できました。 操作はとてもシンプルです。
① 型式を入力
② 年式を選択
③ 商品ランクを選択
この3ステップを踏むと、 システムが参考販売価格を自動で提示してくれる仕組みです。

…と、書けば簡単に見えますが、 それを実現するためには、価格データの蓄積、ジャンルごとの計算式設計、 さらにはカタログ情報の入力を地道に続けるスタッフの協力が不可欠でした。 正直、当時の会社規模を考えると、 「ウチの規模で、ここまでやる?」って声があってもおかしくないレベルだったと思います。(実際あったかも…)
でも私にとっては、 “こうしたい” と思ったことを、Accessで実装して、 実際に現場で使えるようにすることが、 もはや趣味とかやりがいのレベルを超えた “使命感” だったように思います。
気づけば、 「考えたことは、Accessで実装して現場で運用する」という、“理想的な仕事の流れ” が完成していました。 ただ—— そんな快適な環境にも、想定していなかったことが起こります。
思わぬ落とし穴
Accessによる仕組み化で、業務はかなりスムーズに回るようになりました。 販売・在庫・値決め・売上管理まで、すべてが仕組化されて、現場の負担も軽減。
ただ—— そこには思わぬ落とし穴がありました。 Accessを作り込めば作り込むほど、 そのシステムに不具合が起きたとき、対応できるのが自分しかいない状態になっていたんです。 属人化からの脱却を目指した開発が、開発の部分においては完全に属人化された状態にハマってしまいました。
当時、社内にはAccessを簡単に修正できるスタッフもいました。 でも、組み込んだVBAのコードや、複雑に絡んだクエリ・フォーム間の処理については、 深いところまで理解しているのが私だけという状況でした。 軽微な修正で済むこともあれば スタッフの「これ、なんかエラー出てるんですけど…」の一言で、 業務を止めて対応に入らないといけない場面も出てきます。
もちろん頻繁に起こることではありません。 でも、自分の本業の業務とシステム保守の両方を背負うストレスは、想像以上にじわじわ効いてきました。 対応が難しい場合は、 現開発パートナーのSEさんにお願いして修正してもらうこともありました。 Accessで “仕組みをつくる” というチャレンジは大成功だった。 けれどその反面、 「回る仕組みが、自分に依存しすぎていた」という事実に、だんだんと気づき始めたんです。

この仕組み… 未来には進めなかった
この仕組み…
未来には進めなかった
そんなAccessによる運用は、数年間にわたって続きました。 仕組みがどんどん便利になっていくにつれて、現場からも 「これってできませんか?」 「こんな項目も表示できたら助かるんですけど」 という要望が日常的に上がってくるようになりました。
その都度できる範囲で改修を加え、 時には現開発パートナーのSEさんに依頼して実装してもらうことも増えていきました。 でも、あるとき決定的な問題が見えてきたんです。 それは、 Accessというソフト自体が “WindowsのOSに依存している” ということ。
OSがアップデートされれば、動作保証がされなくなったり、 思わぬ不具合が起こるリスクがあります。 さらに当時、新しいAccessがリリースされたのですが、 それまで使っていたバージョンとの互換性がないという衝撃の事実。 このとき私たちには、2つの選択肢しかありませんでした。
① 古いOSと古いAccessで、そのまま運用し続ける
② 新しいAccessの仕様に合わせて、システムをゼロから作り直す
でも、Accessで組み上げた仕組みは複雑に絡み合っていて、 何年もかけて構築してきたものを “ゼロから” なんて、現実的に不可能に近かった。 その結果、「古いままでいく」という選択をする以外になかったのです。
Accessの次に選んだのは また「ゼロからつくる」だった
Accessの次に選んだのは
また「ゼロからつくる」だった
でも古いAccessを使い続けるというのは、問題の先延ばしにすぎず限界があります。このまま使い続けるわけにはいかない。 そう頭ではわかっていながら、踏み出すには勇気のいる話でした。 でも、いつかは必ず決断しなければならない。 そのときが来たのだと思います。
これからのシステムには、 OSに依存せず、いつでもどこでも使える柔軟さと安定性が必要。 その答えは、どう考えても “クラウドシステム” でした。 クラウド化のメリットは明確でした。
端末や場所にとらわれない運用。
データの一元管理。
アップデートのしやすさ。
そして、なにより未来の変化に耐えうる土台になるということ。 これまでAccessのカスタマイズで力を貸してくれていた 現開発パートナーのSEさんに、 正式にクラウド版システムの構築を依頼しました。
ただ、当然のことながら、これは数年単位に及ぶ大きなプロジェクトになります。 でも、私としてはなるべく短期間で使える状態に持っていきたかった。 そのためには、開発側とこちら側で いかに完成イメージを共有できるかがカギになります。
そこでたどり着いたのが、 “Accessで構築した旧システムの全画面資料を共有する” というスタイルでした。 Access時代に作り上げたすべてのフォーム画面を資料化し、 そこに機能の詳細・処理内容・仕様などを細かく書き込んでいく。

資料は2部作成し、常に開発側と同じものを持つことで、 打ち合わせのたびに “同じ絵を見て、同じことを考える” という状況をつくったんです。
「変更があれば、資料に追記して送る」
「打ち合わせは、常にその資料ベースで進める」
このスタイルは、その後クラウドシステムが完成したあとも、 当社の開発チームの文化として、形を変えて残り続けています。 こうして、Accessからクラウドへ。 数年にわたる再構築プロジェクトは、ようやく実用段階にたどり着くことができました。

一般的な開発スタイルとは 全く違うアプローチ
一般的な開発スタイルとは
全く違うアプローチ
いわゆる “システム開発” と呼ばれる仕事の多くは、 発注側と開発側がしっかり分かれていて、 「こういう機能をつけてください」というオーダーを出して、 それをプログラマーが実装していく、という流れが一般的です。
でも『厨房君』の開発は、まったく違います。 私自身が、現場を誰よりも理解していて、 「何が必要か」だけでなく、 「どう動いてほしいか」「どんなUI(ユーザーインターフェース)なら使いやすいか」まで全部設計していたんです。 「こういう機能がほしい」ではなく、 「こういう動きにして、こういう結果が出るようにして、 そこにこういう命令文が出て…」 というところまで、Access時代の構築経験を活かしながら、 細部まで言語化して共有していきました。
開発パートナーであるSEさんも、 単に “言われた通りに作る” のではなく、 「どうすればそれをもっとシンプルに実装できるか?」を一緒に考えてくれる存在でした。
指示ではなく、共創。
要望ではなく、設計。
それが、厨房君の開発スタイルです。 そしてもうひとつ。 このスタイルが成り立ったのは、 そこに “現場のリアル” があったからです。 現場で何が起きているのか。どこで詰まるのか。 どこでミスが起きやすいのか。どこで手間がかかっているのか。
それをすべて肌で感じながら、 「本当に役立つシステムってなんやろう?」を考え続けたからこそ、 ここまでの仕組みが作れたのだと思います。
ちょっと変な名前 でも… それがいい
ちょっと変な名前
でも… それがいい
『厨房君』という名前は、実は比較的最近になってつけたものです。 それまでは、『RUBS(ラブズ)』という名称で社内では呼ばれていました。 これは「RISE UP BACKBONE SYSTEM」の略称で、 社名にちなんでつけた “ライズアップ基幹システム” という意味です。
当時からすでに、FC加盟している会社でもこのRUBSを活用していました。 ただ、社名由来の名称だと、 他社にとってはちょっと距離を感じるのではないか? そんなふうに感じるようになったんです。
そこで、「もっとわかりやすく、親しみやすい名前を」と考えて、 生まれたのが『厨房君』でした。 ちょっと驚かれることもあります。 「直球すぎる名前ですね!」って(笑)。
でも、あえて “柔らかく、親しみのある名前” にしたかったんです。 固い名前よりも、スタッフが日常的に使いやすく、
「厨房君に入力といて!」
「厨房君で確認してみて!」
と、自然と社内で飛び交う共通のことばになるようなもの。 実は、このネーミングに確信を持てたのには、知人の会社の影響でもあります。 その会社では、歯科技工士向けの業務ソフトを開発・販売していて、 全国シェアはなんと7割! そのソフトの名前が、『いればくん』。 初めて聞いたときは、「ホントに??」と驚きましたが、よくよく考えてみると、 それがめちゃくちゃわかりやすくて、技工士さんたちが親しみを感じて使いたくなるのも納得でした。
だからこそ、『厨房君』。
誰にでも伝わって、覚えてもらえる。 そして、現場で “自分たちの相棒” のように感じてもらえる。 そんな存在になってほしいという願いを込めています。
また、名前だけでなく、構想そのものも当初から “未来の使い方” を意識していました。 こうした設計思想を初期段階から取り入れていたのは、 “厨房君は自社だけのシステムでは終わらせない” というビジョンがあったからです。 そしてそのビジョンは、のちに大きな進化のフェーズを迎えることになります。
電子棚札(ESL)との連携で 新たなフェーズへ
電子棚札(ESL)との連携で
新たなフェーズへ
厨房君の開発も一旦落着き、日々の業務がスムーズに回るようになっていた頃、 私たちはある大きな現場の課題にぶつかっていました。 それは、「紙の値札」問題。 在庫商品には値札を貼っていましたが、価格変更や情報修正があるたびに、 その値札を貼り替える必要があったんです。

しかも、「貼り替えが間に合っていない」「修正を手書きで対応したまま放置される」。 …そんな小さなズレが、いつの間にか在庫管理自体の信頼性を揺るがしていました。 そこで導入の検討を始めたのが、電子棚札(ESL)でした。 一般的には大手のスーパーマーケットや家電量販店などで導入されているもので、 中小企業やましてや中古厨房機器業界では前例がない取り組みでした。
でも、私たちにはESLの制御を可能にしてくれるポテンシャルをもった厨房君があります。 このシステムとESLを “シームレスに連携” させることができれば、 在庫・状態・価格などの情報の更新内容をリアルタイムで現場に反映し在庫データとの整合性を保つことができると考えたんです。 開発はもちろん一筋縄ではいきませんでした。 ESLは単体で機能するものではなく、 制御システムやクラウド、アクセスポイントとの連携が必要です。 しかも業界に特化した仕様にするには、 ESLメーカーが用意している汎用の制御ソフトでは不可能でした。
「本当にやるのか?」という根本的な問い、それはこれまでの仕事の中でも最大級の覚悟を決める必要がありました。そんな問いを自分に投げかけながらも、 厨房君との連携こそが、大きなDXの前進につながるという確信がありました。 そこから慎重に仕様の検討と設計を重ね、構想から3年という時間をかけて厨房君とESL連携がついに実現しました。


その結果、システム上の在庫と実在庫の整合性が保たれた環境が整いました。 在庫状況の確認に電話や人手を使うこともなくなり、「人が動かなくても情報が回る」仕組みが完成しました。

さらに、この仕組みによって、 倉庫が “無人” でも運用できるようになったこと、 在庫の見える化によって中古品を見積りに組込みやすくなり、利益率が向上したこと など、導入効果は会社全体に広がっていきました。
厨房君とESLの連携は、まさに現場DXの完成形に近づいた瞬間だったと言えます。
それでも厨房君は “完成” ではなく “進化中”
それでも厨房君は
“完成” ではなく “進化中”
はじめは、ただの小さな疑問でした。 それが改善となり、やがて仕組みになり、いまでは多くの現場を支える存在になっています。 『厨房君』は、そんなふうに、現場から少しずつ広がっていった、 そしてこれからも育っていくデザインです。
私たちが厨房君を使って業務を仕組み化してきたのは、 自社の効率化だけが目的ではありません。
中古厨房機器業界には、「厨房一式をまかせられる相手がいない」という悩みを持ったお客様が多くいます。 厨房づくりには本来、図面作成・現地打ち合わせ・仕様確認など、幅広い業務が必要です。 ところが、そうした業務は手間がかかる割に利益に直結しにくいため、対応できる会社がほとんどありません。 中古品を扱うショップの多くは、単に商品を売ることにとどまり、“一式対応”を実現できていないのが現実です。
私たちは、そうした業界の構造を変えるべく、中古品であっても“一式案件”を本来の意味で引き受けられる存在を目指してきました。
仕事には、「人がやるべきこと」と「機械に任せるべきこと」があります。 その線引きができていない会社では、本来システムで処理できることまで人が抱えることになり、現場の負担がどんどん増えていきます。
厨房君は、そうした「機械でできることは仕組みに任せ、人は本来向き合うべき仕事に集中できる環境」を整えるインフラです。 そして今も現場の声を取り入れながら、私たちと一緒に進化を続けています。
