より信頼できるクエリを書くために、SQLでもテストを書く

はじめに

こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。
今日はSQLについてです。
弊社に入社してから毎日のようにSQLのクエリを書いてきました。
クエリを書き始めてからもう3年が経とうとしています。
日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。
僕は

• 正確で
• 読みやすく
• 再利用しやすいクエリを
• 高速に

生み出すための工夫を重ねてきました。
結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。
似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。

対象読者

対象読者は、分析のためにクエリを書いている人とします。
プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。

痛み

クエリを日々書いていると書きたいものが書けているか不安になることはないでしょうか？
僕はそういう気持ちになることは頻繁で、とくに慣れていないテーブルや新しいパターンの集計を行うときなんかは、クエリの隙間に select hoge from foo などと書いて一部実行して目で確認するということをよく行います。
「nullはないよな？」「xxxに対してユニークだよな？」「xxxはマイナスにならないはず...」 などなど心配事は多岐に及び、さらに複雑になるほどその数は増えていきます。
そうやって一つ一つを確認していきながら丁寧に書いたクエリは、時間が立つと行数も増え、何を確認して何を確認していないかがあやふやになり、不鮮明な不安が積もるのは必須です。
コメントで確認したことをメモしていても、クエリ前半で確認が取れていたことが、クエリの後半でも担保されているかは別問題ということもよくある状況でしょう。(予期しない動作のjoinにより前半部分では存在しなかったnullがクエリの途中から追加されていた。など)

再利用するときにも苦しくなるときがあります。
このクエリはどこまで信用できるんだっけ？といった不安がつきまといます。
クエリを書いている時間は、ワーキングメモリに可視化されないクエリの事情が脳内に展開されていますが、1ヶ月後に見たときにはどこまで信用して良いものかわからないのが常です。
クエリというものは常にそうした不安と付き合いながら分析していくものだとは思いますが、こういう痛みを弱める工夫はあってもいいでしょう。

ということで、僕の場合はこうしているよというのを紹介してみます。
少なくとも僕はこの方法を取ることによって、

• より高速に
• より正確性の有る

クエリを書くことができています。
加えて後で読んだクエリの品質の把握も容易にできていて上記の痛みはかなり解消されたと実感しています。
それでは少しずつ説明していきます。

クエリにテストを書く

上述した痛みを解決するために行っているクエリに書くテストを例を交えながら紹介していきたいと思います。
今回はBigQueryで書いていますが、その他でも同様なことはできます。(把握している限りですが)

題材としてECサイトのテーブルを想定します。
テーブルは、usersとshoppingの二種類。
前者はユーザそれぞれの情報で、shoppingはそのユーザの購買行動を記録しています。

user_id	name	age	registered_date
1	aaa	25	2023-01-01
2	bbb	30	2023-01-01
3	ccc	20	2023-03-01
4	ddd	43	2023-07-01
5	eee	18	2023-12-01

shopping_id	user_id	amount	shopping_date
1	1	1000	2023-01-01
2	3	2000	2023-03-04
3	3	1500	2023-04-10
4	1	1000	2023-05-01
5	4	5000	2023-07-02
6	4	3000	2023-10-15

だれでも手元でイジイジできるように with句でCTE(Common Table Expression)化しておきました。

with users as (
SELECT * FROM UNNEST([STRUCT<user_id INT64, name STRING, age INT64, registered_date date>
    (1, 'aaa', 25, date('2023-01-01'))
    , (2, 'bbb', 30, date('2023-01-01'))
    , (3, 'ccc', 20, date('2023-03-01'))
    , (4, 'ddd', 43, date('2023-07-01'))
    , (5, 'eee', 18, date('2023-12-01'))
    ])
)


, shopping as (
SELECT * FROM UNNEST([STRUCT<shopping_id INT64, user_id INT64, amount INT64, shopping_date date>
    (1, 1, 1000, date('2023-01-01'))
    , (2, 3, 2000, date('2023-03-04'))
    , (3, 3, 1500, date('2023-04-10'))
    , (4, 1, 1000, date('2023-05-01'))
    , (5, 4, 5000, date('2023-07-02'))
    , (6, 4, 3000, date('2023-10-15'))
    ])
)

20歳以上のユーザの合計購入金額を出してみます。

with users as (
SELECT * FROM UNNEST([STRUCT<user_id INT64, name STRING, age INT64, registered_date date>
    (1, 'aaa', 25, date('2023-01-01'))
    , (2, 'bbb', 30, date('2023-01-01'))
    , (3, 'ccc', 20, date('2023-03-01'))
    , (4, 'ddd', 43, date('2023-07-01'))
    , (5, 'eee', 18, date('2023-12-01'))
    ])
)


, shopping as (
SELECT * FROM UNNEST([STRUCT<shopping_id INT64, user_id INT64, amount INT64, shopping_date date>
    (1, 1, 1000, date('2023-01-01'))
    , (2, 3, 2000, date('2023-03-04'))
    , (3, 3, 1500, date('2023-04-10'))
    , (4, 1, 1000, date('2023-05-01'))
    , (5, 4, 5000, date('2023-07-02'))
    , (6, 4, 3000, date('2023-10-15'))
    ])
)

-- ここから分析クエリ

, users_over20 as (
select *
from users
where age>=20 
)

, tbl_agg as (
select
    u.user_id
    , max(u.age) as age
    , sum(s.amount) as total_amount
from users_over20 u
left join shopping s on u.user_id=s.user_id
group by u.user_id 
)

select *
from tbl_agg

結果

というまぁ簡単なクエリですが、これが大規模で全数を目視できなかったり初めて使うので元のテーブルへの理解が十分でないと想定して、確認作業というものをやっていこうと思います。
今回は、users.ageに nullはないか？、 tbl_agg.total_amountにnullはないか？ を確認していこうと思います。
users.ageに関しては、ユーザの自由記入欄でnullになっているかも？とかそういう目線での疑いです。
すでにわかっていることですが、total_amountにはnullがあります。shoppingテーブルに存在しない→購買行動を行っていない、のでこれは0とするのが適切な処理でしょう。
こうあるべき を確認してクエリの品質を担保していきます。

users.age に nullがないと確認するのはどうやるべきでしょうか？
通常であれば、CTEとCTEの間に select ... from ... と書いて部分実行するか、別クエリで確認するなどでしょう。
total_amountの確認も同様かと思います。

テストを行うために tbl_agg の CTE と 最後の select の間に test という名前のCTEを追加する形で書いていきたいと思います。
結論から言うと以下のようになります。

with users as (
SELECT * FROM UNNEST([STRUCT<user_id INT64, name STRING, age INT64, registered_date date>
    (1, 'aaa', 25, date('2023-01-01'))
    , (2, 'bbb', 30, date('2023-01-01'))
    , (3, 'ccc', 20, date('2023-03-01'))
    , (4, 'ddd', 43, date('2023-07-01'))
    , (5, 'eee', 18, date('2023-12-01'))
    ])
)


, shopping as (
SELECT * FROM UNNEST([STRUCT<shopping_id INT64, user_id INT64, amount INT64, shopping_date date>
    (1, 1, 1000, date('2023-01-01'))
    , (2, 3, 2000, date('2023-03-04'))
    , (3, 3, 1500, date('2023-04-10'))
    , (4, 1, 1000, date('2023-05-01'))
    , (5, 4, 5000, date('2023-07-02'))
    , (5, 4, 3000, date('2023-10-15'))
    ])
)



