Diary over Finite Fields

515ひかるの日記と雑文

2019 年の振り返り

2010 年代が終わるとのこと。じつはこのブログは 2013 年から存在していたらしい。もはや自分でもどんな経緯で作ったとかあまり覚えていない。でも記録によると 10 年のうち、5 年くらいはなんだかんだブログを書いていることになる。このブログには 500 記事以上の記事が実は存在していて、今年の記事は約 50 記事ほどらしい。

こんなに長く続けるつもりはなかったんだけど、惰性で続いてきた。そんなわけで、今年も惰性で節目に振り返りをしておく。

2019 年

さて、今年の話。毎年「言うほど何もしてないよな」と思うけれど、頑張って思い出す。

冬〜春

1 月から 3 月くらいにかけては、ずっと退職に向けてだらだらしていた。正確には最終面接、内定が出たのが 1 月の終わりくらいで、正式に退職が決まったのが 2 月か 3 月かくらい。入社したのはこのブログにも書いたように 5 月。

blog.515hikaru.net

単純に時間が経っているというのもあって、あまり覚えていない。とにかく時間だけがあり余っていたと思う。

この時期に『エンジニアリング組織論への招待』だとか『エンジニアのためのマネジメントキャリアパス』だとか、『エンジニアの知的生産術』だとかやたら本を読んでいた気がする。今思うともっとデータ構造の本とか、JavaScript の本とか読んだほうがいいんじゃないのと思うんだけど、それはそれとして。

メルカリにチョットはまったり、キャッシュレスをメインに移行したのもこの時期だったかな。あと何気なく仙台に観光に行ったり。思いついたことは何でもやる時間があった。

春〜夏

転職して慣れよう期。忙しくはなかったんだけど、なんか退屈な時期でもあった。

なんかやたらとお金を使っていた気がする。なんでなのかよくわかっていないが、夏だからだろう。ちなみに今は反動(?)で全然お金使っていない。ていうかお金を使う時間がない。

心の余裕がとてもあった時期だったと思っている。ただ一方で、夏の終わりにどうしようもない気持ちになることもあった。

blog.515hikaru.net

あとはイベントとしては、技術書典に出展した。本を出すというのはだいぶ昔(中学生くらい)に思っていた人生の目標ではあったので、それがどんな形であれ叶ったのは嬉しかった。

blog.515hikaru.net

次回の技術書典は、ちょっと出せないかもしれない。。他にやらないといけないことがいっぱいある。。。

秋〜冬

OSS 活動を始めたりした。あとは副業をやってたりします。

blog.515hikaru.net

年齢のせいか季節のせいか何のせいかよくわからないけれど、冬って言えないことが増える。

1 年を通じて

ライブ行った

自分の中で、ライブに今までで一番行った年じゃないかと思う。ぱっと思い出せる範囲で表にしてみた。

歌手名 場所
1 3 月 TK from 凛として時雨 東京ドームシティホール
2 3 月 CIVILIAN 赤坂マイナビブリッツ
3 5 月 majiko x CIVILIAN 新宿 LOFT
4 6 月 凛として時雨 Zepp Tokyo
5 7 月 THE ORAL CIGARETTES x 凛として時雨 Zepp Tokyo
6 8 月 サマソニ 2019 2 日目 幕張メッセ他
7 10 月 TK from 凛として時雨 新木場スタジオコースト
8 10 月 ヤバイTシャツ屋さん Zepp Tokyo
9 11 月 ALEXANDROS x THE ORAL CIGARETTES Zepp Sapporo
10 12 月 TK(凛として時雨) Bunkamuraオーチャードホール

に行ったらしい。こんなに行っていたのか。3 月の CIVILIAN が本当に良かったね...本当に良かったね......。2020 年しょっぱなから東名阪ツアーもあるよ、東京完売したよ、嬉しいけど俺普通に買い逃したよ(名古屋のチケット買うか迷い中)。

さて、CIVILIAN の話はさておき、来年も既にあいみょんに行くとか Indigo la End にいくとか決まっているのがあるので、楽しみ。来年も音楽をきいて楽しく過ごそう。

プログラミング

なんか何もコードを書いていない気がする。 GitHub の Contribution の数値は確かに最近増えているのだけど、そういう問題ではない。

今年形になったアウトプットって ↓ くらいのものだし。

blog.515hikaru.net

コレ自体とくにツールとしてなんにも難しいことはしていないので、なんかな。

読んだ技術書が特に思い当たらないし。やたら家にあるけど、最近家に何があるか把握しきれていなくて「俺これ買ってたんだ」とか思ったりする。

