おそらくはそれさえも平凡な日々

NFCタグ入りの自己紹介アイコンバッジを自作する

このバッジにスマホをかざすと、song.mu という自己紹介サイトに飛べるようにした。バッジにはNFCタグが仕込まれている。最近よくあるやつ。

缶バッジだとNFCタグが読み込めない罠

最近は自己紹介グッズとして、pixivFACTORY でアイコン缶バッジを作るのが、lacolaco手法として知られている。私も持っています。

参考: 自分のアイコンの缶バッジを作ると便利

しかし、缶バッジは金属製なのでNFCタグをくっつけても読めません。なので、こういう素人手作り感満載のグッズを作ることにしたのでした。ちなみに、pixivFACTORYはアクリルキーホルダーも作れるのでそれを活用しても良さそうです。

NFCタグシール

やったことは簡単で、以下のNFCタグシールを買って、NFC Tools でURLを書き込んでロックするだけ。

バッジどうするか

コンビニで光沢紙にカラープリントして丸く切ったやつの裏にNFCのシールを貼り付けて、以下のバッジの中に挟み込むだけ。

44mmサイズ

バッジ自体は44mmだが、中に入れる紙は直径41mmで切り出した。切り出しグッズも買った。

54mmサイズ

もう少し大きいサイズだとハメパチというものがあった。これも上の円切りカッターで切り出しても良いが、専用のパンチを使うのもお手軽そうだ。

まとめ

ということで自己紹介グッズを作ったのだった。興味ある方は是非真似してください。大吉祥寺.pmに持っていく予定なので実物興味ある方はお声がけください。

自己紹介サイトの song.mu はBunとHonoとCloudflare Pagesで作ったのだけどその話はまた別途。

ちなみに、Amazonのアソシエイトの画像が廃止になっていたのをスルーしていたのだけど、今回ブクログを使ってアフィリエイトタグを生成した。便利。個人サイトだと現実的な開放になりそう。API使って自作の仕組みを作りたいけど、その辺は追々。

新車を買って体験した最近のロードバイク事情

ロードバイクを新たに一台買った。久しぶりに外でのサイクリングを楽しんでいる。

新車はCannondaleのSuperSix Evo 3べースにホイールをMavicのKSYRIUM SLにアップグレードした。KSYRIUM大好き。

町田のたかだフレンドに10年以上ぶりに顔を出して組んでもらった。ORBEAのORCAが欲しかったのだが、扱いがなかったので勧められたこのバイクにした。信頼できるショップに組んでもらうことが大事。Cannondaleも僕がロードレース見ていた頃のSaecoチームの印象もあるし、このバイクも今どきのバイクにしてはそこまでゴツすぎないのも良かった。

ローラー台生活

コロナ禍始まった頃、健康への危機意識からローラー台を買って、部屋で毎日のようにロードバイクを漕ぎ出した。数年続けた結果、パフォーマンスが上がって、興が乗ってヒルクライムレースにでも出るかとなって、そのためにレース用に1台買うか、となったのがきっかけ。

このローラー台に固定しているやつは20年前に買ったやつで、時間的には十分長く乗った。今から20年後となると僕はもう60歳を越えている。まだ肉体的なパフォーマンスが辛うじて維持できているうちに、もう一台買ってもよかろうという判断。結果として今は部屋に3台ロードバイクがある。

今どきのロードバイク

正直あまり新しいロードバイクを買いたいとは思っていなかった。今どきのロードバイクの進化の方向性があまり好みではなく、それなのに異常に値上がっているというのが大きかった。いかにも懐古主義的な意見である。

上の青いバイクは、当時の最高グレードのフレーム、パーツ、ホイールで揃えたものだが、それでもトータル50万円台くらい。それを今同じグレードで揃えようとすると150万円位かかってしまう。今、50万円では当時から数段階グレードが落ちたバイクしか買えないのである。

今どきは見た目もゴツい。エアロ形状のためかもしれないが、スマートさに欠けて見えてしまう。ただ、僕がロードに乗り始めた20年前とかも「最近のバイクはフレームが太すぎる」と言われていたので、自分が乗り始めた頃のバイクが一番カッコよく見えてしまうという刷り込みみたいなものだとは思う。

あと、電動変速。これは心理的に受け入れるのには抵抗があった。とはいえ、プロ選手は全員電動変速を使っている状況だし、不可逆の変化として受け入れることにした。トレンドに抗っても仕方がないという大人の諦念。

電動変速に限らず、その他の面でも自分でメンテナンスするのではなくショップにお任せするのが強く推奨される流れになってきている。最終的には自分でほぼ全部メンテナンスできて然るべきだと考えて自転車いじりを楽しんでいた身からするとブラックボックスが増えてしまうのは少し寂しい。車の修理権的な話。とは言え、とんでもない速度でかっ飛んでいく乗り物なのだからプロにメンテナンスを任せるのは至極真っ当ではある。実際、多くのパーツがメンテナンスフリーになってトラブル率も減っているはず。

ということで、今回のバイク購入にあたっては、変に過渡期のものを買っても仕方がないと考え、最新のテクノロジーを積極的に導入することにした。具体的には、コンポーネントをSHIMANO 新型105 Di2にしてワイヤレス電動変速と油圧ディスクブレーキを導入し、ホイールをチューブレスレディにすることは狙っていた。

その辺りを満たせるものを買えたので良かった。結局70万くらいかかって当初の予算はオーバーしたが、妻には「もっと高いの買うのかと思ってた」とか言われた。良くわかっていらっしゃる。

気になる重量は8.3kg。元のバイクは8kgジャストだったので、重くなっている…。まあ、誤差の範囲内で、走りは良くなっていると思いたい。実際乗ってて快適なので満足はしている。

実際に買って、乗ってみると色々と時代の変化も感じられて面白い。ざっと書き出すだけでも以下のような新しい体験や知見があった。

YAPC::Hiroshimaの安心感と進化に感動した話

だいぶ時間が経ってしまいましたが、YAPC::Hiroshimaで「Blogを作り、育み、慈しむ ~ Blog Hacks 2024」というタイトルでトークをしてきた。

https://junkyard.song.mu/slides/yapc-hiroshima-2024/#0

YAPC::Hiroshimaのテーマが "what you like" ということで、Blogについて話す機会となったのは良かった。いつもながらとっ散らかってしまったが、それなりに面白い話はできたんじゃないかと思う。昼イチのセッションで同時刻の別トラックのスピーカーが強力だったので、まあそんなに聴衆来なくても逆に気楽に話せるから良いか、位に考えていたけど、思った以上に聞きに来てくださったし、質問も出て嬉しかった。ありがとうございました。

ありがたいことにログミーTechで書き起こしていただいた。

IndieWeb周りはもう少し調べたかった。この辺はもう少し調べるなりしてbuildersconのプロポーザルを出そうと思っている。

