"お土産"ってみんなどうやって選んでるんだろう

会社のリモートワーク制度を活用させてもらって、1週間弱、富山の実家に帰省していた。

今回はリモートワークの話ではなく「お土産」の話。（予め書いておくが、普遍的な話ではなく完全に自分の場合の話。）

福岡のお土産といえば？

富山の実家に帰るなら、お土産・・・は買わない。

どこの地域でもそうだと思うが、福岡みやげの大半は、福岡で人々が日常的に食べるようなものではない。なので、通りもんだかなんだかを買って帰るのには結構抵抗があるのだ。

とくに、うちの両親はわざわざ福岡に来てくれたこともあるので、どうせ買って帰るなら、自分が食べてみて「これ美味しかったよ！」とかそういうものを持って帰りたい。そもそもお土産とはそういうものだろう。自分の体験をからめてだったり、その土地の文化のようなものが色濃く出ているものがいい。

ちなみに今回は（前回持っていって「またそれ？」と言われてしまったので）落選した「よつばドーナツ」は、その点カンペキだ。

自分は日常的によつばドーナツを食っているし、福岡市には結構多い"健康志向"のお店のものでもあるからだ。

そんなわけで、今回は実家には何もお土産を買って帰らず、親戚用にだけ形だけのお土産を適当に買っていった。明太子で有名な"ふくや"のなんかだったと思う。福岡に来たことがない人であれば、とりあえず"明太子発祥の店の"お土産がいい、という論理だ。

そういえば、札幌のお土産・・・

昔、札幌に3年半くらい住んでた時に、何を買って帰ってたっけ？というのを思い出すと、あの「白い恋人」っていうやつは多分最初の1回しか買って帰ってなかった気がする。

札幌にいて、飲み会の後にジェラートを食うことはあっても、クッキーを食べることは絶対にない。そんなわけで白い恋人はただただ「形だけのお土産」になってしまうわけで、親しい人に買って帰ると逆に失礼だ。そんなわけで最初の1回だけだったんだろう。

じゃあ何買って帰ってたっけ？というと、能動的に買っていたのは

• サッポロクラシックのビール
  • これは北海道でしか買えないし、札幌に居て缶ビールを買うならまず間違いなくクラシックを選ぶ
• ロイズのチョコ
  • めちゃくちゃコスパがいい
  • 個人的に、仕事中に食ってたｗ
• "島の人" の昆布の加工品
  • モノが本当に礼文島のものかは知らないけど、礼文島の何か。
  • 自分が礼文島大好きだから

あたりだったかな。「なにこれ？」って聞かれても自分なりに説明が付くものを買ってたなって、今更ながら思う。

富山のお土産といえば？

迷いなく、「ささら屋の白えびせんべい」か、その周辺の何かを買う。

富山に居て、白えびせんべいを日常的に食うことはないのだけど、それでも他の県に比べると"せんべい"は割と食う県なんじゃない？というのが第一にある。

あとは、白エビっていうのが地元の特産品で、こいつがぜひとも他の県の人に知って食べてもらいたいものなのだ。

とはいえ残念ながら、新鮮なものを生食しない限りはただの小エビ...。それならそれで割り切って、「名前だけでも知ってもらえばええんや！」っていう産物が「白えびせんべい」だ。（もしかすると、ささら屋(日の出製菓)は本気で白エビ風味を出すべく頑張っているのかもしれないけど、自分の認識は↑です...ｗ）

ちなみに、これは本当にどうでもいいことなんだけど、ささら屋は大阪にも東京にもある。万が一富山で「やべー！お土産買い忘れた！」ってなっても、こっそり買うことができるｗ

まとめ

完全に自分の話しか書いてないんだけど、お土産って モノじゃなくて、それに付随する話ネタがあってこそのものだ という結論に至りつつある。

会社でちょいちょい「大阪行ったのでお土産買ってきましたー！」みたいな感じで謎のお菓子が置かれていることがあるのは、あればどういう論理なのだろう・・・。

「リファクタリング専門チームによるお金周りリファクタリング」を斜め読みして思ったこと

engineer.crowdworks.jp

これ。すごく読みやすいし良い記事だった。

再現性のある取り組みだと思うのだけど、微妙に補足しといたほうが良いのかなーと思うところもあり、メモがてら書いておく。

専任が引っ張る体制

属人化を嫌って、「技術的負債はみんなで対処するぞ！」「そのためのコーディング規約とかを整備するぞ！」とかとかやりだすと、続かない。

2016年頃に、自分がまだRails初心者だったころにこんなことがあった。

class HogeHogeFeedbacksController < SecureApplicationController

  def create
    feedback_params = params.require(:feedback).permit(:content, :score, :version, :device_name)
    feedback = HogeHogeFeedback.new(feedback_params)
    feedback.user = current_user
    if feedback.save
      ...
      redirect_to ...
    else
      render :new
    end
  end
end

っていう感じの、ほぼほぼRails Wayに乗っかるようなコードをPull Request出したときのことだ。

レビュー時に「サービスクラス作れ」「サービスハンドラークラス作れ」とかとか言われた。「コード量が増えるだけじゃん？」と初心者ながらに反論したものの、受け入れられず、無駄に記述量だけが多いコードを書くことになった。