とにかく書いているコードの絶対量が足りていない気がして、やたら気が急いている。もっと基礎を勉強する、そのために基礎となることを実装する、ということをやっていかなきゃいけないんじゃないかと思う。こんなのが今年見つけた課題かなぁ。

終わりに

他に作りたいアプリがどうとか、仕事についてどうこうとか、色々あるのだけれど、口を動かす前に手を動かしていきたいなと思うのでこの辺で。

最後になりますが、今年も読んでいただきありがとうございました。よいお年をお迎えください。

Markdownのテーブル記法をCSVに変換するmdtable2csv作った

この記事の概要

  • Markdown の表を CSV に変換するコマンドラインツールを作りました
  • 表計算ソフトから Markdown の表を作成するツールはあるけど逆変換をするツールをほぼ見かけなかったので作りました
  • 日常の細かなストレスがちょっぴり軽減しました

github.com

なぜ作ったか

わたしは Markown の表を手書きすることはあまりありません。いつも Microsoft Excel などの表計算ソフトで書いて、Markdown 形式に変換をしています。変換の仕方には色々あると思いますが、わたしは普段 Markdown Tables generator という Web アプリを利用しています。

Markdown Tables generator - TablesGenerator.com

これで自分はセルの内容を書くことに集中し、パディング処理だとかに囚われず表を生成することができます。しかし、逆変換はできません。逆変換ができないと何に困るかと言うと、一度作った表を再度編集したいというときに困ります。セル内の typo を直す程度なら 直接 Markdown を編集しても良いのですが、列や行を1つ加えるなど、表の構造を変えるような編集になると面倒です。表計算ソフトを利用して表を編集したくなります。

しかし、存在するのが Markdown 記法で書かれた表だけのときに、それを表計算ソフトにサッとペーストする方法はありません(少なくともわたしは知りません)。そのため、Markdown 記法で書かれた表しか存在していないときに、簡単に表計算ソフトでその表を扱えるようにしたい。そんなモチベーションで作りました。

インストール

Go 言語の開発環境が構築されている前提ですが、下記のコマンドでインストールできます。もちろん、あらかじめ $GOPATH/bin に PATH を通してください。

$ go get -u github.com/515hikaru/mdtable2csv

バイナリのアップロードなどはしていないので、使いたければソースからビルドするしかない状態です。GitHub Actions 使って CI/CD を工夫しようかな、とは思っていますが手を動かしてはいない状態です。

使い方

わたしは標準入出力をよく扱います。特に今回のケースでは、Crowi などの Markdown ベースでの Wiki にある表を CSV に変換するのがモチベーションだったので、 Mac の pbpastexclip -o などを用いて、クリップボードの内容を標準入力から読み込んでパースできると便利かなと思いました。そのため、 cat コマンドのように何も指定しない場合は標準入力を読み込む作りにしています。

下の画像はブラウザから Markdown の表をコピーして、CSV へ変換する例です。

f:id:hikaru515:20191228175525g:plain

おまけ機能

  • Microsoft Excel 対策で BOM 付きの UTF-8 で CSV を出力する機能があります。 mdtable2csv -to-code=UTF-8-BOM とすると BOM を付けます
  • ファイルからの入力、ファイルへの出力もサポートしています。オプション名は dd コマンドに倣って mdtable2csv -if foo.md -of foo.csv という形です

実装

なぜ Golang か

リポジトリを見ればわかりますが、Go言語を使っています。理由は自分は普段 デスクトップ Ubuntu を使っていますが、仕事でもこのツールを使いたかったので他のマシンにインストールするときも簡単にできてほしいと思いました。そこでインストールが簡単な言語で、自分のマシンであればたいてい実行環境を整備してある Go にしました*1

正直インストールが簡単でさえあればいいので、 Node.js でも Rust でもよかったといえばよかったのですが、それらに比べれば Go のほうが書き慣れているかなということで Go にしました。

実装方針

Markdown パーサは gomarkdown/markdown を使用しました。CSVの出力は標準ライブラリを特に工夫せずに使っています。わたしが実装したのは Markdown の AST をたどって、表のセルを [][]string 型へと変換してやる部分だけです。2つの巨人の肩に乗り、巨人から巨人へとデータを送ることしかしていません*2

この実装方針は 10 秒くらいで目処が立ったのですが、形にするとそこそこ時間がかかるものですね。

困りゴト

特にファイルからの入力を実装したので、1回の入力で複数のテーブルが渡された時にどうしようか悩んでいます。

なんとなく、

