『発酵食品の歴史』を読んだ。
さまざまな発酵技術、発酵食品が近代化に伴ってどう変化していったかを語る本だった。
裏テーマとして、「伝統的で多様な発酵食品 vs 大量生産されたつまらない食品」という対立構造があった。これは客観的にそうだ、というよりは著者の意見にすぎないが、量産品が似通った味で飽きやすく、発酵食品の味が多様になりやすいのは事実だろう。私も大量生産された食品はつまらないと思う。
量産食品なしでは生きられなくなった我々
おいしくて栄養のある家庭の発酵食品は産業革命とともに失われていった。みんな働くようになって時間がなくなったからである。家事をする時間がなくなり、買ってきたものを食べるようになったのだ。
また、公衆衛生意識を向上させたい政府の思惑と量産食品を売りたい企業の要求が結びついた側面もある。当時は「家庭の発酵食品＝汚染されていて危険」「工場で作られた食品＝衛生的」というプロパガンダが広告されていた。
現代では逆に量産品への不信感をもつ人たちもいる。添加物が云々、遺伝子組み換えが云々。その結果として、家庭でなんでも作り、実際に汚染された食品を作ることがあるのは皮肉である。特に発酵は、ちゃんと手順を守らないとたしかに危険な食べ物になるのだ。
発酵は微生物培養なのでたしかに危険
発酵食品を作るうえで気をつけることは、このnoteが参考になる。特に危険なのは大腸菌とボツリヌス菌だろう。
料理をするとき、肉と土による汚染にはじゅうぶん気をつけないといけない。肉と野菜を同時に扱わないのは当然だが、土も汚染源であることに注意する。
我が家の発酵趣味
ザワークラウト
ザワークラウトを仕込んで10日経った。最初の1週間はただの酸っぱいキャベツだったが、7日経ったあたりから急においしくなった。
上記の本によると、ザワークラウトはphが下がると主役の乳酸菌が変わるらしい。最初は乳酸球菌が糖をすべて乳酸に変える発酵をするのだが、そのうち乳酸桿菌が出てきて乳酸以外の物質も作るようになる。ここで作られる物質が香味と旨味に寄与するのだろう。
12℃という低温で発酵させているおかげなのか、雑味がほとんどない。代わりに酸度は高くないのだが、むしろ食べやすくてよい。というかめちゃくちゃおいしい。
今回はドイツ式のレシピにならってキャラウェイシードを入れているが、別になくてもよいような気はする。次はイギリス式でリンゴなどを入れてみたい。
パン
私ではなく妻氏がずっと続けている。2021年の5月くらいから作り続けているのでもう1年やっていることになる。
パンを作り始めて最初の10ヶ月くらいはおいしいけどまだまだだなあ、という仕上がりだったのだが、最近になって高いレベルで安定してきている。売り物でありそうな味になってきた。
きっかけはこの本を買ったこと。中古でしか手に入らない絶版本だが、レシピが具体的でパン生地のたたみ方が丁寧に解説されていてよかった。
安定してよいパンが作れるようになったので、今は発酵条件や粉、イーストの量を変えて遊んでいる。発酵温度と粉の種類が大事な気がする。リスドォルはうまい。
ワイン
作るだけでなく飲むのも発酵の楽しみである*1。
発酵のためにワインセラーが導入されたのでワインを常備するようになった。もともと二人ともワインが好きなのでちょうどよかった。
推測するな計測せよ
『ワインの科学』という本によると、温度によって苦味や甘味の感じ方が変わるらしい。苦味や甘さをいい具合にするために温度管理をしている。
ただ、味の好みとは主観的なものである。本やインターネットで何が言われていようと、自分がおいしいと思ったらそれが正しい。なので、ワインの温度も自分で探求しないといけない。
そこで実際に測る方法を考えた。赤外線式の体温計である。ワインをグラスに注ぎ、おいしいと思ったタイミングで温度を測るのだ。
この方法はワインだけでなく、ビールとかジュースにも使えるはずだ。
雑記
- アウトライナー自作プロジェクトでテストを書きたくなった。
現代フロントエンドのテストは何を使えばいいのかなーと思って調べていたら、power-assertがあるのを思い出した。
rspecみたいな記法よりassert記法のほうが好みだ。仕事で書いてるgoでもtestifyというライブラリでassert記法のテストを書いている。if err != nil 云々のテンプレ3行がassert.nil(t, err)になるのでたいへん便利だ。
jsのpower-assertのメンテナはフロントエンド界隈でよくみるアイコンだらけだったので安心して導入した。
- 業務Slackで毎日Huddleを立てている。目的は雑談とか突発相談、フリー1on1など。
たいてい人は来なくて、ただ店を開けているだけである。人は毎日来なくてもよくて、開かれているのが大事。
ところが、今週は一気に2人来てしまった。ふだん在宅勤務でコミュニケーションが足りていないのか、たいへん盛り上がってしまう。楽しいのだが疲れてしまうのだった。
一人で考えていると思考がドツボにハマっていくので、他人と会話することで、ちゃんと前に進めることができるよねみたいな話をした。新しい視点や情報を仕入れると思考や行動が変わりうる。
- Realforce R3を買った。4端末までペアリングできて、切り替えがFn ＋ 1〜4のワンアクションなのがめちゃくちゃ便利。
キー加重は30gにした。変荷重モデルからの移行なので軽くなってしまうが、それでよかった。 キーボードは一日中触っている道具なので、いいものを使うのがよい。
- HDDを分解して捨てた。
HDDは物理破壊が一番だとされているが、穴を開けるのはたいへん。とはいえ、破壊業者も信用できるかどうかわからない。
なので、分解してプラッタを抜くのがよい。特殊ネジセットを買っておけばだいたいなんでも分解できる。プラッタは傷をつけて燃えるゴミで捨てる。
HDDはシールに隠れたネジが何箇所かあるので注意して探しましょう。副産物として超強力磁石が手に入る。たのしいおもちゃだが、スマホなどには近づけないように。
他者を啓蒙するより、他者が見ているものを観察する
分散システムの問題、経済学の合成の誤謬には共通する構造があると思う。「個々のエージェントがてきとうに行動したらシステム全体として失敗していた」という性質だ。
複雑なシステムはエージェントがやりとりをしているもの
エージェントとは、システム構成要素のサーバでもよいし、個人でもよい。システムのなかにエージェントが複数いて、エージェント同士で情報のやりとりをしていたらこの構造が適用できる。
この世の難しい問題はだいたいこの構造をしている。複数のエージェントがネットワークを作っており、全体としてわけのわからない現象が起きている。生体内の化学反応群や発酵、社会組織の文化など複雑すぎて分析しきれていないものは多い。
エージェントとシステム全体の視点は別
これらのシステムが「失敗」したかどうかを判断しているのは、エージェントとは別の視点である。エージェントそれぞれにとってシステム全体の「失敗」は関係のない評価基準だ。知ったことではない。
エージェントが行動をしているそのときどきには「システム全体」という評価は成立しない。エージェントの行動が合成されて出てきたのが「システム全体」であるから。
どうやって全体最適にするか
それでも複雑なシステムを制御したがるのが人類だ。どうにかして全体最適を実現したい。分散システムもそうだし、経済学での個人の経済活動もそう。会社組織で個人が最適な行動をしているのに、部署全体としては何かがうまくいかないこともある。
エージェントをかしこくするのはうまくいかない
素朴に考えると、エージェントをかしこくするアプローチが思いつく。
しかし、かしこいエージェントの集まったシステムが失敗をする事例はたくさんある。
（広い意味での）官僚制がよい例だ。優秀な労働者を集めても、人事制度や組織構造によって組織はうまく動かなくなる。分散システムであれば、ネットワーク分断の前にはどんなかしこいエージェントも無力であろう。
おそらく、エージェント個々の能力よりも、エージェントのネットワーク、依存関係が大事なのだろう。
ネットワークのどこかに制御点がある
科学ではエージェント間の依存関係を捨象することが多い。依存関係が難しすぎるからだ。だが、実際には依存関係がある。分子は独立して漂っているのではなく、何らかの磁場、電場、重力の影響を受けている。SNSでは数万フォロワーをもつ人が大衆を動かしている。
われわれは、エージェント・ネットワークのなかのハブ、制御点を見つけて「構造を見抜く」とか「これが本質だ」と言っている。「権力」のポイントを見つけ、そのエージェントを動かすのが、システム全体を制御する効率的な方法なのだろう。
発酵だとpHや塩分濃度、温度管理がそれにあたる。塩分濃度という制度設計によって、雑菌のみを選択的に弱らせることができるのだ。雑菌エージェントの活動はこれらの環境条件に依存している。
余談: 環境とエージェントの関係
ところで「環境」はエージェント・ネットワークとどういう関係にあるのか。組織構造はネットワークとして記述できるが、「環境」「電場」「人事制度」はネットワークではない。所与の条件だろうか。エージェント全員が影響を受けている、前提としての依存関係。
もちろん、より広い視点へと移動すると、「環境」もエージェントが作るものになる。電場は電子やイオンが作っているし、人事制度もあるエージェントたちが設計している。われわれは、ある特定のシステムに注目するとき、所与としてよい条件があればそれを環境と呼ぶのであろう。
まとめ
社会組織ではエージェントをかしこくするよりも、エージェント間の依存関係を分析し、どの依存関係が影響を与えやすいかを分析したほうがいいと思う。
他者の行動を変えるのはたいへん難しい。他者を変えるよりも、部署内のエージェント（同僚）が何に影響を受けているのか、依存関係を分析するのが大事ではなかろうか。
設計が好きだと言っていたが、もっと抽象化された
10年くらい前は設計が好きだ、と言っていた。現職の最終面接でも
「設計が好きです」
「設計にもいろいろなレベルがあるが、どれが好きなのか？」
「全部です」
「ほんまか〜」
というやりとりをした覚えがある。
今考えても、設計が好きなのは間違いない。それがどのレイヤでも楽しめるのも、本当にそうなのだ。そう答えるしかない。
数年前からは「設計が好き」ではなく「問題解決が好き」と言うようになった。これは哲学を始めた影響である。設計という営みをより一般化して捉えている。
さらに、最近になって自分の欲望をより抽象的に捉えられるようになった。「問題解決」ではなく、「複雑なものの構造を明らかにすること」が好きなのだ。複雑なものとは、依存関係がぐちゃぐちゃになっている現象である。
複雑なのはお仕事の混みあった要件もそうだし、社会そのもの、そして自分自身や他者もそうである。これらの複雑なものがどうなっているのか？を問うて本質的構造を知ってゆくのが私の趣味であり生きがいなのだろう。
そういえば幼少期から好奇心が強いと言われていた。好奇心が順当に育った結果、なんでも構造を分析するようになったのかもしれない。
