寿司を握る技術（導入編）
この記事は、Boulder Advent Calendar 2020 1日目の記事です。
皆さんは、寿司はお好きでしょうか。エンジニアはとかく寿司が好きな人が多い印象ですが、ご多分に漏れず僕もめちゃくちゃ好きです。どれくらい好きかというと、自分で握ってしまうくらいには好きです。
この記事では、ソフトウェアエンジニアがふと思い立って寿司を握り始めてから、実際に人に振舞うようになる過程で学んだことを書いていきます。この記事を読んで、自分も寿司を握ってみようと思う方がいればそれ以上嬉しいことはありません。
写真は、身内向けにお店を貸し切らせてもらって握ったときに撮ってもらったものです。
一気に書くと結構な長さになってしまいそうなので、導入編・実践編に分けて書いていきたいと思います。本記事は導入編として、寿司を握ろうと思った経緯から始め、実際に寿司を握るための準備として構造やプロセスを眺め、それを支える道具を紹介します。
実際の工程やオレオレレシピについては本記事では細かく言及せず、実践編で書きたいと思います。
（※完全にアマチュアなので、情報や認識の正確性などについてはご容赦ください。）
なぜ寿司を握ろうと思ったのか
寿司を握ろうと思ったシンプルで「寿司が好きだったから」です。
寿司にはたくさんの魅力があります。美味しいのはもちろんですが、おめでたい行事などの人が集まる会に出される、ちょっとした「特別さ」を持った料理でもあります。そういった特別さも含めて、最も好きな料理の一つです。
ただ一方では、その特別さにも関係するのですが、今まではあまり自分で作るという発想がない料理の筆頭でした。普段からほぼ毎日料理はしているので、料理自体と縁遠いというわけではないのですが、寿司に関しては無意識的にどこか自分で作ってはいけない気がしていたものでもあったのです。
ですが、よくよく考えてみれば寿司も料理です。ふとしたときに、「あれ、別に作ってもいいんじゃない？」と思った時からワクワクし始めて、気付いたらAmazonで包丁とまな板と寿司桶を購入していました。
寿司の構造とプロセスを読み解く
まるで魔法のように板前さんの手から現れる寿司は、宇宙の法則をねじ曲げているように見えることもあります。実際本当に美味しいお寿司からはコスモパワー的なアレを感じることがありますが、それは寿司ではなくて頭の方がどうにかなってるだけなので問題ありません。
寿司はちゃんと物理法則に従っていますし、その基本構造は至ってシンプルです。しかし、最終形がシンプルであるということは、それだけ途中経過のプロセスに全てが詰まっているということでもあります。
最終的な構成要素はネタとシャリです。問題は、それをどのように組み上げるかということです。成り立ちを分解することで、組み上げるプロセスが見やすくなります。
プロセスがわかったので、次は個々のステップに目を向けます。プロセスを完了するためには、全てのステップを実行できなくてはいけません。
各ステップでの作業に要求されることとして、知識と技術があります。知識というのは、文字通り頭で方法を知っているということ、技術というのは、体で動作や感覚を知っていることを指しています。図中に付けた「知」と「技」の印は、そのステップで要求されていることが、知識なのか技術なのかを示しています。
知識のみが必要とされるものは、一度やり方さえわかってしまえばできるものです。これには、「合わせ酢の配分」などが当てはまります。対して、技術のみが必要とされるものは、知識はあまり必要なくても、体で動作や感覚を身に付けなければいけないものです。これには、「一定量のシャリを手で測りとる」などが当てはまります。
もちろん、両方が必要とされるものもあります。これには、「魚を捌く作業」などが当てはまります。知識については調べればできるようになりますが、技術については反復を通して習得することが必要です。
そのため、最初は習得しなくてはいけない技術がなるべく少なくて済むように、かつなるべく品質が下がらないように工夫することが大事です。やり方としては二通りあって、補助してくれる道具を使うか、あるいはステップそのものをスキップするかです。
例えば、前者としては、酢飯を作るステップで扇風機を使ったり、シャリをとるステップで測りを使ったりできます。後者は、魚を自分で捌かないで刺身の柵を買ってくるというのがあります（何も無理して捌くことはないので）。
これで、必要とされる技術を「切る」「握る」の二つに絞ることができます。
技術にはゴールイメージが大事
さて、知識が必要とされるものは調べるとして、技術を高めるにはどのようにすればいいでしょう。これについても、まずは調べて、公開されている方法論から探ることから始めます。そこからは反復して自分の理想に近づけていく作業になります。
ここで重要になるのがどれくらい理想の寿司を思い描けているか、つまりゴールイメージです。どんな形にしたいか、どんな味にしたいか、それがなければ精度の高いフィードバックができません。
僕たちは寿司職人ではないので、当然のことながら職場にいっても寿司を握っている人はいません。となれば、食べにいくしかありません。理想の寿司を求めて、美味い寿司を食べにいきましょう。
楽ができるように道具を揃える
プロではないので、なるべく楽ができるように道具を揃えます。観点としては主に二つで
- 実行時のコストをなるべく下げる （作業が楽になる道具）
- メンテナンスコストをなるべく下げる （手間のかからない道具）
つまり、考え方はシステム開発と同じです。エンジニアの皆さんは得意だと思います。
1に関しては、プロセスの中でボトルネックになり、かつ事前準備では対処できない作業が最も大きなコストになります。その作業を楽にしてくれるような道具があると嬉しいです。それ以外にも、ちょっとした手間を省くような道具はこれに当たります。
2に関しては、あまり道具として手間のかからないものが最初はいいということです。具体的には、鋼製の包丁などがあたります。たしかにちゃんとメンテナンスすれば道具としての性能は高いのですが、慣れてない人間がいきなり面倒をみるのは大変です。身の丈にあった道具を選ぶことをオススメします。
以下では、楽にするための２観点で買って良かった道具と、その他使っている道具をご紹介します。
作業が楽になる道具
小型扇風機
酢飯をつくる時に便利です。煽いで冷ましながら混ぜるとよく言いますが、前述の通り、慣れないうちは大変です。
しかも、米は冷めてしまうと澱粉質が固まって味が染みづらくなってしまうので、熱いうちに混ぜなくてはいけません。一方、あまり温度を下げるのがゆっくりでも、今度はベチャベチャになってしまいます。
しっかり味が染みて、食感が悪くない酢飯にするには、熱いうちに手早く冷ましながら混ぜる必要があります。冷ますのは扇風機におまかせして、熱いうちに手早く混ぜることに集中するのがオススメです。
大きめのまな板
まな板は切るだけではなく、切ったネタを置いておけるだけのスペースがあると非常に便利です。「切る」と「握る」の作業のスイッチングコストは思ったよりも大きく、無視することはできません。
とくに、ある程度の人数に対してある程度の量の寿司を握ろうとすると、いかにスイッチングコストを減らすかが勝負になってきます。僕の場合は7人x12貫をやったのですが、一度に1種類分しか切って置いておくことができなかったので、相当大変でした。
クッキングスケール
慣れてしまえば必要なくなりますが、最初はシャリの量を均一に揃える感覚を掴むためにあると非常に便利です。熟練の職人はシャリの米粒の量まで同じ、といいますが、米一粒のサイズは大体同じなので理想のg数に寄せられれば大体同じ量にはなります。
握っては測り、握っては測り、とやっているうちにわかるようになっていきます。要は手に感覚を持たせる作業なので、ひたすら反復と計測を繰り返すことで身に付けられます。
スシローなどでは15-16gくらいだそうですが、僕は握ってみたサイズ的に13gくらいが好きだったのでそこに感覚を合わせにいきました。
手間のかからない道具
刺身包丁（ステンレス）
前述の通り、鋼製のものより切れ味は落ちますが、メンテナンスコストのかからなさが段違いです。鋼製の包丁を導入するタイミングは、最終的な寿司の出来栄えを左右する品質のボトルネックが包丁の切れ味になってからでも全然遅くないと思います。
片刃包丁用の研ぎ器
こちらはステンレスでも鋼製のものでも使えるものを買うと便利です。
その他の道具
寿司桶
ボウルのように窄まった構造の容器で作ると、底に水気が集まって溜まってしまいベチャベチャになりやすいのですが、寿司桶のように平らだとそういったことも起きないのでオススメです。蓋もあると便利です。
寿司酢
好みによりますが、赤酢が好きなので次の二つを1:1で混ぜて使っています。
美濃三年酢
帝釈の酢 【後藤の赤酢】
まとめ & アドベントカレンダーについて
この記事では、ソフトウェアエンジニアがふと思い立って寿司を握り始めてから、実際に人に振舞うようになる過程で学んだことを紹介しました。具体的な作り方については、続きとして「実践編」を書く予定ですのでそちらで言及できればと思っています。
ちなみにこの記事は僕が働いている会社のアドベントカレンダーの1発目ですが、誤解なきよう申し上げておきますと、弊社は食品を扱う会社ではありません。
僕たちはWellというHR SaaSを開発しているスタートアップです。SlackやTeamsなどのコミュニケーションツールのデータから、従業員の状態を予測し可視化するというプロダクトを開発しています。
僕はVPoE/エンジニアとして、アプリケーションからデータ基盤まで、サービスのシステム全般を見ています。弊社は開発メンバーが3人しかいないので、技術系のアドベントカレンダーというわけではないのですが、ワイワイ楽しくやっているので良かったら覗いていってください。
楽しんでいただけたら幸いです。
Discussion