Table 1
foo,bar
1,2
Table 2
hoge,fuga
3,4

のように、どのテーブルかわかればいいのではないかとも思うんですが、そうするとリダイレクトでCSVが作れなくなってしまいます。現在は1つめの表のみをCSVに変換するようになっています(2つ以上表が入力されても何の警告もなく無視します)。

もし自分の中で複数の表を扱うユースケースが発生すれば考えるのですが、現在は特に思いついていないのでしばらくは放置でいいかなと思っています。

おわりに

あまりきれいなコードではないですが、自分としてはこれで満足しています*3。もし機能追加の要望や、動かないなどあれば GitHub の Issues などでお知らせください。特にWindowsでの動作確認はしていないので動かないかもしれません。

そんな広く使われるツールにもならないと思うので、質問も GitHub の Issues で大丈夫です。

もし使ってみて「いいな」と思っていただけたらぜひ Star をお願いします。

*1:筆者は ghq など Go 製のコマンドラインツールをそこそこ使うので、たいていのマシンに go コマンドと GOPATH が設定されています。

*2:こんな解説、どこかで聞いたなと考えていたら VimConf 2019 の LT で登壇されていた deoplete-vim-lsp の作者の方が似たようなことを言っていました。

*3:特に機能追加にモチベーションがないのに、既存のコードベースのリファクタリングをする意味はないためです。

なんでもない特別な日と、特別な普通の日

Happy Holidays! と騒ぐほど浮かれてもおらず、かといって別に落ち込んだり怒ったりもしていない。あまりにも普通な日だ。

多くの人にとって特別な意味を持つ日を、特別な日にするのはとてもむずかしい。何もしなくたって、その日は特別な日だからだ。1月1日と1月23日ではみんな過ごし方が違うだろう。1月1日は何もしなくたって既に特別だけれど、1月23日はただの普通の日だ。だから何かをすると特別になれる。

特別な日に何もしなくていいというわけではない。ただ、多くの人にとって特別な日よりも、自分(たち)にとって特別な日を大切にすることのほうが大事だと思う。あるいは、何でもない日を特別な日にすることに努力したいと思う。その何でもないような日は、きっと未来の自分を創っていく。

そんな今日はクリスマス。

ライブ

代わり映えのない毎日ではあるけれど1、時折イベントごとが発生する。12/23 にライブに行ってきた。

tkofficial.jp

すごくよかった。なにが、と言われても困るけど。

this is is this や make up syndrome やCRAZY 感情 STYLE が、あんな姿になるなんて思わなかったし、そうした姿が目に焼き付いて、耳に鳴り響いて。あぁ贅沢だなこれって。ロックバンドのフロントマンが歌っているというのに座りながらずっと聴いていたのは初めてかもしれない。

一方で、自分も歳をとったんだなと思った。いや、まだ26歳のわかものなんだけど、凛として時雨を聴き始めたときにこのライブに行っても、魅力は伝わらなかっただろうと思う。なんやかんやいってもう4年くらい?聴き続けている2。もちろん激しいロックも好きなんだけど、自分の中にいつの間にか新しい視点が芽生えていたんだと思う。

また企画されたなら、行きたいな。すごく創作意欲が刺激されて、俺もプログラミングやビジネスマンとして頑張らないといけないなと思った。

ブログ

最近あんまり書いていなかった、メタな話を書こうと思う。なぜこのブログを書いているのだろうと最近思っていた。いつの間にか記事数は500を越え、どうでもいい日記から、人生の節目に思ったことなど、自分を主体にして書いてきた。そうした自分語りは今年もしていた。

blog.515hikaru.net

しかしこの頃、ブログを書く気力みたいなのがうすれている気がする。ネタが切れた、そうなのかもしれない。最近とにかく書くことが思いつかない。ネタはあっても膨らまない。

あるいは書いたものの萎縮して捨てることもある。炎上ネタからの着想だったりすると、炎上ネタ自体に直接言及はしていなくても避けようかなとか思ってしまう。

ただせっかく何年もかけて、自分の世界観だけで完結する空間をインターネットの片隅にでも作ろうとしてきたのだから、それを壊してしまったり、やめてしまうのはもったいないよなと思っている。このブログやめる気は決してない。でもなんで続けたいのか自分でももはやよくわかっていない。習慣にしては不定期更新にすぎるし、かといって頻度がそこまで低いわけでもないし。

英語を書きたいとは思っていて、DEV Community に発信するとか、Medium に英語で書くとかやってみようかなとか思い始めている。だけどそのへんはこのブログとは関わりをそこまで持たせないようにしようかな。