, users_over20 as (
select *
from users
where age>=20 
)


, tbl_agg as (
select
    u.user_id
    , max(u.age) as age
    , sum(s.amount) as total_amount
from users_over20 u
left join shopping s on u.user_id=s.user_id
group by u.user_id 
)


, test as (
select
    -- ageにnullがない
    case
        when exists(
            select 1
            from users
            where age is null
            ) then error('ageにnullが存在します')
        else '問題なし'
        end as test1
    
    
    -- total_amountにnullがない  
    , case
        when exists(
            select 1
            from tbl_agg as t
            where t.total_amount is null
            ) then error('total_amountにnullが存在します')
        else '問題なし'
        end as test2
)



select *
from tbl_agg
cross join test

結果は以下のようになりました。

total_amountにnullが存在するために、用意していたエラー文が出ました。

sum(s.amount) as total_amount を sum(case when s.amount is null then 0 else s.amount end) as total_amount とすると以下のように出力されます。

解説の前にポイントを軽く解説しておくと、

• test というCTE内で、別々のテーブルusersとtbl_aggの中身をチェックしています。クエリがどんなに大きくなろうと、このCTE testを起点にどこのテーブルにでも自由度高く確認ができるということです。
• このテストは、クエリを実行するたびに実行されるので、この時点では問題なかったが後の追加作業でバグが埋め込まれたとしても検知できます。
• さらに後日このクエリを読んだときに、どの程度のことまでが保証されているのか一目でわかります。
• 実行速度の問題もCTE のtestはselect一つ、つまり一行の実行で後にcross joinされます。そのため大規模な計算が行われることはありません。気になる場合は、cross join test をコメントアウトするだけでテスト実行がオンオフできます。

という感じのメリットがあります。

簡単な解説

select
    -- ageにnullがない
    case
        when exists(
            select 1
            from users
            where age is null
            ) then error('ageにnullが存在します')
        else '問題なし'
        end as test1

さてこれはどういう挙動をしているのでしょうか？
分析を普段からやっている人を対象とするので少々くどいと思いますがとりあえず解説していきます。

まず case 文があります。trueなら error(xxx) が発生してエラー文が出る。falseであれば、問題なしが出力されるようになっています。
true/falseを決めるのは exists() 。これはexists内のサブクエリに結果が帰ってこればtrueでそうでなければelseを返します。
今回は、users.ageにnullが存在しないので、サブクエリ

select 1
from users
where age is null

は何も返ってきません。結果として exists は falseを返すためエラーにならないという挙動です。

逆に test2のほうは、existsがtrueを返していたためにエラーが出たという仕組みでした。

解説完了です。

こんな感じであらゆるテーブルに自由度高く確認が行える点が強力だと個人的には思っております。
データ分析経験者であれば遭遇したことのある以下のようなケースにも対応できます。

• ユーザをいくつかのセグメントに分けたセグメントのユニークユーザ数の和が、もとの和と一致しない。(セグメントの分け方がMECEでない)
• ある単位でユニークだと思っていたが実は違っていて、left join 時に数倍に膨れ上がり想定の数倍の数値が集計された。　

などなど枚挙にいとまがないと思います。
こういう複雑なケースにも自由度高く対応できて、実際に何度も僕を救ってくれました。

クエリを書く流れ

クエリを書きはじめるときは、だいたい以下のようなテンプレートになります。

with const as (
...
)

, tbl1 as (
...
)

, tbl2 as (
...
)

, tbl_agg as (
...
)


, test as (
...
)

select *
from tbl_agg
cross join test

constに変数のようなもの、日付とかを書いて、tbl1, tbl2などで集計前のCTEを作成して、tbl_aggで集計、そしてtest内でテストを実行。
これが大まかな流れです。
testに書き込むタイミングはわりと好きなタイミングでやっています。
クエリって書いていると脳汁がドバドバ出て勢いで書けるときってありますよね？あのときのペースを邪魔したくないので、testにコメントだけを書いてあとからチェックするなど好きなタイミングで書くなどをよくします。

, test as (
select
    -- test1
    , case
        when ...
    
    -- tableA.col1にnullは存在しない
    
    -- tableB.hoge_at は 2022年以降のデータのみ存在する

    -- tableAのuuとtableDのuuが一致する
)

と開発過程はこんな感じで進むことは多いです。
確認していないことが可視化されるだけでも大きいです。

基礎編終わり

ここまでで何がしたいのかはわかってもらえたかと思います。
自分で気を張って監視をしなくても、常にクエリがそのクオリティを担保しようと働いてくれます。
クエリが複雑化し大きくなったとしても抑えるべきところは抑えている状態でクエリを書けるので心理的面でも大きな意味が有ると思います。
安心して、より難しいクエリを書くことに集中できます。

僕は結果的に

• より高速に
• より正確性の有る

クエリが書けるようになりました。

最初は慣れないと思いますが、慣れればこっちも悪くないと実感してもらえると思います。
実際に試してもらえると嬉しいです。
そしてより良い方法があればお互いに共有していければなと願っております。

とまあ一旦ここで締めるのですが、以降で少し発展的な例を起点に、あらゆるテストを行うことができることを主張した後、ある低程度体系化してみようと思います。 こういうテストはこういう書き方でできるよ的なことを書いてみます。

発展編

もう一つ違う例を書こうと思います。
ユーザ数は意図した数になっているか？を見ます。

具体的には、 users_over20 のユーザ数と、tbl_agg のユーザ数が一致するか？を確認します。
集計の手順として、users_over20で集計対象とする集団を作って、tbl_aggでユーザそれぞれにtotal_amountの情報を付与という手順を取っています。

users_over20 から最終的な出力まで、ユーザは増えも減りもしない前提ですが、この間にあらゆるjoinを行った結果user_idに対してユニークになっていなかったり、減っていたり増えていたりする事故は往々にしてあります。
今回の簡単なクエリであれば心配ありませんが、大きめのクエリを書いている気持ちになってこのタイプのテストを行います。

以前の２つのテストと大きく違う点は、2つのテーブルの集約値を比較すること にあります。
テストはこうなります。

, test as (
select
    -- test1
    -- test2

    -- users_over20 とユーザ数が一致しません
    , case
        when (select count(user_id) from users_over20) = (select count(distinct user_id) from tbl_agg) then '問題なし'
        else error('users_over20 とユーザ数が一致しません')
        end as test3
)

このように２つのテーブルをまたがって比較することも可能です。
自由度の高さを示す例の一つでしょう。

テストは大きく4種類に分かれると思っています。
軸が２つあり

• 1行単位の確認なのか？それともテーブルの集約値なのか？の軸
• 2つのテーブル同士の比較なのか？の軸

です。2つの軸で4象限あり、表にすると以下のような形になります。

	1つのテーブル	2つのテーブル
1行単位	A	B
集約値	C	D

4つの領域にA,B,C,Dと名前を振って例を示していこうと思います。

A: 1行単位 x 1つのテーブル

これは、最初に示した2つの例のことですね。
今回は、監視したい対象が負になっていないかを見ることとします。

