近所の美味しいラーメン屋の紹介、或いはダイナミクスで人を感動させるということ

はじめに

どうも、ARCHチームの野呂です。 今日は（前回の記事の後編を書かずに！）近所の美味しいラーメン屋について書かせていただきます。

名古屋市千種区にある「太陽」というチャーシューメン専門店なんですけれども。

世間の流行とはちょっと違うのかもですが、近所の人々から愛されていて、昼過ぎにはいつも完売している感じのラーメン屋です。

別に店主から聞いたわけではないので以下の文章は半分くらい妄想＆ただの感想なんですが、しかし自分の感じている魅力を文章にしてお届けしたいと思っております。

特徴と美味しい食べ方と

まず、スープがあっさりしているというところが特徴です。 それ単体で味わうと少し物足りないくらいの、今どき珍しい薄味。 麺をすすってもやっぱり少し薄味すぎるくらいの感じで、でも出汁が効いていて旨みは十分にあります。

何口か食べて、その味に慣れてきた頃にチャーシューを少しだけ食べると、実はチャーシューにはしっかりと味がついていて、スープよりも味が濃くてはっとするんですよね。さすがチャーシュー麺専門店、チャーシューが美味しい！

また何口か麺を食べて、口の中を落ち着かせてから、チャーシューと麺を一緒に口に運びます。
そのあとは、つけ麺のごとく、毎回チャーシューを少しだけ麺に絡めて食べるわけです。
あっさり目で出汁の効いたスープと麺、チャーシューについた味、そして肉本来の旨みが口の中で融合して最高です。
一番安い「松」ですら、大きめのチャーシューが3枚入っているので、それを少しずつ麺に絡めて食べても全然最後まで食べ切れる量あるので、安心してください。
楽しむコツは、少しずつチャーシューの割合を増やしていくこと。
最後の一口はチャーシューと麺が1：1くらいになるようにすると満足度が高いのでおすすめです！

麺とチャーシューを食べ終わったら、水を一口飲んでから、レンゲを使ってスープを飲む。

すると、最初物足りなく感じていたスープの味が、何故か信じられないくらい美味しくなっているんです！！！！
この、食べ終わった後に感じる感動、満足感。
最初の一口目の「少し物足りないかな？」という気持ちが裏返ったかのようです。

何に感動しているか？

このラーメンの何に感動しているかを自分なりに考察してみました。

スープとチャーシューの対比

スープがあっさりしていて、最初は少し薄く感じる。
その控えめな始まりが、後の「濃さ」の対比を際立たせている（気がする）。
結果、スープが地、チャーシューが図になる。

スープとチャーシューの味の融合

スープの「旨み」とチャーシューの「濃さ」が一体になり、 食べ進めるごとに「物足りなさ」が「ちょうど良さ」に、「ちょうど良さ」が「最高」になっていく。

最後に最初の味を思い返す

食後に飲むスープで、最初の淡い味が再び現れ、今度は「物足りなさ」ではなく「完成された味」として感じられる。
この“最初と最後がつながる”構造、遠くまで運ばれてきた末に、一番最初の一口を思い出す体験が、無意識に「旅の終わりのような感動」を呼び起こしているのだ、と僕は考えます。

是非皆様もこの感動を味わいに、名古屋の「太陽」に足を運んでみてくださいネ！

ここはテックブログ

「遠くまで運ばれてきた末に一番最初を思い出す体験が、無意識に『旅の終わりのような感動』を呼び起こす」というのは人類にとって「普遍的な感動を呼び起こす構成」だと思っています。
普遍的な構成、という抽象的なものを表現するための機構であるTypeScriptのTypeをテックブログらしく（？）使って整理してみます。

/**
 * 各セクションのテーマと主張を表す
 */
type Section = {
    theme: string;
    claim: string;
}

/**
 * 物語の各パートを語るための抽象メソッド
 */
type Teller = {

    /**
     * Aパートを語る
     */
    tellASection: (aSection: Section) => string;

    /**
     * Bパートを語る
     */
    tellBSection: (bSection: Section, aSectionContent: string) => string;

    /**
     * AパートとBパートのテーマと主張を組み合わせて展開させる
     */
    tellDevelopmentSection: (aSection: Section, aSectionContent: string, bSection: Section, bSectionContent: string, developmentSection: Section) => string;

    /**
     * AパートとBパートのテーマと主張を再提示してまとめる
     */
    tellRecapitulationSection: (aSection: Section, aSectionContent: string, bSection: Section, bSectionContent: string, developmentPart: string) => string;
}