技術記事はこのブログにはもう書かない、というスタンスは一貫していこうと思う。これからの技術的なアウトプットは、QiitaGitHub自分の技術ブログ に書こうと思う。もっとメモ書きを自分の技術ブログには増やしたいんだけど、増えないね(メモ書きはメモアプリに書けばいいので)。ただ技術の話題であっても、自分の考え方とかを書くのはこのブログにしようと思っている。ちょうど Advent Calendar も書いたし。

blog.515hikaru.net

おわり

さて、まったく 12/25 感のない記事だった。もう年の瀬ですね。年内に2019年の振り返り記事を書くかもしれないけど、書かないかもしれない。

というわけで、今年もありがとうございました。よいお年をお迎えください。


  1. 新しいことをちらほらと始めたりはしている。けど書かない。

  2. 凛として時雨というバンドの歴史から考えると非常に短い。自分の中では結構長い。

OSS 活動の形

はじめに

この記事は LAPRAS Fans Advent Calendar の 9 日目です。前日は tomato360 さんの 今年一番のアウトプットについて で、明日は Ryusuke Takahama さんの「今年のアウトプットまとめ」です。

adventar.org

テーマはアウトプットとのことなので、最近意識している OSS 活動でのアウトプットについて書きます。

OSS 活動を始めた

最近は OSS 活動を気が向いた時にちまちまとやっています。日常的に「やらないといけない」とか考え出すと辛いですし、長続きしないと思っているので、基本的に誰からも強制されない内容をコミットしています。

始めたのは今年の秋くらいなので、まだ日常になってから 3 ヶ月も経っていませんし、機能追加だとかバグ修正だとかにはあまり貢献できていません。大体 README を読んでいて見つけた typo を直すとか、初心者向け Issue を直すとか、落ちている CI を直すとか些細な修正です。

例えば、

などの PR を出しました。これらのツールは自分が見つけたり、ツイッターやブログなどで誰かがシェアしていて知ったものです。そこで GitHub のページを開いて Star 付けて終わるのでなく、動かす、そして(たいてい気になることがあるので)より良くするために自分が何ができるか考えて行動する、という行動をした結果です。

OSS 活動を始めるまでの心境の変化

このような行動を始めるまでには、いくつかの発想の転換がありました。わたし自身は、昨年の 12 月に 1 度機会があってとある OSS に Contribute していますが、それが続くことはありませんでした。

このタイミングで再開に至れたのは、様々な転機が重なったのもありますが、何よりもこの半年間でソフトウェア開発に対する考え方が少しずつ変わったことが大きいです。以下には、そうした心境の変化と、それに伴う自分の行動の変化について書きます。

ひとりで行動するのをやめる

まず一番大きかったのは「自分ひとりで大きなことを成そうとするのをやめよう」と思ったことです。

わたしも開発者の端くれ。天才プログラマーでもなければ有名人でさえないですが、いつか自分でソフトウェアを作って世界中で広く使われるなんて未来が来たらいいなぁと漠然と思っていましたし、今も思っています。

しかしわたしはそうした幻想を基に行動をするのをやめました。 Linux カーネルは Linus Torvalds ひとりだけで今ほど成長したのではありません1し、それ以外のどんなソフトウェアであってもひとりだけでメンテナンスをし続け、広く使われ続けているものはおそらく存在しないでしょう。

結局複数人で行動しなければ、社会のためにあるいはより多くの人のためになるようなツールやソフトウェアを作るのは難しいです。そもそも、SaaS 事業をしている会社がエンジニア採用に多大なコストを払ってでも採用しているのは、サービスを作るためには開発者のチームが不可欠であるということを認識しているからでしょう。

わたしは天才ではない。だから 1 人で開発するのではなく、皆と協力したり、既に作られたものをより良くする方向にアウトプットをするほうがより多くの人のためになる。知っていましたが、それを認めた上で行動するにはそれなりの時間がかかってしまいました。

既製品をよりよくすることへの喜びを感じる

自分がツールなどソフトウェアを作る、ということを以前は考えていました。しかし最近は休止しています。もちろん、作りたいものができたら作るとは思いますが、無理に作る必要はないと考えています。

OSS では、みんな直したいけど忙しくて直せていないもの、いつでも直せるからと放置されているものが思っているほどたくさんあります。そうした課題には GitHub の Issues でチケットが管理されている場合は、"good first issue" というラベルがついていることが多いです。このプロジェクトに最初に Contribute するのにオススメの Issue ということです。

