食べチョク開発者ブログ

食べチョクエンジニアによるプロダクト開発ブログ

デザインと上手くお付き合いする方法を社内で発表した

デザイン

こんにちは、松久です。

株式会社ビビッドガーデンでは、「週次 Sync & Share の会 」が開催されています。 （だいたい）毎週、各チームから全社に向けて、学んだことを伝えたり、聞いたりしています。

デザインチームから Sync & Share 会で「デザインと上手くお付き合いする話」というテーマで、デザインチームとより上手に仕事をする方法がわかることを目的とした発表をしました。

発表テーマを決めた気持ち

「デザインと上手くお付き合いする話」というテーマだと、今は「上手くできていない」と聞こえます。正直、すべてが上手くいっているとは言えません。上手くできているところもあるので、上手くできているところを増やすために伝えたい、という気持ちでした。

「デザインチームはどんな事ができるのか」を伝えて、デザインの必要性や、どんな風に関わると事業に対してよい影響を与えることができるか社内の広報活動が必要だと感じていました。同様のことが、「銀行とデザイン」という本に、インハウスデザイナーの取り組みとして書かれています。この本に後押しされて、実際にやってみました。

銀行とデザイン デザインを企業文化に浸透させるために

銀行とデザイン デザインを企業文化に浸透させるために

Amazon

発表内容

「いい感じになーれ」を図解

当日は、スライドを作り、発表をしました。

一番言いたいことは、デザイナーが魔法使いで「いい感じになーれ」と唱えたら「いい感じ」にしてくれるわけではなく、一緒に「いい感じ」を探しましょう、ということです。

要件を決める前に呼んでもらえないのは、理由があると思っている。忙しそうで話すと迷惑そう。工数をかけたくない。話すと質問されて面倒。話しても上手くいかない経験がある。チームで話して決まっている。的確な質問をする力が必要という認識。そのために何ができるかは模索中。質問の作り方と数字の理解がデザイナーに必要
デザインチームが取り組むこと

一緒に取り組むためには、デザインチームも取り組むことが必要です。 認識している問題はいくつか有り、解決策が見えていることもあれば、暗中模索のこともあります。

発表した結果、どんな関わり方を持つとよいか、わかったと感想をいただいくことができました。発表することで、少しでも伝わったはずです。

おわりに

会社の取り組みの 1 つである「Sync & Share 会」を利用して、デザインとの関わり方を全社に伝える機会を得ることができました。 日々の活動で伝えることももちろん重要なのですが、業務ありきから始まってしまうので、業務で直接話したことがない人も含めて伝えられるいい機会があり助かりました。

デザインとの関わり方を全社で行えるようになることで、「食べチョク」の改善に活かしていきます。

GitHub Projects でデザインチームのタスク管理をするノウハウ

デザイン

こんにちは、松久です。

デザインチームでは、GitHub Projects でタスク管理しています。 タスク管理する理由はいくつかあります。

  • 「食べチョク」の改善を少しでも進めるため
    • チームで効率的に改善を進めるため
  • 他のチームと一緒に仕事をするため

チームで成果を出せているのかを確認するため GitHub Projects を使って「カンバン」を参考にして管理をしています。

なぜ GitHub Projects を使っているのか

GitHub が、職種関係なく導入されています。GitHub issue で、タスクを書き出して GitHub Projects に集約がある程度されている状況がすでにありました。もし、GitHub Projects を使い続けて問題が発生すれば移行することを検討することにしました。

現在の GitHub Projects の状態

GitHub Projects の運用状態です。

いくつかのカラムに分けて運用しています。 カンバンと同じで、issue は、inbox から始まり、Done で完了します。 現在あるカラムと役割は下記のとおりです。

  • inbox
    • issue ができたらまずはここに置く
    • 担当が決まっていない
  • Talking
    • デザインチームで検討したいことをここに置く
    • 定期的に話す時間を設けて話して解決したり、具体的な取り組みになれば、あたらしく issue を作る
  • Backlog
    • 取り組む担当を決めた issue
    • 取り組める状態にするのもこの状態で行う
  • Expired Backlog
    • リリース日が決まって動かせない issue
    • 取り組む担当を決めた issue
    • 取り組める状態にするのもこの状態で行う
  • In Progress
    • 取組中
  • 開発中・連絡待ち
    • UI デザインが終わり、開発実装中
    • 社外からの連絡待ちで、動かせない issue
  • マスターデータに反映待ち
    • 開発も終わり、利用者に届けられた状態だが、デザインデータをマスターデータ（ Figma でブランチ機能が使えないため）に反映するの待ちの状態
  • Done
    • 利用者に届けられたられた状態
  • icebox
    • いつか優先度が上がる可能性のある issue