, test as (
select
    -- colに負の値が存在しない
    case
        when exists(
            select 1
            from table1
            where col < 0
            ) then error('colに負の値が存在します')
        else '問題なし'
        end as testA
)

B: 1行単位 x 2つのテーブル

2つのテーブルの各行間を比較します。
これは経験上、そこまで多くないパターンです。
table1のcol1とcol2の和がtable2のcol1と一致するという例を書きます。

, test as (
select
    -- table1のcol1とcol2の和がtable2のcol1と一致する
    case
        when exists(
            select 1
            from table1 t1
            left join table2 t2 on t1.user_id=t2.user_id
            where t1.col1+t1.col2 = t2.col1
            ) then error('table1のcol1とcol2の和がtable2のcol1と一致しません')
        else '問題なし'
        end as testB
)

C: 集約値 x 1つのテーブル

これも頻出ですね。
例えば、すでにどこかで出た実績値と一致しているか見るとか、合計値が0になっているはずとかそういうときに使います。

, test as (
select
    -- col1の合計値が 1234 と一致する
    case
        when (select sum(col1) from table1) = 1234 then '問題なし'
        else error('col1の合計値が 1234 と一致しません')
        end as testC
)

D: 集約値 x 2つのテーブル

これは例で出したパターンですね。
セグメント切った前後がMECEか？などのチェックで活躍します。
例えば、ある月の購入額が3000円以上/未満のユーザの数 を数えるときに、あるユーザが3000円未満と3000円以上の購入をしたがために両方のセグメントに属してしまうなどあるあるではないでしょうか？
こういう考慮漏れが起こったときにテストが活躍して自分の問題定義の甘さが露呈します。
この場合は、 ある月の最高購買額が3000円以上/未満のユーザの数 が妥当でしょう。こうやって問がシャープになっていくことはよくあることだと思います。

, test as (
select
    -- table1のユニークなユーザ数とtable2の2つのセグメントのユニークなユーザ数が一致する
    case
        when (select count(distinct user_id) from table1) = (select count(distinct case when seg='A' then user_id else null end)+count(distinct case when seg='B' then user_id else null end) from table2) then '問題なし'
        else error('table1のユニークなユーザ数とtable2の2つのセグメントのユニークなユーザ数が一致しません')
        end as testD
)

やっと終わり

以上です。
これで頻出のケースは網羅できたかなと思います。
このテストを活用する方法は、日進月歩で育ってきました。
これが完成形ではないと思っているので、これからも発展させていくつもりです。
また共有できることがあれば書いちゃいます。

長いのに最後まで読んでいただいありがとうございます。
お礼に沖縄に遊びに来ていいよ券を置いてておきますね。

つ 🎫

本を一日一冊読むことに決めた

これは、僕が本を一日一冊読む生活を始めた話を書いたもの。

ちなみに、所属している会社(カンム)のアドカレ13日目を司っている記事でも有る。
昨日のやつはgai氏のイケイケ記事。
タイトルで興味が湧いた人はすぐに飛びつけばいいし飛びついて損はないと思う。

note.com

なぜはじめたのか

これを説明する事は僕にはとても難しい作業で、下手をすると説明不可能な事かもしれないなとも思う。
30歳になって焦っているのかもしれないし、単に今の生活に刺激が欲しかったのかもしれない。
きっかけはたしかにあったけど、基本的にはずっとやりたいと思っていた気もする。

そのきっかけってやつは、デザイナーであるしんぱち先生のブログ。

note.com

意識が高いわけではないのにものすごいエネルギーを感じる文章とその優しい人柄、そして狂気的な習慣にしびれたのをはっきり覚えている。
誰かのブログを継続的に読むなんてことのない人生だったが初めて誰かのブログの更新を楽しにしている。

詳細は割愛しつつ軽く紹介すると毎日のように映画を見に行き本を1冊読む生活をしながらも、本のデザインを年間200冊、同時進行の仕事は30~50冊こなしている。そんな感じ。
note.com

このブログをきっかけに「あぁ、そうだ、僕は継続の先の狂気に憧れがあったんだ」と思い出すことができた。
職人や学者など1を極めたものだけがたどり着ける境地に憧れがあった。
その道のスペシャリストとして活躍しているから憧れているというよりも、もう長くやっていてこれやる事以外は何も知らないから続けている、楽しいかと言われれば楽しいわけがあるかみたいなそんなイメージ。

誰に共感されなくてもいい。僕は人間臭い人間になりたい。

特に目的もなく何かを継続してどこかにたどり着けばいいと思う。
富や地位が向上する必要はない。人間臭くなれば良い。
今から始めれば30年後の60歳ぐらいには孫に「なんで一日一冊本を読んでいるの？」と聞かれたときにきっと「俺が知りたいね」と一蹴できる。
これは臭い。

ということで僕は新しい習慣「本を一日一冊読む」を始めた。

続けるために

昔から継続や習慣には強い興味があった。
正確には根が怠惰であるためにそういったものに頼らざるを得なかった。
故にノウハウと経験がある。
継続には僕なりのコツがある

1. 必ず毎日やること
2. ハードルを下げること
3. 記録をつけること
4. どうしようもない日のためにチートデーを用意すること
5. どうせ続かないを前提にすること

だいたいこんなところ。

こうやって身につけた習慣に「朝早く起きる」がある。
家庭があるので毎日はできていないけれども5時とかには起きて仕事を始めている。
僕の宝物の一つ。

1. 必ず毎日やること
これはとても大事。一番大事かもしれない。
週に1度とかいう習慣は最悪だと思う。
毎日の自分に選択肢 やるorやらない を与えその7つのうち6にはやらないを選択させることになる。
負け癖がつく。
1日でやろうとしてた目標を7等分して毎日やればいい。

2. ハードルを下げること
読書習慣がない人であれば、一日一ページとかで良いと思う。
僕は毎日読む習慣はあったので僕にとってはちょっと大変な1日1冊にした。
とはいえ普通に大変なので、平日は長くても250ページ程度の文庫本など今の実力にあった分厚さの本を選んでいる。

3. 記録をつけること
人間は、自分のもっているものを奪われる事や自分のパーソナリティが否定されたときにそれを守る方向に行動させる力学が働くらしい。
これがものすごく継続に効く。
僕は本を読んだらカレンダーに◯をつけ、Twitterに報告する。

37冊目　怠けた日3日
「代表的日本人」

今年だけで5回目ぐらい。
まじで最高の本。
一生読む。 pic.twitter.com/QQvqdX50fB

— fkubota🦉 (@fkubota_) 2023年9月19日

これを継続すると、自分に対して「僕は毎日を本を読む人だ」と思い、周りの人には「彼は毎日本を読む人だ」と思われていると錯覚？する。
仮に怠けたいと思ったときに、この継続の◯の欠損と「本を読む人だ」のイメージを壊したくないという方向に力が働く。
このちからは想像以上にでかい。
こんな些細なことでもそれが自分の一部になり、それが損なわれるのを防ごうとする。
そうやって自分の定義みたいなもの、守るべき範囲が広がったときに習慣になるんだなぁと今では思っている。