そんなに頻繁にこなしているわけではないですが、こうした Issue をこなしているだけでもやることは山積みという感覚が湧いてきますし、何より PR すると感謝されます。何度言われても、 PR で Thank you だとか Good だとか Great だとかありがとうございますだとか言われるのは嬉しいものです。

気軽にコメントする

今まではなんとなく自分が Contribute したことないソフトウェアの Issue にコメントしたりするのは控えていました。特に理由はなかったんですが、重複している Issue の指摘2や、動作や回避策の検証はむしろ積極的にコメントするべきだとこの頃は思っています。というのも、メンテナの方はあちらこちらから Mention が飛んできていて普通に通知を見逃している(と思われる)からです。悪意があるわけではなく。

なのでただ Watch しているだけのリポジトリで、自分が知っている Issue と重複していたり、すぐに指摘できるようなことはコメントをしてしまったほうが良いと思います。GitHub 上ではなんの Contribution にもなりませんが、これも OSS への貢献のひとつなんじゃないかと思います。

まとめ

総合すると、わたしの最近の OSS 活動で意識していることは以下の 3 つです。

  • 自分ひとりで考えるのではなく誰かと協力する
  • 簡単なバグ修正など忙しくて手が回っていないところを助ける
  • コードによる貢献以外にもひたすら Issue Tracker を読んでいるだけでできる貢献もある

あくまでわたしはこうやっているというだけで、ものを作るのが好きで得意な人も居るでしょうし、もっとコミッター、メンテナとして深く関わる道へ進みたい、そのために努力していきたい(している)という人も居るでしょう。そしてそういう人のほうがやはり目立ちますし、説得力もあります3

ですが、たとえ説得力なんて皆無だったとしても、あまり可視化されない「気張らずにやっている人」という立場で何かを伝えられたらなと思い書きました。OSS 活動を何かしようと思っていてもまだ踏み切れていない人4に、何か参考になることがひとつでもあれば幸いです。


  1. 『Team Geak ―Google のギークたちはいかにしてチームを作るのか』 pp.4-5

  2. 重複していると指摘したことがあり、すぐに Close してくれたことがありました。

  3. 例えば、 Node.jsへのコントリビュート解説、そしてOSSへ貢献するということ - 別にしんどくないブログ という記事にいたってはわたしのこの記事の上位互換なのではないかという気さえします。

  4. 自分自身がそうだったように。

近況報告的なやつ

今週はとても疲れた。

仕事が忙しかった、いくつかの心労が重なった、いくつか意思決定をした。毎日家に帰っても業務をし、業務以外のこと*1もなんとかこなした。とてもしんどい1週間だった。

なんとか生き延びて、12月になった。そう、気がついたらもう12月である。

やがて君になる

『やがて君になる』の最新巻(最終巻)が発売になった。

やがて君になる(8) (電撃コミックスNEXT)

やがて君になる(8) (電撃コミックスNEXT)

もう言いたいことは特にないので紹介に留める。ただ何度も言うように、自分が自分であること、そして自分が自分でしかないことを僕が初めて受け入れるきっかけになったマンガである。それで自分の行動がどう変わったのか、みたいな話は今度公開する記事に書く。

blog.515hikaru.net

文章生成

最近なぜか文章の自動生成をするプログラムを書いていた。Encoder Decoder モデルを使ってどうこうするアレである。

例えば、下記のような記事がとても参考になった。

www.pytry3g.com

上記は文章は生成しないが、語彙が異なるだけでやることは同じである。他にも書籍を2冊ほど参考にした。

つくりながら学ぶ! PyTorchによる発展ディープラーニング

つくりながら学ぶ! PyTorchによる発展ディープラーニング

詳解ディープラーニング 第2版 ~TensorFlow/Keras・PyTorchによる時系列データ処理~ (Compass Booksシリーズ)

詳解ディープラーニング 第2版 ~TensorFlow/Keras・PyTorchによる時系列データ処理~ (Compass Booksシリーズ)

かなり疲れたけれど、久々に終わった感のある実装だった。学習ができることがわかったので、これからがスタートという向きもあるのだけど。

しかし Encoder Decoder モデル、最初 Encoder に文章をつっこんで context のようなものを Decoder に与えて、あと Decoder に <bos> token を与えれば文章を作ってくれると初めて聞いたときは「本当にそれだけでいいの?」と思ったのだけど、本当にそれだけでよかった。ニューラルネットワークってすごい。そしてちゃんと文脈変われば出力変わる、すごい*2