運用を始めて、少しづつ変化して現在の形になっています。 今後も変化していきます。

GitHub Projects の運用ルール

運用しながら出来たルールがいくつかあります。

  • issue を左から右に進める
    • チームで issue をゴール（完了/Done）に進めることを大切にしています
    • issue が左から右に移動することで取り組む内容が具体的になります
  • Done に移動した（完了） issue をアーカイブするのは月曜日
    • 一定期間にどれぐらい完了したかチームで確認するため
      • 大体、1 週間で 10〜15 ぐらいの issue がクローズされているのか肌感をもつようにしています。少ない時は、進めるための障害があった時だと気付けるからです
    • Projects に置いておける issue には限りがある
  • 並べる順位は、取り組む・期限が近いもの順
    • 取り組む価値が大きいことを先にするのが基本です。ただし、取り組む内容が時間のかかるものの場合（例：冊子を作る）や、リリース日が近いのもあるので、取り組む順で並べています

GitHub Projects の運用ノウハウ

運用している中で、上手くいかなかったこともあります。

  • 毎日見る
    • チームでは月・水・金に見ています。取り組むことに困っていることはないかを確認しています
    • 私は毎日見ています。急ぎの issue が登録されていることがあるためです
      • 急ぎの issue は、Slack のデザイン組織のチャンネルなどでメンションしてもらうなどの方法もありますが徹底は出来ていないです
    • issue での連絡が途絶えたときは「いかがでしょうか」と連絡することから始めます
  • 担当者別のカラムは作らない
    • 担当者のことが知りたいわけではなく、issue がどんな状態なのかを把握したいので、担当者（アサイン）別のカラムは用意しません
      • 担当者の状態が知りたいときは、担当者別の View を作って対応しています
      • ラベル別で View も作れるので、ラベルの管理を大事にしています
  • カラムを増やしすぎない。
    • カラムを増やしたいと感じる時は、1 つのカラムに issue が溜まっていて取りこぼすことが出てくる時のようです
    • カラムを増やす前に、issue が止まっている要因を取り除くことを優先します
      • 「左から右」に issue を進める方法が他に無いか模索します。例えば、他のチームにお願いできないか、人を増やせないか、取り組み方やゴールを変えられないかを検討します

issue を作成する時のコツ

  • とりあえず issue にする
    • issue にしないのは、プライバシーに関わることなど、秘匿性が高いものだけです
    • デザイナー採用の資料作成など、プロダクトに関係ないことも issue にしています
    • Slack やミーティングで取り組むことを決めたら、issue にします。特に、Slack で話して取り組むことを決めたら忘れずに、issue にします
  • 完了を定義する
    • 「バナーを作る。中身未定」という issue はよくあります。そのときは、要望がでてくるまで待ちます。もしくは、声をかけて、取り組みを具体的にするところから始めます
    • 方法だけ決まっていて、何をすればいいのかわからないときは、わかるようにしていく取り組みをします。例えば、issue で質問したり、ミーティングしてみるなどをして結果を issue に記載します
  • issue の種類を把握する
    • 急ぎ（ASAP）、Epic（複数の issue 達成で成立する ）、不具合といった issue があり、別で管理できるようにラベルを付けています

GitHub Projects を運用してみて

運用していくなかで、大切にできていることは 2 つです。

  • 見える化する
  • フローを重視する

チームがどれだけ改善を実現しているのか一週間ごとで確認できるようになりました。同時に、連絡待ちや、急ぎの発生回数があるかも把握できるようになりました。 チーム外の人が見ても、詳しくは分からなくても、どのカラムにどれだけの作業があるのかはわかるようになっているハズです。

「左から右へ進める」ということを前提にしています。進めるための障害（デザインする時の悩み）が発生し、検知するためのイベントができ、検知したことを定例で話すようになってきたので、issue を進めることを大切にできるようになってきたと感じています。

もちろん、出来ていないこともあります。
また終わっていない issue があるのに、新しい issue に着手することがあります。取り組む issue を増やすのではなく、完了する issue を増やすことを優先できていないときがあります。終わらせることを優先したいのですが、確認待ちなどもあり、In Progress が増えている状態です。