4.どうしようもない日のためにチートデーを用意する
嘘でもいい。継続しているふりをする。
そして◯を欠かさない。
そうやって自分のイメージを守る。
僕の一日一冊習慣の場合、どうしようもない日は漫画を良しとしているし、どうしようもない日は自分でも驚くほどに多い。根が怠惰だからね。

5.どうせ続かないを前提にすること
いろいろ頑張ってみたけれど僕の習慣は大抵続かない。
けれども必ず再スタートを切る。
そもそもどうせ続かないと思っているから問題ない。
一日一冊が続かない状況が3, 4日でも続いたら反省してさっさと再スタートを切る。
漫画を一日一冊にするとか、一日10ページにするとか。

落ち込む必要はない。どうせ続かないんだから。
ちょびっと反省してハードルを下げて再スタートしよう。そういう言い訳を続けている。

失うもの

新しい習慣は必ず時間を奪う。
もともとそこにあったものは、小さくなるか消えてなくなる。
僕の場合は、興味のある分野の勉強とかがそれに当たる。

今では読書で手がいっぱいでそういった時間はほとんど取れなくなってしまった。

だがこれも嘆き悲しむ必要はない。

僕は人間は制限されたときこそ創造性を発揮し、ある意味で自由になると思っている。
写真は映画じゃないからこその創造性が発揮されるし、漫画はアニメじゃないからこその自由をそこで得ているはずだ。

近しいことを紀元前あたりの哲学者とか、中世の作曲家が言っていた気がする。たぶん。

一日一冊本を読んでいる１年後の僕は今よりもっと難しい本を読めるようになっているし、早く読めるようになっている。
本以外の時間を作るために頭を働かせて、生活の無駄(ほとんどはスマホ)な時間を削除し失った僕の時間をほんの少しは取り戻しているはず。

終わり

30年後にはどうなっているんだろう。
「こんなクソみたいな習慣早く辞めてしまいたい」とか言いながら続けてたらいいな。

おわり。

大好きなエイプリルフール 2023

今年もやってきました

エイプリルフールです。
それっぽい嘘をついていたずらするのが大好きなのでクリスマスより楽しみな日です。

今年もめっちゃ面白かったのでまとめます。

エイプリルフールまとめ

KNさん

きょうへいさん

たいちさん(冷蔵庫)

同僚のかつまたさん

おじろさん

つじのさん

小学校からのお友達

大学の同期

おわりに

ご協力いただきありがとうございました！！
毎年やるとバレるので不定期に友人に嘘をついています。
いたずらされてない人も待っていれば機会があると思うので諦めないでください。

ではでは。

沖縄に移住した話

はじめに

こんにちは 、fkubota🦉 (@fkubota_) / Twitter です。
弊社(カンム)のアドベントベントカレンダー3日目の記事になります。
もうこの季節が来てしまいましたか。2022年の目標をまだ立ててないので急いで立てないと間に合わないですね。(漫画1冊読むとかにしようかな)

ちにみに昨日は sugawaraさんのこのイケイケ技術系記事でした。よければどうぞ！ tech.kanmu.co.jp

僕は、2022年2月に沖縄に引っ越しをしたのでそのことについて書きますね。

引っ越し理由

一言で言うと、家族のため でしょうか。
8年付き合ってる沖縄出身の彼女がいるんですが、僕が社会人になってから4年間遠距離をしていたんです。
本当は彼女氏が東京にきて一緒に住む予定だったんですが、いろいろ考えて沖縄で生活することにしました。
ふたりとも地元が沖縄で実家と近いほうがいいだろうというのと、個人的に彼女氏に満員電車とかで通勤は絶対してほしくないという思いがありましてそうなりました。

こういう理由で引っ越ししたいという願いを一つ返事で了承してくれた弊社には感謝してもしきれませんね。。。
いい会社なのでカジュアル面談しましょ😁。

引っ越しについて

引っ越し費用がバカみたいに高かったですね。。。
成人男性1人の料金なわけですが、海を渡るのでシーズンでもないのに、21万ぐらい取られました。
最初の提示料金なんて40万を超えていましたからね、絶対相見積もり取りましょうね。

引越し先は、モノレール駅から歩いて5分のところにしました。
モノレール駅から徒歩圏内、というだけで一気に家賃が跳ね上がり候補物件数が減少します。
モノレールって、沖縄本島の↓ここだけしかないですからね。しかたありません。
僕はお酒を飲んでも帰れる という生活を東京で味わってしまったせいでやめられなくなりそういう場所に住むことにしたんです。

家賃は、駐車場付きの物件に二人で住んで、8.5万ぐらいです。
沖縄にしてはかなり高いですね、、、
僕の地元の沖縄市だったら5万出せば、きれいな広めの2LDKに住めます。

これメチャクチャ大事な話 なんですが、Twitterの友人達から信じられない量のプレゼントをもらったんですよね、、、
引きますよねこの量は、、、
感謝してもしきれない返せないですよこれは、、、
本当にありがとうございます。 こつこつ返していきたいので、沖縄に来た際に是非声かけてください。
いい感じに案内しますので。

車について

モノレール沿線に住んでるので車はなくてもいいかな〜とか思ってたんですが、やっぱかなり不便でしたね。
引っ越しして半年で諦めました。中古車を買って車生活を楽しんでします。

友達の話

寂しくないのか？って言われますが、めっちゃ寂しいですねw。
出社の機会もあまりないので同僚にも会えないですし、東京のたくさんいる友人にも気軽に会えないのはとても寂しいです。
沖縄にもたくさん友人はいますが、地元が沖縄市で那覇から離れてるので気軽に会えないんですよね。
こればっかりは仕方がない。

とはいえ みんな、僕に会いに来てくれます。
引っ越して10ヶ月ほど経過しましたが、毎月誰かが遊びに来てくれて、合計15名と再会することができました。
みんな優しいですね、持つべきは友って感じです。

本当にいろいろな人達です。

• 元同僚
• 後輩
• 先輩
• 学会で仲良くなった人
• 居酒屋で仲良くなった人
• 転職するときにお世話になったエージェント
• そしてTwitterの友達

温かい

いや〜〜〜、温かいっていいですね。今12月なんですが、最高気温25度、最低気温21度です。
僕は寒くなると、不思議と気分も落ち込みがちになるので温かいっていいなぁってつくづく思います。

終

思いつくままに書いてしまいました。
総じて、彼女との同棲生活はとても楽しいものです。家に帰ってきたときに誰かいるっていいですね。
喧嘩もほとんどしないですし、来年には人生を進めていこうと思います。

最後まで読んでくださってありがとうございます。
遊びに来てくれるの待ってますね 🦉

家庭内情シス1年目の備忘録

こんにちは！fkubotaです。
新卒(2018年)から4年弱住んでいた神奈川から2022年02月に沖縄に引っ越してきて8ヶ月ほどが経過しました。
今回は、この引越の主目的である彼女氏との同棲生活をITやら家電やらの力を使っていい感じにしてるよって話をしようと思います。

ちなみにフォロワーさんから大量のプレゼントのおかげでQoLがバク上がりしているのもこの場を借りてお礼を言いたいです。
本当にありがとうございます。

愛溢れるフォロワーから信じられない量(70ぐらい？)のプレゼントが届きました！！！
全員集合して記念撮影した！
この量は正直引いてます！！ww