そういえば、下記の面白そうな本を買ったんだけど、NLPと結びつけて考えてる人誰か居ないだろうか。少なくとも冒頭にかかれているような内容を読む限りでは、ナイーブには word2vec の考え方とほぼ同じような感じがしたんだが。

前置詞byの意味を知っているとは何を知っていることなのか ―多義論から多使用論へ

前置詞byの意味を知っているとは何を知っていることなのか ―多義論から多使用論へ

いや、あんまわかってないけど。

生き延びた

最初生き延びたと表現したように、久々にしんどい思いをした。そしてまた少々しんどい気がする。今日からも頑張って生きていきますかね。

なんの表明でもないけど、なんかそんな風に思っている。

*1:お金につながることではない。

*2:自然な文章では全く無いけれど。

好きなジンについて雑に語る -- ジン・ウォッカアドベントカレンダー 2019

この記事は、「ジン・ウォッカアドベントカレンダー 2019」 1 日目です。

adventar.org

ノリで企画しましたが、コンセプトとしては好きなお酒について思い出だとかを交えつつ雑に好きなことを語ってもらうという想定です。

初日だしジンの基礎知識だとか、定番のジンみたいなの紹介しようかなとも少し思いましたが、いまどきググれば出てくるしググって出てくる以上のことを自分が書けるわけでもないのでやめます。

わたしはジンについて書きます。といっても、最近おいしいと思ったジンについては結構前にメモ書きを残していたため、あんまり差分がありません。なので、あまり情報はありませんが、わたしの好きなジンの飲み方と、その飲み方で飲んだ時に印象に残っているジンについて書こうと思います。

blog.515hikaru.net

ジンの好きなトコロ

やはり一番好きなのは、同じジンであっても飲み方(ロック、ショートカクテル、ロングカクテル etc..)を変えれば全く違う魅力をみせてくれるところです。

ウイスキーはやはりそのお酒の種類(スコッチ、バーボンetc...)や熟成した樽(シェリー樽、赤ワイン樽 etc...)で味が変わるし、飲み方は好みとかその日の気分や体調次第です。良いウイスキーをハイボールにするのはもったいないという感覚があるように、ベースとなる酒をなるべくそのまま楽しみたいという感覚があるように思います。

しかしジンはド定番のコンビニで売っているビーフィーター・ジンであっても作り手の腕1や、カクテルの種類で全く別の魅力を醸し出します。比較的シンプルなロングカクテル(ジン・トニック、ジン・フィズ)と、ショートカクテル(マティーニなど)では全く魅力が違いますし、1種類のジンでも飲み方を変えれば何度でも楽しめます。

好きな飲み方

身も蓋もないことを言えば、どんな飲み方が良いのかは「ジンとその人によりけり」です。わたしはタンカレーのようなある意味ジンらしいジンをロックで飲むのは苦手です。そして基本的にはロングカクテルが好きですが、ものによってはショートカクテルじゃないと飲まないジンもあります。

ですが、個人的に「だいたいこういうのが好き」とか、「初見のジンはこう飲んでみることが多い」というのを挙げてみます。といっても、変わったカクテルを頼むのではなくド定番な飲み方をします。ていうか、わたしは定番が好きです。

ジン・トニック

なんやかんやでジン・トニックで飲んでみることが多いです。もちろん中には面白さが損なわれてしまうジンもあるので、避けることもあります。しかしクセのないものについてやはりジン・トニックが王道でしょう。

好きなのは Le Gin とか好きです。

ロック・ストレート

事前情報で「ロックで飲んでみてほしい」という情報がある場合はロックで飲むことが多いです。なんだかんだいってジンの味がダイレクトに伝わるので。最近は慣れてきたのもあって、初見でストレートで飲むこともあった。

これはストレートで飲んで美味しかったです。ほぼ終売らしいですが。

www.thewhiskyexchange.com

マティーニ

ロックで飲むほど元気ではないときにマティーニで飲むことがあります。ギブソンも飲まなくはないですが、やはり王道感でマティーニを頼んでしまう。

強めの感じが好きで、No. 3 とかいいですね。

No.3 ロンドン ドライ ジン 700ml 46度 [並行輸入品]

No.3 ロンドン ドライ ジン 700ml 46度 [並行輸入品]

言われるがまま

バーとかで飲むとき限定だけど、結局一番楽しいのは「言われるがまま」に飲むのが楽しい。特に何度か行っている店だと「最近こんなの入ったんですよ〜」から話が弾んでついつい飲んでしまう。

あとお店によって変わったカクテルを作ってくれるお店もあります。その中でも鮮烈だったのはラスト・ワード2でしょうか。ビーフィーター・ジンがめちゃくちゃ美味しいのにはとてもびっくりしました。