/**
* 物語る。
*/
const telling = (teller: Teller, aSection: Section, bSection: Section, developmentSection: Section): string => {
    const a = teller.tellASection(aSection);
    const b = teller.tellBSection(bSection, a);
    const development = teller.tellDevelopmentSection(aSection, a, bSection, b, developmentSection);
    const recapitulation = teller.tellRecapitulationSection(aSection, a, bSection, b, development);

    return [a, b, development, recapitulation].join('\n');
}

太陽のラーメンは、おそらくこんな感じです。

const aSection: Section = {
    theme: "あっさりとしたスープ",
    claim: "あっさりとした主張しすぎないスープと、麺が地を作る"
};

const bSection: Section = {
    theme: "スープよりも味の濃い美味しいチャーシュー",
    claim: "スープと麺が作った地に対して、チャーシューが図として作用する"
};

const developmentSection: Section = {
    theme: "スープとチャーシューの味の対比",
    claim: "少しずつチャーシューの比率を高めていくことで、ラーメンにクライマックスをもたらす"
};

ところで、「普遍的な構成」ということは、この構成で説明すれば何でも人を感動させられるはずですね。 ちょっと試してみましょう。

この構造で弊社のサービスを説明してみる

ということで、弊社のサービス「パークダイレクト」をこの構成で説明してみたいと思います。
自分で書いてもアレなので、上記の抽象関数を実装してclaudeに小説風に書いてもらうことにします。

const aSection: Section = {
    theme: "借主(＝駐車場を借りたい人)が駐車場を借りる際の従来の手続きの不便さ",
    claim: "かつての駐車場賃貸借契約の手続きは、足で駐車場を探し、紙ベースで手続きするのが主流であり、借主にとって非常に悪い体験であった。契約後も、多くの場合は銀行振込が毎月必要で、手数料と手間がかかっていた。"
};

const bSection: Section = {
    theme: "貸主(＝不動産管理会社)が駐車場を貸し出す際の従来の手続きの業務負荷の高さ",
    claim: "かつての駐車場賃貸借契約の手続きは、紙ベースでの管理や対面での契約が主流であり、貸主にとって非常に高い業務負荷となっていた。また、駐車場の利益率の低さから、広告などは掲載することができず、集客にも課題があった。"
};

const developmentSection: Section = {
    theme: "パークダイレクトによる駐車場賃貸借契約の効率化と利便性向上",
    claim: "パークダイレクトを活用することで、借主はスマートフォンやパソコンから簡単に駐車場を検索・予約でき、契約手続きもデジタル化されるため、非常に便利で迅速な体験が提供される。また、貸主にとっても、オンラインでの管理や契約が可能となり、業務負荷が大幅に軽減される。さらに、Web上にデータが掲載されることで、集客力も向上し、駐車場の収益性が改善される。"
};

const teller: Teller = {
    tellASection: (aSection: Section) => {
        const story = execSync(`claude -p "次のテーマと主張について、テーマの提示に相応しい文章で小説風に述べてください。返答は、その文章のみを出力してください。テーマ: ${aSection.theme} 主張: ${aSection.claim}"`).toString();
        return story;
    },

    tellBSection: (bSection: Section, aSectionContent: string) => {
        const story = execSync(`claude -p "まず、テーマAの文章を読んでください。${aSectionContent}。その上で、次のテーマと主張について、テーマBの提示に相応しい文章で小説風に述べてください。返答は、その文章のみを出力してください。テーマ: ${bSection.theme} 主張: ${bSection.claim}"`).toString();
        return story;
    },

    tellDevelopmentSection: (aSection: Section, aSectionContent: string, bSection: Section, bSectionContent: string, developmentSection: Section) => {
        const story = execSync(`claude -p "次のテーマと主張を組み合わせて、展開部分に相応しく、盛り上がる文章で小説風に述べてください。なお、テーマAとテーマBは既に提示されているため、展開部のみを出力してください。返答は、その文章のみを出力してください。テーマA: ${aSection.theme} 主張A: ${aSection.claim} 内容A: ${aSectionContent} テーマB: ${bSection.theme} 主張B: ${bSection.claim} 内容B: ${bSectionContent} 展開時のテーマ: ${developmentSection.theme} 展開時の主張: ${developmentSection.claim} "`).toString();
        return story;
    },

    tellRecapitulationSection: (aSection: Section, aSectionContent: string, bSection: Section, bSectionContent: string, developmentPart: string) => {
        const story = execSync(`claude -p "次のテーマと主張と展開部を読んだ上で、感情面でテーマAとBをなぞるような形で振り返りまとめる文章を小説風に述べてください。なお、テーマA、テーマB、展開部は既に提示されているため、再現部のみを出力してください。返答は、その文章のみを出力してください。テーマA: ${aSection.theme} 主張A: ${aSection.claim} 内容A: ${aSectionContent} テーマB: ${bSection.theme} 主張B: ${bSection.claim} 内容B: ${bSectionContent} 展開部: ${developmentPart}"`).toString();
        return story;
    }
};