本当ありがとうございました😭
新生活がより楽しくなってます。
明日も届くようですが置き場所が無いのでそろそろ片付けます笑笑

沖縄来てくださいね！ https://t.co/Cm6CgoGcaF pic.twitter.com/HgOE18blRm

— fkubota🦉 (@fkubota_) 2022年2月9日

背景

本題に入る前に少し背景をお話しておくと、、、
大学時代からお付き合いさせて頂いている彼女氏とは、僕が就職のタイミングから遠距離になってしまっていました。
4年弱という長い期間、年に数回しか会えないという状況でしたがなんとか二人で乗り越えてこの度僕が沖縄に帰るという形で同棲生活が始まりました。
しかし、不安なことがいくつかありました。
"お互い初めての同棲生活"という点だったり "彼女氏はずっと実家暮らし"という点だったり、、、
「同棲生活は大変だよ！予想外のストレスがあるよ！」という話はあちらこちらから聞こえて来るので、ITやら家電やらで楽をしたいなと思い頑張ったよという備忘録です。

そうそう、takapyニキのこの記事

www.takapy.work

からも刺激を受けていますね。2020年の記事ですが、僕が彼女氏と同棲始めたら絶対真似しよ！って思ってました。

アウトライン

大体こんな感じで話します。

• コミュニケーション
  • slackとgoogle calendar使ってるで！便利やで！
• お金の管理
  • B/43というサービスを使っているで！やばいで！ストレスがなくなったやで！
• 家事
  • 神家電4つがない生活はもう考えられない！！！........やで！

コミュニケーション

ではでは本題に入らせていただきます。
まずはコミュニケーションから。
ツールは、誰でも知っている、slack と google calendar です。

slack はシンプルに普段の非同期コミュニケーションのツールとして利用しています。もともとLINEを使っていましたが僕がPCから返信しやすいという理由が主な理由です。 もしかしたらいろいろな拡張機能を使っていくかもと思ってましたが今の所特に高度なことはしていないですね。家庭内情シス担当としては複雑にしすぎないことも大事かなと。

もう一つはgoogle calendar です。これはめちゃくちゃ便利です。
使い方にコツがありましてですね、僕と彼女二人共通のカレンダーがあります。
google アカウントは僕と彼女それぞれがもっているものだけですが、カレンダーは3種類あって

• 僕のカレンダー
• 彼女氏のカレンダー
• 共通のカレンダー

という感じです。
相手に伝えるべき予定だけ共通のカレンダーにいれればいいので運用も大変ではないのも好きなポイント。
↓こんな感じで予定を作ったらどのカレンダーに追加するか選べます。

僕のカレンダーから見ると↓のように2色のカレンダーが表示されていて青が僕の予定、黄色が同棲用カレンダーの予定です。

これほんとうにおすすめなので真似してみて下さい。 やりかたは例えばこちらとか。

お金の管理

一緒にお出かけして外食したとき、仕事帰りについでに買ってきたトイレットペーパーなど二人共通の出費というは日々発生します。
どちらかが精算したものを後で請求なんてことをやっていたらトラブルの温床になるのは目に見えています。
僕としては一番どうにかしたい問題でした。
僕は B/43ペアカード というチャージ式のクレジットカードを使うことで解決しました。
b43.jp

使い方は簡単です。
アプリから何かしらの手段を使ってクレカにチャージします。
僕が1万円、彼女氏が1万円チャージするとお互いのアプリ画面からは2万円のチャージ額が見えます。
どこかで僕がこのクレカを使っても彼女氏が使ってもこの2万円から引かれます。
気分的には 共有口座 を持っているような状態です。
似たようなサービスにクレジットカード会社が発行している家族カードもありますが、婚姻関係がないといけないらしく彼氏/彼女関係の僕たちでは使えず断念という感じでした。

運用方法 もざっくりと紹介します。 月々に出る出費(家賃、光熱費、食費、、、) を計算してお互いが払う金額をチャージするだけです。
このとき、家賃や光熱費は僕の銀行口座から引き落とされるのでその分僕のチャージ金額は少なくなる感じです。
毎月1日にチャージしてあとはクレカで支払いするだけ。これだけで、どこで誰がいくら使ったのかもわかります。とても簡単です。

現金の支払いはどうする？
おそらく残る大きな問題はこれですね。僕たちは Notionの運用で解決しています。
お店で現金を使ったときには、支払った人が Notionの立て替え欄 に どこ で 誰 が いくら 支払ったかを記入します。↓のような感じ

一番左にチェックボックスがありますが、これがとても重要です。
チェックされていない 5,000円があったとするとその料金分、僕はどこかで共有クレカを使って個人的な買い物をしていいという意味になります。

1. どこかで僕が5,000円分現金で支払いをする
2. Notionの立て替え欄に5,000円支払ったことを記入する
3. amazonで5,000円のお酒を共有クレカで購入
4. Notionにチェックする

という感じの流れです。これはやってみてめんどくさかったら考え直す予定だったのですがほとんどストレスがないので今後もこの運用で行きます🔥

家事

家事は一番気を使いましたね。
家事のバランスを失うとどちらかに負担がいきストレスが溜まりかねないので、、、
どう分担するかも考えたのですが辞めました。ガチガチのルールは窮屈でしかも完全に公平にはできないで不満が生まれそうなので一旦考えませんでした。
生活しながらPDCAを回せばいいかなと。
その中でできることとなると、そもそもの家事の量を減らすことですね。
これはある程度お金で解決できることなのでいろいろ買いました。

神4家電 を紹介します。
衣類乾燥機
ドラム式洗濯機も可。
とりあえず服を干すという作業を生活から消したくで導入しました。
一人暮らしのときにドラム式洗濯機を買うお金が無かったので、洗濯機とは別に衣類乾燥機を買いました。
電気代がもったいない？洋服を干す作業によって蓄積されたストレスを消化するための出費はもっと高額なはず、、、(持論、クソデカ個人差)
次の買い替えは絶対ドラム式洗濯機を買います。
僕はかれこれ2年ぐらい洋服を干すという重労働をしていないし今後の人生でも絶対しない予定です。
チョーーーキライ！！！

お掃除ロボット
もう説明不要ですね。お掃除が楽になり、床にモノを置かなくなります。

食洗機
これももうなくてはいけない存在になりました。
容量に限りはありますが、使った食器はほとんど入ります。
たまに溢れてしまいますが、残りの少ない食器を洗うのは余裕です。
値段も安いモデルだと3万程度で買えます。僕は3.5万ぐらいの奴を買いました。

google home
「オッケーグーグル」
一日に何度も唱えます。
「オッケーグーグル、明日6:30に起こして」
「オッケーグーグル、カフェミュージックかけて」
「オッケーグーグル、エアコンつけて」
「オッケーグーグル、この後雨降る？」

などなどいろいろなタイミングで使いまくりです。
そしてそしておすすめの機能がショッピングリスト機能です。
google homeにはtodo リストやショッピングリスト機能があって、これがもうめちゃ便利です。
ショッピングリストはいつくも作ることができます。
彼女氏と共有のショッピングリストを作っているので僕か彼女が事あるごとに「オッケーグーグル、ショッピングリストに〜を追加して」と唱えます。
これ本当に便利で、スマホを取り出す必用もなく両手がふさがっていてもできます。
特に料理中に何かを使い切ったときに手を洗ってスマホを触る必用もなく声だけで追加できてしまいます。
想像の1000倍便利なのでみなさんも是非使ってみて下さい(^^)。