あんまり飲みすぎないようにしないとな、と思いつつも結局は飲んでしまう。。

まとめ

自分が好きな飲み方を紹介しました。わたしはあまり意思がないので、流されるままに飲んじゃうこともあります。

健康の問題もありますし、何より節度を保って飲まないと迷惑な酔っぱらいになってしまいます。飲み過ぎには気を付けて、節度を持ってジンを楽しみましょう。

2日目はニラニラは社畜ちゃんさんがジンについて書いてくださる予定です!


  1. わたしにバーテンダーさんの実力がわかっているとは言い難いですが…

  2. リンク先は行ったことのないお店です。。。

多様性という理想と現実の自分

まえおき

ブログで話題にするのを避けるべきことに、炎上しやすいテーマというのがあると思っている。そして自分の視野の範囲で炎上しやすい話題といえば、性差であったり、マイノリティへの発言だったりする。

今日はそんな話を書こうと思った。既に気が重い。書きたくない。

立場をはっきりさせるために、わたしはこうした話題の際には自分の年齢と性別、及び自分が念頭に置いている範囲を書く。わたしはこの記事を書いている時点で26歳男性であり、ITエンジニア、ソフトウェアエンジニアと呼ばれそうな人たちが集まる場を想定してこの記事を書いている。

コミュニティの多様性

勉強会、カンファレンスなどにおいて常々話題にあがるのが、そうした場に女性が少ないことだ。わたしはITエンジニアの総人口を知らないし、男女の比率がどれほどのものなのか知らない。ただ勉強会に行ってみると女性が0人なんてこともあるし、100人とか200人とか参加者が居ても女性が10人も居ない、という現場はよく見ている。

多様性が重要である、と(根拠はなんであれ)信じられ始めている昨今の世界において、どんな場であれ偏りがあるのは喜ばしいことではない。地理的な理由などで外国人の方が少ないのは仕方ない部分はある。しかし蓋を開けてみれば、地理的な障害は少ないはずの日本人に限ってみても勉強会参加者のほとんどが日本人男性であるというのが常だ。明らかに性別の偏りはあるし、その偏りを産んでいる何かがある。

先に断っておくと、わたしにはこの理由はわからない。そしてわからない理由はたぶんわたしが「ITエンジニアの勉強会参加者」というカテゴリにおいてマイノリティに属していないからだ。

人は残念ながら、集団において少数派を無視したり、弾圧したりしがちだ。歴史もそう物語っているし、何も教えていないのに小学生だって集団をつくれば同じように振る舞う。「多様性(ダイバーシティ)が重要である」という価値観はとても自然発生するものではなく、理性的な判断から生まれたものだ。だからこの課題を打破するために施策を講じなければならないし、時間をかけて価値観の変化を促し続けなければならない。

しかしこのテーマにおいてはわたしはマジョリティだ。どんな勉強会に参加することも特に抵抗はない。だから、参加するのを躊躇う気持ちというものが何もわからない。この問題に対してわたしが有効な施策をうつことはできない。何が問題なのか、どれほど頭を捻ったところで気づきようがないからだ。

炎上リスク

マジョリティがマイノリティに対して心無い言葉を投げかけるのが激しく非難される風潮もある。わたしも柄にもなく怒りを覚え、非難をする側に回ってしまったこともある。

誰かを不快にさせるような言動はマイノリティを排斥することにつながるし、コミュニティの多様性を損なう。互いの背景に思いを巡らせ、尊重し共生していくことが美徳とされる。

近頃は行動規範(Code of Conduct)が多くのコミュニティに制定されているのも、そうした流れの一環だろう。誰かを不快にさせる発言・行為・発表は悪だという認識が徐々に広まりつつあるとわたしは感じている。わたしはこの流れを歓迎しているし、コミュニティの一員として行動規範を遵守しているつもりだ。

ところが、コミュニティにて参加者の一員として振る舞うとき、わたしは炎上、非難をとても怖がっている。マイノリティに対して言及したり、何か行動したりすることを過剰に避けている自覚がある。

対マジョリティに対してコミュニケーションを試みるときには、あまり躊躇いはない。しかし、相手がマイノリティだととても怖く感じる。自分が十分に倫理的である保証なんてどこにもないし、自分の言動が誰かを不快にさせない保証なんてどこにもないではないかと考えてしまう。