書籍 Blog Hacks

トークタイトルはもちろん、miyagawaさんとnaoyaさんが代表著者の書籍、Blog Hacksにちなんだものだ。この本はBlogいじりの楽しさについても書かれた本であるが、それが2024年だとどうなるのかについて話したかったというのがある。この本は2004の本でなんとちょうど20年前の本なのだ。

広島にはBlog Hacksの書籍を持っていったが、前夜最後に941さん幹事の飲み会に混ぜてもらい、そこで著者のお二人からサインを貰うことができた。941さんもノリノリでサインの儀を執り行ってくださってありがたかった。

翌日の懇親会で「miyagawaさんとnaoyaさんと写真写ってた人ですよね?」とか若い人に話しかけられたりして面白かった。YAPC初参加とのことだったがRebuild.fmでmiyagawaさんとnaoyaさんは知っていたとのこと。若い人にリーチしていてすごい。

参加者448名!

旧交を温められて同窓会感がありつつも、若い人も多く、約半数が初参加ということで驚いた。

正直、地方開催するPerlの技術カンファレンスにこんなに人が集まると思っておらす、これは、完全に見くびっていた。所属のヘンリー社でのスポンサーも打診されていたのだが、僕の個人的な趣味でスポンサーする感じになると嫌だなと思ったこともあって見送っていたが、完全にこれは費用対効果あったし、ちゃんと情熱稟議を出すべきであった。これはPerl、YAPC好きとして慙愧の念に耐えない。

BASEのCTO川口(id:dmnlk)さんが「カンファレンススポンサーのススメ」というスポンサーLTで、初参加のYAPCながら、ちゃんとスポンサー稟議を通した話をしていて、完全に尊敬です。

何にせよ、これだけ盛り上がったのは、運営の努力の賜物であり素晴らしかった。

トークのごった煮感

Perlのイベントと言いつつ、いつも通りの全体的なトークのごった煮感は良かった。マネジメントの話・技術的にコアな話・事業の固有ドメインの解説とその実装の話など、ここまでトークが多様なカンファレンスもなかなか無い。ちゃんと毎回Perlのアップデートの話があるし、その他Perlの話があるのも良いですね。

個人的には「awkでつくってわかる、Webアプリケーション」が面白かった。

意外な旧交

とにかく旧交を温められたし、コロナ禍中にオンラインで知り合った人とも会えたりしてよかった。

意外な邂逅だとSugamo.cssの主催者だった、 Sig.さんと会えたのはめっちゃ良かった。今は広島に住んでいたこともあり参加したとのことで、僕のことも探して話に来てくれた。これは嬉しかった。

懇親会でも話して、お互いロードバイク乗りなので、一緒に自転車のヒルクライムイベントに出る話になり、ツールド美ヶ原に申し込んだ。実は、知らなかったが、前日の2/9(金)から丁度、富士ヒルのエントリーが始まっており、Sigさんは申し込んだということだったので、そっちに一緒に出るかという話もしていたのだが、その日の夜は既に申し込みを締め切っていた。富士ヒル恐るべし。

Sugamo.cssは実は僕が初めて深く交流した技術コミュニティなので思い入れがある。

杜甫々さんキーノート

参加者全員が何度も言っていることだが、とほほさんのトークはとにかく素晴らしかった。

これも誰もが言っているように、最後の「なぜ発信を続けられているのか?」という質疑に対して、「好きだから」という回答がでてきたのはすごかった。"what you like"がテーマのYAPCを締めくくるにふさわしかった。

僕も「好きだから発信を続けられている」というトークをしたので、完全にその上位互換の発表を目の当たりにして、ショックを受けつつもしびれました。

kobakenさんのクロージング

最後のkobakenさんの締めも良かった。話す姿が堂に入っており、特にスポンサー社名を一つ一つ丁寧に読み上げて感謝を伝える部分の途中で「これちょっと手疲れるかもしれないんですけど、頑張ってみてください。53あります」とおもしろめかして参加者に拍手を促しながら笑いを取っていた部分でめちゃくちゃ感動してしまった。

彼のことは若い頃から知っているのですが、そのリーダー的振る舞いをみて「これはリーダーとして越えられたかもな」とか感慨にふけってしまった。そのリーダーシップがYAPC::Hiroshimaの成功の大きな一因でもあると感じる。

YAYAPC

そのkobakenさんが企画した、YAPCの翌日のアフターイベントのYAYAPC::Hiroshima ~オフラインだからできる話〜も盛り上がって良かった。僕も、スタートアップとSOについての話をしてきました。内容は非公開です。

その後、てっぺん回るまで飲み明かしたのでした。

次回のYAPC::Hakodate 2024も楽しみにしています。

ISUCON13 カラアゲネイティブチーム 15位

近年ISUCON出場のBlogを書いていませんでしたが、一応毎年出場はしていました。ISUCON9は本戦が娘の運動会と被っていたため、予選を一人チームで出て当然惨敗した。それ以降、ISUCON10, 11, 12, 13は、motemen, toricls(トリ)と「カラアゲネイティブ」というチーム名で出場している。馬が合うメンツなので楽しく参加している。

ISUCON10は予選突破ならず。ISUCON11は予選突破できそうだったが次点1位で本戦出場を逃す。これはもう、ふらりと当日参戦するスタイルはやめてISUCON12は流石にちゃんと対策しようということになり、初めて事前のチーム練習を実施したが、結局予選を突破できずであった。これは結構ショックが大きかった。

今回のISUCON13は同じメンツで参加はする話はしていたが、個人的にはあまりモチベーションは高くなかったのが実際のところだった。それに、トリさんがUS出張でフライトの時間が被っていて、後半からの参加になることになり、それもあって、ゆるく頑張るか、というチームの雰囲気だった。果たして、事前の打ち合わせすら全くせず本番を迎えたのであった。

競技開始

開始前にチームのDiscordで音声通話を繋げて、3人で会話。競技開始前にトリさんは飛行機に搭乗し一旦離脱。競技が開始され問題を見たら、DNSが組み込まれている新機軸で一気にテンションが上った。すわDNSサーバー自作か、とか思うなどしたが、そこは落ち着いて問題を見て対策を立てていった。

NginxからのICON配信

とりあえず、ICON配信が一つの関門ぽかったので、餅は餅屋ということで静的配信Nginxに任せ、1台目のサーバーからICONを配信することとした。conditional getがちゃんとできるかは定かではなかったが、Nginxならできるやろ、とか思っていたが、どうもそうではなかったらしい。とはいえ、NginxからICONを配信するようにしたらスコアは上がったので結果オーライである。後から振り返ると、今回はこういう、正答ではないが暫定対応がうまくハマってスコアが上がったケースが多く、運が良かった。