終わり

とまあこんな感じで楽しく楽をしています。
みなさんのイケてるハックがあれば是非教えて下さい！
以上です！
ありがとうございました！！！！

ビールをもう少し楽しんでみたいという人へ

こんにちは！カンムで機械学習エンジニアをしているfkubotaです。
カンムの2021年のアドベントカレンダー3日目です。

adventar.org

2日目はシャッチョの記事でした。
よければどうぞ。

note.com

僕は趣味全開のビールについて書きます。

ビールと僕

僕はビールが大好きなわけですが、最初から好きだったわけではなく独自のビールトレーニングを10ヶ月行ってやっと好きになった という過去があります。 それについては、こちらに書いているのでよかったら読んでください。

fkubota.hatenablog.com

そんな僕がビールと向き合う中でビールを楽しむコツみたいなものがわかってきたので紹介したいと思います。
とはいえ、僕はただのビールが好きな素人でしかないので、本当に詳しく知りたい場合はビアバーの店主にでも聞いてください！
(ビール検定2級は持っています)
僕もよく勉強させてもらっております。

ビールとは

まずは、原料について。
ビールの原料は、水、麦芽、ホップと決まっています。(これは、1516年の(現ドイツの)バイエルン公ヴィルヘルム4世が出したビール純粋令が起源です。)
これ以外の素材を使ってはいけません。使っていい副原料というものも中にはありますが、材料は決まっているし最大の量も決まっいてそれを超えると、発泡酒だったり第三のビールと呼ばれるものになります。
細かい話は酒税法を見てください。 ちなみにホップはこんな感じの見た目です。ビールの味の大事な部分を担っていますが味のどの部分がホップなのかわからない人は多いのでは無いでしょうか？

後ほど、ホップが何かわかる飲み方を紹介しますのでお楽しみに。

ビールのスタイル

続いてスタイルについて。
ビールにはスタイルというものがあって材料や作り方の違いに応じて味が変わります、その違いをスタイルと呼んでいます。
クラフトビールが置いてあるお店や、ビールがたくさん置いてあるお店に行って知らない言葉に圧倒された経験がある人は多いと思います。
でも大丈夫です。この記事で少ないポイントを抑えてもらうと次にそういうお店に行ったときに少し楽しめるようになると思います。

ざっくりとビールのスタイルを理解するためにビールの系統図を使って説明します。

この5つをまずは抑えるといいと思います。
それぞれについて解説します。
まず最初の分岐ですがこれは麦汁を発酵させる時に使う酵母の違いです。
醗酵した後に酵母がどこに集まるかが名前の由来です。

①日本で飲むビール

日本で作られるほとんどのビールで使われるのは、下面発酵酵母です。
この下面発酵酵母で作られるビールで代表的なものが、ラガーとかピルスナーと呼ばれるビールです。
日本でよく飲むビールはラガー/ピルスナーと呼ばれるんだなと覚えれば大丈夫です。

分岐のもう一方が、上面発酵酵母を使ったビールです。
特徴はラガービールより高い温度でも美味しく飲め、香りやコクなども豊かです。
そして今から紹介するスタイルのほとんどがこの上面発酵酵母で作られます。

②ペールエール

エールビールの王道と言えばこのペールエールでしょう。クラフトビールを楽しみたいという人にはピッタリだと思います。ホップの香りや、苦味を良く感じる事ができます。
日本のビールより色も濃いのが特徴です。

③IPA

一言で言えば、ペールエールより度数が高く、ホップがたくさん入っています。インディア・ペール・エールという名前のスタイルのビール。当時、インドへの長い航海中にビールの劣化が問題となっていました。 パスツールが低温殺菌法を発明するまでは、ビールの保存期間を長くする方法には大きく2種類あり、アルコール度数を高めること、ホップ(保存料としての役割がある)をたくさん入れることがありました。 その2つを取り入れているため、度数が高く、ホップを大量に使っています。ホップは、香りと苦味のもとになるためフルーティな香りと強い苦味が特徴です。ビール好きは全員好きなスタイルといっても過言ではないでしょう。

④小麦を使った白いビール

今回紹介する中では一番飲みやすいタイプでフルーティなのが特徴です。ビールの原料の麦芽は基本的に大麦を使っています。その半分以上を小麦にしたビールを白ビールとか呼んだりします。 一番の王道は、ドイツのヴァイツェン。小麦を使っているのでバナナのようなフルーティな香りと白い色が特徴的です。さらにハーブを加えたりして独特の味を出しているのがベルギー発祥のベルジャンホワイトです。

⑤黒ビール

麦芽をローストしているのでめちゃくちゃ黒いです。コーヒーと同じですね。チョコレートやコーヒーのような香りやコクを楽しめます。黒ビールで代表的なスタイルのスタウトは強いという意味があり、その名の通り度数が高いです。

この5つさえ抑えとけば大抵のビールは対応できます。
例えば、Hazy IPAだったらIPAの親戚なんだな、ヘフェヴァイツだったらヴァイツェンと近い味なのかな？など想像できます。
全然知らない名前のビールでも、調べてみると上のビールの派生であることがほとんどだと思います。

市販で買えるビールを使って味比べをしてみる

上記で紹介したビールを揃えて使って味比べをするととてもおもしろいと思います。
友人数人で集まって1本を4人で分けるみたいな飲み方すると少量ずついろいろなビールを楽しめていいですよ。
それと、絶対にグラスに入れて飲んでください。色を見るのもそうですがエールビールは香りも楽しまなくちゃ損です。

買いやすさなども考慮し、5つのスタイルそれぞれ紹介していきます。

①日本で飲むビール

これはなんでもいいです。
銀色のやつとか買っとけば良いんじゃないでしょうか。

②ペールエール

これは一択です。手に入りやすさも抜群で日本クラフトビール界のエースといっても過言でないビール。
ヤッホーブルーイングが作るよなよなエールです。

コンビニとかで気軽に帰えます。

一択とかいいつつ、一つだけ追加で紹介させてください。。。
たまーに成城石井とか売ってるちょっとレアなビールなのですがシエラネバダのペールエールは絶品です。
ペールエールはイギリスで生まれましたがその後アメリカに渡り、アメリカの個性豊かなホップが使われるアメリカンペールエールも今では大人気のスタイルです。
その中で王道といっても良いビールはこれでしょう。

③IPA

これもヤッホーブルーイングのビール、インドの青鬼です。コチラもコンビニで気軽に手に入ります。

もう一つ、BREWDOGのPUNK IPAという名前のビール。イギリスのクラフトビールメーカーのBREWDOGのIPAで世界中で大人気です。
インドの青鬼に比べると手に入りづらいですが、成城石井に行けばほぼ確実に売っています。手軽に手に入るIPAだと僕はこれが一番好きです。

④小麦を使った白いビール

ヴァイツェン1種類、ベルジャンホワイトを2種類紹介します。
まずは、日本のヴァイツェンと言えばこれ、銀河高原ビール これもたまにコンビニで売っていたり成城石井に置いています。
それなりに手に入りやすいです。僕も大好きでよく買います。このビールはヴァイツェンの中でもヘフェヴァイツと呼ばれるタイプです。
へフェはドイツ語で「酵母」という意味があります。酵母などの浮遊物を取り除くろ過をしていないので濁っているのが特徴です。