const story = telling(teller, aSection, bSection, developmentSection);
console.log(story);

npx tsx index.ts

実行結果

駐車場を探すという行為は、かつて一つの冒険であった。

休日の午後、地図を片手に住宅街を歩き回る。空き地の隅に立てられた色褪せた看板を見つけては、そこに書かれた不動産会社の電話番号をメモ帳に書き写す。
電話をかければ、平日の営業時間内に来店するよう言われる。
仕事を調整して不動産会社を訪れると、申込書、住民票、印鑑証明書、所得証明書——必要書類のリスト*1を手渡される。
何度も役所と会社と不動産屋を往復し、ようやく契約にこぎつけるころには、最初の熱意はすっかり冷めていた。

しかし、契約が終わっても、煩わしさは続いた。毎月決まった日に、銀行の窓口やATMへ足を運ぶ。
振込用紙に口座番号を書き込み、手数料を支払う。
忘れれば督促の電話がかかってくる。ある月は出張と重なり、ある月は体調を崩して遅れた。
たかが駐車場一つのために、これほどの時間と労力を費やさねばならないのか。

紙の束と印鑑と、銀行の窓口の長い列。それが、駐車場を借りるということの、真実の姿だったのである。

問い合わせの電話が鳴るたびに、机の上の書類の山が揺れた。

不動産管理会社の事務所には、いつも紙の匂いが充満していた。
駐車場の契約書、更新通知、督促状——それらは年代物のキャビネットに詰め込まれ、必要なときには埃を払いながら探し出さねばならなかった。
ある借主の入金状況を確認するだけで、三つの台帳を開き、過去半年分の記録を目で追う。それが、日常だった。

契約の申し込みが入れば、借主との面談の日程を調整する。
平日の昼間に来られないと言われれば、夜間や休日の対応も辞さない。
契約書は一枚一枚手書きで記入し、印鑑を押す箇所を指で示す。
書類に不備があれば、また来てもらうか、郵送でやり取りをする。
一件の契約を完了させるまでに、何通の電話と何度の面談を重ねたことか。

そして毎月、入金確認の作業が待っていた。
通帳記帳をして、名義を照合し、台帳に手書きで記録する。
振り込みが遅れている借主には、電話をかけ、督促状を送る。月の半分は、この繰り返しに費やされた。

駐車場の賃料は安い。
月額一万円足らずの物件も珍しくない。
そこから広告費を捻出することなど、到底できない。
看板を立て、口コミに頼り、それでも空きが埋まらない月は、ただ時間だけが過ぎていった。

利益は薄く、手間ばかりが重い。それが、駐車場を貸すということの、偽らざる現実だったのである。

だが、時代は変わった。パークダイレクトの登場とともに、すべてが一変したのである。

ある朝、スマートフォンを手に取った借主は、画面を数回タップするだけで、自宅周辺の空き駐車場を一覧で見ることができた。
地図上にピンが並び、料金も、距離も、空き状況も、すべてが一目瞭然だった。
気に入った物件があれば、その場で予約ボタン*2を押す。　
契約書類は画面上で確認し、電子署名で完結する。役所へ行く必要も、平日に仕事を休む必要も、もはやなかった。

そして毎月の支払いは、自動引き落としで完了する。
手数料を気にすることも、振込を忘れて督促される心配も、もう過去のものとなった。
すべてが、指先ひとつで終わる。
かつての冒険は、今や五分で完結する日常へと姿を変えたのだ。

一方、管理会社の事務所では、紙の山が消えていた。

契約書はクラウド上に保存され、必要な情報は検索窓にキーワードを打ち込むだけで瞬時に表示される。
入金確認は自動で行われ、台帳に手書きで記録する必要もなくなった。
借主との面談のために夜間や休日を潰すこともない。
すべてが、オンラインで完結するのだから。

さらに、パークダイレクトのプラットフォームに物件を掲載すれば、全国のユーザーがその駐車場を目にする。
広告費をかけずとも、Web上のデータベースが集客を担ってくれる。
空室期間は短くなり、稼働率は上がり、収益性は目に見えて改善された。

利益は増え、手間は減った。借主は笑顔で契約し、貸主は余裕を持って事業を運営する。