ただ、ここのNginxの設定に苦戦した。アイコン画像がない場合に NoImage.jpg を配信する必要があった。これは try_files ディレクティブを使えばイケるやろ、と思っていたが、ここでは aliaserror_page ディレクティブを組み合わせる必要があった。これに異常に時間を取られてしまったのは痛恨。

昼過ぎに、フライトを終えたトリさんがホテルから参加。長年チームを組んでいることもあって特に説明無くキャッチアップしてくれたのは良かった。

複数台構成

とりあえず、PowerDNSで使っているMySQLの負荷がいかんともしがたかったので、アプリケーション用のDBは3台目のサーバーに移すこととした。ついでにGoのアプリケーションも1台目と2台目に動かして分散するようにした。2台目のサーバーは必要になったらRedisも同居させる想定。実際この前後でRedisをmotemenが立ててくれた。どのサーバーにどのミドルウェアを置くかといった構成案はチームで既定路線の慣れた動きになっていて、阿吽の呼吸になっているのは楽。

あとは、encoding/jsongoccy/go-jsonに差し替え。毎年やっているので、以下の置換ワンライナーがシェル履歴から呼び出せて笑ってしまった。

$ perl -i -pe 's{"encoding/json"}{"github.com/goccy/go-json"}g' **/*.go

競技開始当初はバタついたが、トリさんも競技開始して、細かい改善も色々入りスコアとしてはこの時点で3万超えくらい。安定的に10位前後に位置取りできるようになってきた。TOP3辺りで、ヘンリー同僚のataganが参加している「都営三田線東急目黒線直通急行日吉行」チームが奮闘しており、励みになった。

しかし、ここもPowerDNSの負荷に向き合うのではなく、適当に負荷分散したら凌げた、という話なのでうまく噛み合った感がある。最終的な構成は以下。

10万点超えと終戦

後は水責め攻撃に対する抜本的な改善は諦めて、Redisに置けるデータはRedisに置くようにしたり、N+1を潰したり、複数台の負荷分散の調整などの作業を各自で実施して地道にスコアを上げていった。ここで、Go 1.21で入った新機能である sync.OnceValue を使えたのが個人的に少し嬉しかった。

今回は、再起動試験もちゃんと実施できたのは良かった。レギュレーションを読むと競技中の最終計測が競技スコアとなるようだったため、再起動後にスコア計測を何度か行い、105,751を提出スコアとした。

TOP10に入れるかと期待していたが、結果としては15位だった。まあ、カラアゲネイティブチームとしては最も良い成績を挙げられたので良し。

反省

カラアゲネイティブでチームを組むのが4回目で、勝手知ったる感じがあってやりやすかった。お互いがやってることをうまく把握し合いながらうまく戦えて楽しかった。

ただ、運が良く噛み合った感もある。本丸のDNS水責め攻撃は特にこれといった対処はしなかったし、ICONのconditional getもそう。何れも暫定対応がそこそこうまくいってしまった。

カラアゲネイティブのメンバーはスキルセットが似通っているので、やりやすさはある反面、技術領域のカバレッジがそこまで高くない所に課題がある。特に、インフラ面の弱さ。そんじょそこらのインフラエンジニアには負けないとは思うが、ウー馬場イーツチームとかと比べると差は感じる。PowerDNSに無抵抗だったのも結局そこが課題。

なので、このメンツでの伸びしろを感じづらくなってきているが、組んでて楽しいメンバーなので今後も機会があるなら出場を続けていきたい。4年間でチーム内でのノウハウも溜まってきているので、その辺りは別途アプトプットできればと思う。

今回も素晴らしい大会運営ありがとうございました。毎回、次回のISUCON開催が心配されますが、今回は特に不透明な状況かと思います。個人的にはISUCONには大変お世話になったので色々思いがあります。多くのOSS、技術カンファレンスやイベントが、実はすごく不安定ながら継続している儚いものであるということが改めて思い起こされます。インターネット自身がそうであるように。だからこそ、尊いものでもあるし、エンジニア個人としても興味を持ったらその時点ですぐに参加してみるのが大事です。もちろん継続性に向き合っていかないといけないものもありますが。ただ、いつまでも続くように見えているものが、あっけなく終わるということは、全然珍しいことではありません。

参考

静的サイトをFediverseに対応させる

当サイトをFediverseに対応させました。 @songmu.jp@songmu.jp でMastodonなどでリモートフォローできます。

やったことは、 このブログがFediverseに対応しました というtyageさんのエントリーをそのままなぞっただけです。このエントリーはh-cardのサイトトップへの掲出に関する説明が書き漏れていそうでしたが、それも実施しました。

当サイトは静的サイトであり、付随機能は外部サービスに頼りたいと考えている。例えば、コメント機能はDisqusを使っている。Fediverseに関しても何かそういうサービスがないかと思っていたが、Bridge Fedというサービスがあり、上記のエントリー内で懇切丁寧に解説されていたので導入は比較的簡単で、作業時間は小一時間でできた。大まかな手順は以下。

  1. Bridgy Fed というサービスを利用してサイトをFediverseに対応させる
    1. "/.well-known/host-meta"と"/.well-known/webfinger"を Bridgy Fed にリダイレクトする
    2. Bridge Fedが当サイトのコンテンツを解析できるように、htmlテンプレートにmicroformatのクラスをいくつか足す
      • h-card, h-content, e-entry等
  2. サイト更新時にBridgy Fedに通知する
    • 投稿記事のURLをAPI投稿
      • curl一行でいける
      • GitHub Actionsに仕込む
  3. webmention.io との連携
    • これは追加対応なのでやらなくてもいいが、単に <link rel="webmention" href="https://webmention.io/blog.tyage.net/webmention" /> と言ったタグを仕込むだけなのでやると良い
    • Webmentionは記事への反応や言及を通知するプロトコル
      • 現代版Trackbackとも言える存在で、2017年W3C勧告
    • Webmentionが実装されたサイトがwebmention.io
    • webmention.ioへのログインの仕組みがindieloginというやつで、例えば <a href="https://github.com/Songmu" rel="me">github.com/Songmu</a> というタグをトップページに仕込んでおけばGitHubログインできる(他のログイン方法も選べる)というもので、面白かった。

当サイトは、Rijiという自作のPerl製の静的サイトジェネレーターで生成したHTMLをFirebase Hostingで配信しています。

やっぱこういう個人サイト弄り楽しいよね、と言う話を来週の YAPC::Hiroshima 2024で「Blogを作り、育み、慈しむ - Blog Hacks 2024」というタイトルで話す のでご興味ある方はぜひ聞きに来てください!

肉じゃがメタアナリシス

このエントリーはバズレシピ Advent Calendar 2023、11日目の記事です。

日本人皆が大好き肉じゃが。メジャーな料理なので、多くのYouTuberがレシピを公開してくれている。ここでは私がよく見ている料理系YouTuberの中から以下の動画を参考にして、最高に美味い肉じゃがの作り方を考察してみたい。

豚肉か牛肉か、男爵かメークインか

まず主役の肉とジャガ。意外と肉は牛肉派が多かった。リュウジさんだけ豚肉。さすがは庶民の味方ですね。まかないチャレンジは分量が多いので、半量くらいにすれば他のレシピと大体目方が揃いそう。

リュウジさん 豚 250g 男爵 400g
クラシル 牛 300g メークイン 3個
シズるチャンネル 牛 200g メークイン 200g
まかないチャレンジ 牛 400g 言及なし(多分男爵) 1kg
くまの限界食堂 牛 150g 言及無し(多分男爵) 3個
コウケンテツさん 牛 200g メークイン 2個

複数見て気づいたこととしては、牛肉とメークイン、豚肉と男爵という組み合わせが良いようだ。関西のすき焼きのような、砂糖強めの上品な甘カラな味付けの場合には、牛の脂とツルンとしたメークインの食感が合うのだろう。

また、肉とジャガの分量は肉1に対してジャガ1.5~2くらいが目安になりそう。

私としては、豚肉と男爵の組み合わせで作りたい。個人的に肉じゃがって庶民料理だと思うので、どうも牛肉を使う気になれない貧乏性。

その他材料

玉葱 人参 白滝 青味
リュウジさん 250g 300g 200g 青ねぎ
クラシル 1個 1/2本 - 絹さや
シズるチャンネル 260g 160g 160g -
まかないチャレンジ 2個 - 180g モロッコインゲン
くまの限界食堂 1/2個 1/2本 - -
コウケンテツさん 1個 1/2本 - -

見比べてみると、玉葱は当然マスト。人参もほぼマスト。白滝は半々。青味は案外使われていなかった。動画映え的には必ず使われそうなものだが意外。リュウジさんは適当なようで、こういうところで最後に青ネギを散らしてくるところが流石感ある。

私としては、白滝は欲しい。出汁を吸った白滝美味しい。青味は絹さやがあると色味としても食感的にも嬉しいけど、処理めんどいし無くても良い。

下処理Tips

しらたきのアク抜きは水道の温水で十分

アク抜き済みのやつならそのまま使えばいい。アク抜きする場合でも別に茹でこぼさずとも、リュウジさんの動画にあった、水道の蛇口から出る42度くらいの温水をつかってザルで洗えばよいというのは、機会があれば真似したいと思った。

じゃがいもの皮むきにアルミホイルを使う

芽さえ取れば、皮付きでも良いと思っているが、これもリュウジさんの動画にあった、アルミホイル丸めて、たわし状にし、それで皮をこそぎ剥くのは面白いアイデアだった。

これはやってみたが、歩留まりも良いし、剥ききらずに皮の風味も残る感じになるので結構良い。ただ、時間は包丁で剥くのと実はそこまで変わらない。

玉ねぎの皮むき前に水につけておく

包丁で上手く剥けるようになりたい…。これは、まかないチャレンジにあった、皮を剥く前に水に漬けておくというのは結構良かった。玉葱の皮がばらばらになりづらくなり、まとまって剥きやすくなると思う。

調理工程

玉ねぎの切り方

基本はくし切り。面白かったのはコウケンテツさんのレシピで、半量は薄切りにするというもの。これは先に入れる玉葱は薄切りにして、タンパク質分解酵素を働かせやすくして、肉を柔らかくするため。

具材への火の通し方

具材を最初に炒めてメイラード反応で香ばしい旨味を引き出すか否か。特に悩ましいのが肉で、肉は炒めると固くなりがち。柔らかい食感を出したいのであれば炒めずにふわっと煮たい。ここは、それぞれ調理方法が千差万別で面白い。

ここで面白いのが、まかないチャレンジの半量を炒め、半量を後入れする方式。メイラード反応の香ばしさと、ふわっと煮た柔らかい肉の両取りを狙う欲張り手法。これは参考にしたい。

クラシルとコウケンテツさんは全く炒めておらず、上品な優しい味になりそう。また、クラシルさんのレシピでは、火を通した後に冷まして具材に味を染み込ませることを手順に明示している。炒めて味にパンチを出さない分、しっかり具材に味を含ませるというのが大事なのでしょう。丁寧に作る場合はそういう作り方をしたい。

味付け

醤油 みりん 砂糖 だし 生姜
リュウジさん 大4 - 大2 大6 白だし 大2 - 15g
クラシル 大4 大4 大1 - 顆粒だし 3g 900cc -
シズるチャンネル 85g 60g 80g - 出汁 400g - -
まかないチャレンジ 大6 - 大6 200cc - - -
くまの限界食堂 大3 大2 大1 - - 300cc -
コウケンテツさん 大3 大1.5 大1.5 大3 - 400cc -

醤油に対して、みりんや砂糖で甘味を足す。甘みの加え方は結構バラバラだが、みりん+砂糖の量が、醤油と同じかそれより少し多いくらいにどれも調整されている。

みりんを使わないレシピがあるのも意外。リュウジさんとまかないチャレンジがそうだが、この2つは水を使わずに酒で蒸し煮にしている点が共通している。酒で旨味が足されているので、みりんはなくても良いということかも知れない。個人的Tipsとして、酒+砂糖で調味するときは、砂糖の代わりに一部ハチミツを使うと、味に奥行きが出て良いです。

旨味について考察すると、肉じゃがだと動物系のイノシン酸は肉から出るから良いとして、昆布系のグルタミン酸の旨味成分もあると嬉しい。上3つのレシピはダシ系の調味料を加えることでそれを実現していると思われる。

グルタミン酸で考えると、味の素を加えるというのが良さそうだが、意外とリュウジさんのこのレシピでは使われていなかった。みりんを使わず、白だしと生姜を加えている点でも、攻めた味付けになっているといえる。このレシピだけ生姜が使われてるが、このレシピだけ豚肉なので、臭み消し的な意味合いもあるのかも知れない。

私としては、醤油 : みりん : 砂糖を 2 : 1 : 1 くらいで味付けをして、味の素も適宜振り入れ、水を使わずに酒で蒸し煮にするのが良さそうに思っている。

落し蓋

荷崩れを防ぐ意味でも、味を均等にしみさせるためにも必要。クラシルで、キッチンペーパーを落とし蓋にする方法を紹介しているが、この方法が個人的にもベスト。煮汁少なめの時でも味が行き渡る。

リュウジさんとまかないチャレンジは落し蓋をしていなかった。蒸し煮で時短で作るレシピだからだとは思う。ただ、蒸し煮にする場合であっても、煮汁が少ないこともあって、落し蓋したほうが良いと思っている。キッチンペーパーを使うやり方だったら手間もかからない。

他のレシピだと、クッキングペーパーを器用に切って落し蓋にする方法を紹介していて、よく見る方法だけど、個人的には手間に感じてやったことはない。

レシピ完成形

上記のメタアナリシスを踏まえ、完成形のレシピはざっと以下のようになる。

材料

手順

  1. 肉を半量炒める
  2. 薄切りにした半量の玉葱、人参、じゃがいもを加えて軽く炒める
  3. 調味料、残りの肉と玉葱、白滝を加える
  4. キッチンペーパーで落し蓋をし、その上から酒を注ぐ
  5. 蓋をして蒸し煮をして火が通れば完成

一回冷ますとより味が沁みて美味しくなるでしょう。青味はお好みで加えてください。

クラシルやコウケンテツさんのように炒めずに時間をかけて丁寧に味を含ませるやり方も別解となるので、それもやってみてください。

はてなブログとblogsyncの歴史

ヘンリーでVP of Engineeringを務めるSongmuです。このエントリーは株式会社ヘンリー Advent Calendar 2023 、11日目の記事です。

はてなブログとblogsync

はてなブログにはAtomPub APIという、はてなブログをAPIで操作できる機能があります。これは実は結構古くからある機能で、2013年にリリースされています。当時のはてなインターン生によるもので、moznionさんkrrrrさんが担当されたようです。歴史を感じますね。

そのAtomPub APIを利用し、はてなブログを管理するためのCLIツールとして、当時はてな社のチーフエンジニアで現CTOのmotemenさんが「個人で」開発したGo製のOSSがblogsyncです。これは2014年にリリースされています。社員が自社サービスのユーザーであり、社員が趣味の個人開発でそのサービス利用のための便利ツールを作るという流れは、はてならしくて好きです。

blogsyncのメンテナ引き継ぎ

このblogsync、2015年にコミット権を付けてもらい、私Songmuが実質メインで細々とメンテナンスを続けています。以下のスクリーンショットがその様子です。ちなみに、同様にmotemenさんから私がメンテナンスを引き継いだ他のGo製のOSSにghqがあります。

ちなみに、blogsyncは当初、はてなブログに限らない多くのブログサービスのコンテンツをローカル管理することを目論んでおり、その命名になったと聞きました。はてなブログはあくまで最初の対応サービスという位置づけということです。結果として、今ははてなブログにフォーカスするツールになりましたが、このあたりはmotemenさんらしい壮大な思惑を感じます。ghqが実はGit以外の数多くのVCSに対応しているように。

私がblogsyncに手を入れ始めた経緯としては、当時携わっていたMackerelというサービスのドキュメント類をはてなブログでホストしていたため、それらをバージョン管理したかったからというのが理由の一つにあったと記憶しています。

そのあたりの話はMackerelドキュメントをGitHubで管理して、はてなブログでホストする ~ Mackerelの場合という2015年の記事に書かれています。ドキュメント管理のためのGitHubリポジトリは当初はprivateリポジトリのみでしたが、その後、公開リポジトリも作られて現在に至ります。

blogsyncのメンテナンスは、2018年に、blogsync v0.9.1をリリースしました というエントリを書いており、ここである程度一段落していました。

完全自動化への道と公式ワークフロー

blogsyncは便利で、多くの企業のエンジニアブログでもご利用いただいています。しかし、ブログ記事の公開、更新を含めたリリース作業には手元でのコマンド作業などの手作業が必要になることが多く、GitHub上での完全自動化には、もう一息な部分がありました。実際各社が事例を出してはくれていたものの、かなり頑張って複雑なワークフローを組まれているという実情がありました。2019年にGitHub Actionsがリリースされ、より自動化への機運は高まっていました。

そしてついに今年、はてなブログ開発チームから、はてなブログ運営をGitHub上で行なうためのテンプレートリポジトリが公開されました。これは内部的にblogsyncが利用されています。このリポジトリに組み込まれているワークフロー利用することで、はてなブログコンテンツのバージョン管理と、運用自動化が捗るようになりました。これは、はてなブログ本体とblogsync両方に細かい機能改善が入ることで実現可能になったものです。

とは言え、blogsync側の機能不足が起因で、ワークフロー側にかなり頑張った実装を強いている部分があります。これを個人的に申し訳なく感じ、それが改めてblogsyncのメンテナンスに意欲を出す契機にもなりました。結果的に、今年はこれまでになく最もblogsyncに手を入れた年になりました。

今年の更新

今年の大きな変更をざっと書き出してみると以下のようなものがありました。ここでは個別の説明は省きますのでリポジトリを参照下さい。別途解説エントリを書くかも知れません。

ちなみに、issue番号やblogsyncのバージョンの今年一年での変遷は以下のとおりです。急成長が伺えます。

blogsyncの今後

blogsync側でもGitHub上でのコンテンツ管理をやりやすくするワークフロー機能を開発したいと考えています。それを、はてなブログオフィシャルのワークフローにバックポートするような形にできればと考えています。このあたりは、今年からはてなブログ開発チームとのMTGやコミュニケーションを必要に応じて随時実施することになりましたので、協調しながら進める予定です。

また、はてなブログは日本のサービスですし、blogsyncのissueやpull requestは日本語でも構いません。私も今年から場合によっては無理せず日本語を使うようになりました。日本の開発者にとってとっつきやすくなったと思いますので、貢献もお待ちしています。

https://github.com/x-motemen/blogsync

はてな社からの寄付

はてな社からの正式なアナウンスはまだされておらず、フライングとなりますが、この度、これらのblogsyncへの貢献に対して、GitHub Sponsorsではてな社から寄付をいただきました。この記載については許可をいただいており、後日はてな社からもアナウンスがあると聞いています。(ちなみに、私は以前はてな社の社員でしたが2019年に退職しています。)

とてもありがたいお話で、これを励みにして引き続きOSS貢献を続けていきます。GitHub Sponsorsやghq handbookへの寄付は随時受け付けています。少額で構いませんので是非ご検討下さい。

ブログと歴史

当ブログは、はてなブログではないのですが、私のサブブログは、はてなブログでホストしています。また、私が所属しているヘンリーのエンジニアブログも、はてなブログです。これらの運用ではblogsyncを使っているので、特にヘンリーのエンジニアブログについては解説エントリを書きたいと思っています。また、ヘンリー社では絶賛エンジニアを採用しており、僕と一緒にエンジニアブログを書いてくれる人を募集しています。

さて、このエントリを書くにあたって、過去の経緯を調べ直しましたが、blogsyncをメンテナンスし始めてから10年近く経っていることに驚き、そして、それらにまつわるの過去の歴史が、はてなブログ上で数多くホストされ、残存していることに更に驚きました。

改めてブログは良いものだと思うと同時に、コンテンツ残存のために、はてな社が企業努力されていることに、敬意を表したいです。

Happy Blogging!

同僚をどう呼ぶか ~ さん付けやあだ名など

数年前から業務上では同僚に通りの良いあだ名がない場合、極力「さん」付で呼ぶように意識している。新卒やインターンの大学生を無条件で君付けで呼ぶみたいなのをやめたいと思ったのだ。

呼称から暗黙の権威勾配が生まれることは少なくない。例えば、上司が部下を君付けで呼び、部下が上司をさん付けで呼ぶという光景はよく見られる。上下関係が前提にあり、逆転させると違和感を感じるはずだ。こういう暗黙の権威勾配は双方の心理に染み付いてしまい、構造を変えるのが難しくなる。

逆に、我々のIT業界では、新卒やインターン生が数年後に自分の上司になることも珍しくない。流動性が高くて素晴らしいことである。その時に呼び方を「君」から「さん」に変えるのもおかしな話である。そもそも上下関係によって呼び方が変わるのはナンセンスだと私は思っていて、仕事の上ではお互い一人前の大人でリスペクトしあいたいし、個人的にフラットさを志向しているというのもある。

それも踏まえて、自分は以下の判断基準で相手をどう呼ぶかを決めている。

本エントリーでは、その私のポリシーについて解説していく。

どう呼んで欲しいか表明すること

相手が望む呼び方がある場合、よっぽどおかしいものではない限り、それを用いている。

呼ばれる側がどう呼んで欲しいか表明してくれるのもありがたいと思っていて、最近の ossanfm ep.256 でゲストのKaoriさんが、結婚後の姓の山本よりも香織の方がアイデンティティがあり、どちらかと言うとKaoriさんと呼んで欲しいため、SNS上の表示をそれに変更した、という話があって、良い表明方法だと感心しました。

場合によっては、フラットじゃない呼び方を相手が望む場合もあります。例えば「社長」や「部長」と言った肩書付加を望むなど。この例は今どきなかなかないとは思いますが。これも自分のポリシーに反しない限りは相手に合わせています。

また、相手がどう呼んで欲しくないかを尊重するのも大事だと思っています。これもまたossanfmの話で、パーソナリティの栗栖さんがどこかのエピソードで「栗栖社長と呼ばれると違和感がある」的なことをおっしゃっていました。実際、栗栖さんは「栗栖さん」と呼ばれる方を望ましく思っているだろうから、そう呼んだ方が良かろう、ということです。

組織においては、自分がどう呼んでほしいか表明しやすくする雰囲気作りも大事で、最近ヘンリー社では、社員にNotion上で「ユーザーマニュアル」を書いてもらうことを推奨していますが、そこのテンプレートに「どう呼んでほしいか」の項目を設けています。例えば私は以下のように書いています。

ちなみに、皆が呼称を表明すべきだという話ではなく、特に当人にこだわりがなければ、私からは普通に「名字+さん」で呼ばせてもらえれば良いと思っています。

あだ名/ハンドル/ID文化の良さと危うさ

フラットさを志向して、あだ名で呼びあう会社がある。結構なことだと思う。あだ名/ハンドル/ID等の宣言は「自分をどう呼んで欲しいか」という自己表明・開示なので、前項の通り尊重すればよい。それを表明しやすくする施策としての、あだ名文化は良いと思っています。私も、はてなという社員全員がはてなIDで呼び合うのが前提の会社にいたことがあり、その有用性は感じています。

ただ、自分にあだ名的なものを付けること気恥ずかしさを感じる人は当然多いし、同僚とそういう距離感で仕事をしたくない人もいるので強制することでもないと考えている。

更に言うと、あだ名を別の人につけてもらうケースは危うい。エンジニアはよく知っていると思うが、命名には力がある。「名付け親」という言葉があるように、名付けというのは権力的な行為で、暗黙的な権威勾配を生む可能性があるのだ。特に「社長が新入社員にあだ名を付けてみんなでそれを呼ぶ」とかやるのは非常に危険。

あだ名文化であっても、自分で決めるのが大事。もちろん、あだ名をつけるのが上手い人というのはいて、そういう人の案を採用するのは良いですが、ちょっとでもしっくりこなかったらNoを言うのも大事です。変にあだ名圧に負けずに「普通に〇〇さんと呼んでください」と表明するのも良いと思います。

ちなみに、あだ名にさん付けするのか、呼び捨てなのか問題というのもありますが、対称性を意識しつつ、なんとなくしっくりくる呼び方をチョイスするようにしています。

具体的には、基本はさん付けですが、敬称をつけないほうがしっくり来る場合には敬称を略させてもらうこともある (例: achiku, astj)。君付けは基本はしないけど、あだ名にクンがついている場合はそのまま呼んでいる (例: ninjinkun, dekokun)。

対称性重要

これまで何度か述べてきた通り、呼称には対称性を求めたいと思っている。お互いが「さん」づけ、お互いが「君」付けだったり呼び捨てなのであれば違和感は無い。ただ、相手が「さん」付けで呼んでくるのに、相手を「君」や呼び捨てで呼ぶのは避けたい。私の方が上だと思われてしまうような呼び方は避けたいのだ。

少なくとも、こちらが「さん」付けで呼んでおけば、敬称の面では自分が暗黙的な権威勾配の上に立つことは少なかろうと思っている。お互いの距離感もあるので、相手が望む呼び方を表明していないのであれば、最初は基本は「さん」付けスタートとなる。

ビジネス上はさん付けじゃないといけないと思っているわけではない。例えば、新卒の同期だったり、大学からの同級生同士が、君付けだったりあだなや呼び捨てで呼び合ってたりするのを見ると、良いなーとか思って見たりしています。これはちゃんと対称性があるし。個人的には業務上そういう関係性の人はいないので少し羨ましくもあります。

私自身のケースだと、大学時代の中国語クラス関連の友人たちは「ソンムー」と呼び捨てにしてくれるが、仕事や技術コミュニティでは「ソンムーさん」と呼ばれてしまうことが多い。まあ、残念ながら私はなんか圧があるみたいだしね。なので、こちらも多くの場合は「さん」付けさせてもらうことになる。

ちなみに、ISUCONフレンズの、白金動物園のsorah、rosylillyとかは、私のことを「ソンムー」呼びしてくれるので、私も「そらはー」「ロージー」と呼んでいる。

私を君付けしてくださる人たち

矛盾するようようなことを書くが、明らかに人生の大先輩の方が私を「松木くん」と呼んで、私が「〇〇さん」と呼ぶ関係性がある。それは別に嫌ではなくて、むしろそう呼んでいただける人がいるのはありがたい。例えばyamazさんだったり、カヤック社でお世話になった佐田俊樹さんや佐藤純一さんがそう。今でも食事など連れて行っていただくこともありますが、引き続きよろしくお願いします。

外国人や日本語以外の場合

最後に、外国人だったり、日本語じゃないケースについて軽く触れておきます。

日本語コミュニケーションの場合は、外国人でも普通にさん付けすれば良い。さんはジェンダーニュートラルだし便利。中国語だと「先生」「女士」とか使い分ける必要あるし。

さんが便利だからと言って、英語で -san を使うのは色々意見があるみたいですが、個人的にはポジ寄りです。ただ、英語の場合、同僚間の距離感でも敬称を使わない事が多いし、そもそも自己紹介の段階で "Call me 〇〇" と、どう呼んでほしいか表明することが多いと思う。なのでやはり、どう呼んで欲しいかの表明は大事だし、そういう文化があるのは好ましいことです。

持続可能で幸せなOSS開発 ~ YAPC::Kyotoを終えて

もうだいぶ前になってしまいましたが、3月に京都でYAPC::Kyotoに参加してきました。

YAPC::Kyotoは運営の皆さま、本当にお疲れ様でした。コロナ渦で運営の継続には色々苦労があったかと思います。そんな中、世間的にコロナ明けの雰囲気になってきている中、ちょうど先陣を切るような形でオフラインイベントが開催できて、大きな盛り上がりを見せたのは、皆様の苦労が報われたようにも思いました。旧交も温められたし、それだけではなく、学生支援制度などのお陰で、若い人も参加していて交流が盛り上がってよかったです。

思えば、2019年のYAPC::Tokyoのときに僕がベストトーク賞を受賞した勢いで、懇親会の最後にで胴上げされた後に、無責任に「次は京都でやるぞ!」と、勝手に宣言したのが実現した形でした。JPAにも禄に関わっていないのに(当時は一応末席で参加することもあった)。とはいえ、懇親会で @__papix__ が「次は京都もアリだと思ってるんですよ」とか言っていて、僕が「KRP開催で大西さん(id:onishi)がキーノートだったら最高だよね」と返し、papix「京都開催だったら僕が動きますよ」とかそういう会話はしていたので、まあ目のない話ではないだろうと思った上であの発言をしたと記憶している。事前に何もなしにいきなりあの発言をするとも思えないので。しかし、papixもあまり覚えていないようなので、全部記憶違いかもしれない。

延期もありましたが、KRP開催で大西さんのキーノートが実現できたのは本当に嬉しかった。単なる外野の無責任なファンボーイとしては満足だけど、実現にあたっては難しい点もあったでしょう。papixのお疲れ様エントリーにも、自社への利益誘導にならないかどうか気にしている記述もあって、その点含めて誠実にYAPCに向きあったことが伺えて素晴らしかった。僕は、YAPC::Tokyo時点では、はてな社所属でしたが、その後3回も転職してしまいました。

あらたまさんのベストトーク

あらたまさんベストトーク賞おめでとうございます。このトークは予てから楽しみにしており、僕のトークの中でも「あらたまさんのトーク楽しみですね」という話もしていたのでした。

というのも、YAPC::Japan::Onlineのキーノートを担当させてもらったときに、「ハッカーに憧れた原体験を大事にしたい」という話をしていたのですが、このタイトルは明らかにその先の景色を見せてくれる話だろうと期待していたからです。果たしてその通りの内容でした。

yusukebeの復活

yusukebeの最近の活躍はカッコいい。一時期コードから完全に離れていたのに、ハッカーとして舞い戻ってきた。

元々yusukebeと僕は同世代で、Perl界でも近い立ち位置にいて、ハッカーに憧れつつもハッカーが作ってくれたものを「使う」立場だった。それでいいじゃんというメッセージを込めて"Perl Casual"を立ち上げたのもyusukebeだった。

Perl Casualは盛り上がり、その後のMySQL Casualなどのカジュアル勉強会ムーブメントにも繋がった。

そのようにハッカーに憧れる側だし、それでいいじゃん、というメッセージを発していた彼が、Honoというキラーソフトウェアを引っ提げ、フレームワークやモジュールを使う側ではなくて「作る側」のハッカーとして舞い戻ってきたのはアツい。

それに、Honoを見る人が見るとPerlの影響を感じる作りになっているのもエモい。明らかにPSGI/Plack, Router::Simple, Router::Boom 等からの影響があることがわかってニヤリとしてしまうのである。

moznionと個人技の話

moznionの話は良かった。彼が学生の頃から知っているが、彼のソフトウェア開発の力における「腕力」は凄まじく、時には「異常な努力」などと言われることもある。その一つの集大成がゲストトークとして見られたと思う。

裏テーマとして「個人技」というのがあったというのも納得で、彼の「極限まで求めた個人技と個人技のせめぎあい、そしてその技の協調によって形成されるチームこそが最強のチーム」という意見には全面的に同意する。

#yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた

彼もまた「ハッカー」に影響を受けた世代なのだな、とも。

ハッカーと無縁の世代

無縁とは言い過ぎかもしれないが、最近面白いのは、はてなで活躍中の id:yigarashi さん。YAPC::Kyotoでトークはしていなかったが、YAPC::Japan::Onlineではトークをしていた のもあって注目していた。

あまり交流したことが無いので勝手な想像だが、彼は優秀なソフトウェアエンジニアでありながら、おそらく世代もあって、ハッカーであることにこだわりが無く、最強のエンジニアリングマネージャーを素直に目指している。新世代だと感じる。

ハッカーに憧れた世代が、それに対してそれぞれのアプローチ方法を見つけ、ハッカーに強いこだわりを持たない世代も出てきている、という多様さに対して胸がアツくなるYAPC::Kyotoだった。

自分のトーク

資料は荒削りだが、手直しがいつまでもできそうにないので公開することにする。

https://junkyard.song.mu/slides/yapc-kyoto-2023/#0

元々は自分の事例を例にとって、OSSに関わっていく方法について話していく技術的なTips集的な話にする予定だったが、エモい内容も含まれてしまい、とっ散らかってしまった。このトークの原案は、元々の2020年のときに話そうとしていた内容だったが、そこから数年経って醸成されすぎてしまった。

このトーク資料を作っているときや実際に登壇していた気づいたが、自分は「持続可能で幸せなOSS開発」について論じたい、というモチベーションがあることに気づいた。

OSS開発者が燃え尽きてしまったり、資金難になったりして開発を続けられなくなる話は度々耳にするようになってきた。また、サプライチェーンアタックなど、元々性善説で運用されてきたものが通用しなくなり、悪意が混入するようになってきた。

OSSの影響範囲が大きくなるに連れ、責任が求められてしまったり、悪意の混入を防ぐために重厚なプロセスが敷かれてしまったり、暗黙的なマナーなどが勝手に設けられているケースがあったりと、OSSへの参加に対する敷居が高く感じられてしまっている空気も感じていた。

それらに対して個人的に心を痛めていたのだ。だからこそ「それでもOSSは楽しいよ、気軽にやっていいよ」という無垢な立場を取り続けていた。

ただ、悪意の混入については本当に悩ましい。また、Web3等の一部の人たちが「OSSだからガバナンスがうまくいく」といった、そこだけ切り取ると、あまりにもイノセントに聞こえる発言を聞くと、無垢を気取りすぎるのも良くないと思うようになってきた。

自分にとってはOSS開発やそのコミュニティに関わったことが、大きな人生の転換期だった。「持続可能で幸せなOSS開発」を多くの人が体験できる状況であって欲しい。これについてはまたどこかで論じたいと思う。

WEB+DB PRESS

話がそれるが、このGWのビッグニュースとしてWEB+DB PRESSの休刊というのがあった。

WEB+DB PRESSではPerl Hackers Hubというリレー連載が今でも続いている。リレー形式でPerl Hackerの方にPerlに関する記事を書いてもらうものだ。僕は、2014年と2018年に寄稿し、2016年からは連載の監修チームに関わっていた。2019年の初頭までは執筆者のアサインを担当していて、第35回~第53回まで延べ19名(重複含む)をアサインした。

WEB+DB PRESSはコミュニティに関わっていなかった頃から毎号買っており、誌面からコミュニティとのつながりを感じ取れる気がしたものだ。Perl Hackers Hubに寄稿できたときは非常に嬉しかった。その後、執筆者のアサインをする中で、執筆者の人たちがコミュニティと更に繋がる手助けができたと感じることもあった。

このPerlの連載もいつまで続けられるのか、と思うこともあったが、雑誌のほうが先に休刊してしまうのは残念である。とはいえ業界への貢献も僕が言うまでもなく大きかった雑誌なので、お疲れ様と感謝の意も伝えたい。

YAPCの話からそれてしまったが、Perlやそのコミュニティに関することで、僕にとって大事な話なのでとりあげておく。

はてなと旧交

YAPC::Kyoto期間中、連日はてなオフィスにお邪魔して飲んでいました。各所の懇親会の最後の受け皿となっていて面白かったし、その懐の深さはすごかった。旧交を温められてよかったです。ありがとうございました。

ついでに、はてな社で取材を受けてきました。写真はいい感じに撮ってくれてますが、この日はYAPC::Kyoto明けでまだYAPC気分が残存しており、実は、 id:onk ともどもだいぶYAPC疲れがある中での対談でした。その後の編集でカバーしたこともあり、面白い内容にはなっていると思うので、是非ご覧ください。

ヘンリーで活躍中の id:Songmu を訪問 | はてな卒業生訪問企画 [#3]

ヘンリーに入社しました

1月から株式会社ヘンリーに入社しました。ヘンリーは「社会課題を解決し続け、より良いセカイを創る」というミッションを掲げ、現在はHenryというレセコン一体型クラウド電子カルテサービスを主力として医療DXに取り組んでいるスタートアップです。

https://corp.henry-app.jp/

ヘンリーのことはあまり知らなかったのですが、ずっと一緒に働きたいと思っていたエンジニアの一人である縣さんが所属しており、今回私が転職活動を始めたのを彼が早々に察知して誘ってくれたのがきっかけです。

彼と話したところ、開発に色々課題は抱えつつも前向きに、楽しそうに働いていると感じたのが印象的でした。ナイスガイな彼がそれくらい魅力を感じているのであれば、良いチームで面白い社会課題を解いているだろうなと。

その後、2週間で様々なポジションの7名とお話しました。どの方もモチベーション高く、顧客や事業やプロダクトに取り組んでいるのが感じられ、やはり良いチームだと確信でき、事業やプロダクトにも魅力を感じられそうだったので、入社することに決めました。

比較的年齢が若い会社ですが、CEOの一人も含め、働きながら子育てしている社員も多く、健康に活力を持って生きながら、柔軟にモチベーション高く働ける環境を志向している点も、ミッションや事業と言行一致していて魅力的でした。

人数もまだ30人程度で、リモートワーク中心で入社する上で、自分にとってちょうど良く感じる組織規模だったというのもあります。

入社して

入社して早くも2週間近く経ちましたが、ちょうど全社員参加のワークショップがあってチームメンバーや業務をキャッチアップできて助かりました。各メンバーのモチベーションの高さも改めて感じられ、これくらいの人数のスタートアップの良さを感じましたし、人がこれから増える中でもそれを維持したいですね。月末にはオフラインの新年会もあるようですし、良いタイミングで入社できて嬉しいです。

入社後驚いたことの一つに、営業チームの各メンバーがHenryをSaaSとして売っていくことをしっかりと理解していたことがあります。カスタマイズを極力避け、自分たちの製品がフィットする病院をターゲティングしてリストアップし営業をかけている点が非常にクレバーだと感じました。開発側としても迷いを減らして生産性を上げられるので嬉しいポイントです。

とはいえ、医療というドメインはなかなか難しく、入社したら予想通り情報量も多くて大変です。私自身も自分が直接のユーザーにならないサービスを開発するのはSIer時代以来でだいぶ久しぶりのことで、その点もチャレンジングではあります。

ただ、私も歳を重ねるに連れて、医療機関にお世話になる機会も増え、医療は、今後一層自分ゴト化せざるを得ないドメインです。また、電子カルテ自体も実はまだ普及率が50%程度にとどまり、業界にDXの余白が多く残っている状況で、事業にもまだまだ伸びしろがあります。日本は世界一の高齢化先進国の一つになることが宿命付けられているので、その分野で世界をリードできるチャンスもあります。そんな中で良い仲間と有意義な社会課題を面白く解いていくことを楽しみにしています。

また、今はレセコン一体型電子カルテがメインサービスで、しばらくはそれが注力事業ですが、長いスパンでは医療ドメインや隣接分野でも新規サービスを展開していきたいと考えているようですし、新規事業がどんどん生まれる会社になると嬉しいですね。

技術

システムとしてはいくつかのマイクロサービスに分割されていてバックエンドは主にKotlin、BFFにNode.js, TypeScript、フロントはReact, TypeScriptです。BFFのプロトコルは後ろはgRPCで前はGraphQLです。クラウドはGCPで主にCloud Runを実行環境としています。

結構モダンな技術選定ではありますが、その分苦労している点もあるようです。お陰様でお客様も付き始め、その過程で当初想定していなかったことや、運用の難しさなどにも当然直面しています。当初の設計も振り返りが必要なタイミングだとも感じているようです。

また、当然品質が大事な製品なので、QAフローを厚くやりつつも、そこが開発サイクルのボトルネックにならないよう全員がQAを意識して開発に取り組む必要性も感じています。言うのは簡単ですが、これは開発に携わるメンバー全員が感じている大きな課題意識です。

採用

ということで、各職種絶賛採用中なので、お問い合わせいただけると嬉しいです。

https://jobs.henry-app.jp/

また、1/24(火)にオフラインのエンジニアミートアップをやるのでヘンリーが少しでも面白そうだと思ったらお申し込みください。ピザやビールを片手にラフに技術について雑談できればと思います。そういう機会も久しぶりなので楽しみですね。


https://henry.connpass.com/event/271976/

お待ちしています!