食品衛生責任者になりました
個人の日記どころかチラ裏のメモ。
食品衛生責任者とは
一般社団法人東京都食品衛生協会によれば、
食品衛生法施行条例第２条の公衆衛生上講ずべき措置の基準及び食品製造業等取締条例第６条の衛生管理運営基準により食品衛生責任者の設置として「営業者は、許可施設ごとに自ら食品衛生に関する責任者となるか、当該施設において従事者のうちから食品衛生責任者１名を定めておかなければならない
とのことです。
簡単に言うと、飲食店などにおいて衛生に責任を持つ人という感じでしょうか。
1日（6時間程度）の講習を受けることで食品衛生責任者になる資格を得ることができます。
動機
今までにも衛生面には注意しながら料理してきたつもりですが、最近は自分が料理したものを多くの人（100人とか）に食べてもらう機会が増えてきて衛生面が本格的に気になってきたので、勉強ついでに取っておくかというくらいの気持ちで受講することにしました。
「とりあえず徳丸本を読んでおこう」くらいの気持ちです。
別に飲食店を開業する予定はありません。
受講まで
受講するにあたっていくつかつらみがありました。
- 講習会が平日の日中にしかやってない
- 申込み方法が郵送のみ
講習会が平日の日中にしかやってない
「ぐおお、お役所……」となりつつも、有給は余っているので特に問題なく参加。
申込み方法が郵送のみ
Web に日程表が公開されてるんですが、この日程表を見た上で、用紙に第3希望まで記入して郵送するという感じになっていてつらい。
受講
情報処理試験とかと同じで、一番難しいのが起床。
そして、09:30には受付を終わらせておく必要があるため、通勤時間とぶつかって電車がつらい……。
午前（09:45-12:45）
衛生法規と公衆衛生。
衛生法規は保健所がやっている仕事とか営業許可の審査基準とかがわかって面白かった。ただ、営業許可の審査基準については「これ満たしてない店いっぱいあるやろ……」という感じがした。
公衆衛生で面白かったのは水道水の管理について「ここまでは水道局で、ここからは各事業者」みたいな責任分界点みたいなのが定義されていて、言われてみるとそうなんだろうけどなるほどなという感じ。
午後（13:30-16:30）
午後はまるっと食品衛生。
食中毒の主な原因をざっとながめていく。大きく分けると、
- 微生物が原因のやーつ
- 化学物質とかが原因のやーつ
- 自然毒が原因のやーつ
- 寄生虫が原因のやーつ
という感じ。
この中でも微生物が原因のやつが食中毒の9割を占めているらしく、ノロウィルス、カンピロバクター、サルモネラ、出血性大腸菌、黄色ブドウ球菌、腸炎ビブリオ、ウェルシュ菌、セレウス菌、ボツリヌス菌なんかが紹介される。
化学物質は洗剤とか消毒剤の混入の他にも、魚類の腐敗によるヒスタミンもここに分類されるらしい。
自然毒はキノコとかフグとかソラニン（ジャガイモの芽）でわかりやすい。
寄生虫はアニサキスが圧倒的。ここ数年、アニサキスが原因の食中毒が増えてて原因の第3位になっているらしい。
結果
食品衛生責任者になる資格を得た*1とともに、食品衛生責任者手帳を受け取りました。
飲食店などで見る青いプレートは追加課金アイテム（800円）なんですが、せっかくなので買ってみました。 週明けに出社したときにテプラで自分の名前を貼りたいと思います。
講習を受けてみた感想としては「微生物（特にノロウィルス）、マジこえーな」という感じです。
食品衛生責任者資格、わりと面白いし（知識の更新とかは適宜やっていく必要はあるものの）面倒な更新とかはないのでみんな取ってみれば良いんじゃないかな。
余談
このエントリの URL を考えるために「食品衛生責任者 英語」でググったところ「food hygiene manager」というのが出てきて「ハイジーン・オフィサーじゃん！」となりました（アルファコンプレックス脳）
*1:つまり、タイトルは微妙にウソです。
s-dev talks についての個人的お気持ち
少し前から s-dev talks というサービス開発について話すイベントをやっていて、organizer のひとりとして参加しています。
第2回も終わって一旦落ち着いたので、このイベントについて抱いている気持ちについて書いてみようと思います。
はじめに
これは僕個人の気持ちです。 僕が思っていることを書きたいように書いています。 s-dev talks 公式の見解や声明などではありません。
こういう考えを持った人間が現時点で organizer にいるのは事実ですが、今後 s-dev talks が向かっていく先は他の organizer との議論や参加者からのフィードバックを元にして決まっていくはずです。 フィードバックお待ちしています 🙏
s-dev talks とは？
Connpass のグループページから引用します。
以下のようなコミュニティです。
s-dev talks はサービス開発者の草の根コミュニティです！
ここでの「サービス開発者」は良いサービスをつくりたいと思っているすべての人を意図しています。 典型的にはプロダクトオーナー、ディレクター、デザイナー、エンジニアなどが含まれますが、そういった人たちに限らず多様なバックグラウンドを持った方に来てほしいと思っています。 我々は「良いサービスをつくるためには様々なスキルを持った人たちが協力し合う必要がある」と考えています。
s-dev talks はあらゆる垣根を越えて、サービス開発のためのスキルや知見をカジュアルに共有できる場を目指しています。
Organizer は僕 @s_osa_ の他に @spicycoffee66、@ukstudio、「とくなり餃子大好き」こと @to9nariyui でやっていて、諸々のグラフィックデザインを @tomoya_tsuji_ に手伝ってもらっています。ありがとう。
#1 「仮説検証」、#2 「チームビルディング」と順調に回を重ねています。
s-dev talks をつくった理由
厳密には「s-dev talks をつくるのに乗っかった理由」です。 発起人をひとり選ぶなら @spicycoffee66 だと思うので。
さて、肝心の理由ですが、だいたいは上の引用文に書かれている通りです。 上の文章は僕が叩きをつくって organizer のみんなにいろいろ修正してもらいました。
と、これで終わらせるのもアレなので、もう少しだけ詳しく書いておきます。
チームにはサービスをつくる上で生じる課題を解決するために、いろいろなスキルや視点を持った人が集まっています。 僕だったらエンジニアリングという専門性を持ってチームに加わっていますし、デザインやマネジメントをはじめとして、みなさんそれぞれの専門性を持って加わっているでしょう。
「フレンズによって得意なこと違うから」
これがチームを組んでサービスをつくる主な目的だと思います。
しかし、いろいろなスキルや視点を持った人が集まっている一方で、我々は全員「ユーザーの課題を解決するサービスをつくる」という目的の下に集っています。
持っているスキルや視点は違えど、最終的な目的は同じです。 そのために同じ方向を見て、同じものを思い描いて、チーム全員で「良いサービスをつくる」ということを考えていく必要があります。
こうして考えたときに、前者の各専門領域については勉強会などが活発に開催されていますが、後者の「サービスをつくる人」が集まるイベントがあまり見当たらなかったので「じゃあ、つくるか」となりました。
s-dev talks をどういう場所にしたいか
いろんな人が集まる場所
いろんなところに書いているように、様々なバックグラウンドを持った人が集まる場所にしたいです。
「全員『サービスをつくる人』だ！ バックグラウンドなんて関係ない！」という気持ちがある一方で「望むと望まざるとにかかわらず、それぞれの専門によって見えているものが違う。ある人の当たり前が他の人にとってそうではないことは結構ある」という気持ちがあります。
現時点ではまだまだ Web 界隈のエンジニア・デザイナ・PO・PM といった人たちが多いですが、業種も職種も飛び越えていろんな人に来て欲しいし喋って欲しいと思っています。マジで！！！
いろんな人に届けられる場所
サービスをつくっている人たちに聞いてほしいことがあったときに、それを効果的に伝えられる場所にしたいと思っています。
実は大阪の人から「中継とかはないんですか？」といった問い合わせも貰っていて*1、そういう意味でももっといろんな人に届けられるようにしたいと考えています。
勉強会というよりコミュニティ
「s-dev talks 〜サービス開発勉強会〜」と銘打っていますが、「勉強会」という感じにはしたくないなと思っています。
学びがあるのはもちろん良いことですし、過去のイベントではいろんな学びがあったんですが、いろんな目的で来る人がいて良いと思っています。
そのときどきで抱えている課題を懇親会で相談する人がいても良いと思いますし、他の人が難題に立ち向かっている姿を見て元気をもらうのも良いと思います。
明日の行動が少し変わる場所
s-dev talks で話されることは必ずしも「すごいこと」じゃなくて良いと思っています。
世の中には日々試行錯誤しながらサービスをつくっている人たちがたくさんいます。 そんな人たちが現場で得た学びや気付きを共有することによって、他の人の「これ試してみよう」とか「明日、チームの人に話してみよう」といったアクションにつながれば良いなと思っています。
小さな行動がたくさん生まれる場所にしたい。
おわりに
以上、現時点での個人的なお気持ちを書いてみました。
s-dev talks 〜サービス開発勉強会〜 #3 「ユーザーインタビュー」の募集が始まっています。以前からの 5分枠（LT）に加え、今回から20分枠も公募になったので、ご応募お待ちしています！！
Slack で簡単かつ公平にくじびきをする
前に書いた「Ruboty でくじびきをする」というエントリの続編です。
何をつくったのか
Slack の slash command を使うことによって、簡単かつ公平にくじびきをできるものをつくりました。
なぜつくったのか
日常にくじびきをしたいシーンは結構あります。
たとえば、issue の assignee を決めるとか、飲み会の予約をする人を決めるとか。弊社でよくあるのだと、ランチのためにご飯を炊く人を選ぶなんていうのもあります。
そういったケースで公平にくじびきできるようにするために、2年ほど前に ruboty-kujibiki という gem を書きました。
この gem は社内の Slack で今も便利に使われていますが、当然ながら「Ruboty がいるところでしか使えない」という問題があり、別の Slack workspace で「くじびきしたい！」となったときに「ここ Ruboty いないじゃん……」となることが結構ありました。
とはいえ、いろんな Slack に Ruboty を入れて回るのは面倒すぎるので絶対にやりたくない。
そこで、Slack App にしてサクッと入れられるようにしました。
使い方
/kujibiki {number} from {comma-separated-elements} でくじびきを行なうことができるようになります。
その他の使い方は /kujibiki help で見ることができます。
インストール
下のボタンをポチッとするとインストールすることができます。
なお、現時点では Slack の審査を通せていないので Slack の App Directory には表示されないですし、認可画面にも「This app hasn’t been reviewed or approved by Slack.」と表示されてしまっています。
どうやって動いているか
全然大したことはしてないんですが、簡単に。
Slack command が実行されると、事前に登録してあるエンドポイントに対して POST リクエストが飛んできます。
このリクエストに対してレスポンスを返すと Slack command の結果として表示されるんですが、今回はこの API を AWS の API Gateway と Lambda (Node.js) で実装しています。
API Gateway と Lambda を選んだ理由は以下のようなものです。
- 複雑なことをしていない
- いかなる状態も持たなくて良い
- サーバー代を払いたくない 💰
今後の課題
自分が使えればいいやという感じでつくっていて細かい処理を全然実装してないので、そのあたりをちゃんとしないといけないのと同時に、せっかくなのでちゃんと Slack の App Directory に登録したいと思っています。
ただ、App Directory 登録のためには審査があり、
- アイコン
- インストール説明用ランディングページ
- プライバシーポリシー
- サポートページ
- サポート用メールアドレス
あたりを用意する必要があります。
いい感じのアイコンとか LP を用意するの厳しいなという気持ちがあり、さらにテキストはすべて英語で用意する必要があって「英語のプライバシーポリシーなんてどうすればいいんや……」と途方に暮れています。
おわりに
Slack でくじびきをするためにつくった slash command について紹介しました。
「使ってみたよ」とか「なんか壊れてる」とかあれば @s_osa_ まで連絡していただければと思います。
もし、「アイコンつくるよ」とか「LP デザインするよ」とか「英語のプライバシーポリシー書けるよ」という神がいたらそちらもよろしくお願いします 🙏