おわりに

GitHub Projects を使ったチームのタスク管理についてまとめました。 やっていて、取り組まないといけないことが漏れていることは減りましたし、困っていることを見つけて、解決に進める機会が増えたことも感じます。

チームで成果をだせる体制を作り「食べチョク」の改善に活かしていきます。

おいしそうが伝わる写真を選ぶ原則をチームで共有した

デザイン

こんにちは、松久です。

「食べチョク」では、キャンペーンなどで使うバナー・キービジュアルを自社で作成しています。作成する時に使う写真は、素材サイトで配布・販売されている写真や、生産者さんが撮影された写真を使います。これらの写真から使用する写真を選ぶのは、時間がかかります。また、選んだとしても、デザインレビューで「もう少しシズル感のある写真がいい」という指摘をもらうこともあります。そこで、写真を選ぶ基準をデザインチームで認識を揃えることにしました。

企画によって写真選びの基準は違う

「【濃厚派？さわやか派？】あなた好みの「いちじく」集めました！」という企画を公開しました。品目・品種の違いを味わってもらいたい、という「今が旬」という企画です。この企画での写真選びの基準を用意することにしました。

何を伝える目的の写真なのかを決める

一番最初に決めたのは「何を伝える役割の写真」なのかを決めました。 決めたことは以下のとおりです。

  • おいしくみえる
    • シズル感がある
      • 果汁が見える
      • 果物であれば切り口が見える
    • 思わず食べたくなる写真
    • きれいに食べている
  • 届く商品を勘違いさせない

逆の項目も決めました。

  • 調理後の写真は原則ダメ
    • 美味しそうだけれど、知ってほしいこと（品目・品種の違い）ではない
    • 企画が「料理」である必要があるときのみ
  • 収穫前の状態
    • 今回の企画で知ってほしいこと（品目・品種の違い）ではない
    • 産直であること、鮮度、生産者さんといった別の連想がされやすい

いくつか試作をしながら、写真の役割を言葉にして項目案を出しました。一度、言葉に出てくると、役割とは逆の項目も出てきやすくなりました。

写真の役割が決まったので、写真を並べて、他に検討することがないかデザインチームで話し合いました。
実際に出来た原則が以下の図です。

Figma で原則を作り、バナーを作成するファイルに入れるようにしました

話し合いをする中で、食器があるときや、フォークが刺さった状態の時なども含めて話し合いました。写真での食材の写りだけではなく、食材の周囲の事も合わせて、どんなイメージを持たれそうか検討して、写真選びの原則の認識を揃えることができました。

まだ出来ていないこと

あくまでもバナーに使う写真なので、これでクリック数・クリック率の変化は、まだ未集計です。写真だけでクリック数・クリック率が決まるわけではないですが、いくつか試しながら調整していく必要がありそうです。

おわりに

写真選びの基準を持つことで、写真選びのノウハウがデザインチームに貯めることが出来ました。小さなことも少しづつためて「食べチョク」の改善に活かしていきます。

桃やぶどうのような同じ品目でバナーを作る前に事前準備したこと

デザイン

こんにちは、松久です。

「食べチョク」では、桃、ぶどう、梨の特集をしています。 特集では、キービジュアルや「チャート」と呼ばれる品種の収穫・販売時期を 1 枚の画像にまとめています。他にも「桃占い」というコンテンツの作成もありました。これらの画像を作成するにあたり、いくつか悩んだことや、取り組んだことがあります。

同じ品目に関するビジュアルを数種類作る難しさ

桃について固さから品種を選ぶ企画がスタートすることになり、キービジュアルが必要という話と「チャート」の画像、LINE などの広告用の画像を作ることになり始めてみて気づいたことが 2 つあります。

1 つめは、同じ「桃」という品目で画像を数種類作るので、踏襲するところと違いを出すところを決めて作り始めます。今までとは作る手順が増えていることです。 2 つめは、同じ「桃」という品目で画像ごとに目的に合わせた表現はしつつ、同じ「桃」であることを伝えるために何を踏襲するのかを決める必要がありました。また、桃の「柔らかい」「かたい」の表現方法を最初に決める必要もありました。最初に決めておかないと「桃」というテーマで繋がらなくなるためです。

難しさに気づいたタイミング

