そこまでやる？”が　自分の普通だった “そこまでやる？”が
自分の普通だった

“結果は想いの総量” これが、私の座右の銘です。

思い返せば、小学生の頃から「やる」と決めたら止まらない性格でした。きっかけは、父と一緒に行った散髪屋さん。待ち時間に読んだ『北斗の拳』で、ムキムキのケンシロウが服を破って登場するシーンを見て、

「うわ、すげぇ！」……では終わらなかったんです。
「僕もケンシロウになりたい！」と、即座にスイッチが入りました。

学校から帰ると、毎日鉄アレーで筋トレ。気づけば小学6年生のときには、クラスで “ムキムキ＝高見” と呼ばれるほどになっていました。

「本気で続けたら、憧れに近づける」
この感覚を、小学生のうちに手に入れられたことは、自分にとって大きな体験でした。

それから中学時代に、自分の “底” を知った出来事があります。

ある日、返ってきた数学のテストは12点。
そして、当時 “勉強が苦手” で有名だったクラスメイトが15点を取っていた。

周りの男子たちが、冗談半分にからかっているのを見て、心の中で思いました。

「これはさすがにまずい……！」

その日すぐに「塾に行かせてほしい！」と親に頼み込み、猛勉強することを決意。
成績は急上昇し、数学はむしろ得意科目に。気づけば成績上位に食い込んでいました。

高校では数学・英語ともにAクラスからスタート。
でも、部活に熱中しすぎてB → Cクラスへと転落。

それでも、不思議と「本気になったらいつでも戻せる」という感覚があって、焦りはなかったんです。
結果、そこからV字回復。

大学では、陸上競技のハンマー投げでスポーツ推薦入学。

ハンマー投げの選手は、基本的に体格の大きな選手が多く、私のような体格の小さい選手は明らかに不利でした。
でも、「だから無理」とは思いませんでした。

どうすれば結果を残せるか？ その一点にフォーカスして、フォームの見直し・筋トレ・メンタルまで、
とにかく自分なりのPDCAをぐるぐる回して、可能性を磨き続けました。

結果、全国レベルとはいかないまでも、“そこそこ” の結果は残せたと思っています。
……いや、柔道みたいに体重別のクラスがあったら、きっとその階級で日本一だったと思ってます（笑）

そうやって、自分の限界を勝手に決めない思考、諦めない精神は、大人になるまでにしっかり染みついた気がします。

「なんとなく始まった仕事」に違和感を覚えた頃 「なんとなく始まった仕事」
に違和感を覚えた頃

大学卒業後、海外留学を経て日本に戻ったあと、ひょんなきっかけから、父と一緒にリサイクルショップを始めることになりました。

最初は、ありとあらゆるジャンルの商品を扱っていて、まさに “なんでも屋さん”。
ノンジャンルで物を売る楽しさや、お客さんとのやりとりの面白さも感じていましたが、でもどこかで、
「これは趣味の延長線みたいな仕事だな」という感覚もあったんです。

どうせやるなら、ちゃんと専門性を持って、
「この分野なら誰にも負けない」と言えるような武器を持ちたい。

そう思うようになってから、少しずつ業務用の厨房機器が増え始め、
気づけば中古厨房機器専門のショップへと自然にシフトしていきました。

スタッフも増え、取り扱い商品も増えていく中で、
やがて “仕組み” の必要性と、“継続性のある強さ” を追求するようになっていきます。

これって…　自分がやり続ける仕事？ これって…
自分がやり続ける仕事？

日々の業務の中で、ふと立ち止まる瞬間がありました。
「これって、自分がやり続ける仕事なんかな？」と。

たとえば、厨房機器の中古品の値段を決める作業。
その頃、店舗の責任者として働いていたので、値決めは大事な仕事のひとつです。

最初はそれが「仕事」だと思ってました。
でも、ふと我に返ると、これってずっと自分が抱えてる状態でええんかな？という違和感が生まれたんです。

もちろん、任せたい気持ちはありました。
でも、「じゃあどうやって任せたらいいのか？」が難しい。

つきっきりで教える形では、継続的な運用が難しい。 教える側の負担も大きいし、受け取る側の理解にも差が出てしまう。

そこで考えたのが、
「仕組みで任せられる状態をつくろう」ということでした。

仕組み化すれば、教える側も教わる側もラクになる。
仕事の精度もブレにくくなる。

そしてなにより、「自分じゃなくても回る状態」こそが、会社の未来にとって必要なんだと。

ここが、“厨房君” に続くポイントだったと思います。

Accessを猛勉強して　業務に落とし込む Accessを猛勉強して
業務に落とし込む

業務の仕組み化を本気で進める中で、私はあるソフトにチャレンジすることになります。

多くの人が挫折すると言われるデータベースソフト、Microsoft Accessです。

「Excelのマクロを組む」レベルの話ではありません。

Accessは、
“データを見せるためにどう入力し、どう蓄積し、どう出力するか” という、
情報そのものを構築していくソフト。

当時は「ACCESS使えます！」という人材は貴重で重宝されていたと思います。

入力フォームをつくり、テーブルにデータを書き込み、
クエリを使って処理・抽出・分析をかけたうえで、また別のフォームに表示させる。

Excelが「表計算ツール」だとしたら、
Accessは “頭の中のアイデアを、動くしくみに変えるプラットフォーム” です。

これを使いこなすことができれば、
“こうだったらいいのに” という思いつきを、自分の手でシステムに実装できる。

そう確信して、私は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に情報が反映されます。このESLを商品に貼付けて運用が始まります。
画面表示は整備中の状態では「整備モード」、整備が完了すると「店頭在庫モード」に自動で切り替わります。

さらにどちらのモードでも商談中になれば「商談中」、
売約が確定すれば「売約済」の表示に切り替わります。

すべての表示が厨房君のデータベースとリアルタイムで同期しています。

その結果、
在庫状況の確認に電話や人手を使うこともなくなり、
「人が動かなくても情報が回る」仕組みが完成しました。

さらに、この仕組みによって、

・倉庫が “無人” でも運用できるようになったこと
・在庫の見える化によって中古品を見積りに組込みやすくなり、利益率が向上したこと

など、導入効果は会社全体に広がっていきました。

厨房君とESLの連携は、まさに現場DXの完成形に近づいた瞬間だったと言えます。

それでも厨房君は　“完成” ではなく “進化中” それでも厨房君は
“完成” ではなく “進化中”

厨房君という仕組みができあがり、
業務フローは大きく変わりました。

さらに、ESLとの連携によって
在庫データと店舗や倉庫の商品情報の表示がシームレスにつながる仕組みも実現。

社内では、
「厨房君」という共通言語が飛び交い、
業務の精度もスピードも、一段階も二段階も上がりました。

でも私は、これで “完成” とは思っていません。

厨房君は、
現場で働くスタッフたちの声、
新たに出てくる課題、
そしてお客様の変化に合わせて、

これからも “進化し続ける仕組み” であるべきだと考えています。

それは、
「仕組みは、止まった瞬間にズレていく」から。

厨房君は、現場から生まれた仕組みです。

だからこそ、現場とともに進化していく。
それが一番自然で、強いかたちだと思うんです。

厨房君はまだまだ進化できる。構想はまだあります。

そしてまた数年後、きっと新しい “厨房君ストーリー” が生まれているはずです。