仮にわたしが問題のある言動をしたとして、そうした言動が正規のルートで運営に報告されれば、それなりの注意や処分を受けることはあっても、社会的に死ぬことはさすがに免れるだろう。しかし、ネット上で写真や動画でも撮られて第三者に晒されれば、どうなるのだろう。

わたしは炎上したことがない。だから炎上したあとの未来というのをうまく思い描くことはできない。多分仕事は続けられるんだろうけど、もしかしたら会社の女性陣から白い目で見られ続けるのかもしれないし、勉強会に参加するたびに「あの人〜〜の会で問題を起こした人だよ」と陰口を叩かれ続ける未来が待っているのかもしれない。あるいは意外と普通に生きられるのかもしれない。

リスク回避

別に注意や処分、批判や非難をやめてほしいと思っているわけではない。実際に問題を起こす人は残念ながら居るし、そうした人を野放しにすることがコミュニティにとって良いことだとは思わない。しかし見方を変えると、マジョリティがマイノリティに接したり、言及した時点でその人はある種のリスクを抱えることになる。

わたしはマジョリティとしてマイノリティに接するという行為に対して、非常に大きなリスクを感じている。そしてこのリスクという感覚は、回り回ってコミュニティの多様性を阻害することにつながってしまうのではないかと思う。たとえマイノリティがその場に居ることを受け入れたとしても、マジョリティと同じように議論や発表、提案や意思の表明、雑談に参加などを自由にできなければ、それは本当の意味でマイノリティを受け入れたことにはならないからだ。

マジョリティの皆がマイノリティを避けているとは思っていない。しかしマイノリティを避けていることと、マイノリティとのコミュニケーションを避ける気はないがたまたまマジョリティ同士でのコミュニケーションしかしなかった人との区別は、第三者にはできない。だからそうしたことをリスクとして認識している人がどれほど居るのか可視化されることはない(わたしだけかもしれない)。

わたしは、正直なところ、マジョリティ同士でコミュニケーションをしているほうがリスクが少なくて楽だと感じている。炎上や非難のリスクが小さくなるし、第三者からは多様性を妨げる行いをしていると思われないからだ。しかし同時にわたしは、この行いが誤っていると思っている。

建設的なフィードバック

人間は易きに流れるものだ。わたしが特定のコミュニティでマジョリティに属している場合、結局マジョリティとしかコミュニケーションしないだろうなと思う。やはり、そもそも参加者の多様性を担保できるよう、マジョリティとマイノリティの区別がその場で生じないよう、参加しやすい会やコミュニティを形成していくしか方策はないんじゃないかと思う。

勉強会を主催したことさえないが、自分のことを棚に上げて偉そうなことを言う無礼を見逃してほしい。

note.mu

たとえば、上記の記事はいくつかわたしにはない視点がある。そもそも立地なんて気にしたことがなかったし、立ちっぱなしはキツイと感じたことはわたしにはない。それはわたしがケガも病気もほとんどしない健康体だからだ。

良い会にするために必要なのは、独身男性の五体満足の若者でマジョリティのわたしの意見ではない。勉強会の参加者として増やしたいのは、マジョリティが気づけない障害で参加をためらっている・参加できない状態に追い込まれてしまっている人たちだからだ。

そのような人たちを会に呼び込めるのは、当たり前のように会に参加できるわたしの意見ではない。基本的には勉強会などに参加はできないが、配慮されている場であれば行ける、という方々のフィードバックが重要なのだと思う。

ローマは一日にして成らず

しかし、こうした人たちに対して気を配ることができたとしても、参加者を増やすことはそれでも難しいだろう。つまらない結論になるが、わたしがなんとかできるわけでも、勉強会やコミュニティの運営がなんとかできるわけでもなく、時間をかけて努力し続けるしかないのだろう。

わたしはあなたではない。あなたのことは完全にはわからない。しかし、たとえわからなくてもあなたが大切にしていることを尊重しようとは思っている。そうした態度で臨み、行動をし続けるしか結局道はないように思う。

終わりに

書きたくないことを書いた。いまわたしにできていることが行動規範を(半ばハックして)守っているだけだという自分が情けないと思ってこれを書いた。わたしはマジョリティだとかマイノリティだとか関係なく、参加したい人が自由にコミュニティに参加できることを望んでいる。

わたしは頑張って理性的な判断をして、多様性が善であると言い聞かせている。わたしはマイノリティを排斥する方向に動きがちな自分の思考を自覚し続けている。しかし、行動を伴わせることが全くできていない。

さて、どうすればいいのやら。

まとめようとしてもまとめられないから、最後にジェンダーフリーなラブソングでも置いておこうと思う。

www.youtube.com