ベルジャンホワイトの２つは、ヤッホーブルーイングの水曜日のネコ と ヒューガルデン・ホワイト です。 これもコンビニとかで気軽に手に入ります。

⑤スタウト

これは一択ですね。ギネスが出しているスタウトです。
ちなみにスタウトを作ったのはこのギネス社です。
スタウトが生まれた歴史も面白いのですが、ここではやめておきます。。。
あ、そうそう、ギネスブックもこの会社ですよ。

このビール、ぜひ缶ビールで買ってほしいです。きめ細かい泡を作るために中にボールが入っています。 飲み終わった後に缶を振るとカラカラと音がして面白いです。

おすすめの飲む順番

1. ①日本のビールを飲む。
2. ②ペールエールを飲む。発酵酵母の違いを楽しんでください。苦味も少し強いし、香りも華やかだと思います。
3. ③IPAを飲む。③と②の大きな違いがホップの量です。この２つを比べて何かが違うと感じるはずです。それがホップ由来だという理解でだいたい問題ないでしょう。ホップを感じてください。
4. ④小麦を使った白いビールを飲む。原料に小麦を使うだけでこんなにもフルーティで飲みやすくなるのかというのを感じられるはずです。フルーツ入ってないですからね。すごいです。(ベルジャンホワイトにはオレンジピールが入っていたりはします)
5. ⑤黒ビールを飲む。黒ビールはコクがすごすぎるので最後に。今までとは全然違う味のビールだと思います。香りの中にチョコレート感が感じられます。このビールが好きであれば、デュンケルとかボックという種類の濃色ビールも飲んでみると良いかもしれません。スタウトほどじゃないですが、麦芽をローストしていて濃い色のビールです。

こうやってビールを楽しむと、ビールの系統図の幹と太い枝みたいなものが頭の中に出来上がります。新しいビールを飲むたびにその太い枝に細かい枝を生やして行けばどんどんいろんなビールを楽しめるようになるはずです。かつて僕がそうだったように。

終わり

ありがとうございました。
ぜひ上で紹介したビールを買い揃えて楽しんでみてください。
絶対グラスに注いでくださいね！！！
社内で興味ある人がいれば僕が買い揃えたビールで飲み比べ会とかしてみたいなぁ。

ちなみにカンムにはビール好きな人達がいて先日一緒に飲みに行きました。
一緒にどうですか？募集してますよ！

team.kanmu.co.jp

ビールが大嫌いだった僕がビール検定2級を取得する話

Caution!!

記事の途中で注意とか書いちゃうと流れが悪くなるので最初に書いておく。

注意!!

• 「ビールは全人類飲める必要はない。飲みたい人だけ飲めばいい！」と思っている。
• 僕の真似をして飲めるようになる保証はない。たまたま僕に合っていただけという可能性を否定できない。

Hello Beer!!

話は2017年の春まで遡る。
当時物理学科の修士2年生だった僕はいろいろあって(本当にいろいろあった)専門商社に内定をもらい、これまたいろいろあってそこにお世話になることになった。
その会社にはユニークな制度があって、入社後すぐにドイツに行く研修がある。
ドイツと聞いて最初にイメージするのはそう、ビールだ。ビールとソーセージ、素敵な響きだ。

そんなビールには大きな欠点がある(正確には"あった"だが)、僕が大嫌いという事だ。

見た目までは完璧で隙なんて一つもない。黄金に輝く液体、それに蓋をするように美味しそうに浮いているきめ細かい泡たち。
飲むと美味しいにはずなのに、これが不思議と美味しくない。
匂いも含め褒めるところが一つもない。
なんなんだこれは。

当時の僕は最初に飲んだ時そう思ったし、その後何年もそう思い続けた。

そんなときに知らされたドイツ研修。
これは克服しないわけにはいかないなと一大決心しビールトレーニングをすることにした。
時は流れトレーニングを開始してから4年後の2021年11月にビール検定2級を取得してしまった。
今ではビールがない生活は考えられないほどのビール好きになった僕。

この記事では一つの区切りとして、僕とビールの歴史を書こうと思う。
未来の僕から見るといささかむず痒い記事になるだろうが、黒歴史の1つや２つあったっていいじゃないかと思うので書く。

本編

僕がどれくらいビールが嫌いだったかって？
当時は間違いなく1番嫌いなものだった。
「とりあえず生」の掛け声を断る事ができずに頼んだビールは一口が限界だった。
その後は隣の理解ある友達に目線を送る「わかるよな？」その合図で彼は残りのビールを飲んでくれる。そんな感じ。

そんな僕が、「ドイツ研修がある」→「故にビールトレーニングをする」というのは論理の飛躍も甚だしいと思う人もいるだろう。
でも本当に理由はそんなものだった。せっかくドイツに行くのにビールを飲めないのはもったいないな。それに飲めるようになると今後の人生の楽しみが増えるってもんだ。 できないよりはできたほうがいいという文脈で、嗜好品を楽しむチャンネルは多いほうがいいに決まっている。

そんなこんなでトレーニングをすることになった。
僕は過去にも似たようなことをいくつも経験したことがある。 例えばコーヒー、コーヒーをブラックで飲むことには憧れがあり、研究しながらコーヒーを飲むのはかっこいいと思っていた。
たったそれだけのモチベーションで2ヶ月ほど試行錯誤をした結果苦手だった苦いコーヒーが飲めるようになった。
過去の経験からビールもいけるだろう、そういう謎の自信だけを持ってチャレンジは始まった。いや、始まってしまったと言う方が正確か...。

夏

ここからは僕の成長を4段階で描いていく。ちょうど季節にして春夏秋冬で表現できる。

夏。就活も無事終わり、秋の学会にソワソワし始めた頃に僕のビールトレーニングは始まった。
新しいチャレンジを行う時に必ず初めに行うのは知識の獲得だ。
とりあえず周辺知識から固めていった。
図書館で2冊ビールの本を借りて読んだ。書店ではビール特集みたいな雑誌を1冊買った。
ビールとは何なのか、材料は？、歴史は？とざっと学んでみた。
1冊読む毎に彼と少し仲良くなった気がして缶ビールを買っては飲んでみた。
相変わらず外っ面だけよくて肝心の中身は残念なやつだった。
打ち解けるのは時間がかかりそうだ。

知識をつけつつもう一つ、少し高いビールを飲んで見るというのもやってみた。
高いものはうまい理論を全面に押し出したこの挑戦は、貧乏学生の財布に小さくないダメージを残して静かに音も立てずに終わった。

秋

夏の挑戦はある程度想定の範囲内。
知識をつけたって、高いものを飲んだって大嫌いなものが飲めるようになるはずがない。

そうやって強がっている僕が次に取り組んだのは「手に入りやすいビールの中に僕が飲めるビールはあるか？」という問題だ。

具体的には以下のことをしてみた

• 友達に飲みやすいビールはあるかと質問する
• インターネットで「ビール 飲みやすい」「ビール 苦手でも」「ビール 苦くない」 などのワードで一通り調べる
• ビールと何かを混ぜて飲みやすくする