それが、パークダイレクトがもたらした、新しい現実だったのである。

かつて、駐車場を借りるということは、時間と労力を消耗する戦いだった。
地図を片手に街を歩き、電話番号をメモし、役所と会社と不動産屋を何度も往復した。
契約が終わっても、毎月銀行へ足を運び、振込用紙に数字を書き込み、手数料を支払った。
たかが駐車場ひとつのために、人生の貴重な時間が削り取られていく——その不条理に、誰もが諦めの溜息をついていた。

そして同じ頃、貸す側もまた、別の苦しみの中にいた。
事務所には紙の山が積み上がり、電話が鳴るたびに台帳をめくり、借主との面談のために休日を潰した。
毎月の入金確認に追われ、督促の電話をかけ、それでも利益は薄く、広告を出す余裕すらなかった。
駐車場を貸すということは、終わりのない事務作業との格闘であり、誰にも報われることのない労働だった。

けれど今、あの日々は遠い記憶となった。スマートフォンの画面を数回タップするだけで、すべてが完結する。
借主は、もう迷わない。
貸主は、もう疲弊しない。
紙の束も、印鑑も、日々の業務も、すべてが消え去った。

かつての不便と苦労は、今やただの昔話である。
パークダイレクトは、借りる人にも、貸す人にも、新しい時代の扉を開いたのだ。

完

いやぁ、エモいですね！そこまでしろとは言ってないレベルでエモい。 （ちょっと盛られすぎているところがあったので注釈は筆者が入れました。）

型とTellerの実装はそのまま再利用できると思うので、小説風エモプレゼンが必要になった際は是非ご利用ください。

構造について

さて、実装を読んでいただければ一目瞭然ですが、念の為に自然言語でも解説をしておきます。
ラーメンもパークダイレクト紹介小説も、以下のような形をとっています。

【提示】
テーマ１
テーマ２

【展開】
テーマ１とテーマ２を融合して展開

【再現】
テーマ１とテーマ２を展開されたことを踏まえて振り返る

特徴的なのはテーマが2つ（出来るだけ相反するものが良い）あることと、最後にテーマを繰り返す再現部があるところだと思います。
相反するテーマを2つ用意することで、展開した時に弁証法的*3に盛り上げやすくなります。
また、人間は基本的に自分の記憶の中にあるものでしか感動しないので、最初に提示で無理やり記憶を作り、再現部でその記憶を思い出のように提示することで無理矢理感動させているのだと僕は思っています。
感情をハックしている感があってクールですね！

起承転結や序破急と並んで、時間を伴う表現では非常によく使われる構成で、いろいろな愛称で呼ばれています。
有名なのは「ハリウッド形式」や「水戸黄門形式」などでしょうか。

ハリウッド形式と呼ばれる場合、大抵テーマ１を主人公、テーマ２を事件と置いて、主人公が事件を解決し、一番最初の主人公の日常シーンに戻ってきて終わる、という本当にオーソドックスな構成です。
水戸黄門の場合はテーマ１が水戸黄門一行テーマ２が事件となるだけで、大体同じですね。一行が街を訪れるシーンで始まり、最後に同じように街を去っていくシーンで終わる構成が取られがちです。

音楽ではソナタ形式と呼ばれていて、ベートーヴェンが一人で作って一人で拡張し一人で破壊したと言われています。
音楽の場合はテーマがモチーフと呼ばれる音形（音の並び）になリます。
実際にどの分野で最初にこの構造が用いられたのかは（少なくとも僕には）わかりませんが、考え方が明快でフレームワークとして優秀なので、感情に訴えたい場面では色々と便利に使えます。
LLMへの指示の場合も「ソナタ形式の提示部にあたる」などの文言を補うと、より形式を意識したアウトプットになります。
ちなみに、上記のTypeScriptで記述した関数を実行するのと、テーマABと展開部についての指示を書いて「ソナタ形式で小説風に」と指示するのはほぼ等価です。
どちらがトークン効率が良いかは明白なので、 構造を指示するキーワードの強力さがわかりますね。

営業、技術採用のためのプレゼンから、イベントの構成のような抽象的なものまで、ダイナミクス(力、動き、変化、相互作)で人を感動させるため技術の基本がこの構成にあると思っています。

最後に

Nealleではエンジニアを大募集しています！

あと、（ラーメンだけに）話のダシに使ってしまったラーメン屋は実在します。
実際とっても美味しいので、名古屋に立ち寄る際は是非。
（Google Map上は夜も営業していることになっていますが、平日でも大抵昼のうちに完売してしまって夜営業していることは稀なのでその点だけご注意ください）