当初から作る難しさを担当のグラフィックデザイナーの日報から感じてました。 ハッキリとわかったのは「桃の世界を探検しよう」という特集の画像作成の時です。 サイトトップにはピンク色の桃に関するバナー画像が複数個ならんでいる状態で、さらにピンク色の桃のバナー画像を追加しても、伝えたいことが伝わらないと予想されました。

「桃の世界を探検しよう」では周囲のバナーに合わせて色を変更した

対策として、桃の色を引き立てつつ、他のバナーではあまり使っていなかった青を背景に使うことにしました。 食べチョクでは、夏ギフト以外で青を使うことが少ないので、他との違いが明確になりました。

同じ品目でバナー画像を作り、同時期に使われると同じ色・雰囲気のバナーが並ぶことが予想されました。そこで、企画が始まる前に準備することが必要だとわかりました。

企画が始まる前に準備をする

「桃」の次に「ぶどう」が始まることになりました。 「桃」で気づいたことについて対策として、色の設計と表現案を下調べしておくことにしました。「ぶどう」は、他のサービス・商品ではどんな表現をしているのかまとめていきました。

「梨」では、黄色ベースとなることはわかったのですが、他の黄色系の果物との違いも含めて認識を揃えることにしました。パイナップルやレモンなど「黄色」の果物がありますが、どんな色と組み合わせることがあるか確認しています。

制作に入る前に、準備した内容を、グラフィックデザイナー同士で話をして認識を揃えることにしました。準備をしておくことで、デザインレビューも表現方法について話すことは減り、より伝えられる方法についての議論が増えました。

まだ出来ていないこと

準備をすることで、作る時間を少し短縮することは出来ました。 しかし、使うことにした色をデザイナー以外には共有ができておらず、メルマガなどでは異なる色が使われており、サイト上での印象と揃えることがまだ出来ていません。

他にも、食べチョクで使われていると、色の印象が揃っているかももう少し確認が必要そうです。 あと、来年も同じ特集をするとしたら、最終的にどんな色設計にしたのかなどをまとめておくことも必要そうです。

おわりに

事前準備をすることで、バナー画像の作成時間を減らすことは出来ました。 ですが、まだ出来ていないこともたくさんあることに気づきました。今回気づいたことも、今後の取り組みで活かして「食べチョク」の改善を進めていきます。

「似ているけれど少し違う色」を減らす取り組み

デザイン

こんにちは、松久です。

UI を作るときに、色は定義されている中から選ぶのを基本にしています。 色の定義が Figma で行われ、実装に反映され、違う場合は Stylelint で指摘される運用がされています。

色の運用が進んできたので、過去に定義した色や、デザイナー間で色が共有されていなかったために起きた「似ているけれど少し違う色」を減らす対応をすすめています。

似ている少し違う色がある問題

「似ているけれど少し違う色」がある状態は、使っている人に「なんとなく、まとまりに欠ける」印象を与えます。ブランドイメージを下げたり、いい買い物した、という印象を下げることもあります。

デザイナーや実装者にとっては、色の違いの意味がわからず実装のコストが増える原因の 1 つになります。

この問題を解消するために、少し違う色が実装されているのかを確認します。 CSS に設定されている色の確認方法は、Chrome の CSS Overview 機能を使います。

似ているけれど少し違う色を目視で見つける

確認してみると、似ているが少し違う色が見つかります。 これを、1 つずつ減らしていきます。

少し違う色を、減らしていく取り組み

見つけた「似ているけれど少し違う色」を、減らしていく取り組みを今しています。 取り組みは、4 つに分けて取り組むことにしました。

1.新しい色の定義の変数に置き換える

直接色コードが記述されている箇所を SCSS の変数を使えるところは、置き換えをします。 今後、色の調整をするとしても、変数を変えれば調整ができるからです。

2.過去の SCSS の色定義の利用を辞める

過去の色の定義の SCSS を新しいものに置き換えていきます。 新しく使われないように、Stylelint でも指摘がされるようにしています。 最後に、利用がなければ過去の SCSS の定義を消して終わりです。

3.少し違う色を新しい定義に寄せて置き換える

まだこれは実施をしていません。 少し違う色なので、対応箇所が 100 箇所ぐらいの色もあります。そのため、少し違う色の方が標準になっている色もあるためです。

4.色の Utility Class を置き換える

色に関する Utility Class がいくつかあります。設定されている色を新しく定義された色にしていく取り組みをしています。

難しいのは同じ Utility Class が複数あることです。 同じクラス名だけれど、色の定義が違うこともあります。