class HogeHogeFeedbacksController < SecureApplicationController

  def create
    HogeHogeServiceHandler.new(
      content: params[:feedback][:content]
      score: params[:feedback][:score]
      version: params[:feedback][:version]
      device_name: params[:feedback][:device_name]
    ).handle

    ...

    redirect_to ...
  rescue HogeHogeServiceCreationError => e
    render :new
  end
end

class HogeHogeServiceHandler
  def initialize(content, score, version, device_name)
    @content = content
    @score = score
    @version = version
    @device_name = device_name
  end

  def handle
    HogeHogeFeedbackCreateService.new(
      content: @content,
      score: @score,
      version: @version,
      device_name: @device_name
    ).perform
  end
end


class HogeHogeFeedbackCreateService
  def initialize(content, score, version, device_name, current_user)
    @content = content
    @score = score
    @version = version
    @device_name = device_name
    @current_user = current_user
  end

  def perform
    feedback = HogeHogeFeedback.new
    feedback.content = @content
    feedback.score = @score
    feedback.version = @version
    feedback.user = @current_user
    feedback.save!
  rescue ActiveRecord::RecordNotFound
    ...
  end
end

あまり覚えてないけど、たしかこんな感じの構成に書き換えたと思う。そしてレビューが通ってリリースされた。（そして、3ヶ月後くらいに変数名のタイポを発見したｗ）

Railsを普通に使ってる人が10人いたら、おそらく10人全員が変更前のコードを好むだろう。なのになぜタイポのリスクが高い後者のようなコードが受け入れられたのか？

そこに「ルール」があったからだ。

「Railsをあまり知らない人でもとりあえずルールに従っておけば間違いない」みたいな解釈がされたルールがあったんだと思う。

課題のないところをルールで縛るとか、冷静に考えるとありえない話。なんだけど、 属人化を排除しないといけない！って思うと、「なるべくルールの例外はつくるべからず」みたいな判断が働いてしまう のだろう。しらんけど。

ともかく、今回MinoDrivenさん(とkinakoboさん?)がかなり引っ張っていろいろやってるのが大きいんだろうなーーーーーってブログ記事読んで思った。

すごく大変だと思うのだけど、こだわり持ってる人がとにかく突き進めていくのがこういう成功事例につながってるんだと思う。

間違っても「全員がこういう美しいコード書けるように整備しよう」とか考えないでほしいなって思った。

現状理解と斬新的な改善

現状を納得する必要はないけど、少なくとも動いてしまってるコードである以上は理解する必要がある。

• 誰がどういう期待をもって使うものか
• かりに全部作り変えたとして、残さないといけないものはどれか、捨ててもいいものはどれか

などなど、いくら現状がクソコードで納得しがたいものであっても、理解はしておかないといけない。

　 たしかMinoDrivenさんと一緒にリファクタリングやってるkinakobo氏は、「実は使われていないメソッド」みたいなのを地道に消す取り組みとかもやってた気がする。

今回の記事には関係がないけど

qiita.com

あたりを読んだときも、似たようなことを感じた。

「こんなの１から作り直してやる！」から始めてはいけないと改めて思った。

「DDDで」とか「クリーンアーキテクチャで」とかは解決策ではない

自分がうっっっっっっすら記憶してる限りだと、お金周りのコードはモデルがファットなだけじゃなくて、コントローラもそこそこボリューミーだし、サービスクラスもいくつか絡んでいる、みたいな構造だったはず。（自分みたいな素人がなんとなくリファクタやってくれっていわれたら、多分コントローラとかサービスクラスを分解して、闇雲に何かをやる気がする）

そんななかで、モデルの役割整理にフォーカスを絞っているのが、成功の鍵なんだろうなーってうっすら思った。

・・・てか

「リファクタリング専門チームによるお金周りリファクタリング」に書かれてないような前提の補足をして、より理解を深めて読んでもらいたいなーから書き始めたんだけど、なにも貢献できてない気がする。

やはり自分には文章力が足りない。

唐津の七ツ釜はとても良かった

3連休に何もしないのはもったいないので、唐津の方をドライブしてきた。

たまたまGoogle Map見てたら

なんかおもしろそうなものが？

七ツ釜

遊覧船は1000円。

（ネットで調べると呼子の港から出る「イカ丸」みたいな名前のやつがあるけど、それは1600円するうえに、海上区間が長い）

んで、乗ってみると、これが結構良かった。1000円にしては十分楽しめる。

出港場所自体も結構景色が良くて、

象の鼻を横に見ながら、七ツ釜のあたりまでは風は爽快に。

七ツ釜は結構接近して見せてもらえる。（ガイドの人は、呼子発のイカ丸よりも近くで見れるよと言っていたが本当かどうかは不明）

一つだけ、穴が奥まで貫通してるのがあるんだとか。

で、戻る。20分くらいのプチクルーズなんだけど、ちょうどよかった。

呼子は人が多い

その後、呼子と波戸岬をまわって帰ったんだけど、呼子は有名になりすぎなのか、やたら人が多かった。

歩いて回ったわけじゃないので、実は楽しめる場所なのかもしれないけど、今回のドライブではスルー。行くなら、自家用車じゃなくてバス旅行かなー。

あと、「呼子のイカ」って有名だけど、たぶん呼子じゃなくてもうまいイカは食えると思った。

海中レストラン？！

www.manbou.co.jp

今回はまったく下調べしないで適当にいったので、ここには行けてない。観光で誰か来た時に一緒に行こうかなと思った。

---

ということで、福岡から片道1時間半で結構いい場所あるなー、と再認識したのでした。