結論から言うと全滅だった。
すべて一口が限界で、希望の光はこれっぽっちも顔を出さなかった。
うーん困った。僕の症状は想像していたよりも重いのかもしれない。
そう思い始めていたら紅葉という概念のない沖縄の秋(知ってた？)は終わっていた。

飲みやすいと言われるビール

冬

自分の症状が重いことがわかり落胆している僕。
同時に修論という文字が一日に5000回ぐらい頭をよぎる修士2年の冬がやってきた。
つまり僕だけ2つのビックプロジェクトを抱えているというわけだ。

販売されている商品に救いがないことがわかった僕は、独自の道をたどるしかない事を悟っていた。

ここからは地道にやるしかないと心に決めた僕はシャンディーガフに目をつけた。
シャンディーガフというのは、ビールとジンジャーエールを混ぜたカクテルだ。
秋に試していたが一口飲んだだけでその後疎遠になっていたやつだ。

目をつけた理由は簡単でこいつを使えば、確実に飲めるようになることを知っていたからだ。
できれば避けたかったが止むを得ない。

ではなぜ確実に飲めるようになると考えているかを説明する。

まず、以下の事実がある。

• ビールは飲めない
• 世間一般のシャンディーガフは飲めない
• ジンジャーエールは飲める

簡単のためにシャンディーガフの定義を広く取って、ジンジャーエールにビールが1滴でも入っていたらそれをシャンディーガフとする。
ビールの量によって、ビール感の強いシャンディーガフとビール感の弱いシャンディーガフがあるというわけだ。

ビールが1滴だけ入ったシャンディーガフを飲めないわけがないので、グラデーションで分布するシャンディーガフの中に、ギリギリ飲めるシャンディーガフとギリギリ飲めないシャンディーガフの境界が存在することになる。
僕はこの境界を自分のビール力を表す指標とした。
あとは、この境界をジリジリと押し上げれば時間はかかるかもしれないけれど、いつかはビールが飲めるようになるというわけだ。

左がジンジャーエール、右がビール。この間のどこかに僕がギリギリ飲めるシャンディーガフが存在する。

大げさに式にするとこんな感じの式で表現できる。

一般的なシャンディーガフはビールとジンジャーエールを1:1で混ぜるのでシャンディーガフが飲めるのであればビール力は0.5以上あることになる。
ちなみにこのときの僕のビール力は 0.1だった。つまり ビール:ジンジャー=1:9 で混ぜるのがやっとだったわけだ。

さてここからが大変だ。確実だが果てしない挑戦が続いた。
研究もかなり忙しく、夜中の2時に帰るのは当たり前だったのでビールのトレーニングはその後に始まることになる。
疲れた体に鞭打って飲みたくもないものを飲むのは苦行以外のなにものでもない。

できれば毎日やりたかったがもちろん怠けた日もある。
5日やらなかった日もあるし、飲む日と飲まない日を交互に過ごす時期もあった。
それでもなんとか続けられたのはやっぱりビール力という目に見える指標を用意していたからだと思う。
時間はかかったが日に日に成長していた。
呑み会ではチャレンジとしてビールを頼んで1口以上飲めたりしたときは素直に嬉しかった。

そうやって日常は忙しく過ぎていき冬が終わった。
秋の3ヶ月でシャンディーガフが飲めるようになった。
つまりビール力が0.5を超えたのだ。 ドイツ研修は5月。もう時間がないぞ。間に合うか？？

春

日本の春は3月から始まる。
僕にとっては特別な月で長かった学生生活最後の月になる。
沖縄から東京への引っ越し、就職の準備、学会(この時期に参加するのは珍しいと思う)の準備で大忙しだった。
気づいた時には入社式を終えていた。
一段落したころに新卒同期にホッピーという飲み物を教えてもらった。
これがビール力0.6ぐらいの僕にはピッタリのビールトレーニングアイテムとなった。
おそらくビール力0.7~0.8程度必要な飲み物だがもう時間がなかったので、荒療治にはなるがお店で買って可能な限り家で毎日飲んだ。
そして訪れたドイツ研修。そこで僕は覚醒することになる。

覚醒の時

僕はドイツに降り立った。
初日の夜にレストランに行き、ビールを頼んだ。もちろんソーセージも一緒に。
ビールを一口飲んでみた。おや？うまいぞ？？
なぜかゴクゴク飲めた。それもそのはず、このビールはヴァイツェンと呼ばれるドイツの伝統的なビールで日本のビールより飲みやすいのだ。
以前なら飲みやすかろうが関係ない。ビールであるというだけで僕は一口が限界だった。しかしこのときの僕は以前よりビール力が桁違いに高い。

叫びだしたいほど嬉しかった僕は、叫ぶ代わりに何杯もビールを飲んだ。
僕のトレーニングを知っていた同期達も嬉しそうに一緒にビールを飲んでくれたのは今でもとてもいい思い出。

ここまでが僕が覚醒するまでのお話。

あまり写真を撮ったりしない僕。ドイツでも10枚ほどしか写真を取っておらず、ビールの写真は0。代わりにこいつが3枚もあった。

ビール検定2級合格

日本に帰ってきてからは毎週のようにいろいろなビールを飲んだ。
ビアバーに行くときもあるし、めずらしいクラフトビールを飲んでは幸せな気分に浸っていた。
聞いたことのないスタイルのビールがあれば調べてどういう特徴があるのかなど、気になったところを勉強をしていた。

そうやって僕の生活にビールは根付いていき、気づけば友人の中ではビールに詳しい方になって、無類のビール好きになっていた。

そんなときにふと、もう少し体系的に勉強をしてみたいなという意欲が湧いてきた。
製法やスタイルなどは一通り理解しているつもりだが、ビールの作るどの工程やどの材料が味に変化をもたらすのかをもう少し解像度高く理解したくなったのだ。
調べてみるとビール検定なるものがある。これは受けないわけにはいかないなと思いさっそく申し込んだ。
3,2,1級があったがいろいろ考えて2級を受けることにした。
問題は、原料や基本的な製法・スタイル、ビールの歴史、ビールの味わい などなど かなり幅広く出る。(実技試験はない)
興味ある人はココ↓を見ると知りたいことがわかると思う。 beerken.jp

100点満点中70点で合格だが、ギリギリの73点で合格だった。
正直ビールの日本史とかにはあまり興味が持てず苦手な印象があり点数も低かった。
一番学びたかった製法やスタイルの部分はめちゃくちゃ解けた。

検定を勉強してよかったのかと聞かれると間違いなくよかったと答える。
今まで点で理解していた部分が繋がりバラバラだった知識が体系化された感覚がある。
実際にビールの紹介文を見ると製造工程のどこで味の違いを出しているかが以前よりはるかに解像度高く理解できるようになった。

ここまで長かったですが、結局何が言いたかったのかというと特に言いたいこともなく、僕はビールが飲めるようになり、さらに初心者に毛が生えた程度の知識も手に入れたってだけ。

また一緒にビール飲もうね:)

今週の土曜日にIPAの対策かなり頑張った。
習慣にして毎日取り組むようにしたい。 pic.twitter.com/1uCmJrCeF7

— fkubota🦉 (@fkubota_) 2021年10月4日