.text-gray {
  color: #555;
}

// 同じクラス名だが、別の色が使われている
.text-gray {
  color: #b8b8b8;
}

バラバラになっていますが、定義に近い色がある場合は、一気に統一をします。

問題なのは、バラバラだけれど似ていない色が出てくる場合もあります。 この問題については、一気に統一をするのを避けています。

.text-red {
  color: #ff7355 !important;
}

.text-red {
  color: #d0555a;
  font-weight: 600;
}

.text-red {
  font-size: 1.3rem;
}

新しく使われるのを防ぎ、使われている箇所を置き換えるしかなさそうです。 上記の例にある .text-red では 100 数箇所あるので、一旦統一するか、置き換えるかを検討しているところです。

おわりに

似ているけれど、少し違う色は、サービスを提供するのであれば、サービスが動かなくなるような存在ではありません。提供するサービスの質や、サービスを運用するための手間が増えてしまう存在です。

時間はかかりそうですが、少しつづ減らしてくことで、「食べチョク」の改善を進めます。

ふりかえりからデザイナー同士のミーティングを改善しました

デザイン

こんにちは、松久です。

以前、「デザイナー同士で行う 3 つのミーティング設計」というお話を書きました。そこから、半年ぐらい運用していくなかで、変えたことがあります。

変わらないこと

大きく 3 つのミーティングがあることは変わりません。

  • プランニング・交通整理
  • Designer Team Discussion
  • Monthly Update

ミーティングの数も変わらず、時間も変わっていません。

変わったこと

Designer Team Discussion が少し変わりました。 以前は話したことを「📝🍵🍡」の絵文字をつけて、Slack のデザイナーチャンネルにメモしていました。そこから、取り組むことを esa に書き出して Monthly Update で進捗を確認していました。この方法だと、頻度が月 1 回のため成果を出し続けることが難しかったです。 月に 1 回の進捗確認だと、忘れてしまったり、進まなかったと気づくのが 1 ヶ月後になる可能性があります。そこから対応策を決めると、さらに 1 ヶ月かかり、対応までの時間がかかります。デザイナー同士で検討するのにも時間が必要な場合は特に時間がかかります。 このことに、Monthly Update という月 1 回のふりかえりで気づきました。

この問題の対応として、 Designer Team Discussion で気になり話し合いたいことも、見つけた不具合も全て GitHub の issue にすることにしました。issue にしたことで、週 3 回の「プランニング・交通整理」のミーティングで確認することができるようになり、進み具合や、進めるのに障害になっていることを以前より早く把握できるようになりました。

GitHub Project に「🧵Talking」というレーンを作りました。このレーンには、話し合いが中心となる issue を入れておくことにしました。

このレーンにある issue を Designer Team Discussion の月曜日に話しています。月曜日は、全員揃う日であること、週の始まりで週の予定を調整しやすいことが理由です。

現在は、この方法で少しづつですが、確実に「カイゼン」を進められています。

おわりに

自分たちのやり方に、より良い方法がないか Monthly Update というふりかえりから、気づいて別な方法に切り替えていくことができました。

ふりかえりから、自分たちのやり方を定期的に見直して「食べチョク」の改善を進めていきます。

RubyKaigi参加者向け飲食店情報

ようこそ！松本へ！

こんにちは！ビビッドガーデンの美味しいものハンター兼エンジニアのy-hakutakuです。 弊社は今週5月11日〜13日にかけて開催される RubyKaigi 2023 で ローカルフードスポンサー として協賛しています。 オフライン会場ではブース出展をしており、地元生産者さんの食材やプレゼントありのクイズ企画を実施していますのでぜひお立ち寄りください！

せっかく松本まできたし、美味いものを食べたい

今年は外のランチ推奨とオーガナイザーの松田さんもおっしゃっていたので、お店の情報はあればあるほど助かると思い、安曇野にルーツがあるy-hakutakuが紹介していきます！

そば

榑木野

昔からの有名店。松本駅側にもあるので、あずさに乗る前にいかがでしょうか。 https://www.kurekino.co.jp/tenpo/ekisha/

みよ田

松本、上高地周辺の郷土料理に「とうじそば」を提供しているお店。ご当地グルメハンターにおすすめです！ https://www.ohtaki-gp.jp/brand/brand14/

ワインバー

peg

学生時代の先輩のおすすめのお店。ワインで酔いたい方はこちらへ🍷 https://tabelog.com/nagano/A2002/A200201/20020569/

居酒屋

山女や

地酒を飲みながら、串はいかがでしょうか。南信地方の「ザザムシ」や「蜂の子」などもあります🐛 https://tabelog.com/nagano/A2002/A200201/20000078/

松本つなぐ横丁

複数の店舗が併設されているタイプ施設。色々楽しみたい方はいかがでしょうか。 STORESさん主催のアフターパーティの会場でもあります。 https://hey.connpass.com/event/277763/ https://matsumoto-yokocho.jp/

大衆食堂

たけしや（焼きそば）　

焼きそば通にも一目置かれる名店です。わざわざここに来るために松本に来る焼きそばマニアもいらっしゃるそうです。 https://tabelog.com/nagano/A2002/A200201/20001590/

白雪（食堂）

松本周辺って普通サイズが大盛りということも。今はそういうお店もだいぶ減っていますがこちらは現役です！ ガッツリいきたい方はぜひ！ https://tabelog.com/nagano/A2002/A200201/20005440/

せいこうえん (中華料理店)

駅地下の昔ながらの中華料理店です。飲んだ後の〆にもお食事にもいかがでしょうか！ https://tabelog.com/nagano/A2002/A200201/20011076/

焼き鳥

鳥心

「焼き鳥を食べるならここ！」と学生時代の先輩に教えてもらったお店です。 https://tabelog.com/nagano/A2002/A200201/20003244/

洋食

どんぐり

シルバーが金属バケツで置かれ、一緒に入っているどんぐり通信を読みながら注文を待ちます。 メニューの名前にはマスターのご家族の名前が冠されたものもあり、あたたかさを感じるお店です。 https://tabelog.com/nagano/A2002/A200201/20000428/

カレー

メーヤウ

カレーの名店。ここのカレーを食べに松本まで来たこともありました。辛味が苦手な方は非推奨です。 また、会場からは少し離れているので、向かう方はタクシーで。満席の時は近くの桐店へGO！ https://www.facebook.com/maeyaomatsumoto

ラーメン

おおぼし

こってりとあっさりのラーメンのある名店。ばりこてが個人的にはおすすめです！ https://tabelog.com/nagano/A2002/A200201/20025262/

うなぎ

山勢

うなぎのみのお店、地元の工場などで繁忙期に差し入れとして利用されたりもします！ https://tabelog.com/nagano/A2002/A200201/20021045/

焼肉

明月館

松本の焼き肉の名店。地元民に愛される名店です。私もいきたい！ https://tabelog.com/nagano/A2002/A200201/20003701/

和食

蔵

ちょっと高価格帯ですが、和食や郷土料理をじっくり味わいたい方へいかがでしょうか。 https://www.matsumotokura.com/

ビストロ

オー・クリヨー・ド・ヴァン

個人的名物はステーキとフライドポテト。パリのビストロ感を強く感じるのは外のラタンチェアからかも。 https://crieur-japon.com/menu/

スイーツ

マサムラ

シュークリーム。懐かしい感じ。地元民なら知っている名店。会場近くにあるので糖分の補給にどうぞ。 https://tabelog.com/nagano/A2002/A200201/20000074/

喫茶店

珈琲美学 アベ

全国区になった純喫茶。サイフォンコーヒーやパフェが有名。電車待ちにいかがでしょうか。 https://tabelog.com/nagano/A2002/A200201/20001420/

お土産

開運堂

祖父母は必ずここでお土産を買っていました。 https://www.kaiundo.co.jp/shop 「これはうまい」という商品名のくるみ饅頭がオススメです。 https://www.kaiundo.co.jp/products/detail/2510

竹風堂

北信地域の和菓子屋さん。有名なお布施の栗を使った商品が有名です。 栗鹿の子や栗羊羹など、マストバイだと思います。 https://chikufudo.com/shop/491/

以上、ざっと紹介いたしました。 マップも合わせて公開します。

また、松本駅周辺の飲食エリアの大体のイメージも載せます。

会場周辺地図

まとめ 松本駅周辺は飲食店が密集しており、夜の散策もきっと参加者同士の交流においても楽しい場所かと思います。 RubyKaigi 2023、ご参加の方はぜひ松本グルメをご堪能ください。

私も初日だけですがブースでスタッフとしておりますので、是非お話しさせてください。 松本名物のお話や、食べチョクの美味しい商品などもご紹介できるかと思います。

それでは会場でお待ちしております！